План за разработка на … Документ #

1Въведение

• 
  Версия1: част 1 & 2
  
• 
  Версия2: част 3 & 4
  
• 
  Версия3: част 5
  
• 
  Версия4: част 6
  

1.1Описание на документа

• 
  XXX.
  

1.2Обхват на проекта

1.2.1Identification

1.2.2Кратко описание

1.3Речник на термините и използвани съкращения

1.3.1Съкращения

1.3.2Речник на термините

1.4Свързани документи

1.4.1Към други проектни документи

1.4.2Към стандарти и изисквания за съответствие

1.5Конвенции

Описание на изискването

Например:

Описание на XXX-000

2Управление на проекта

2.1Описание на екипа

2.2Отговорности

• 
  Технически мениджър: XXX
  
• 
  Мениджър проект: XXX
  
• 
  Ръководител екип:
  
• 
  Програмист:
  
• 
  XXX
  

2.3Участие на клиента в проекта

2.4Задачи – Планиране – Важни етапи от разработката

2.5Инструменти за разработка

2.6Други необходими ресурси

2.7Използвана методология за разработка

2.8Рецензии

• 
  Рецензии на дизайна
  
• 
  Тестови рецензии/демонстрации на продукта
  

2.9Управление на софтуерни конфигурации

2.10Управление на документацията

• 
  В технически аспект – от член на екипа,
  
• 
  За изпълнение на изискванията по качеството
  

2.11Верификация на продукта

3Спецификацияя

3.1Режими на работа

• 
  Стартиране: софтуера зарежда компонентие си;
  
• 
  Използване: всички части от системата са достъпни за потребителя;
  
• 
  Спиране: системата е в процес на спиране.
  
• 
  Диагностика: системата е в режим на диагностика
  
• 
  И т.н…
  

3.1.1Основна функционалност

3.2Безопасност, сигурност и защита на данните

3.3Експолатация

3.4Графични интерфейси

3.4.1Изисквания към потребителският интерфейс

3.4.2Помощ

3.5Външни системи

3.6Външни интерфейси

3.6.1Хардуерни интерфейси

3.6.2Мрежови интерфейси

3.6.3Обмен на данни

3.7Изисквания към средата

3.7.1Хардуерни изисквания

3.7.2Софтуерни изисквания

3.8Модел на данните

3.9Конфигуриране

3.10Верификация на системата

3.11Обучение

3.12Пакетиране и инсталация

4Архитектура на системата

4.1Архитектура

4.1.1Общо описание

• 
  В каква среда работи (вкъщи, до леглото на пациента ...)
  
• 
  Кои са потребителите
  
• 
  За какво се отнася,
  
• 
  Кои са основните функции,
  
• 
  Кои са основните интерфейси, входно-изходни данни.
  

4.1.2Логическа архитектура

• 
  Идентификация на компонента
  
• 
  Неговата цел,
  
• 
  Как той комуникира с останалите софтуерни интерфейси,
  
• 
  Мрежови интерфейси които ползва
  
• 
  Хардуерните ресурси от които се нуждае – например:колко памет се нуждае, дисково пространство за инсталиране и за кеш, CPU...
  

4.1.3Физическа архитектура

• 
  Идентификация на компонент
  
• 
  Неговата цел
  
• 
  От кои софтуерни компоненти се ползва
  
• 
  Технически характеристики като CPU, RAM, disk and so on.
  
• 
  Мрежови интерфейси
  

4.1.4Динамични модели на системата

4.2Ограничения и предположения

5Верификация

5.1Тестов план

5.1.1Тестова среда

• 
  Операционна система и service packs
  
• 
  Необходими драйвери (ако се нуждаете от такива)
  
• 
  Инструменти за Backup / recovery
  
• 
  Web, blogs, CMS, Databases engines,
  
• 
  Начини и инструменти за анализ на Memory, disk usage, CPU, и трансвер на мрежови данни.
  
• 
  Test coverage или системи за управление на тестовете
  
• 
  Симулатори, генератории на данни за хардуера или софтуера, който нямате в наличност
  
• 
  Всякакъв друг помощен софтуер, който сте разработили за да направите тестовете.
  

• 
  Входни файлове,
  
• 
  Файлове с данни,
  
• 
  Скриптове за генериране на даните,
  
• 
  Изходни файлове, логове
  

5.1.2Тестване в реални условия

5.2Описание на тестовете

5.2.1Изисквания към тестовете

• 
  Уникален идентификатор,
  
• 
  Описание на целта на теста,
  
• 
  Връзка към съответното изискване от секция §3 на този документ,
  
• 
  Методите използвани за верификация (I, A, D, T),
  
• 
  Процедури за записване на данните и последващата им обработка и анализ,
  
• 
  Предположения или ограничение, ако има такива,
  
• 
  Забележки относно безопасността и сигурността.
  

Идентификатора има следната структура::

• 
  Дефинирайте формата на вашият уникален идентификатор.
  
• 
  Например добавете –Т-<НОМЕР> след ID-то на изискването, което тествате. Номерът се ползва ако това изискване се тества от повече от един тест.
  

5.2.2Описание на тестовете

Определено изискване към системата може да се нуждае от повече от един тест за да се валидира. В този случай всички тестове трябва да минат успешно за да бъде валидирано това конкретно изискване..

6Резултати от тестоветес

6.1Обосновка на резултатите

• 
  Минал: Теста получава този статут, ако всички негови стъпки са изпълнени успешно и реалният резултат е съвместим/съизмерим с очакваните резултати..
  
• 
  Провален: Тестът е провален ако някоя стъпка е провалена, или когато резултатът от изпълнение на стъпка се различава от очакваните резултати.
  
• 
  Неизпълнен: Първоначалният статут на теста, преди да се стартира неговото изпълнение..
  
• 
  Недовършен: Статутът на теста, когато някоя негова стъпка е все още със статус „Неизпълнен”.
  

6.2Резултати

7Проследимост на изискванията

• 
  Инспекци (И): контрол или визуална верификация
  
• 
  Анализ(A): верификация базирана на някакви аналитични свидетелства/документи
  
• 
  Демонстрация (Д): верификация на специални функционални изисквания, които нямат ясни количествени изражение
  
• 
  Тест(T): верификация на количествени характеристики, посредством измервания
  

За всяко изискване описано в този документ е дефиниран метод за верификаци. Методите са съкратени до следните означения: И, А, Д и Т.