- •Порядок оформления учебных документов
- •3 Требования к оформлению текстовых документов
- •3.1 Общие требования
- •3.4 Рисунки, графики и диаграммы
- •3.9 Ссылки
- •3.10 Приложения
- •3.11 Перечисления
- •4 Документ, выпущенные до начала проектирование по
- •5.1 Принципы моделей процессов
- •5.2 Схема процесса разработки
- •6 Варианты жизненного цикла по (жцпо)
- •6.1 Каскадная модель
- •6.2 Итерационная модель жцпо
- •6.3 Спиральная модель жцпо.
- •6.4 Обязательные правила (жцпо)
- •6.4.1 Фаза «определение требований пользователя»
- •6.4.2 Фаза «определение требования к по»
- •6.4.3 Фаза «архитекрурное проектирование»
- •6.4.4 Фаза «детальное проектирование и разработка код-программ»
- •6.4.5 Фаза «тестирование и передача по в эксплуатацию»
- •6.4.6. Фаза «эксплуатации и сопровождения»
- •6.1 Процесс отладки
- •6.2 Принцип тестирование
- •3. Определение требований пользователя
- •Получение требований пользователя
- •Спецификация требования пользователя
- •Мандатные требования
- •Ограничительные требования пользователя
- •Суть требований для различных видов интерфейсов
- •Требование взаимодействия «человек-компьютер»
- •Качество программного обеспечения
- •Методы для определения требований пользователя
- •Методы для спецификации требований
- •Объединение требований.
- •Средства разработки для определения требований пользователя
- •Средства разработки для спецификации требований пользователя
- •3.6 Атрибуты требований пользователей
- •3.7 Последовательность действий
- •3.8 Классификация требований
- •3.8.1 Требования пользователя
- •3.8.2 Системные требования (требования к по) Дополнительные атрибуты требований к по. Полнота. Корректность. Дублирование.
- •3.8.2.1 Типа интерфейсов
- •3.8.2.2 Категории системных требований
- •3.8.3 Проектная системная спецификация
- •4. Процесс разработки требований к по
6.4 Обязательные правила (жцпо)
6.4.1 Фаза «определение требований пользователя»
Ответственность за определение требований пользователя возлагается на пользователя.
Каждое требование пользователя должно включать в себя идентификатор.
Существенные требования пользователя должны быть обязательно выделены
Для итерационного жизненного цикла каждое требование пользователя должно включать в себя уровень приоритета, чтобы разработчик мог составить график производства.
Источник каждого требования пользователя должен быть установлен.
Каждое требование пользователя должно проверяемым.
Выходы этой фазы должны быть формально проверены в ходе обзора требований пользователя.
Выходом этой фазы должен быть документ требований пользователя или раздел технического задания.
Необходимо описать внешние связи (интерфейсы) системы или сделать ссылку на них в документах управления внешними связями, которые уже существуют или должны быть написаны.
6.4.2 Фаза «определение требования к по»
Разработчик должен создать не зависящую от реализации модель того, что требуется пользователю.
Каждое требование к ПО должно включать в себя идентификатор.
Для итерационного жизненного цикла каждое требование к ПО должно включать уровень приоритета, чтобы разработчик мог составить график реализации.
Каждое требование к ПО должно сопровождаться ссылками для прослеживание связи требования к ПО с требованиями пользователя.
Каждое требование ПО должно быть проверяемым.
Выходи этой фазы должны быть формально проверены в ходе обзора требований к ПО.
Выходом этой фазы должен быть документ требований к ПО или раздел технического задания.
Этот документ должен быть полным и охватывать все требования, в нем должна быть помещена таблица, показывающая, как требования пользователя трассируются (сопоставляются) с непротиворечивыми требованиям к ПО.
Этот документ должен быть непротиворечивым и не содержать деталей или терминологию реализации, если это не должно быть представлено как ограничение.
«Описание функций…» должны указывать, что должно делать ПО, и избегать предписаний, как это должно быть сделано.
6.4.3 Фаза «архитекрурное проектирование»
Процессы этой фазы должны выполняться в соответствии с планами, определенными на предыдущих фазах.
В этой фазе должен быть принят и последовательно применен известный метод проектирования ПО.
Разработчик должен построить физическую модель, которая описывает проект ПО, используя терминологию реализации.
Метод, применяемый для декомпозиции ПО на составляющие его компоненты, должен допускать нисходящий подход.
В документе, описывающем результаты архитектурного проектирования, должен быть отражен только выбранный подход к проектированию.
пятница, 14 сентября 2012 г.
Для каждой компоненты в этом документе должна быть подробно определена следующая информация:
Входные данные
Выполняемые функции
Выходные данные
В этом документе должны быть определены структуры данных, которыми обмениваются компоненты.
Определения структуры данных должны включать в себя:
Описание каждого элемента (например, наименование, тип, размерность);
Взаимосвязи между элементами (т.е. структуру);
Диапазон возможных значений каждого элемента;
Начальные значения каждого элемента.
В этом документе должен быть определен поток управления между компонентами, главные компоненты ПО и интерфейсы между ними. (поток управление – последовательность подключения модулей компонента)
Необходимо указать все внешние интерфейсы или сослаться на них, клмпьютерные ресурсы (например, скорость центрального процессора, память, накопительные устройства, системное ПО), необходимые для инструментальной среды разработки и функционирования.
Этот документ должен быть достаточно подробным, чтобы позволить руководителю проекта составить детальный план реализации и управлять всем проектом на протяжении последующих фаз разработки.
Выходы этой фазы должны быть формально проверены в течение обзора результатов архитектурного проектирования.