Главная Случайная страница


Полезное:

Как сделать разговор полезным и приятным Как сделать объемную звезду своими руками Как сделать то, что делать не хочется? Как сделать погремушку Как сделать так чтобы женщины сами знакомились с вами Как сделать идею коммерческой Как сделать хорошую растяжку ног? Как сделать наш разум здоровым? Как сделать, чтобы люди обманывали меньше Вопрос 4. Как сделать так, чтобы вас уважали и ценили? Как сделать лучше себе и другим людям Как сделать свидание интересным?


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Документация проектирования

План проекта и журнал проекта

1.1. Обзор проекта

– Описание проекта и разрабатываемого ПО, цель и назначение, предметная область.

– Важнейшие требуемые функции разрабатываемой системы (функциональность и ограничения).

– Состав команды, имеющиеся навыки и опыт разработчиков, распределение ролей и ответственности.

– Ограничения на процесс разработки.

– Основные этапы работ и график их выполнения (диаграмма Гантта).

– Используемые в проекте формы отчетности и взаимодействия (внутренние и внешние).

1.2. Прогресс разработки

– Протоколы собраний (см. шаблон meeting-YYYY-MM-DD.txt). Регулярность: 1-2 собрания в неделю.

– Индивидуальные отчеты разработчиков (см. шаблон wh-Ivanov.txt). Регулярность: каждый рабочий день.

– Отчет о текущем состоянии проекта (см. шаблон progress-YYYY-MM-DD.txt). Регулярность: каждые 2 недели.

Спецификация требований

2.1. Первичный список требований (функциональные и ограничения).

2.2. Модели требований (анализ и детализация требований)

– Модель предметной области. Объекты и взаимосвязи между ними. Возможно модели данных для этих объектов. Рамки разрабатываемой системы.

– Модели пользователей системы.

– Функциональная модель. Сценарии использования системы или детальное описание работы каждой функции с точки зрения пользователя.

2.3. Высокоуровневая архитектура системы.

– Модель архитектуры.

– Детальные требования к основным подсистемам.

2.4. Критерии аттестации системы.

– Набор базовых высокоуровневых тестов и характеристик, которые будут проверяться при аттестации ПО и удостоверяют его соответствие требованиям заказчика.

2.5. Глоссарий терминов.

Документация проектирования

3.1. Проект архитектуры

– Детальное разбиение системы на подсистемы и модули, высокоуровневое описание взаимодействия подсистем и модулей.

3.2. Проект интерфейса пользователя.

– Внешний вид системы

– описание ввода/вывода данных.

3.3. Основные структуры данных (если таковые проектировались).

3.4. Основные алгоритмы (если таковые проектировались).

3.5. Проект подсистем.

– внутреннее устройство каждой подсистемы

– ее интерфейс с другими подсистемами.

3.6. Структура кода.

3.7. Проект сборки и установки системы.

3.8. Трассируемость требований в проектных решениях.

План тестирования

4.1. Описание методов и обоснование необходимости их применения.

4.2. Варианты тестов (список для каждого объекта/метода: № теста, описание теста, входные данные, ожидаемый результат).

4.3. Трассируемость требований в тестах.


<== предыдущая | следующая ==>
Совет Стай | 

Date: 2015-09-05; view: 245; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.007 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию