Мерал Емин 1601681103

Етапи при разработването на софтуер

 Agile methodology – Agile е итеративен подход за управление на проекти и разработка на

софтуер, който помага на екипите да предоставят стойност на своите клиенти по-бързо и с по-малко
главоболия. Вместо да заложи всичко на старт с "голям взрив", пъргавият екип доставя работа с
малки, но консумативни стъпки. Изискванията, плановете и резултатите се оценяват непрекъснато,
така че екипите имат естествен механизъм за бързо реагиране на промените. Хората и
комуникацията стоят над процесите и инструментите

o Работещият софтуер е над подробната документация

o Сътрудничеството с клиента е над преговорите по време на сключване на договора
o Адресирането на промените стои над следването на плана

Аgile manifesto се основава на следните дванадесет принципа:

1) Удовлетворение на клиентите чрез бърза доставка на полезен софтуер

2) Промяна в спецификациите е възможна, дори и в късните фази на проекта
3) Често предоставяне на работещ софтуер (в периоди от седмици, а не месеци)
4) Работещият софтуер е основната мярка за напредък
5) Устойчиво развитие, което успява да поддържа постоянно темпо
6) Тясно, ежедневно сътрудничество между бизнес служители и разработчици
7) Разговорите лице в лице са най-добрата форма на комуникация (съвместна локация)
8) Проектите се изграждат около мотивирани хора, на които се има доверие
9) Непрекъснато внимание към техническо съвършенство и добър дизайн
10) Простота – изкуството максимално количество работа да бъде пропусната, е от
съществено значение
11) Самоорганизиращи се екипи
12) Редовна адаптация към променящи се обстоятелства

Недостатъци:

Agile не може да се прилага към мащабни проекти.

Agile не може да се справи с разработването на проекти, които изискват по-голям времеви диапазон.

Крайния продукт е резултат от няколко сесии обсъждане и промени в дадения проект. Той трябва да
удовлетворява клиента и да е спазен времевия период. Екипът дава на клиента описани
спецификациите, документацията и готовият продукт.

 Scrum е рамка, която помага на екипите да работят заедно. Подобно на ръгби отбора (откъдето е
получил името си) обучение за голямата игра, Scrum насърчава екипите да се учат чрез опит, да се
самоорганизират, докато работят върху даден проблем, и да разсъждават върху своите печалби и
загуби, които непрекъснато се усъвършенстват.
 Докато Scrum, за който говоря, се използва най-често от екипи за разработка на софтуер, неговите
принципи и уроци могат да се прилагат за всички видове екипна работа. Това е една от причините
Scrum да е толкова популярен. Често смятан за гъвкава рамка за управление на проекти, Scrum
описва набор от срещи, инструменти и роли, които работят съвместно, за да помогнат на екипите да
структурират и управляват работата им.
Ключови роли или самият SCRUM екип.
 Product Owner / Собственик на продукта
Собственикът на продукта е отговорното лице за това организацията да добавя стойност за
клиентите.
 Scrum Master / Scrum ръководител
Ръководителя е отговорен да бъдат премахвани пречките при изпълнението на договорените
в спринта задачи и да постигне желаните за спринта цели. Следи за изпълнение на правилата
и за това нещата да се случват по концепциите на SCRUM.
 Development Team / Екип разработка
Екипът, който създава продукта – анализира, прави архитектурата, пише код, тества го,
извършва работа по техническа комуникация, документира и т.н. Състои се от 3 до 9 души,
които имат различни и сходни умения по множеството работа.
Недостатъци
Не важи за разсрастващи се екипи.

Крайният продукт е следствие на няколко Спринта, чрез които са достигнати желанията на клиента в
крайните срокове, като след всеки спринт има обсъждане на дадените промени, докато не се
удовлетворят изискванията. Екипът дава на клиента описани спецификациите, документацията и
готовият продукт.

 Waterfall Model - Waterfall методологията се отличава с това, че дейностите протичат в

процес, при който фазите на разработка на софтуера следват точно определен ред:

1. Спецификация на изискванията (Анализ на изискванията)

2. Софтуерен дизайн (Софтуерна архитектура)

3. Имплементация и интеграция

4. Тестване (Валидация)

5. Внедряване (Инсталация)

6. Поддръжка.

Процесите при водопадния модел протичат линейно и последователно. Това означава, че всеки от
етапите в процеса на разработка започва, само когато предишната фаза е напълно завършена. При
стриктно спазване на методологията връщане към предишна фаза за преправяне на продукта поради
промяна на изискванията, не се допуска.

Употреба
Най-често се употребява при разработка на софтуер, при който промяната на изискванията и обхвата
е малко вероятна и не е критична.

Предимства
– принципите на действие на модела лесно могат да бъдат обяснени на потребителя;

– има добре структуриран подход към разработката;

– различните етапи и дейностите в тях са точно определени;

– планирането на проекта и изплнението му по график е по-лесно;

– тестването на всеки етап осигурява ранното откриване на грешки, ккато и избягване на отклонения
от обхвата на проекта поради неразбиране на определена част от изискванията на клиента;

– във всяка фаза се виждат конкретни резултати.

Недостатъци

– изхожда се от презумпцията, че системата е „замразена“ и изискванията и желанията на клиента

няма да се променят, което е трудно постижимо в реалния свят;

– изключително трудно може да се върне екипа на предишен етап, който вече е завършил;

– има твърде малко гъвкавост по регулацията на обхвата на проекта и всяка промяна по него е
трудоемка и скъпа.

Краен продукт

Водопадният модел е методология, при която разработката на софтуерен продукт е скъпа и

времеемка. За сметка на това готовият софтуер има подробна документация и всеки елемент от него
отговаря на заданието на клиента и е тестван подробно.

Може би едно от най-добрите приложения на този модел е разработката на софтуер за институции и

организации, при които няма големи и важни промени в последната минута.