Ссылочные документы

1 2 3

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

Описание функций

Описание информации

Общая характеристика

1.1 Цели и назначение

Рыночная ниша, потенциальные пользователи, основная функциональность

1.2 Технико-экономическое обоснование

Экономический эффект для потребителей

Сравнение с аналогами

1.3 Требования и ограничения

Конфигурация целевой платформы и потребляемые ресурсы

Требования к эксплуатационным показателям качества: производительность, надежность, совместимость, переносимость и т.д.

Ограничения: чего не будет, хотя может тщетно ожидаться пользователем

2.1 Поток данных

Пути преобразования данных от входных через промежуточные к выходным

2.2 Содержание и структура данных

Форматы входных / выходных данных

3.1 Функциональная структура

· Разделение на части (подсистемы, модули, процедуры, объекты) и взаимосвязи между частями

· Словесное описание функций, ключевых алгоритмов и математических моделей, ссылки на прототипы

3.2 Внешний интерфейс

Для продукта-приложения – интерфейс пользователя

Для продукта-библиотеки – API (Application Programming Interface)

3.3 Системный интерфейс

Сопряжение с аппаратно-программным окружением

4.1 Измеряемые показатели функционирования

Методика испытаний на соответствие требованиям к показателям, заданным в п. 1.3.

4.2 Классы тестов

Перечень тестовых испытаний на нормальное функционирование, предельные и аварийные ситуации и пр.

Перечень стандартов, статей, монографий и других документов

В промышленности в этот документ включают еще один раздел: «План разработки проекта», адресованный менеджерам. В нем даются оценки трудоемкости, времени и других требуемых ресурсов:

§ График разработки: основные этапы, их результаты и сроки

Потребность в рабочей силе на каждом этапе
Потребность в аппаратуре, софте и др.

В рамках MSF результатом этапа анализа является концепция (Vision Document), приблизительно соответствующий 1 разделу шаблона на стр. 2, плюс черновой график проекта. На 2 этапе (планирование, или общее проектирование) готовится Project Plan, содержание которого соответствует остальным разделам внешней спецификации, включая детальный график проекта.

Software Design Documents – это проектные (внутренние) спецификации. Они относятся к компонентам ПП. Для подсистем они строятся по такой же схеме, как внешняя спецификация, но с двумя отличиями: раздел "Общая характеристика" короче, а разделы «Описание информации» и «Описание функций» - более подробные; в них используются различные модели (структурная, функциональная и пр.) в соответствии с методологией проектирования. Спецификация наименьшего компонента – программного модуля – это формат его вызова с описанием всех параметров и результатов и кроме того, возможно, его алгоритм, если он неочевиден. Совокупность таких форматов называется API (Application Programming Interface).

Исходные коды также относятся к ПД; главное требование к ним – читабельность, что достигается следованием стандарту кодирования и подробными комментариями (в среднем 20% строк – комментарии). Стандарт кодирования обычно определяет: