• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

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

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

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

У документі обов'язково мають бути описані:

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

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

Терміни завершення окремих етапів, форма здачі робіт, ресурси, залучені в процесі розробки проекту, заходи по захисту інформації;

Опис виконуваних системою функцій;

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

Суті, необхідні для виконання функцій системи;

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

Вимоги до програмних та інформаційних компонентів ПЗ, вимоги до СУБД (якщо проект передбачається реалізовувати для кількох СУБД, то вимоги до кожної з них, або загальні вимоги до абстрактної СУБД і список рекомендованих для даного проекту СУБД, які задовольняють заданим умовам);

Що не буде реалізовано в рамках проекту.

Виконана на даному етапі робота дозволяє відповісти на питання, чи варто продовжувати даний проект і які вимоги замовника можуть бути задоволені при тих чи інших умовах. Може виявитися, що проект продовжувати не має сенсу, наприклад через те, що ті або інші вимоги не можуть бути задоволені з якихось об'єктивних причин. Якщо приймається рішення про продовження проекту, то для проведення наступного етапу аналізу вже є подання про обсяг проекту і кошторис витрат.

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

Вся інформація про систему, зібрана на етапі визначення стратегії, формалізується і уточнюється на етапі аналізу.

Аналітики збирають і фіксують інформацію у двох взаємопов'язаних формах:

· Функції - інформація про події та процеси, які відбуваються в бізнесі;

· Сутності - інформація про речі, які мають значення для організації і про яких щось відомо.

Двома класичними результатами аналізу є:

· Ієрархія функцій, яка розбиває процес обробки на складові частини (що робиться і з чого це складається);

· Модель «сутність-зв'язок» (Entry Relationship model, ER-модель), яка описує сутності, їх атрибути і зв'язки (відношення) між ними.

Три найбільш часто застосовуються методології структурного аналізу це:

· Діаграми «сутність-зв'язок» (Entity-Relationship Diagrams, ERD), які служать для формалізації інформації про сутності та їхні стосунки;

· Діаграми потоків даних (Data Flow Diagrams, DFD), які служать для формалізації представлення функцій системи;

· Діаграми переходів станів (State Transition Diagrams, STD), які відображають поведінку системи, залежне від часу; діаграми життєвих циклів сутностей відносяться саме до цього класу діаграм.

На етапі аналізу залучаються групи тестування, наприклад для отримання порівняльних характеристик передбачаються для використання апаратних платформ, операційних систем, СУБД, іншого оточення. Крім того, на даному етапі визначається план робіт щодо забезпечення надійності інформаційної системи та її тестування.

На початкових етапах розробки ІС значну увагу приділяють тестуванню БД, яка розробляється паралельного з системою. Це дає можливість практично повністю покрити тестами весь функціонал системи, який містить в собі звернення до БД. Також це сприяє виявленню критичних місць в самій схемі БД, наприклад, невідповідність нормальним формам (тестування логічної схеми), громіздкі запити до БД, що значно сповільнюють роботу всієї системи або окремих її частин тощо. На даному етапі розвитку ІТ-індустрії дуже широко використовуються еволюційні підходи до розробки ПЗ, що часто називаються адаптивними. Ці методи також застосовуються і для розробки БД, коли схема розробляється не до початку розробки проекту ІС, а нарощується з часом, паралельно до розробки системи.

Переваги у застосуванні еволюційного підходу до розробки БД в наступному:

- Мінімізація невиправданих затрат;

- Попередження необхідності в суттєвих доробках;

- Постійна впевненість в наявності робочої системи;

- Постійна впевненість в тому, що існуючий на даний момент проект бази даних володіє найвищою якістю;

- Зменшення загальної трудомісткості.

Одним з підходів еволюційної розробки є метод створення тестів до початку розробки (Test-First Development – TFD). Цей метод передбачає підготовку тестів, невдале завершення яких буде вказувати на наявність помилок, ще до початку роботи по розробці основного функціоналу.Це тестування складається з декількох етапів, опис яких подано нижче:

1. Прискорене створення тестів з метою невдалого завершення тестування на момент створення через відсутність потрібного функціоналу.

2. Виконання підготовлених тестів для перевірки того, що новий тест закінчується провалом.

3. Оновлення функціоналу таким чином, щоб він проходив тест.

4. Повторення виконання всіх тестів. Якщо тест не проходить, то відбувається повернення до кроку 3, а в іншому випадку - до початку циклу.

Перевагами такого методу при тестуванні як системи в цілому, так і БД, яка є її частиною, в тому, що завжди можна бути впевненим в наявності тестів, за допомогою яких можна виконати перевірку якості виконаної роботи; а також вона дає впевненість в тому, що подальший розвиток системи можливий. В кінцевому випадку це тестування дає регресійний набір тестів для БД, який можна виконувати над неї при внесення будь-яких змін.

Значу увагу приділяють також тестуванню БД не лише на етапах розробки ІС, але і на етапах супроводу. Це пояснюється тим, що саме на етапі супроводу вже готового програмного продукту, виявляються критичні місця, які не були виявленими на етапах розробки та тестування, або ж замовник змінив вимоги до системи й хоче, щоб ці вимоги були реалізовані.

Цей процес внесення змін до БД на етапі супроводу отримав назву рефакторінг БД – внесення простих змін в схему БД, які покращують її проект, зберігаючи незмінною інформаційну та поведінкову семантику БД.

Для того, щоб можна було вносити зміни в існуючу ІС, або для додання нового функціонального засобу, потрібно мати можливість перевірити те, що після проведення потрібних змін всі програми продовжують успішно функціонувати. Іншими словами, потрібно передбачати можливість виконання в системі повного регресійного тестування. Якщо при цьому буде виявлено, що відбулось порушення в роботі якого-небудь компоненту, повинна існувати можливість усунути порушення, що виникло, або виконати відкочування змін. При цьому значну увагу потрібно приділяти тестуванню БД, адже важлива бізнес-логіка реалізується в БД в формі процедур, правил перевірки даних та правил цілісності посилань, і очевидно, що ця бізнес-логіка потребує детального тестування.

Впевненість в тому, що зміни, які були внесені в схему БД правильні, з’являється, якщо можливо легко переконатись, що база даних як і в минулому коректно працює із зовнішніми програмами після внесення змін. Потенційно, може виникнути потреба написання тестів, що виконують наступне:

- Перевірку схеми бази даних – повинні існувати тести, які розроблені для БД та які будуть давати можливість протестувати тригери, функції, обмеження цілісності, визначення представлень тощо.

- Перевірку зовнішніх програм доступу – повинні існувати тести, які дадуть можливість перевірити правильність функціонування програм після накладення змін на схему БД.

Для багатьох спеціалістів підхід, що передбачає тестування БД, є незвичним, тому їм доводиться стикатись з різними проблемами, серед яких:

• Недостатні навики тестування, які можна компенсувати завдяки сумісній роботі

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

• Недостатній асортимент компонентних тестів для БД, що пояснюється незначним поширенням підходу заснованого на тестуванні БД, а тому зростає ймовірність того, що тестовий набір для схеми буде недостатнім.

• Недостатній асортимент інструментальних засобів тестування БД.

Також дуже важливо, щоб на етапі супроводу ІС, зміни до схеми БД, що будуть вноситись, були невеликими. Тестувати такі зміни найпростіше, що дає можливість не лише швидко переходити до внесення наступних змін, але також і виявляти їх.

На етапі проектування формується модель даних. Проектувальники в якості вихідної інформації отримують результати аналізу. Кінцевим продуктом етапу проектування є:

Схема бази даних (на підставі ER-моделі, розробленої на етапі аналізу);

Набір специфікацій модулів системи (вони будуються на базі моделей функцій).

Для проектування і реалізації необхідні апаратні ресурси і спеціальне програмне забезпечення. Крім того, потрібно механізм, що дозволяє контролювати створювану документацію та код. Ці питання краще вирішувати на ранніх стадіях проектування, а не на стадії розробки.

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

При проектуванні модулів визначають розмітку меню, вид вікон, гарячі клавіші і пов'язані з ними виклики. Існують два види переміщення за програмами:

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

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

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

На етапі визначення специфікації модулів вирішуються такі завдання:

Перетворення функціональних визначень аналізу в реалізовані модулі;

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

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

Визначення послідовності реалізації модулів і залежностей модулів.

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

Коли генерація модуля завершена, виконують автономний тест, який переслідує дві основні мети:

Виявлення відмов модуля (жорстких збоїв);

Відповідність модуля специфікації (наявність всіх необхідних функцій, відсутність зайвих функцій).

Після того як автономний тест пройшов успішно, група згенерованих модулів проходить тести зв'язків, які повинні відстежити взаємний вплив модулів.

Далі група модулів тестується на надійність роботи, тобто проходять, по-перше, тести імітації відмов системи, а по-друге, тести напрацювання на відмову. Перша група тестів показує, наскільки добре система відновлюється після збоїв програмного забезпечення, відмов апаратного забезпечення. Друга група тестів визначає ступінь стійкості системи при штатній роботі і дозволяє оцінити час безвідмовної роботи системи. У комплект тестів стійкості повинні входити тести, що імітують пікове навантаження на систему.

Потім весь комплект модулів проходить системний тест - тест внутрішньої приймання продукту, що показує рівень його якості. Сюди входять тести функціональності і тести надійності системи.

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

Необхідність контролювати процес створення ІС, гарантувати досягнення цілей розробки і дотримання різних обмежень (бюджетних, тимчасових і ін) призвело до широкого використання в цій сфері методів і засобів програмної інженерії: структурного аналізу, об'єктно-орієнтованого моделювання, CASE-систем.

Читайте також:

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. II. Основні закономірності ходу і розгалуження судин великого і малого кіл кровообігу
3. III. Етапи розробки програмного забезпечення
4. VII. Етап проектування
5. VII. Етап проектування
6. А/. Форми здійснення народовладдя та види виборчих систем.
7. Автоматизація проектування напівзамовлених ВІС.
8. Адвокатура в Україні: основні завдання і функції
9. Амортизація основних засобів, основні методи амортизації
10. Артеріальний пульс, основні параметри
11. Асортиментний процес включає три основних етапи: концентрацію, кастомізацію і розсіювання.
12. Аудит захищеності інформаційних систем

Переглядів: 1193