Поясніть зміст поняття „системне проектування”. Наведіть приклади методів системного проектування. Охарактеризуйте класичні моделі циклу життя інформаційної системи. Виконайте порівняльну характеристику водоспадної та спіральної моделі.

Системне проектування — це організаційна дисципліна, при­значена для проектування інформаційних систем (ІС), що вико­ристовує певний набір засобів проектування.

Системне проектування застосовується до найрізноманітніших класів систем, як загальноуправлінські ІС (MIS — management infor­mation system, EIS — executive information system, DSS — Decision Support System), спеціалізовані за галузями ІС (банківські, управлін­ня дискретним та неперервним виробництвом, системи управління готельним господарством та ін.), спеціалізовані за функціями ІС, (управління роботою складу, система маркетингових досліджень, аналітичні системи), універсальні ІС (електронний архів, корпора­тивна система управління процесом виконання офісних робіт, сис­тема статистичних розрахунків) та ін.

Для проектування спеціалізованої ІС або адаптації універсальної ІС до вимог і потреб конкретного замовника застосовується бага­то в чому спільний набір засобів і технологій. Цей набір разом з програмними засобами, що їх підтримують, називають «Майстернею Інформаційних Технологій» (IT Workshop).

Тенденції розвитку сучасних інформаційних технологій призво­дять до постійного зростання складності інформаційних систем (ІС), створюваних у різноманітних галузях економіки.

• Сучасні великі проек­ти ІС характеризуються, як правило, наступними особливостями:

• складність описання (достатньо велика кількість функцій, процесів,

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

• наявність сукупності тісно взаємодіючих компонентів (підсистем), що мають свої локальні задачі і цілі функціонування (наприклад, традиційних застосувань, пов'язаних з опрацюванням трансакцій і вирішенням регламентних задач, і застосувань аналітичного опра­цювання (підтримки прийняття рішень), що використовують нерег-ламентовані запити до даних великого обсягу);

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

• функціонування в неоднорідному середовищі на декількох апаратних

• платформах;

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

• зрослий динамізм та постійний потік змін в сучасних ІС.

Для успішної реалізації проекту об'єкт проектування (ІС) повин­ний бути, насамперед, адекватно описаний, побудовані повні і несу-перечливі функціональні й інформаційні моделі ІС. Накопичений дотепер досвід проектування ІС показує, що це логічно складна, трудомістка і тривала за часом робота, яка потребує високої квалі­фікації спеціалістів, що беруть у ній участь. Проте, донедавна проек­тування ІС виконувалося в основному на інтуїтивному рівні з засто­суванням неформалізованих методів, що ґрунтуються на мистецтві, практичному досвіді, експертних оцінюваннях і вартісних експери­ментальних перевірках якості функціонування ІС. Крім того, у про­цесі створення і функціонування ІС інформаційні потреби користу­вачів змінюються або уточнюються, що ще більш ускладнює розробку і супровід таких систем.

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

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

Ручне розроб­лення звичайно породжувало такі проблеми:

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

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

• низька якість документації, що зменшує експлуатаційні якості;

• затяжний цикл і незадовільні результати тестування.

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

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

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

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

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

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

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

На сьогоднішній день CASE-технологія є основною технологією проектування та реінженерії ІС, а широке її запровадження почалося значно раніше. Відповідно до огляду передових технологій (Survey of Advanced Technology), складеному фірмою Systems Development Inc. у 1996 p. за результатами анкетування більш ніж 1000 американсь­ких фірм, CASE-технологія вже тоді потрапила в розряд найстабіль-ніших інформаційних технологій (її використовувала половина всіх опитаних користувачів більш ніж у третині своїх проектів, із них 85% завершилися успішно).

Проте, незважаючи на наведені дані, слід враховувати наступне:

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

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

Успішне впровадження CASE-засобів забезпечує:

високий рівень технологічної підтримки процесів розроблення і супро­воду ІС;

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

прийнятний рівень віддачі від інвестицій у CASE-засоби.

Класичні схеми проектування інформаційних систем

Проектування ІС для достатньо стабільних умов (що припускалося в 70-і і в першій половині 80-х років) вважається класичним. Представницькість відповідних технологій, орієнтація на наймасовішу частину ІС, наявність не лише теоретичних підстав, але і промисло­вих методик та стандартів, використання цих методик протягом де­сятиріч — саме це дозволяє називати ці засоби класичними. Засоби проектування таких ІС в 80-х роках були добре описані в літературі різних напрямків: методичних монографіях, стандартах (ANSI, ISO, ГОСТ-и), підручниках. Відповідна організація робіт рекомендувала­ся офіційно і широко застосовувалася в багатьох галузях.

Головна різниця між класичними технологіями стосується орга­нізації циклу життя ІС.

Під моделлю циклу життя (ЦЖ) ІС розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і задач, виконуваних протягом ЦЖ ІС. Модель ЦЖ залежить від специфіки ІС і специфіки умов, у яких остання створюється і функціонує.

Найбільше поширення одержали такі дві основні моделі цж:

водоспадна модель та її модифікації (70-85 pp.); спіральна модель (86-90 pp.).

1. Водоспадна модель організації робіт, її переваги та недоліки

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

Крім того, найрозумніше організовані методики та стандарти уни­кали жорстко однозначного «прив'язування» робіт до конкретних ста­дій. Разом з тим, при можливості неодноразового включення деякої роботи в загальну схему постійно виділялися наступні проектні стадії:

Ч «запуск» (proposal for the development, agreement, mobilization): органі­зація підстави для діяльності і запуск робіт: наказ та (або) договір на розробку інформаційної системи, завдання на виконання робіт;

Ч «обстеження» (feasibility stady, scope analysis, strategy stady and plan­ning, requirement definition) : передпроектне обстеження, загальний аналіз ситуації на підприємстві (фірмі), Розроблення загального об­ґрунтування доцільності створення ІС;

Ч «концепція, ТЗ» (strategy planning, analysis, requirement specification, function description): дослідження вимог підприємства і користува­чів, формування рекомендацій з розроблення ІС, Розроблення техніч­ного завдання (ТЗ) на проектування ІС загалом та часткових ТЗ (ЧТЗ) для підсистем;

Ч «ескізний проект» (detailed analysis, high level design): Розроблення архітектури майбутньої ІС в межах ескізного проекту ;

Ч дослідний варіант ІС (pilot-project, test development): Розроблення спрощеного варіанта, пілотного проекту майбутньої ІС;

Ч дослідне використання пілот-проекту ІС, Розроблення виправлень та доповнень до ТЗ (test, corrected requirement specification);

Ч «777» (detailed analysis and design, test development): Розроблення тех­нічного проекту ІС;

Ч «РП» (development, test, system implementation): Розроблення робочої документації проекту;

Ч «введення в дію» (deployment, put into operation): іншими словами — «впровадження» ІС .

* Одна з назв, що використовується для такої послідовної схе­ми організації робіт, це «водоспадна модель» (waterfall model). Основними укрупненими етапами послідовної (водоспадної, кас­кадної) схеми є: формулювання та аналіз вимог, проекту­вання, реалізація, впровадження, супровід.

Рис. 15.1. Ідеальна послідовність виконання етапів водоспадної моделі

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

Рис. 15.2. Фактичні пов'язання між елементами водоспадної моделі

Н

Рис. 15.3. Розподіл ресурсів за водоспадною моделлю

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