3.2. Программные требования (Software Requirements по swebok)
Программные требования – Software Requirements – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.
Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени – на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями.
На практике часто применяется подход, используемый в различных методологиях разработки программного обеспечения и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы требований, например: системные, программные, функциональные, нефункциональные и т.п. Классический пример (рис. 7) высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса.
Рис.7. Уровни требований по Вигерсу
3.3. Проектирование программного обеспечения (Software Design по swebok)
Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или ее компонентов называется проектированием. Результат процесса проектирования – дизайн. Проектирование, как процесс, есть инженерная деятельность в рамках жизненного цикла (в данном контексте – программного обеспечения), в которой надлежащим образом анализируются требования для создания описания внутренней структуры программного обеспечения. Программный дизайн должен описывать архитектуру программного обеспечения, то есть представлять декомпозицию программной системы в виде организованной структуры компонент и интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна является тот уровень детализации компонентов, который позволяет заняться их конструированием. Термины дизайн и архитектура могут использоваться взаимозаменяемым образом, но чаще говорят о дизайне как о целостном взгляде на архитектуру системы.
Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей:
архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание высокоуровневой структуры и организации компонентов системы;
детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования.
В 1999 году Tom DeMarco, один из известных специалистов в программной инженерии, предложил терминологическое разделение различных видов дизайна:
D-дизайн (D-design, decomposition design) – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент;
FP-дизайн (FP-design, family pattern design) – семейство архитектурных представлений, базирующихся на шаблонах;
I-дизайн (I-design, invention) – создание высоко-уровневой концепции, видения того, что из себя будет представлять программная система; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации.
Если обсуждать данную область знаний в терминах ДеМарко, проектирование программного обеспечения в понимании программной инженерии подразумевает D- и FP-дизайн. I-дизайн в большей степени относится к работе с программными требованиями.