sdlc phases
Какво представлява жизнения цикъл на разработката на софтуер (SDLC)? Научете SDLC фази, методологии, процес и модели
Жизнен цикъл на разработката на софтуер (SDLC) е рамка, която определя стъпките, свързани с разработването на софтуер на всяка фаза. Той обхваща подробния план за изграждане, внедряване и поддръжка на софтуера.
SDLC дефинира пълния цикъл на разработка, т.е. всички задачи, свързани с планирането, създаването, тестването и внедряването на софтуерен продукт.
Какво ще научите:
- Процес на жизнен цикъл на разработка на софтуер
- SDLC цикъл
- SDLC фази
- Модели на жизнения цикъл на разработка на софтуер
- Заключение
Процес на жизнен цикъл на разработка на софтуер
SDLC е процес, който определя различните етапи, свързани с разработването на софтуер за предоставяне на висококачествен продукт. SDLC етапите обхващат целия жизнен цикъл на софтуер, т.е.от създаването до оттеглянето на продукта.
Придържането към процеса SDLC води до разработване на софтуера по систематичен и дисциплиниран начин.
Предназначение:
Целта на SDLC е да достави висококачествен продукт, който отговаря на изискванията на клиента.
SDLC е определила своите фази като Събиране на изисквания, Проектиране, кодиране, тестване и поддръжка. Важно е да се придържате към фазите, за да предоставяте Продукта по систематичен начин.
Например, Трябва да се разработи софтуер и екипът е разделен, за да работи по характеристика на продукта и му е позволено да работи както иска. Единият от разработчиците решава да проектира първо, докато другият решава да кодира първи, а другият - в документационната част.
Това ще доведе до провал на проекта, поради което е необходимо да имате добри познания и разбиране сред членовете на екипа, за да доставите очакван продукт.
SDLC цикъл
SDLC Cycle представлява процеса на разработване на софтуер.
По-долу е схематично представяне на цикъла SDLC:
SDLC фази
По-долу са дадени различните фази:
- Събиране и анализ на изискванията
- Дизайн
- Внедряване или кодиране
- Тестване
- Разгръщане
- Поддръжка
# 1) Събиране и анализ на изискванията
По време на тази фаза, цялата съответна информация се събира от клиента, за да се разработи продукт според неговите очаквания. Всички неясноти трябва да бъдат разрешени само през тази фаза.
Бизнес анализаторът и ръководителят на проекти организираха среща с клиента, за да съберат цялата информация като това, което клиентът иска да изгради, кой ще бъде крайният потребител, каква е целта на продукта. Преди изграждането на продукт е много важно разбирането или познаването на продукта.
Например, Клиент иска да има приложение, което включва парични транзакции. В този случай изискването трябва да е ясно като какъв вид транзакции ще се извършват, как ще се извършва, в коя валута ще се извършва и т.н.
След като се събере изискването, се прави анализ, за да се провери осъществимостта на разработването на даден продукт. В случай на неяснота се установява повикване за по-нататъшно обсъждане.
След като изискването е ясно разбрано, се създава документът SRS (Software Requirement Specification). Този документ трябва да бъде добре разбран от разработчиците и също така трябва да бъде прегледан от клиента за бъдещи справки.
# 2) Дизайн
В тази фаза изискването, събрано в SRS документа, се използва като вход и се извежда архитектура на софтуера, която се използва за внедряване на разработка на системата.
# 3) Внедряване или кодиране
Внедряването / кодирането започва, след като разработчикът получи документа за проектиране. Дизайнът на софтуера е преведен в изходния код. Всички компоненти на софтуера са внедрени в тази фаза.
как да фалшифицирате имейл адрес
# 4) Тестване
Тестването започва, след като кодирането завърши и модулите са пуснати за тестване. На този етап разработеният софтуер се тества щателно и всички открити дефекти се възлагат на разработчиците, за да ги отстранят.
Повторното тестване, регресионното тестване се извършва до момента, в който софтуерът е в съответствие с очакванията на клиента. Тестерите препращат SRS документа, за да се уверят, че софтуерът отговаря на стандарта на клиента.
# 5) Внедряване
След като продуктът бъде тестван, той се внедрява в производствената среда или първо UAT (Тест за приемане от потребителя) се извършва в зависимост от очакванията на клиента.
В случая на UAT се създава реплика на производствената среда и клиентът заедно с разработчиците прави тестването. Ако клиентът намери приложението, както се очаква, тогава клиентът се отписва, за да пусне на живо.
# 6) Поддръжка
След внедряването на продукт в производствената среда, поддръжката на продукта, т.е. ако възникне някакъв проблем и трябва да бъде отстранен или трябва да се направи подобрение, се полага от разработчиците.
Модели на жизнения цикъл на разработка на софтуер
Моделът на жизнения цикъл на софтуера е описателно представяне на цикъла на разработване на софтуер. SDLC моделите може да имат различен подход, но основните фази и активност остават едни и същи за всички модели.
# 1) Модел на водопад
Модел на водопад е първият модел, който се използва в SDLC. Известен е и като линеен последователен модел.
В този модел резултатът от една фаза е входът за следващата фаза. Разработването на следващата фаза започва едва когато предходната фаза приключи.
- Първо се извършва събиране и анализ на изискванията. След като изискването замръзне, тогава може да започне само проектирането на системата. Тук създаденият SRS документ е изход за фазата на изискване и действа като вход за системния дизайн.
- В софтуерната архитектура и дизайн на системния дизайн се създават документи, които действат като вход за следващата фаза, т.е. внедряване и кодиране.
- Във фазата на внедряване се извършва кодиране и разработеният софтуер е вход за следващата фаза, т.е. тестване.
- Във фазата на тестване разработеният код се тества щателно, за да се открият дефектите в софтуера. Дефектите се регистрират в инструмента за проследяване на дефекти и се тестват отново, след като бъдат отстранени. Регистрация на грешки, повторно тестване, тестване на регресия продължава до момента, в който софтуерът е в състояние за стартиране.
- Във фазата на внедряване разработеният код се премества в производство, след като клиентът даде знак за изключване.
- Всички проблеми в производствената среда се решават от разработчиците, които са подложени на поддръжка.
Предимства на модела на водопада:
- Моделът на водопада е простият модел, който може лесно да се разбере и е този, при който всички фази се извършват стъпка по стъпка.
- Резултатите от всяка фаза са добре дефинирани и това не води до сложност и прави проекта лесно управляем.
Недостатъци на модела Waterfall:
- Моделът на водопада отнема много време и не може да се използва в краткосрочните проекти, тъй като в този модел не може да се стартира нова фаза, докато не завърши текущата фаза.
- Моделът на водопада не може да се използва за проекти, които имат несигурни изисквания или при които изискването продължава да се променя, тъй като този модел очаква изискването да бъде ясно на самата фаза на събиране и анализ на изискванията и всяка промяна в по-късните етапи би довела до по-високи разходи, тъй като ще бъдат необходими промени във всички фази.
# 2) V-образен модел
V- Модел е известен също като модел за проверка и валидиране. В този модел Проверката и валидирането вървят ръка за ръка, т.е. разработването и тестването вървят паралелно. V моделът и моделът водопад са еднакви, с изключение на това, че планирането на тестовете и тестването започват на ранен етап във V-Model.
а) Фаза на проверка:
(i) Анализ на изискванията:
На този етап се събира и анализира цялата необходима информация. Дейностите по проверка включват преглед на изискванията.
(ii) Дизайн на системата:
След като изискването е ясно, системата се проектира, т.е.архитектура, компонентите на продукта се създават и документират в проектния документ.
(iii) Дизайн на високо ниво:
Дизайнът на високо ниво определя архитектурата / дизайна на модулите. Той определя функционалността между двата модула.
(iv) Дизайн на ниско ниво:
Дизайнът на ниско ниво определя архитектурата / дизайна на отделните компоненти.
(v) Кодиране:
Разработването на кода се извършва в тази фаза.
б) Фаза на валидиране:
(i) Тестване на единица:
Единично тестване се извършва с помощта на модулни тестови случаи, които са проектирани и се извършва във фазата на проектиране на ниско ниво. Единичното тестване се извършва от самия разработчик. Извършва се върху отделни компоненти, които водят до ранно откриване на дефекти.
(ii) Тестване на интеграцията:
Интеграционно тестване се извършва с помощта на тестови случаи на интеграция във фаза на високо ниво на проектиране. Интеграционното тестване е тестването, което се извършва върху интегрирани модули. Извършва се от тестери.
(iii) Тестване на системата:
Тестване на системата се извършва във фазата на проектиране на системата. На тази фаза се тества пълната система, т.е.тества се цялата функционалност на системата.
(iv) Изпитване за приемане:
Изпитването за приемане е свързано с фазата на анализ на изискванията и се извършва в средата на клиента.
Предимства на V - Модел:
- Това е прост и лесно разбираем модел.
- Подходът V-model е добър за по-малки проекти, при които изискването е дефинирано и замръзва в ранния етап.
- Това е систематичен и дисциплиниран модел, който води до висококачествен продукт.
Недостатъци на V-Model:
- V-образният модел не е добър за текущи проекти.
- Промяната на изискванията на по-късен етап би струвала твърде много.
# 3) Прототип модел
Прототипният модел е модел, при който прототипът е разработен преди действителния софтуер.
Прототипните модели имат ограничени функционални възможности и неефективна производителност в сравнение с действителния софтуер. Фиктивни функции се използват за създаване на прототипи. Това е ценен механизъм за разбиране на нуждите на клиентите.
Софтуерните прототипи са създадени преди действителния софтуер, за да получат ценна обратна връзка от клиента. Обратните връзки са внедрени и прототипът отново се преглежда от клиента за всяка промяна. Този процес продължава, докато моделът не бъде приет от клиента.
След като приключи събирането на изискванията, се създава бързият дизайн и се изгражда прототипът, който се представя на клиента за оценка.
Отзивите на клиентите и усъвършенстваното изискване се използват за модифициране на прототипа и отново се представят на клиента за оценка. След като клиентът одобри прототипа, той се използва като изискване за изграждане на действителния софтуер. Действителният софтуер се изгражда, като се използва моделът на водопада.
Предимства на прототипния модел:
- Прототипният модел намалява разходите и времето за разработка, тъй като дефектите се откриват много по-рано.
- Липсващата функция или функционалност или промяна в изискването могат да бъдат идентифицирани във фазата на оценяване и могат да бъдат приложени в рафинирания прототип.
- Участието на клиент от началния етап намалява всякакво объркване в изискването или разбирането на която и да е функционалност.
Недостатъци на прототипния модел:
- Тъй като клиентът участва във всяка фаза, клиентът може да промени изискванията на крайния продукт, което увеличава сложността на обхвата и може да увеличи времето за доставка на продукта.
# 4) Спирален модел
Спиралният модел включва итеративен и прототипен подход.
В итерациите се следват фази на спирален модел. Циклите в модела представляват фазата на процеса SDLC, т.е. най-вътрешният цикъл е от събиране и анализ на изискванията, който следва планирането, анализа на риска, разработването и оценката. Следващият цикъл е проектиране, последвано от внедряване и след това тестване.
Спиралният модел има четири фази:
- Планиране
- Анализ на риска
- Инженерство
- Оценка
(i) Планиране:
Фазата на планиране включва събиране на изисквания, при което цялата необходима информация се събира от клиента и се документира. Документът за спецификация на софтуерните изисквания се създава за следващата фаза.
(ii) Анализ на риска:
На тази фаза се избира най-доброто решение за свързаните рискове и анализът се извършва чрез изграждане на прототипа.
Например , рискът, свързан с достъпа до данните от отдалечена база данни, може да бъде, че скоростта на достъп до данните може да е твърде бавна. Рискът може да бъде разрешен чрез изграждане на прототип на подсистемата за достъп до данни.
(iii) Инженеринг:
След като се направи анализ на риска, се прави кодиране и тестване.
(iv) Оценка:
Клиентът оценява разработената система и планира следващата итерация.
Предимства на спиралния модел:
- Анализът на риска се извършва широко, като се използват прототипните модели.
- Всяко подобрение или промяна във функционалността може да се направи в следващата итерация.
Недостатъци на спиралния модел:
- Спиралният модел е най-подходящ само за големи проекти.
- Цената може да бъде висока, тъй като може да отнеме голям брой повторения, което може да доведе до много време за достигане на крайния продукт.
# 5) Итеративен инкрементален модел
Итеративният инкрементален модел разделя продукта на малки парчета.
Например , Функцията, която ще бъде разработена в итерацията, е решена и внедрена. Всяка итерация преминава през фазите, а именно анализ на изискванията, проектиране, кодиране и тестване. В итерациите не се изисква подробно планиране.
След като итерацията приключи, продуктът се проверява и се доставя на клиента за оценка и обратна връзка. Отзивите на клиентите се прилагат в следващата итерация заедно с новодобавената функция.
Следователно продуктът се увеличава по отношение на характеристиките и след завършване на итерациите окончателното изграждане съдържа всички характеристики на продукта.
Фази на итеративен и инкрементален модел на развитие:
- Начална фаза
- Фаза на разработка
- Фаза на строителство
- Преходна фаза
(i) Начална фаза:
Началната фаза включва изискването и обхвата на проекта.
(ii) Фаза на разработка:
Във фазата на разработване се предоставя работната архитектура на продукта, която покрива риска, идентифициран във фазата на начало, и също така отговаря на нефункционалните изисквания.
(iii) Фаза на строителство:
Във фазата на изграждане архитектурата се попълва с кода, който е готов за внедряване и се създава чрез анализ, проектиране, внедряване и тестване на функционалните изисквания.
(iv) Преходна фаза:
Във фазата на преход продуктът е внедрен в производствената среда.
Предимства на итеративния и инкрементален модел:
- Всяка промяна в изискването може да бъде направена лесно и няма да струва, тъй като има обхват за включване на новото изискване в следващата итерация.
- Рискът се анализира и идентифицира в итерациите.
- Дефектите се откриват на ранен етап.
- Тъй като продуктът е разделен на по-малки парчета, е лесно да се управлява продукта.
Недостатъци на итеративен и инкрементален модел:
- Пълно изискване и разбиране на продукта са необходими, за да се разграждат и изграждат постепенно.
# 6) Модел на Големия взрив
Моделът на Големия взрив няма дефиниран процес. Парите и усилията се обединяват, тъй като входът и изходът идват като разработен продукт, който може да бъде или да не е същият като това, което се нуждае от клиента.
Моделът Big Bang не изисква много планиране и планиране. Разработчикът прави анализ и кодиране на изискванията и разработва продукта според неговото разбиране. Този модел се използва само за малки проекти. Няма екип за тестване и не се прави официално тестване и това може да е причина за провала на проекта.
Предимства на модела от Големия взрив:
- Това е много прост модел.
- Изисква се по-малко планиране и планиране.
- Разработчикът има гъвкавостта да създава собствен софтуер.
Недостатъци на модела за Големия взрив:
- Моделите от Големия взрив не могат да се използват за големи, текущи и сложни проекти.
- Висок риск и несигурност.
# 7) пъргав модел
Agile Model е комбинация от итеративен и инкрементален модел. Този модел се фокусира повече върху гъвкавостта при разработване на продукт, а не върху изискването.
В Agile продуктът се разбива на малки постепенни компилации. Той не е разработен като цялостен продукт с едно движение. Всяка компилация се увеличава по отношение на характеристиките. Следващата компилация е изградена върху предишна функционалност.
В гъвкавите итерации се наричат спринтове. Всеки спринт трае 2-4 седмици. В края на всеки спринт собственикът на продукта проверява продукта и след неговото одобрение той се доставя на клиента.
Отзивите на клиентите се вземат за подобрение и по неговите предложения и подобрения се работи в следващия спринт. Тестването се извършва във всеки спринт, за да се сведе до минимум рискът от неуспехи.
Предимства на Agile Model:
- Тя позволява повече гъвкавост за адаптиране към промените.
- Новата функция може да бъде добавена лесно.
- Удовлетвореността на клиентите, тъй като отзивите и предложенията се вземат на всеки етап.
Недостатъци:
- Липса на документация.
- Agile се нуждае от опитни и висококвалифицирани ресурси.
- Ако клиентът не е наясно как точно иска да бъде продуктът, тогава проектът ще се провали.
Заключение
Спазването на подходящ жизнен цикъл е много важно за успешното завършване на проекта. Това от своя страна улеснява управлението.
Различните модели на жизнения цикъл на разработка на софтуер имат свои плюсове и минуси. Най-добрият модел за всеки проект може да бъде определен от фактори като изискване (независимо дали е ясно или неясно), сложност на системата, размер на проекта, цена, ограничение на уменията и др.
Пример, в случай на неясно изискване, спиралните и пъргавите модели са най-добре да се използват, тъй като необходимата промяна може да бъде приспособена лесно на всеки етап.
Моделът Waterfall е основен модел и всички останали SDLC модели се базират само на него.
Надявам се, че бихте получили огромни познания за SDLC.
Препоръчително четене
- Спирален модел - Какво е SDLC спирален модел?
- Какво е SDLC модел водопад?
- Какво е жизнен цикъл на тестване на софтуер (STLC)?
- Тестване на софтуер QA Assistant Job
- 10 НАЙ-ДОБРИ компании и услуги за разработка на софтуер през 2021 г.
- Практическо тестване на софтуер - Нова БЕЗПЛАТНА електронна книга [Изтегляне]
- На място - офшорни модели на проекти за тестване на софтуер (и как да го направя да работи за вас)
- Защо софтуерът има грешки?