CASE-технології. Сучасні методи і засоби проектування інформаційних систем
Введення
Метою даного огляду є введення особливо сучасних методів і засобів проектування інформаційних систем, заснованих на використанні CASE-технології.
Незважаючи на високі потенційні можливості CASE-технології (підвищення продуктивності праці, поліпшення якості програмних продуктів, підтримка уніфікованого та узгодженого стилю роботи) далеко не всі розробники інформаційних систем, що використовують CASE-засоби, досягають очікуваних результатів.
Існують різні причини можливих невдач, але, мабуть, основною причиною є неадекватне розуміння суті програмування інформаційних систем і застосування CASE-засобів. Необхідно розуміти, що процес проектування і розробки інформаційної системи на основі CASE-технології не може бути подібний до процесу приготування їжі по повареної книзі. Завжди слід бути готовим до нових труднощів, пов'язаних з освоєнням нової технології, послідовно долати ці труднощі і послідовно добиватися потрібних результатів.
Тенденції розвитку сучасних інформаційних технологій приводять до постійного зростання складності інформаційних систем (ІС), що створюються в різних галузях економіки. Сучасні великі проекти ІС характеризуються, як правило, наступними особливостями:
складність опису (достатньо велику кількість функцій, процесів, елементів даних і складні взаємозв'язки між ними), що вимагає ретельного моделювання та аналізу даних і процесів;
наявність сукупності тісно взаємодіючих компонентів (підсистем), які мають свої локальні завдання та цілі функціонування (наприклад, традиційних програм, пов'язаних з обробкою транзакцій і рішенням регламентних задач, та програм аналітичної обробки (підтримки прийняття рішень), що використовують нерегламентовані запити до даних великого обсягу);
відсутність прямих аналогів, що обмежує можливість використання будь-яких типових проектних рішень і прикладних систем;
необхідність інтеграції існуючих і розроблених нових додатків;
функціонування в неоднорідному середовищі на декількох апаратних платформах;
роз'єднаність та різнорідність окремих груп розробників за рівнем кваліфікації і сформованим традиціям використання тих чи інших інструментальних засобів;
істотна тимчасова довжина проекту, обумовлена, з одного боку, обмеженими можливостями колективу розробників, і, з іншого боку, масштабами організації-замовника та різним ступенем готовності окремих її підрозділів до впровадження ІС.
Для успішної реалізації проекту об'єкт проектування (ІС) повинен бути перш за все адекватно описаний, повинні бути побудовані повні і несуперечливі функціональні та інформаційні моделі ІС. Накопичений до теперішнього часу досвід проектування ІС показує, що це логічно складна, трудомістка і тривала за часом робота, що вимагає високої кваліфікації беруть участь у ній фахівців. Однак до недавнього часу проектування ІС виконувалося в основному на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірок якості функціонування ІС. Крім того, в процесі створення і функціонування ІС інформаційні потреби користувачів можуть змінюватися або уточнюватися, що ще більше ускладнює розробку та супровід таких систем.
У 70-х і 80-х роках при розробці ІС досить широко застосовувалася структурна методологія, що надає в розпорядження розробників строгі формалізовані методи опису ІВ і прийнятих технічних рішень. Вона заснована на наочній графічній техніці: для опису різного роду моделей ІС використовуються схеми та діаграми. Наочність і строгість коштів структурного аналізу дозволяла розробникам і майбутнім користувачам системи з самого початку неформально брати участь в її створенні, обговорювати і закріплювати розуміння основних технічних рішень. Однак, широке застосування цієї методології і дотримання її рекомендацій при розробці конкретних ІС зустрічалося досить рідко, оскільки при неавтоматизованої (ручний) розробці це практично неможливо. Дійсно, вручну дуже важко розробити і графічно представити суворі формальні специфікації системи, перевірити їх на повноту та несуперечність, і тим більше змінити. Якщо все ж таки вдається створити сувору систему проектних документів, то її переробка при появі серйозних змін практично нездійсненна. Ручна розробка зазвичай породжувала наступні проблеми:
неадекватна специфікація вимог;
нездатність виявляти помилки в проектних рішеннях;
низька якість документації, що знижує експлуатаційні якості;
затяжний цикл і незадовільні результати тестування.
З іншого боку, розробники ІС історично завжди стояли останніми в ряду тих, хто використовував комп'ютерні технології для підвищення якості, надійності та продуктивності у своїй власній роботі (феномен "чоботаря без чобіт").
Перераховані фактори сприяли появі програмно-технологічних засобів спеціального класу - CASE-засобів, що реалізують CASE-технологію створення і супроводу ІС. Термін CASE (Computer Aided Software Engineering) використовується в даний час в дуже широкому значенні. Первісне значення терміна CASE, обмежене питаннями автоматизації розробки тільки лише програмного забезпечення (ПЗ), в даний час набула нового змісту, що охоплює процес розробки складних ІС у цілому. Тепер під терміном CASE-засоби розуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, проектування прикладного ПЗ (додатків) і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. CASE-засоби разом із системним ПЗ і технічними засобами утворюють повну середовище розробки ІС.
Появі CASE-технології та CASE-засобів передували дослідження в галузі методології програмування. Програмування отримав риси системного підходу з розробкою і впровадженням мов високого рівня, методів структурного і модульного програмування, мов проектування і засобів їх підтримки, формальних і неформальних мов описів системних вимог і специфікацій і т.д. Крім того, появі CASE-технології сприяли і такі фактори, як:
підготовка аналітиків і програмістів, сприйнятливих до концепцій модульного і структурного програмування;
широке впровадження і постійне зростання продуктивності комп'ютерів, що дозволили використовувати ефективні графічні засоби і автоматизувати більшість етапів проектування;
впровадження мережної технології, яка надала можливість об'єднання зусиль окремих виконавців в єдиний процес проектування шляхом використання розділяється бази даних, яка містить необхідну інформацію про проект.
CASE-технологія являє собою методологію проектування ІС, а також набір інструментальних засобів, що дозволяють в наочній формі моделювати предметну область, аналізувати цю модель на всіх етапах розробки та супроводження ІС і розробляти програми відповідно до інформаційних потреб користувачів. Більшість існуючих CASE-засобів засновано на методологіях структурного (в основному) або об'єктно-орієнтованого аналізу і проектування, що використовують специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв'язків між моделями системи, динаміки поводження системи та архітектури програмних засобів.
Відповідно до огляду передових технологій (Survey of Advanced Technology), складеним фірмою Systems Development Inc. в 1996 р. за результатами анкетування понад 1000 американських фірм, CASE-технологія в даний час потрапила в розряд найбільш стабільних інформаційних технологій (її використовувала половина всіх опитаних користувачів більш ніж у третині своїх проектів, з них 85% завершилися успішно). Однак, незважаючи на всі потенційні можливості CASE-засобів, існує безліч прикладів їх невдалого впровадження, в результаті яких CASE-засоби стають "полична" ПЗ (shelfware). У зв'язку з цим необхідно відзначити наступне:
CASE-засоби не обов'язково дають негайний ефект; він може бути отриманий тільки через якийсь час;
реальні витрати на впровадження CASE-засобів звичайно набагато перевищують витрати на їх придбання;
CASE-засоби забезпечують можливості для одержання істотної вигоди тільки після успішного завершення процесу їх впровадження.
Зважаючи різноманітної природи CASE-засобів було б помилкою робити які-небудь беззаперечні твердження щодо реального задоволення тих чи інших очікувань від їх впровадження. Можна перерахувати наступні фактори, що ускладнюють визначення можливого ефекту від використання CASE-засобів:
широке розмаїття якості і можливостей CASE-засобів;
відносно невеликий час використання CASE-засобів в різних організаціях і брак досвіду їх застосування;
широке розмаїття в практиці впровадження різних організацій;
відсутність детальних метрик і даних для вже виконаних і поточних проектів;
широкий діапазон предметних областей проектів;
різний ступінь інтеграції CASE-засобів в різних проектах.
Внаслідок цих складнощів доступна інформація про реальне впровадження вкрай обмежена і суперечлива. Вона залежить від типу засобів, характеристик проектів, рівня супроводу і досвіду користувачів. Деякі аналітики вважають, що реальна вигода від використання деяких типів CASE-засобів може бути отримана тільки після одно-або дворічного досвіду. Інші вважають, що вплив може реально проявитися у фазі експлуатації життєвого циклу ІС, коли технологічні поліпшення можуть призвести до зниження експлуатаційних витрат.
Для успішного впровадження CASE-засобів організація повинна володіти наступними якостями:
Технологія. Розуміння обмеженості існуючих можливостей і здатність прийняти нову технологію;
Культура. Готовність до впровадження нових процесів і взаємовідносин між розробниками та користувачами;
Управління. Чітке керівництво і організованість по відношенню до найбільш важливих етапів і процесів впровадження.
Якщо організація не володіє хоча б одним з перерахованих якостей, то впровадження CASE-засобів може закінчитися невдачею незалежно від ступеня старанності проходження різних рекомендацій щодо впровадження.
Для того, щоб прийняти зважене рішення щодо інвестицій в CASE-технологію, користувачі змушені робити оцінку окремих CASE-засобів, спираючись на неповні і суперечливі дані. Ця проблема часто ускладнюється недостатнім знанням всіх можливих "підводних каменів" використання CASE-засобів. Серед найбільш важливих проблем виділяються наступні:
достовірна оцінка віддачі від інвестицій в CASE-засоби скрутна через відсутність прийнятних метрик і даних по проектам і процесів розробки ПЗ;
впровадження CASE-засобів може являти собою досить тривалий процес і може не принести негайної віддачі. Можливо навіть короткострокове зниження продуктивності в результаті зусиль, що витрачаються на впровадження. Внаслідок цього керівництво організації-користувача може втратити інтерес до CASE-засобів і припинити підтримку їх впровадження;
відсутність повної відповідності між тими процесами та методами, які підтримуються CASE-засобами, і тими, які використовуються в даній організації, може призвести до додаткових труднощів;
CASE-засоби часто важко використовувати в комплексі з іншими подібними засобами. Це пояснюється як різними парадигмами, що підтримуються різними засобами, так і проблемами передачі даних і керування від одного засобу до іншого;
деякі CASE-засоби вимагають надто багато зусиль для того, щоб виправдати їх використання в невеликому проекті, при цьому, тим не менш, можна отримати вигоду з тієї дисципліни, до якої зобов'язує їх застосування;
негативне ставлення персоналу до впровадження нової CASE-технології може бути головною причиною провалу проекту.
Користувачі CASE-засобів повинні бути готові до необхідності довгострокових витрат на експлуатацію, частого появи нових версій і можливого швидкого морального старіння засобів, а також постійних витрат на навчання та підвищення кваліфікації персоналу.
Незважаючи на всі висловлені застереження і деякий песимізм, грамотний і розумний підхід до використання CASE-засобів може подолати всі перераховані труднощі. Успішне впровадження CASE-засобів повинне забезпечити такі вигоди як:
високий рівень технологічної підтримки процесів розробки і супроводу ПЗ;
позитивний вплив на деякі або всі з перерахованих факторів: продуктивність, якість продукції, дотримання стандартів, документування;
прийнятний рівень віддачі від інвестицій в CASE-засоби.
1. Основи методології проектування ІС
1.1. Життєвий цикл з ІВ
Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:
основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
допоміжні процеси, які забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).
Розробка включає в себе всі роботи зі створення ПЗ і його компонент відповідно до заданих вимог, включаючи оформлення проектної та експлуатаційної документації, підготовку матеріалів, необхідних для перевірки працездатності та відповідної якості програмних продуктів, матеріалів, необхідних для організації навчання персоналу і т . д. Розробка ПЗ включає в себе, як правило, аналіз, проектування і реалізацію (програмування).
Експлуатація включає в себе роботи з впровадження компонентів ПЗ в експлуатацію, в тому числі конфігурування бази даних і робочих місць користувачів, забезпечення експлуатаційної документації, проведення навчання персоналу і т.д., і безпосередньо експлуатацію, в тому числі локалізацію проблем і усунення причин їх виникнення, модифікацію ПЗ в рамках встановленого регламенту, підготовку пропозицій щодо вдосконалення, розвитку та модернізації системи.
Управління проектом пов'язано з питаннями планування та організації робіт, створення колективів розробників і контролю за строками та якістю виконуваних робіт. Технічне та організаційне забезпечення проекту включає вибір методів та інструментальних засобів для реалізації проекту, визначення методів опису проміжних станів розробки, розробку методів і засобів випробувань ПЗ, навчання персоналу тощо Забезпечення якості проекту пов'язано з проблемами верифікації, перевірки та тестування ПЗ. Верифікація - це процес визначення того, чи відповідає поточний стан розробки, досягнута на даному етапі, вимогам цього етапу. Перевірка дозволяє оцінити відповідність параметрів розробки з вихідними вимогами. Перевірка частково збігається з тестуванням, яке пов'язане з ідентифікацією відмінностей між дійсними і очікуваними результатами та оцінкою відповідності характеристик ПЗ початковим вимогам. У процесі реалізації?? проекту важливе місце займають питання ідентифікації, опису і контролю конфігурації окремих компонентів і всієї системи в цілому.
Управління конфігурацією є одним з допоміжних процесів, які підтримують основні процеси життєвого циклу ПЗ, перш за все процеси розробки та супроводження ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди чи версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури і забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін до ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені в проекті стандарту 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-засоби використовуються для швидкого отримання працюють прототипу. Користувачі, які безпосередньо взаємодіючи з ними, уточнюють і доповнюють вимоги до системи, які не були виявлені на попередній фазі. Більш докладно розглядаються процеси системи. Аналізується і, при необхідності, коригується функціональна модель. Кожен процес розглядається детально. При необхідності для кожного елементарного процесу створюється частковий прототип: екран, діалог, звіт, що усуває неясності або неоднозначності. Визначаються вимоги розмежування доступу до даних. На цій же фазі відбувається визначення набору необхідної документації.
Після детального визначення складу процесів оцінюється кількість функціональних елементів системи розробляється і приймається рішення про поділ ІС на підсистеми, які піддаються реалізації однією командою розробників за прийнятний для RAD-проектів час - близько 60 - 90 днів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:
загальна інформаційна модель системи;
функціональні моделі системи в цілому і підсистем, що реалізуються окремими командами розробників;
точно визначені за допомогою CASE-засоби інтерфейси між автономно розробляються підсистемами;
побудовані прототипи екранів, звітів, діалогів.
Усі моделі та прототипи повинні бути отримані із застосуванням тих CASE-засобів, які будуть використовуватися в подальшому при побудові системи. Ця вимога викликана тим, що в традиційному підході при передачі інформації про проект з етапу на етап може відбутися фактично неконтрольоване перекручення даних. Застосування єдиної середовища зберігання інформації про проект дозволяє уникнути цієї небезпеки.
На відміну від традиційного підходу, при якому використовувалися специфічні кошти прототипирування, не призначені для побудови реальних програм, а прототипи викидалися після того, як виконували завдання усунення неясностей у проекті, у підході RAD кожен прототип розвивається в частину майбутньої системи. Таким чином, на наступну фазу?? ередается більш повна і корисна інформація.
На фазі побудови виконується безпосередньо сама швидка розробка програми. На цій фазі розробники виробляють Ітеративний побудову реальної системи на основі отриманих в попередній фазі моделей, а також вимог нефункціонального характеру. Програмний код частково формується за допомогою автоматичних генераторів, які отримують інформацію безпосередньо з репозиторію CASE-засобів. Кінцеві користувачі на цій фазі оцінюють отримані результати і вносять корективи, якщо в процесі розробки система перестає задовольняти визначеним раніше вимогам. Тестування системи здійснюється безпосередньо в процесі розробки.
Після закінчення робіт кожної окремої команди розробників проводиться поступова інтеграція даної частини системи з іншими, формується повний програмний код, що виконується тестування спільної роботи даної частини програми з іншими, а потім тестування системи в цілому. Завершується фізичне проектування системи:
визначається необхідність розподілу даних;
проводиться аналіз використання даних;
здійснюється фізичне проектування бази даних;
визначаються вимоги до апаратних ресурсів;
визначаються способи збільшення продуктивності;
завершується розробка документації проекту.
Результатом фази є готова система, що задовольняє всім узгодженим вимогам.
На фазі впровадження проводиться навчання користувачів, організаційні зміни і паралельно з впровадженням нової системи здійснюється робота з існуючою системою (до повного впровадження нової). Так як фаза побудови достатньо нетривала, планування та підготовка до впровадження повинні починатися заздалегідь, як правило, на етапі проектування системи. Наведена схема розробки ІС не є абсолютною. Можливі різні варіанти, які залежать, наприклад, від початкових умов, в яких ведеться розробка: розробляється зовсім нова система; вже було проведено обстеження підприємства і існує модель його діяльності; на підприємстві вже існує деяка ІВ, яка може бути використана в якості початкового прототипу або повинна бути інтегрована з розробляється.
Слід, однак, відзначити, що методологія RAD, як і будь-яка інша, не може претендувати на універсальність, вона хороша в першу чергу для відносно невеликих проектів, що розробляються для конкретного замовника. Якщо ж розробляється типова система, яка не є закінченим продуктом, а являє собою комплекс типових компонент, централізовано супроводжуваних, адаптується до програмно-технічним платформ, СУБД, засобів телекомунікації, організаційно-економічних особливостей об'єктів впровадження та інтегруються з існуючими розробками, на перший план виступають такі показники проекту, як керованість і якість, які можуть увійти в суперечність з простотою і швидкістю розробки. Для таких проектів необхідні високий рівень планування та
