Ніша та впровадження CASE-засобів

Після того як я прочитав у вересневому випуску журналу "Директору ІС" статтю Фреда Хепгуда "CASE: кінець історії?", Захотілося поділитися своїми (і не тільки своїми) міркуваннями – все-таки вже майже 10 років займаюся цією проблематикою. Заголовок статті відразу викликав бажання заперечити: який же це кінець історії, коли їй без року тиждень, і все тільки починається (досить звернутися до оцінки ступеня розвиненості програмної інженерії, що міститься у технічному звіті SEI "A Mature Profession of Software Engineering", опублікованому в 1996 році). По суті, я хочу підтримати одну з думок, процитованих у статті Ф. Хепгуда, а саме те, що CASE-засоби зайняли свою нішу в області проектування великих та складних систем.


Якщо розглядати CASE (Computer Aided Software Engineering) в первісному розумінні – як засіб комп'ютерної підтримки розробки програмного забезпечення (ПЗ), то їх користь у проектуванні великих і складних програмних систем стане цілком зрозумілою. На підтвердження цієї тези можна послатися на "Міфічний людино-місяць" Фредеріка Брукса. Найбільшою проблемою, яку доводиться вирішувати програмної інженерії, є складність ПЗ. Складність стає істотним і невід'ємним властивістю програмних систем. Тому спроби опису програмних об'єктів, абстрагуючись від їх складності, призводять до абстрагування і від їх сутності. Нелінійний зростання складності при збільшенні розміру ПЗ. Створює труднощі в процесі спілкування між розробниками, що веде до помилок у продукті, перевищення вартості розробки, затягування виконання графіків робіт. Складність структури ускладнює розвиток ПЗ і додавання нових функцій.


Моделювання програмних систем


Для успішної реалізації проекту об'єкт проектування (в нашому випадку ПЗ) повинен бути перш за все адекватно описаний, тобто повинна бути побудована повна і несуперечлива архітектура ПЗ. Архітектура ПО представляється у вигляді сукупності моделей, які будуються для того, щоб зрозуміти і осмислити структуру і поведінку майбутньої системи, полегшити управління процесом її створення та зменшити можливий ризик, а також документувати прийняті проектні рішення. Розробка архітектури системи ПО промислового характеру на стадії, що передує її реалізації чи оновленню, в такій же мірі необхідна, як і наявність проекту для будівництва великої будівлі. Це твердження справедливо як у випадку розробки нової системи, так і при адаптації типових продуктів класу R / 3 або BAAN, у складі яких також є власні кошти моделювання. Хороші моделі є основою взаємодії учасників проекту та гарантують коректність архітектури.


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



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


У той же час практичне впровадження CASE-технології в організаціях-розробниках ПЗ пов'язане з низкою проблем. Вони досить повно викладені в американському стандарті IEEE Std. 1348-1995. IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools. Мета наведених у стандарті рекомендацій – надати посібник, що дозволяє підвищити вірогідність успішного впровадження CASE-технології. Ці рекомендації досить актуальні і цінні, оскільки відображають досвід, накопичений багатьма зарубіжними користувачами і розробниками CASE-засобів.


Проблеми впровадження CASE-засобів


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



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



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


Процес впровадження CASE-засобів


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


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


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


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



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


Очікувані та несподівані результати


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


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


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


Реалістичні очікування:



Нереалістичні очікування:



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



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


Про вибір CASE-засоби


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



  1. Підтримка повного життєвого циклу ПЗ з забезпеченням еволюційності його розвитку.
  2. Забезпечення цілісності проекту та контролю за його станом.
  3. Незалежність від програмно-апаратної платформи і СУБД.
  4. Підтримка одночасної роботи груп розробників.
  5. Можливість розробки додатків "клієнт-сервер" необхідної конфігурації.
  6. Відкрита архітектура і можливості експорту / імпорту.
  7. Якість технічної підтримки в Росії, вартість придбання та підтримки, досвід успішного використання.
  8. Простота освоєння і використання.
  9. Забезпечення якості проектної документації.
  10. Використання загальноприйнятих, стандартних нотацій і угод.

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


До речі, початком появи на російському ринку перших CASE-засобів можна вважати 1992 рік. Першими такими засобами були ProKit Workbench фірми McDonnell Douglas Information Systems, Design / IDEF фірми MetaSoftware і вітчизняна розробка фірми "Ейтекс" під назвою CASE.Аналітік. Надалі на ринку з'явилися і успішно використовувалися такі продукти, як Erwin, BPwin, Silverrun, Oracle Designer, Rational Rose.


Підсумовуючи сказане


Зазначу ще раз, що основна ніша CASE-засобів – проектування великих та складних систем. Проте їх застосування може бути успішним у повній мірі лише за умови належної організації проекту, достатнього фінансування, розумних термінів і т.д. У той же час в останні роки складається культура так званих екстремальних проектів. В англомовній літературі з легкої руки Едварда Йордана, одного з провідних світових фахівців у галузі програмної інженерії та автора книги "Death March. The Complete Software Developers" s Guide to Surviving "Mission Impossible" Projects ", випущеної видавництвом Prentice-Hall в 1997 р. (у видавництві "ЛОРІ" виходить її російський переклад) за такими проектами затвердилася назва "death march", буквально – "смертельний марш". Однак, більш докладну розмову на тему про використання CASE-засобів в таких проектах краще залишити для окремої статті.


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


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

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

Ваш отзыв

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

*

*