7. Сучасні підходи та організаційно-методичні основи створення інформаційних систем

Завжди не вистачає часу, щоб виконати роботу як слід,

але на те, щоб її переробити, час знаходиться.

Закон Мескімена

7.1. Моделі життєвого циклу інформаційних систем підприємств

Під моделлю життєвого циклу ІС розуміється структура, що визначає послідовність виконання і взаємозв'язок процесів, дій і задач упродовж життєвого циклу. Головним нормативним документом, що регламентує склад процесів життєвого циклу, є міжнародний стандарт ISO¹/IEC² 12207:1995 “Information Technology – Software Life Cycle Processing” та відповідний йому Державний стандарт України ДСТУ 3918-99 “Інформаційні технології. Процеси життєвого циклу програмного забезпечення“ [57].

Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:

– основні процеси ЖЦ ПЗ (придбання, поставка, розробка, експлуатація, супровід);

– допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);

– організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка й поліпшення самого ЖЦ, навчання).

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

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

Управління проектом пов'язане з питаннями планування й організації робіт, створення колективів розроблювачів і контролю за строками і якістю виконуваних робіт.

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

Забезпечення якості проекту пов'язане із проблемами верифікації, перевірки й тестування ПЗ.

Верифікація – це процес визначення того, чи відповідає поточний стан розробки, досягнутий на даному етапі, вимогам цього етапу.

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

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

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

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

ЖЦ ПЗ носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, прийнятих на більш ранніх етапах.

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

В усіх роботах, в яких так чи інакше висвітлюється життєвий цикл програмних систем, наприклад [58, 59], є посилання на ці стандарти. Крім того, в них наводяться приклади каскадної моделі життєвого циклу та для порівняння на її тлі – спіральної моделі, що має більш досконалі властивості для моделювання процесів життєвого циклу. Але, якщо для каскадної моделі життєвий цикл включає стадію експлуатації та супроводу, то для спіральної моделі (її графічного зображення) життєвий цикл закінчується стадією тестування. Інакше кажучи, така спіральна модель відображає не життєвий цикл програмної системи, а життєвий цикл її розробки. Цей погляд на спіральну модель дещо розбігається з міжнародним та державним стандартами.

ЖЦ є моделлю створення і використання АІСУП, що відображає різні її стани, починаючи з моменту виникнення необхідності у даному виробі і закінчуючи моментом його повного виходу з використання усіх без винятку користувачів.

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

– стадії;

– результати виконання робіт на кожній стадії;

– ключові події – точки завершення робіт і прийняття рішень.

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

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

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

Існуючі моделі ЖЦ визначають порядок виконання етапів у ході розробки, а також критерії переходу від етапу до етапу. Відповідно до цього найбільше поширення отримали такі три моделі ЖЦ:

1. Каскадна (водоспадна) модель (англ. waterfall model) (70–80-ті роки ХХ ст.) передбачає перехід до наступного етапу після повного завершення робіт на попередньому етапі і характеризується чітким поділом даних і процесів їх опрацювання (рис. 7.1).

Формування вимог

Розробка технічного завдання

Планування розробки

Проектування

Реалізація

Впровадження системи

Супровід

Рис. 7.1. Каскадна (водоспадна) модель життєвого циклу ІС

Переваги:

– повна й узгоджена документація на кожному етапі;

– легкість визначення термінів і витрат на проект.

Недоліки:

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

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

2. Поетапна модель з проміжним контролем (80–85-ті роки ХХ ст.) – ітераційна³ модель розробки з циклами зворотного зв'язку між етапами (англ. iterative and incremental development – IID), модель ітеративної і інкрементальної розробки, еволюційна модель є альтернативою послідовної моделі.

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

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

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

Перевага такої моделі – в тому, що міжетапні коригування забезпечують меншу трудомісткість порівняно з каскадною моделлю; з іншого боку, час життя кожного з етапів розтягується на весь період розробки.

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

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

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

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

Рис. 7.2. Спіральна модель життєвого циклу ІС

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

– дефіцит фахівців;

– нереалістичні терміни і бюджет;

– реалізація невідповідної функціональності;

– розробка неправильного користувальницького інтерфейсу;

– перфекціонізм, непотрібна оптимізація і відточування деталей;

– безперервний потік змін;

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

– недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами;

– недостатня продуктивність одержуваної системи;

– розрив у кваліфікації фахівців різних областей.

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

– concept of operations (COO) – концепція (використання) системи;

– life cycle objectives (LCO) – цілі та зміст життєвого циклу;

– life cycle architecture (LCA) – архітектура життєвого циклу; тут же можливо говорити про готовність концептуальної архітектури цільової програмної системи;

– initial operational capability (IOC) – перша версія створюваного продукту, придатна для дослідної експлуатації;

– final operational capability (FOC) – готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.