Вимоги до програмних та інформаційних компонентів ПЧ, необхідні апаратні ресурси, вимоги до бази даних, фізичні характеристики компонент ПЧ, їхні інтерфейси.

Модель вимог повинна включати:

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

· специфікації операцій нижнього рівня;

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

· концептуальну інформаційну модель вимог;

· пакет звітів і документів з інформаційної моделі;

· архітектуру системи з прив’язкою до концептуальної інформаційної моделі;

· пропозиції щодо організації структури для підтримки системи.

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

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

· описати, «побачити» і скоригувати майбутню систему до того, як вона буде реалізована фізично;

· зменшити витрати на розробку і впровадження системи;

· оцінити розробку за часом і результатами;

· досягнути взаєморозуміння між усіма учасниками роботи (замовниками, користувачами, розробниками, програмістами);

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

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

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

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

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

2) Розробка технічного завдання.

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

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

· розробку вимог до технічних засобів;

· визначення вимог до програмних засобів;

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

· вимоги до етапів і термінів виконання робіт.

3) Проектування.

Етап проектування дає відповідь на питання: «Як (яким чином) система задовольнятиме вимоги, що ставляться до неї?. Завданням цього етапу є дослідження структури системи і логічних взаємозв’язків її елементів, причому тут не зачіпаються питання, по­в’язані з реалізацією на конкретній платформі. Проектування розглядається як ітераційний процес отримання логічної моделі системи разом зі строго сформульованими цілями, поставленими перед нею, а також написання специфікацій фізичної системи, що задовольняє ці вимоги. Цей етап звичайно поділяють на два підетапи:

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

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

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

4) Реалізація (програмування / адаптація).

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

5) Тестування і налагодження.

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

Встановлення коректності є головною метою етапу життєвого циклу, що розглядається. Треба зазначити, що етап тестування і налагодження — один із найбільш трудомістких, стомлюючих і непередбачуваних етапів розробки АІСУП. У середньому за розробки традиційними методами цей етап займає від 1/2 до 1/3 всього часу розробки. З іншого боку, тестування і налагодження являють собою серйозну проблему: у деяких випадках тестування і налагодження програми вимагають в декілька разів більше часу, ніж безпосередньо програмування.

Тестування — це набір процедур і дій, призначених для демонстрації коректної роботи АІСУП у заданих режимах і зовніш­ніх умовах. Мета тестування — виявити наявність помилок або переконливо продемонструвати їх відсутність, що можливо лише в окремих тривіальних випадках. Важливо розрізнювати тестування і супутнє поняття «налагодження». Налагодження — це набір процедур і дій, що починаються з виявлення самого факту наявності помилки і закінчуються встановленням точного місця, характеру цієї помилки і способів її усунення.

Найважливішим і найчастіше застосовуваним на практиці є метод детермінованого тестування. При цьому як еталони тестів використовуються конкретні початкові дані, що складаються з взаємопов’язаних вхідних і результуючих величин і правильних послідовностей їх опрацювання. У процесі тестування із заданими початковими величинами треба встановити відповідність результатів їх опрацювання еталонним величинам. Для складних систем потрібна велика кількість тестів, і виникає проблема оцінки їх необхідної кількості й використання методів їх скорочення. Тому тестування (як і будь-який інший вид діяльності) доцільно планувати. План тестування повинен містити:

· формулювання цілей тестування;

· критерії якості тестування, що дозволяють оцінити йогорезультати;

· стратегію проведення тестування, що забезпечує досягнення заданих критеріїв якості;

· потреби в ресурсах для досягнення заданого критерію якості за обраної стратегії.

l Автоматизація тестування і налагодження

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

6) Експлуатація і супроводження.

Основними завданнями етапу експлуатації і супроводження є такі:

· забезпечення стійкості роботи системи і збереження інформації — адміністрування;

· своєчасна модернізація і ремонт окремих елементів — техніч­на підтримка;

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

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

Особливу увагу на етапі експлуатації і супроводу потрібно приділити питанням навчання персоналу і, відповідно, плануванню інвестицій у цей процес.

2.3. Сучасні підходи до створення
інформаційних систем на підприємствах

Головна особливість індустрії АІСУП полягає в концентрації складності на початкових етапах ЖЦ (аналіз та проектування) за відносно невисокої складності та трудомісткості наступних етапів. Більш того, невирішені питання та помилки, що мали місце під час аналізу та проектування, породжують на подальших етапах важкі, часто нерозв’язні проблеми і, зрештою, можуть позбавити успіху.

Залежно від того, яким чином виконуються аналіз і проектування, прийнято виділяти такі методи створення АІСУП:

а) структурно-орієнтовані;

б) об’єктно-орієнтовані;

в) процесно-орієнтовані.

2.3.1. Структурно-орієнтований підхід

2.3.1.1. Структурні методи аналізу

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

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

2) обмежений контекст, що включає лише істотні на кожному рівні деталі;

3) використання суворих формальних правил запису;

4) послідовне наближення до кінцевого результату.

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

· Конструювання системи «чорних скриньок» істотно спрощується. Набагато легше розробити магнітофон або програвач, якщо не дбати про створення вбудованого підсилювального блоку.

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

· Є можливість простого реконфігурування системи «чорних скриньок». Якщо колонка несправна, то можна віддати їїв ремонтну майстерню і продовжувати слухати записи в монорежимі.

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

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

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

а) кожна «чорна скринька» має реалізовувати одну єдину функцію системи;

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

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

г) зв’язки між «чорними скриньками» мають бути якомога простішими для забезпечення незалежності між ними.

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

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

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

Для цілей структурного аналізу традиційно використовують тригрупи засобів, які показують:

· функції, що їх система повинна виконувати;

· відношення між даними;

· поведінку системи залежно від часу (аспекти реального часу).

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

1) DFD (Data Flow Diagrams) — діаграми потоків даних разом зі словниками даних і специфікаціями процесів (міні-специфікаціями);

2) ERD (Entity—Relationship Diagrams) — діаграми «суть—зв’язок»;