ови її функціонування, склад людей і робіт, які забезпечують безперебійне функціонування системи;
В· терміни завершення окремих етапів, форма здачі робіт, ресурси, що залучаються в процесі розробки проекту, заходи по захисту інформації;
В· опис виконуваних системою функцій;
В· майбутні вимоги до системи в разі її розвитку, наприклад можливість роботи користувача з системою за допомогою Інтернету тощо;
В· сутності, необхідні для виконання функцій системи;
В· інтерфейси і розподіл функцій між людиною і системою;
В· вимоги до програмних та інформаційних компонентів ПЗ, вимоги до СУБД (якщо проект передбачається реалізовувати для декількох СУБД, то вимоги до кожної з них, або загальні вимоги до абстрактної СУБД і список рекомендованих для даного проекту СУБД, які задовольняють заданим умовам);
В· що не буде реалізована в рамках проекту.
Виконана на даному етапі робота дозволяє відповісти на питання, чи варто продовжувати даний проект і які вимоги замовника можуть бути задоволені при тих чи інших умовах. Може виявитися, що проект продовжувати не має сенсу, наприклад через те, що ті чи інші вимоги не можуть бути задоволені з якихось об'єктивних причин. Якщо приймається рішення про продовження проекту, то для проведення наступного етапу аналізу вже є уявлення про обсяг проекту і кошторис витрат.
Етап аналізу передбачає докладне дослідження бізнес-процесів (функцій, визначених на етапі вибору стратегії) та інформації, необхідної для їх виконання (сутностей, їх атрибутів і зв'язків (відносин)). На цьому етапі створюється інформаційна модель, а на наступному за ним етапі проектування - модель даних.
Вся інформація про систему, зібрана на етапі визначення стратегії, формалізується і уточнюється на етапі аналізу.
Аналітики збирають і фіксують інформацію у двох взаємопов'язаних формах:
В· функції - Інформація про події та процеси, які відбуваються в бізнесі;
В· сутності - Інформація про речі, що мають значення для організації і про яких щось відомо.
Двома класичними результатами аналізу є:
В· ієрархія функцій, яка розбиває процес обробки на складові частини (що робиться і з чого це складається);
В· модель В«Сутність-зв'язокВ» (Entry Relationship model, ER-модель), яка описує сутності, їх атрибути і зв'язки (відношення) між ними.
Три найбільш часто вживані методології структурного аналізу це:
В· діаграми В«Сутність-зв'язокВ» (Entity-Relationship Diagrams, ERD), які служать для формалізації інформації про сутності та їх відносинах;
В· діаграми потоків даних (Data Flow Diagrams, DFD), які служать для формалізації подання функцій системи;
В· діаграми переходів станів (State Transition Diagrams, STD), які відображають поведінку системи, залежне від часу; діаграми життєвих циклів сутностей відносяться саме до цього класу діаграм.
На етапі аналізу залучаються групи тестування, наприклад для отримання порівняльних характеристик передбачуваних до використання апаратних платформ, операційних систем, СУБД, іншого оточення. Крім того, на даному етапі визначається план робіт із забезпечення надійності інформаційної системи та її тестування.
На етапі проектування формується модель даних. Проектувальники в якості вихідної інформації отримують результати аналізу. Кінцевим продуктом етапу проектування є:
В· схема бази даних (на підставі ER-моделі, розробленої на етапі аналізу);
В· набір специфікацій модулів системи (вони будуються на базі моделей функцій).
Для проектування і реалізації необхідні апаратні ресурси та спеціальне програмне забезпечення. Крім того, потрібно механізм, що дозволяє контролювати створювану документацію і код. Ці питання краще вирішувати на ранніх стадіях проектування, а не на стадії розробки.
На етапі аналізу вже розроблено перелік функцій, які будуть реалізовані. На етапі проектування цей перелік ще раз аналізується і коректується. Однозначна відповідність між функцією і модулем навряд чи можливо. Справа в тому, що на етапі аналізу функції організовані за бізнес-категоріями, а на етапі проектування їх доведеться реорганізовувати для спрощення розробки. Проектувальники можуть прийняти рішення об'єднати кілька функцій, що володіють загальними властивостями, або виділити якесь загальна властивість (або їх набір) у окремий модуль, а також розбити складну функцію на кілька модулів.
При проектуванні модулів визначають розмітку меню, вид вікон, гарячі клавіші і пов'язані з ними виклики. Існують два види переміщення за програмами:
В· з контекстом, коли цільова екранна форма частково або повністю заповнюється автоматично даними, пов'язаними з тими, що знаходяться у вихідній екранної формі;
В· без контексту, коли цільова екранна форма не заповнюється зовсім або частково заповнюється автоматично даними, не пов'язани...
