1.1. ПРОБЛЕМАТИКА АВТОМАТИЗАЦІЇ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

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

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

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

Етап 2. Методи програмної інженерії

Однією із незмінних тенденцій розвитку ІС є постійне їх ускладнення. Передусім це зумовлене характеристиками об’єктів автоматизації, які мають:

— структурну складність (багаторівнева ієрархічна структура) і територіальну розпорошеність;

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

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

— складну динаміку поведінки, зумовлену високим рівнем мінливості зовнішнього і внутрішнього середовища.

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

— відсутність цілісного уявлення про майбутню систему на перших етапах проектування, що потенційно спричиняє необхідність процедур перепроектування на стадіях упровадження та експлуатації ІС;

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

Необхідність розв’язання цих проблем, а також підвищення продуктивності розробки зумовило появу наприкінці 70х — початку 80х рр. методів програмної інженерії, зокрема формальних. Більшість із цих методів було спрямовано на окремі етапи життєвого циклу на основі різних точок зору стосовно кінцевої мети ІС.

Нині методи програмної інженерії поділяють на три категорії:

— евристичні методи, що включають неформалізовані підходи. Це структурні, зорієнтовані на дані, об’єктноорієнтовані та зорієнтовані на область застосування методи;

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

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

Ці три категорії не є ізольованими, вони поєднуються в конкретних методологіях та підходах до розробки ІС. За реалізованими принципами декомпозиції розрізняють два підходи:

— структурний — алгоритмічна декомпозиція, ґрунтована на впорядкуванні подій/потоків даних;

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

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

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

Етап 3. CASEтехнології

Неавтоматизоване (ручне) проектування ІС породжує низку проблем, пов’язаних із якістю власне розробки та із якістю проектної документації на систему:

— суттєве перевищення бюджету проекту;

— запізнення реалізації;

— неадекватна специфікація вимог;

— складність виявлення помилок у проектних рішеннях;

— неадекватне виконання і низький рівень надійності;

— неузгодженість структурних частин системи (підсистем, задач, файлів, баз даних);

— проблематичність підтримки в майбутньому;

— висока вартість, трудомісткість і ризикованість модифікації;

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

Так, за даними американських дослідників («Chaos Report», підготовлений Standish Group), у 1980ті роки лише 14 % проектів зі створення ПЗ (програмного забезпечення) було завершено успішно — своєчасно, в рамках бюджету, з реалізацією потрібних функціональних характеристик і задоволенням вимог замовника. За даними аналогічного звіту, опублікованого у квітні 2009 року («CHAOS Summary 2009») успішними виявилися 32 % проектів, 44 % проектів зіткнулися з певними труднощами (запізнення реалізації, перевищення бюджету тощо), а 24 % стали провальними — їх реалізацію припинили до отримання кінцевого результату або проект був завершений, але його результати ніколи не використовувалися.

Названі проблеми набули особливої актуальності, адже сучасні проекти ІС вимагають сотень людиногодин праці висококваліфікованих спеціалістів і, відповідно, великого бюджету.

Необхідність розв’язання вказаних проблем зумовила, а поширення персональних комп’ютерів у середині 1980х років уможливило появу спеціалізованих програмнотехнологічних засобів — CASEсистем, які реалізують CASEтехнології створення і супроводження ІС.

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

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

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

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

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

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

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

— незримість, відсутність чіткої фізичної структури;

— відсутність точних систем вимірювання якості;

— більша заплутаність ПЗ порівняно з технічним забезпеченням;

— необхідність внесення змін та їх вибухоподібні наслідки;

— взаємозв’язок даних і логіки.

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

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

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

У цьому значенні поняття CASEсистеми наближається до понять середовища програмування (programming environment) чи середовища розробки програм (software development environment) — системи програмних засобів, що використовуються програмістами для розробки ПЗ. В акронімі CASE літеру Е іноді навіть розшифровують як «environment» — середовище.

Зазвичай середовище розробки включає текстовий редактор, компілятор та/або інтерпретатор, засоби автоматизації складання та відладчик. Іноді в системі також присутні засоби інтеграції з системами керування версіями і різноманітні інструменти для спрощення конструювання графічного інтерфейсу користувача. Багато сучасних середовищ розробки також містять браузер класів, інспектор об’єктів і діаграму ієрархії класів для використання під час об’ єктноорієнтованого розроблення ПЗ. Хоча існують середовища розробки, призначені для кількох мов (Eclipse, Microsoft Visual Studio), зазвичай орієнтація здійснюється на певну мову, наприклад Visual Basic. Окремим випадком середовищ є візуальні середовища розробки, які вможливлюють візуальне редагування інтерфейсу програми.

Спільна тенденція розвитку CASEсистем і середовищ розробки програм (нині їх ще називають фабриками програм, software factory, див. п. 4.4.3) полягає в намаганні охопити якомога більшу кількість етапів життєвого циклу програм і підсилити інтеграцію різнорідних засобів, що підтримують різні види робіт.

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

— розроблення ІС, зокрема проектування, є творчим процесом, тоді як CASEзасоби автоматизують лише рутинні операції;

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