Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

Рис. 2.2 . Разделы и рубрики Руководства по SWEBOK

58 Глава 2

Ядро знаний по программной инженерии продолжает развиваться. Текущая

версия SWEBOK рассматривается как проект соответствующего международного

стандарта, разработку которого осуществляет ISO/IEC JTC1/SC7 WG20

. В 2005

году вышла первая версия стандарта - ISO/IEC TR 19759:2005 «Software Engineering

- Guide to the Software Engineering Body of Knowledge - SWEBOK».

2.2.2. Область знаний «Программные требования»

Область знаний «Программные требования» (Software Requirements) по су-

ществу охватывает все аспекты инженерии требований – инженерной дисциплины

(в рамках программной инженерии) извлечения, анализа, спецификации, докумен-

тирования, проверки и управления требованиями к ПО на всех стадиях ЖЦ систем.

Требования – это «свойства, которыми должно обладать разработанное или

адаптированное ПО, для того чтобы решать поставленные задачи».

С одной стороны, требования - это множество функций, которые должно

выполнять ПО, чтобы удовлетворить потребности его заказчиков, с другой стороны

- это множество ограничений на способ реализации функций (например, язык,

платформа, эффективные алгоритмы), с третьей – это множество условий выполне-

ния функций ПО в определенной среде эксплуатации (с учетом конфигурации вы-

числительной среды, режима секретности и др.).

«Многоаспектность» требований связана с необходимостью учитывать не

только пожелания непосредственных пользователей ПО, но и потребности сопро-

вождения и развития ПО. В SWEBOK различаются требования к продукту и к про-

цессу, функциональные и нефункциональные требования, а также системные тре-

бования, касающиеся взаимосвязанных программных и аппаратных подсистем.

Требования могут иметь количественное представление (например, «количество

запросов в сек. должно составлять…», «средний показатель ошибок не должен пре-

вышать …% от объема вводимой информации» и т.п.). Значительная часть требо-

ваний относится непосредственно к характеристикам и подхарактеристикам каче-

ства: безотказность, надежность и др.

Область знаний включает следующие разделы:

• основы требований

(Requirements Fundamentals),

• процесс инженерии требований (Requirements Process),

• выявление (извлечение) требований (Requirements Elicitation),

• анализ требований (Requirements Analysis),

• спецификация требований (Requirements Specification),

• проверка требований (Requirements Validation),

• практические соображения (Practical Considerations).

Раздел области знаний Процесс инженерии требований базируется на об-

щем процессном подходе к работе с требованиями, в соответствии с которым каж-

дое требование с момента его выявления должно идентифицироваться, определять-

ся как элемент конфигурации и попадать в сферу непрерывного управления и

уточнения с учетом мнений всех заинтересованных сторон и обеспечением ком-

промисса между требованиями. Процесс инженерии требований нуждается в под-

держании, управлении, оценке качества (зрелости) и совершенствовании и для сво-

Структура комитетов ISO по стандартам описана в главе 5.

«Основы» в областях знаний мы здесь не всегда выделяем в виде раздела.

Глава 2 59

его выполнения требует определенных ресурсов проекта, включая квалифициро-

ванный персонал – участников процесса (пользователей, аналитиков и др.).

Раздел Выявление требований касается процесса извлечения информации из

разных источников (договоров, материалов аналитиков по задачам и функциям

системы и др.), проведения организационных мероприятий (наблюдений за выпол-

нением бизнес-процессов, собеседований, собраний и др.) для определения спектра

требований на разработку, согласования требований с заказчиком, исполнителем и

всеми заинтересованными сторонами. Основа надлежащего выявления требования

– налаженные коммуникации между всеми участниками проекта.

Раздел Анализ требований касается изучения заявленных потребностей и

целей пользователей, их классификации и преобразования к требованиям к систе-

ме, установления и разрешения конфликтов между требованиями, определения

приоритетов, границ системы и принципов взаимодействия со средой функциони-

рования. Требования классифицируются как функциональные и нефункциональ-

ные, внешние (по отношению к системе и ПО) и внутренние. Функциональные тре-

бования характеризуют функции системы и ее ПО, способы поведения ПО в про-

цессе выполнения функций и методы преобразования входных данных в выходные

(результаты). Нефункциональные требования определяют условия и среду выпол-

нения функций (например, относительно защиты и доступа к БД, секретности,

взаимодействия функциональных компонентов и др.). Моделирование требований

и их декомпозиция до уровня программных компонентов завершается на этапе про-

ектирования архитектуры ПО и отражается в специальном документе, по которому

проводится согласование требований для достижения взаимопонимания между за-

казчиком и разработчиком.

Спецификация требований к ПО в SWEBOK трактуется как процесс фор-

мализованного описания функциональных и нефункциональных требований к ПО и

характеристикам его качества в документе спецификации требований, структура и

содержание которого регламентируется стандартом, утвержденным для использо-

вания в проекте, например, IEEE Std. 830:1998 «Рекомендованные приемы специ-

фикации требований к ПО».

Проверка требований заключается в проведении процедуры верификации

требований, сформулированных в документе спецификации требований. Ее цель –

убедиться в том, что все требования заказчиков учтены и правильно поняты разра-

ботчиками. Верификация требований – это процесс проверки соответствия требо-

ваний потребностям, их непротиворечивости, полноты и реализуемости, соответст-

вия стандартам, а также их пригодности для проведения проверки и подтверждения

соответствия с помощью приемочных тестов. Верификация проводится методами

обзора или прототипирования, т.е. быстрого моделирования (отработки) отдельных

требований на конкретном инструменте.

В разделе Практические соображения акцент делается на непрерывности и

итеративности процесса инженерии требований, включая мониторинг источников

требований, управление изменениями в документе требований, трассирование про-

граммных требований к системным, а также принятых архитектурно-программных

решений к программным требованиям. Даются также практические рекомендации

по определению объема функциональности ПО на основе концепции FSM (Func-

tional Size Measurement), отраженной в стандарте ISO/IEC 14143:1998 «Information

technology - Software measurement - Functional size measurement».

60 Глава 2

2.2.3. Область знаний «Проектирование программного обеспечения»

Проектирование ПО (Software Design) – процесс определения архитектуры,

компонентов, интерфейсов и других характеристик системы. Конечный результат

проектирования – проект (или дизайн

). В иностранной литературе по программ-

ной инженерии слово Design определяет оба понятия – и процесс проектирования,

и результат проектирования. Базовые понятия в области проектирования – цели,

ограничения, возможные альтернативы, представления и решения. В соответствии

с процессным походом деятельность по проектированию организована в виде по-

следовательных процессов «проектирования архитектуры системы» и «проектиро-

вания ПО», включая архитектурно-функциональное проектирование и детальное

проектирование отдельных компонентов. Результат этого процесса – множество

моделей и артефактов, фиксирующих основные решения.

При проектировании используются принципы и техники абстракции, связы-

вания (coupling) и сцепления (cohesion), декомпозиции и модульности, инкапсуля-

ции и сокрытия информации, разделения интерфейса и деталей реализации, необ-

ходимой достаточности, полноты и простоты.

Область знаний включает следующие разделы:

• основы проектирования ПО (Software Design Fundamentals),

• ключевые вопросы проектирования ПО (Key Issue in Software Design),

• структура и архитектура ПО (Software Structure and Architecture),

• анализ и оценка качества проекта ПО (Software Design Quality Analysis

and Evaluation),

• нотации проектирования ПО (Software Design Notations),

• стратегия и методы проектирования ПО (Software Design Strategies and

Methods).

Раздел Ключевые вопросы проектирования ПО определяет фундаменталь-

ные проблемы, поднимаемые вне зависимости от используемых методологий про-

ектирования: обеспечение производительности, декомпозиция ПО на функцио-

нальные компоненты и их интеграция в систему, поведенческие аспекты (паралле-

лизмы) в работе ПО, распределение компонентов в среде выполнения и их взаимо-

действие между собой, организация данных и потоков управления, обработка со-

бытий и исключительных ситуаций, эргономические аспекты и др.

В разделе Структура и архитектуры ПО проект рассматривается как

«многоаспектный» артефакт, произведенный в ходе процесса проектирования и

отражающий множество независимых ортогональных взглядов на ПО (поведенче-

ский, функциональный, структурный и др.).

Современная практика проектирования использует понятие архитектурных

стилей и шаблонов проектирования.

Архитектурный стиль – это множество ограничений, определяющих семей-

ство архитектур, удовлетворяющих этим ограничениям; или метамодель, опреде-

ляющая высокоуровневую организацию ПО (например, клиент-серверные архитек-

туры, послойные архитектуры и др.).

См., например, [1]. В отечественной программной инженерии слово «проект» также

трактуется двояко – как «проект = дизайн», и как «проект = вид организации работ» (в анг-

лийском – Project). Поэтому, возможно, автор работы [1] прав, воспользовавшись словом

«дизайн».

Глава 2 61

Шаблон проектирования (паттерн, pattern) — это эффективный способ реше-

ния характерных задач проектирования, образец типового решения общей пробле-

мы в заданном контексте. Паттерн не есть готовое проектное решение, которое мо-

жет быть непосредственно преобразовано в код, скорее это описание того, как ре-

шить задачу таким образом, чтобы решение можно было использовать многократно

в различных ситуациях.

Архитектурные стили рассматриваются как паттерны, описывающие макро-

архитектуру ПО. Для описания микроархитектуры ПО (деталей ПО на более низ-

ких, локальных уровнях) используют другие паттерны: структурные («контейнер»,

«адаптер», «компоновщик» и др.), креативные («строитель», «фабрика», «прото-

тип», «одиночка» и др.), поведенческие («интерпретатор», «посредник», «наблюда-

тель» и др.). Главная польза паттернов состоит в том, что каждый из них описывает

решение целого класса абстрактных проблем, имеет свое имя, независим от приме-

няемого языка программирования, облегчает взаимодействие между разработчика-

ми, использующими унифицированную терминологию.

Еще один из возможных подходов к повторному использованию архитектур-

ных решений и компонентов - формирование линий (семейств) продуктов (product

lines) на основе общего дизайна. В объектно-ориентированном программировании

аналогичным по смыслу понятием являются фреймворки (каркасы), частично за-

вершенные программные подсистемы, которые могут быть надлежащим образом

дополнены в соответствии со спецификой решаемой задачи.

В разделе Анализ и оценка качества проекта ПО рассматриваются про-

блемы обеспечения и оценивания качества, непосредственно касающиеся проекта

ПО. Делается различие между атрибутами качества, наблюдаемыми во время рабо-

ты ПО (эффективность, безопасность, удобство применения и др.), и атрибутами

качества, присущими проекту ПО как таковому (концептуальная целостность, кор-

ректность, полнота и др.).

Для анализа качества проекта рекомендуются методики статического анали-

за, моделирования и прототипирования, а также меры и метрики для оценки проек-

та по различным аспектам – размера, структуры, функций и качества проектирова-

ния. Очевидно, что спектр метрик зависит от выбранного подхода к проектирова-

нию. В SWEBOK они классифицируются как функционально-ориентированные

(структурные) метрики проекта (на базе анализа иерархических диаграмм пред-

ставления проекта) и объектно-ориентированные (на базе диаграмм классов).

В разделе Нотации проектирования представлены две категории нотаций

артефактов проекта – структурные и поведенческие.

Структурные нотации, как правило, графические, используются для пред-

ставления структурных аспектов проекта - компонентов и их взаимосвязей, элемен-

тов архитектуры и их интерфейсов. К ним относятся формальные языки специфи-

каций и проектирования: ADL (Architecture Description Language), UML (Unified

Modeling Language), IDL (Interface Description Language), диаграммы сущность-

связь - ERD (Entity–Relation Diagrams), диаграммы классов и компонентов, диа-

граммы Джексона, структурные схемы, схемы классов (CRC Cards) и др.

Поведенческие нотации используются для описания динамических аспектов

функционирования систем и их компонентов. К ним относятся диаграммы потоков

данных, диаграммы действий (потоков управления), диаграммы взаимодействия

62 Глава 2

объектов, диаграммы переходов состояний, таблицы решений, блок-схемы, фор-

мальные языки спецификации, псевдокод, язык проектирования PDL и др.

Раздел Стратегии и методы проектирования ПО представляет общие

стратегии проектирования и специализированные методы, предлагающие собст-

венные нотации для описания различных аспектов проекта.

К общим стратегиям относятся: «разделяй и властвуй», «пошаговое уточне-

ние», «снизу-вверх», «сверху–вниз», «абстракция данных» и «сокрытие информа-

ции», «применение паттернов и языков паттернов», «применение итеративного и

инкрементного подходов» и др.

Функционально–ориентированные (структурные) методы базируются на

структурном анализе, структурных картах, диаграммах потоков данных и др. Они

ориентированы на идентификацию функций и их уточнение сверху–вниз и после-

дующую разработку диаграмм потоков данных и описание процессов.

В методах объектно–ориентированного проектирования ключевую роль иг-

рает наследование, полиморфизм и инкапсуляция, а также абстрактные структуры

данных и представления объектов.

Методы проектирования от данных во главу угла при проектировании ставят

структуры данных, которыми должны манипулировать программы, и базируются

на применении методов Джексона, Варнье-Орра и др. для задания входных и вы-

ходных данных структурными диаграммами.

Методы компонентного проектирования ориентированы на построение про-

грамм-компонентов с четко описанными интерфейсами и зависимостями, которые

могут разрабатываться автономно (с ориентацией на их повторное использование)

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

посредством интерфейсов. Компонентное проектирование образует базис для дру-

гих видов проектирования и программирования, например, сервисно-

ориентированного.

В SWEBOK упоминаются также другие подходы к проектированию, включая

формальные методы проектирования и методы трансформации.

2.2.4. Область знаний «Конструирование программного обеспечения»

Конструирование ПО (Software Construction) – создание работающего ПО пу-

тем комбинирования методов кодирования, верификации, автономного и интегра-

ционного тестирования и отладки компонентов. Границы между конструировани-

ем, проектированием и тестированием ПО существенно варьируются в зависимости

от моделей ЖЦ и методологий разработки ПО.

Область знаний включает следующие разделы:

• основы конструирования ПО (Software Construction Fundamentals),

• управление конструирование ПО (Managing Construction),

• практические соображения (Practical Considerations).

Основу конструирования составляют концепции минимизации сложности

ПО, ожидания изменений (готовности к изменениям), облегчения проверки, соблю-

дения стандартов (внешних и внутренних).

Управление конструированием базируется на моделях конструирования,

планировании деятельности по конструированию и измерении артефактов процесса

конструирования.

Глава 2 63

Модели конструирования описывают спектр выполняемых действий, их по-

следовательность (взаимосвязь) и результаты. Виды моделей определяются приме-

нимыми стандартами ЖЦ, методологиями и приемами, например, Экстремальное

программирование или RUP

Планирование состоит в определении порядка создания и интеграции компо-

нентов, распределении задач между исполнителями и действий по обеспечению

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

конструирования.

Измерение в конструировании ориентировано на количественную оценку

объема кода (разработанного, модифицированного, повторно используемого, уда-

ленного), сложности кода; оценку статистических данных, касающихся верифика-

ции (инспекции) кода, интенсивности выявления и устранения дефектов в коде, а

также трудоемкости конструирования. Данные измерений используются для управ-

ления конструированием с целью совершенствования самого процесса конструиро-

вания и повышения качества кода.

Практические соображения в данной области знаний касаются следующих

проблем конструирования:

1) применение элементов проектирования в конструировании (особенно

детального проектирования) и рекомендаций по использованию подходов, предло-

женных в области знаний «Проектирование ПО»;

2) применение различных языков программирования и нотаций.

В SWEBOK представлены такие типы языков конструирования, как конфигу-

рационный язык (configuration language), позволяющий задавать параметры выпол-

нения программной системы; инструментальный язык (toolkit language) – язык

конструирования из повторно используемых компонентов в определенной инстру-

ментальной среде, а также язык программирования (programming language) – наи-

более гибкий тип языков конструирования.

Определены такие виды нотаций современных языков программирования:

– лингвистические нотации, основанные на строковых инструкциях и

предложениях для представления сложных программных конструкций;

– формальные нотации, основанные на точных, однозначных и формаль-

ных (математических) определениях;

– визуальные нотации, которые, в отличие от ориентированных на текст

лингвистических и формальных нотаций, основаны на непосредственном визуаль-

ном представлении элементов ПО (как, например, язык UML);

3) кодирование с соблюдением хорошего стиля кодирования, включающе-

го соглашения об именовании и структурировании исходного кода, использование

классов, перечисляемых типов, переменных, поименованных констант; организа-

цию исходного текста; использование структур управления, обработку ошибок и

исключительных ситуаций, организацию доступа к параллельно используемым ре-

сурсам, документирование кода и другие вопросы. В процессе конструирования

должны использоваться внешние стандарты применяемых языков программирова-

ния (например, Ада 95, С++ и др.), языков описания данных (XML, SQL и др.),

средств коммуникации (COM, CORBA и др.), интерфейсов компонентов (POSIX,

IDL, APL), сценариев (UML и др.);

Современные методологии конструирования (включая упоминаемые в SWEBOK)

детально описаны в главе 11.

64 Глава 2

4) применение элементов тестирования в конструировании. Проводится

две формы тестирования кода – модульное (автономное) и интеграционное. Виды

тестирования определены в отдельной специальной области знаний (см. ниже). Ре-

комендованы два стандарта тестирования элементов ПО и документирования этого

процесса - IEEE Std. 829:1998 «IEEE standard for software test documentation» и IEEE

Std. 1008:1987 «IEEE Standard for software unit testing»;

5) реализация повторного использования ПО, включая выбор элементов,

подлежащих повторному использованию, оценку потенциальной возможности по-

вторного использования кода и тестов, ведение информации и отчетности по по-

вторному использованию и других процедур, регламентируемых стандартом IEEE

Std.1517:1999 «IEEE Standard for Information Technology – Software Lifecycle Proc-

esses – Reuse Process»;

6) обеспечение качества кода путем применения не только модульного и

интеграционного тестирования, но и разработки, управляемой тестами, пошагового

кодирования (итеративного кодирования с тестированием), технических обзоров,

статического анализа и др.;

7) интеграция отдельно сконструированных процедур, классов, компонен-

тов и подсистем.

2.2.5. Область знаний «Тестирование программного обеспечения»

Тестирование ПО (Software Testing) заключается в проверке работы кода в

динамике на конечном (ограниченном) наборе тестов, охватывающих выбранное

подмножество сценариев использования ПО и тестовых данных, и сравнении по-

лученных результатов с ожидаемыми (ключевые слова – выделены курсивом).

Область знаний включает следующие разделы:

• основы тестирования (Software Testing Fundamentals),

• уровни тестирования (Test Levels),

• приемы тестирования (Test Techniques),

• метрики тестирования (Test-related Measures),

• процесс тестирования (Test Process).

Раздел Основы тестирования охватывает терминологию, основные пробле-

мы тестирования и связь с другими областями знаний в SWEBOK. Базовые понятия

в области тестирования определяются по стандарту IEEE Std. 610:1990 «Standard

Glossary of Software Engineering Terminology». Рассматриваются ключевые пробле-

мы, связанные с формированием критериев отбора (и адекватности) тестов, эффек-

тивности тестирования, идентификации дефектов, выбора «оракула» (который

принимает решение о том, прошел или не прошел тест), тестируемости и др.

В разделе Уровни тестирования указаны уровни объектов ПО, для которых

формируются тесты, и цели тестирования этих объектов. Выделены следующие

уровни тестирования:

– тестирование отдельных элементов (unit testing), которое заключается в

автономной проверке отдельных, изолированных и независимых частей ПО;

– интеграционное тестирование, ориентированно на проверку связей и

способов взаимодействия (интерфейсов) отдельных компонентов;

– тестирование системы предназначено для проверки правильности

функционирования системы в целом и выполнения сформулированных нефунк-

Глава 2 65

циональных требований (по безопасности, надежности и др.), а также правильности

внешних интерфейсов системы со средой окружения.

В разделе выделены такие наиболее распространенные и обоснованные цели

и, соответственно, виды тестирования: функциональное тестирование, регресси-

онное тестирование, тестирование эффективности, нагрузочное (стрессовое) тести-

рование, альфа и бета-тестирование, тестирование конфигурации, тестирование

производительности, надежности и др. К виду тестирования отнесены также мето-

ды проверки поведения системы на этапе испытаний ПО и его приемки.

В разделе Приемы (техники) тестирования представлена следующая клас-

сификация приемов тестирования:

– приемы, базирующиеся на интуиции и опыте исполнителя (тестирование

по опыту (ad hoc), исследовательское тестирование),

– приемы, базирующиеся на анализе спецификации (по формальным спе-

цификациям, на основе эквивалентного разделения программы на части, анализа

граничных значений, таблиц решений, анализа переходов состояний и др.),

– приемы, базирующиеся на анализе кода (покрытие условий и решений в

блок-схеме, анализ «жизненного цикла» переменных и др.),

– специальные приемы обнаружения дефектов (обнаружение дефектов на

основе анализа рисков, «подсев» дефектов, мутационное тестирование),

– приемы, базирующиеся на сценариях и условиях использования (по опе-

рационному профилю, по специализированным методикам испытаний системы - на

надежность, безопасность и др.),

– приемы, ориентированные на определенный тип и архитектурную при-

роду ПО (приемы объектно-ориентированного, компонентно-ориентированного,

Web-ориентированного тестирования, тестирования на соответствие протоколам,

тестирование систем реального времени и др.).

Измерения с помощью метрик, связанных с тестированием, используются

для анализа качества ПО, как инструмент оптимизации планирования и выполне-

ния тестов, а также для управления процессом тестирования.

Для оценки программ в ходе тестирования рекомендуются метрики программ

– размера, структурной сложности, частоты обращения к модулям; метрики (моде-

ли) дефектов и отказов - плотности дефектов, интенсивности отказов, роста надеж-

ности и др. Для оценки эффективности выполненных тестов рекомендуются метри-

ки покрытия/глубины тестирования, оценки результатов мутаций и подсева дефек-

тов, сравнительного анализа различных приемов тестирования.

В разделе Процесс тестирования указывается, что концепции, стратегии,

техники и измерения тестирования должны быть объединены в единый процесс

тестирования как деятельности по обеспечению качества на основе учета четырех

элементов и связанных с ними факторов: людей, инструментов, регламентов и ко-

личественных оценок (измерений). Базовый стандарт по процессам ЖЦ ISO/IEC

12207 не выделяет всю деятельность по тестированию в качестве единого самостоя-

тельного процесса, однако рассматривает соответствующие принципы работ по

тестированию как неотъемлемую часть процессов ЖЦ.

Составной частью формализации процесса тестирования и основой для сер-

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

(например, СММI) является документация тестирования. При ее составлении

SWEBOK рекомендует руководствоваться стандартом IEEE Std. 829:1998 «Standard