Інформаційні системи в міжнародному бізнесі (1999)

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

Далі наведемо короткий опис робіт, що виконуються на кожній стадії.

Стадія 0. Оцінювання реалізованості. Стадія необов’язкова, оскільки передбачені на ній роботи виконуються, як правило, при розробці стратегії автоматизації. Якщо проект досить складний, то на цій стадії розробляють загальний задум і оцінюють витрати і очікуваний ефект з урахуванням наявних ресурсів.

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

Стадія 2. Вибір варіанта автоматизації. Мета — розробити кілька можливих варіантів побудови нової системи і вибрати з них найкращий. Вимоги, зафіксовані на попередній стадії, проектувальники розбивають на кілька перехресних множин залежно від їх важливості і з урахуванням їх змісту. Для кожної також групи складають короткий опис варіанта побудови нової системи і дають якісну, а якщо можливо, і кількісну оцінку його вартості та ефективності. Наприклад, в одну групу можуть бути включені лише вимоги з найвищим пріоритетом, а в іншу — всі виявлені вимоги. Першій з них відповідає найдешевший варіант системи, що забезпечує реалізацію мінімального набору функцій, а другій — найдорожчий варіант з найбільш повними функціональними можливостями. Ці два варіанти утворюють кордони, в межах яких слід з урахуванням обмежень на виділені ресурси шукати компромісне рішення. Для цього складають і оцінюють ще кілька проміжних варіантів, а для остаточного розгляду відбирають два-три найбільш прийнятних, для яких складають більш детальний опис і оцінки. Ці варіанти пред’являють замовникові і представникам майбутніх користувачів, які серед найкращих вибирають кінцевий варіант.

Стадія 3. Розробка технічного завдання. Мета — складання досить повного формалізованого опису вимог до майбутньої системи згідно з варіантом, обраним на попередній стадії. На цій стадії розробляються формалізовані описи функціонального, предметного і динамічного аспектів концептуальної частини майбутньої АС. Одночасно формалізують вимоги до інтерфейсу користувача і розробляють його демонстраційний прототип, призначений для того, щоб оцінити, наскільки відповідають вимогам користувачів форми вхідної та вихідної інформації і структура діалогової взаємодії. Остаточно погоджені формалізовані вимоги збирають у комплект документів — технічне завдання. Основну його частину складають логічна модель даних (ЛМД), моделі функціональних задач (МФЗ), а також результати прототипування, що відображають найважливіші вимоги до інтерфейсу.

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

Стадія 5. Розробка логічного проекту. Мета — спроектувати комплекс програмних засобів на логічному рівні, тобто на незалежному від середовища реалізації. Ці проектні роботи виконуються одночасно зі стадією 4. На основі технічного завдання спочатку розробляють логіку діалогової взаємодії. Потім проектують алгоритми задач обробки даних, а також інформаційних задач. При цьому, якщо необхідно, уточнюють каталог вимог і логічну модель даних. Розроблені проектні документи погоджують між собою і об’єднують разом з ЛМД у логічний проект.

Стадія 6. Фізичне проектування. Мета — згенерувати роботоздатний фізичний опис даних у вибраному середовищі реалізації і розробити завдання на створення програмних компонентів майбутньої АС. На базі існуючої логічної моделі даних розробляють первісний варіант її фізичного зображення і оцінюють його роботоздатність. У разі потреби, з метою прискорення доступу до деяких груп даних, доопрацьовують ЛМД, зокрема, добавивши класи індексних інформаційних об’єктів. У логічні постановки задач вносять елементи, які залежать від специфіки середовища реалізації, наприклад опису даних на вибраній мові програмування. При цьому уточнюють раніше отримані оцінки потрібної пам’яті та швидкодії обчислювальних засобів, і в разі потреби вносять корективи в проект. На закінчення уточнюють деталі реалізації інтерфейсу користувача і відображають їх у завданнях на програмування. Розроблені постановки задач збирають у єдиний пакет — фізичний проект.

Отже, основним продуктом, створеним з використанням технології SSADM, є комплект документів, на основі яких розроблювана АС може бути реалізована на обчислювальному пристрої з використанням системи програмування і СУБД, вибраних на стадії 4.