Життєвийцикл по ІС
Однимз базових понять методології проектування ІС є поняття життєвого циклу їїпрограмного забезпечення (ГЦ ПЗ). ЖЦ ПЗ — це безперервний процес, якийпочинається з моменту ухвалення рішення про необхідність його створення ізакінчується у момент його повного вилучення з експлуатації.
Основнимнормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC12207 (ISO — International Organization of Standardization — Міжнароднаорганізація по стандартизації, IEC — International Electrotechnical Commission- Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що міститьпроцеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
СтруктураЖЦ ПО за стандартом ISO/IEC 12207 базується на трьох групах процесів:
üосновні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація,супровід);
üдопоміжні процеси, що забезпечують виконання основних процесів(документування, управління конфігурацією, забезпечення якості, верифікація,атестація, оцінка, аудит, рішення проблем);
üорганізаційні процеси (управління проектами, створенняінфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).
Розробкавключає всі роботи із створення ПЗ і його компонент відповідно до заданихвимог, включаючи оформлення проектної і експлуатаційної документації,підготовку матеріалів, необхідних для перевірки працездатності і відповідноїякості програмних продуктів, матеріалів, необхідних для організації навчанняперсоналу і т.д. Розробка ПЗ включає, як правило, аналіз, проектування іреалізацію (програмування).
Експлуатаціявключає роботи по впровадженню компонентів ПЗ в експлуатацію, зокремаконфігурацію бази даних і робочих місць користувачів, забезпеченняексплуатаційною документацією, проведення навчання персоналу і т.д., ібезпосередньо експлуатацію, зокрема локалізацію проблем і усунення причин їхвиникнення, модифікацію ПЗ в рамках встановленого регламенту, підготовкупропозицій по вдосконаленню, розвитку і модернізації системи.
Управлінняпроектом пов'язане з питаннями планування і організації робіт, створення колективіврозробників і контролю за термінами і якістю виконуваних робіт. Технічне іорганізаційне забезпечення проекту включає вибір методів і інструментальнихзасобів для реалізації проекту, визначення методів опису проміжних станіврозробки, розробку методів і засобів випробувань ПЗ, навчання персоналу і т.п.Забезпечення якості проекту пов'язане з проблемами верифікації, перевірки ітестування ПЗ. Верифікація — це процес визначення того, чи відповідає поточнийстан розробки, досягнутий на даному етапі, вимогам цього етапу. Перевіркадозволяє оцінити відповідність параметрів розробки з початковими вимогами.Перевірка частково співпадає з тестуванням, яке пов'язане з ідентифікацієювідмінностей між дійсними і очікуваними результатами і оцінкою відповідності характеристикНА початкові вимоги. В процесі реалізації проекту важливе місце займаютьпитання ідентифікації, опису і контролю конфігурації окремих компонентів івсієї системи в цілому.
Управлінняконфігурацією є одним з допоміжних процесів, що підтримують основні процесижиттєвого циклу ПЗ, перш за все процеси розробки і супроводу ПЗ. При створенніпроектів складних ІС, що складаються з багатьох компонентів, кожний з яких можемати різновиди або версії, виникає проблема обліку їх зв'язків і функцій, створенняуніфікованої структури і забезпечення розвитку всієї системи. Управлінняконфігурацією дозволяє організувати, систематично враховувати і контролювативнесення змін до ПЗ на всіх стадіях ЖЦ. Загальні принципи і рекомендаціїконфігураційного обліку, планування і управління конфігураціями ПЗ відбиті впроекті стандарту ISO 12207-2.
Коженпроцес характеризується певними завданнями і методами їх рішення, початковимиданими, одержаними на попередньому етапі, і результатами. Результатами аналізу,зокрема, є функціональні моделі, інформаційні моделі і відповідні їм діаграми.ЖЦ ПЗ носить ітераційний характер: результати чергового етапу часто викликаютьзміни в проектних рішеннях, вироблених на попередніх етапах.
Моделіжиттєвого циклу ПЗ
СтандартISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлюЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язкупроцесів, дій і завдань, що виконуються впродовж ЖЦ. Модель ЖЦ залежить відспецифіки ІС і специфіки умов, в яких остання створюється і функціонує). Йогорегламенти є загальними для будь-яких моделей ЖЦ, методологій і технологійрозробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але неконкретизує в деталях, як реалізувати або виконати дії і завдання, включені вці процеси. До теперішнього часу найбільшого поширення набули наступні двіосновні моделі ЖЦ:
ü каскадна модель (70-85 г.г.);
ü спіральна модель (86-90 г.г.).
У спочаткуіснуючих однорідних ІС кожне застосування було єдине ціле. Для розробки такоготипу застосувань застосовувався каскадний спосіб. Його основною характеристикоює розбиття всієї розробки на етапи, причому перехід з одного етапу на наступнийвідбувається тільки після того, як буде повністю завершена робота на поточному(Рис. 2.1). Кожен етап завершується випуском повного комплекту документації,достатньої для того, щоб розробка могла бути продовжена іншою командоюрозробників.
Позитивністорони застосування каскадного підходу полягають в наступному:
ü на кожному етапі формується закінчений набір проектноїдокументації, що відповідає критеріям повноти і узгодженості;
ü виконувані в логічній послідовності етапи робіт дозволяютьпланувати терміни завершення всіх робіт і відповідні витрати.
/>
Рис.2.1. Каскадна схема розробки ПЗ
Каскаднийпідхід добре зарекомендував себе при побудові ІС, для яких на самому початкурозробки можна достатньо точно і повно формулювати всі вимоги, з тим щоб надатирозробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цюкатегорію потрапляють складні розрахункові системи, системи реального часу іінші подібні завдання. Проте, в процесі використання цього підходу виявився рядйого недоліків, викликаних перш за все тим, що реальний процес створення ПЗніколи повністю не укладався в таку жорстку схему. В процесі створення ПЗпостійно виникала потреба в поверненні до попередніх етапів і уточненні абоперегляді раніше ухвалених рішень. В результаті реальний процес створення ПЗприймав наступний вигляд (Рис. 2.2):
/>
Рис.2.2. Реальний процес розробки ПЗ по каскадній схемі
Основнимнедоліком каскадного підходу є істотне запізнювання з отриманням результатів.Узгодження результатів з користувачами проводиться тільки в крапках, щоплануються після завершення кожного етапу робіт, вимоги до ІС«заморожені» у вигляді технічного завдання на весь час її створення.Таким чином, користувачі можуть внести свої зауваження тільки після того, якробота над системою буде повністю завершена. У разі неточного викладу вимог абоїх зміни протягом тривалого періоду створення ПЗ, користувачі одержуютьсистему, що не задовольняє їх потребам. Моделі (як функціональні, так і інформаційні)об'єкту, що автоматизується, можуть застаріти одночасно з їх твердженням.
Дляподолання перерахованих проблем була запропонована спіральна модель ЖЦ (Рис.2.3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цихетапах реалізовується технічних рішень перевіряється шляхом створенняпрототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ,на ньому уточнюються цілі і характеристики проекту, визначається його якість іплануються роботи наступного витка спіралі. Таким чином заглиблюються іпослідовно конкретизуються деталі проекту і в результаті вибираєтьсяобґрунтований варіант, який доводиться до реалізації.
Розробкаітераціями відображає об'єктивно існуючий спіральний цикл створення системи.Неповне завершення робіт на кожному етапі дозволяє переходити на наступнийетап, не чекаючи повного завершення роботи на поточному. При ітеративномуспособі розробки бракуючу роботу можна буде виконати на наступній ітерації.Головне ж завдання — щонайшвидше показати користувачам системи працездатнийпродукт, тим самим активізуючи процес уточнення і доповнення вимог.
Основнапроблема спірального циклу — визначення моменту переходу на наступний етап. Дляїї вирішення необхідно ввести тимчасові обмеження на кожний з етапів життєвогоциклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланованаробота закінчена. План складається на основі статистичних даних, одержаних впопередніх проектах, і особистого досвіду розробників.
/>
Рис2.3. Спіральна модель ЖЦ
Використаналітература
1. Горін С.В., Тандоєв А.Ю. Застосування CASE-засобу Erwin 2.0 дляінформаційного моделювання в системах обробки даних. «СУБД», 1995 №3.
2. Горчинськая О.Ю. Designer/2000 — нове покоління CASE-продуктівфірми ORACLE. «СУБД», 1995 №3.
3. Зіндер Е.З. Бізнес-рєїнжінірінг і технології системногопроектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996
4. Калянов Г.Н. CASE. Структурний системний аналіз (автоматизація ізастосування). М., «Лорі», 1996.
5. Марка Д.А., МакГоуен К. Методология структурного аналізу іпроектування. М., «МетаТехнология», 1993.