После того, как мы решили создать необходимое программное обеспечение, с самого начала мы будем работать с различными элементами, благодаря UML мы можем выполнить довольно подробный этап моделирования, который поможет команде разработчиков.
Однако есть и другие факторы, связанные с UML, хотя они не связаны с построением диаграмм, одним из таких факторов является методология разработки программного обеспечения проекта, который мы собираемся выполнить.
методологии
При запуске проекта самое обычное состоит в том, что есть члены команды, которые хотят начать разработку и кодирование решения с первого дня, однако этот тип нетерпения должен быть немедленно отключен, а не только потому, что невозможно знать, что он собирается делать. сосредоточиться на разработчиках, но также добавляет фактор давления, чтобы увидеть «ощутимые» результаты в короткие сроки.
Что происходит сегодня, у нас есть отличные рабочие среды, которые обещают нам сократить время разработки, используя их инструменты, однако, если наш проект недостаточно сфокусирован, мы закончим работать больше, чем необходимо, исправляя то, что уже было сделано в начале.
Методология помогает нам построить шаги, которые мы собираемся предпринять для реализации проекта, который мы разработали. На разных этапах выбранной методологии у нас будет пространство для сбора информации, моделирования решения, различных случаев. использования и, наконец, начало кодирования.
На данный момент у нас есть два варианта:
- Старый метод
- Недавний метод
Давайте посмотрим на первый.
Старый метод
В то время он делал так, чтобы этапы происходили один за другим, упрощая таким образом способ решения проблемы, поэтому было сделано определение серии этапов и установление упущений для выполнения каждого из них .
Из-за этого упрощения, когда проблема возникла на более позднем этапе, но проблема была получена на более раннем этапе, оценки проекта пришлось практически разбить для перезапуска.
Из-за разделения каждой стадии было обычным делом находить случаи, когда разработчик никогда не работал с разработчиком или разработчиком модели системы, таким образом, разделяя программное обеспечение человека, который разработал функциональные возможности.
Давайте посмотрим на следующий график, который описывает процесс, выполненный с помощью этой методологии:
Это водопадный процесс, он берет свое название по мере того, как каждый этап течет за другим, и чтобы начать новый этап, мы должны завершить нынешний этап, поскольку, как упоминалось ранее, этот подход имеет серьезные недостатки.
На этом мы заканчиваем эту первую часть руководства, мы уже знаем немного больше о том, как методология разработки программного обеспечения работала в древние времена, в следующей части мы увидим последние методологии и другие важные аспекты процесса разработки.
Я оставляю здесь часть 2 этого урока
- 0
СТАТЬИ