Проектування інформаційних систем завжди починається з визначення мети проекту. Основне завдання будь-якого успішного проекту полягає в тому, щоб на момент запуску системи і в Протягом усього часу її експлуатації можна було забезпечити:
необхідну функціональність системи та ступінь адаптації до мінливих умов її функціонування;
необхідну пропускну здатність системи;
необхідний час реакції системи на запит;
безвідмовну роботу системи в необхідному режимі, іншими словами - готовність і доступність системи для обробки запитів користувачів;
простоту експлуатації та підтримки системи;
необхідну безпеку.
Продуктивність є головним чинником, що визначає ефективність системи. Хороше проектне рішення служить основою високопродуктивної системи.
Проектування інформаційних систем охоплює три основні області:
проектування об'єктів даних, які будуть реалізовані в базі даних;
проектування програм, екранних форм, звітів, які будуть забезпечувати виконання запитів до даних;
облік конкретного середовища або технології, а саме: топології мережі, конфігурації апаратних засобів, використовуваної архітектури (файл-сервер або клієнт-сервер), паралельної обробки, розподіленої обробки даних і т.п.
У реальних умовах проектування - це пошук способу, який задовольняє вимогам функціональності системи засобами наявних технологій з урахуванням заданих обмежень.
До будь-якого проекту пред'являється ряд абсолютних вимог, наприклад максимальний час розробки проекту, максимальні грошові вкладення в проект і т.д. Одна зі складностей проектування полягає в тому, що воно не є такою структурованої завданням, як аналіз вимог до проекту або реалізація того чи іншого проектного рішення.
Вважається, що складну систему неможливо описати в принципі. Це, зокрема, стосується систем управління підприємством. Одним з основних аргументів є зміна умов функціонування системи, наприклад директивне зміну тих чи інших потоків інформації новим керівництвом. Ще один аргумент - обсяги технічного завдання, які для великого проекту можуть становити сотні сторінок, в той час як технічний проект може містити помилки. Виникає питання: а може, краще взагалі не проводити обстеження і не робити ніякого технічного проекту, а писати систему "з чистого аркуша" в надії на те, що станеться якесь чудесний збіг бажання замовника з тим, що написали програмісти, а також на те, що все це буде стабільно працювати?
Якщо розібратися, то чи так уже непередбачувано розвиток системи і чи дійсно отримати інформацію про неї неможливо? Ймовірно, уявлення про систему в цілому і про передбачувані (керівництвом) шляхи її розвитку можна отримати за допомогою семінарів. Після цього розбити складну систему на більш прості компоненти, спростити зв'язку між компонентами, передбачити незалежність компонентів і описати інтерфейси між ними (щоб зміна одного компонента автоматично не тягло за собою суттєвого зміни іншого компонента), а також можливості розширення системи і "заглушки" для нездійсненних в тій чи іншій версії системи функцій. Виходячи з подібних елементарних міркувань опис того, що передбачається реалізувати в інформаційній системі, вже не здається настільки нереальним. Можна дотримуватися класичних підходів до розробки інформаційних систем, один з яких - схема "Водоспаду" (рис.1) - описаний нижче. Коротко будуть розглянуті і деякі інші підходи до розробки інформаційних систем, де використання елементів, описаних у схемі "водоспаду", також припустимо. Якого підходу з описуваних нижче дотримуватися (і чи є сенс придумувати власний підхід) - в якійсь мірі справа смаку і обставин.
В
Рис.1. Cхема "водоспаду"
Життєвий цикл програмного забезпечення являє собою модель його створення і використання. Модель відображає його різні стани, починаючи з моменту виникнення необхідності в даному ПЗ і закінчуючи моментом його повного виходу з ужитку в усіх користувачів. Відомі наступні моделі життєвого циклу:
Каскадна модель. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.
Поетапна модель з проміжним контролем. Розробка ПЗ ведеться итерациями з циклами зворотного зв'язку між етапами. Міжетапні коригування дозволяють зменшити трудомісткість процесу розробки в порівнянні з каскадної моделлю; час життя кожного з етапів розтягується на весь період розробки.
Спіральна модель. Особливе увага приділяється початковим етапам розробки - виробленню стратегії, аналізу і проектуванню, де реалізованість тих чи інших технічних рішень перевіряється і обгрунтовується за допомогою створення прототипів (макетування). Кожен виток спіралі припускає створення якоїсь версії продукту або якого-небудь його компонента, при цьому уточнюються характеристики і цілі проекту, визначається його якість і плануються роботи наступного витка спіралі.
Нижче ми розглянемо деяк...
