Життєвий цикл програмного забезпечення (Software Lifecycle)
Це період часу, що починається з моменту появи концепції програмного забезпечення і закінчується тоді, коли подальше використання програмного забезпечення неможливе.
Життєвий цикл програмного забезпечення зазвичай охоплює такі етапи як: концепт, опис вимог, дизайн, реалізація, тестування, інсталяція та налагодження, експлуатація та підтримка, а також іноді етап виведення з експлуатації. Ці фази можуть накладатись одна на одну, або проводитись ітераційно.
Життєвий цикл розробки програмного забезпечення (SDLC – Software Development Lifecycle)
Це систематизований процес, етапи котрого охоплюють повний життєвий цикл програмного забезпечення (Software Lifecycle). SDLC визначає етапи розробки програмного забезпечення, де розробка продукту має бути завершена у заздалегідь визначені терміни та вартість. Кожна фаза SDLC має свій власний процес і результати, які можуть використовуватись в наступній фазі.
Фази SDLC
Зазвичай SDLC ділиться на шість-вісім фаз, але менеджери проектів можуть об’єднувати, декомпозувати або пропускати деякі кроки, в залежності від специфіки проекту та встановлених процесів. Також у різних джерелах фази можуть трохи відрізнятись, але загалом суть скрізь однакова:
Далі буде окремо розглянуто кожну з фаз SDLC.
1. Збір та аналіз вимог (Requirement gathering and analysis)
Це перший фундаментальний етап SDLC. На цьому етапі збирають усю необхідну інформацію від клієнта, для розробки продукту відповідно до його очікувань. Будь-які непорозуміння мають бути вирішені одразу, на цьому етапі. Створення плану проекту, визначення обсягу робіт, постановка цілей і виявлення ризиків, також є важливими кроками збору вимог.
Після збору вимог, проводиться їх аналіз для перевірки можливості розробки продукту. В результаті чіткого розуміння вимог створюється документ SRS (Специфікація вимог до програмного забезпечення). Цей документ має бути повністю зрозумілий команді розробки, а також розглянутий замовником для використання в майбутньому.
2. Проектування (Design)
На цьому етапі, вимоги сформовані в документі SRS використовуються як вхідні дані, для проектування архітектури програмного забезпечення, яка буде використовуватись для розробки.
На цьому етапі можуть створюватись такі види дизайн-документів як: високорівневий дизайн (HLD – High-Level Design) та низькорівневий дизайн (LLD – Low-Level Design).
3. Розробка (Implementation or Coding)
Починається після отримання розробниками Design documents. Дизайн програмного забезпечення переводиться у вихідний код. На цьому етапі реалізуються всі компоненти програмного забезпечення.
4. Тестування (Testing)
Після етапу кодування розроблене програмне забезпечення ретельно тестується, і всі виявлені дефекти передаються розробникам для виправлення. Мета цього етапу, переконатися що програмний продукт функціонує належним чином і відповідає необхідним специфікаціям.
5. Розгортання (Deployment)
Після тестування програмного забезпечення його розгортають у продуктовому середовищі, або відбувається перше User Acceptance Testing (UAT, приймальне тестування), в залежності від очікувань клієнта. В разі UAT створюється копія наближена до продуктового середовища, і замовник разом з зацікавленими особами виконують приймальне тестування. Якщо клієнт залишається задоволеним, він надає згоду на реліз версії продукту.
6. Підтримка (Maintenance)
Основна увага на цьому етапі SDLC приділяється забезпеченню роботи системи відповідно до специфікацій, а також вирішенню потреб клієнтів. Після розгортання системи та початку її експлуатації, можуть слідувати такі види активностей як виправлення помилок, оновлення, покращення, тощо.
Моделі SDLC
Моделі представляють SDLC в організованому вигляді. Різні моделі, розташовують фази SDLC у різному хронологічному порядку, для оптимізації циклу розробки.
Серед поширених моделей SDLC можна виділити:
- Waterfall model (Водоспадна або каскадна модель)
- Iterative model (Ітеративна модель)
- Spiral model (Спіральна модель)
- V-model (V-образна модель)
- Agile model (Гнучка модель)
- Prototype model (Модель прототипу)
Моделі формуються для досягнення певного результату. Наприклад, модель Waterfall найкраще підходить для проектів з чітко визначеними вимогами та обсягом робіт. З іншого боку, Agile модель підходить для проектів, що потребують гнучкості та адаптивності до мінливих вимог. Загалом, кожна модель має свій власний набір переваг і недоліків, та потребує розгляду в окремому записі.