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

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

VII. Етап проектування

Словник

Стиль

Документ з вимогами

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

Приклад такого документа:

Малюнок 5.7.1. Документ з вимогами.

Послідовність дій, застосованих до документа, повинна бути наступною:.

Якщо немає інформації, записати "не додається".

Повинна бути описана причина виконання кожної з вимог. Призначення проекту може залежати від вимог, нестача цієї специфікації може спричинити невдачу виконання.

Будь-який матеріал, що не ввійшов до секції, повинен бути доданий в "Додаток".

Часто до документа додаються:

· Вимоги апаратного і програмного забезпечення,

· Модель системи (архітектура),

· Словник (термінологія, акроніми, абревіатури),

· Зміст.

Якість документа з вимогами

Найбільш важливі чинники для якісних вимог:

· Ясність: однозначне формулювання, ясне для користувача і розробника,

· Структура документа,

· Відповідність: ніяких протиріч у формуванні вимог,

· Змінність: формулювання по ключових моментах.

Гнучкість

· Можливість додавання нових вимог.

Специфікація ролей

· Можливість пов'язати особу з вимогою, описувати дію вимоги.

Помірність

· Паперовий або електронний варіант,

· Контроль версії документа.

Не може бути незрозумілих термінів для якої-небудь із сторін.

Всі специфічні треміни повинні бути додані в словник.

Всі невизначеності повинно бути уточнено. Приклад:

Малюнок 5.7.2. Словник.

7. Чинники успіху

Ключові чинники успіху етапу формулювання вимог:

· Надання лієнту зразків для усунення неясності,

· повна ідентифікація вимог, виявлення специфічних і виняткових вимог. ,

· завершеність і перевірка змісту,

· формулювання нефункціональних вимог в певній формі.

8. Короткий звіт

Етап формулювання вимог дуже важливий в процесі розробки ПЗ. Помилки на цьому етапі складно виправити, що робить цей етап дорогим. Помилковий або неузгоджений опис вимоги може викликати невдачу або стати причиною не прийняття продукту.

Тому краще сформулювати вимоги ясно, скласти документ, що задовольняє обидві сторони.

VI. Розробка моделі

1. Потреба в розробці моделі

Модель - це представлення концепції якоїсь реальності. Розум людини завжди займався розробкою моделей, будь то математичні моделі, фізичні, моделі машин, будинків і т.д.

Яка мета розробки моделі?

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

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

· модель вимог - описується, наприклад, випадками використання,

· аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

· модель дизайну - описується мовою UML більш деталізовано. Наприклад, присутні фізичні діаграми.

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

2. Аналітична модель

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

Наступний етап - етап дизайну. Він відповідає на питання, як система повинна реалізовуватися і описує цю реалізацію.

Границі аналітичної моделі

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

Ось декілька причин проектування більшої моделі:

· Імпортування в модель елементів із зовнішніх систем робить систему більш загальною і всеосяжною,

· Протягом розробки ми можемо все ще не знати, які готові елементи будуть включені у фінальну версію продукту, а які будуть написані уручну,

· Бюджет може не дозволити повного проектування системи "з нуля", і визначення способів розробки буде проведено під час аналізу.

Мета розробки аналітичної моделі

Хороша аналітична модель повинна мати наступні характеристики:

· вона повинна бути спрощеним описом системи,

· функції повинні бути представлені ієрархічно,

· логічна модель повинна слідувати певним правилам,

· модель повинна будуватися за допомогою добре відомих методів і інструментів,

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

Модель ПЗ повинна бути спрощеним описом, який представляє найважливіші особливості ПЗ на високому абстрактному рівні.

Логічна модель:

· показує, що повинна робити система,

· показує ієрархію системи,

· уникає термінології реалізації,

· дозволяє ухвалювати рішення "від причини до наслідків" і назад.

Записи, що робляться на етапі аналізу

У аналітичному спорудженні моделі найчастіше роблять такі записи:

· звичайна мова,

· графічні записи,

· специфікація - структурований текстовий і числовий опис.

Графічні записи дуже важливі в спорудженні аналітичної моделі. Розробка ПЗ використовує і інші способи запису, наприклад, методи з електроніки і механіки. Психологічний аналіз показує важливість використання графічного запису.

Функції запису:

· інструмент аналітика і дизайнера,

· зв'язок з користувачем,

· зв'язок з іншими членами команди,

· основа для реалізації ПЗ,

· опис технічної документації.

Запис повинен бути простий, зрозумілий, конкретний, легкий для розуміння, дозволяючи моделювати складні зв'язки.

3. Дії на етапі аналізу

Основними діями на етапі аналізу є:

· визначення, пояснення, моделювання, специфікація і документування частин і проблем проекту,

· визначення контексту проекту,

· визначення вимог користувача,

· визначення організаційних вимог,

· інші рішення, наприклад, апаратні настройки, настройки ПЗ, фінансові обмеження, обмеження часу і т.п.

Сам аналіз не повинен робити якісь зміни, наприклад, введення таких нових елементів, як комп'ютерні системи. Мета аналізу - ідентифікувати всі аспекти, які можуть вплинути на форму, організацію і результати проекту.

Основними діями в під час аналізу є:

· розробка статичних моделей класів,

· аналіз функцій і випадків застосування,

· перевірка класів і об'єктів,

· розпізнавання і визначення методів і повідомлень,

· моделі станів і діаграми їх змін,

· моделі процесів і діаграми потоків даних,

· управління потоком.

4. Функціональна декомпозиція

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

· функції повинні мати унікальні визначені цілі,

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

· інтерфейси повинні бути мінімальні, що дозволить легше розділяти функції,

· повинне дотримуватися правило виклику не більше семи функцій,

· описи функцій не повинні залежати від подробиць реалізації (наприклад, файл, завдання, запис, модуль, робоча станція),

· характеристики якості роботи повинні бути описані, там де це можливо (наприклад, швидкість, частота і т.п.),

· слід визначити найважливіші функції,

· імена функцій повинні описувати, що вони роблять, а не як вони це роблять,

· імена функцій повинні бути декларативними (наприклад "обробка замовлення"), а не процедурними (наприклад "дії після того, як прийде замовлення").

5. Методологія, що використовується в створенні аналітичної моделі

Структурні методи

Структурні методи комбінують статичний опис процесів і статичні моделі даних.

До цього класу моделей належать наступні підходи:

· методи Yourdon (DeMarco і Ward/Mellon),

· методологія структурного системного аналізу і дизайну (Structured System Analysis and Design Methodology, SSADM),

· техніка структурного аналізу і дизайну (Structured Analysis and Design Technique, SADT).

Згідно з DeMarco, структурний аналіз використовує наступні методи:

· Словник баз даних,

· Схеми потоків даних,

· Структурована англійська мова,

· Таблиці рішень,

· Дерева рішень.

Інші методи:

· Схема перетворення,

· Діаграма зміни станів,

· Список подій,

· Схема даних,

· Пред- і післяумови,

· Діаграми відносин "сутність-зв'язок",

· Історія життя об'єкту.

Недолік використання структурного підходу - труднощі в об'єднанні моделей.

Моделі об'єктів

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

Для будь-якої мови її синтаксис, семантика і прагматика повинні бути проаналізовані.

· Синтаксис визначає способи ведення запису,

· Семантика визначає значення запису,

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

6. Документація вимог

Аналітичну модель слід представляти у формі єдиного повного документа.

Ось приклад такого документа:

Мал. 6.7.1 Структура документа вимог.

7. Аналіз чинників успіху

Ключовими чинниками успіху на етапі аналізу є:

· участь представників клієнта,

· повний і загальний підхід, без загостренної уваги на деталях,

· розгляд складних аспектів (безпека, масштабованість, оцінка об'єму і т.п.),

· відповідність стандартам,

· перевірка коректності і послідовності,

· прозорість, логічність і послідовність документа.

8. Короткий звіт

На етапі аналізу будується логічна модель. Модель відповідатиме детальному і конкретному опису того, як повинна бути спроектована система, щоб задовольняти сформульовані вимоги.

Результи цього етапу наступні:

· задовільні вимоги, описані в документі,

· словник даних,

· документація моделі, що містить:

o діаграми класів,

o діаграми випадків використання,

o діаграми послідовності повідомлень,

o діаграми станів,

o визначення класів, атрибутів, відносин, методів і т.д.

· графік етапу дизайну,

· попереднє визначення персоналу і терміну.

Аналітична модель описує те, для чого призначена система. Модель не має відношення до самої реалізації. Таким чином, роблячи наступний крок, ви повинні чітко визначити значення всієї інформації, необхідної програмістові в його роботі над інформаційною системою. Ця частина роботи називається - «проектування системи».

1. Цілі проектування

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

Проектувальник повинен зберегти структуру системи, розроблену раніше (в процесі аналізу). Тільки невеликі зміни можуть бути зроблені в домені/області, вони не повинні сильно впливати на проект загалом.

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

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

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