Правильність та якість системи

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

Правильний проект повинен бути:

завершеним;

сумісним;

узгодженим;

повинна зберегтися семантика позначень.

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

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

 

Верифікація діаграм класів

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

У верефікації діаграм класів потрібно враховувати наступне:

ациклічні відносини узагальнення-спеціалізації,

варіанти відносин циклічного об'єднання,

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

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

 

У чому полягає якість системи

Багато методів і позначень є неформальними, і їх використання залежить від типу проекту. Оцінка якості вельми важка і під час будівництва ПЗ, і при задоволенні користувача: рівень відповідності вимогам, надійність, ефективність і ергономічність. Якість вказує на узгодженість, рівень зв'язків і прозорість. Існують формальні заходи для оцінки якості, і вони є дуже важливими, але не повністю визначають ефективність системи.

 

Критерії декомпозиції системи

-Випадкова декомпозиція. Розділення на модулі відбувається із-за неможливості обхватити всю систему в різних завданнях.

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

-Часова декомпозиція. Компоненти працюють в однаковий час.

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

Функціональна декомпозиція. Всі компоненти потрібні для виконання однієї функції.

 

Рівні зв’язку компонентів системи

У хорошому проекті зв'язки між компонентами повинні бути слабкі. Це визначає декомпозицію проекту на частини, а ПЗ - на модулі.

Малюнок 7.9.2. Рівні зв'язку між компонентами.

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

 

В чому полягає прозорість проекту

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

Представлення реальності

Компоненти і їх зв'язки повинні представляти структуру системи. Тісні зв'язки проекту з реальністю дозволяє полегшити його розуміння і підтримку.

Узгодженість і рівень зв'язків компонентів

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

Зрозуміла термінологія

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

Зрозуміла і повна специфікація

Специфікація повинна бути написана на зрозумілій користувачеві мові. Слід уникати професійного сленгу.

Відповідна складність компонентів на кожному рівні.

Застосування наслідування і методів в класах спрощує розуміння проекту.

 

Не функціональні вимоги етапу проектування

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

Повинні бути враховані такі вимоги:

1.Вимоги до робочих характеристик.

2.Вимоги до інтерфейсу (протоколи, формати файлів).

3.Експлуатаційні вимоги.

4.Вимоги до ресурсів (число процесорів, об'єм вінчестера).

5.Контрольні вимоги.

6.Тестові вимоги.

7.Вимоги документування.

8.Вимоги безпеки.

9.Вимоги портативності.

10.Вимоги якості.

a.підбір методу проектування

b.можливість повторного використання

c.підбір інструментів

d.можливість зовнішнього доступу

11.Вимоги по надійності.

12.Інструкція по технічному обслуговуванню.

13.Можливість усунення відмов або несправностей.

 

Результати етапу проектування

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

Покращений документ з описом вимог

Покращена модель

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

Опис проекту, що містить (у разі об'єктно-орієнтованого підходу):

класові діаграми

зв'язки об'єкту

структурні зв'язки

модульні діаграми

глосарій:

класових визначень

визначень атрибутів

визначення комплексних і елементарних даних

визначення методів

Ресурси інтерфейса для меню, діалогів

База даних проекту

Структура фізичної системи проекту

Виконання розкладу

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

 

Структура детального документу проекту

хз....ненайшов. То походу — DPD.

 

Модифікація, еволюція та відповідальність за документ, створений на етапі проектування

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

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

На цьому етапі виконується перетворення абстрактних понять, що використовувалися в аналізі.

У ПЗ існує декілька складових; одна з них представляє частину проблем, відповідальних за виконання основних функцій і обробки необхідних даних. Вона відображає модель, розроблену після аналізу. Інші частини відповідальні за комунікацію з клієнтом, за зберігання і доступ до даних, управління пам'яттю і компоненти управління завданнями.

На етапі проектування також виконується оптимізація моделі.

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

На етапі проектування також повинна бути визначена фізична структура моделі/

 

На стратегічному етапі виконуються наступні дії:

· обговорення проекту з представниками клієнта

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

· визначення можливостей і контексту проекту

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

· формулювання альтернативних рішень

· аналіз

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

· попереднє планування і вибір структури команди

· стандартні визначення

 

Співпраця з клієнтом

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

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