Въведение в модела на водопада
Произхождаща от строителната и производствената индустрия, тя е силно структурирана физическа среда, предназначена за проектиране и разработка. Моделът на водопад е известен още като модел на жизнения цикъл на разработката на софтуер. Това беше първият модел на процеса, въведен като модел на линейно-последователен жизнен цикъл. Моделът на водопад просто казва на феномена, че напълно трябва да завърши едната фаза, преди да започне новата фаза на развитие, така че да няма припокриване на фазите. В областта на разработката на софтуер, моделът на водопада първо е използван като SDLC подход. За да работим върху модела на водопада, трябва да разберем неговия подход за приложение, базиран както на вътрешни, така и на външни фактори, които могат да бъдат както следва:
- Няма нееднозначни изисквания в приложението.
- Стабилност на дефиницията на продукта
- Това е технологично разбрано
- Не е динамично
- Налични са големи ресурси с подходящ опит в подкрепа на продукта
- Проект с къса дължина Vey
- Добрият документ, ясни и фиксирани изисквания.
Като начало на историята на модела на водопада бих искал да кажа, че първата извадка от модела на водопада е представена през 1970 година от Winston w Royce в статия. Оттогава моделът на водопада заявява, че човек трябва да премине към друга фаза само когато предишните фази са напълно тествани, прегледани и проверени. Той акцентира върху логическата прогресия на фазовите стъпки. Функционалността му е подобна на водните потоци през ръба на скалата. Този подход за разработка на софтуер е получил името водопад, тъй като той се развива систематично от една фаза в друга по низходящ начин. От времето, когато е публикувано за първи път от Winston W. Royce през 1970 г., моделът на водопада е широко използван в областта на разработката на софтуер. В процеса на разработване на софтуерния цикъл се използват модели за програмиране за планиране на различните етапи на разработване на приложение. Един такъв модел е моделът на водопада.
Модели на фазите на водопада
Сега нека да поговорим за фазите на модела на водопада, които могат да бъдат обяснени ясно чрез тази демонстрационна инфографика.
С горната инфографика можем да разберем, че моделът на водопада има общо 7 фази на софтуерния цикъл за проектиране и разработка, които са както следва:
- Изисквания
- анализ
- Дизайн
- Кодиране / внедряване
- Тестване
- Работа / разгръщане
- Поддръжка
Така че можем да видим, че моделът на водопада работи йерархия отгоре надолу с една фаза, завършена с пълни проверки, след това преминаване към друга фаза, включително фазови процеси като Концепция, Иницииране, Анализ, Проектиране, Конструиране, Тестване, Производство / Реализация и Поддръжка. За да получим по-кратко знание за модела на водопада, трябва да разберем всички негови процеси в дълбочина с неговия работен модел. Има основна предпоставка фаза, която трябва да бъде разбрана, преди да започнете дълбоките фази на знанието. Става въпрос за проучване на възможностите за софтуерния продукт. Той се занимава с финансовите и техническите аспекти на изискванията на проекта. Тази фаза се занимава с коригирането на мерките въз основа на анализираните ползи и недостатъци. Така се избира най-доброто решение.
- Изисквания: Като конкретни думи, ние трябва да знаем и разбираме какво трябва да проектираме, какво трябва да разработим, процесите му, каква ще бъде неговата функционалност и т.н. Той осигурява входен материал към произвеждания продукт и по този начин предстоящия продукт се изучава, финализира и маркира. Той също така ни дава разширението да решаваме хардуерните или софтуерните изисквания на продукта, които ще бъдат проектирани, разработени и заснети във всички фази.
- Анализ: В резултат се проектира модели, схеми и бизнес правила. Това изискване се разделя не само на две части:
- Събиране и анализ на изискванията: Първо цялата информация и изискване за разработване на продукта се събира от клиента и след това се обработва за анализ. Основната роля на тази част е да премахне непълноти и несъответствия, свързани с разработването на софтуерни продукти.
- Спецификация на изискването: Тогава анализираните по-горе изисквания се документират в документ SRS (спецификация на софтуерното изискване). Той служи като път между клиента и екипа за разработка на SRS. Всички бъдещи спорове се управляват и уреждат само чрез тази документация за SRS.
- Дизайн: След като първата фаза е завършена и проверена, тя е следващата най-важна фаза, която се изучава, тъй като се използва за проектиране на системата. Той помага при уточняване на софтуерните и хардуерни изисквания за дизайна на продукта. Той също така помага в цялостната архитектура за дизайна на системата. Така че спецификацията на изискванията се изучава и проверява най-вече в тази фаза. Също така е полезно за трансформирането на SRS документа във функционален дизайн и разработка на софтуерния продукт. Така че можем да кажем, че във фазата на проектиране човек прави цялостната архитектура на проекта за разработка на софтуер.
- Изпълнение: При цялостно проверено проектиране на системата фазата на внедряване идва на ред. В тази фаза се вземат входните данни от проектирането на системата и тя първо се разработва в малки програми, известни като единици, което се тества и прилага в следващата фаза. Всеки модул във фазата на внедряване се подлага на разработка и се тества пълната му функционалност, която е известна също като тестване на единици. Така че в тази фаза, системният дизайн се преобразува в изходен код с напълно функционални модули на програми. Тя включва разработка, доказване и интегриране на софтуера.
- Интеграция и тестване: Всяка конструкция на устройството и разработена в по-ранните фази е включена от фазата на внедряване, която е интегрирана в модул или система за различни изпитвания като тест за натоварване, тест на олово и др. След тестване на всяка единица. Тестовата среда се подлага на постоянна проверка на софтуера, за да разбере дали има някакви потоци или грешки в дизайна или кода. Тестването се прави, за да се поддържа стабилността и осъществимостта на софтуера, така че клиентът да не се сблъсква с никакви смущения или грешки по време на неговото производство. Така че в тази фаза след внедряването цялата система се тества старателно за всякакви повреди и повреди. Тестването на системата се състои от три различни вида дейности, които могат да бъдат обяснени по-долу:
- Алфа (α) Тестване: Това е тестването, извършено от екипа за разработка.
- Бета (β) Тестване: Това е тестването, извършено от приятелския екип от клиенти и потребители.
- Тест за приемане: той се извършва както след алфа тестване, така и при бета тестване. По принцип това тестване се извършва след доставка от клиентите. След тестване, извършено от клиента, се взема решение дали този софтуер е приемлив или да го отхвърли. Така че в тази фаза се извършва отстраняване на грешки в бъгове.
- Разгръщане на системата / Операции: след извършване на нефункционалното, функционално, алфа и бета тестване продуктът на софтуера се разгръща в системата на потребителя или клиента или се пуска на пазара. Фазата на внедряване включва инсталация, миграция и поддръжка на цялата система към потребителя или клиентската среда.
- Поддръжка: Това е последната, но най-важната фаза в модела на работния процес на водопада. Тази стъпка идва веднага след инсталирането и включва извършване на съответната модификация на продукта или системата или за подобряване, промяна или промяна на атрибути, свързани с проблем с производителността, свързан със системата. основната му роля е да подобри производителността на системата с максимална точност на резултатите от софтуера. Тези промени, повдигнати по време на фазата на поддръжка, са свързани главно с промените, инициирани да бъдат направени от клиента или потребителите след фазата на инсталиране и тестване, която включва грешки като дефект, открит по време на живо използване на системата или заявка, повдигната от клиентите. Така на клиента се предоставя навременна и планова поддръжка и поддръжка на разработения продукт. Наистина ще бъдете изумени, когато знаете, че усилията, положени във фазата на проектиране и разработка на софтуерния продукт, са само 60% усилия в сравнение с усилията, положени във фазата на поддръжка. По принцип има три вида поддръжка, което е обяснено по-долу:
- Коригираща поддръжка: По време на фазата на проектиране и разработка някои грешки не се откриват, те се отчитат само когато потребителят използва. Това е само коригираща поддръжка, което означава коригиране на проблеми или грешки, които не са били открити във фазата на разработка.
- Перфектна поддръжка: Този тип поддръжка се извършва по заявка на клиента за повишаване и подобряване на функционалностите на системата или софтуера.
- Адаптивна поддръжка: поддръжката е необходима за превключване на системната среда. Обикновено се изисква за пренасяне на съществуващата система в нова среда или нов компютър или система или може би с нова операционна система. Тази фаза е твърде важна, тъй като това води до по-добра производителност на системата.
Така в горната дискусия се запознахме дълбоко с всяка фаза на водопадния модел с пълни спецификации. Така че можем да кажем, че моделът на водопад е много важен в софтуерната област също в сравнение с механичната промишленост, тъй като всяка фаза има своето значение, това води до генериране на по-продуктивен и стабилен софтуер.
Предимства
Не само този модел на водопад има и много повече предимства в жизнения цикъл на разработката на софтуер, които могат да бъдат разгледани по-долу:
- Той позволява департаментализация и контрол.
- Графикът може да бъде определен със срокове за всеки етап на разработка и продуктът може да продължи през етапите на модела на процеса на разработване един по един.
- Тъй като преминава лесно разбираеми и обясними фази, той преодолява много проблеми, така че е много лесен за използване.
- Поради твърдостта на модела на работния процес е много лесно да се управлява, тъй като всяка фаза в модела на водопада има специфични процеси за преглед и резултати.
- Моделът на водопад работи добре за по-малки проекти, където изискванията са много добре разбрани.
- Графикът може да бъде зададен с крайни срокове за всеки етап от разработката и продуктът може да продължи през етапите на модела на процеса на разработване един по един.
- Ясно определени етапи.
- Добре разбрани етапи.
- Лесни за подреждане на задачи.
- Процесът и резултатите са добре документирани.
- Подсилва добрите навици: определете преди проектиране,
- Дизайн-преди-код.
- Моделът работи добре за по-малки проекти и проекти, където изискванията са добре разбрани.
недостатък
Както знаем, че всяка монета има две лица, така че с големия достъп до предимствата на модела на водопада, моделът на водопад също има някои недостатъци или можете да кажете недостатъци, които са разгледани по-долу:
- Не е добър модел за сложни и обектно ориентирани проекти.
- Не е подходящ за проекти, при които изискванията са изложени на умерен до висок риск от промяна.
- Трудно е да се оцени времето и разходите за всяка фаза на процеса на разработване.
- Не е добър модел за сложни и обектно ориентирани проекти.
- Не се произвежда работещ софтуер до късно през жизнения цикъл.
- Не могат да се поберат променящите се изисквания.
- Трудно е да се измери напредъкът на етапи.
- Високи количества на риск и несигурност.
- Лош модел за дълги и текущи проекти.
- Настройката на обхвата по време на жизнения цикъл може да завърши проект.
- Няма път за обратна връзка
- Без припокриване на фази
- Трудно да се приемат заявки за промяна.
- риск и несигурност са високи при този модел на процеса.
Къде да използваме водопадния модел
След като обградим всички сценарии, стигаме до момент, в който искаме да знаем къде да използваме модела на водопада.
- Основният модел на водопад се използва в отбранителен проект, тъй като там изискването е ясно, защото преди да преминат към фаза на развитие, те го анализират добре.
- Това може да се използва и в проекти за миграция, където изискванията ще бъдат еднакви само платформата или езиците могат да се променят / променят.
заключение
Така че като цяло мога да кажа, че моделът на водопад е най-подходящ за малък проект за разработка на софтуер в сравнение с големи проекти, тъй като проектирането, разработката и изпълнението е по-лесно в малкия проект, когато се работи върху модел на водопад, тъй като в този модел всички предишни фази се нуждаят да бъде завършен при преминаване към предстоящи фази. Така че в големия проект проблемите и грешките идват често, тъй като той има голям модел, така че всеки път фазата на тестване ще бъде продължена, ако се прилага чрез модела на водопада, което ще доведе до по-малка оптимизация и точност на софтуера.
Препоръчителни статии
Това е ръководство за Модел на водопад. Тук сме обсъдили фазите, предимствата и недостатъците на модела на водопада. Можете да разгледате и другите ни предложени статии, за да научите повече -
- Какво е AWS?
- Какво е Bootstrap?
- Какво е кошер?
- Какво е Unix?
- Scrum срещу водопад | сравнение
