15 Стандарты документации

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

SVVP - План определяет каким образом и в какой последовательности должны проверяться стадии проекта. Верификация – это процесс проверки правильности сборки приложения. Валидация проверяет тот факт, что собран требуемый продукт.

SQAP - План контроля качества программного обеспечения

SCMP - План управления программным проектом

SRS - Спецификация требований к программному обеспечению

SDD - Проектная документация программного обеспечения

STD - Документация по тестированию программного обеспечения

16 Согласованность и целостность документации.

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

Управление документацией подразумевает поддержание ее полноты и согласованности и включает в себя также управление конфигурациями.

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

Согласованность означает, что набор документов не содержит внутренних противоречий. Проблема в том, что когда этот набор велик, то довольно сложно избежать появления в нем взаимоисключающих утверждений.

Поддержка конфигурации – это координация различных версий и частей документации и программного кода.

17 Способы представления предметной области.

Часто для описания поведения сложных систем и деятельности крупных организаций используются диаграммы потоков данных. Эти диаграммы содержат 4 вида графических элементов: процессы (представляющие собой любые трансформации данных в рамках описываемой системы), хранилища данных, внешние по отношению к системе сущности и потоки данных между элементами трех предыдущих видов.

Используются несколько систем обозначений для перечисленных элементов, наиболее известны нотация Йордана-ДеМарко и нотация Гэйна-Сарсона.

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

18 Выделение и анализ требований.

Потребности определяются на основе наиболее актуальных проблем и задач, которые пользователи и заказчики видят перед собой.

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

Формулировка потребностей не должна накладывать лишних ограничений на возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что именно является проблемой, а не предлагать сразу возможные решения.

На основе выделенных потребностей пользователей, отнесенных к области ответственности системы, формулируются возможные функции будущей системы, которые представляют собой услуги, предоставляемые системой и удовлетворяющие потребности одной или нескольких групп пользователей.

Имея набор функций, достаточно хорошо поддерживающий решение наиболее существенных задач, с которыми придется работать разрабатываемой системе, можно составлять требования к ней.

В.19 Стандарты, регламентирующие работу с требованиями.

Правила работы с требования к ПО и более общими системными требованиями (к программно-аппаратной системе), определяются следующими двумя стандартами IEEE.

IEEE 830-1998 Описывает структуру документов для фиксации требований к ПО. Кроме того, он определяет характеристики, которыми должен обладать правильно составленный набор требований (соответствие реальным потребностям, однозначность понимания, отражение всех выделенных потребностей, согласованность между различными элементами, оформление в удобных для внесения изменений структуре и стилях).

IEEE 1233-1998 Описывает правила построения требований для программно-аппаратных систем в целом. Он выделяет следующие необходимые свойства набора требований (Однократное упоминание отдельных требований, Отсутствие пересечений между требованиями, Явное указание связей между требованиями, Полнота, Непротиворечивость, Определение ограничений).