✅ UML - Процес на разработка, част 1

Съдържание

След като сме решили да изградим необходимия ни софтуер, от самото начало ще се натъкнем на различни елементи, благодарение на UML можем да направим доста подробна фаза на моделиране, която да помогне на екипа за разработка.
Съществуват обаче и други фактори, свързани с UML Въпреки че те нямат отношение към изграждането на диаграми, един от тези фактори е методологията за разработка на софтуер на проекта, която ще изпълним.
Методологии
Когато стартирате проект, най -нормалното е, че има членове на екипа, които желаят да започнат разработването и кодирането на решението от първия ден, но този вид нетърпение трябва да бъде изключен незабавно, не само защото е невъзможно да се знае какви са те ще се фокусира върху разработчиците, но също така добавя фактор на натиск, за да види "осезаеми" резултати за кратко време.
Това, което се случва днес, имаме страхотно рамки на работа, която обещава да съкрати часовете за разработка, когато използваме техните инструменти, но ако нашият проект не е добре фокусиран, ще свършим повече от необходимото, като поправим вече направеното в началните моменти.
А методология Помага ни да изградим стъпките, които ще предприемем, за да осъществим изграждането на проекта, който сме измислили, през различните фази на избраната методология ще имаме пространство за събиране на информация, моделиране на решението , различните случаи на използване и накрая началото на кодирането.
На този етап имаме два варианта:

Стар метод.
Скорошен метод.

Всеки от тях е генерирал достатъчно информация, за да може да опише процеса на изграждане на проект.
Нека видим първия от тях.
Старият метод
Този метод по времето, когато той правеше, беше да направи етапите да се случват един след друг, като по този начин опрости начина, по който е изправен проблемът, тогава какво е трябваше да се определи поредица от етапи и да се установят пропуски за извършване на всеки един.
Поради това опростяване, когато проблем възникне на по -късен етап, но проблемът е получен от по -ранен етап, беше необходимо на практика да се пречупят прогнозите за проекта, за да се започне отначало.
Поради разделянето на всеки етап, беше обичайно да се откриват случаи, в които разработчикът никога не е работил с дизайнера или системния моделатор, като по този начин развежда софтуера от лицето, което е измислило функционалностите.
Нека видим следната графика, която описва процес, направен с тази методология:

Това е каскаден процес, той приема името си, тъй като всеки етап тече един след друг и за да започне нов етап е необходимо да завърши настоящия, както споменахме по -рано, този подход има сериозни недостатъци.
С това приключваме тази първа част от урока, вече знаем малко повече за това как методологията за разработка на софтуер е работила в древни времена, в следващата част ще видим най -новите методологии и други важни аспекти на процеса на разработка.
Оставям тук част 2 от този урок