Життєвий цикл програмного забезпечення
2 План лекції 1. Поняття життєвого циклу програмного забезпечення 2. Вибір життєвого циклу розробки програмного забезпечення 3. Моделі процесу розробки програмних засобів
3 1. Поняття життєвого циклу програмного забезпечення. ISO/IEC 12207: 1995 "Information Technology - Software Life Cycle Processes « ГОСТ ЄСПД (ГОСТ 19. ХХХ) ГОСТ 34. 601 -90, ГОСТ 34. 602 -89, ГОСТ 34. 603 -92 ГОСТ Р ИСО/МЭК 12207 -99 (переклад ISO 12207) ДСТУ ISO/IEC 15288: 2005. Інформаційні технології. Процеси життєвого циклу системи (ISO/IEC 15288: 2002, IDT) ДСТУ ISO/IEC TR 15504 -3: 2002 Оцінювання процесів життєвого циклу програмних засобів
4 Загальна модель ЖЦ складної системи: • визначення потреби; • дослідження та опис основних концепцій; • проектування та розробка; • випробування системи; • створення та виробництво; • розповсюдження та продаж; • експлуатація; • супроводження та моніторинг; • припинення експлуатації.
5 Моделі ЖЦ ПЗ: • каскадна (водоспадна, послідовна); • V-подібна; • ітераційна; • спіральна.
6 Каскадна модель життєвого циклу Системний аналіз та розробка концепції програмної системи Розробка вимог до проекту ПС Планування і проектування ПС Розробка програмних компонентів Верифікація та тестування програмних компонентів Інтеграція, кваліфікаційне тестування та випробування ПС Супроводження та управління конфігурацією ПС Документування ПС
7 V-подібна модель життєвого циклу Виробництво, експлуатація та супровід Планування проекту та вимог Аналіз вимог продукту і специфікацій Системне та прийомне тестування Розробка архітектурного проекту Інтеграція та тестування Деталізовано розробка проектів Модульне тестування Кодування
8 Ітераційна модель життєвого циклу Системний аналіз та розробка концепції програмної системи Розробка вимог до проекту ПС Планування і проектування ПС Розробка програмних компонентів Верифікація та тестування програмних компонентів Інтеграція, кваліфікаційне тестування та випробування ПС Супроводження та управління конфігурацією ПС Документування ПС
9 Спіральна модель життєвого циклу
10 Типовий приклад визначення рівня затрат та чисельності персоналу протягом ЖЦ проекту Початкова фаза Проміжна фаза (фази) Затрати, персонал Час Кінцева фаза
11 2. Вибір життєвого циклу розробки програмного забезпечення Процедура вибору ЖЦ: 1. Проаналізувати характеристики проекту. 2. Дати відповіді на запитання. 3. Розмістити по пріоритетності категорії або запитання
12 Вибір моделі ЖЦ на основі характеристик вимог Вимоги Каскадна VСпіральна Ітераційна подібна Чи відомі вимоги? Так Ні Ні Чи можна визначити вимоги в циклі наперед? Чи часто будуть змінюватись вимоги в циклі? Чи будуть вимоги відображати складність системи? Чи має вимога функціональні властивості на ранньому етапі? Так Ні Ні Ні Так Так
13 Вибір моделі ЖЦ на основі характеристик типу проекту та ризиків Тип проекту та ризики Каскадна VСпіральна Ітераційна подібна Чи є проект новим напрямом для організації? Ні Чи буде проект мати тип системної інтеграції? Ні Чи буде проект розширенням існуючої системи? Ні Так Так Так Ні Так Чи буде стабільним фінансування на всьому ЖЦ? Так Ні Ні Чи «прозорі» інтерфейсні модулі? Чи можливе повторне використання компоненти? Так Ні Ні Так Ні Чи достатньо ресурсу (час, гроші, інструменти, персонал)? Ні Ні Так Ні
14 3. Моделі процесу розробки програмних засобів SW-CMM, Capability Maturity Measure RUP, Rational Unified Process Як вийде Agile, XP, Crystal, Scrum, ASD, FDD … MSF SEI PSP/ TSP ISO, ГОСТ, ДСТУ
15 Capability Maturity Model for Software, SW-CMM П'ять рівнів зрілості процесу розробки ПО. Початковий — процес розробки носить хаотичний характер. Повторюваний — встановлено основні процеси управління проектами: відстежування витрат, термінів і функціональності. Визначений — процеси розробки ПО і управління проектами описані і впроваджені в єдину систему процесів компанії. У всіх проектах використовується стандартний для організації процес розробки і підтримки ПЗ, адаптований під конкретний проект. Керований — збираються детальні кількісні дані по функціонуванню процесів розробки і якості кінцевого продукту. Аналізуються значення і динаміка цих даних. Постійно оптимізується — постійне покращення процесів, ґрунтується на кількісних даних процесів і на пробному впровадженні нових ідей і технологій.
16 Rational Unified Process, RUP Розроблений Філіппом Крачтеном (Philippe Kruchten), Іваром Якобсоном (Ivar Jacobson) та іншими співробітниками компанії "Rational Software" як доповнення до мови моделювання UML. Модель RUP описує абстрактий процес, на основі якого організація або проектна команда повинні створити конкретний спеціалізований процес, орієнтований на її потреби. Саме ця риса RUP викликає основну критику — оскільки він може бути чим завгодно. В результаті такої будови RUP можна використовувати і як основу для каскадної моделі, так і як гнучкий процес.
17 Microsoft Solutions Framework, MSF Microsoft Solutions Framework (MSF) — це гнучка і досить легка модель, побудована на основі ітеративної розробки. Особливістю MSF є увага до створення ефективної і небюрократизованої проектної команди. Для досягнення цієї мети MSF пропонує досить нестандартні підходи до організаційної структури, розподілу відповідальності і принципів взаємодії всередині команди.
18 Personal Software Process / Team Software Process, PSP / TSP Personal Software Process визначає вимоги до компетенції розробника. Згідно цієї моделі кожен програміст повинен уміти: • враховувати час, витрачений на роботу над проектом; • враховувати знайдені дефекти; • класифікувати типи дефектів; • оцінювати розмір задачі; • здійснювати систематичний підхід до опису результатів тестування; • планувати програмні задачі; • розподіляти їх за часом і складати графік роботи; • виконувати індивідуальну перевірку проекту і архітектури; • здійснювати індивідуальну перевірку коду; • виконувати регресійне тестування.
19 Personal Software Process / Team Software Process, PSP / TSP Team Software Process описує на самокеровані команди чисельністю 3 -20 розробників. Команди повинні: • встановити власні цілі; • скласти свій процес і плани; • відстежувати роботу; • підтримувати мотивацію і максимальну продуктивність.
20 Agile Основна ідея всіх гнучких моделей полягає в тому, що процес розробки ПО повинен бути адаптивним. Орієнтований на людей та їх взаємодію, а не на процеси і ресурси. По суті, так звані, гнучкі методології це не методології, а набір практик, які можуть дозволити добиватися ефективної розробки ПО, ґрунтуючись на ітеративності, самокерованості команди і адаптивності процесу. Agile Manifesto розроблений та прийнятий 11 -13 лютого 2001 року. Маніфест підписали представники наступних методологій Extreme programming, Scrum, DSDM, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming.
Скачать презентацию Життєвий цикл програмного забезпечення 2 План лекції
L2.ppt