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

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 с.
• Орлик С., "Моделі життєвого циклу"