Вступ до моделі водоспаду

Походить із будівельної та обробної промисловості, воно має високоструктуроване фізичне середовище, призначене для процесів проектування та розробки. Модель водоспаду відома також як модель життєвого циклу розробки програмного забезпечення. Це була перша модель процесу, введена як лінійно-послідовна модель життєвого циклу. Модель водоспаду просто говорить про явище, як повністю завершити одну фазу перед початком нової фази розвитку, щоб не було перекриття фаз. У галузі розробки програмного забезпечення модель водоспаду вперше була використана як підхід SDLC. Щоб працювати над моделлю водоспаду, ми повинні розуміти його підхід до застосування, заснований як на внутрішніх, так і на зовнішніх факторах, які можуть бути наступними:

  • Ніяких неоднозначних вимог у заявці.
  • Стабільність визначення продукту
  • Це технологія зрозуміла
  • Це не динамічно
  • Для підтримки продукту доступні великі ресурси з відповідним досвідом
  • Проект короткої довжини Вей
  • Хороший документ, чіткі та фіксовані вимоги.

Для початку з історії моделі водоспаду, я хотів би сказати, що перший зразок моделі водоспаду був представлений у 1970 році Вінстоном у Ройсом у статті. Відтоді модель водоспаду стверджує, що слід переходити на іншу фазу лише тоді, коли попередні фази повністю перевіряються, переглядаються та перевіряються. Він підкреслює логічне просування фазових кроків. Його функціональність схожа на течію води через край обриву. Такий підхід розробки програмного забезпечення отримав назву водоспад, оскільки він систематично розвивається від однієї фази до іншої вниз. З часу, коли він був вперше опублікований Winston W. Royce в 1970 році, модель водоспаду широко застосовується в галузі розробки програмного забезпечення. У циклі процесу розробки програмного забезпечення використовуються моделі програмування для планування різних етапів розробки програми. Однією з таких моделей є модель водоспаду.

Фази моделі водоспаду

Тепер поговоримо про фази моделі водоспаду, які можна чітко пояснити за допомогою цієї демонстраційної інфографіки.

З вищенаведеної інфографіки ми можемо зрозуміти, що модель водоспаду має загалом 7 фаз циклу програмного забезпечення та розробки, які є наступними:

  1. Вимоги
  2. Аналіз
  3. Дизайн
  4. Кодування / реалізація
  5. Тестування
  6. Експлуатація / розгортання
  7. Технічне обслуговування

Таким чином, ми можемо бачити, що модель водоспаду працює ієрархією зверху вниз з однією фазою, завершеною повною верифікацією, а потім переходить на іншу фазу, включаючи фазові процеси, такі як Концепція, Ініціація, Аналіз, Проектування, Будівництво, Тестування, Виробництво / Реалізація та Технічне обслуговування. Для того, щоб отримати більш короткі знання про модель водоспаду, ми повинні глибоко розібратися з усіма його процесами з його робочою моделлю. Існує основна передумова фази, яку потрібно зрозуміти перед початком глибоких фаз пізнання. Йдеться про техніко-економічне обґрунтування програмного продукту. Він стосується фінансових та технічних аспектів вимог проекту. Цей етап стосується виправлення заходів на основі проаналізованих переваг та недоліків. Таким чином, вибирається найкраще рішення.

  1. Вимоги: Як конкретні слова, ми повинні знати і розуміти, що ми повинні розробити, що ми маємо розробити, які процеси, які будуть його функціональні можливості тощо. Це забезпечує вхідний матеріал для виготовленого продукту, а отже, і майбутнього продукту вивчається, допрацьовується та маркується. Це також дає нам розширення для вирішення вимог до апаратного або програмного забезпечення продукту, які будуть розроблені, розроблені та захоплені на всіх етапах.
  2. Аналіз: Результатом є розробка моделей, схем та правил бізнесу. Не тільки ця вимога ділиться на дві частини:
  • Збір вимог та аналіз: Спочатку вся інформація та вимоги до розробки товару збирається у замовника, а потім обробляється для аналізу. Основна роль цієї частини полягає у усуненні неповноти та невідповідностей, пов’язаних із розробкою програмних продуктів.
  • Специфікація вимог: Потім вище проаналізовані вимоги документуються в документі SRS (специфікація вимог до програмного забезпечення). Він слугує як шлях між замовником та командою розвитку SRS. Будь-які суперечки в майбутньому вирішуються та вирішуються лише за допомогою цієї документації щодо СРС.
  1. Дизайн: Після завершення та перевірки першого етапу це наступний найважливіший етап, який слід вивчити, оскільки він використовується для проектування системи. Це допомагає визначити вимоги до програмного та апаратного забезпечення для дизайну продукту. Це також допомагає в загальній архітектурі для дизайну системи. Отже специфікація вимог здебільшого вивчається та перевіряється на цій фазі. Це також корисно для перетворення документа SRS у функціональне проектування та розробку програмного продукту. Таким чином, ми можемо сказати, що на етапі проектування можна створити загальну архітектуру для проекту розробки програмного забезпечення.
  2. Впровадження: Після повністю перевіреного проектування системи, послідовно настає етап впровадження. На цій фазі беруться вхідні дані від проектування системи, і вона спочатку розробляється в невеликих програмах, відомих як одиниці, що тестується та впроваджується на наступній фазі. Кожен підрозділ на етапі впровадження проходить розробку, і його повну функціональність перевіряють, яка також відома як одиничне тестування. Тож на цій фазі дизайн системи перетворюється у вихідний код із повністю функціональними модулями програми. Він включає розробку, доведення та інтеграцію програмного забезпечення.
  3. Інтеграція та тестування: Кожна конструкція блоку та розроблена на попередніх етапах включена з етапу впровадження, який інтегрується в модуль або систему для різних випробувань, таких як випробування навантаженням, випробування свинцю тощо після тестування кожного блоку. Тестове середовище постійно проходить перевірку програмного забезпечення, щоб з’ясувати, чи є в дизайні чи коді якісь потоки чи помилки. Тестування проводиться для підтримки стабільності та доцільності програмного забезпечення, щоб клієнт не стикався з будь-якими порушеннями або помилками під час його виробництва. Тож на цій фазі після впровадження вся система ретельно перевіряється на наявність будь-яких несправностей та збоїв. Тестування системи складається з трьох різних видів діяльності, які можна пояснити нижче:
  • Альфа (α) Тестування: це тестування, проведене командою розробників.
  • Бета (β) тестування: це тестування, проведене дружньою командою клієнтів та користувачів.
  • Тестування прийняття: це робиться як після альфа-тестування, так і бета-тестування. В основному, це тестування проводиться після доставки клієнтами. Після тестування, проведеного замовником, приймається рішення про прийнятність цього програмного забезпечення або про його відхилення. Тож у цій фазі в основному робиться налагодження помилок.
  1. Розгортання системи / Операції: після того, як нефункціональне, функціональне, альфа- та бета-тестування виконано, продукт програмного забезпечення розгортається до користувача або клієнтської системи або випускається на ринок. Етап розгортання включає встановлення, міграцію та підтримку всієї системи в середовищі користувача або споживача.
  2. Технічне обслуговування: Це остання, але найважливіша фаза моделі робочого процесу водоспаду. Цей крок відбувається одразу після встановлення, і він включає внесення відповідних змін до продукту чи системи або для вдосконалення, зміни або модифікації атрибутів, пов’язаних з проблемою продуктивності, пов’язаною з системою. його головна роль полягає в підвищенні продуктивності системи з максимальною точністю результату програмного забезпечення. Ці зміни, підняті під час фази технічного обслуговування, в основному пов'язані зі змінами, ініційованими замовником або користувачами після встановлення та тестування, що включає помилки, такі як дефекти, виявлені під час використання системної системи або запит, піднятий клієнтами. Таким чином, клієнту надається своєчасне та планове обслуговування та підтримка розробленого продукту. Ви дійсно здивовані, дізнавшись, що зусилля, докладені на етапі розробки та розробки програмного продукту, становлять лише 60% зусиль порівняно із зусиллями, докладеними на етапі обслуговування. В основному є три види технічного обслуговування, що пояснено нижче:
  • Виправне обслуговування: На етапі проектування та розробки деякі помилки не виявляються, вони враховуються лише тоді, коли користувач користується. Це лише корекційне обслуговування, яке означає виправлення проблем або помилок, які не були виявлені на стадії розробки.
  • Ідеальне обслуговування: Цей тип технічного обслуговування проводиться за бажанням клієнта для підвищення та покращення функціональних можливостей системи чи програмного забезпечення.
  • Адаптивне обслуговування: саме технічне обслуговування потрібно для перемикання системного середовища. Зазвичай необхідний для перенесення існуючої системи до нового середовища або нового комп'ютера або системи або, можливо, з новою операційною системою. Ця фаза є надто важливою, оскільки це призводить до кращої роботи системи.

Отже, у вищенаведеному обговоренні ми глибоко познайомилися з кожною фазою моделі водоспаду з повними характеристиками. Тож можна сказати, що модель водоспаду дуже важлива в галузі програмного забезпечення також порівняно з механічною промисловістю, оскільки кожна фаза має своє значення, це призводить до створення більш продуктивного та стабільного програмного забезпечення.

Переваги

Мало того, що ця модель водоспаду має ще багато переваг у життєвому циклі розробки програмного забезпечення, про які можна говорити нижче:

  • Це дозволяє здійснювати департаменталізацію та контроль.
  • Графік може бути встановлений з термінами для кожного етапу розробки, і продукт може проходити по етапах моделі розробки по черзі.
  • Оскільки він проходить легко зрозумілі та пояснювані фази, він долає багато питань, тому дуже простий у використанні.
  • Через жорсткість моделі робочого процесу керувати дуже легко, оскільки кожна фаза в моделі водоспаду має конкретні процеси огляду та результатів.
  • Модель водоспаду добре працює для менших проектів, де вимоги дуже добре вивчені.
  • Графік може бути встановлений з термінами для кожного етапу розробки, і продукт може проходити через фази моделі розробки по черзі.
  • Чітко визначені етапи.
  • Добре зрозумілі віхи.
  • Легко організувати завдання.
  • Процес та результати добре зафіксовані.
  • Підсилює хороші звички: визначтесь перед розробкою,
  • Дизайн перед кодом.
  • Ця модель добре працює для менших проектів та проектів, де вимоги добре зрозумілі.

Недоліки

Як ми знаємо, що кожна монета має дві грані, тому, маючи великий доступ до переваг моделі водоспаду, модель водоспаду також має деякі недоліки, або, можна сказати, недоліки, про які йдеться нижче:

  • Недобра модель для складних та об'єктно-орієнтованих проектів.
  • Не підходить для проектів, де вимоги мають помірний та високий ризик зміни.
  • Важко оцінити час та витрати на кожну фазу процесу розробки.
  • Недобра модель для складних та об'єктно-орієнтованих проектів.
  • Жодне робоче програмне забезпечення не виробляється до пізнього періоду життєвого циклу.
  • Неможливо прийняти зміни, що змінюються.
  • Важко виміряти прогрес по етапах.
  • Висока кількість ризику та невизначеності.
  • Погана модель для тривалих і поточних проектів.
  • Регулювання обсягу протягом життєвого циклу може закінчити проект.
  • Немає шляху зворотного зв’язку
  • Відсутність перекриття фаз
  • Важко вмістити запити на зміни.
  • ризик та невизначеність високі при цій моделі процесу.

Де використовувати модель водоспаду

Тепер, оббивши всі сценарії, ми приходимо до того, що хочемо знати, де використовувати модель водоспаду.

  • В основному модель водоспаду використовується в оборонному проекті, оскільки там вимога зрозуміла, оскільки перед переходом до фази розвитку вони добре аналізують її.
  • Це також можна використовувати в міграційних проектах, де вимоги будуть однаковими, лише платформа або мови можуть змінюватися / змінюватися.

Висновок

В цілому я можу сказати, що модель водоспаду найкраще підходить для невеликих проектів розробки програмного забезпечення порівняно з великими проектами, оскільки проектування, розробка та реалізація легше в малому проекті при роботі над водоспадною моделлю, оскільки в цій моделі потрібні всі попередні етапи. має бути завершено під час переходу до наступних етапів. Тож у великому проекті проблеми та помилки трапляються часто, оскільки у нього є велика модель, тому кожен раз фаза тестування буде продовжена, якщо впроваджуватися через модель водоспаду, що призведе до меншої оптимізації та точності програмного забезпечення.

Рекомендовані статті

Це було керівництвом для моделі водоспадів. Тут ми обговорили фази, переваги та недоліки моделі водоспаду. Ви також можете ознайомитися з іншими запропонованими нами статтями, щоб дізнатися більше -

  1. Що таке AWS?
  2. Що таке Bootstrap?
  3. Що таке вулик?
  4. Що таке Unix?
  5. Scrum vs водоспад | Порівняння

Категорія:

Розробка програмного забезпечення