Методології і технології проектування ІС. Загальні вимоги до методології і технології

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

Життєвий цикл ІС.

Життєвий цикл по ІС

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

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

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

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

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

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

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

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

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

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

Найбільшого поширення набули наступні дві основні моделі ЖЦ:

· каскадна модель (70-85 г.г.);

· спіральна модель (86-90 г.г.).

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

Позитивні сторони застосування каскадного підходу полягають в наступному:

· на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;

· виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.

Мал. 1.Каскадна схема розробки ПЗ

В процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. В результаті реальний процес створення ПЗ приймав наступний вигляд (мал.2):

Мал. 2. Реальний процес розробки ПЗ по каскадній схемі

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

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

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

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

Мал. Спіральна модель ЖЦ

Методології і технології проектування ІС. Загальні вимоги до методології і технології

Методології, технології і інструментальні засоби проектування (CASE-средства) складають основу проекту будь-якій ІС. Методологія реалізується через конкретні технології і стандарти, що підтримують їх, методики і інструментальні засоби, які забезпечують виконання процесів ЖЦ.

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

· покрокової процедури, що визначає послідовність технологічних операцій проектування (мал. 4);

· критеріїв і правил, використовуваних для оцінки результатів виконання технологічних операцій;

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

Мал. 4. Представлення технологічної операції проектування

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

Технологія проектування, розробки і супроводу ІС повинна задовольняти наступним загальним требованям:

· технологія повинна підтримувати повний ЖЦ ПЗ;

· технологія повинна забезпечувати гарантоване досягнення цілей розробки ІС із заданою якістю і у встановлений час;

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

· технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу і підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

· технологія повинна забезпечувати мінімальний час отримання працездатної ІС;

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

· технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ІС (систем управління базами даних (СУБД), операційних систем, мов і систем програмування);

· технологія повинна бути підтримана комплексом узгоджених CASE-засобів, що забезпечують автоматизацію процесів, що виконуються на всіх стадіях ЖЦ.

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

· стандарт проектування;

· стандарт оформлення проектної документації;

· стандарт призначеного для користувача інтерфейсу.

Стандарт проектування повинен встановлювати:

· набір необхідних моделей (діаграм) на кожній стадії проектування і ступінь їх деталізації;

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

· вимоги до конфігурації робочих місць розробників, включаючи настройки операційної системи, настройки CASE-засобів, загальні настройки проекту і т. д.;

· механізм забезпечення спільної роботи над проектом, зокрема: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розробників стані (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і так далі), правила перевірки проектних рішень на несуперечність і так далі

Стандарт оформлення проектної документації повинен встановлювати:

· комплектність, склад і структуру документації на кожній стадії проектування;

· вимоги до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і так далі)

· правила підготовки, розгляду, узгодження і затвердження документації з вказівкою граничних термінів для кожної стадії;

· вимоги до настройки видавничої системи, використовуваної як вбудований засіб підготовки документації;

· вимоги до настройки CASE-засобів для забезпечення підготовки документації відповідно до встановлених вимог.

Стандарт інтерфейсу користувача повинен встановлювати:

· правила оформлення екранів (шрифти і колірна палітра), склад і розташування вікон і елементів управління;

· правила використання клавіатури і миші;

· правила оформлення текстів допомоги;

· перелік стандартних повідомлень;

· правила обробки реакції користувача.