Сучасні методи і засоби проектування інформаційних систем

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

Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, передусім процеси розробки і супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди чи версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін в ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені в проекті стандарту ISO 12207-2 [5].

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

Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій і завдань, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС та специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO / IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.

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

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

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

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

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

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

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

Рис. 1.1. Каскадна схема розробки ПЗ

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

Рис. 1.2. Реальний процес розробки ПЗ за каскадної схемою

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

правила обробки реакції користувача. 1.3.2. Методологія RAD

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є отримала останнім часом широкого поширення методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном зазвичай розуміється процес розробки ПЗ, що містить 3 елементи:

невелику команду програмістів (від 2 до 10 осіб);

короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);

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

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

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

фаза аналізу і планування вимог;

фаза проектування;

фаза побудови;

фаза впровадження.

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

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