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

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

НАЦІОНАЛЬНИЙ ЛІСОТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ

Кафедра ОТ і МПТ

РЕФЕРАТ

на тему

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

Виконав:

Студент групи КН-41/2

Повшука О.В.

Прийняв:

ст. викладач ОТіМПТ

Пірко І. Б.

Львів – 2013

ЗМІСТ

1. Процеси життєвого циклу ПО 3

2. Стадії життєвого циклу ПЗ, взаємозв'язок між процесами і стадіями 4

3. Моделі життєвого циклу ПО 5

3.1. Водопадна (каскадна, послідовна) модель 5

3.2. Ітераційна модель 6

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

4. Методології розробки ПЗ 9

5. Адаптація стандарту до конкретного проекту 9

Література 13

1. Процеси життєвого циклу ПО

• Основні:
• Придбання (дії і завдання замовника, що здобуває ПО)
• Поставка (дії і завдання постачальника, який постачає замовника програмним продуктом або послугою)
• Розробка (дії і завдання, що виконуються розробником: створення ПО, оформлення проектної та експлуатаційної документації, підготовка тестових та навчальних матеріалів і т. д.)
• Експлуатація (дії і завдання оператора - організації, що експлуатує систему)
• Супровід (дії і завдання, що виконуються супроводжує організацією, тобто службою супроводу). Супровід - внесень змін в ПЗ з метою виправлення помилок, підвищення продуктивності або адаптації до нових умов роботи або вимогам.
• Допоміжні
• Документування (формалізований опис інформації, створеної протягом ЖЦ ПО)
• Управління конфігурацією (застосування адміністративних і технічних процедур на всьому протязі ЖЦ ПО для визначення стану компонентів ПЗ, управління його модифікаціями).
• Забезпечення якості (забезпечення гарантій того, що ІС і процеси її ЖЦ відповідають заданим вимогам та затвердженим планам)
• Верифікація (визначення того, що програмні продукти, які є результатами певної дії, повністю задовольняють вимогам або умовам, обумовленим попередніми діями)
• Атестація (визначення повноти відповідності заданих вимог і створеної системи їх конкретному функціональному призначенню)
• Спільна оцінка (оцінка стану робіт по проекту: контроль планування та управління ресурсами, персоналом, апаратурою, інструментальними засобами)
• Аудит (визначення відповідності вимогам, планам і умов договору)
• Дозвіл проблем (аналіз і рішення проблем, незалежно від їх походження чи джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів)
• Організаційні
• Управління (дії і завдання, які можуть виконуватися будь-якою стороною, що управляє своїми процесами)
• Створення інфраструктури (вибір та супровід технології, стандартів та інструментальних засобів, вибір і установка апаратних і програмних засобів, що використовуються для розробки, експлуатації чи супроводу ПО)
• Удосконалення (оцінка, вимір, контроль та вдосконалення процесів ЖЦ)
• Навчання (початкове навчання і подальше постійне підвищення кваліфікації персоналу)

Кожен процес включає ряд дій. Наприклад, процес придбання охоплює наступні дії:

1. Ініціювання придбання
2. Підготовка заявочних пропозицій
3. Підготовка та коригування договору
4. Нагляд за діяльністю постачальника
5. Приймання та завершення робіт

Кожна дія включає ряд завдань. Наприклад, підготовка заявочних пропозицій повинна передбачати:

1. Формування вимог до системи
2. Формування списку програмних продуктів
3. Встановлення умов і угод
4. Опис технічних обмежень (середовище функціонування системи і т. д.)

2. Стадії життєвого циклу ПЗ, взаємозв'язок між процесами і стадіями

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

Стандарт ДСТУ ISO / IEC 12207-99 не пропонує конкретну модель життєвого циклу. Його положення є загальними для  будь-яких моделей життєвого циклу, методів і технологій створення  ІС. Він описує структуру процесів життєвого циклу, не конкретизуючи, як реалізувати або виконати дії  і завдання, включені в ці процеси.

Модель ЖЦ ПЗ включає в себе:

1. Стадії;
2. Результати виконання робіт на кожній стадії;
3. Ключові події - точки завершення робіт і прийняття рішень.

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

На кожній стадії можуть виконуватися декілька процесів, визначених у стандарті  ДСТУ ISO / IEC 12207-99, і навпаки, один і  той же процес може виконуватися на різних стадіях. Співвідношення між  процесами і стадіями також визначається використовуваної моделлю життєвого  циклу ПЗ.

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

1. Водопадна (каскадна, послідовна) модель

Водопадна модель життєвого циклу ( англ. waterfall model ) була запропонована в 1970 р. Уїнстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проекту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, суворо документуються у вигляді технічного завдання і фіксуються на весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.

Етапи проекту відповідно до каскадної  моделлю:

1. Формування вимог;
2. Проектування;
3. Реалізація;
4. Тестування;
5. Впровадження;
6. Експлуатація та супровід.

Переваги:

• Повна і узгоджена документація на кожному етапі;
• Легко визначити терміни і витрати на проект.

Недоліки:

У Водоспадної моделі перехід від  однієї фази проекту до іншого передбачає повну коректність результату (виходу) попередньої фази. Однак неточність вимозі або некоректна його інтерпретація в результаті призводить до того, що доводиться "відкочуватися" до ранньої фази проекту і необхідна переробка не просто вибиває проектну команду з графіка, але призводить часто до якісного зростання витрат і, не виключено, до припинення проекту в тій формі, в якій він спочатку замислювався. На думку сучасних фахівців, основне оману авторів Водоспадної моделі полягає в припущеннях, що проект проходить через весь процес один раз, спроектована архітектура хороша і проста у використанні, проект здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені в реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи ^[2]. Таким чином, Водопадна модель для великих проектів мало реалістична і може бути ефективно використана тільки для створення невеликих систем ^[3].

2. Ітераційна модель

Альтернативою послідовної моделі є так звана модель ітеративної  і інкрементального розробки ( англ. iterative and incremental development, IID ), Що отримала також від Т. Гілба в 70-і рр.. назву еволюційної моделі. Також цю модель називають ітеративної модель інкрементальний моделлю ^[4].

Модель IID передбачає розбиття життєвого  циклу проекту на послідовність  ітерацій, кожна з яких нагадує "міні-проект", включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, порівняно  з проектом в цілому. Мета кожної ітерації - отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом всіх попередніх та поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт отримує приріст - інкремент - до його можливостей, які, отже, розвиваються еволюційно. Ітеративного, інкрементального і еволюційність в даному випадку є вислів одного і те ж сенсу різними словами зі злегка різних точок зору ^[3].

За висловом Т. Гілба, "еволюція - прийом, призначений для створення видимості стабільності. Шанси успішного створення складної системи будуть максимальними, якщо вона реалізується в серії невеликих кроків і якщо кожен крок містить в собі чітко певний успіх, а також можливість" відкоту "до попереднього успішному етапу в разі невдачі. Перед тим, як пустити в справу всі ресурси, призначені для створення системи, розробник має можливість одержувати з реального світу сигнали зворотного зв'язку і виправляти можливі помилки в проекті " ^[4].

Підхід IID має і свої негативні  сторони, які, по суті, - зворотна сторона  достоїнств. По-перше, цілісне розуміння  можливостей і обмежень проекту  дуже довгий час відсутня. По-друге, при ітераціях доводиться відкидати  частину зробленої раніше роботи. По-третє, сумлінність фахівців при  виконанні робіт все ж знижується, що психологічно зрозуміло, адже над  ними постійно тяжіє відчуття, що "все  одно все можна буде переробити і  поліпшити пізніше" ^[3].

Різні варіанти ітераційного підходу  реалізовані в більшості сучасних методологій розробки ( RUP, MSF, XP).

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

Спіральна модель ( англ. spiral model ) Була розроблена в середині 1980-х років Баррі Боем. Вона заснована на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ПО створюється в кілька ітерацій (витків спіралі) методом прототипування.

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

На кожній ітерації оцінюються:

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

Важливо розуміти, що спіральна модель є не альтернативою еволюційної  моделі (моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну  модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно  самостійну модель поряд з IID ^[3].

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

1. Дефіцит фахівців.
2. Нереалістичні терміни і бюджет.
3. Реалізація невідповідної функціональності.
4. Розробка неправильного користувальницького інтерфейсу.
5. Перфекціонізм, непотрібна оптимізація і відточування деталей.
6. Безперервний потік змін.
7. Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених до інтеграцію.
8. Недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами.
9. Недостатня продуктивність одержуваної системи.
10. Розрив у кваліфікації фахівців різних областей.

У сьогоднішній спіральної моделі визначено  такий загальний набір контрольних  точок ^[5] :

1. Concept of Operations (COO) - концепція (використання) системи;
2. Life Cycle Objectives (LCO) - цілі та зміст життєвого циклу;
3. Life Cycle Architecture (LCA) - архітектура життєвого циклу; тут же можливо говорити про готовність концептуальної архітектури цільової програмної системи;
4. Initial Operational Capability (IOC) - перша версія створюваного продукту, придатна для дослідної експлуатації;
5. Final Operational Capability (FOC) - готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.

4. Методології розробки ПЗ

• Rational Unified Process (RUP).
• Microsoft Solutions Framework (MSF). Включає 4 фази: аналіз, проектування, розробка, стабілізація, припускає використання об'єктно-орієнтованого моделювання.
• Екстремальне програмування ( англ. Extreme Programming, XP ). В основі методології командна робота, ефективна комунікація між замовником і виконавцем протягом усього проекту з розробки ІС. Розробка ведеться з використанням послідовно доопрацьовано прототипів.

5. Адаптація стандарту до конкретного проекту

Не буває двох однакових  проектів. Варіації в організаційних службах і процедурах, методах і стратегіях придбання, розмірі та складності проекту, вимогах системи і методи розробки серед іншого впливають на спосіб створення, застосування і супроводу ПС. Використовувані реально у фірмах життєві цикли ПС останнім часом часто відрізняються від наведених в стандартах у зв'язку з розвитком і впровадженням об'єктно-орієнтованого аналізу і проектування, а також методів швидкої розробки прикладних програм, CASE-систем і мов четвертого покоління. У нових технологіях скорочуються стадії безпосереднього створення програмних та інформаційних компонентів і деталізуються процеси системного аналізу і проектування ПС в цілому. Крім того, зростають роль і конкретизація робіт з технологічної підтримки та графічної візуалізації проектування, а також по стандартизації інтерфейсів компонентів у створюваних додатках. Особлива увага приділяється деталізації процесів ЖЦ, що забезпечують високу якість створюваних ПС, і можливості їх ефективного ітераційного розвитку тривалий час у численних версіях. Вітчизняні розробники і користувачі сучасних інструментальних засобів створення програм, як правило, не знають і не враховують досвід, формалізований і відбитий в зарубіжних стандартах на ЖЦ ПС. технологічні комплекси збираються з окремих, слабко пов'язаних інструментальних пакетів прикладних програм, вирішальних приватні задачі автоматизації без аналізу та обліку всього ЖЦ ПС. У результаті технологія і процеси розробки формуються несистемно - з позиції досягнення найвищих показників ефективності та якості всього життєвого циклу конкретного ПС, а з позиції якнайшвидшого досягнення видимих для замовника результатів проекту. У разі критичних ПС це позначається згодом на їх низької надійності функціонування та безпеки застосування, а також ускладнює модернізацію та розвиток версій. 

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

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

Застосування вимог ГОСТ Р ІСО / МЕК 12207 до конкретного проекту (його адаптація) складається з робіт  таких видів:  
 
• визначення умов виконання проекту;  
• запит вихідних даних для адаптації;  
• вибір процесів, робіт і завдань;  
• документування рішень з адаптації та їх обгрунтувань.  
 
При визначенні умов виконання проекту повинні бути визначені характеристики умов виконання проекту, що впливають на адаптацію (наприклад, модель ЖЦ; вплив ЖЦ циклу існуючої системи; вимоги до системи та ПС; організаційні підходи, процедури і цілі; розмір, критичність і типи системи, ПС продукту або послуги; кількість задіяного персоналу та беруть участь у проекті сторін).  
 
При запиті вихідних даних для адаптації від беруть участь у проекті суб'єктів повинні бути запитані і отримані вихідні дані, які можуть вплинути на рішення щодо адаптації. У роботи з адаптації мають бути залучені користувачі, персонал супроводу, замовник і потенційні постачальники.  
 
При виборі процесів, робіт і завдань мають бути визначені необхідні для побудови моделі ЖЦ ПС процеси, роботи і завдання. При цьому повинні бути охоплені розробляється документація та обов'язки виконавців. Додаткові процеси, роботи і завдання, необхідні для реалізації проекту, але не описані в ДСТУ ISO / IEC 12207, слід встановити в договірній документації проекту.  
 
Всі рішення з адаптації та їх обгрунтування мають бути документально оформлені. 

При проведенні робіт з  адаптації слід керуватися також  рекомендаціями в частині класифікації ПС і в частині вибору і побудови моделі ЖЦ ПС.  
 
 Так, побудова моделі ЖЦ ПС повинно базуватися на концептуальній ідеї ПС (системи), охоплювати розробку (створення), експлуатацію та супровід і закінчуватися зняттям (утилізацією). Модель ЖЦ зазвичай розбивається на періоди реалізації, наприклад стадії або етапи. Кожне таке розбиття має охоплювати окремі роботи і завдання, реалізовані в даному періоді (стадії, етапі), і при їх завершення може знадобитися дозвіл сторін на перехід до наступного періоду моделі. 

Запитання адаптації загальної  структури ЖЦ ПС, описаної в ДСТУ ISO / IEC 12207, є ключовими при виборі (побудові) моделі ЖЦ ПС (автономної або  входить до складу загальної моделі ЖЦ створюваної системи) в умовах реалізації конкретного проекту. 

Процеси загальної структури  ЖЦ ПС за ГОСТ Р ІСО / МЕК 12207 засновані  на двох вихідних принципах; модульності  і відповідальності.  
 
Принцип модульності заснований на наступних положеннях. Кожен процес сильно пов'язаний, тобто організований таким чином, що всі частини процесу (роботи, задачі) суворо взаємопов'язані.  
 
• Процеси вільно з'єднані між собою. Кількість інтерфейсів між процесами зведено до мінімуму.  
 
• У принципі кожен процес призначений для реалізації унікальної функції в ЖЦ і може залучати інший процес для виконання спеціалізованої функції. При визначенні сфери застосування і структурування процесів повинні використовуватися такі правила.  
 
• Процес повинен бути свого роду модулем ЖЦ, тобто кожен процес повинен виконувати тільки власну функцію в ЖЦ, а інтерфейси між двома будь-якими процесами повинні бути мінімальні.  
 
• Кожен процес має бути прив'язаний до архітектури системи.  
 
• Якщо процес А викликаний процесом В і тільки процесом В, тоді А належить до В.  
 
• Якщо робота або завдання викликана більш ніж одним процесом, тоді вона сама стає процесом.  
 
• Повинна бути можливість для перевірки будь-якого процесу, роботи і завдання в моделі ЖЦ.  
 
• Кожен процес повинен мати внутрішню структуру, встановлену відповідно з тим, що повинно виконуватися.  
 
Принцип відповідальності базується на певних обов'язках кожного суб'єкта, залученого в ЖЦ. Суб'єкт може виконувати один або декілька процесів. Процес може бути виконаний одним або кількома суб'єктами, при цьому один із суб'єктів має бути визначений відповідальним за процес. Суб'єкт, що виконує процес, несе відповідальність за весь даний процес, навіть якщо виконання окремих робіт (завдань) доручено іншим суб'єктам. 

Відповідальність є особливістю  структури ЖЦ стосовно до умов проекту, в який закономірно може бути залучено безліч суб'єктів. 

Безумовно, застосування ДСТУ ISO / IEC 12207 вимагає від відповідних  суб'єктів певних зусиль щодо його адаптації  до умов реалізації конкретних проектів. Крім того, потрібні зусилля по його взаємозв'язку з конкретними методиками розробки Систем і іншими стандартами. Тим не менш, можна вважати, що впровадження даного стандарту в практичну діяльність має полегшити впорядкування взаємовідносин між суб'єктами, залученими в ЖЦ ПС [58]. 

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

Література

• Братіщенко В. В. Проектування інформаційних систем - Іркутськ: Изд-во БГУЕП, 2004. - 84 с.
• Вендров А. М. Проектування програмного забезпечення економічних інформаційних систем - М .: Фінанси і статистика, 2000.
• Грекул В.І., Денищенко Г.Н., Коровкіна Н. Л. Проектування інформаційних систем - М .: Інтернет-університет інформаційних технологій - ІНТУІТ.ру, 2005.
• Мішенін А. І. Теорія економічних інформаційних систем - М .: Фінанси і статистика, 2000. - 240 с.
• Орлик С., "Моделі життєвого циклу"