Нормативное обеспечение специфицирования требований к аппаратно-программным комплексам

Введение

Постановка задачи на разработку аппаратно-программного комплекса является критически фактором успеха проекта. «Как задачу сформулируешь, так её и решат». Невозможно создать высококачественный продукт в случае, если четко не определены требования к его потребительским свойствам. Следует обратить внимание на то, что в различных нормативных документах, с одной стороны приводятся схожие рекомендации по содержанию спецификаций требований. С другой стороны, рекомендуемые структуры спецификаций различаются. Это, на наш взгляд, является отражением невозможности четкой формализации работ, выполняемых на начальных стадияхпроекта.

Целью практических занятий является изучение приемов специфицирования пользовательских требований в рамках стандартов ESA PSS-05-03 и IEEE Std-830-1998.

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

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

1. Эталон потребительских свойств изделия. Спецификация требований пользователей представляет собою систему функциональных и нефункциональных требований к изделию в терминах конечных пользователей. Система функциональных и нефункциональных требований является эталоном, с которым будут сравнивать результаты функционирования объекта, а также основой разработки сценариев валидации изделия. Спецификация требований пользователей как эталон потребительских свойств изделия должна обладать следующими базовыми свойствами: корректность; определенность; полнота; согласованность; ранжированность по важности/устойчивости; верифицируемость; модифициуемость; трассируемость.

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

3. Основа для определения бюджета и сроков проекта. Объем и содержание функциональных требований, а также ограничения на возможные решения в виде нефункциональных требований являются основой для оценивания масштаба и сложности проекта. Это, а также учет доступных ресурсов, служит основой оценивания бюджета и сроков проекта (под ресурсами согласно COBIT понимаются кадры, инфраструктуры, инструментальные средства, доступные работникам истории ранее реализованных проектов (Project History Document).

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

5. Компромиссное решение, поддерживаемое правообладателями. Для нормального хода проекта необходимо обеспечить его поддержку (либо хотя бы нейтральное отношение) со стороны правообладателей, способными по-разному влиять на ход проекта (вопросы управления отношением правообладателей к проекту рассматриваются, например). В силу того, что разные правообладатели по-разному оценивают изделие , поддержка проекта с их стороны возможна лишь в случае, если его реализация не представляет угрозы их жизненным интересам. Таким образом, содержание спецификаций требований пользователей не должно противоречить интересам разных правообладателей. Иными словами, спецификация требований пользователей представляет собой решение, учитывающее интересы правообладателей и поддерживаемое ими.

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

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

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

7. Основа формирования требований к процессам производства изделия. Требования пользователей к потребительским характеристикам конечного продукта определяют требования к характеристикам процессов производства системы (основного и вспомогательного). Примером реализации этого положения является QFD методология. Ограничением данной методологии является то, что не учитывается неопределенность, свойственная требованиям пользователей.

8. Основа проектирования спецификаций использования программной системы разными правообладателями.

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

10. Спецификации требований пользователей – представляют согласованное видение правообладателями способов достижения целей проекта на основе определенных принципов и правил.

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

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

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