Меню

Етапи, методології, процеси та моделі SDLC (життєвий цикл розробки програмного забезпечення)

  • Головна
  • Інший
  • Етапи, методології, процеси та моделі SDLC (життєвий цикл розробки програмного забезпечення)

sdlc phases

Спробуйте Наш Інструмент Для Усунення Проблем

Що таке життєвий цикл розробки програмного забезпечення (SDLC)? Вивчіть етапи SDLC, методології, процеси та моделі

Життєвий цикл розробки програмного забезпечення (SDLC) - це структура, яка визначає кроки, що беруть участь у розробці програмного забезпечення на кожному етапі. Він охоплює детальний план побудови, розгортання та обслуговування програмного забезпечення.

SDLC визначає повний цикл розробки, тобто всі завдання, пов'язані з плануванням, створенням, тестуванням та розгортанням програмного продукту.

Життєвий цикл розробки програмного забезпечення SDLC

Що ви дізнаєтесь:

Процес життєвого циклу розробки програмного забезпечення

SDLC - це процес, який визначає різні етапи розробки програмного забезпечення для постачання високоякісного продукту. Стадії SDLC охоплюють повний життєвий цикл програмного забезпечення, тобто від створення до виходу з експлуатації продукту.

Дотримання процесу SDLC веде до системного та дисциплінованого розвитку програмного забезпечення.

Призначення:

Метою SDLC є постачання високоякісного продукту, який відповідає вимогам замовника.

SDLC визначила свої етапи: збір вимог, проектування, кодування, тестування та обслуговування. Важливо дотримуватися етапів систематичного надання Продукту.

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

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

Цикл SDLC

Цикл SDLC представляє процес розробки програмного забезпечення.

Нижче наведено схематичне зображення циклу SDLC:

Цикл 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-моделі.

V-образна модель

а) Етап верифікації:

(i) Аналіз вимог:

На цьому етапі збирається та аналізується вся необхідна інформація. Діяльність з перевірки включає перегляд вимог.

(ii) Дизайн системи:

Після того, як вимога чітка, система розробляється, тобто архітектура, компоненти продукту створюються та документуються в проектному документі.

(iii) Дизайн високого рівня:

Високорівневий дизайн визначає архітектуру / дизайн модулів. Він визначає функціональність між двома модулями.

(iv) Дизайн низького рівня:

Дизайн низького рівня визначає архітектуру / дизайн окремих компонентів.

(v) Кодування:

На цьому етапі розробляється код.

b) Фаза перевірки:

(i) Одиничне тестування:

Блокове тестування виконується з використанням модульних тестових кейсів, які розроблені та виконуються на етапі проектування низького рівня. Модульне тестування виконується розробником самостійно. Він виконується на окремих компонентах, що призводить до раннього виявлення дефектів.

(ii) Інтеграційне тестування:

Інтеграційне тестування виконується за допомогою інтеграційних тестових кейсів у фазі проектування високого рівня. Інтеграційне тестування - це тестування, яке проводиться на інтегрованих модулях. Його виконують тестери.

(iii) Тестування системи:

Тестування системи виконується на етапі проектування системи. На цьому етапі перевіряється повна система, тобто перевіряється вся функціональність системи.

(iv) Випробування на приймання:

Приймальні випробування пов'язані з етапом аналізу вимог і проводяться в середовищі замовника.

Переваги V - моделі:

  • Це проста і зрозуміла модель.
  • Підхід V-model підходить для невеликих проектів, де вимога визначена, і вона застигає на ранній стадії.
  • Це систематизована та дисциплінована модель, яка дає високоякісний продукт.

Недоліки V-моделі:

  • V-подібна модель не підходить для поточних проектів.
  • Зміна вимог на пізнішому етапі буде коштувати занадто дорого.

# 3) Модель прототипу

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

Прототипи моделей мають обмежені функціональні можливості та неефективну продуктивність у порівнянні з фактичним програмним забезпеченням. Фіктивні функції використовуються для створення прототипів. Це цінний механізм розуміння потреб споживачів.

Прототипи програм створюються до фактичного програмного забезпечення для отримання цінних відгуків від замовника. Зворотній зв'язок впроваджено, і прототип знову переглядається замовником на будь-які зміни. Цей процес триває до тих пір, поки модель не буде прийнята замовником.

Модель прототипу

Після завершення збору вимог створюється швидкий дизайн і будується прототип, який представляється замовнику для оцінки.

Відгуки клієнтів та уточнені вимоги використовуються для модифікації прототипу і знову представляються замовнику для оцінки. Як тільки замовник схвалює прототип, він використовується як вимога для побудови власне програмного забезпечення. Фактичне програмне забезпечення будується з використанням підходу Waterfall model.

Переваги моделі-прототипу:

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

Недоліки моделі-прототипу:

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

# 4) Спіральна модель

Спіральна модель включає ітераційний та прототипний підхід.

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

Спіральна модель має чотири фази:

  • Планування
  • Аналіз ризиків
  • Техніка
  • Оцінка

Спіральна модель

(i) Планування:

Етап планування включає збір вимог, де вся необхідна інформація збирається від замовника та документується. Документ специфікації вимог до програмного забезпечення створюється для наступного етапу.

(ii) Аналіз ризику:

На цьому етапі вибирається найкраще рішення для ризиків, і аналіз проводиться шляхом створення прототипу.

Наприклад , ризик доступу до даних із віддаленої бази даних може полягати в тому, що швидкість доступу до даних може бути занадто повільною. Ризик можна вирішити шляхом створення прототипу підсистеми доступу до даних.

(iii) Техніка:

Після аналізу ризику виконується кодування та тестування.

(iv) Оцінка:

Клієнт оцінює розроблену систему та планує наступну ітерацію.

Переваги спіральної моделі:

  • Аналіз ризиків широко проводиться з використанням прототипів моделей.
  • Будь-яке вдосконалення або зміна функціональних можливостей може бути здійснено на наступній ітерації.

Недоліки спіральної моделі:

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

# 5) Ітеративна інкрементальна модель

Ітераційна інкрементальна модель ділить продукт на невеликі шматки.

Наприклад , Визначено та реалізовано функцію, яка буде розроблена в ітерації. Кожна ітерація проходить етапи, а саме: аналіз вимог, проектування, кодування та тестування. Детального планування не потрібно в ітераціях.

Після завершення ітерації продукт перевіряється та доставляється замовнику для оцінки та зворотного зв'язку. Відгуки клієнтів реалізуються в наступній ітерації разом із нещодавно доданою функцією.

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

Фази ітеративної та додаткової моделі розвитку:

  • Початкова фаза
  • Етап розробки
  • Етап будівництва
  • Фаза переходу

(i) Початкова фаза:

Початковий етап включає вимоги та обсяг Проекту.

(ii) Етап розробки:

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

(iii) Етап будівництва:

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

(iv) Фаза переходу:

На фазі переходу продукт розгортається у виробничому середовищі.

Переваги ітеративної та додаткової моделі:

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

Недоліки ітеративної та додаткової моделі:

  • Повні вимоги та розуміння продукту потрібні, щоб поступово руйнувати та будувати.

# 6) Модель Великого вибуху

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

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

Переваги моделі Великого вибуху:

  • Це дуже проста модель.
  • Потрібно менше планування та планування.
  • Розробник має гнучкість для створення власного програмного забезпечення.

Недоліки моделі Великого вибуху:

  • Моделі Big Bang не можна використовувати для великих, постійних та складних проектів.
  • Високий ризик та невизначеність.

# 7) Спритна модель

Agile Model - це поєднання ітеративної та інкрементальної моделей. Ця модель більше фокусується на гнучкості при розробці продукту, а не на вимозі.

В Agile продукт розбивається на невеликі поступові нарощування. Він не розробляється як цілісний продукт за один раз. Кожна збірка збільшується з точки зору функцій. Наступна збірка побудована на попередній функціональності.

У спритних ітераціях називаються спринти. Кожен спринт триває 2-4 тижні. В кінці кожного спринту власник товару перевіряє товар і після його схвалення він доставляється замовнику.

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

Спритна модель

Переваги Agile Model:

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

Недоліки:

  • Відсутність документації.
  • Agile потребує досвідчених та висококваліфікованих ресурсів.
  • Якщо замовнику не ясно, як саме він хоче, щоб товар був, тоді проект зазнає невдачі.

Висновок

Дотримання відповідного життєвого циклу дуже важливо для успішного завершення Проекту. Це, в свою чергу, полегшує управління.

Різні моделі життєвого циклу розробки програмного забезпечення мають свої плюси і мінуси. Найкраща модель для будь-якого проекту може бути визначена такими факторами, як Вимога (ясна чи незрозуміла), Складність системи, Розмір проекту, Вартість, Обмеження навичок тощо.

Приклад, у разі незрозумілої вимоги найкраще використовувати спіральні та гнучкі моделі, оскільки необхідну зміну можна легко застосувати на будь-якому етапі.

Модель водоспаду є базовою моделлю, і всі інші моделі SDLC базуються лише на ній.

Сподіваюся, ви отримали б величезні знання SDLC.

Рекомендована література

^