CASE-технології: що, коли, як?, CASE-засоби (моделювання), Програмування, статті

ЩО?


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


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


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



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


Але рано чи пізно повинні були з’явитися спеціалізовані програмно-технологічні засоби для розробки проектів, зокрема, заснованих на інформатизації. Ними стали кошти, що реалізують CASE-технологію створення та супроводження інформаційних систем. Термін CASE (Computer-Aided Software Engineering) сьогодні розуміється досить широко.


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


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



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


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



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


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


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


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



Всі сучасні CASE-засоби можна класифікувати за типами і категоріями. Класифікація за типами відображає функціональну орієнтацію CASE-засобів на ті чи інші процеси життєвого циклу. Класифікація по категоріях визначає ступінь інтегрованості по виконуваних функцій і включає окремі локальні засоби, вирішальні невеликі автономні задачі (tools), набір частково інтегрованих засобів, охоплюють більшість етапів життєвого циклу інформаційних систем (toolkit) і повністю інтегровані засоби, що підтримують весь життєвий цикл інформаційних систем і пов’язані спільним репозиторієм. Крім цього CASE-засоби можна класифікувати по застосовуваних методологій та моделями систем і БД; ступеня інтегрованості із СУБД; доступним платформам.


Класифікація за типами в основному збігається з компонентним складом CASE-засобів і включає:



Допоміжні типи включають:



КОЛИ?


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



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



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


Для того щоб прийняти зважене рішення щодо інвестицій в CASE-технологію, користувачі змушені виробляти оцінку окремих CASE-засобів, спираючись на неповні і суперечливі дані. Ця проблема часто посилюється недостатнім знанням усіх можливих “підводних каменів” використання CASE-засобів. Серед найбільш важливих проблем виділяють наступні:


• достовірна оцінка віддачі від інвестицій в CASE-засобу скрутна через відсутність прийнятних метрик і даних по проектам і процесам розробки ПЗ;
• впровадження CASE-засобів може представляти тривалий процес і не принести негайної віддачі. Можливо навіть короткострокове зниження продуктивності в результаті зусиль, що витрачаються на впровадження. Внаслідок цього керівництво організації-користувача може втратити інтерес до CASE-засобів і припинити підтримку їх впровадження;
• відсутність повної відповідності між тими процесами і методами, які підтримуються CASE-засобами, і тими, що використовуються в даній організації, може призвести до додаткових труднощів;
• CASE-засоби часто важко використовувати в комплексі з іншими подібними засобами. Це пояснюється як різними парадигмами, підтримуваними різноманітними засобами, так і проблемами передачі даних і управління від одного засобу до іншого;
• деякі CASE-засоби вимагають занадто багато зусиль для того, щоб виправдати їх використання в невеликому проекті, тим не менш, можна отримати вигоду з тієї дисципліни, до якої зобов’язує їх застосування;
• негативне ставлення персоналу до впровадження нової CASE-технології може бути головною причиною провалу проекту.


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


Але все ж грамотне, продумане і обгрунтоване використання CASE-технології здатне принести наступні вигоди:



ЯК?


Отже, ви зважилися на впровадження CASE-засобів. Процес впровадження складається з наступних етапів:



Визначення потреб у CASE-засобах можна проілюструвати наступною діаграмою (див. рис. 1).


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


Процес оцінки і вибору CASE-засобів можна розглянути у вигляді моделі. Цей процес може переслідувати декілька цілей і включати:



Нижче приведена діаграма, що описує найбільш загальну ситуацію оцінки і вибору, а також показує залежність між ними (див. рис. 2).


Як видно з малюнка, вхідний інформацією для процесу оцінки є:



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


Елементи процесу включають:



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


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


Визначення списку критеріїв засновано на користувацьких вимогах і включає:



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


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



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

Пілотний проект дозволяє отримати важливу інформацію, необхідну для оцінки якості функціонування CASE-засобу та його підтримки з боку постачальника після того, як засіб встановлено. Його реалізацію можна проілюструвати наступною схемою (див. рис. 3).


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


План переходу повинен включати наступне:



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


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


На додаток до цього слід зазначити, що кожна категорія співробітників (наприклад, адміністратори засобів, служба підтримки робочих місць, інтегратори засобів, служба супроводу і розробники додатків) потребує різному навчанні.
Навчання не повинно замикатися тільки на користувачах CASE-засобів, навчатися повинні і ті співробітники, на діяльність яких так чи інакше впливає використання CASE-засобів.


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


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



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


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


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


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


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*