Skip to content

Latest commit

 

History

History
335 lines (207 loc) · 13.2 KB

slides.md

File metadata and controls

335 lines (207 loc) · 13.2 KB
layout
section

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

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

 

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

Стандарти:

  • ISO/IEC 12207: 1995 «Information Technology – Software Life Cycle Processing» ( Державний стандарт України ДСТУ 3918-99 «Інформаційні технології. Процеси життєвого циклу програмного забезпечення».
  • IEEE 1540: Standard for Software Risk Management – управління ризиками програмного забезпечення;
  • IEEE 1517: Standard for Software Reuse Processes – процеси повторного використання програмного забезпечення;
  • ISO/IEC 15939: Standard for Software Measurement Process – процеси вимірювання в області програмного забезпечення.

Моделі життєвого циклу ПЗ

 

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

Програмне забезпечення в процесі своєї розробки й експлуатації проходить ряд певних етапів:

  • виникнення та дослідження ідеї
  • аналіз вимог i проектування
  • безпосередньо кодування
  • тестування та налагодження
  • введення програми в дію
  • експлуатація та супровід
  • виведення з експлуатації

Найбільш вживані моделі:

 

  • Waterfall
  • Incremental
  • Rational Unified Process model
  • Agile

Waterfall

 

graph LR

A[Requirements] --> D[Design]
D --> Dev[Development]
Dev --> I[Integration]
I --> T[Testing]
T --> Dep[Deployment]
Dep --> S[Support]
Loading

layout: two-cols

Переваги

  • Ніяких переробок
  • Гарна специфікація перетікає в гарну документацію
  • Зрозуміла модель
  • Code Monkeys

::right::

Недоліки

  • Важко вносити зміни (якщо взагалі можливо)
  • Надлишкове проектування
  • Perfect vs Code Monkeys

J.Martin An Information Systems Manifesto -1984

Процес автоматизації завдання змінює уявлення користувача про це завдання, тобто користувач вирішує завдання з використанням засобів автоматизації інакше, ніж без них (користувача треба використовувати постійно в процесі проектування, а не тільки на початку)

Чим більше часу пройшло з моменту здійснення помилки до моменту її виявлення, тим більше коштів необхідно для її усунення

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

V-model

layout: two-cols

::right::

Вальсируя с медведями …

Найбільш розповсюджені та найнебезпечніші ризики:

  • внутрішні складнощі календарного планування;
  • збільшення вимог з боку замовника в ході реалізації проекту;
  • текучка кадрів;
  • порушення специфікацій;
  • низька продуктивність.

Incremental model

Iterative model

Rational Unified Process

layout: two-cols

::right::

Початкова фаза

<style> p, ul li { font-size:small; line-height:1; padding:0 } </style>

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

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

Після їх завершення проєкт перевіряється на відповідність наступним критеріям:

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

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

layout: two-cols

::right::

Фаза уточнення

<style> p, ul li { font-size:small; line-height:1; padding:0 } </style>

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

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

Ця фаза має пройти віху життєвого циклу архітектури (LCA), задовольняючи такі критерії:

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

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

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

layout: two-cols

::right::

Фаза конструювання

Основна мета полягає в створенні програмної системи.

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

Цей етап створює перший реліз програмного забезпечення. Його завершення позначає віха початкової боєготовності.

layout: two-cols

::right::

Фаза впровадження

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

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

Продукт також перевіряється на відповідність рівню якості, встановленого в початковій фазі.

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

Agile

layout: two-cols

::right::

Agile

<style> p, ul li { font-size:small; line-height:1; padding:5px 0; } </style>
  • Максимальне задоволення вимог клієнта (у разі необхідності - продовження терміну здачі проекту)
  • Продукт часто показується клієнту (до прикладу кожен тиждень, а не кожен місяць)
  • Працююче програмне забезпечення є визначником прогресу проекту
  • Навіть пізні зміни у вимогах до продукту сприймаються позитивно
  • Тісна щоденна кооперація клієнтів, програмістів, аналітиків проекту
  • Постійна комунікація групи учасників проекту
  • Проект будується навколо вмотивованих індивідів, до яких повинна бути довіра
  • Постійна увага до технічної сторони і хорошого дизайну продукту
  • Простота
  • Самоорганізованість
  • Постійна адаптація до зміни середовища.