Измерение требований (Measuring Requirements)

С практической точки зрения, обычно полезно иметь нечто, позволяющее определить “объем” требований для заданного (создаваемого) программного продукта. Это число полезно для исследования “масштабов” изменений в требованиях, оценки стоимостных характеристик (cost estimation) разработки и поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п.

Измерение объема функциональности (Functional Size Measurement, FSM) техника такого рода численной оценки, определена на концептуальном уровне в стандарте IEEE 14143.1. Стандарты ISO/IEC и другие источники описывают частные методы FSM (например, модель COCOMO II для оценки стоимости, например, может использоваться в тесной связи с методами функциональных точек – functional points для оценки масштабов функциональности, то есть требований, предъявляемых заданной программной системе).

Дополнительная информация по стандартам и подходам в оценке масштабов представлена в области знаний “Процесс программной инженерии” (Software Engineering Process).

В дополнение к практическим соображениям, представленным в SWEBOK, на фоне общей тенденции разработки моделей <оценки> зрелости, стоит отметить, что существуют определенные работы и по созданию различных моделей зрелости требований. Например, наиболее популярная модель зрелости в индустрии программного обеспечения – CMMI включает разный объем и содержание работ по определению и управлению требованиями для уровней зрелости 2 и 3.

2. Проектирование программного обеспечения
(Software Design по SWEBOK)

Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK.
Содержит перевод описания области знаний SWEBOK “Software Design”, с замечаниями и комментариями.

Проектирование программного обеспечения (Software Design)
1. Основы проектирования (Software Design Fundamentals)
1.1 Общие концепции проектирования (General Design Concepts)
1.2 Контекст проектирования (Context of Software Design)
1.3 Процесс проектирования (Software Design Process)
1.4 Техники применения (Enabling Techniques)
2. Ключевые вопросы проектирования (Key Issues in Software Design)
2.1 Параллелизм (Concurrency)
2.2 Контроль и обработка событий (Control and Handling of Events)
2.3 Распределение компонентов (Distribution of Components)
2.4 Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance)
2.5 Взаимодействие и представление (Interaction and Presentation)
2.6 Сохраняемость данных (Data Persistence)
3. Структура и архитектура программного обеспечения (Software Structure and Architecture)
3.1 Архитектурные структуры и точки зрения (Arcitectural Structures and Viewpoints)
3.2 Архитектурные стили (Arcitectural Styles)
3.3 Шаблоны проектирования (Design Patterns)
3.4 Семейства программ и фреймворков (Families of Programs and Frameworks)
4. Анализ качества и оценка программного дизайна (Software Design Quality Analysis and Evaluation)
4.1 Атрибуты качества (Quality Attributes)
4.2 Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)
4.3 Измерения (Measures)
5. Нотации проектирования (Software Design Notations)
5.1 Структурные описания, статический взгляд (Structural Descriptions, static view)
5.2 Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view)
6. Стратегии и методы проектирования программного обеспечения (Software Design Startegies and Methods)
6.1 Общие стратегии (General Strategies)
6.2 Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design)
6.3 Объектно-ориентированное проектирование (Object-Oriented Design)
6.4 Проектирование на основе структур данных (Data-Structure-Centered Design)
6.5 Компонентное проектирование (Component-Based Design)
6.6 Другие методы (Other Methods)

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

Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения (Software Development Life Cycle), например, IEEE и ISO/IEC (ГОСТ Р ИСО.МЭК) 12207. Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей:

• Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание высокоуровневой структуры и организации компонентов системы;
• Детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования.

В результате консенсуса, принятого создателями SWEBOK, данная область знаний не описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или “архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из известных специалистов в программной инженерии, предложил терминологическое разделение различных видов дизайна:

• D-дизайн (D-design, decomposition design) – декомпозиция структуры программного обеспечения в виде набора фрагментов или компонент;
• FP-дизайн (FP-design, family pattern design) – семейство архитектурных представлений, базирующихся на шаблонах;
• I-дизайн (I-design, invention) – создание высоко-уровневой концепции, видения того, что из себя будет представлять программная система; данный вид дизайна является результатом процесса анализа требований и их трансформации в подходы к реализации.

Если обсуждать данную область знаний в терминах ДеМарко, проектирование программного обеспечения в понимании программной инженерии подразумевает D- и FP-дизайн. I-дизайн в большей степени относится к работе с программными требованиями.

Соответственно, данная область знаний тесно связана со следующими областями программной инженерии:

• Software Requirements
• Software Construction
• Software Maintenance
• Software Engineering Management
• Software Quality

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

Рисунок 3. Область знаний “Проектирование программного обеспечения” [SWEBOK, 2004, с.3-2, рис. 1]

Дата добавления: 2014-10-22