Загальні вимоги до методології й технології

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

· технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ВС;

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

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

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

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

· стандарт користувацького інтерфейсу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Методологія RAD

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

· невелику команду розробників (від 2 до 10 чоловік);

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

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

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

Життєвий цикл ВС по методології RAD складається із чотирьох фаз:

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

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

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

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

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

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

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

· загальна інформаційна модель системи;

· функціональні моделі системи в цілому й підсистем, реалізованих окремими командами розробників;

· точно визначені за допомогою CASE-засобу інтерфейси між автономно розробленими підсистемами;

· побудовані прототипи.

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

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

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

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

· визначається необхідність розподілу даних;

· виробляється аналіз використання даних;

· виробляється фізичне проектування бази даних;

· визначаються вимоги до апаратних ресурсів;

· визначаються способи збільшення продуктивності;

· завершується розробка документації проекту.

Результатом фази є готова система, що відповідає всім погодженим вимогам.

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

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

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

< 1000 функціональних елементів	одна людина
1000-4000 функціональних елементів	одна команда розробників
> 4000 функціональних елементів	4000 функціональних елементів на одну команду розробників

Як підсумок перерахуємо основні принципи методології RAD:

· розробка додатків ітераціями;

· необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

· обов'язкове залучення користувачів у процес розробки ВС;

· необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

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

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

· ведення розробки незначною, але добре керованою командою професіоналів;

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