Інформаційні системи і технології на підприємствах - Плескач В.Л. - 3.2. Автоматизація проектування ІС

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

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

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

3) побудову моделей діяльності організації, що передбачає обробку матеріалів обстеження;

4) побудову двох видів моделей:

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

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

o відмовостійкість;

o кількість клієнтів, що одночасно мають доступ до системи;

o вимоги безпеки;

o час очікування відповіді на звернення до системи;

o виконавські властивості системи (обмеження щодо ресурсів пам'яті, швидкість реакції на звернення до системи тощо).

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

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

3.2. Автоматизація проектування ІС

На етапі проектування ІС побажання замовників перетворюються у проектні рішення у формі певної системи програмування.

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

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

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

Методологія проектування передбачає наявність концепції, принципів проектування, засобів проектування. Метод проектування ПЗ - це організована сукупність процесів створення моделей, що описують різні аспекти ІС з використанням нотацій. Метод - це сукупність:

o концепцій і теоретичних основ (наприклад, структурний або об'єктно орієнтований підхід);

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

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

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

Методи реалізуються через конкретні технології і методики, стандарти й інструментальні засоби, що забезпечують виконання процесів ЖЦ ПЗ. Розрізняють методи оригінального проектування, коли створюється оригінальна ІС, та типового проектування, коли ІС компонується з готових типових рішень. Комбінація різних методів проектування зумовлює характер технології проектування ІС. Найвідоміші технології проектування ІС - це канонічна (ручна технологія індивідуального проектування) та індустріальна, що у свою чергу поділяється на автоматизовану (з використанням САSЕ-тех-нологій) і типову (модельно орієнтовану або параметрично орієнтовану).

Більшість існуючих САвЕ-засобів засновано на методах структурного або об'єктно орієнтованого аналізу і проектування, що використовує специфікації у вигляді діаграм або текс-

Перехід від моделі ^ияк є" до моделі "як має бути" може відбуватися двома способами:

1) удосконалюванням діючих технологій на основі оцінки їхньої ефективності;

2) радикальною зміною технологій і перепроектуванням бізнес-процесів.

Стадія проектування включає такі етапи:

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

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

Моделі ІС уточнюються і деталізуються до необхідного рівня. На кожній стадії проектування може виконуватися кілька процесів, що визначаються у стандарті ШО/ІЕС 12207. Кожна програма - це певний перетворювач, поведінку і властивості якого визначають у процесі створення системи так, щоб вирішити певну проблему.

Вимоги до програмної системи - це властивості, які слід мати системі для адекватного виконання своїх функцій.

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

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

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

o оператори, що обслуговують функціонування системи;

o розробники системи.

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

Джерела відомостей про вимоги:

o мета та завдання системи, як їх формулює замовник;

o діюча система або колектив, що виконує її функції;

o загальні знання щодо проблемної галузі замовника;

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

Методи збирання вимог:

o інтерв'ю з носіями інтересів замовника та операторами;

o спостереження за роботою діючої системи;

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

Множина зібраних вимог може бути розподілена між двома основними категоріями:

1) такі, що відображають можливості, які повинна забезпечити система, - функціональні;

2) такі, що відображають обмеження, пов'язані з функціонуванням системи, - нефункціональні.

Є кілька класів нефункціональних вимог, суттєвих для більшості ІС, які виражають обмеження, актуальні для багатьох проблемних галузей:

o вимоги конфіденційності;

Рис. 3.5. Контекст технологічної операції проектування

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

Сучасна технологія проектування ПЗ ІС має забезпечувати:

o відповідність стандартові ІБО/ІЕС 12207;

o гарантоване досягнення цілей розробки БС у межах бюджету з дотриманням якості й установленого часу;

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

o мінімальний час одержання працездатного ПЗ ІС;

o незалежність проектних рішень від засобів реалізації 1С (СУБД, операційних систем, мов і систем програмування);

o підтримка САSЕ-засобів, що забезпечують автоматизацію процесів, виконуваних на всіх стадіях ЖЦ.

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

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

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

в) вимоги до конфігурації робочих місць розробників, включаючи настроювання операційної системи та САSЕ-за-собів;

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

Стандарт оформлення проектної документації установлює:

а) комплектність, склад і структуру документації на всіх стадіях проектування;

б) вимоги до оформлення документації;

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

г) вимоги до засобів підготовки документації;

д) вимоги до настроювання САSЕ-засобів для забезпечення підготовки документації відповідно до встановлених правил.

Стандарт інтерфейсу користувача із системою регламентує:

а) правила оформлення екранних елементів і елементів управління;

б) правила використання клавіатури і миші;

в) правила оформлення текстів допомоги;

г) перелік стандартних повідомлень;

д) правила обробки реакції користувача.