Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lecture_Marta.doc
Скачиваний:
53
Добавлен:
12.02.2016
Размер:
2.11 Mб
Скачать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • глосарій:

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

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

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

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

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

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

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

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

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

Продукт повинен бути перевірений і веріфікований командою програмістів і протестований зі всіх можливих сторін.

11. Детальний документ проекту

Модель проекту повинна бути записана в документі під назвою «Детальний Документ Проекту» (ДДП).

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

Організація інформації:

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

  2. Зміст

  3. Статус документа

  4. Опис змін порівняно з минулою версією

ЧастинаIЗагальний опис

Вступ:

Описує мету і можливості, визначає терміни, таблицю посилань і обдумує документ.

  • Мета - описує мету ДДП і визначає читача, для якого це передбачено.

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

  • Визначення, акроніми, абревіатури.

  • Посилання.

Основні положення.

2. Стандарти, правила і порядок здійснення дій проекту:

  • Стандарти проекту

  • Стандарти документа

  • Термінологія

  • Стандарти програмування

  • Засоби розробки ПЗ

Частина II – Визначення складових

n [Ідентифікатор складової]:

n.1. Тип n.2. Ціль n.3. Функція n.4. Підкомпоненти n.5. Зв'язки n.6. Інтерфейси n.7. Ресурси n.8. Посилання n.9. Трансформація n.10. Дані

Додаток A. Початковий текст програми.

Додаток B. Матриця зв'язків безлічі вимог і компонент програмного забезпечення.

Якість ДДП:

  • Модифікованість документа:

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

  • Еволюція документа:

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

  • Відповідальність за документ:

Міра відповідальності повинна бути однозначно визначена. Зазвичай відповідальний - програміст, що створив програмне забезпечення.

  • Середовище документа:

Оригінал документа повинен бути добре захищений. Інші версії повинні бути похідними від оригіналу.

  • Інші рекомендації по ДДП:

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]