Съдържание
След като знаем как методологиите за разработка на проект или система са работили в древни времена, можем да вземем предвид различните грешки и опасни точки за екипа, които са имали.Тъй като ние сме еволюционни същества и имаме толкова много проблеми с ограниченията, вече повдигнати в първата част на урока, той започва да промяна на методологията, Вече няма строго разделяне на етапите, а по -скоро се търси сътрудничеството на екипа, където всеки член участва в разработването на етапите, например разработчиците помагат при събирането на информация, дизайнерите и моделистите в развитие и др.
Скорошен метод
Както очаквахме в началото на урока, скорошният метод ни позволява да приложим сътрудничество на всеки етап от развитието, подпомагайки това за повишаване на разбирането за проекта като цяло в екипа, за по -голямо разбиране и разбиране, ще имаме по -добри решения, които ще се нуждаят от по -малко корекции при кодирането на софтуера.
Въпреки че всичко може да изглежда като доказателство за точки против, трябва да подчертаем някои проблеми, които може да са налице в нашия процес на разработка, така че да видим, че все още сме далеч от перфектния начин да правим проект.
Един от първи проблеми Това, което можем да открием, е липсата на участие на членовете на екипа, въпреки че това е все по -малко, все още можем да намерим срамежливи хора, които се страхуват да изразят мнението си, така че те са оставени настрана, отслабвайки състоянието на колективното познание.
Друг момент е, че много ръководители на проекти трябва да предоставят напредъка на проекта на клиенти или потребители, така че е трудно да се каже, че анализът вече е завършен и разработката е започнала; Поставянето на този тип ограничения може да бъде контрапродуктивно, тъй като може да породи неправилни очаквания и да окаже натиск върху екипа.
RAD3
Това методология получава името си от съкращението за „Бързо разработване и разпространение на дизайн на приложения”, Което ще остане като разработка на дизайн и бързо разпространение на приложения.
Както виждаме в предишната графика, тази методология ни позволява да интегрираме 3 зони за изпълнение По този начин важните етапи от разработването на проекти не са изолирани, така че разработчикът може да получи достъп до важни данни за проекта в момента, в който се генерира, точно както анализаторът може да се намеси в други етапи.
След като всичко е в съответствие с първата доставка на проекта, с това ще получим необходимата обратна връзка за по -кратко време, отколкото използването на старата методология и с това могат да бъдат включени корекции и подобрения, предложени от крайния потребител.
Както виждаме, въпреки различните етапи, този методологичен подход ни дава пространство за генериране на UML диаграми като по този начин фокусира идеите в пространство с a разбираем език за всички страни.
С това завършваме втората част на урока, където се научихме как да включим методологията в нашите разработки и също така да ни помогнем с UML.
Част 1 от този урок
Процес на разработка на UML, част 1
Хареса ли ви и помогнахте на този урок?Можете да възнаградите автора, като натиснете този бутон, за да му дадете положителна точка