Какво представлява моделът на жизнения цикъл на разработката на софтуер (sdlc)? - определение от техопедия

Определение - Какво означава модел на жизнения цикъл на разработката на софтуер (SDLC)?

Моделът на жизнения цикъл на разработката на софтуер (SDLC) е концептуална рамка, описваща всички дейности в проекта за разработка на софтуер от планиране до поддръжка. Този процес е свързан с няколко модела, всеки от които включва различни задачи и дейности.

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

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

Techopedia обяснява модела на жизнения цикъл на разработката на софтуер (SDLC)

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

• Извличане на изискванията: Клиентът има неясна представа за това какво се изисква. След задълбочен анализ на изискванията и стъпки за планиране за постигане на целта, абстрактната идея за клиент се прилага на практика от група софтуерни инженери.
• Описание на софтуера: Описва, че софтуерът е следващата стъпка в процеса.
• Абстрактно представяне на системата: Създадено е, за да потвърди, че отговаря на изискванията на продукта и интерфейси с други софтуерни продукти, заедно с основния хардуер.
• Изисквания към клиента: Изпълнява се чрез кода, програмиран от софтуерните инженери.
• Тестване на кода: Кодът се тества, за да се увери, че няма грешки и се придържа към изискванията на клиента.
• Документация на вътрешния дизайн: За бъдеща поддръжка и усъвършенстване на продукта.
• Поддръжка: Извършва се за промяна на архитектурата на системата според бъдещите нужди. Това може да изисква добавяне на код или промяна на съществуващия код.

Горепосоченият процес на развитие е опростен от серия от модели. Екипът за разработка избира най-подходящия модел. Различните модели са:

• Водопад модел: Разработчиците посочват изискванията, анализират ги, определят решение и рамкират софтуерна архитектура, представяне на интерфейса и алгоритмични детайли. След това те разработват кода, тестват кода, разгръщат софтуера и го поддържат. Въпреки че методът на водопада е лесен за разбиране и задава стабилност на изискванията, той може да създаде невярно впечатление, че не осигурява много участие на клиентите. Основният проблем на този модел е, че изискването за коригиране на грешки трябва да бъде известно предварително и на ранен етап. В противен случай целият процес може да продължи в грешна посока, което може да повлияе негативно на разходите за производство.
• V оформен модел: е вариант на модела на водопада. Той подчертава проверката и валидирането на продукта. Всички резултати са тестируеми, а напредъкът се проследява от етапи. Тестването се осъществява паралелно с фазата на разработка.
• Модел на прототип: Прототип е разработен във фазата на изискване и се оценява от крайните потребители. Въз основа на отзивите на потребителите, разработчиците променят прототипа, за да задоволят потребителските изисквания. Въпреки че този модел финализира изискванията лесно, използването му в производствената среда може да доведе до проблеми с качеството, като по този начин процесът на корекция продължава завинаги.
• Спирален модел: Използва както модели на водопад, така и прототипи. Към модела на водопада добавя програмни езици от 4-то поколение, бързо разработване на приложения и анализ на риска. Системните изисквания са проектирани и се създава предварителен дизайн на системата. Първоначален прототип е проектиран и тестван. Въз основа на оценката на резултатите от теста се създава втори прототип. Следващите прототипи са конструирани, за да гарантират удовлетвореността на клиентите. Системата е създадена на базата на крайния прототип. Крайната система се оценява и тества. Въпреки че този модел намалява риска до голяма степен, той може да не покрие бюджета и се прилага различно за всяко приложение.
• Итеративен и инкрементален SDLC модел: Посочва и реализира част от софтуера, която след това се преглежда и се добавят и прилагат допълнителни изисквания в групи. Всяко издание доставя оперативен продукт, който представя на клиентите първо важни функционалности, намалявайки първоначалните разходи за доставка. Рискът от промяна на изискванията е силно намален и клиентите имат право да реагират на всяка конструкция. Въпреки силните си страни, този модел изисква добро планиране и ранно дефиниране на цялостната и напълно функционална система. Той също така изисква добре дефинирани модулни интерфейси.
• Модел на гъвкаво развитие: Използва се за критични за времето приложения в организации, използващи дисциплинирани методи. Той ускорява фазите на жизнения цикъл и има намален обхват.
• Модел на магическа кутия: Модел за разработка на уеб приложения. Това е най-бързият начин да завършите проекта с най-малко грешки, тъй като предоставя възможност за промяна на кода и структурите на базата данни.