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

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

Більш ефективним є шлях, коли при розробці систем чи їх частин враховується можливість їх використання для певних груп об’єктів: підрозділів, підприємств, галузей тощо. Такі проектні рішення можуть бути прийняті єдиними чи використовуватися як типові. Склад, галузь застосування чи інші характеристики можуть бути прийняті у вигляді відповідних стандартів підприємства, галузі, державних стандартів чи керівних методичних матеріалів. Такими стандартизованими типовими елементами є ЄСКК ТЕІ, ЄСКД, ЄСТД, створені уніфіковані системи планової, облікової, звітної, фінансової та іншої документації.

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

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

2) побудова єдиних схем обміну даними між системою і користувачами;

3) використання єдиних форм документів і повідомлень, які пристосовані для людей і ЕОМ;

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

Перші проектні рішення з’явилися в 1971–1975 рр. на основі тих можливостей і досягнень, які були на той час в області постановок і типізації задач і їх програмних модулів в умовах застосування ЕОМ другого покоління. При розробці ТПР створювалась проектна документація з усіх видів забезпечення, яка уможливлювала виконувати створення ІС методом агрегування її з оригінальною проектною документацією, що відбивала специфіку об’єкта. Потім були розроблені друге й третє покоління ТПР.

Усе це викладено в галузевих керівних методичних матеріалах по створенню АСУВ і її частин і в ряді монографій і підручників.

До ТПР висуваються такі вимоги:

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

допускати приріст системи за рахунок нових рішень, які стають типовими.

Такий підхід дістав назву методу елементного проектування.

Усі ТПР поділяються на 5 класів.

1. Спеціальне програмне забезпечення «Задача».

2. Загальне програмне забезпечення.

3. Техніка (за складом, розміщенням і порядком використання КТЗ).

4. Інформаційна база ( по інформаційній базі).

5. Посадові й технологічні інструкції «Персонал» (які регламен-тують дії посадових осіб органів управління при функціонуванні ІС).

ТПР класу «Задача» розроблюють для конкретних процесів управління об’єктом. Документація містить опис постановки задачі, алгоритм розв’язання, програмні модулі з їх описами та інструкціями по застосуванню. Кожне ТПР може будуватися за модульним принципом, де модулі можуть мати декілька варіантів рішення. Це забезпечує гнучкість ТПР, що дозволяє прив’язувати документацію до різних об’єктів після простого налагодження. ТПР можуть бути галузевими і міжгалузевими. ТПР прогресивно впливали і впливають на розвиток методів створення ІС. Ця технологія скорочує трудові затрати на створення проекту в середньому приблизно на 30 % (Евдокимов В.В., Рейнер В.А. Машинный синтез АСУП. – М.: Статистика, 1980. – 222 с.). Проте досвід показує, що з усіх компонентів системи, можливо, потрібно буде доробляти до 40 % документації.

Загальні недоліки типового (елементного) проектування такі:

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

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

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

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

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

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

7) відсутність засобів машинного ведення проектно-технологічної документації і координації розробників ІС;

8) типові конструктивні елементи (ТКЕ – основне ядро технології типового проектування), які використовуються при проектуванні програм, слабко інформаційно ув’язані;

9) не систематизовано номенклатуру параметрів, які використо-вуються для прив’язки ТКЕ;

10) прив’язка ТКЕ відповідає технології проектування «знизу –вгору» і базується на інтуїтивному підході до розробки програмного забезпечення.

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