Розділ «2. СУТНІСТЬ ІНФОРМАЦІЙНИХ СИСТЕМ В УПРАВЛІННІ ОРГАНІЗАЦІЄЮ»

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

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

Результатом етапу повинна бути модель вимог до системи (іншими словами – системний проект), що визначає:

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

2) інтерфейси і поділ функцій між людиною і системою;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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