Лекція 16: Стандарти iso, sw-cmm. Case-технології

Стандарти ISO

У 1947 році в Лондоні представники 25 країн вирішили створити міжнародну організацію, основним завданням якої стала б координація розробок і уніфікація міжнародних стандартів. Нова організація отримала назву International Organization for Standardization (ISO). В даний час її членами є близько 100 країн.

Головною причиною появи єдиних стандартів стало бажання ініціаторів створення цієї організації усунути технічні бар'єри в торгівлі, які виникли унаслідок того, що в різних країнах для одних і тих же технологій і товарів діяли різнорідні стандарти. Сьогодні стандартами ISO "перекрито" багато технологічних галузей – від програмування і телекомунікацій до банківської і фінансової сфери.

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

Виконання технічної роботи в ISO покладене на 2700 технічних комітетів, підкомітетів і робочих груп, до складу яких входять представники урядових, промислових, науково-дослідних і юридичних кругів (всього біля 500 організацій). Кожна організація – член ISO – має право включити свого представника в будь-який комітет, в діяльності якого вона особливо зацікавлена.

Нові стандарти народжуються відповідно до трьох принципів.

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

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

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

Процес створення нового стандарту включає три етапи. Зазвичай ініціатива його розробки виходить від виробників, які доводять базові пропозиції стандарту до свого представника в ISO. Якщо ця організація визнає доцільність створення нового стандарту, то відповідна робоча група визначає технічну область, на яку передбачуваний стандарт розповсюджуватиметься. На другому етапі відбувається вироблення технічних специфікацій, в ході якого представники різних країн прагнуть досягти консенсусу. На завершальному етапі перша версія стандарту затверджується (за стандарт повинно проголосувати 75% кворуму) і публікується.

По мере совершенствования технологий, появления новых материалов, методов обработки, повышения требований к качеству и надежности изделий возникает необходимость в пересмотре стандартов. В ISO существует правило: все стандарты должны пересматриваться не реже чем раз в пять лет. Сегодня "перу" ISO принадлежит около 9300 различных стандартов, описание которых занимает 171000 страниц текста на английском языке.

Серія ISO 9000 (управління якістю) включає наступні стандарти:

• ISO 9000-1 (1994 р.). Управління якістю і гарантії якості. Частина 1. Керівництво по вибору і використанню.

• ISO 9000-2 (1993 р.). Управління якістю і гарантії якості. Частина 2. Загальне керівництво по застосуванню стандартів ISO 9001, ISO 9002 і ISO 9003.

• ISO 9000-3 (1991 р.). Управління якістю і гарантії якості. Частина 3. Керівництво по застосуванню стандарту ISO 9001 при розробці, установці і супроводі ПО.

• ISO 9000-4 (1993 р.). Управління якістю і гарантії якості. Частина 4. Керівництво по управлінню надійністю програм.

Основоположний стандарт ISO 9001 (1994 р.) задає модель системи якості для процесів проектування, розробки, виробництва, установки і обслуговування (продукту, системи, послуги).

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

По ISO якість – це сукупність властивостей і характеристик продукту, процесу або послуги, які забезпечують здатність задовольняти заявленим або таким, що маються на увазі потребам. Сучасні способи забезпечення якості базуються на підходах TQM (Total Quality Management). Це управління ресурсами і застосування кількісних методів аналізу для поліпшення: розробок, матеріалів і послуг, що поставляються в організацію; всіх процесів усередині організації; ступені задоволеності справжніх і майбутніх потреб клієнтів.

У моделі ISO 9000 лише згадуються вимоги, які повинні бути реалізовані, але не мовиться, як це можна зробити. Тому для побудови повноцінної системи якості по ISO окрім основної моделі ISO 9001 (1994 або 2000 року), необхідно використовувати допоміжні галузеві і рекомендаційні стандарти. Для організації, розробкою програмного забезпечення, що займається, такими стандартами є: ISO 9004-1:94 (ISO 9004:2000), ISO 8402:94 (ISO 9000:2000), ISO 9000-3:91, ISO 10007:95, ISO 10013:95, ISO 12207:95.

Сімейство стандартів ISO 9000 версій 2000 року розроблено з тим щоб подолати недоліки ISO 9000 версій 1994 року і допомогти організаціям всіх спеціалізацій, типів і розмірів упровадити і використовувати ефективні системи менеджменту якості.

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

У основу побудови системи якості відповідно до моделі ISO 9000:2000 закладаються наступні принципи:

• концентрація на потребах замовника;

• активна лідируюча роль керівництва;

• залучення виконавців до процесів вдосконалення;

• реалізація процессного підходу;

• системний підхід до управління;

• забезпечення безперервних поліпшень;

• ухвалення рішень на основі фактів;

• взаємовигідні відносини з постачальниками.

При цьому методично в повній відповідності з дисципліною побудови складних систем в стандарті ISO 9000:2000 передбачається, з одного боку, побудова організаційної системи "зверху — вниз": від цілей підприємства і його політики – до організаційної структури і формування бизнес-процессов, і з іншої – ітеративний розвиток організаційної системи через механізми вимірювання і поліпшення.

Впровадження системи менеджменту якості организацией–разработчиком програмних продуктів по ISO 9000 версій 2000 року складається з декількох етапів. У їх числі виділяються:

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

• застосування результатів вимірювань для визначення поточної ефективності процесів створення і впровадження продуктів;

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

• пошук можливостей по зниженню рисок і поліпшенню ефективності і продуктивності технологічних і інших процесів;

• виявлення і розстановка в порядку важливості тих поліпшень, які можуть давати оптимальні результати з прийнятними ризиками;

• планування стратегії, процесів і ресурсів для отримання ідентифікованих поліпшень продукції;

• контроль результатів поліпшень;

• порівняння отриманих результатів з очікуваними;

• визначення відповідних дій, що коректують.

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

Capability Maturity Model for Software (Модель SEI SW-CMM)

У 1982 році Міністерство оборони США утворило комісію, основним завданням якої стало дослідження проблем, що виникають при розробці програмних продуктів в організаціях міністерства. В результаті діяльності комісії в грудні 1984 року був створений Інститут інженерів-розробників програмного забезпечення (Software Engineering Institute, SEI) на базі Університету Карнеги-меллона в Пітсбурге.

У 1986 році SEI і корпорація Mitre під керівництвом Уоттса Хамфрі (Watts Humphrey) приступили до розробки критеріїв оцінки зрілості технологічних процесів – Capability Maturity Model (CMM).

Далі події розвивалися в наступному порядку.

1987 р. SEI публікує: короткий опис структури CMM; методи оцінки процесів розробки ПО; методи оцінки зрілості процесів виробництва ПО; анкету для виявлення ступеня зрілості процесів (для проведення самостійного, внутрішнього аудиту і зовнішнього аудиту).

1991 р. Випуск версії CMM v1.0.

1992 р. Випуск версії CMM v1.1.

1997 р. Випуск чергової (вдосконаленою) версії CMM.

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов. Для этого предполагалось создать критерии оценки зрелости ключевых процессов компании-разработчика и определить набор действий, необходимых для их дальнейшего совершенствования. В итоге методология оказалась чрезвычайно полезной для большинства компаний, стремящихся качественно улучшить существующие процессы проектирования, разработки, тестирования программных средств и свести управление ими к понятным и легко реализуемым алгоритмам и технологиям, описанным в едином стандарте.

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

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

• відсутнє довготривале і проектне планування;

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

• методи і процедури не стандартизовані і не документовані;

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

• процес вироблення рішення відбувається стихійно, на межі мистецтва.

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

Основні ознаки зрілої організації:

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

• ці процедури постійно уточнюються і удосконалюються;

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

• актуалізовані зовнішні і створені внутрішні стандарти на ключові процеси і процедури;

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

• технологии незначительно меняются от проекта к проекту на основании стабильных и проверенных подходов и методик;

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

• активно апробовуються і упроваджуються нові технології, проводиться оцінка їх ефективності.

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

Кожен з рівнів, окрім першого, складається з декількох ключових областей процесу (Key Process Area), що містять цілі (Goal), зобов'язання по виконанню (Commitment to Perform), здійсненність виконання (Ability to Perform), виконувані дії (Activity Performed), їх вимірювання і аналіз (Measurement and Analysis) і перевірку впровадження (Verifying Implementation). Таким чином, СММ фактично є комплексом вимог до ключових параметрів ефективного стандартного процесу розробки ПО і способам його постійного поліпшення. Виконання цих вимог, кінець кінцем, збільшує вірогідність досягнення підприємством поставлених цілей в області якості.

Початковий рівень (Initial Level – Level 1).

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

Ключові області процесу цього рівня не зафіксовані.

Повторюваний рівень (Repeatable Level – Level 2).

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

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

Ключові області процесу розробки ПО цього рівня:

• Управління вимогами (Requirements management).

• Планування проекту розробки ПО (Software project planning).

• Відстежування ходу проекту і контроль (Software project tracking and oversight).

• Управління субпідрядниками розробки ПО (Software subcontract management).

• Забезпечення упевненості як розробка ПО (Software quality assurance).

• Управління конфігурацією продукту (Software configuration management).

Певний рівень (Defined Level – Level 3).

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

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

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

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

Ключові області процесу розробки ПО цього рівня:

• Мета впорядковування роботи організації (Organization Process Focus).

• Визначення (стандартного) процесу організації (Organization Process Definition).

• Програма навчання (Training Program).

• Інтегроване управління розробкою ПО (Integrated Software Management).

• Технологія розробки програмних продуктів (Software Product Engineering).

• Міжгрупова координація (Intergroup Coordination).

• Експертні (сумісні) оцінки колег (Peer Reviews).

Керований рівень (Managed Level – Level 4).

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

Ключові області процесу розробки ПО цього рівня:

• Кількісне управління процесом (Quantitative Process Management).

• Управління якістю ПО (Software Quality Management).

Оптимізуючий рівень (Optimizing Level – Level 5).

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

Ключові області процесу розробки ПО цього рівня:

• Запобігання дефектам (Defect Prevention).

• Управління зміною технологій (Technology Change Management).

• Управління зміною процесу (Process Change Management).

СММ визначає наступний мінімальний набір вимог: реалізувати 18 ключових областей процесу розробки ПО, що містять 52 мету, 28 зобов'язань компанії, 70 можливостей виконання (гарантій компанії) і 150 ключових практик.

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

До переваг моделі SEI SW-CMM відноситься те, що вона орієнтована на організації, що займаються розробкою програмного забезпечення. У даній моделі вдалося детальніше пропрацювати вимоги, специфічні для процесів, пов'язаних з розробкою ПО. З цієї причини в SEI SW-CMM приведені не тільки вимоги до процесів організації, але і приклади реалізації таких вимог.

Основний же недолік SW-CMM полягає в тому, що модель не авторизована як стандарт ні міжнародними, ні національними органами по стандартизації. Втім, CMM давно вже стала промисловим стандартом де-факто.

До недоліків даної моделі необхідно віднести також великі зовнішні накладні витрати на приведення процесів компанії у відповідність моделі СММ, ніж до моделей ISO 9000. Це пов'язано з меншою поширеністю моделі в світі, меншою кількістю консалтингових органів і експертів і, в результаті, з набагато більшими зовнішніми витратами на консалтинг і на підтвердження відповідності процесів незалежною третьою стороною. Проте, CMM, поза сумнівом, корисно ISO 9000.

CASE-технологии

На протяжении всей истории программирования программные проекты все более и более усложнялись, объем работ стремительно увеличивался (особенно это проявилось в бизнес-приложениях), возникла потребность в таком универсальном средстве, которое могло бы помочь как-то структурировать, упорядочить и даже автоматизировать создание ПО. Проблема была глубже — необходимо было как-то объединить заказчиков, разработчиков, программистов, пользователей — причем в условиях постоянно меняющейся ситуации. А для того, чтобы о чем-то договориться, нужен какой-то общий язык. Традиционные языки программирования в силу малой наглядности, избыточности и многословия для этой роли не подходили, и, в конце концов, стали предприниматься попытки создания четкого графического языка. Реализации графических языков и методологии их использования способствовали появлению программно-технологических средств специального класса — CASE-средств. Аббревиатура CASE расшифровывается как Computer-Aided Software Engineering, т.е. разработка ПО с помощью компьютера.

Зобразимо вісь часу, як початкова точка візьмемо 1965 рік. Саме тоді почався період раннього впровадження комп'ютерів в бізнесі. У той час застосовувалися в основному мейнфрейми (mainframes) — великі ЕОМ колективного користування.

З 1970 по 1990 рік мейнфрейми домінували на ринку. Мейнфрейм у той час – це, перш за все, IBM 360/370. Всі дані зберігалися і оброблялися на одній дуже великій ЕОМ, користувачі працювали за екранами терміналів, які могли тільки відображати інформацію, але ніякої обробки не проводили. У СРСР скопіювали мейнфрейми під ім'ям ЄС ЕОМ. Були клони IBM 360/370 в Англії, ФРН і Японії.

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

В середині 1990-х починається адаптація Internet-систем, які домінують з середини 2000-го року. Зараз починають з'являтися нові системи, яким раніше не було аналогів; їх прийнято називати "не ПК" (un-PC). У їх число можна включити мобільні телефони, кишенькові комп'ютери, системи управління автомобілем (наприклад, вартість програмного забезпечення автомобіля Ford вже перевищує вартість заліза, з якого він зроблений) і багато що інше.

Характерний, що з розвитком комп'ютерних технологій вони стають дешевшими, а самі комп'ютери – доступнішими (особливо це виявилося в 1980-90-і рр.); як наслідок, створюється більше систем на базі кожної конкретної технології.

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

Подивимося на еволюцію підходу до проектування систем.

Розвиток методології проектування

З середини 1960-х до середини 1970-х років програми переважно писалися за принципом RYO (Roll Your Own), тобто кожен писав так, як хотів і як умів — не було певних підходів до процесу розробки ПО. В середині 70-х років минулого сторіччя виникла ідея структурного програмування (SDM, Structure Design Methodology), відбувається розвиток методології програмування і технології моделювання. У Європі головним ідеологом структурного програмування вважається Дейкстра, а в США – Демарко. Розробники приходять до розуміння, що систему (програму) можна описувати без використання конструкцій мови програмування, а на абстрактнішому рівні. У цей період часу програмісти (і не тільки) зрозуміли, що моделювання грає важливу роль, а разом з ним і правила для моделювання. До цього моменту відноситься і введення блок-схем (flow charts). Для цього етапу розвитку технології моделювання характерний, що центром програмного продукту є процес, а не дані (для зберігання даних використовувалися індексні файли і ієрархічні бази даних).

В середині 1980-х років відбувається черговий прорив: з'являються реляційні бази даних, один з авторів яких — James Martin. Головною частиною програмного продукту стають дані і бази даних. Теоретиками була створена реляційна алгебра, що стала основою для побудови реляційних баз даних. Звідси і новий підхід до моделювання систем — IE (Information Engineering — методи і засоби проектування прикладних і інформаційних програм), в яких за основу беруться не процеси, а структури оброблюваних даних.

С появлением персональных компьютеров на уровне систем клиент-сервер развивается графический интерфейс (GUI, Graphic User Interface). В связи с этим рождается объектно-ориентированный подход к проектированию (ОО), объединивший в одной сущности программу и данные.

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

Головні складові CASE-продукта такі:

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

• графічні редактори (Graphic Editors), які допомагають малювати діаграми; виникли з розповсюдженням РС і GUI. Цими двома складовими (так звані upper case технології) CASE-технологии спочатку і були обмежені. Діаграми почало легко малювати, їх з'явилася множина, але користі від них було мало – проектування було розвинене лише на рівні малювання. Існували багато проблем: ніхто не знав всі використовувані в той момент технології (не міг писати і для мейнфреймів, і для клієнта, і для сервера); неясно було, як об'єднувати написане для різних платформ.

• генератор: за графічним уявленням моделі можна згенерувати початковий код для різних платформ (так звана low case частина CASE-технологии). Генерація програм дозволяє автоматично побудувати до 85-90% об'єктного коду або текстів на мовах високого рівня, але тільки для частин програми, що добре формалізуються (перш за все, для опису баз даних і для завдання форм введення-виводу інформації). Складна обробка, як завжди, може бути описана за допомогою ручного програмування.

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

Приклади CASE-средств

Если сначала диаграммы рисовались вручную, то в середине 1980-х годов появляются первые продукты, реализующие CASE-технологию. Компания TI (Texas Instruments) выпускает продукт IEF (Information Engineering Facility), компания KW (Knowledge Ware) создает ADW. Целевыми платформами обоих продуктов были только мэйнфреймы,что являлось их основным недостатком. В 1986 году начинаются разработки продукта HPS (High Productivity System), а в 1990 году образуется компания SEER, которая выпускает HPS на рынок. В 1992-1993гг. по заказу этой компании мы полностью переписали HPS, сохранив их замечательные бизнес-идеи.

Технології виявилися затребуваними на ринку: на 1995 рік об'єми продажів IEF дорівнювали 200 млн. дол., ADW — 150 млн. дол., HPS — 120 млн. дол. У продукту HPS був вищий рівень генерації коду (lower case), але слабкіший рівень методології і графічних редакторів (upper case).

Роки	Організації	Тип систем
1965 — 1975	небагато	Ізольовані
1975 — 1985	багато	Ізольовані
1985 — 1995	багато	Enterprise level
1995 — 2000	багато	Department level
з 2000	багато	SOA

В середині 1980-х років ми також розробили технологію RTST, яка включала всі перераховані вище компоненти, зокрема генератор в Алгол 68. У чомусь ми навіть перевершили американців, оскільки вони уміли генерувати тільки екранні форми, бази даних і стандартні дії CRUD (create, read, update, delete), а ми на додаток до цього генерували і бізнес-логіку на основі SDL-диаграмм. Ця технологія до цих пір активно використовується при виробництві ПО телефонних станцій, але ні про які продажі в нашій країні піратського ПО ми і не думали.

Розглянемо таблицю, що характеризує основні рівні розвитку використання CASE-технологии в бізнесі:

До середини 1980-х років системи і проекти розростаються. Спочатку небагато організацій могли створювати могутні системи. Потім, з розповсюдженням мейнфреймів, кількість таких організацій збільшилася, але розробка систем як і раніше ніяк не координувалася. Для ранніх рівнів розвитку проектування характерна межа – ізольованість "острівців автоматизації" в "морі" організації (етап з 1965 по 1985 рр.). Пізніше, за допомогою IEF, ADW, HPS (на базі IE і CASE-технологий), переважаючим стає централізоване планування в рамках всієї організації (enterprise level). У той час проекти вимагали участі 500-1000 чоловік протягом 1-2 років.

В середині 1990-х років така "гігантоманія" визнається економічно недоцільною, розробка систем переходить на рівень department level, коли проектування і планування здійснюються в рамках одного відділу (департаменту); для цього потрібна робота 2-5 чоловік протягом одного-двух місяців. У цей момент були дуже популярні засоби швидкого прототипирования – Rapid Application Development (RAD), такі як Power Builder, FORTE, Sun Microsystems Powery.

Засоби швидкого прототипирования відсунули на другий план CASE-средства, але, у свою чергу, були задавлені агресивною політикою Microsoft. На якийсь час найпопулярнішою мовою став Visual Basic. Останнім часом спостерігається перехід до рівня SOA (Service-Oriented Architecture), заснованого на ОО-моделировании.

До 2000 року від графічної розробки моделей практично відмовилися і, як виявилось, дарма.

З 1998 року почала набирати силу технологія Rational Rose, заснована на об'єктно-орієнтованому підході і на графічних моделях, що послідовно уточнюються. Спочатку промисловому використанню такого підходу заважала різноманітність схожих, але таких, що розрізняються моделей. Заслугою фірми Rational можна вважати те, що вона зуміла об'єднати трьох класиків об'єктного проектування ("three amigos" Рембо, Золить і Якобсона), які створили універсальну мову ОО-моделирования UML, — Universal Modeling Language .

Технологія стала настільки успішною і популярною, що IBM купила фірму Rational Software більш ніж за 2 млрд. доларів і включила Rational Rose в свою лінійку продуктів.

Аналогічний шлях пройшла технологія компанії Together Soft, правда, значно скромніша по своїх можливостях. Їх купила Borland за 56 млн. доларів.

Що ж трапилося з першими CASE-технологиями?

У 1996 році відомий збирач застарілих засобів – компанія Sterling Software скуповувала майже всі CASE-средства, окрім HPS фірми SEER Technologies. Ідея бізнесу фірми Sterling Software зрозуміла – є сотні компаній, що використовують CASE-средства, куплені на початку 1990-х років. У США прийнято, що щорічний супровід ПО коштує до 20% його продажної ціни. Таким чином, "могильник" Sterling Software збирав величезні гроші тільки на супроводі, не ведучи ніяких нових розробок. Один раз вони захотіли розширити свій ринок і замовили нам конвертор Cobol Coolgen (нова назва, яку вони дали IEF). Ми-то, звичайно, всі зробили як треба, але, на наш погляд, компанія допустила стратегічну помилку: краще було б замовити нам конвертор Coolgen Cobol, оскільки більшість користувачів старих засобів хочуть звільнитися від залежності від них.

Врешті-решт, компанія Computer Associates купила Sterling Software, і вони замовили нам конвертор ADW Cobol, а потім і ще більше п'яти проектів по реинжинирингу ADW-проектов в Cobol.

Параллельно с этим два конкурента — SEER Technologies и Relativity Technologies — заказали нам конверторы HPS Cobol. С их стороны был определенный риск, что жизненно важная для бизнеса информация утечет через нас к конкурентам, но мы их, разумеется, не подвели, и сейчас на рынке активно продаются оба варианта.

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