4.2 Модели качества процессов конструирования

Введение .......................................................................................................... 5
1 Основы программной инженерии .......................................................... 6
1.1 Кризисы программирования и возникновение программной
инженерии ....................................................................................................... 6
1.2 Программная инженерия и сущность инженерного подхода к
созданию программного обеспечения .......................................................... 8
1.3 Системная инженерия программного обеспечения ................... 10
1.4 Управление жизненным циклом программных средств ........... 14
1.4.1 Понятие жизненного цикла .............................................................. 14
1.4.2 Масштабы программных средств .................................................. 15
1.4.3 Классификация процессов жизненного цикла по ИСО/МЭК 1220718
1.4.4 Стадии разработки программных средств по ЕСПД .................. 19
1.4.5 Типичная схема управления процессом создания программного
обеспечения ..................................................................................................................... 22
1.5 Модели жизненного цикла ............................................................ 23
1.5.1 Каскадная (водопадная) модель ....................................................... 23
1.5.2 Итеративная и инкрементальная модель – эволюционный подход24
1.5.3 Спиральная модель ............................................................................ 27
2 Процессы жизненного цикла программного средства .................... 32
2.1 Управление требованиями к программному обеспечению ....... 32
2.1.1 Программные требования ................................................................ 32
2.1.2 Процесс управления требованиями ................................................. 38
2.1.3 Извлечение требований ..................................................................... 39
2.1.4 Анализ программных требований .................................................... 41
2.1.5 Документирование требований ....................................................... 43
2.1.6 Проверка требований (верификация и аттестация).................... 43
2.1.7 Измерение программных требований ............................................. 46
2.2 Проектирование программных средств ....................................... 46
2.2.1 Принципы проектирования............................................................... 46
2.2.2 Структура и архитектура программного обеспечения ............... 47
2.2.3 Анализ качества и оценка программного дизайна ......................... 50
2.2.4 Нотации проектирования ................................................................ 51
2.2.5 Подходы и методы проектирования программного обеспечения 53
2.2.6 Гибкие методы разработки ............................................................. 57
2.3 Использование UML в программной инженерии....................... 60
2.3.1 Основные компоненты UML ............................................................ 60
2.3.2 Диаграмма вариантов использования ............................................. 66
2.3.3 Диаграмма классов ............................................................................ 76
2.3.4 Диаграмма состояний ....................................................................... 90
2.3.5 Диаграмма деятельности............................................................... 103
2.3.6 Диаграмма последовательности ................................................... 108
2.3.7 Диаграмма кооперации ................................................................... 113
2.3.8 Диаграмма компонентов ................................................................ 114
2.3.9 Диаграмма развертывания ............................................................. 120
2.4 Тестирование программного обеспечения ................................ 126
2.4.1 Основы тестирования .................................................................... 126
2.4.2 Уровни тестирования ..................................................................... 129
2.4.3 Техники тестирования .................................................................... 132
2.4.4 Измерение результатов тестирования ........................................ 135
2.4.5 Процесс тестирования ................................................................... 137
2.5 Сопровождение программного обеспечения ............................ 139
2.5.1 Основы сопровождения программного обеспечения ................... 140
2.5.2 Ключевые вопросы сопровождения программного обеспечения 144
2.5.3 Процесс сопровождения ................................................................. 151
2.5.4 Техники сопровождения .................................................................. 155
2.6 Конфигурационное управление ................................................. 156
2.6.1 Управление SCM-процессом ........................................................... 156
2.6.2 Идентификация программных конфигураций .............................. 162
2.6.3 Контроль программных конфигураций ......................................... 165
2.6.4 Учет статусов конфигураций ....................................................... 167
2.6.5 Аудит конфигураций ....................................................................... 168
2.6.6 Управление выпуском и поставкой ................................................ 169
3 Инструменты и методы программной инженерии ......................... 171
3.1 Инструменты ................................................................................ 171
3.1.1 Инструменты работы с требованиями ....................................... 172
3.1.2 Инструменты проектирования и конструирования ................... 173
3.1.3 Инструменты тестирования ........................................................ 174
3.1.4 Инструменты сопровождения ...................................................... 175
3.1.5 Инструменты конфигурационного управления ........................... 175
3.1.6 Инструменты управления инженерной деятельностью............ 175
3.1.7 Инструменты поддержки процессов ........................................... 176
3.1.8 Инструменты обеспечения качества ........................................... 176
3.2 Методы .......................................................................................... 177
3.2.1 Эвристические методы .................................................................. 177
3.2.2 Формальные методы....................................................................... 177
3.2.3 Методы прототипирования .......................................................... 178
4 Качество и эффективность в программной инженерии ............... 179
4.1 Обеспечение качества программного обеспечения ................. 179
4.1.1 Качество программного продукта ................................................ 179
4.1.2 Культура и этика программной инженерии ................................ 179
4.1.3 Значение и стоимость качества ................................................... 180
4.1.4 Повышение качества ПС с использованием процессного подхода181
4.1.5 Показатели качества программных средств .............................. 182
4.1.6 Количественная оценка качества программного обеспечения .. 185
4.2 Модели качества процессов конструирования .......................... 186
4.2.1 Качество процессов......................................................................... 186
4.2.2 CMM/CMMI ...................................................................................... 187
4.2.3 TickIT ................................................................................................. 191
4.2.4 Прочие подходы ............................................................................... 193
4.3 Процессы управления качеством программного обеспечения 195
4.3.1 Подтверждение качества программного обеспечения .............. 196
4.3.2 Проверка (верификация) и аттестация ....................................... 196
4.3.3 Оценка и аудит ................................................................................ 197
4.3.4 Характеристика дефектов ............................................................ 200
4.3.5 Методы управления качеством программного обеспечения ...... 201
4.4 Стандартизация качества программного обеспечения ............ 203
4.4.1 Стандарты в сфере программной инженерии ............................ 203
4.4.2 Стандартизация программных продуктов в ЕСПД ................... 204
4.4.3 Виды стандартных программных документов ........................... 206
4.4.4 Действующие международные стандарты в сфере разработки
программных средств и информационных технологий ........................................... 209
4.5 Документирование программных средств ................................ 214
4.6 Сертификация программных средств ........................................ 214
4.6.1 Правовые акты по сертификации программных продуктов .... 214
4.6.2 Сертификация ПС ........................................................................... 216
4.6.3 Перечень объектов, подлежащих сертификации и их
характеристики ........................................................................................................... 217
Заключение ................................................................................................ 220
Библиография............................................................................................ 221
Введение
1 Основы программной инженерии
1.1 Кризисы
инженерии
программирования
и
возникновение
программной
На рубеже 60-х – 70-х годов прошлого века стоимость программного
обеспечения
стала
приближаться
к
стоимости
аппаратного
обеспечения
(компьютеров), а динамика её роста позволяла прогнозировать, что к середине 90годов все человечество будет заниматься разработкой программ Это событие
явилось первым кризисом программирования. Благодаря ему появилась идея для
сокращения
стоимости
программ
использовать
инженерные
методы
в
производстве программ, которая постепенно оформилась в программную
инженерию (или технологию программирования в нашей стране).
С тех пор программная инженерия бурно развивается. Причём этапы её
развития связаны с решением очередной системной проблемы:
1. Появление модульного подхода к программированию
На начальных этапах становления программной инженерии большие
затраты на создание программ часто были связаны с разработкой однотипных
фрагментов кода, поскольку в разных программах зачастую решались одинаковые
задачи. Очевидной идеей явилось использование при создании новых программ
ранее написанных фрагментов. В результате возник модульный подход к
программированию.
Суть модульного подхода к программированию состоит в выделении
типовых фрагментов и оформлении их в виде модулей. Каждый модуль
снабжается описанием, содержащим правила его использования в разделе
интерфейса модуля, который устанавливал связи модуля с основной программой.
Наиболее простыми в этом отношении оказались модули решения
математических
задач:
решения
уравнений,
систем
уравнений,
задач
оптимизации. К настоящему времени накоплены и успешно используются
большие библиотеки таких модулей.
Для
многих
других
типов
модулей
возможность
их
повторного
использования оказалась проблематичной в виду сложности их связей с основной
программой. Повторное использование модулей со сложными интерфейсами
является проблемой, достаточно актуальной и по сей день. Для ее решения
разрабатываются специальные формы (структуры) представления модулей и
организации их интерфейсов.
2. Формирование структурного подхода к программированию
В дальнейшем, с возникновением задач по созданию сложных программных
комплексов,
таких
как:
автоматизированные
системы
управления
производствами, системы управления сложными техническими объектами
(например,
самолётом)
и
т.д.
резко
выросла
сложность
программного
обеспечения. В результате объёмы программного кода, коллективы разработчиков
и количество модулей стали стремительно увеличиваться, что стало приводить к
крупным провалам и общему снижению эффективности разработки таких систем.
Оказалось, что львиная доля стоимости больших систем приходится не на их
создание, а на их внедрение и эксплуатацию. Появилась идея управления
жизненным
циклом
программного
продукта,
как
последовательностью
конкретных стадий: проектирования, разработки, тестирования, внедрения и
сопровождения.
Стадия сопровождения программного комплекса традиционно связан с
исправлением ошибок и внесением изменений в программу в соответствии с
изменившимися требованиями пользователей. Низкое качество программного
кода и, особенно, программной документации явились
причина высокой
стоимости (а порой и невозможности выполнения) сопровождения программного
комплекса. В результате сформировались основные принципы технологии
структурного проектирования, призванные обеспечить заданное качество и кода,
и документации:
– использование
нисходящего
функционального
проектирования,
основанном на методе пошаговой структурной декомпозиции;
– применение специальных языков проектирования, которые сейчас
принято называть CASE-средствами и средств автоматизации использования этих
языков;
– стандартизация всех этапов жизненного цикла программного комплекса;
– стандартизация оформления и содержания программных документов;
– отказ в программировании от свободного использования операторов
безусловного перехода.
3. Становление объектно-ориентированного подхода
Дальнейшее развитие программной инженерии высветило проблему
определения требований и управления ими, поскольку в отличие от других
инженерий, где заказчик – это обычно следующее звено в цепочке создания
продукта, в программной инженерии заказчик, как правило, – совершенно не
представляет конечную модель программного продукта и, соответственно, не
может сформулировать корректные требования к нему. В результате создание
программного продукта превратилось в его постоянную модернизацию и даже
перепроектирование.
Возникла
необходимость
обеспечения
возможности
внесений изменений в программу, не меняя ранее написанного кода.
Решением
указанной
проблемы
стало
использование
объектно-
ориентированного подхода к проектированию, основанного на понятии класса,
являющегося развитием понятия модуля с определенными свойствами и
поведением, характеризующими его. Каждый класс может порождать объекты –
экземпляры данного класса, которые поддерживают следующие механизмы:
1. Инкапсуляция – объединение в классе свойств и методов.
2. Наследование
–
возможность
порождения
нового
класса
из
существующего с частичным изменением свойств и методов.
3. Полиморфизм – определение свойств и методов объекта по контексту.
Объектно-ориентированный
подход
позволил
успешно
перейти
к
спиральной модели разработки программных продуктов, значительно снизив
потери от необходимости учёта всё новых требований заказчика.
Таким образом, развитие программной инженерии, направленной на
снижение себестоимости создания программ, стимулируется всё новыми
проблемами и очевидно ещё далеко от завершения.
1.2 Программная инженерия и сущность инженерного подхода к
созданию программного обеспечения
Программная инженерия – это интегрирование принципов информатики и
компьютерных
наук
с
инженерными
подходами,
разработанными
для
рассматриваться
как
материального производства.
Дисциплина
программной
инженерии
может
инженерная область, имеющая более тесные связи с компьютерными науками,
чем другие инженерные области. Среди инженерных дисциплин она выделяется
нематериальной природой программного обеспечения и его принципиальной
несводимостью к физическим процессам окружающего мира. Используя
достижения информатики, программная инженерия занимается решением задач
удешевления программных продуктов за счёт разработки методов массового
производства высококачественного программного обеспечения.
Термин «инженерия программного обеспечения» появился впервые в 1968
году на Конференции НАТО «Инженерия программного обеспечения» и
предназначался, чтобы спровоцировать размышления относительно текущего в то
время «кризиса программного обеспечения» [википедия].
В 1972 году IEEE* выпустил первый номер Transactions on Software
Engineering – Труды по Программной Инженерии. Первый целостный взгляд на
эту область профессиональной деятельности появился 1979 году, когда
Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 по качеству
программного обеспечения. После 7 лет напряженной работы, в 1986 году IEEE
выпустило IEEE Std 1002 “Taxonomy of Software Engineering Standards”.
Наконец,
в
1990
году
началось
планирование
всеобъемлющих
международных стандартов, в основу которых легли концепции и взгляды
стандарта IEEE Std 1074 и результатов работы образованной в 1987 году
совместной комиссии ISO/IEC JTC 1**. В 1995 году группа этой комиссии SC7
“Software Engineering” выпустила первую версию международного стандарта
ISO/IEC 12207 “Software Lifecycle Processes”. Этот стандарт стал первым опытом
создания единого общего взгляда на программную инженерию. Соответствующий
национальный стандарт России – ГОСТ Р ИСО/МЭК 12207-99 [ссылка] содержит
полный аутентичный перевод текста международного стандарта ISO/IEC 1220795 (1995 года).
В свою очередь, IEEE и ACM ***, начав совместные работы еще в 1993
году с кодекса этики и профессиональной практики в данной области (ACM/IEEECS Code of Ethics and Professional Practice), к 2004 году сформулировали два
ключевых описания того, что сегодня мы и называем основами программной
инженерии:
1.
Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE
2004 Version - Руководство к Своду Знаний по Программной Инженерии, в
дальнейшем просто “SWEBOK” [SWEBOK, 2004];
2.
Software Engineering 2004. Curriculum Guidelines for Undergraduate
Degree Programs in Software Engineering
– Учебный План для Преподавания
Программной Инженерии в ВУЗах* (данное название на русском языке
представлено в вольном смысловом переводе) [SE, 2004].
* IEEE - Computer Society of the Institute for Electrical and Electronic
Engineers, IEEE Computer Society – IEEE-CS (Компьютерное Общество) или
просто IEEE. http://www.ieee.org
** ISO – International Organization for Standardization. http://www.iso.ch ; IEC
– International Electrotechnical Commission; JTC 1 – Joint Technical Committee 1,
Information technology
*** ACM – Association of Computer Machinery
Оба стандарта стали результатом консенсуса ведущих представителей
индустрии и признанных авторитетов в области программной инженерии – по
аналогии с тем, как был создан PMI PMBOK.
Следовательно, программная инженерия возникла как ответ на кризисы
программирования и в качестве науки решает задачу повышения эффективности и
качества,
главным
образом,
самого
процесса
создания,
внедрения
и
сопровождения программных средств. В этой связи программная инженерия
гораздо шире, чем собственно программирование и является скорее практическим
применением, набирающей популярность в последнее время,
инженерии.
1.3 Системная инженерия программного обеспечения
системной
Системная
инженерия
–
это
практическое
применение
научных,
инженерных и управленческих навыков, необходимых для преобразования
операционных
требований
в
описание
конфигурации
системы,
которая
наилучшим образом удовлетворяет этим требованиям. Это общий процесс
решения проблем, который применяется ко всему техническому управлению в
проекте,
посвященном
разработке
системы,
предоставляя
механизм
формулирования и совершенствования определений изделий и процессов
системы.
Стандарт IEEE Std. 1220-1998 описывает процесс системной инженерии и
ее применение на протяжении всего цикла жизни изделия [Std. 1220-1998].
Системная инженерия порождает документы, а не оборудование. Документы
связывают процессы разработки с циклом жизни проекта. Они определяют
предполагаемые окружения процессов, интерфейсы и инструменты управления
рисками в рамках всего проекта.
Системная инженерия включает в себя пять функций.
 Определение проблемы – указание потребностей и ограничений путем
анализа требований и взаимодействия с заказчиком.
– Анализ
решений
–
выделение
набора
возможных
способов
удовлетворения потребностей и ограничений, их анализ и выбор оптимального.
– Планирование процессов – определение задач, которые должны быть
выполнены, объема ресурсов и затрат, необходимых для создания изделия,
очередности задач и потенциальных рисков.
– Контроль процессов – определение методов мониторинга проекта и
процессов, измерение прогресса, оценка промежуточных изделий и принятие по
мере необходимости корректирующих действий.
– Оценка изделий – определение качества и количества создаваемых
изделий путем оценочного планирования, тестирования, демонстрации, анализа,
верификации и контроля.
Системная инженерия формирует основу всего хода проекта разработки, а
также механизм определения пространства решений в терминах систем и
интерфейсов с внешними системами. Пространство решений описывает изделие
на самом высоком уровне, прежде чем требования к нему будут разделены на
аппаратную и программную составляющую.
Этот подход аналогичен присущей программной инженерии практике –
накладывать ограничения как можно позже в процессе разработки. Чем позже на
проект будут наложены ограничения, тем более гибким будет реализованное
решение.
Термин «системная инженерия программного обеспечения» (СИПО)
появился в начале 80-х годов, и его приписывают Уинстону Ройсу [Уинстону
Ройсу]. СИПО отвечает за общее техническое управление системой и
подтверждение корректности окончательных системных продуктов. Как и
системная инженерия, СИПО порождает документы, а не компоненты. В этом она
отличается от программной инженерии (ПрИ), порождающей компьютерные
программы и руководства пользователей.
СИПО начинается, когда системные требования разделены на аппаратные и
программные подсистемы. СИПО формирует основу для всей разработки
программного обеспечения в проекте и, как и ПрИ, представляет собой
одновременно и технический и управленческий процесс. Технический процесс
СИПО – аналитическая работа, необходимая для преобразования операционных
требований в:
– описание программной системы;
– дизайн программного обеспечения заданного размера, конфигурации и
качества;
– документацию программной системы в виде требований и спецификаций
для проектирования;
– процедуры, необходимые для верификации, тестирования и принятия
окончательного программного продукта;
– документацию, необходимую для его использования и сопровождения.
СИПО не является описанием работ. Это процесс, который выполняют
многие люди и организации: системные инженеры, менеджеры, программные
инженеры, программисты и, не стоит забывать пользователи.
По мере того как крупные системы все больше зависят от программ,
применение
методов
системной
инженерии
к
разработке
программного
обеспечения в состоянии помочь избежать существенных проблем.
Впрочем, разработчики программного обеспечения часто игнорируют эти
методы. Они считают, что чисто программные системы или системы, работающие
на массовых компьютерах, — всего лишь программные, а не системные проекты.
Игнорирование системных аспектов разработки программного обеспечения и
ведет к кризису.
SwSE и программная инженерия
И SwSE, и SwE — это технические и управленческие процессы, однако SwE
порождает программные компоненты и описывающую их документацию. Более
строго, программная инженерия включает в себя следующее.
– Практическое применение компьютерных дисциплин, менеджмента и
других наук к анализу, проектированию, конструированию и обслуживанию
программного обеспечения и связанной с ним документации.
– Наука инженерии, применяющая методы анализа, проектирования,
кодирования, тестирования, документирования и управления с целью создания
крупных,
удовлетворяющих
специфическим
требованиям
программ
в
определенное время и с определенными затратами.
– Систематическое применение методов, инструментов и методик,
которые позволяют выполнить оговоренные требования и добиться цели, создав
эффективную и полезную программную систему.
Рис. 1 иллюстрирует связи между системной инженерией, SwSE и SwE.
Традиционная системная инженерия выполняет первоначальный анализ и
проектирование, а также интеграцию и тестирование окончательной системы.
Во время первой стадии разработки SwSE отвечает за анализ требований к
программному обеспечению и архитектурный дизайн. SwSE также управляет
окончательным тестированием программных систем. Наконец, SwE управляет
тем, что системные инженеры называют инженерией компонентов.
SwSE и управление проектом
Процесс управления проектом включает в себя оценку рисков и затрат на
создание программной системы, определение графика выполнения, объединение
различных специалистов и инженерных групп, конфигурационное управление и
постоянный аудит, позволяющий гарантировать, что проект укладывается в сроки
и смету и соответствует техническим требованиям [6].
Рис. 2. Управленческие связи между системной инженерией программного обеспечения, программной инженерией и
проектным менеджментом
Рис.
2
иллюстрирует
управленческие
связи
между
проектным
менеджментом, SwSE и SwE. Руководство проектом включает в себя общее
управление распределением работ в проекте и полномочия предоставления
ресурсов. SwSE определяет технический подход, принимает технические
решения, взаимодействует с техническими представителями заказчика, а также
одобряет и принимает конечный программный продукт. SwE отвечает за
разработку программного дизайна, кодирование и разработку программных
компонентов.
1.4 Управление жизненным циклом программных средств
1.4.1 Понятие жизненного цикла
Жизненный цикл (ЖЦ) программного средства (ПС) определяется как
период времени, который начинается с момента принятия решения о
необходимости создания ПС и заканчивается в момент его полного изъятия из
эксплуатации. Такой подход соответствует закону жизненной кривой теории
систем. ПС обычно являются компонентами жизненного цикла технических
систем, но по своей природе значительно отличаются от технических изделий,
поэтому их жизненный цикл имеет характерные особенности, по сравнению с
другими техническими объектами.
Типовая модель процессов жизненного цикла сложной системы начинается
с концепции идеи системы или потребности в ней, охватывает проектирование,
разработку, применение и сопровождение системы, и заканчивается снятием
системы с эксплуатации. Программные средства служат для выполнения
определенных функций систем на компьютерах. Модель жизненного цикла
системы обычно разделяют на последовательные периоды реализации — стадии
или этапы. Каждый подобный период включает основные реализуемые в нем
процессы, работы и задачи, при завершении которых может потребоваться
переход к следующему периоду реализации. Общую модель жизненного цикла
сложной системы обычно разделяют на следующие основные этапы с
последующей адаптацией каждого из них в модели жизненного цикла конкретной
системы:
– определение потребностей;
– исследование и описание основных концепций;
– проектирование и разработка;
– испытания системы;
– создание и производство;
– распространение и продажа;
– эксплуатация;
– сопровождение и мониторинг;
– снятие с эксплуатации (утилизация).
1.4.2 Масштабы программных средств
По
особенностям
и
свойствам
жизненного
цикла
программ
их
целесообразно делить на ряд классов и категорий, из которых наиболее
различающимися являются два крупных класса – малые и большие.
Первый
класс
составляют
относительно
небольшие
программы,
создаваемые одиночками или небольшими коллективами (3–5) специалистов,
которые:
– создаются преимущественно для получения конкретных результатов
автоматизации научных исследований или для анализа относительно простых
процессов самими разработчиками программ;
– не предназначены для массового тиражирования и распространения как
программного продукта на рынке, их оценивают качественно и интуитивно
преимущественно как “художественные произведения”;
– не
имеют
конкретного
независимого
заказчика-потребителя,
определяющего требования к программам и их финансирование;
– не ограничиваются заказчиком допустимой стоимостью, трудоемкостью
и сроками их создания, требованиями заданного качества и документирования;
– не подлежат независимому тестированию, гарантированию качества
и/или сертификации.
Для таких, а также для многих других видов относительно не сложных
программ, нет необходимости в регламентировании их жизненного цикла, в
длительном применении и сопровождении множества версий, в формализации и
применении профилей стандартов и сертификации качества программ. Их
разработчики не знают и не применяют регламентирующих, нормативных
документов, вследствие чего жизненный цикл таких изделий имеет не
предсказуемый характер по структуре, содержанию, качеству и стоимости
основных процессов “творчества”.
Второй класс составляют крупномасштабные комплексы программ для
сложных систем управления и обработки информации, оформляемые в виде
программных
продуктов
с
гарантированным
качеством,
и
отличаются
следующими особенностями и свойствами их жизненного цикла:
– большая размерность, высокая трудоемкость и стоимость создания таких
комплексов
программ
определяют
необходимость
тщательного
анализа
экономической эффективности всего их жизненного цикла и возможной
конкурентоспособности на рынке;
– от заказчика, финансирующего проект программного средства и/или
базы
данных,
разработчикам
необходимо
получать
квалифицированные
конкретные требования к функциям и характеристикам проекта и продукта,
соответствующие выделенному финансированию и квалификации исполнителей
проекта;
– для
организации
и
координации
деятельности
специалистов-
разработчиков при наличии единой, крупной целевой задачи, создания и
совершенствования программного продукта, необходимы квалифицированные
менеджеры проектов;
– в проектах таких сложных программных средств и баз данных с
множеством различных, функциональных компонентов, участвуют специалисты
разной квалификации и специализации, от которых требуется высокая
ответственность за качество результатов деятельности каждого из них;
– от разработчиков проектов требуются гарантии высокого качества,
надежности функционирования и безопасности применения компонентов и
поставляемых программных продуктов, в которые не допустимо прямое
вмешательство заказчика и пользователей для изменений, не предусмотренных
эксплуатационной документацией разработчиков;
– необходимо
применять
индустриальные,
регламентированные
стандартами процессы, этапы и документы, а также методы, методики и
комплексы средства автоматизации, технологии обеспечения жизненного цикла
комплексов программ.
Такие крупномасштабные комплексы программ являются компонентами
систем, реализующими обычно их основные, функциональные свойства,
увеличивающими сложность и создающими предпосылки для последующих
изменений их жизненного цикла. Реализация ЖЦ, методологии управления и
изменения ПС зависит от многих факторов, от персонала, технических,
организационных и договорных требований и сложности проекта. Множество
текущих состояний и модификаций компонентов сложных ПС менеджерам
необходимо
участниками
упорядочивать,
проекта.
контролировать
Организованное,
их
развитие
контролируемое
и
применение
и
методичное
отслеживание динамики изменений в жизненном цикле программ и данных, их
слаженная разработка при строгом учете и контроле каждого изменения, является
основой эффективного, поступательного развития каждой крупной системы
методами программной инженерии.
Существует множество моделей процессов жизненного цикла систем и
программных средств, но три из них в международных стандартах обычно
квалифицируются
как
фундаментальные:
каскадная;
инкрементная;
эволюционная. Каждая из указанных моделей может быть использована
самостоятельно или скомбинирована с другими для создания гибридной модели
жизненного цикла конкретного проекта. При этом конкретную модель
жизненного цикла системы или ПС следует выбирать так, чтобы процессы и
задачи
были
связаны
между собой, и
определены
их
взаимосвязи
с
предшествующими процессами, видами деятельности и задачами.
1.4.3 Классификация процессов жизненного цикла по ИСО/МЭК 12207
Процесс определяется как совокупность взаимосвязанных действий,
преобразующих некоторые входные данные в выходные. Каждый процесс
характеризуется определенными задачами и методами их решения, исходными
данными, полученными от других процессов, и результатами.
Каждый процесс разделен на набор действий, каждое действие – на набор
задач. Каждый процесс, действие или задача инициируется и выполняется другим
процессом по мере необходимости, причем не существует заранее определенных
последовательностей выполнения (естественно, при сохранении связей по
входным данным).
Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие процесса
жизненного цикла [ГОСТ Р ИСО/МЭК 12207]:
Основные процессы:
– приобретение;
– поставка;
– разработка;
– эксплуатация;
– сопровождение.
Вспомогательные процессы:
– документирование;
– управление конфигурацией;
– обеспечение качества;
– верификация;
– аттестация;
– совместная оценка;
– аудит;
– разрешение проблем.
Организационные процессы:
– управление;
– усовершенствование;
– создание инфраструктуры;
– обучение.
1.4.4 Стадии разработки программных средств по ЕСПД
Теперь рассмотрим набор типовых стадий создания ПС, изучение которого
позволит понимать процесс разработки и более осознанно относиться к созданию
качества ПС. Эти стадии предусмотрены ГОСТ 19.102-77 ЕСПД. Стадии
разработки.
Стадии – наиболее укрупненные составляющие процесса разработки, для
завершения которых характерно получение ПО в определённой стадии
готовности.
Разработка ТЗ
Эскизный
проект
Технический
проект
Рабочий
проект
Внедрение
Рисунок
Выделяют следующие стадии разработки программного обеспечения:
1 Стадия технического задания (предпроектная стадия) состоит из:
 сбора исходных данных;
 определения цели разработки – желаемого набора основных свойств и
функций разрабатываемого ПС;
 обоснования и выбора критерия эффективности и качества разработки;
 формирования на верхнем уровне состава входной и выходной
документации по решаемой задаче;
 выбора принципиальных методов решения задач;
 определения
требований
к
комплексу
технических
средств
и
операционному окружению;
 определения инструментальных средств, используемых для разработки;
 планирования, т.е. декомпозиции процесса на стадии и этапы с
установлением сроков их выполнения;
 разработки документа, называемого «Техническое задание».
2 Эскизное проектирование
На данной стадии выполняется:
 детализация состава и структуры входной и выходной информации;
 детализация метода решения задач.
На этапе эскизного проектирования нужно создать предварительную
версию программного средства (возможно в виде модели) и выяснить
принципиальные
вопросы,
устраняя
возможные
разногласия
между
разработчиком и заказчиком. При этом выполняется:
 определение предварительной технологии решения задачи;
 прогнозирование эффективности решения задачи на конкретном
объекте;
 ведется освоение инструментальных средств (апробирование, обучение
персонала).
3 Техническое проектирование (технический проект)
На данном этапе:
 окончательно определяется состав и структура информации;
 разрабатывается интерфейс во всех его компонентах;
 технология решения задачи доводится автоматизма;
 полностью определяется конфигурация тех средств, на которых ведется
разработка ПС;
 определяется структура базы данных, где храниться информация о работе
ПС;
 разрабатывается
тестовый
набор
для
проверки
правильности
программной реализации;
 начинается разработка программной документации;
 полностью определяется структура ПС (модули, компоненты).
Технический проект может рассматриваться как постановка задачи,
передаваемой
специалистом-постановщиком
специалисту
по
программной
реализации.
4 Рабочее проектирование (рабочий проект)
Результат рабочего проектирования – получение ПС в состоянии
операционной готовности, в котором устранены синтаксические и семантические
ошибки, как в программном коде так и в программной документации.
Основные работы этой стадии:
 программная реализация (написание программного кода, привязка его к
специфике конкретного объекта, адаптация и настройка программных модулей);
 отладка (автономная – в лабораторных условиях и комплексная – на
объекте);
 разработка эксплуатационной документации;
 организация внедрения ПС.
5 Внедрение
На этапе внедрения осуществляют:
 подготовку персонала к эксплуатации;
 подготовку базы данных;
 проверку
эксплуатация);
работоспособности
ПС
на
реальных
данных
(опытная
 доводку
–
окончательное
устранение
всех
ошибок
в
коде
и
документации.
По отдельным компонентам может быть откат на предыдущие стадии.
В процессе разработки стадии могут объединяться. Объединяют эскизный и
технический или технический и рабочий проекты. Иногда могут сразу объединять
эскизный, технический и рабочий проекты. Обычно это производится, если в
разрабатываемом ПС можно использовать значительный объём предыдущих
разработок.
1.4.5 Типичная схема управления процессом создания программного
обеспечения
Управление процессами при разработке программного обеспечения в
общем случае реализуется по спиральной схеме и состоит из следующих
повторяемых действий [SWEBOK]:
 создание инфраструктуры процесса (Establish Process Infrastructure). На
данном этапе обеспечивается достижение согласия заинтересованных лиц
(обычно это руководство организации) в работах по реализации или изменению
процесса, определяется потребность в необходимых ресурсах и выполняется
распределение обязанностей (ответственности);
 планирование (Planning), в ходе которого формулируются текущие
бизнес-цели и потребности в процессе, необходимые отдельным специалистам,
проекту и/или организации, в целом, определяются и описываются сильные и
слабые стороны существующего процесса и планируемых на данной итерации
нововведений и/или изменений и разрабатывается план реализации и изменения
процесса;
 реализация и изменение процесса (Process Implementation and Change),
предусматривающая выполнение разработанного плана по внедрению нового
(усовершенствованного) процесса, в результате чего он процесс должен быть
внедрен в практику организации;
 оценка процесса (Process Evaluation), позволяющая выяснить уровень
качества реализации процесса, а также степень достижения ожидаемых эффектов
от его внедрения, после чего происходит либо выход, либо возвращение к первой
итерации.
РИСУНОК
1.5 Модели жизненного цикла
Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие модели
жизненного цикла [ГОСТ Р ИСО/МЭК 12207]:
– каскадная (водопадная) или последовательная;
– итеративная
и
инкрементальная
–
эволюционная
(гибридная,
смешанная);
– спиральная (spiral) или модель Боэма.
1.5.1 Каскадная (водопадная) модель
Данная модель предполагает строго последовательное (во времени) и
однократное
выполнение
всех
фаз
проекта
с
жестким
(детальным)
предварительным планированием в контексте предопределенных или однажды и
целиком определенных требований к программной системе.
Рисунок. Каскадная модель жизненного цикла.
На рисунке изображены типичные фазы каскадной модели жизненного
цикла и соответствующие активы проекта, являющиеся для одних фаз выходами,
а для других – входами.
Практика
показывает,
что
каскадная
модель
не
эффективна
для
большинства ИТ-проектов. В программной инженерии – высокая «подвижность»
требований, которые часто корректируются и уточняются, в силу невозможности
их четкого и однозначного определения требований до начала работ по
реализации. В каскадной модели переход от одной фазы проекта к другой
предполагает полную корректность результата (выхода) предыдущей фазы.
Однако, например, неточность какого-либо требования или некорректная его
интерпретация, в результате, приводит к тому, что приходится “откатываться” к
ранней фазе проекта и требуемая переработка не просто выбивает проектную
команду из графика, но приводит часто к качественному росту затрат и, не
исключено, к прекращению проекта в той форме, в которой он изначально
задумывался. Кроме того, эта модель не способна гарантировать необходимую
скорость отклика и внесение соответствующих изменений в ответ на быстро
меняющиеся потребности пользователей, для которых программная система
является одним из инструментов исполнения бизнес-функций. И таких примеров
проблем, порождаемых самой природой модели, можно привести достаточно
много.
Достоинство:
 наличие чёткого плана и временного графика по всем этапам проекта.
Недостатки:
 высокие издержки по причине частых откатов;
 реальные
проекты
часто
требуют
отклонения
от
стандартной
последовательности шагов;
 цикл основан на точной формулировке исходных требований к ПО
(реально в начале проекта требования заказчика определены лишь частично);
 результаты проекта доступны заказчику только в конце работы.
Сфера применения:
– программные средства, являющиеся элементами аппаратных систем,
требования к которым хорошо определены и изменяются не часто;
– программные
средства,
применяемые
в
оборонной,
медицинской,
космической или авиационной отрасли.
1.5.2 Итеративная и инкрементальная модель – эволюционный подход
Итеративная модель предполагает разбиение жизненного цикла проекта на
последовательность
итераций,
каждая
из
которых
представляет
собой
самостоятельный проект, но в миниатюре, включая все фазы жизненного цикла.
Цель каждой итерации – получение работающей версии программной системы,
включающей функциональность, определенную интегрированным содержанием
всех предыдущих и текущей итерации. Результатом финальной итерации является
версия ПС, которая реализует всю требуемую функциональность продукта. Таким
образом, с завершением каждой итерации, продукт развивается инкрементально.
Эволюционная модель подразумевает не только сборку работающей (с
точки зрения результатов тестирования) версии системы, но и её развертывание в
реальных операционных условиях с анализом откликов пользователей для
определения содержания и планирования следующей итерации.
Значимость эволюционного подхода на основе организации итераций особо
проявляется в снижении неопределенности с завершением каждой итерации. В
свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок
3 иллюстрирует некоторые идеи эволюционного подхода, предполагая, что
итеративному разбиению может быть подвержен не только жизненный цикл в
целом, включающий перекрывающиеся фазы – формирование требований,
проектирование, конструирование и т.п., но и каждая фаза может, в свою очередь,
разбиваться на уточняющие итерации, связанные, например, с детализацией
структуры декомпозиции проекта – например, архитектуры модулей системы.
Рисунок . Снижение неопределенности и инкрементальное расширение
функциональности при итеративной организации жизненного цикла.
Достоинства:
 снижение неопределённости в требованиях по мере проектирования,
позволяющее уменьшать число откатов;
 совмещение
относительно
строгой
последовательности
шагов
и
итеративного подхода обеспечивает достаточно сбалансированный по рискам
затрат план работ.
Недостатки:
 трудность прогнозирования сроков окончания проекта;
 возможность отката при интеграции отдельных компонентов, что может
приводить к откатам и связанным с ними затратам.
Сфера применения:
– программные средства, имеющие относительно несложную структуру в
несколько десятков модулей, компоненты которой можно достаточно легко
сочетать.
Наиболее известным и распространенным вариантом эволюционной модели
является спиральная модель, ставшая уже, по сути, самостоятельной моделью,
имеющей различные сценарии развития и детализации.
1.5.3 Спиральная модель
Спиральная модель была впервые сформулирована Барри Боэмом (Barry
Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели
является специальное внимание рискам, влияющим на организацию жизненного
цикла.
Боэм формулирует перечень наиболее распространенных (по приоритетам)
рисков [SWEBOK]:
 Дефицит специалистов.
 Нереалистичные сроки и бюджет.
 Реализация несоответствующей функциональности.
 Разработка неправильного пользовательского интерфейса.
 “Золотая
сервировка”,
перфекционизм,
ненужная
оптимизация
и
оттачивание деталей.
 Непрекращающийся поток изменений.
 Нехватка
информации
о
внешних
компонентах,
определяющих
окружение системы или вовлеченных в интеграцию.
 Недостатки в работах, выполняемых внешними (по отношению к
проекту) ресурсами.
 Недостаточная производительность получаемой системы.
 “Разрыв” в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными
аспектами взаимодействия специалистов в проектной команде.
Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки
по Боэму
В 2000 году [Boehm, 2000], представляя анализ использования спиральной
модели и, в частности, построенного на его основе подхода MBASE – ModelBased (System) Architecting and Software Engineering (MBASE), Боэм формулирует
6 ключевых характеристик или практик, обеспечивающих успешное применение
спиральной модели:
1.
Параллельное, а не последовательное определение артефактов
(активов) проекта
2.
Согласие в том, что на каждом цикле уделяется внимание:
o
целям и ограничениям, важным для заказчика
o
альтернативам организации процесса и технологических решений,
закладываемых в продукт
o
идентификации и разрешению рисков
o
оценки со стороны заинтересованных лиц (в первую очередь
заказчика)
o
достижению согласия в том, что можно и необходимо двигаться
дальше
3.
Использование соображений, связанных с рисками, для определения
уровня усилий, необходимого для каждой работы на всех циклах спирали.
4.
Использование соображений, связанных с рисками, для определения
уровня детализации каждого артефакта, создаваемого на всех циклах спирали.
5.
Управление жизненным циклом в контексте обязательств всех
заинтересованных лиц на основе трех контрольных точек:
 Life Cycle Objectives (LCO)
 Life Cycle Architecture (LCA)
 Initial Operational Capability (IOC)
6.
Уделение специального внимания проектным работам и артефактам
создаваемой системы (включая непосредственно разрабатываемое программное
обеспечение, ее окружение, а также эксплуатационные характеристики) и
жизненного цикла (разработки и использования).
Эволюционирование спиральной модели, таким образом, связано с
вопросами детализации работ. Особенно стоит выделить акцент на большем
внимании вопросам уточнения – требований, дизайна и кода, т.е. придание
большей важности вопросам итеративности, в том числе, увеличения их
количества при сокращении длительности каждой итерации.
В результате, можно определить общий набор контрольных точек в
сегодняшней спиральной модели:
 Concept of Operations (COO) – концепция <использования> системы;
 Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
 Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же
возможно
говорить
о
готовности
концептуальной
архитектуры
целевой
программной системы;
 Initial Operational Capability (IOC) – первая версия создаваемого
продукта, пригодная для опытной эксплуатации;
 FinalOperationalCapability (FOC) – готовый продукт, развернутый
(установленный и настроенный) для реальной эксплуатации.
Достоинства:
– большое
внимание
раннему
анализу
возможностей
повторного
использования;
– предоставляет механизмы достижения необходимых параметров качества
как составную часть процесса разработки программного продукта;
– большое внимание предотвращению ошибок и отбрасыванию ненужных,
необоснованных или неудовлетворительных альтернатив на ранних этапах
проекта, за счёт работ по анализу рисков, проверке различных характеристик
создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и
подтверждение возможности двигаться дальше на каждом “цикле” процесса
разработки;
– контроль источников проектных работ и соответствующих затрат;
– возможность использования модели как для разработки нового продукта,
так и для расширения (или сопровождения) существующего;
– возможность решения интегрированных задач системной разработки,
охватывающих и программную и аппаратную составляющие создаваемого
продукта.
Недостатки:
– высокая нагрузка на заказчика, который становится, по сути, участником
разработки;
– большая сложность в прогнозировании окончания проектных работ;
– наличие риска снижения качества финальной версии ПС по причине
отказа от последних итераций для снижения сроков разработки.
Сфера применения:
– программные средства широкого применения (операционные системы,
офисные программы, бизнес-приложения, игры и т.д.), разрабатываемые для
коммерческого
использования
небольших ошибок;
и
некритичные
к
некоторому
количеству
– программное обеспечение информационных систем, разработка которого
может без потерь продолжаться и в процессе сопровождения.
Следует отметить, что с позиций отечественных стандартов существует
только каскадная модель жизненного цикла, регламентированная в ГОСТ 19.10277. Однако форма изложения стандарта позволяет с некоторыми уточнениями
использовать его и для других моделей жизненного цикла.
2 Процессы жизненного цикла программного средства
2.1 Управление требованиями к программному обеспечению
2.1.1 Программные требования
Программные требования – свойства программного обеспечения, которые
должны быть надлежащим образом представлены в нём для решения конкретных
практических задач. Данная область знаний касается вопросов извлечения (сбора),
анализа, специфицирования и утверждения требований.
Опыт индустрии информационных технологий однозначно показывает, что
вопросы, связанные с управлением требованиями, оказывают критически-важное
влияние на программные проекты. Только систематичная работа с требованиями
позволяет корректным образом обеспечить моделирование задач реального мира
и формулирование необходимых приемочных тестов для того, чтобы убедиться в
соответствии создаваемых программных систем критериям, заданным реальными
практическими потребностями [Орлик].
Требование – условие или особенность, которой должна удовлетворять
система.
Требованием может быть:
– функциональность, необходимая заказчику или пользователю для
разрешения проблем (или получения прибыли);
– функциональность, которая должна быть реализована в системе в
соответствии с контрактом, стандартом, спецификацией, инструкцией или другим
официальным документом;
– ограничение, наложенное заинтересованным лицом.
2.1.1.1 Пирамида требований
В зависимости от формата, источника и общих характеристик, требования
могут быть разделены на различные типы. Несколько типов требований, наиболее
часто использующихся в проектах:
– потребности заинтересованного лица: требование от заинтересованного
лица;
– функциональная
функциональность,
особенность:
предоставляемая
системой
обычно формулируемая бизнес-аналитиком; назначение
особенности – удовлетворить потребности заказчика;
– сценарий Использования (Use Case): описание поведения системы в
терминах последовательности действий;
– дополнительное
требование:
другое
требование
(обычно
нефункциональное), которое не может быть охвачено сценариями использования;
– тестовые сценарии (Test Cases): спецификация тестовых исходных
данных, условий выполнения и ожидаемых результатов;
– сценарий (Алгоритм, Scenario): особая последовательность действий;
определенный путь по сценариям использования.
Эти типы требований могут быть представлены в виде пирамиды, как
показано на Рисунке 1.1.
На верхнем уровне располагаются потребности заинтересованного лица. На
последующих уровнях находятся функциональные особенности, сценарии
использования и дополнительные требования. Достаточно часто на разных
уровнях этих требований могут быть выяснены детали различного уровня. Чем
ниже уровень, тем более детально описывается требование.
Например, потребность может быть следующей: «Данные должны быть
неизменными».
Функциональная
особенность
этого
требования
будет:
«Система должна использовать реляционную базу данных». На уровне
дополнительных требований, требование еще более точное: «Система должна
использовать базу данных Oracle 9i».
Чем дальше вниз, тем более детальным становится требование. Один из
лучших способов управления требованиями – обобщать требования, по крайней
мере, на двух различных уровнях.
Например, документ Концепция («Vision») содержит высокоуровневые
требования
(особенности),
а
низшие
уровни
пирамиды
представляют
требования на более детальном уровне. У вышестоящих заинтересованных лиц
(таких, как вице-президент) нет времени читать 200 страниц детально
описанных требований. Но можно надеяться, что они смогут прочитать 12
страниц Концепции.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок. Пирамида требований.
Главное отличие между потребностями и функциональными особенностями
– в источнике требований. Потребности поступают от заинтересованных лиц, а
функциональные особенности формулируются бизнес-аналитиками.
Роль тестовых сценариев – проверить, корректно ли были реализованы
сценарии использования и дополнительные требования. Алгоритмы помогают
получить сценарии использования из тестовых сценариев, а также способствуют
проектированию
и
реализации
определенных
путей
через
сценарии
использования.
2.1.1.2 Характеристики программных требований
Перечислим основные характеристики программных требований:
Недвусмысленность
Должен существовать только один путь интерпретации требования. Иногда
двусмысленность проявляется в виде неопределенных акронимов.
Пример:
Треб.1: Система не должна принимать пароли более 15-ти символов.
Не совсем ясно, что система должна делать:
– Система не должна позволять пользователю вводить более чем 15
символов.
– Система должна отсекать введенную строку до 15-ти символов.
– Система не должна отображать сообщение об ошибке, если
пользователь вводит более чем 15 символов.
Исправленное требование содержит пояснение:
Треб.1: Система не должна принимать пароли более 15-ти символов. Если
пользователь вводит более 15-ти символов при выборе пароля, сообщение об
ошибке должно информировать пользователя о необходимом исправлении
пароля.
Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование
реализовано корректно. Тестирование должно быть либо пройдено, либо нет.
Чтобы быть пригодным для тестирования, требование должно быть ясным,
точным и недвусмысленным. Использование некоторых слов может сделать
требование невозможным для тестирования:
– Некоторые
прилагательные:
устойчивый,
безопасный,
точный,
эффективный,
целесообразный,
гибкий,
настраиваемый,
надежный,
дружелюбный, адекватный.
– Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
– Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Треб.1: Система должна препятствовать одновременному доступу
большого числа пользователей.
Какое количество здесь имеется в виду под «большим числом» - 10, 100 или
1000?
Ясность (Краткость, Сжатость, Простота, Точность)
Требования не должны содержать ненужных выражений или информации.
Они должны быть изложены кратко и просто:
Треб.1: Иногда пользователь будет вводить Airport Code (Код Аэропорта),
который система будет распознавать. Но иногда код можно заменить
близлежащим городом, и тогда пользователю не нужно знать код аэропорта,
т.к. система будет понимать название города.
Это предложение может быть заменено на более простое:
Треб.1: Система должна идентифицировать аэропорт на основании
Airport Code (Кода Аэропорта) или City Name (Названия Города).
Корректность
Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цены на аренду машин должны включать все соответствующие
налоги (включая налог штата - 6%)
Налог зависит от штата, так что представленная цифра в 6 % некорректна.
Понятность
Требования должны быть грамматически правильные, написаны в
соответствующем стиле. Должны быть использованы стандартные соглашения.
Слово «должен» должно быть использовано вместо «будет», «обязан» или
«может».
Реалистичность (Правдоподобность, Выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений,
таких как время, деньги и доступные ресурсы.
Треб.1: Система должна иметь интерфейс на естественном языке,
который будет понимать команды на английском языке.
Это требование может быть нереальным из-за короткого периода времени
разработки.
Независимость
Чтобы понять требование, не нужно знать какое-либо другое требование.
Треб.1: Список доступных рейсов должен включать номер рейса, время
отправления и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Слово «Он» во втором предложении относится к предыдущему требованию.
И если порядок требований изменить, это требование будет непонятно.
Элементарность
Требование должно содержать отдельный трассируемый элемент (для
которого возможно отслеживание связи):
Треб.1: Система должна предоставлять возможность бронировать рейс,
покупать билет, бронировать номер в гостинице, бронировать машину, а также
предоставлять информацию о развлечениях.
Это требование содержит пять элементарных требований, которые
затрудняют трассировку. Предложения, включающие предлоги «и» или «но»
должны быть пересмотрены на предмет разделениях их на элементарные
требования.
Необходимость
В требовании нет необходимости, если:
– ни одному заинтересованному лицу требование не нужно;
– удаление требования не повлияет на систему.
Пример требования, которое может быть удалено, т.к. оно не предоставляет
никакой новой информации:
Треб.1: Все требования, указанные в документе Концепции должны быть
реализованы и протестированы.
Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о дизайне и
реализации системы:
Треб.1: Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем
передаваться
пользователю,
должно
приниматься
дизайнерами
или
архитекторами системы.
Постоянство
Не должно существовать конфликтов между требованиями. Конфликты
могут быть прямые и косвенные.
Прямые конфликты возникают, когда ожидается различное поведение
системы в одной и той же ситуации:
Треб.1: Дата должна отображаться в формате мм/дд/гггг.
Треб.1: Дата должна отображаться в формате дд/мм/гггг.
Иногда возможно разрешить конфликт путем анализа условий, которые
явились источником данных требований. Например, если Треб.1 поступило от
американского пользователя, а Треб.2 от французского, то предыдущие
требования могут быть переписаны следующим образом:
Треб.1: Для пользователей США дата должна отображаться в формате
мм/дд/гггг.
Треб.2: Для пользователей Франции дата должна отображаться в
формате дд/мм/гггг.
Немногословность
Каждое требование должно быть обозначено только один раз, и не должно
перекрываться другим требованием:
Треб.1: Для удобства ввода даты рейса в системе должен быть доступен
календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при
вводе любой даты.
Первое требование (относящееся только к дате рейса) является частью
второго требования (относящееся к любой дате, вводимой пользователем).
Завершенность
Требование должно быть описано для всех возможных условий.
Хорошее
требование
должно
удовлетворять
как
можно
большему
количеству критериев. Однако они могут быть выражены в виде комбинации
вышеперечисленных критериев.
2.1.2 Процесс управления требованиями
Самое простое описание процесса управления требованиями содержит
следующие основные пункты:
–
формирование плана управления требованиями;
–
сбор требований;
–
разработка документа Концепции (Vision);
–
создание сценариев использования (Use Cases);
–
дополнительная спецификация;
–
создание тестовых сценариев (Test Cases) из сценариев использования
(Use Cases);
–
создание
тестовых
сценариев
спецификации;
–
проектирование системы.
(Test
Cases)
из
дополнительной
Первый шаг (план управления требованиями) определяет пирамиду
требований. На каждом из последующих семи шагов строится один элемент
пирамиды. Таблица 1.1. описывает, какие типы требований и какая документация
создаются на каждом шаге. Как Вы видите, процесс проходит через пирамиду
сверху вниз и слева направо.
Таблица 1.1. Требования и документы, созданные на каждом шаге.
Шаг
Сбор требований
Разработка документа
Концепции (Vision)
Создание сценариев
использования (Use cases)
Дополнительная
спецификация
Создание тестовых сценариев
(test cases) из сценариев
использования (use cases)
Создание тестовых сценариев
(test cases) из дополнительной
спецификации
Проектирование системы
Тип требований
Документы
Потребности
заинтересованного лица
Функциональные особенности
Запросы заинтересованного
лица
Концепция
Сценарии использования,
алгоритмы
Дополнительные требования
Тестовые сценарии
Спецификация Сценариев
Использования
Дополнительная
спецификация
Тестовые сценарии
Тестовые сценарии
Тестовые сценарии
Диаграммы классов,
диаграммы взаимодействий
UML-диаграммы
Управление требованиями – это интерактивный процесс. На типичной
итерации предполагается полное прохождение по пирамиде. На любой итерации
мы можем вернуться назад на несколько шагов и повторить действия. Например,
в процессе создания тестовых сценариев, мы можем обнаружить, что отсутствует
некоторая информация, и нам нужно получить ее от заинтересованного лица.
Таким образом, мы возвращаемся на шаг сбора требований. Для обеспечения
целостности модели, важно обновлять все соответствующие требования. На
начальных итерациях акцент делается на первых нескольких шагах (в вершине
пирамиды), а затем, на последующих итерациях, больше времени проводится на
низших уровнях пирамиды.
2.1.3 Извлечение требований
Идентификация заинтересованных лиц, их взаимодействия, выполняемых
ими бизнес-процессов ключевые вопросы, закладывающие основы успеха
проекта.
Необходимо идентифицировать все возможные источники требований,
значимые для решения задач проекта, к которым относят:
– цели;
– знания предметной области;
– заинтересованных лиц;
– операционное окружение;
– организационную среду.
Под заинтересованным лицом понимают личность, на которую оказывает
влияние разрабатываемая система. Два главных типа заинтересованных лиц – это
пользователи и заказчики. Пользователи – это лица, которые будут пользоваться
системой. Заказчики – лица, кто заказывает систему и отвечает в дальнейшем за
приемку системы. Обычно заказчики платят за разработку системы. Кроме
заказчиков и пользователей, есть и другие типы заинтересованных лиц.
В качестве заинтересованного лица можно рассматривать:
–
участников
разработки
системы
(бизнес-аналитики,
дизайнеры,
кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению,
дизайнеры сценариев использования, графические дизайнеры);
– поставщиков знаний в систему (эксперты предметной области, авторы
документов, которые были использованы для сбора требований, собственники
веб-сайтов, ссылки на которые были предоставлены);
– руководство (президент компании, которого представляют заказчики,
директор отдела информационных технологий компании, проектирующей и
разрабатывающей систему);
– обслуживающий персонал, вовлеченный в управление, настройку и
сопровождение системы (хостинговая компания, справочная служба).
– поставщики стандартов и регламентов (стандарты устанавливаются
поисковыми механизмами согласно содержанию веб-сайта, политическим
нормам, а также порядку налогообложения в конкретном штате).
После
идентификации
источников
требований,
производится
сбор
требований, являющийся, сложным и конфликтным процессом извлечения
информации из источников. Выделяют следующие причины, которые приводят к
дальнейшим ошибкам и потерям на качестве ПС:
– недопонимание между аналитиком и заинтересованными лицами;
– упущение некоторых аспектов, изначально кажущихся второстепенными;
– неоднозначность
или
некорректность
интерпретации
информации,
полученной от заинтересованных лиц.
Существует множество практик и подходов, позволяющих добиться
действительно
стройной
системы
требований,
отвечающих
реальным
потребностям и приоритетам заказчиков:
– интервьюрирование – традиционный подход извлечения требований
посредствам опроса экспертов, в роли которых выступают пользователи или
другие заинтересованные лица;
– использование
сценариев –
моделирование
ситуаций
для
сбора
пользовательских требований, определяющих ответы на вопросы «что если» и
«как это делается» в отношении бизнес-процессов, реализуемых пользователями;
– создание прототипов – инструмент для постепенного перехода от
«бумажных» моделей до пилотных подсистем, реализуемых как самостоятельные
проекты или бета-версий продуктов, при этом прототипы могут постепенно
трансформироваться в результаты проекта и использоваться для проверки и
утверждения требований;
– разъясняющие встречи – мероприятия, в ходе которых заинтересованные
лиц совместно с аналитиками ищут пути решения проблем, определения и
предупреждения рисков и т.п.;
– наблюдение – непосредственное присутствие аналитиков и инженеров
рядом с пользователем в процессе выполнения последним его работ по
обеспечению функционирования бизнес-процессов;
Существуют и другие, достаточно эффективные практики, описание
которых можно найти в литературе и которые вы, наверняка, сами используете в
своей работе.
2.1.4 Анализ программных требований
При
анализе
требований
происходит
трансформация
информации,
полученной от заинтересованных лиц в четко и однозначно определенные
требования, передаваемые инженерам для реализации в программном коде.
Анализ требований включает:
– обнаружение и разрешение конфликтов между требованиями;
– определение границ задачи, решаемой создаваемым программным
обеспечением;
– детализация системных требований для установления программных
требований.
Вне зависимости от выразительных средств, которые являются лишь
инструментом анализа и фиксирования результатов, результатом анализа
требований должны быть однозначно интерпретируемые требований, реализация
которых проверяема, а стоимость и ресурсы – предсказуемы.
Требования могут классифицироваться по следующим параметрам:
– функциональные и нефункциональные требования;
– внутренние (с другими требованиями) или внешние зависимости;
– требования к процессу или продукту;
– приоритет требований;
– содержание
требований
в
отношении
конкретных
подсистем
создаваемого программного обеспечения;
– изменяемость/стабильность требований.
Разработка
модели
проблемы
реального
мира
(концептуальное
моделирование) – ключевой элемент анализа требований. Цель моделирования –
понимание проблемы, задачи и методов их решения до того, как начнется
решение проблемы.
Объем моделей, их детализация и средства представления могут быть
различны. Их выбор диктуется предпочтениями и компетенциями организаций,
вовлеченных в проект.
Среди факторов, которые влияют на выбор модели, метода и детализации её
представления, степени связанности с программным кодом и другими вопросами:
– природа проблемы (проблемной области);
– экспертиза и опыт инженеров;
– требования заказчика к процессу;
– доступность методов и инструментов;
– внутрикорпоративные стандарты и регламенты;
– культура разработки.
Вопросы моделирования тесно связаны с применяемыми методами и
подходами.
Поэтому,
частные
методы
или
нотации,
обычно
следуют
распространенным в индустрии практикам и тяготеют к тем формам, с которыми
связаны накопленный опыт и подтвержденные общепринятой практикой знания.
Архитектурное
проектирование
очень
близко
к
концептуальному
моделированию. Непосредственное отображение бизнес-сущностей реального
мира на программные компоненты не является обязательным, поэтому и
существует такое разделение между моделированием и проектированием.
Деятельность по моделированию определяет порядок проектирования (то, «что»
надо сделать), а архитектура – процедуры («как» это будет реализовано).
2.1.5 Документирование требований
Для
сложных
систем
существует
целый
комплекс
документов
(спецификаций), которые являются результатом сбора и анализа требований, их
моделирования
и
архитектурного
проектирования.
Управление
этими
документами требует их анализа, изменения, пересмотра и утверждения. Обычно
для описания требований в комплексных проектах используется три основных
документа (спецификации):
– определение системы;
– системные требования;
– программные требования.
2.1.6 Проверка требований (верификация и аттестация)
Определение требований напрямую связано с процедурами проверки и
утверждения (аттестации или валидации, как это сформулировано в ГОСТ Р и
ISO/IEC 12207). Без этих процедур требования считаются не полностью
описанными, поскольку определены способы их проверки (при верификации) и
утверждения (при аттестации).
Если стандарты жизненного цикла описывают как правильно создавать
продукт, то стандарты (в том числе, внутрикорпоративные) отвечают за создание
правильного продукта, то есть того продукта, который соответствует ожиданиям
пользователей и других заинтересованных лиц. Для достижения этой цели
применяются следующие методы:
Обзор требований
Один из распространенных методов проверки требований - инспекция или
обзор требований. Суть его заключается в том, что ряд лиц, вовлеченных в проект
(для крупных проектов – специально выделенные специалисты), “вычитывают”
требования в поисках необоснованных предположений, описаний требований,
допускающих множественные интерпретации, противоречий, несогласованности,
недостаточной степени детализации, отклонений от принятых стандартов и т.п.
Прототипирование
В общем случае, прототипирование подразумевает проверку инженерной
интерпретации программных требований и извлечение новых требований,
неопределенных или неясных на ранних итерациях сбора требований. Существует
множество подходов к прототипированию, как с точки зрения детализации, так и
того, чему уделяется внимание при прототипировании. Наиболее часто
прототипы создаются для оценки способа реализации пользовательского
интерфейса и проверки архитектурных подходов и решений.
При всей безусловной полезности прототипирования для обеспечения
проверки требований и решений, необходимо понимать, что с прототипированием
связан ряд вопросов способных привести к негативным последствиям или, как
минимум, работам, требующим дополнительного времени и средств. Среди
возможных
негативных
последствий
прототипирования
стоит
выделить
следующие:
– смещение внимания с целевых функций прототипа и, как следствие,
неудовлетворенность пользователей огрехами прототипа, отсутствием стоящей за
ним
реальной
функциональности
(для
интерфейса), ошибками в прототипе и т.п.;
прототипов
пользовательского
– превращение прототипа в реальную систему за счет постоянного
добавления новых свойств и функциональности “для проверки” – часто бывает
нарушена
архитектурная
целостность,
необеспеченная
необходимая
масштабируемость и качество получаемого программного продукта;
– переключение внимания заинтересованных лиц на эргономику и детали
дизайна графического пользовательского интерфейса с начальной цели выявления
функциональных и иных требований.
Аттестация
Аттестация модели связана с вопросами обеспечения приемлемого качества
продукта. Уверенность в соответствии модели заданным требованиям может быть
закреплена формально со стороны пользователей/заказчика. В то же время,
проверка
и
аттестация
модели,
например,
объектно-ориентированного
представления бизнес-сущностей и связей между ними может быть проведена с
той или иной степенью использования формальных методов. Это – другая сторона
утверждения модели.
Приемочные тесты
Требования должны быть верифицируемы. Требования, которые не могут
быть проверены и аттестованы, могут выступать только в форме рекомендаций,
даже если они очень важны для пользователей. Если описанное требование не
сопровождается процедурами проверки – в большинстве случаев говорят о
недостаточной
детализации
или
неполном
описании
требования
и,
соответственно, спецификация требований должна быть отправлена на доработку
и если необходимо, должны быть предприняты дополнительные усилия,
направленные на сбор требований.
Можно говорить о том, что процедура анализа требований считается
выполненной только тогда, когда все требования, включенные в спецификацию,
обладают методами оценки соответствия им создаваемого программного
продукта. Чаще всего столь строгое ограничение на степень законченности
спецификации накладывается на функциональные требования и атрибуты
качества (например, время отклика системы).
Идентификация и разработка приемочных тестов для нефункциональных
требований часто оказывается наиболее трудоемкой задачей. Для ее решения
обычно “ищут точку опоры”, то есть возможность взгляда на описываемые
требования с количественной точки зрения, в плоть до переформулирования и
большей степени детализации описания таких требований.
2.1.7 Измерение программных требований
Для обеспечения качества программных требований полезно иметь методы,
определяющие «объем» требований для создаваемого программного продукта.
Такая
оценка
полезна
для
исследования
предполагаемых
изменений
в
требованиях, оценки стоимостных характеристик разработки и поддержки
программной системы, опосредовано – оценки продуктивности разработки и
эффективности поддержки на этапах реализации требований и внесения
изменений и т.п. [Орлик]
2.2 Проектирование программных средств
Проектирование в основном рассматривается как двух-шаговый процесс
[Орлик]:
– Архитектурное проектирование – декомпозиция структуры (статической)
и организации (динамической) компонент;
– Детализация архитектуры – описывает специфическое поведение и
характеристики отдельных компонент.
Выходом этого процесса является набор моделей и артефактов, содержащих
результаты
решений,
принятых
по
способам
реализации
требований
в
программном коде.
2.2.1 Принципы проектирования
В качестве основных принципов проектирования выделим следующие:
Абстракция
Абстракция – отвлечение в процессе познания от несущественных сторон,
свойств, связей объекта (предмета или явления) с целью выделения их
существенных,
закономерных
признаков;
абстрагирование;
обобщение как результат такого отвлечения [википедия].
теоретическое
Абстракция – модель, упрощающая поставленную проблему до рамок,
значимых для заданного контекста [орлик].
В контексте проектирования программных систем существует два
механизма абстракции – параметризация и детализация. При этом, абстракция
через детализацию может быть: процедурной (связанной с поведением),
абстракцией данных (связанной с информацией) и абстракцией контроля
(связанной с управлением системой и обрабатываемой ею информацией).
Связанность и соединение
Связанность – определяет силу взаимосвязи между модулями. Соединение
– определяет взаимосвязь элементов внутри модуля, внутренние связи.
Декомпозиция и разбиение на модули
Декомпозиция и разбиение на модули сложных программных систем
производится с целью получения более мелких и относительно независимых
программных
компонентов,
каждый
из
которых
несет
различную
функциональность.
Инкапсуляция
Предполагает группировку и упаковку элементов и внутренних деталей
абстракции в отношении реализации с тем, чтобы эти детали были недоступны
пользователям элементов. В качестве «пользователя» одного компонента может
выступать другой компонент. Более того, при использовании объектноориентированного подхода, наследники компонентов могут не иметь доступа ко
внутренним деталям реализации компонента, который является их предком.
Разделение интерфейса и реализации
Данная
техника
предполагает
отделение
компонента
через
специфицирование интерфейса, известного и доступного клиентам (или другим
компонентам), от непосредственных деталей реализации.
Достаточность, полнота и простота
Создаваемые
программные
компоненты
должны
обладать
всеми
необходимыми характеристиками, определенными абстракцией (моделью), но не
должны включать функциональность, отсутствующую в модели.
2.2.2 Структура и архитектура программного обеспечения
Архитектура программного обеспечения – описание подсистем, компонент
программной системы и связей между ними. Архитектура задаёт способ, которым
программная система организована.
На сегодняшний день сформировался взгляд на архитектуру, как на
приложение общих принципов организации программных компонент, что
привело
к
накоплению
множества
подходов
и
созданию
различных
архитектурных «фреймворков», то есть систематизированных комплексов
методов, практик и инструментов, призванных формализовать имеющийся в
индустрии опыт.
Фреймворк
(англ. framework —
каркас,
структура) —
структура
программной системы; программное обеспечение, облегчающее разработку и
объединение разных компонентов большого программного проекта. В отличие от
библиотек, которые объединяют набор подпрограмм близкой функциональности,
фреймворк содержит в себе большое количество разных по назначению
библиотек. Употребляется также слово «каркас», а некоторые авторы используют
его в качестве основного, в том числе не базируясь вообще на англоязычном
аналоге. Можно также говорить о каркасном подходе[3] как о подходе к
построению программ, где любая конфигурация программы строится из двух
частей: первая, постоянная часть — каркас, не меняющийся от конфигурации к
конфигурации и несущий в себе гнезда, в которых размещается вторая,
переменная часть — сменные модули (или точки расширения) [википедия].
Примеры такой систематизации в форме фреймворков:
TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на
момент первичного написания данной главы доступен в версии 8.1, впервые
опубликованной в декабре 2003 года; в 2009 году вышла версия TOGAF 9)
Модель Захмана – Zachman Framework [Zachman]
Руководство по архитектуре электронного правительства E-Gov Enterprise
Architecture Guidance [E-Gov, 2002]
2.2.2.1 Архитектурные структуры и точки зрения
Принцип сужения предметной области с использованием точки зрения
[пособие по ТССА] широко используется в программной инженерии. Система
может рассматриваться с разных точек зрения – поведенческой, структурной,
логической, физической и т.п. Следовательно, можно получить множество
различных архитектурных представлений. Архитектурное представление может
быть
определено,
как
частные
аспекты
программной
архитектуры,
рассматривающие специфические свойства программной системы. Дизайн
системы – комплекс архитектурных представлений, достаточный для реализации
системы и удовлетворения требований, предъявляемых к системе.
Архитектурная структура – применение архитектурной точки зрения и
представления к конкретной системе и описания тех деталей, которые
необходимы для реализации системы, но отсутствуют
в используемом
представлении. Таким образом, представление, концентрируясь на заданном
подмножестве свойств является составной частью и/или результатом точки
зрения, а архитектурная структура – дальнейшей детализацией в отношении
проектируемой системы [орлик]. В качестве примера архитектурных точек зрения
можно рассматривать модель Захмана [Zachman].
2.2.2.2 Архитектурные стили
Архитектурный стиль – это мета-модель или шаблон проектирования
макро-архитектуры
Архитектурный
–
стиль
на
–
уровне
набор
модулей,
«крупноблочного»
ограничений,
определяющих
взгляда.
семейство
архитектур, которые удовлетворяют этим ограничениям [орлик].
2.2.2.3 Шаблоны проектирования
Архитектурный стиль определяет макро-архитектуру системы, а шаблоны
проектирования задают микро-архитектуру, то есть определяют частные аспекты
деталей архитектуры.
Чаще всего говорят о следующих группах шаблонов проектирования:
– Шаблоны создания (Creational patterns) - builder, factory, prototype,
singleton
– Структурные шаблоны (Structural patterns) - adapter, bridge, composite,
decorator, facade, flyweight, proxy
– Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator,
mediator, memento, observer, state, strategy, template, visitor
2.2.2.4 Семейства программ и фреймворков
Один из возможных подходов к повторному использованию архитектурных
решений и компонент заключается в формировании линий продуктов на основе
общего дизайна. В объектно-ориентированном программировании аналогичную
смысловую нагрузку несут «фреймворки», обеспечивающие решение одних и тех
же задач – например, внутренней организации компонентов пользовательского
интерфейса или общей логики работы распределенных систем [орлик].
2.2.3 Анализ качества и оценка программного дизайна
2.2.3.1 Атрибуты качества
Атрибуты для оценки качественного дизайна ПС можно разбить на
следующие группы:
– применимые во время выполнения системы, например, среднее время
отклика системы;
– используемые в режиме разработки, например, среднее количество
методов в классе, среднее количество свойств объекта и т.д.;
– атрибуты качества архитектурного дизайна, например, концептуальная
целостность дизайна, непротиворечивость, полнота, завершенность.
Существуют атрибуты, которые сложно измерить, например, такой как
безопасность.
Не стоит путать атрибуты качества дизайна с атрибутами качества,
фигурирующими в ряду требований, предъявляемых к системе. Часть из них
может отображаться друг на друга и нести эквивалентную смысловую нагрузку,
некоторые могут быть связаны, большая часть атрибутов является специфичной
именно для дизайна и не связана с требованиями [орлик].
2.2.3.2 Анализ качества и техники оценки
Известно немало различных инструментов и методов, предназначенных для
формирования качественного дизайна ПС:
– обзор дизайна, например, неформальный обзор архитектуры членами
проектной команды;
– статический анализ, например, трассировка с требованиями;
– симуляция и прототипирование – динамические техники проверки
дизайна в целом или отдельных его атрибутов качества; например, для оценки
производительности используемых архитектурных решений при симуляции
нагрузки, близкой к прогнозируемым пиковым [орлик].
2.2.3.3 Измерения
Измерения
используются
для
количественной
оценки
ожиданий
в
отношении различных аспектов конкретного дизайна, например, сложности
структуры ПС или качества требований, предъявляемых к производительности.
Обычно метрики разделяют на 2 класса:
– функционально-ориентированные;
– объектно-ориентированные [орлик].
2.2.4 Нотации проектирования
Нотация – система условных обозначений, принятая в какой-либо области
знаний или деятельности. Нотация включает множество символов используемых
для представления понятий и их взаимоотношений, составляющее алфавит
нотации, а также правила их применения [википедия].
Следовательно, нотация – соглашение о представлении некоторой
абстракции в визуальной (графической) форме. Нотация может задаваться:
– стандартом;
– общепринятой практикой;
– внутренним методом проектной команды.
Определенные
нотации
используются
на
стадии
концептуального
проектирования, ряд нотаций ориентирован на создание детального дизайна,
многие могут использоваться на обеих стадиях. Кроме того, нотации чаще всего
используют в контексте применяемой методологии или подхода [орлик].
2.2.4.1 Структурные описания
Следующие нотации, в основном, являются графическими, описывая и
представляя структурные аспекты программного дизайна:
– языки описания архитектуры, такие как текстовые языки, обычно
используемые для описания программной архитектуры в терминах компонентов;
– диаграммы классов и объектов, применяемые для представления набора
классов и связей между ними (например, наследования);
– диаграммы компонентов используемые для
представления набора
компонентов и связей между ними с учётом того, что компонент в отличие от
класса является реализуемым элементом;
– карточки
функциональности
и
связей
класса,
используемые
для
обозначения имени класса, его функции и связей с другими сущностями
(классами, компонентами и т.п.);
– диаграммы развёртывания, применяемые для представления физических
узлов, связей между ними и моделирования других физических аспектов системы;
– диаграммы
сущность-связь,
служащие
для
представления
информационной модели или концептуальной модели данных, хранимых в ходе
работы информационной системы;
– языки
определения
описания
(определения)
интерфейсов
интерфейса,
программных
предназначенные
компонентов
(имён
и
для
типов
экспортируемых или публикуемых операций);
– структурные диаграммы Джексона, описывающие структуры данных в
терминах последовательности, выбора и итераций (повторений);
– структурные схемы, применяемые для описания структуры вызовов в
программах [орлик].
2.2.4.2 Поведенческие (динамические) описания
Рассмотрим нотации и языки, используемые для описания динамического
поведения программных систем и их компонентов:
– диаграммы деятельности или операций, применяемые для описания
потоков работ и управления;
– диаграммы
сотрудничества,
демонстрирующие
динамическое
взаимодействие, осуществляемое в группе объектов и концентрирующиеся на
объектах, связях между ними и сообщениях, которыми обмениваются объекты
посредством этих связей;
– диаграммы потоков данных, описывающие потоки данных внутри набора
процессов;
– таблицы
и
диаграммы
принятия
решений,
используемые
для
представления сложных комбинаций условий и действий (операций);
– схемы алгоритмов и структурированные схемы алгоритмов, служащие для
представления потоков управления (контроля) и связанных операций;
– диаграммы
последовательности,
демонстрирующие
взаимодействие
внутри группы объектов по времени;
– диаграммы перехода и карты состояний, применяемые для описания
потоков управления переходами между состояниями;
– формальные языки спецификации или текстовые языки, использующие
основные понятия из математики для строгого и абстрактного определения
интерфейсов и поведения программных компонентов;
– псевдокод
и
программные
языки
проектирования,
описывающие
поведение процедур и методов, в основном на стадии детального проектирования
[орлик].
2.2.5 Подходы и методы проектирования программного обеспечения
Различают
подходы
и
методы
проектирования
ПС.
Подходы
к
программированию определяют стратегию работ по проектированию. В отличие
от
подходов,
методы
проектирования
более
специфичны,
предлагая
и
предоставляя нотации для использования совместно с этими методами, а также
процессы, которым необходимо следовать в рамках используемого метода.
Таким образом, методы выступают как более общие понятия, это –
методологии, сконцентрированные на процессе и предполагающие следование
определенным правилам и соглашениям, в том числе – по используемым
выразительным
средствам.
Такие
методы
полезны
как
инструмент
систематизации (иногда, формализации) и передачи знаний в виде общего
фреймворка не только для отдельных специалистов, но для команд и проектных
групп программных проектов.
2.2.5.1 Общие подходы
Наиболее часто используются следующие общепринятые подходы:
– метод пошаговой декомпозиции;
– нисходящий и восходящий подход к проектированию;
– абстракция и инкапсуляция;
– итеративный и инкрементальный подход.
Метод пошаговой декомпозиции
Структурный
подход требует представления задачи в виде иерархии
подзадач простейшей структуры. Для получения такой иерархии применяется
метод пошаговой детализации, который заключается в следующем:
– определяется общая структура программы в виде одного из трех
вариантов:
– последовательности подзадач (например, ввод данных, преобразование
данных, вывод данных),
– альтернативы подзадач (например, добавление записей к файлу или их
поиск),
– повторения подзадачи (например, циклически повторяемая обработка
данных);
– каждая подзадача, в свою очередь, разбивается на подзадачи с
использованием тех же структур;
– процесс продолжается, пока на очередном уровне не получается
подзадача, которая достаточно просто реализуется средствами используемого
языка (1 - 2 управляющих оператора языка).
Нисходящий и восходящий подход к проектированию
Нисходящим методом проектирование программы ведется от общего к частному, ко все большей детализации на каждом этапе. При этом сначала определяется задача в целом, в виде последовательности этапов, реализующих
самостоятельные смысловые части алгоритма. Затем она поэтапно детализируется. Процесс детализации алгоритма продолжается до тех пор, пока реализуемые части алгоритма не станут достаточно простыми и легко програм-
мируемыми. Результатом этого процесса может быть структура программы. Это
направленный граф, определяющий взаимосвязи подпрограмм в виде блоков
подпрограмм и их вызовов. На последнем этапе каждый модуль представляется в
виде детального описания его функций, например с помощью схемы алгоритма.
Схема алгоритма – это направленный граф, который определяет процесс
обработки данных.
Альтернативным методом по отношению к методу нисходящего проектирования является метод восходящего проектирования. При этом вначале разрабатываются модули низшего уровня, а затем они объединяются с помощью
модулей более высокого уровня. Сложные программные системы восходящим
методом создавать значительно труднее и дольше, чем нисходящим. На практике
часто используют смешанный метод, т. е. в основном используют метод
нисходящего проектирования, а в некоторых случаях, по мере необходимости, –
восходящее проектирование.
Абстракция и инкапсуляция
Абстракция – это придание объекту характеристик, которые четко
определяют его концептуальные границы, отличая от всех других объектов.
Основная идея состоит в том, чтобы отделить способ использования составных
объектов данных от деталей их реализации (инкапсуляция) в виде более простых
объектов, подобно тому, как функциональная абстракция разделяет способ
использования функции и деталей её реализации в терминах более примитивных
функций, таким образом, данные обрабатываются функцией высокого уровня с
помощью вызова функций низкого уровня [2].
Инкапсуляция
пользователю
программного
не
–
свойство
задумываться
компонента,
а
языка
о
программирования,
сложности
реализации
взаимодействовать
с
ним
позволяющее
используемого
посредством
предоставляемого интерфейса, а также объединить и защитить жизненно важные
для компонента данные. При этом пользователю предоставляется только
интерфейс — спецификация объекта.
Итеративный и инкрементальный подход
Итеративный подход – выполнение работ параллельно с непрерывным
анализом полученных результатов и корректировкой предыдущих этапов работы.
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл:
Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act
cycle).
Преимущества итеративного подхода:
– снижение воздействия серьёзных рисков на ранних стадиях проекта, что
ведет к минимизации затрат на их устранение;
– организация эффективной обратной связи проектной команды с
потребителем (а также заказчиками, стейкхолдерами) и создание продукта,
реально отвечающего его потребностям;
– акцент усилий на наиболее важные и критичные направления проекта;
– непрерывное
итеративное
тестирование,
позволяющее
оценить
успешность всего проекта в целом;
– раннее обнаружение конфликтов между требованиями, моделями и
реализацией проекта;
– более равномерная загрузка участников проекта;
– эффективное использование накопленного опыта;
– реальная оценка текущего состояния проекта и, как следствие, большая
уверенность заказчиков и непосредственных участников в его успешном
завершении.
– затраты распределяются по всему проекту, а не группируются в его
конце [1].
2.2.5.2 Функционально-ориентированное (структурное)
проектирование
Классический
метод
проектирования,
в
котором
декомпозиция
сфокусирована на идентификации основных программных функций и, затем,
детальной разработке и уточнении этих функций “сверху-вниз”. Структурное
проектирование, обычно, используется после проведения системного анализа с
применением диаграмм потоков данных, функциональных моделей и схем
алгоритмов.
2.2.5.3 Объектно-ориентированное проектирование
Представляет собой совокупность методов проектирования, базирующихся
на концепции объектов. Главную роль в ООП играют полиморфизм и
инкапсуляция, наследование и абстракция.
2.2.5.4 Проектирование на основе структур данных
В данном подходе фокус сконцентрирован в большей степени на структурах
данных, которыми управляет система, чем на функциях системы. Инженеры по
программному обеспечению часто вначале описывают структуры данных входов
и выходов, а, затем, разрабатывают структуру управления этими данными (или,
например, их трансформации).
2.2.5.5 Компонентное проектирование
Данный подход призван решить задачи использования, разработки и
интеграции
программных
компонент
с
целью
повышения
повторного
использования активов. Компонентно-ориентированное проектирование является
одной из наиболее динамично развивающихся концепций проектирования.
2.2.6 Гибкие методы разработки
Гибкие методы разработки ПО появились в 90-е годы 20-го века в качестве
альтернативы
формальным
методологиям,
перегруженных
значительным
объёмом документирования и проверок, которые зачастую, особенно небольших
коммерческих проектах, неэффективны. Основными положениями гибких
методов являются следующее:
– индивидуальные
методы
и
взаимодействие
вместо
процессов
и
программных средств;
– работающее ПО вместо сложной документации;
– взаимодействие с заказчиком вместо жестких контрактов;
– реакция на изменения вместо следования плану.
Гибкие
методологии
предполагают
создание
небольших,
самоорганизующихся команд, состоящих из высококвалифицированных и
энергичных людей, ориентированных на бизнес.
Экстремальное программирование
Самым
известным
гибким
методом
является
экстремальное
программирование (Extreme Programming или сокращенное название – XP),
созданный специалистом в области программной инженерии Кентом Беком в
результате его работы в 1996-1999 годах над системой контроля платежей
компании "Крайслер".
Модель процесса по XP выглядит как частая последовательность выпусков
продукта, столь частых, сколь это возможно. Но при этом обязательно, чтобы в
выпуск входила новая функциональность. Основные принципы организации
процесса по XP:
– планирование, основанное на принципе, что разработка ПО является
диалогом между возможностями и желаниями, при этом изменятся и то и другое;
– простой дизайн – против избыточного проектирования;
– метафора – суть проекта должна умещаться в 1-2 емких фразах или в
некотором образе;
– рефакторинг – процесс постоянного улучшения (упрощения) структуры
ПО, необходимый в связи с добавлением новой функциональности;
– парное программирование – один программирует, другой думает над
подходом в целом, о новых тестах, об упрощении структуры программы и т.д.;
– коллективное владение кодом – все участники проекта должны уметь
писать код;
– участие заказчика в разработке – представитель заказчика входит в
команду разработчика;
– создание и использование стандартов кодирования в проекте – при
написании кода используются стандарты на имена идентификаторов, составление
комментариев и т.д.;
– тестирование – разработчики сами тестируют свое ПО, перемежая этот
процесс с разработкой (при этом рекомендуется создавать тесты до того, как
будет
реализована
соответствующая
функциональность
с
привлечением
заказчика);
– непрерывная
интеграция
последовательность выпусков;
–
разработка
представляется
как
– 40-часовая рабочая неделя.
Однако в полном объеме XP не была использована даже ее авторами. Кроме
того, известны и внедряются отдельные практики XP, как, например, парное
программирование, коллективное владение кодом, рефакторинг кода. Однако
идея простого, неизбыточного дизайна проекта также оказала значительное
влияние на мир разработчиков ПО.
Более практичным гибким методом разработки является Scrum.
Метод схватки или Scrum
В 1986 японские специалисты Hirotaka Takeuchi и Ikujiro Nonaka
опубликовали сообщение о новом подходе к разработке новых сервисов и
продуктов (не обязательно программных). Основу подхода составляла сплоченная
работа небольшой универсальной команды, которая разрабатывает проект на всех
фазах. Приводилась аналогия из регби, где вся команда двигается к воротам
противника как единое целое, передавая (пасуя) мяч своим игрокам как вперед,
так и назад. В начале 90-х годов данный подход стал применяться в программной
индустрии и обрел название Scrum (термин из регби, означающий – схватка), в
1995 году Jeff Sutherland и Ken Schwaber представили описание этого подхода на
OOPSLA '95 – одной из самых авторитетных конференций в области
программирования. С тех пор метод активно используется в индустрии и
многократно описан в литературе. Scrum активно используется также в России.
Общее описание. Метод Scrum позволяет гибко разрабатывать проекты
небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся
требований. При этом процесс разработки итеративен и предоставляет большую
свободу команде. Кроме того, метод очень прост – легко изучается и применяется
на практике. Его схема изображена на рисунке.
Рис. 11.1.
Вначале создаются требования ко всему продукту. Потом из них
выбираются самые актуальные и создается план на следующую итерацию. В
течение итерации планы не меняются (этим достигается относительная
стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается
созданием работоспособной версии продукта (рабочий продукт), которую можно
предъявить заказчику, запустить и подемонстрировать, пусть и с минимальными
функциональными возможностями. После этого результаты обсуждаются и
требования к продукту корректируются. Это удобно делать, имея после каждой
итерации продукт, который уже можно как-то использовать, показывать и
обсуждать. Далее происходит планирование новой итерации и все повторяется.
2.3 Использование UML в программной инженерии
2.3.1 Основные компоненты UML
UML
представляет
собой
методологию
или
язык
визуального
моделирования, разработанный для описания, визуализации, проектирования и
документирования компонентов программного обеспечения, бизнес-процессов и
других систем. UML является простым и мощным средством моделирования,
используемым для построения концептуальных, логических и графических
моделей сложных систем различного назначения. Язык вобрал в себя наилучшие
подходы программной инженерии. Использование UML основывается на
понимании общих принципов моделирования сложных систем и особенностей
процесса объектно-ориентированного анализа и проектирования, таких как
абстригирование, принцип неполноты модели и принцип её иерархического
построения.
Рис. 3.1. Общая схема взаимосвязей моделей и представлений сложной
системы в процессе объектно-ориентированного анализа и проектирования
Основные задачи, решаемые с помощью UML:
1. Реализация
функционала
языка
визуального
моделирования,
предназначенного для разработки и документирования моделей сложных систем.
Благодаря чему системный анализ прочно вошёл в практику проектирования и
объектно-ориентированный
подход
постепенно
стал
доминирующим
в
программной инженерии.
2. Обеспечение возможности расширения и специализации UML для
повышения качества моделирования систем в предметной области.
3. Независимость UML от конкретных языков программирования и
инструментальных средств проектирования программных систем, что означает,
что конструкции языка UML не должны зависеть от особенностей их реализации
в применяемых языках программирования.
4. Наличие семантического базиса в описании UML для понимания общих
особенностей ООП, что означает претензию UML на понимание общих
принципов ООП.
5. Обеспечение
развития
рынка
объектно-ориентированных
инструментальных средств за счёт популяризации UML и распространение
объектно-ориентированных технологий и соответствующих понятий ООАП.
6. Интеграция в UML последних достижений объектно-ориентированных
технологий за счёт его дальнейшей интеграции с другими современными
технологиями моделирования и методами программной инженерии.
Описание UML состоит из двух взаимодействующих частей, таких как:
 семантика языка UML, представляющая собой метамодель, которая
определяющую синтаксис и семантику понятий объектно-ориентированного
моделирования с использованием UML;
 нотация
языка
UML,
реализуемую
графической
нотацией
для
визуального представления семантики UML.
Абстрактный синтаксис и семантика UML описываются с использованием
некоторого подмножества нотации. В дополнение к этому, нотация UML
описывает соответствие или отображение графической нотации в базовые
понятия семантики. Таким образом, с функциональной точки зрения эти две части
дополняют друг друга. При этом семантика UML описывается на основе
метамодели, имеющей три отдельных представления: абстрактный синтаксис,
правила корректного построения выражений и семантику. Рассмотрение
семантики языка UML предполагает не полностью формализованный стиль
изложения, объединяющий естественный и формальный языки для представления
базовых понятий и правил их расширения.
Семантика определяется для двух видов объектных моделей: структурных
моделей и моделей поведения. Структурные (статические) модели описывают
структуру сущностей или компонентов некоторой системы, включая их классы,
интерфейсы, атрибуты и отношения. Модели поведения (динамические модели)
описывают поведение объектов системы, включая их методы, взаимодействие и
связи между ними, а также процесс смены состояний компонентов и системы в
целом.
Нотация UML включает в себя описание отдельных семантических
элементов, которые могут применяться при построении диаграмм. Формальное
описание UML основывается на общей иерархической структуре модельных
представлений, состоящей из четырех уровней:
 мета-метамодель;
 метамодель;
 модель;
 объекты пользователя.
Верхний уровень является основой для всех метамодельных представлений.
Назначение уровня состоит в определении языка для спецификации метамодели.
Мета-метамодель определяет модель UML на самом высоком уровне абстракции
и является наиболее компактным ее описанием. Мета-метамодель может
описывать несколько метамоделей.
Метамодель является экземпляром мета-метамодели. Главная задача уровня
метамодели – определение языка для формирования моделей. Данный уровень
обладает более развитой семантикой базовых понятий. Основные понятия UML
относятся как раз к уровню метамодели. Примеры таких понятий — класс,
атрибут, операция, компонент, ассоциация и многие другие.
Модель в контексте UML является экземпляром метамодели в том смысле,
что любая конкретная модель системы должна использовать только понятия
метамодели, конкретизировав их применительно к данной ситуации. Это уровень
для описания информации о конкретной предметной области. Однако если для
построения модели используются понятия языка UML, то необходима полная
согласованность понятий уровня модели с базовыми понятиями языка UML
уровня метамодели. Примерами понятий уровня модели могут служить имена
соответствующих
информационных
атрибутов,
например,
имена
полей
проектируемой базы данных, такие как имя и фамилия сотрудника, возраст,
должность, адрес, телефон.
Конкретизация понятий модели происходит на уровне объектов. Объект
является экземпляром модели, поскольку содержит конкретную информацию
относительно того, чему в действительности соответствуют те или иные понятия
модели. Примером объекта может служить следующая запись в проектируемой
базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 1000000".
Метамодель UML является больше логической моделью, чем физической
или моделью реализации. Особенность логической модели заключается в том, что
она концентрирует внимание на декларативной или концептуальной семантике,
опуская детали конкретной физической реализации моделей. При этом отдельные
реализации, использующие данную логическую метамодель, должны быть
согласованы с ее семантикой, а также поддерживать возможности импорта и
экспорта отдельных логических моделей.
В то же время, логическая метамодель может быть реализована различными
способами для обеспечения требуемого уровня производительности и надежности
соответствующих инструментальных средств. В этом заключается недостаток
логической модели, которая не содержит на уровне семантики требований,
обязательных
для
ее
эффективной
последующей
реализации.
Однако
согласованность метамодели с конкретными моделями реализации является
обязательной для всех разработчиков программных средств, обеспечивающих
поддержку UML.
В рамках UML все представления о модели сложной системы фиксируются
в виде специальных графических конструкций, получивших название диаграмм. В
терминах UML определены следующие виды диаграмм:
–
диаграмма вариантов использования (use case diagram);
–
диаграмма классов (class diagram);
–
диаграммы поведения (behavior diagrams);
–
–
диаграмма состояний (statechart diagram);
–
диаграмма деятельности (activity diagram);
–
диаграммы взаимодействия (interaction diagrams);
–
диаграмма последовательности (sequence diagram);
–
диаграмма кооперации (collaboration diagram);
диаграммы реализации (implementation diagrams);
–
диаграмма компонентов (component diagram);
–
Диаграмма развертывания (deployment diagram).
Из перечисленных выше диаграмм некоторые служат для обозначения двух
и более других подвидов диаграмм. При этом в качестве самостоятельных
представлений в языке UML используются следующие диаграммы:
 диаграмма вариантов использования;
 диаграмма классов;
 диаграмма состояний;
 диаграмма деятельности;
 диаграмма последовательности;
 диаграмма кооперации;
 диаграмма компонентов;
 диаграмма развертывания.
Перечень этих диаграмм и их названия представляют собой неотъемлемую
часть графической нотации языка UML. Более того, процесс ООП неразрывно
связан с процессом построения этих диаграмм. При этом совокупность
построенных таким образом диаграмм содержит практически всю информацию,
которая необходима для реализации проекта сложной системы.
Каждая из этих диаграмм детализирует и конкретизирует различные
представления о модели сложной системы в терминах языка UML.
Диаграмма вариантов использования представляет собой наиболее общую
концептуальную модель сложной системы, которая является исходной для
построения всех остальных диаграмм.
Диаграмма классов является, по своей сути, логической моделью,
отражающей статические аспекты структурного построения сложной системы.
Диаграммы поведения также являются разновидностями логической
модели, которые отражают динамические аспекты функционирования сложной
системы.
Диаграммы реализации служат для представления физических компонентов
сложной системы и поэтому относятся к ее физической модели.
Таким образом, интегрированная модель сложной системы в нотации UML
представляется в виде совокупности указанных выше диаграмм.
Рис. 3.10. Интегрированная модель сложной системы в нотации UML
2.3.2 Диаграмма вариантов использования
Визуальное
моделирование
в
UML
представляет
собой
процесс
декомпозиции абстрактного описания системы: от наиболее обшей и абстрактной
концептуальной модели исходной системы к логической, а затем и к физической
модели соответствующей программной системы. Причём первым этапом на
данном пути является так называемая диаграмма вариантов использования (use
case
diagram),
которая
описывает
основную
логическую
структуру
и
функциональное назначение системы. Диаграмма вариантов использования
является исходным концептуальным представлением или концептуальной
моделью системы в процессе ее проектирования и разработки. Наиболее близким
аналогом диаграммы вариантов использования является мнемосхема, обычно
используемая в функционально-ориентированном моделировании.
Разработка диаграммы производится с целью:
 определения границ и связей с внешней средой моделируемой
предметной области;
 выяснения основных требований к поведению проектируемой системы;
 формирования концептуальной модели системы для ее последующей
детализации в форме логических и физических моделей;
 разработки
компонентов
документации
для
разработчиков системы с ее заказчиками и пользователями.
взаимодействия
Суть диаграммы вариантов использования состоит в представлении
проектируемой
системы
в
виде
множества
сущностей
или
актеров,
взаимодействующих с системой с помощью вариантов использования. При этом
актером
(actor)
или
действующим
лицом
называется
любая
сущность,
взаимодействующая с системой извне: человек, техническое устройство,
программа или любая другая система, которая может служить источником
воздействия на моделируемую систему. Вариант использования (use case) служит
для описания сервисов, которые система предоставляет актеру и определяет
некоторый набор действий, совершаемый системой при диалоге с актером.
Способы
взаимодействия
актеров
с
системой
в
диаграмме
вариантов
использования не конкретизируются.
Графически диаграмма вариантов использования представляет собой граф,
который
является
нотацией
для
представления
конкретных
вариантов
использования, актеров, возможно некоторых интерфейсов, и отношений между
этими элементами. Отдельные компоненты диаграммы могут быть заключены в
прямоугольник,
Отношениями
который
данного
обозначает
графа
могут
проектируемую
быть
только
систему
в
фиксированные
целом.
типы
взаимосвязей между актерами и вариантами использования, которые в
совокупности
описывают
сервисы
или
функциональные
требования
к
моделируемой системе.
Конструкция или стандартный элемент языка UML вариант использования
применяется для спецификации общих особенностей поведения системы или
любой другой сущности предметной области без рассмотрения внутренней
структуры
этой
сущности.
Каждый
вариант
использования
определяет
последовательность действий, которые должны быть выполнены проектируемой
системой при взаимодействии ее с соответствующим актером. Диаграмма
вариантов может дополняться пояснительным текстом, который раскрывает
смысл или семантику составляющих ее компонентов. Такой пояснительный текст
получил название примечания или сценария.
Отдельный вариант использования обозначается на диаграмме эллипсом,
внутри которого содержится его краткое название или имя в форме глагола с
пояснительными словами (рис. 4.1).
Рис. 4.1. Графическое обозначение варианта использования
Примерами вариантов использования могут являться следующие действия:
проверка состояния текущего счета клиента, оформление заказа на покупку
товара, получение дополнительной информации о кредитоспособности клиента,
отображение графической формы на экране монитора и другие действия.
Актер
представляет
собой
любую
внешнюю
по
отношению
к
моделируемой системе сущность, которая взаимодействует с системой и
использует ее функциональные возможности для достижения определенных
целей
или
решения
частных
задач.
Актеры
служат
для
обозначения
согласованного множества ролей, которые могут играть пользователи в процессе
взаимодействия с проектируемой системой. Актер может рассматриваться как
отдельная роль относительно конкретного варианта использования. Стандартным
графическим обозначением актера на диаграммах является фигурка «человека»,
под которой записывается конкретное имя актера (рис. 4.2).
Рис. 4.2. Графическое обозначение актера
Имя актера должно быть достаточно информативным с точки зрения
семантики. Вполне подходят для этой цели наименования должностей в компании
(например, продавец, кассир, менеджер, президент). Не рекомендуется давать
актерам имена собственные (например, «А.С. Пушкин») или моделей конкретных
устройств (например, «компьютер Pentium Intel Core 2 Duo 2700»), даже если это
с очевидностью следует из контекста проекта.
Так как в общем случае актер всегда находится вне системы, его внутренняя
структура никак не определяется. Для актера имеет значение только его внешнее
представление, т. е. то, как он воспринимается со стороны системы. Актеры
взаимодействуют с системой посредством передачи и приема сообщений от
вариантов использования. Сообщение представляет собой запрос актером сервиса
от системы и получение этого сервиса. Это взаимодействие может быть выражено
посредством
ассоциаций
между
отдельными
актерами
и
вариантами
использования или классами. Кроме этого, с актерами могут быть связаны
интерфейсы, которые определяют, каким образом другие элементы модели
взаимодействуют с этими актерами.
Два и более актера могут иметь общие свойства, т. е. взаимодействовать с
одним и тем же множеством вариантов использования одинаковым образом.
Такая общность свойств и поведения представляется в виде рассматриваемого
ниже отношения обобщения с другим, возможно, абстрактным актером, который
моделирует соответствующую общность ролей.
Интерфейс (interface) служит для спецификации параметров модели,
которые видимы извне без указания их внутренней структуры. В языке UML
интерфейс является классификатором и характеризует только ограниченную
часть поведения моделируемой сущности. Применительно к диаграммам
вариантов использования, интерфейсы определяют совокупность операций,
которые обеспечивают необходимый набор сервисов или функциональности для
актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни
направленных ассоциаций. Они содержат только операции без указания
особенностей их реализации. Формально интерфейс эквивалентен абстрактному
классу без атрибутов и методов с наличием только абстрактных операций.
На диаграмме вариантов использования интерфейс изображается в виде
маленького круга, рядом с которым записывается его имя (рис. 4.3, а). В качестве
имени может быть существительное, которое характеризует соответствующую
информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще
строка текста (например, "запрос к базе данных", "форма ввода", "устройство
подачи звукового сигнала"). Если имя записывается на английском, то оно
должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor
(рис. 4.3, б).
Рис. 4.3. Графическое изображение интерфейсов на диаграммах вариантов
использования
Примечания (notes) в языке UML предназначены для включения в модель
произвольной текстовой информации, имеющей непосредственное отношение к
контексту разрабатываемого проекта. В качестве такой информации могут быть
комментарии разработчика (например, дата и версия разработки диаграммы или
ее отдельных компонентов), ограничения (например, на значения отдельных
связей или экземпляры сущностей) и помеченные значения. Применительно к
диаграммам вариантов использования примечание может носить самую общую
информацию, относящуюся к общему контексту системы.
Графически примечания обозначаются прямоугольником с "загнутым"
верхним правым уголком (рис. 4.5). Внутри прямоугольника содержится текст
примечания. Примечание может относиться к любому элементу диаграммы, в
этом случае их соединяет пунктирная линия. Если примечание относится к
нескольким элементам, то от него проводятся, соответственно, несколько линий.
Разумеется, примечания могут присутствовать не только на диаграмме вариантов
использования, но и на других канонических диаграммах.
Рис. 4.5. Примеры примечаний в языке UML
Между
компонентами
диаграммы
вариантов
использования
могут
существовать различные отношения, которые описывают взаимодействие
экземпляров одних актеров и вариантов использования с экземплярами других
актеров и вариантов. Один актер может взаимодействовать с несколькими
вариантами использования. В этом случае этот актер обращается к нескольким
сервисам данной системы. В свою очередь один вариант использования может
взаимодействовать с несколькими актерами, предоставляя для всех них свой
сервис. Следует заметить, что два варианта использования, определенные для
одной и той же сущности, не могут взаимодействовать друг с другом, поскольку
каждый из них самостоятельно описывает законченный вариант использования
этой сущности. Более того, варианты использования всегда предусматривают
некоторые сигналы или сообщения, когда взаимодействуют с актерами за
пределами системы. В то же время могут быть определены другие способы для
взаимодействия с элементами внутри системы.
В языке UML имеется несколько стандартных видов отношений между
актерами и вариантами использования:
 отношение ассоциации (association relationship);
 отношение расширения (extend relationship);
 отношение обобщения (generalization relationship);
 отношение включения (include relationship).
При
этом
общие
свойства
вариантов
использования
могут
быть
представлены тремя различными способами, а именно с помощью отношений
расширения, обобщения и включения.
Отношение ассоциации является одним из фундаментальных понятий в
языке UML и в той или иной степени используется при построении всех
графических моделей систем в форме канонических диаграмм.
Применительно к диаграммам вариантов использования оно служит для
обозначения специфической роли актера в отдельном варианте использования.
Другими словами, ассоциация специфицирует семантические особенности
взаимодействия актеров и вариантов использования в графической модели
системы. Таким образом, это отношение устанавливает, какую конкретную роль
играет актер при взаимодействии с экземпляром варианта использования. На
диаграмме вариантов использования, так же как и на других диаграммах,
отношение ассоциации обозначается сплошной линией между актером и
вариантом использования. Эта линия может иметь дополнительные условные
обозначения, такие, например, как имя и кратность (рис. 4.6).
Рис. 4.6. Пример графического представления отношения ассоциации
между актером и вариантом использования
Отношение расширения определяет взаимосвязь экземпляров отдельного
варианта
использования
с
более
общим
вариантом,
свойства
которого
определяются на основе способа совместного объединения данных экземпляров.
В метамодели отношение расширения является направленным и указывает, что
применительно к отдельным примерам некоторого варианта использования
должны быть выполнены конкретные условия, определенные для расширения
данного варианта использования. Так, если имеет место отношение расширения
от варианта использования А к варианту использования В, то это означает, что
свойства экземпляра варианта использования В могут быть дополнены благодаря
наличию свойств у расширенного варианта использования А.
Отношение расширения между вариантами использования обозначается
пунктирной линией со стрелкой (вариант отношения зависимости), направленной
от того варианта использования, который является расширением для исходного
варианта использования. Данная линия со стрелкой помечается ключевым словом
"extend" ("расширяет"), как показано на рис. 4.7.
Рис. 4.7. Пример графического изображения отношения расширения между
вариантами использования
Отношение обобщения служит для указания того факта, что некоторый
вариант использования А может быть обобщен до варианта использования В. В
этом случае вариант А будет являться специализацией варианта В. При этом В
называется предком или родителем по отношению А, а вариант А — потомком по
отношению к варианту использования В. Следует подчеркнуть, что потомок
наследует все свойства и поведение своего родителя, а также может быть
дополнен новыми свойствами и особенностями поведения. Графически данное
отношение обозначается сплошной линией со стрелкой в форме незакрашенного
треугольника, которая указывает на родительский вариант использования (рис.
4.9). Эта линия со стрелкой имеет специальное название — стрелка "обобщение".
Рис. 4.9. Пример графического изображения отношения обобщения между
вариантами использования
Отношение
включения
между
двумя
вариантами
использования
указывает, что некоторое заданное поведение для одного варианта использования
включается в качестве составного компонента в последовательность поведения
другого варианта использования. Данное отношение является направленным
бинарным отношением в том смысле, что пара экземпляров вариантов
использования всегда упорядочена в отношении включения.
Семантика этого отношения определяется следующим образом. Когда
экземпляр первого варианта использования в процессе своего выполнения
достигает точки включения в последовательность поведения экземпляра второго
варианта использования, экземпляр первого варианта использования выполняет
последовательность действий, определяющую поведение экземпляра второго
варианта использования, после чего продолжает выполнение действий своего
поведения. При этом предполагается, что даже если экземпляр первого варианта
использования может иметь несколько включаемых в себя экземпляров других
вариантов, выполняемые ими действия должны закончиться к некоторому
моменту, после чего должно быть продолжено выполнение прерванных действий
экземпляра первого варианта использования в соответствии с заданным для него
поведением.
Один вариант использования может быть включен в несколько других
вариантов, а также включать в себя другие варианты. Включаемый вариант
использования может быть независимым от базового варианта в том смысле, что
он предоставляет последнему некоторое инкапсулированное поведение, детали
реализации которого скрыты от последнего и могут быть легко перераспределены
между несколькими включаемыми вариантами использования. Более того,
базовый вариант может зависеть только от результатов выполнения включаемого
в него поведения, но не от структуры включаемых в него вариантов.
Отношение включения, направленное от варианта использования А к
варианту использования В, указывает, что каждый экземпляр варианта А
включает в себя функциональные свойства, заданные для варианта В. Эти
свойства специализируют поведение соответствующего варианта А на данной
диаграмме. Графически данное отношение обозначается пунктирной линией со
стрелкой (вариант отношения зависимости), направленной от базового варианта
использования к включаемому. При этом данная линия со стрелкой помечается
ключевым словом "include" ("включает"), как показано на рис. 4.11.
Рис. 4.11. Пример графического изображения отношения включения между
вариантами использования
Рис. 4.14. Пример диаграммы вариантов использования для системы
продажи
При построении диаграммы вариантов использования следует иметь в виду:
 любой вариант использования может быть декомпозирован на множество
подвариантов использования отдельных элементов, которые образуют исходную
сущность;
 рекомендуемое общее количество актеров в модели — не более 20, а
вариантов использования — не более 50;
 отдельный экземпляр варианта использования по своему содержанию
является выполнением последовательности действий, которая инициализируется
посредством экземпляра сообщения от экземпляра актера, в качестве отклика или
ответной реакции на сообщение которого экземпляр варианта использования
выполняет последовательность действий, установленную для данного варианта
использования; при этом экземпляры актеров могут генерировать новые
экземпляры сообщений для экземпляров вариантов использования;
 если для представления иерархической структуры проектируемой
системы используются подсистемы, система может быть определена в виде
вариантов использования на всех уровнях, а отдельные подсистемы или классы
могут выступать в роли таких вариантов использования;
 функциональность,
определенная
для
более
общего
варианта
использования, полностью наследуется всеми вариантами нижних уровней;
 отдельные варианты использования нижнего уровня могут участвовать в
нескольких кооперациях, т. е. играть определенную роль при выполнении
сервисов нескольких вариантов верхнего уровня;
 варианты использования классов соответствуют операциям этого класса,
поскольку сервис класса является по существу выполнением операций данного
класса,
т.е.
некоторые
варианты
использования
могут
соответствовать
применению только одной операции, в то время как другие – конечного
множества операций, определенных в виде последовательности операций, а время
одна операция может быть необходима для выполнения нескольких сервисов
класса и поэтому будет появляться в нескольких вариантах использования этого
класса;
 реализация варианта использования зависит от типа элемента модели, в
котором он определен (например, поскольку варианты использования класса
определяются
посредством
операций
этого
класса,
они
реализуются
соответствующими методами), при этом варианты использования подсистемы
реализуются элементами, из которых состоит данная подсистема;
 если в качестве моделируемой
сущности выступает система или
подсистема самого верхнего уровня, то отдельные пользователи вариантов
использования этой системы моделируются актерами.
2.3.3 Диаграмма классов
Диаграмма классов служит для представления статической структуры
модели
системы
в
терминологии
классов
объектно-ориентированного
программирования. Диаграмма классов может отражать, в частности, различные
взаимосвязи между отдельными сущностями предметной области, такими как
объекты и подсистемы, а также описывает их внутреннюю структуру и типы
отношений.
В рамках проекта следует разработать логическую структуру информации в
виде диаграммы классов. Хранимая в базе данных информация обычно также
представляется в виде диаграммы классов.
Класс
Класс (class) в языке UML служит для обозначения множества объектов,
которые обладают одинаковой структурой, поведением и отношениями с
объектами из других классов. Графически класс изображается в виде
прямоугольника, который дополнительно может быть разделен горизонтальными
линиями на разделы или секции. В этих разделах могут указываться имя класса,
атрибуты (переменные) и операции (методы).
Рис. 1 Графическое изображение класса на диаграмме классов
Обязательным элементов обозначения класса является его имя. На
начальных этапах разработки диаграммы отдельные классы могут обозначаться
простым прямоугольником с указанием только имени соответствующего класса
(рис. 1, а). По мере проработки отдельных компонентов диаграммы описания
классов дополняются атрибутами (рис. 1, б) и операциями (рис. 1, в).
Предполагается, что окончательный вариант диаграммы содержит наиболее
полное описание классов, которые состоят из трех разделов или секций. Иногда в
обозначениях классов используется дополнительный четвертый раздел, в котором
приводится семантическая информация справочного характера или явно
указываются исключительные ситуации.
Даже если секция атрибутов и операций является пустой, в обозначении
класса она выделяется горизонтальной линией, чтобы сразу отличить класс от
других элементов языка UML. Примеры графического изображения классов на
диаграмме классов приведены на рис. 2. В первом случае для класса
"Прямоугольник" (рис. 2, а) указаны только его атрибуты — точки на
координатной плоскости, которые определяют его расположение. Для класса
"Окно" (рис. 2, б) указаны только его операции, секция атрибутов оставлена
пустой. Для класса "Счет" (рис. 2, в) дополнительно изображена четвертая секция,
в которой указано исключение — отказ от обработки просроченной кредитной
карточки.
Рис. 2 Примеры графического изображения классов на диаграмме
В верхней секции указывается имя класса.
Атрибуты класса
Во второй сверху секции прямоугольника класса записываются его
атрибуты (attributes) или свойства. Каждому атрибуту класса соответствует
отдельная строка текста, которая состоит из квантора видимости атрибута, имени
атрибута, его кратности, типа значений атрибута и, возможно, его исходного
значения:
 <квантор видимости><имя атрибута>[кратность]:
 <тип атрибута> = <исходное значение>{строка-свойство}
Квантор видимости может принимать одно из трех возможных значений и,
соответственно, отображается при помощи специальных символов:
Символ "+" обозначает атрибут с областью видимости типа общедоступный
(public). Атрибут с этой областью видимости доступен или виден из любого
другого класса пакета, в котором определена диаграмма.
Символ "#" обозначает атрибут с областью видимости типа защищенный
(protected). Атрибут с этой областью видимости недоступен или невиден для всех
классов, за исключением подклассов данного класса.
И, наконец, знак "-" обозначает атрибут с областью видимости типа
закрытый (private). Атрибут с этой областью видимости недоступен или невиден
для всех классов без исключения.
Квантор видимости может быть опущен. В этом случае его отсутствие
просто означает, что видимость атрибута не указывается.
Кратность атрибута характеризует общее количество конкретных атрибутов
данного типа, входящих в состав отдельного класса. В общем случае кратность
записывается в форме строки текста в квадратных скобках после имени
соответствующего атрибута:
[нижняя_граница1.. верхняя_граница1, нижняя_граница2..
верхняя_граница2,..., нuжняя_гpaнuцak .. верхняя_границаk],
где нижняя_граница и верхняя_граница являются положительными целыми
числами, каждая пара которых служит для обозначения отдельного замкнутого
интервала целых чисел, у которого нижняя (верхняя) граница равна значению
нижняя_граница (верхняя_граница). В целом данное условное обозначение
кратности
соответствует
теоретико-множественному
объединению
соответствующих интервалов. В качестве верхней_границы может использоваться
специальный символ "*", который означает произвольное положительное целое
число. Другими словами, это означает неограниченное сверху значение кратности
соответствующего атрибута.
Операция
В третьей сверху секции прямоугольника записываются операции или
методы класса. Операция (operation) представляет собой некоторый сервис,
предоставляющий каждый экземпляр класса по определенному требованию.
Совокупность операций характеризует функциональный аспект поведения класса.
Запись операций класса в языке UML также стандартизована и подчиняется
определенным синтаксическим правилам. При этом каждой операции класса
соответствует отдельная строка, которая состоит из квантора видимости
операции, имени операции, выражения типа возвращаемого операцией значения
и, возможно, строка-свойство данной операции:
 <квантор видимости><имя операции>(список параметров):
 <выражение типа возвращаемого значения>{строка-свойство}
Квантор видимости, как и в случае атрибутов класса, может принимать
одно из трех возможных значений и, соответственно, отображается при помощи
специального символа. Символ "+" обозначает операцию с областью видимости
типа общедоступный (public). Символ "#" обозначает операцию с областью
видимости типа защищенный (protected). И, наконец, символ "-" используется для
обозначения операции с областью видимости типа закрытый (private).
Квантор видимости для операции может быть опущен. В этом случае его
отсутствие просто означает, что видимость операции не указывается.
Имя
атрибута
является
единственным
обязательным
элементом
синтаксического обозначения операции.
Список параметров является перечнем разделенных запятой формальных
параметров, каждый из которых может быть представлен в следующем виде:
<вид параметра><имя параметра>:<выражение типа>=<значение параметра
по умолчанию>.
Здесь вид параметра – есть одно из ключевых слов in, out или inout со
значением in по умолчанию, в случае если вид параметра не указывается. Имя
параметра есть идентификатор соответствующего формального параметра.
Выражение типа является зависимой от конкретного языка программирования
спецификацией
типа
возвращаемого
значения
для
соответствующего
формального параметра. Наконец, значение по умолчанию в общем случае
представляет собой выражение для значения формального параметра, синтаксис
которого зависит от конкретного языка программирования и подчиняется
принятым в нем ограничениям.
Операция с областью действия на весь класс показывается подчеркиванием
имени и строки выражения типа. По умолчанию под областью операции
понимается объект класса. В этом случае имя и строка выражения типа операции
не подчеркиваются.
Операция,
которая
не
может
изменять
состояние
системы
и,
соответственно, не имеет никакого побочного эффекта, обозначается строкойсвойством "{запрос}" ("{query}"). В противном случае операция может изменять
состояние системы, хотя нет никаких гарантий, что она будет это делать.
Отношения между классами
Кроме внутреннего устройства или структуры классов на соответствующей
диаграмме указываются различные отношения между классами. При этом
совокупность
типов
таких
отношений
фиксирована
в
языке
UML
и
предопределена семантикой этих типов отношений. Базовыми отношениями или
связями в языке UML являются:




отношение зависимости (dependency relationship);
отношение ассоциации (association relationship);
отношение обобщения (generalization relationship);
отношение реализации (realization relationship).
Каждое из этих отношений имеет собственное графическое представление
на диаграмме, которое отражает взаимосвязи между объектами соответствующих
классов.
Отношение зависимости
Отношение
зависимости
в
общем
случае
указывает
некоторое
семантическое отношение между двумя элементами модели или двумя
множествами таких элементов, которое не является отношением ассоциации,
обобщения или реализации. Оно касается только самих элементов модели и не
требует множества отдельных примеров для пояснения своего смысла.
Отношение зависимости используется в такой ситуации, когда некоторое
изменение одного элемента модели может потребовать изменения другого
зависимого от него элемента модели.
Отношение зависимости графически изображается пунктирной линией
между соответствующими элементами со стрелкой на одном из ее концов ("—>"
или "<—"). На диаграмме классов данное отношение связывает отдельные классы
между собой, при этом стрелка направлена от класса-клиента зависимости к
независимому классу или классу-источнику (рис. 3). На данном рисунке
изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является
источником некоторой зависимости, а Класс_А — клиентом этой зависимости.
Рис. 3 Графическое изображение отношения зависимости на диаграмме
классов
В
качестве
класса-клиента
и
класса-источника
зависимости
могут
выступать целые множества элементов модели. В этом случае одна линия со
стрелкой, выходящая от источника зависимости, расщепляется в некоторой точке
на несколько отдельных линий, каждая из которых имеет отдельную стрелку для
класса-клиента. Например, если функционирование Класса_С зависит от
особенностей реализации Класса_А и Класса_Б, то данная зависимость может
быть изображена следующим образом (рис. 5.4).
Рис. 4 Графическое представление зависимости между классом-клиентом
(Класс_С) и классами-источниками (Класс_А и Класс_Б)
Стрелка может помечаться необязательным, но стандартным ключевым
словом в кавычках и необязательным индивидуальным именем. Для отношения
зависимости предопределены ключевые слова, которые обозначают некоторые
специальные
виды
зависимостей.
Эти
ключевые
слова
(стереотипы)
записываются в кавычках рядом со стрелкой, которая соответствует данной
зависимости.
Отношение ассоциации
Отношение ассоциации соответствует наличию некоторого отношения
между
классами.
Данное
отношение
обозначается
сплошной
линией
с
дополнительными специальными символами, которые характеризуют отдельные
свойства конкретной ассоциации. В качестве дополнительных специальных
символов могут использоваться имя ассоциации, а также имена и кратность
классов-ролей ассоциации. Имя ассоциации является необязательным элементом
ее обозначения. Если оно задано, то записывается с заглавной (большой) буквы
рядом с линией соответствующей ассоциации.
Наиболее простой случай данного отношения – бинарная ассоциация. Она
связывает в точности два класса и, как исключение, может связывать класс с
самим собой. Для бинарной ассоциации на диаграмме может быть указан порядок
следования классов с использованием треугольника в форме стрелки рядом с
именем данной ассоциации. Направление этой стрелки указывает на порядок
классов, один из которых является первым (со стороны треугольника), а другой —
вторым (со стороны вершины треугольника). Отсутствие данной стрелки рядом с
именем ассоциации означает, что порядок следования классов в рассматриваемом
отношении не определен.
N-арная ассоциация графически обозначается ромбом, от которого ведут
линии к символам классов данной ассоциации. В этом случае ромб соединяется с
символами соответствующих классов сплошными линиями. Обычно линии
проводятся от вершин ромба или от середины его сторон. Имя N-арной
ассоциации записывается рядом с ромбом соответствующей ассоциации.
Порядок классов в N-арной ассоциации, в отличие от порядка множеств в
отношении, на диаграмме не фиксируется. Некоторый класс может быть
присоединен к ромбу пунктирной линией. N-арная ассоциация не может
содержать символ агрегации ни для какой из своих ролей.
Следующий элемент обозначений
– кратность отдельных классов,
являющихся концами ассоциации. Кратность отдельного класса обозначается в
виде интервала целых чисел, аналогично кратности атрибутов и операций
классов. Интервал записывается рядом с концом ассоциации и для N-арной
ассоциации означает потенциальное число отдельных экземпляров или значений
кортежей этой ассоциации, которые могут иметь место, когда остальные N-1
экземпляров или значений классов фиксированы.
Частным случаем отношения ассоциации является так называемая
исключающая ассоциация (Xor-association). Семантика данной ассоциации
указывает на тот факт, что из нескольких потенциально возможных вариантов
данной ассоциации в каждый момент времени может использоваться только один
ее экземпляр. На диаграмме классов исключающая ассоциация изображается
пунктирной линией, соединяющей две и более ассоциации, рядом с которой
записывается строка-ограничение "{хог}".
Специальной формой или частным случаем отношения ассоциации является
отношение агрегации, которое, в свою очередь, тоже имеет специальную форму
— отношение композиции. Поскольку эти отношения имеют свои специальные
обозначения и относятся к базовым понятиям языка UML, рассмотрим их
последовательно.
Отношение агрегации
Отношение агрегации имеет место между несколькими классами в том
случае, если один из классов представляет собой некоторую сущность,
включающую в себя в качестве составных частей другие сущности.
Данное отношение имеет фундаментальное значение для описания
структуры
сложных
систем,
поскольку
применяется
для
представления
системных взаимосвязей типа "часть-целое". Раскрывая внутреннюю структуру
системы, отношение агрегации показывает, из каких компонентов состоит
система и как они связаны между собой. С точки зрения модели отдельные части
системы могут выступать как в виде элементов, так и в виде подсистем, которые,
в свою очередь, тоже могут образовывать составные компоненты или
подсистемы. Это отношение по своей сути описывает декомпозицию или
разбиение сложной системы на более простые составные части, которые также
могут быть подвергнуты декомпозиции, если в этом возникнет необходимость в
последующем.
Очевидно, что рассматриваемое в таком аспекте деление системы на
составные части представляет собой некоторую иерархию ее компонентов, однако
данная
иерархия
принципиально
отличается
от
иерархии,
порождаемой
отношением обобщения. Отличие заключается в том, что части системы никак не
обязаны наследовать ее свойства и поведение, поскольку являются вполне
самостоятельными сущностями. Более того, части целого обладают своими
собственными атрибутами и операциями, которые существенно отличаются от
атрибутов и операций целого.
В качестве примера отношения агрегации рассмотрим взаимосвязь типа
"часть-целое".
Рис. 5 Графическое изображение отношения агрегации в языке UML
Еще одним примером отношения агрегации может служить известное
каждому из читателей деление персонального компьютера на составные части:
системный блок, монитор, клавиатуру и мышь. Используя обозначения языка
UML, компонентный состав ПК можно представить в виде соответствующей
диаграммы классов (рис. 7), которая в данном случае иллюстрирует отношение
агрегации.
Рис. 6
Диаграмма классов для иллюстрации отношения агрегации на
примере ПК
Отношение композиции
Отношение композиции, как уже упоминалось ранее, является частным
случаем
отношения
агрегации.
Это
отношение
служит
для
выделения
специальной формы отношения "часть-целое", при которой составляющие части в
некотором смысле находятся внутри целого. Специфика взаимосвязи между ними
заключается в том, что части не могут выступать в отрыве от целого, т. е. с
уничтожением целого уничтожаются и все его составные части.
Графически отношение композиции изображается сплошной линией, один
из концов которой представляет собой закрашенный внутри ромб. Этот ромб
указывает на тот из классов, который представляет собой класс-композицию или
"целое". Остальные классы являются его "частями" (рис. 8).
Рис. 7 Графическое изображение отношения композиции в языке UML
В качестве дополнительных обозначений для отношений композиции и
агрегации могут использоваться дополнительные обозначения, применяемые для
отношения ассоциации. А именно, указание кратности класса ассоциации и имени
данной ассоциации, которые не являются обязательными.
Отношение обобщения
Отношение обобщения является обычным таксономическим отношением
между более общим элементом (родителем или предком) и более частным или
специальным элементом (дочерним или потомком). Данное отношение может
использоваться для представления взаимосвязей между пакетами, классами,
вариантами использования и другими элементами языка UML.
Применительно к диаграмме классов данное отношение описывает
иерархическое строение классов и наследование их свойств и поведения. При
этом предполагается, что класс-потомок обладает всеми свойствами и поведением
класса-предка, а также имеет свои собственные свойства и поведение, которые
отсутствуют у класса-предка. На диаграммах отношение обобщения обозначается
сплошной линией с треугольной стрелкой на одном из концов (рис. 9). Стрелка
указывает на более общий класс (класс-предок или суперкласс), а ее отсутствие –
на более специальный класс (класс-потомок или подкласс).
Рис. 8 Графическое изображение отношения обобщения в языке UML
Как правило, на диаграмме может указываться несколько линий для одного
отношения обобщения, что отражает его таксономический характер. В этом
случае более общий класс разбивается на подклассы одним отношением
Обобщения.
С целью упрощения обозначений на диаграмме классов совокупность
линий, обозначающих одно и то же отношение обобщения, может быть
объединена в одну линию. В этом случае данные отдельные линии изображаются
сходящимися к единственной .стрелке, имеющей с ними общую точку
пересечения (рис. 10).
Рис. 9 Вариант графического изображения отношения обобщения классов
для случая объединения отдельных линий
Рядом со стрелкой обобщения может размещаться строка текста,
указывающая на некоторые дополнительные свойства этого отношения. Данный
текст будет относиться ко всем линиям обобщения, которые идут к классам-
потомкам. Другими словами, отмеченное свойство касается всех подклассов
данного отношения. При этом текст следует рассматривать как ограничение, и
тогда он записывается в фигурных скобках.
В качестве ограничений могут быть использованы следующие ключевые
слова языка UML:
{complete}
–
означает,
что
в
данном
отношении
обобщения
специфицированы все классы-потомки, и других классов-потомков у данного
класса-предка быть не может. На соответствующей диаграмме классов это можно
указать явно, записав рядом с линией обобщения данную строку-ограничение;
{disjoint} – означает, что классы-потомки не могут содержать объектов,
одновременно являющихся экземплярами двух или более классов. В этом случае
рядом с линией обобщения можно записать данную строку-ограничение;
{incomplete} – означает случай, противоположный первому. А именно,
предполагается, что на диаграмме указаны не все классы-потомки. В
последующем возможно восполнить их перечень не изменяя уже построенную
диаграмму;
{overlapping} – означает, что отдельные экземпляры классов-потомков
могут принадлежать одновременно нескольким классам.
С учетом возможности использования строк-ограничений диаграмма
классов (рис. 10) может быть изображена без многоточий и без потери
информации (рис. 11).
Рис. 10 Вариант графического изображения отношения обобщения классов
с использованием строки-ограничения
Интерфейсы
Интерфейсы являются элементами диаграммы вариантов использования.
Однако при построении диаграммы классов отдельные интерфейсы могут
уточняться и в этом случае для их изображения используется специальный
графический символ – прямоугольник класса с ключевым словом или
стереотипом "interface" (рис. 12). При этом секция атрибутов у прямоугольника
отсутствует, а указывается только секция операций.
Рис. 11 Пример графического изображения интерфейса на диаграмме
классов
Объекты
Объект (object) является отдельным экземпляром класса, который создается
на этапе выполнения программы. Он имеет свое собственное имя и конкретные
значения атрибутов. В силу самых различных причин может возникнуть
необходимость показать взаимосвязи не только между классами модели, но и
между отдельными объектами, реализующими эти классы. В данном случае
может быть разработана диаграмма объектов, которая, хотя и не является
канонической в метамодели языка UML, но имеет самостоятельное назначение.
Для графического изображения объектов используется такой же символ
прямоугольника, что и для классов. Отличия проявляются при указании имен
объектов, которые в случае объектов обязательно подчеркиваются (рис. 13). При
этом запись имени объекта представляет собой строку текста "имя объекта:имя
класса", разделенную двоеточием (рис. 13 а, б). Имя объекта может отсутствовать,
в этом случае предполагается, что объект является анонимным, и двоеточие
указывает на данное обстоятельство (рис. 13, г). Отсутствовать может и имя
класса. Тогда указывается просто имя объекта (рис. 13, в). Атрибуты объектов
принимают конкретные значения.
При изображении диаграммы объектов нужно помнить, что каждый объект
представляет собой экземпляр соответствующего класса, а отношения между
объектами
описываются
с
помощью
связей
(links),
которые
являются
экземплярами соответствующих отношений. При этом все связи изображаются
сплошными линиями.
Рис. 12 Пример графического изображения объектов на диаграммах языка
UML
Рис. 13 Пример диаграммы классов кадрового учёта
2.3.4 Диаграмма состояний
Главное предназначение диаграммы состояний – описание возможных
состояний и переходов, которые в совокупности характеризуют поведение
элемента модели в течение его жизненного цикла. Диаграмма состояний
представляет динамическое поведение сущностей, на основе спецификации их
реакции на восприятие некоторых конкретных событий. Системы, которые
реагируют на внешние действия от других систем или от пользователей, иногда
называют реактивными. Если такие действия инициируются в произвольные
случайные моменты времени, то говорят об асинхронном поведении модели.
Рис. 14 Простейший пример диаграммы состояний
При проектировании следует выявить все возможные состояния и варианты
их возникновения, а также построить диаграмму состояний для жизненного цикла
одного из разрабатываемых объектов.
Рис. 15 Пример диаграммы состояний жизненного цикла объекта
«телефона»
Диаграмма строится для отдельного класса, варианта использования,
отдельной операции класса или целой подсистемы. В рамках данного проекта
необходимо построить диаграмму состояний для всех выбранных объектов, для
которых будет описано поведение.
Состояние
Понятие состояния (state) является фундаментальным не только в
метамодели языка UML, но и в прикладном системном анализе. Концепция
динамической системы основывается на понятии состояния системы. Однако
семантика состояния в языке UML имеет целый ряд специфических особенностей.
В языке UML под состоянием понимается абстрактный метакласс,
используемый для моделирования отдельной ситуации, в течение которой имеет
место выполнение некоторого условия. Состояние может быть задано в виде
набора конкретных значений атрибутов класса или объекта, при этом изменение
их отдельных значений будет отражать изменение состояния моделируемого
класса или объекта.
Следует заметить, что не каждый атрибут класса может характеризовать его
состояние. Как правило, имеют значение только такие свойства элементов
системы, которые отражают динамический или функциональный аспект ее
поведения. В этом случае состояние будет характеризоваться некоторым
инвариантным условием, включающим в себя только значимые для поведения
класса атрибуты и их значения.
Рис. 16 Графическое изображение состояний на диаграмме состояний
Состояние на диаграмме изображается прямоугольником со скругленными
вершинами (рис. 3). Этот прямоугольник, в свою очередь, может быть разделен на
две секции горизонтальной линией. Если указана лишь одна секция, то в ней
записывается только имя состояния (рис. 3, а). В противном случае в первой из
них записывается имя состояния, а во второй — список некоторых внутренних
действий или переходов в данном состоянии (рис. 3, б). При этом под действием в
языке UML понимают некоторую атомарную операцию, выполнение которой
приводит к изменению состояния или возврату некоторого значения (например,
"истина" или "ложь").
Имя состояния представляет собой строку текста, которая раскрывает
содержательный смысл данного состояния. Имя всегда записывается с заглавной
буквы. Поскольку состояние системы является составной частью процесса ее
функционирования, рекомендуется в качестве имени использовать глаголы в
настоящем времени (звенит, печатает, ожидает) или соответствующие причастия
(занят, свободен, передано, получено). Имя у состояния может отсутствовать, т. е.
оно является необязательным для некоторых состояний. В этом случае состояние
является анонимным, и если на диаграмме состояний их несколько, то все они
должны различаться между собой.
Секция «Список внутренних действий» содержит перечень внутренних
действий или деятельностей, которые выполняются в процессе нахождения
моделируемого элемента в данном состоянии. Каждое из действий записывается в
виде отдельной строки и имеет следующий формат:
<метка-дёйствия '/' выражение-действия>
Метка действия указывает на обстоятельства или условия, при которых
будет выполняться деятельность, определенная выражением действия. При этом
выражение действия может использовать любые атрибуты и связи, которые
принадлежат области имен или контексту моделируемого объекта. Если список
выражений действия пустой, то разделитель в виде наклонной черты '/' может не
указываться.
Перечень меток действия имеет фиксированные значения в языке UML,
которые не могут быть использованы в качестве имен событий. Эти значения
следующие:
 entry – эта метка указывает на действие, специфицированное следующим
за ней выражением действия, которое выполняется в момент входа в данное
состояние (входное действие);
 exit – эта метка указывает на действие, специфицированное следующим
за ней выражением действия, которое выполняется в момент выхода из данного
состояния (выходное действие);
 do – эта метка специфицирует выполняющуюся деятельность ("do
activity"), которая выполняется в течение всего времени, пока объект находится в
данном состоянии, или до тех пор, пока не закончится вычисление,
специфицированное следующим за ней выражением действия.
 include – эта метка используется для обращения к подавтомату, при этом
следующее за ней выражение действия содержит имя этого подавтомата.
Во всех остальных случаях метка действия идентифицирует событие,
которое
запускает
соответствующее
выражение
действия.
Эти
события
называются внутренними переходами и семантически эквивалентны переходам в
само это состояние, за исключением той особенности, что выход из этого
состояния или повторный вход в него не происходит. Это означает, что действия
входа и выхода не выполняются.
Начальное состояние представляет собой частный случай состояния,
которое не содержит никаких внутренних действий (псевдосостояния). В этом
состоянии находится объект по умолчанию в начальный момент времени. Оно
служит для указания на диаграмме состояний графической области, от которой
начинается процесс изменения состояний. Графически начальное состояние в
языке UML обозначается в виде закрашенного кружка (рис. 4, а), из которого
может только выходить стрелка, соответствующая переходу.
Рис. 17 Графическое изображение начального и конечного состояний на
диаграмме состояний
На самом верхнем уровне представления объекта переход из начального
состояния может быть помечен событием создания (инициализации) данного
объекта. В противном случае переход никак не помечается. Если этот переход не
помечен, то он является первым переходом в следующее за ним состояние.
Конечное (финальное) состояние представляет собой частный случай
состояния,
которое
также
не
содержит
никаких
внутренних
действий
(псевдосостояния). В этом состоянии будет находиться объект по умолчанию
после завершения работы автомата в конечный момент времени. Оно служит для
указания на диаграмме состояний графической области, в которой завершается
процесс изменения состояний или жизненный цикл данного объекта. Графически
конечное состояние в языке UML обозначается в виде закрашенного кружка,
помещенного в окружность (рис. 4, б), в которую может только входить стрелка,
соответствующая переходу.
Переход
Простой переход (simple transition) представляет собой отношение между
двумя последовательными состояниями, которое указывает на факт смены одного
состояния другим. Пребывание моделируемого объекта в первом состоянии
может сопровождаться выполнением некоторых действий, а переход во второе
состояние будет возможен после завершения этих действий, а также после
удовлетворения некоторых дополнительных условий. В этом случае говорят, что
переход срабатывает, Или происходит срабатывание перехода. До срабатывания
перехода объект находится в предыдущем от него состоянии, называемым
исходным состоянием, или в источнике (не путать с начальным состоянием — это
разные понятия), а после его срабатывания объект находится в последующем от
него состоянии (целевом состоянии).
Переход осуществляется при наступлении некоторого события: окончания
выполнения деятельности (do activity), получении объектом сообщения или
приемом сигнала. На переходе указывается имя события Кроме того, на переходе
могут указываться действия, производимые объектом в ответ на внешние события
при переходе из одного состояния в другое. Срабатывание перехода может
зависеть не только от наступления некоторого события, но и от выполнения
определенного условия, называемого сторожевым условием. Объект перейдет из
одного состояния в другое в том случае, если произошло указанное событие и
сторожевое условие приняло значение "истина".
На диаграмме состояний переход изображается сплошной линией со
стрелкой, которая направлена в целевое состояние (например, "выход из строя" на
рис. 1). Каждый переход может помечен строкой текста, которая имеет
следующий общий формат:
<сигнатура события>'['<сторожевое условие>']' <выражение действия>.
При
этом
сигнатура
необходимыми аргументами:
события
описывает
некоторое
событие
с
<имя события>'('<список параметров, разделенных запятыми>')'.
Событие
Термин событие (event) требует отдельного пояснения, поскольку является
самостоятельным элементом языка UML. Формально, событие представляет
собой спецификацию некоторого факта, имеющего место в пространстве и во
времени. Про события говорят, что они "происходят", при этом отдельные
события должны быть упорядочены во времени. После наступления некоторого
события нельзя уже вернуться к предыдущим событиям, если такая возможность
не предусмотрена явно в модели.
Семантика понятия события фиксирует внимание на внешних проявлениях
качественных изменений, происходящих при переходе моделируемого объекта из
состояния в состояние. Например, при включении электрического переключателя
происходит некоторое событие, в результате которого комната становится
освещенной.
После
успешного
ремонта
компьютера
также
происходит
немаловажное событие — восстановление его работоспособности. Если поднять
трубку обычного телефона, то, в случае его исправности, мы ожидаем услышать
тоновый сигнал. И этот факт тоже является событием.
В языке UML события играют роль стимулов, которые инициируют
переходы из одних состояний в другие. В качестве событий можно рассматривать
сигналы, вызовы, окончание фиксированных промежутков времени или моменты
окончания выполнения определенных действий. Имя события идентифицирует
каждый отдельный переход на диаграмме состояний и может содержать строку
текста, начинающуюся со строчной буквы.
Если рядом со стрелкой перехода не указана никакая строка текста, то
соответствующий переход является нетриггерным, и в этом случае из контекста
диаграммы состояний должно быть ясно, после окончания какой деятельности он
срабатывает. После имени события могут следовать круглые скобки для явного
задания параметров соответствующего события-триггера. Если таких параметров
нет, то список параметров со скобками может отсутствовать.
Сторожевое условие (guard condition), если оно есть, всегда записывается в
прямых скобках после события-триггера и представляет собой некоторое
булевское выражение. Введение для перехода сторожевого условия позволяет
явно специфицировать семантику его срабатывания. Если сторожевое условие
принимает значение "истина", то соответствующий переход может сработать, в
результате чего объект перейдет в целевое состояние. Если же сторожевое
условие принимает значение "ложь", то переход не может сработать, и при
отсутствии других переходов объект не может перейти в целевое состояние по
этому
переходу.
Однако
вычисление
истинности
сторожевого
условия
происходит только после возникновения ассоциированного с ним событиятриггера, инициирующего соответствующий переход.
В общем случае из одного состояния может быть несколько переходов с
одним и тем же событием-триггером. При этом никакие два сторожевых условия
не должны одновременно принимать значение "истина". Каждое из сторожевых
условий необходимо вычислять всякий раз при наступлении соответствующего
события-триггера.
Примером
события-триггера
может
служить
разрыв
телефонного
соединения с провайдером Интернет-услуг после окончания загрузки электронной
почты клиентской почтовой программой (при удаленном доступе к Интернету). В
этом случае сторожевое условие есть не что иное, как ответ на вопрос: "Пуст ли
почтовый ящик клиента на сервере провайдера?". В случае положительного
ответа "истина", следует отключить соединение с провайдером, что и делает
автоматически почтовая программа-клиент. В случае отрицательного ответа
"ложь", следует оставаться в состоянии загрузки почты и не разрывать
телефонное соединение.
Выражение действия
Выражение действия (action expression) выполняется в том и только в том
случае, когда переход срабатывает. Представляет собой атомарную операцию
(достаточно простое вычисление), выполняемую сразу после срабатывания
соответствующего перехода до начала каких бы то ни было действий в целевом
состоянии. Атомарность действия означает, что оно не может быть прервано
никаким другим действием до тех пор, пока не закончится его выполнение.
Данное действие может оказывать влияние, как на сам объект, так и на его
окружение, если это с очевидностью следует из контекста модели. Выражение
записывается
после
знака
"/"
в
строке
текста,
присоединенной
к
соответствующему переходу.
В общем случае, выражение действия может содержать целый список
отдельных действий, разделенных символом ";". Обязательное требование – все
действия из списка должны четко различаться между собой и следовать в порядке
их записи. На синтаксис записи выражений действия не накладывается никаких
ограничений. Главное – их запись должна быть понятна разработчикам модели и
программистам. Поэтому чаще всего выражения записывают на одном из языков
программирования, который предполагается использовать для реализации
модели.
В качестве примера выражения действия может служить "разорвать
телефонное соединение (телефонный номер), которое должно быть выполнено
сразу после установления истинности ("истина") сторожевого условия "почтовый
ящик на сервере пуст".
Составное состояние и подсостояние
Составное состояние (composite state) – такое сложное состояние, которое
состоит из других вложенных в него состояний. Последние будут выступать по
отношению к первому как подсостояния (substate). Хотя между ними имеет место
отношение
композиции,
графически
все
вершины
диаграммы,
которые
соответствуют вложенным состояниям, изображаются внутри символа составного
состояния (рис. 5). В этом случае размеры графического символа составного
состояния увеличиваются, так чтобы вместить в себя все подсостояния.
Рис. 18 Графическое представление составного состояния с двумя
вложенными в него последовательными подсостояниями
Составное состояние может содержать два или более параллельных
подавтомата или несколько последовательных подсостояний. Каждое сложное
состояние может уточняться только одним из указанных способов. При этом
любое из подсостояний, в свою очередь, может являться составным состоянием и
содержать внутри себя другие вложенные подсостояния. Количество уровней
вложенности составных состояний не фиксировано в языке UML.
Последовательные подсостояния (sequential substates) используются для
моделирования такого поведения объекта, во время которого в каждый момент
времени объект может находиться в одном и только одном подсостояний.
Поведение объекта в этом случае представляет собой последовательную смену
подсостояний.
Параллельные
подсостояния
(concurrent
substates)
позволяют
специфицировать два и более подавтомата, которые могут выполняться
параллельно внутри составного события. Каждый из подавтоматов занимает
некоторую область (регион) внутри составного состояния, которая отделяется от
остальных горизонтальной пунктирной линией. Если на диаграмме состояний
имеется составное состояние с вложенными параллельными подсостояниями, то
объект может одновременно находиться в каждом из этих подсостояний.
Однако отдельные параллельные подсостояния могут, в свою очередь,
состоять из нескольких последовательных подсостояний. В этом случае по
определению объект может находиться только в одном из последовательных
подсостояний подавтомата.
Рис. 19 Графическое изображение составного состояния с вложенными
параллельными подсостояниями
Поскольку
каждый
регион
вложенного
состояния
специфицирует
некоторый подавтомат, то для каждого из вложенных подавтоматов могут быть
определены собственные начальное и конечные подсостояния. При переходе в
данное составное состояние каждый из подавтоматов оказывается в своем
начальном подсостояний. Далее происходит параллельное выполнение каждого из
этих подавтоматов, причем выход из составного состояния будет возможен лишь
в том случае, когда все подавтоматы будут находиться в своих конечных
подсостояниях.
Если какой-либо из подавтоматов пришел в свое конечное состояние
раньше других, то он должен ожидать, пока и другие подавтоматы не придут в
свои конечные состояния.
В некоторых случаях бывает желательно скрыть внутреннюю структуру
составного состояния. Если отдельный подавтомат, специфицирующий составное
состояние, может быть настолько большим по масштабу, что его визуализация
затруднит общее представление диаграммы состояний. В подобной ситуации
допускается не раскрывать на исходной диаграмме состояний данное составное
состояние, а указать в правом нижнем углу специальный символ-пиктограмму
(рис.
7).
В
последующем
диаграмма
состояний
для
соответствующего
подавтомата может быть изображена отдельно от основной с необходимыми
комментариями.
Рис. 20 Составное состояние со скрытой внутренней структурой и
специальной пиктограммой
Сложные переходы
Рассмотренное выше понятие перехода является вполне достаточным для
большинства типичных расчетно-вычислительных задач. Однако современные
программные системы могут реализовывать очень сложную логику поведения
отдельных
своих
компонентов.
Может
оказаться,
что
для
адекватного
представления процесса изменения состояний семантика обычного перехода для
них недостаточна. С этой целью в языке UML специфицированы дополнительные
обозначения и свойства, которыми могут обладать отдельные переходы на
диаграмме состояний.
В отдельных случаях переход может иметь несколько состоянийисточников и несколько целевых состояний. Такой переход получил специальное
название — параллельный переход. Введение в рассмотрение параллельного
перехода обусловлено необходимостью синхронизировать и/или разделить
отдельные
подпроцессы
на
параллельные
нити
без
спецификации
дополнительной синхронизации в параллельных подавтоматах.
Графически
такой
переход
изображается
вертикальной
черточкой,
аналогично обозначению перехода в известном формализме сетей Петри. Если
параллельный переход имеет две или более входящих дуг (рис. 8, а), то его
называют соединением (join). Если же он имеет две или более исходящих из него
дуг (рис. 8, б), то его называют ветвлением (fork). Текстовая строка спецификации
параллельного перехода записывается рядом с черточкой и относится ко всем
входящим (исходящим) дугам.
Рис. 21 Графическое изображение параллельного перехода из параллельных
состояний (а) и параллельного перехода в параллельные состояния (б)
Срабатывание параллельного перехода происходит следующим образом. В
первом случае (переход-соединение) переход срабатывает, если имеет место
событие-триггер для всех исходных состояний этого перехода, и выполнено (при
его наличии) сторожевое условие. При срабатывании перехода-соединения
одновременно покидаются все исходные состояния перехода (состояния 1 и 2) и
происходит переход в целевое состояние. При этом каждое из исходных
состояний перехода должно принадлежать отдельному подавтомату, входящему в
состав автомата (процессу 1).
Во втором случае (ветвление) происходит расщепление автомата на два
подавтомата, образующих параллельные ветви вложенных подсостояний. При
этом после срабатывания перехода моделируемый объект одновременно будет
находиться во всех целевых состояниях этого перехода (состояния 3 и 4). Далее
процесс изменения состояний будет протекать согласно ранее рассмотренным
правилам для составных состояний.
Переход, стрелка которого соединена с границей некоторого составного
состояния, обозначает переход в составное состояние (переход b на рис. 9). Он
эквивалентен переходу в начальное состояние каждого из подавтоматов
(возможно, единственному), входящих в состав данного суперсостояния. Переход,
выходящий из составного состояния (переходы f и g на рис. 9), относится к
каждому из вложенных подсостояний. Это означает, что объект может покинуть
составное суперсостояние, находясь в любом из его подсостояний. Для этого
вполне достаточно выполнения события и сторожевого условия.
Рис. 22 Различные варианты переходов в (из) составное состояние
Иногда желательно реализовать ситуацию, когда выход из отдельного
вложенного состояния соответствовал бы выходу и из составного состояния тоже.
В этом случае изображают переход, который непосредственно выходит из
вложенного подсостояния за границу суперсостояния (переход с на рис. 9).
Аналогично, допускается изображение переходов, входящих извне составного
состояния в отдельное вложенное состояние (переход а на рис. 9).
Как уже было отмечено, поведение параллельных подавтоматов независимо
друг от друга, что позволяет реализовать многозадачность в программных
системах. Однако в отдельных случаях может возникнуть необходимость учесть в
модели синхронизацию наступления отдельных событий. Для этой цели в языке
UML
имеется
специальное
псевдосостояние,
которое
называется
синхронизирующим состоянием.
Синхронизирующее состояние (synch state) обозначается небольшой
окружностью, внутри которой помещен символ звездочки "*". Оно используется
совместно с переходом-соединением или переходом-ветвлением для того, чтобы
явно указать события в других подавтоматах, оказывающие непосредственное
влияние на поведение данного подавтомата.
Для
иллюстрации
использования
синхронизирующих
состояний
рассмотрим упрощенную ситуацию с моделированием процесса постройки дома.
Предположим, что постройка дома включает в себя строительные работы
(возведение фундамента и стен, возведение крыши и отделочные работы) и
работы по электрификации дома (подведение электрической линии, прокладка
скрытой электропроводки и установка осветительных ламп). Очевидно, два этих
комплекса работ могут выполняться параллельно, однако между ними есть
некоторая взаимосвязь.
В частности, прокладка скрытой электропроводки может начаться лишь
после того, как будет завершено возведение фундамента и стен. А отделочные
работы следует начать лишь после того, как будет закончена прокладка скрытой
электропроводки. В противном случае отделочные работы придется проводить
повторно. Рассмотренные особенности синхронизации этих параллельных
процессов учтены на соответствующей диаграмме состояний с помощью двух
синхронизирующих состояний (рис. 10).
Рис. 23 Диаграмма состояний для примера со строительством дома
2.3.5 Диаграмма деятельности
При моделировании поведения проектируемой или анализируемой системы
возникает необходимость не только представить процесс изменения ее состояний,
но и детализировать особенности алгоритмической и логической реализации
выполняемых системой операций. Традиционно для этой цели использовались
схемы алгоритмов, акцентирующие внимание на последовательности выполнения
определенных действий или элементарных операций, которые в совокупности
приводят к получению желаемого результата.
Для моделирования процесса выполнения операций в языке UML
используются так называемые диаграммы деятельности. Применяемая в них
графическая нотация во многом похожа на нотацию диаграммы состояний,
поскольку на диаграммах деятельности также присутствуют обозначения
состояний и переходов. Отличие заключается в семантике состояний, которые
используются для представления не деятельностей, а действий, и в отсутствии на
переходах сигнатуры событий. Каждое состояние на диаграмме деятельности
соответствует выполнению некоторой элементарной операции, а переход в
следующее состояние срабатывает только при завершении этой, операции в
предыдущем состоянии. Графически диаграмма деятельности представляется в
форме графа деятельности, вершинами которого являются состояния действия, а
дугами — переходы от одного состояния действия к другому.
Состояние действия
Состояние действия (action state) является специальным случаем состояния
с некоторым входным действием и по крайней мере одним выходящим из
состояния переходом. Этот переход неявно предполагает, что входное действие
уже завершилось. Состояние действия не может иметь внутренних переходов,
поскольку оно является элементарным. Обычное использование состояния
действия заключается в моделировании одного шага выполнения алгоритма
(процедуры) или потока управления.
Графически состояние действия изображается фигурой, напоминающей
прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис.
12). Внутри этой фигуры записывается выражение действия (action-expression),
которое должно быть уникальным в пределах одной диаграммы деятельности.
Рис. 24 Графическое изображение состояния действия
Иногда возникает необходимость представить на диаграмме деятельности
некоторое сложное действие, которое, в свою очередь, состоит из нескольких
более простых действий. В этом случае можно использовать специальное
обозначение так называемого состояния под-деятельности (subactivity state). Такое
состояние
является
графом
деятельности
и
обозначается
специальной
пиктограммой в правом нижнем углу символа состояния действия (рис. 7.2). Эта
конструкция может применяться к любому элементу языка UML, который
поддерживает "вложенность" своей структуры. При этом пиктограмма может
быть дополнительно помечена типом вложенной структуры.
Рис. 25 Графическое изображение состояния под-деятельности
Переходы
При
построении
диаграммы
деятельности
используются
только
нетриггерные переходы, т. е. такие, которые срабатывают сразу после завершения
деятельности или выполнения соответствующего действия. Этот переход
переводит деятельность в последующее состояние сразу, как только закончится
действие в предыдущем состоянии. На диаграмме такой переход изображается
сплошной линией со стрелкой.
Если из состояния действия выходит единственный переход, то он может
быть никак не помечен. Если же таких переходов несколько, то сработать может
только один из них. Именно в этом случае для каждого из таких переходов
должно быть явно записано сторожевое условие в прямых скобках. При этом для
всех выходящих из некоторого состояния переходов должно выполняться
требование истинности только одного из них. Подобный случай встречается
тогда, когда последовательно выполняемая деятельность должна разделиться на
альтернативные ветви в зависимости от значения некоторого промежуточного
результата. Такая ситуация получила название ветвления, а для ее обозначения
применяется специальный символ.
Графически ветвление на диаграмме деятельности обозначается небольшим
ромбом, внутри которого нет никакого текста (рис. 14). В этот ромб может
входить только одна стрелка от того состояния действия, после выполнения
которого поток управления должен быть продолжен по одной из взаимно
исключающих ветвей. Принято входящую стрелку присоединять к верхней или
левой вершине символа ветвления. Выходящих стрелок может быть две или
более, но для каждой из них явно указывается соответствующее сторожевое
условие в форме булевского выражения.
В
качестве
примера
рассмотрим
фрагмент
известного
алгоритма
нахождения корней квадратного уравнения. Графически фрагмент процедуры
вычисления корней квадратного уравнения может быть представлен в виде
диаграммы деятельности с тремя состояниями действия и ветвлением (рис. 14).
Каждый из переходов, выходящих из состояния "Вычислить дискриминант",
имеет сторожевое условие, определяющее единственную ветвь, по которой может
быть продолжен
процесс
вычисления
корней
в зависимости
от знака
дискриминанта. Очевидно, что в случае его отрицательности, мы сразу попадаем
в конечное состояние, тем самым завершая выполнение алгоритма в целом.
Рис. 26 Фрагмент диаграммы деятельности для алгоритма нахождения
корней квадратного уравнения
Дорожки
Диаграммы деятельности могут быть использованы для моделирования
бизнес-процессов. Применительно к бизнес-процессам желательно выполнение
каждого действия ассоциировать с конкретным подразделением компании. В этом
случае подразделение несет ответственность за реализацию отдельных действий,
а сам бизнес-процесс представляется в виде переходов действий из одного
подразделения к другому.
Для моделирования этих особенностей в языке UML используется
специальная конструкция, получившее название дорожки (swimlanes) по аналогии
с плавательными дорожками в бассейне. При этом все состояния действия на
диаграмме деятельности делятся на отдельные группы, которые отделяются друг
от друга вертикальными линиями. Две соседние линии и образуют дорожку, а
группа состояний между этими линиями выполняется отдельным подразделением
(отделом, группой, отделением, филиалом) компании (рис. 15).
Названия подразделений явно указываются в верхней части дорожки.
Пересекать линию дорожки могут только переходы, которые в этом случае
обозначают выход или вход потока управления в соответствующее подразделение
компании. Порядок следования дорожек не несет какой-либо семантической
информации и определяется соображениями удобства.
Рис. 27 Фрагмент диаграммы деятельности для торговой компании
2.3.6 Диаграмма последовательности
В
языке
UML
взаимодействие
элементов
рассматривается
в
информационном аспекте их коммуникации, т. е. взаимодействующие объекты
обмениваются между собой некоторой информацией. При этом информация
принимает форму законченных сообщений. Другими словами, хотя сообщение и
имеет информационное содержание, оно приобретает дополнительное свойство
оказывать направленное влияние на своего получателя. Это полностью
согласуется с принципами ООАП, когда любые виды информационного
взаимодействия между элементами системы должны быть сведены к отправке и
приему сообщений между ними.
Для моделирования взаимодействия объектов в языке UML используются
соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют
в виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно
рассматривать во времени, и тогда для представления временных особенностей
передачи и приема сообщений между объектами используется диаграмма
последовательности.
Объекты
На диаграмме последовательности изображаются исключительно те
объекты, которые непосредственно участвуют во взаимодействии и не
показываются возможные статические ассоциации с другими объектами. Для
диаграммы последовательности ключевым моментом является именно динамика
взаимодействия объектов во времени. При этом диаграмма последовательности
имеет как бы два измерения. Одно — слева направо в виде вертикальных линий,
каждая из которых изображает линию жизни отдельного объекта, участвующего
во взаимодействии. Графически каждый объект изображается прямоугольником и
располагается в верхней части своей линии жизни (рис. 16). Внутри
прямоугольника записываются имя объекта и имя класса, разделенные
двоеточием. При этом вся запись подчеркивается, что является признаком
объекта, который, как известно, представляет собой экземпляр класса.
Рис. 28 Различные графические примитивы диаграммы последовательности
Линия
жизни
объекта
(object
lifeline)
изображается
пунктирной
вертикальной линией, ассоциированной с единственным объектом на диаграмме
последовательности. Линия жизни служит для обозначения периода времени, в
течение которого объект существует в системе и, следовательно, может
потенциально участвовать во всех ее взаимодействиях. Если объект существует в
системе постоянно, то и его линия жизни должна продолжаться по всей плоскости
диаграммы последовательности от самой верхней ее части до самой нижней
(объекты 1 и 2 на рис. 16).
Отдельные объекты, выполнив свою роль в системе, могут быть
уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких
объектов линия жизни обрывается в момент его уничтожения. Для обозначения
момента уничтожения объекта в языке UML используется специальный символ в
форме латинской буквы "X" (объект 3 на рис. 16). Ниже этого символа
пунктирная линия не изображается, поскольку соответствующего объекта в
системе уже нет, и этот объект должен быть исключен из всех последующих
взаимодействий.
В процессе функционирования объектно-ориентированных систем одни
объекты могут находиться в активном состоянии, непосредственно выполняя
определенные действия или в состоянии пассивного ожидания сообщений от
других объектов. Чтобы явно выделить подобную активность объектов, в языке
UML применяется специальное понятие, получившее название фокуса управления
(focus of control). Фокус управления изображается в форме вытянутого узкого
прямоугольника (см. объект 1 на рис. 16), верхняя сторона которого обозначает
начало получения фокуса управления объекта (начало активности), а ее нижняя
сторона — окончание фокуса управления (окончание активности). Этот
прямоугольник располагается ниже обозначения соответствующего объекта и
может заменять его линию жизни, если на всем ее протяжении он является
активным.
Сообщения
Цель взаимодействия в контексте языка UML заключается в том, чтобы
описать связи между множеством взаимодействующих объектов. Каждое
взаимодействие описывается совокупностью сообщений, которыми участвующие
в нем объекты обмениваются между собой. В этом смысле сообщение (message)
представляет собой законченный фрагмент информации, который отправляется
одним объектом другому. При этом прием сообщения инициирует выполнение
определенных действий, направленных на решение отдельной задачи тем
объектом, которому это сообщение отправлено.
Таким образом, сообщения не только передают некоторую информацию, но
и требуют от принимающего объекта выполнения ожидаемых действий.
Сообщения
могут
инициировать
выполнение
операций
объектом
соответствующего класса, а параметры этих операций передаются вместе с
сообщением. На диаграмме последовательности все сообщения упорядочены по
времени своего возникновения в моделируемой системе.
В таком контексте каждое сообщение имеет направление от объекта,
который инициирует и отправляет сообщение, к объекту, который его получает.
Иногда отправителя сообщения называют клиентом, а получателя — сервером.
Сообщение от клиента имеет форму запроса некоторого сервиса, а реакция
сервера на запрос может быть связана с выполнением определенных действий или
передачи клиенту необходимой информации тоже в форме сообщения.
Рис. 29 Графическое изображение различных видов сообщений между
объектами на диаграмме последовательности
В языке UML могут встречаться несколько разновидностей сообщений,
каждое из которых имеет свое графическое изображение (рис. 17).
 Первая разновидность сообщения (рис. 17, а) является наиболее
распространенной и используется для вызова процедур, выполнения операций
или обозначения отдельных вложенных потоков управления. Начало этой стрелки
всегда соприкасается с фокусом управления или линией жизни того объектаклиента, который инициирует это сообщение. Конец стрелки соприкасается с
линией жизни того объекта, который принимает это сообщение и выполняет в
ответ определенные действия. При этом принимающий объект зачастую получает
и фокус управления, становясь активным.
 Вторая разновидность сообщения (рис. 17, б) используется для
обозначения простого (не вложенного) потока управления. Каждая такая стрелка
указывает на прогресс одного шага потока. При этом соответствующие
сообщения обычно являются асинхронными, т. е. могут возникать в произвольные
моменты времени. Передача такого сообщения обычно сопровождается
получением фокуса управления объектом, его принявшим.
 Третья разновидность (рис. 17, в) явно обозначает асинхронное
сообщение
между
двумя
объектами
в
некоторой
процедурной
последовательности. Примером такого сообщения может служить прерывание
операции при возникновении исключительной ситуации. В этом случае
информация о такой ситуации передается вызывающему объекту для
продолжения процесса дальнейшего взаимодействия.
 Наконец, последняя разновидность сообщения (рис. 17, г) используется
для возврата из вызова процедуры. Примером может служить простое сообщение
о завершении некоторых вычислений без предоставления результата расчетов
объекту-клиенту. В процедурных потоках управления эта стрелка может быть
опущена, поскольку ее наличие неявно предполагается в конце активизации
объекта. В то же время считается, что каждый вызов процедуры имеет свою пару
— возврат вызова. Для непроцедурных потоков управления, включая
параллельные и асинхронные сообщения, стрелка возврата должна указываться
явным образом.
В языке UML предусмотрены некоторые стандартные действия,
выполняемые в ответ на получение соответствующего сообщения. Они могут
быть явно указаны на диаграмме последовательности в форме стереотипа рядом с
сообщением, к которому они относятся. В этом случае они записываются в
кавычках. Используются следующие обозначения для моделирования действий:
 «call» (вызвать) – сообщение, требующее вызова операции или процедуры
принимающего объекта. Если сообщение с этим стереотипом рефлексивное, то
оно инициирует локальный вызов операции у самого пославшего это сообщение
объекта;
 «return» (возвратить) – сообщение, возвращающее значение выполненной
операции или процедуры вызвавшему ее объекту. Значение результата может
инициировать ветвление потока управления;
 «create» (создать) – сообщение, требующее создания другого объекта для
выполнения определенных действий. Созданный объект может получить фокус
управления, а может и не получить его;
 «destroy» (уничтожить) – сообщение с явным требованием уничтожить
соответствующий объект. Посылается в том случае, когда необходимо прекратить
нежелательные действия со стороны существующего в системе объекта, либо
когда объект больше не нужен и должен освободить задействованные им
системные ресурсы;
 «send» (послать) – обозначает посылку другому объекту некоторого
сигнала, который асинхронно инициируется одним объектом и принимается
(перехватывается) другим. Отличие сигнала от сообщения заключается в том, что
сигнал должен быть явно описан в том классе, объект которого инициирует его
передачу.
Рис. 30 Окончательный вариант диаграммы последовательности для
моделирования телефонного разговора
2.3.7 Диаграмма кооперации
Диаграмма кооперации предназначена для спецификации структурных
аспектов
взаимодействия.
заключается
в
Главная
возможности
особенность
графически
диаграммы
представить
кооперации
не
только
последовательность взаимодействия, но и все структурные отношения между
объектами, участвующими в этом взаимодействии.
На
диаграмме
кооперации
в
виде прямоугольников изображаются
участвующие во взаимодействии объекты, содержащие имя объекта, его класс и,
возможно, значения атрибутов. Далее указываются ассоциации между объектами
в виде различных соединительных линий. При этом можно явно указать имена
ассоциации
и
ролей,
которые
играют
объекты
в
данной
ассоциации.
Дополнительно могут быть изображены динамические связи — потоки
сообщений. Они представляются также в виде соединительных линий между
объектами, над которыми располагается стрелка с указанием направления, имени
сообщения и порядкового номера в общей последовательности инициализации
сообщений.
Рис. 31 Пример диаграммы кооперации для моделирования телефонного
разговора
2.3.8 Диаграмма компонентов
Диаграмма
разрабатываемой
компонентов
системы,
позволяет
установив
определить
зависимости
между
архитектуру
программными
компонентами, в роли которых может выступать исходный, бинарный и
исполняемый код. Во многих средах разработки модуль или компонент
соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают
отношения взаимозависимости, аналогичные тем, которые имеют место при
компиляции исходных текстов программ. Основными графическими элементами
диаграммы компонентов являются компоненты, интерфейсы и зависимости
между ними.
Диаграмма компонентов разрабатывается для следующих целей:
 визуализации общей структуры исходного кода программной системы;
 спецификации исполнимого варианта программной системы;
 обеспечения многократного использования отдельных фрагментов
программного кода;
 представления концептуальной и физической схем баз данных.
Диаграмма компонентов обеспечивает согласованный переход от
логического
представления
к
конкретной
реализации
проекта
в
форме
программного кода. Одни компоненты могут существовать только на этапе
компиляции программного кода, другие — на этапе его исполнения. Диаграмма
компонентов отражает общие зависимости между компонентами, рассматривая
последние в качестве классификаторов.
Для представления физических сущностей в языке UML применяется
специальный термин – компонент (component). Компонент реализует некоторый
набор интерфейсов и служит для общего обозначения элементов физического
представления модели. Для графического представления компонента может
использоваться специальный символ – прямоугольник со вставленными слева
двумя
более
прямоугольника
мелкими
прямоугольниками
записывается
имя
(рис.1).
компонента
и,
Внутри
объемлющего
возможно,
некоторая
дополнительная информация. Изображение этого символа может незначительно
варьироваться в зависимости от характера ассоциируемой с компонентом
информации.
В метамодели языка UML компонент является потомком классификатора.
Он предоставляет организацию в рамках физического пакета ассоциированным с
ним элементам модели. Как классификатор, компонент может иметь также свои
собственные свойства, такие как атрибуты и операции.
Рис. 32 Графическое изображение компонента в языке UML
Так, в первом случае (рис. 1, а) с компонентом уровня экземпляра
связывается только его имя, а во втором (рис. 1, б) — дополнительно имя пакета и
помеченное значение.
В языке UML выделяют три вида компонентов.
 компоненты развертывания, которые обеспечивают непосредственное
выполнение системой своих функций (такими компонентами могут быть
динамически подключаемые библиотеки с расширением dll (рис. 2, а), Webстраницы на языке разметки гипертекста с расширением html (рис. 2, б) и файлы
справки с расширением hlp (рис. 2, в)).
 компоненты-рабочие продукты (обычно это файлы с исходными текстами
программ, например, с расширениями h или срр для языка C++ (рис. 10.2, г)).
 компоненты исполнения, представляющие исполнимые модули — файлы
с расширением ехе.
Рис. 33
компонентов
Варианты
изображения
компонентов
на
диаграмме
Другой способ спецификации различных видов компонентов — явное
указание стереотипа компонента перед его именем. В языке UML для
компонентов определены следующие стереотипы:
 библиотека (library) – определяет первую разновидность компонента,
который представляется в форме динамической или статической библиотеки;
 таблица (table) – также определяет первую разновидность компонента,
который представляется в форме таблицы базы данных;
 файл (file) – определяет вторую разновидность компонента, который
представляется в виде файлов с исходными текстами программ;
 документ (document) – определяет вторую разновидность компонента,
который представляется в форме документа;
 исполнимый (executable) – определяет третий вид компонента, который
может исполняться в узле.
Следующим элементом диаграммы компонентов являются интерфейсы. В
общем случае интерфейс графически изображается окружностью, которая
соединяется с компонентом отрезком линии без стрелок (рис.3, а). При этом имя
интерфейса, которое обязательно должно начинаться с заглавной буквы "I",
записывается рядом с окружностью. Семантически линия означает реализацию
интерфейса, а наличие интерфейсов у компонента означает, что данный
компонент реализует соответствующий набор интерфейсов.
Рис. 34
компонентов
Графическое
изображение
интерфейсов
на
диаграмме
Другим способом представления интерфейса на диаграмме компонентов
является его изображение в виде прямоугольника класса со стереотипом
«интерфейс» и возможными секциями атрибутов и операций (рис. 3, б). Как
правило, этот вариант обозначения используется для представления внутренней
структуры интерфейса, которая может быть важна для реализации.
При разработке программных систем интерфейсы обеспечивают не только
совместимость различных версий, но и возможность вносить существенные
изменения в одни части программы, не изменяя другие ее части. Таким образом,
назначение интерфейсов существенно шире, чем спецификация взаимодействия с
пользователями системы (актерами).
Зависимости могут отражать связи модулей программы на этапе
компиляции и генерации объектного кода. В другом случае зависимость может
отражать наличие в независимом компоненте описаний классов, которые
используются в зависимом компоненте для создания соответствующих объектов.
Применительно к диаграмме компонентов зависимости могут связывать
компоненты и импортируемые этим компонентом интерфейсы, а также различные
виды компонентов между собой.
В первом случае рисуют стрелку от компонента-клиента к импортируемому
интерфейсу (рис. 4). Наличие такой стрелки означает, что компонент не реализует
соответствующий интерфейс, а использует его в процессе своего выполнения.
Причем на этой же диаграмме может присутствовать и другой компонент,
который реализует этот интерфейс. Так, например, изображенный ниже фрагмент
диаграммы компонентов представляет информацию о том, что компонент с
именем "main.exe" зависит от импортируемого интерфейса I Dialog, который, в
свою очередь, реализуется компонентом с именем "image.java". Для второго
компонента этот же интерфейс является экспортируемым.
Рис. 35 Фрагмент диаграммы компонентов с отношением зависимости
Заметим, что изобразить второй компонент с именем "image.java" в форме
варианта примечания нельзя именно в силу того факта, что этот компонент
реализует интерфейс.
Другим случаем отношения зависимости на диаграмме компонентов
является отношение между различными видами компонентов (рис. 5). Наличие
подобной зависимости означает, что внесение изменений в исходные тексты
программ или динамические библиотеки приводит к изменениям самого
компонента. При этом характер изменений может быть отмечен дополнительно.
Рис. 36 Графическое изображение отношения зависимости между
компонентами
На
диаграмме
компонентов
могут
быть
представлены
отношения
зависимости между компонентами и реализованными в них классами. Ниже
приводится фрагмент зависимости подобного рода, когда некоторый компонент
зависит от соответствующих классов.
Рис. 37 Графическое изображение зависимости между компонентом и
классами
Внутри символа компонента могут изображаться другие элементы
графической нотации, такие как классы (компонент уровня типа) или объекты
(компонент уровня экземпляра). В этом случае символ компонента изображается
так, чтобы вместить эти дополнительные символы (рис. 7).
Рис. 38 Графическое изображение компонента уровня экземпляра, реализующего
отдельные объекты
2.3.9 Диаграмма развертывания
Физическое представление программной системы не может быть полным,
если отсутствует информация о том, на какой платформе и на каких
вычислительных средствах она реализована. Первая из диаграмм физического
представления – диаграмма компонентов – рассмотрена выше. Второй формой
физического
представления
программной
системы
является
диаграмма
развертывания (синоним – диаграмма размещения). Она применяется для
представления общей конфигурации и топологии распределенной программной
системы и содержит распределение компонентов по отдельным узлам системы.
Кроме
того,
соединений
диаграмма
–
развертывания
маршрутов
передачи
показывает
информации
наличие
между
физических
аппаратными
устройствами, задействованными в реализации системы.
Диаграмма развертывания предназначена для визуализации элементов и
компонентов программы, существующих лишь на этапе ее исполнения (runtime).
При
этом
представляются
только
компоненты-экземпляры
программы,
являющиеся исполнимыми файлами или динамическими библиотеками. Те
компоненты, которые не используются на этапе исполнения, на диаграмме
развертывания не показываются. Так, компоненты с исходными текстами
программ могут присутствовать только на диаграмме компонентов. На диаграмме
развертывания они не указываются.
Диаграмма
развертывания
содержит
графические
изображения
процессоров, устройств, процессов и связей между ними. В отличие от диаграмм
логического представления, диаграмма развертывания является единой для
системы в целом, поскольку должна всецело отражать особенности ее реализации.
Эта диаграмма завершает процесс объектно-ориентированного анализа для
конкретной программной системы и её разработка, как правило, является
последним этапом спецификации модели.
Цели разработки диаграммы развертывания:
 определить распределение компонентов системы по ее физическим узлам;
 показать физические связи между всеми узлами реализации системы на
этапе ее исполнения;
 выявить узкие места системы и реконфигурировать ее топологию для
достижения требуемой производительности.
Узел (node) представляет собой некоторый физически существующий
элемент системы, обладающий некоторым вычислительным ресурсом. В качестве
вычислительного ресурса узла может рассматриваться, например, некоторый
объем памяти. Понятие узла может включать в себя не только вычислительные
устройства (процессоры), но и другие механические или электронные устройства,
такие
как
датчики,
принтеры,
модемы,
цифровые
камеры,
сканеры
и
манипуляторы.
Графически на диаграмме развертывания узел изображается в форме
трехмерного куба (прямоугольного параллелепипеда). Узел имеет собственное
имя, указываемое внутри этого графического символа. Сами узлы могут
представляться как в качестве типов (рис.8, а), так и в качестве экземпляров
(рис.8, б).
Рис. 39 Графическое изображение узла на диаграмме развертывания
В первом случае имя узла записывается без подчеркивания и начинается с
заглавной буквы. Во втором имя узла-экземпляра записывается в виде <имя узла
':' имя типа узла>. Имя типа узла указывает на некоторую разновидность узлов,
присутствующих в модели системы.
Рис. 40 Графическое изображение узла-экземпляра с дополнительной
информацией в форме помеченного значения
Если необходимо явно указать компоненты, которые размещаются на
отдельном узле, то это можно сделать двумя способами. Первый из них позволяет
разделить графический символ узла на две секции горизонтальной линией. В
верхней секции записывают имя узла, а в нижней секции — размещенные на этом
узле компоненты (рис. 10, а).
Второй способ разрешает показывать на диаграмме развертывания узлы с
вложенными изображениями компонентов (рис. 10, б). Важно помнить, что в
качестве таких вложенных компонентов могут выступать только исполняемые
компоненты.
Рис. 41 Варианты графического изображения узлов-экземпляров с
размещаемыми на них компонентами
Кроме собственно изображений узлов на диаграмме развертывания
указываются отношения между ними. В качестве отношений выступают
физические соединения между узлами и зависимости между узлами и
компонентами, изображения которых тоже могут присутствовать на диаграммах
развертывания.
Соединения
являются
разновидностью
ассоциации
и
изображаются
отрезками линий без стрелок. Наличие такой линии указывает на необходимость
организации
физического
канала
для
обмена
информацией
между
соответствующими узлами. Характер соединения может быть дополнительно
специфицирован примечанием, помеченным значением или ограничением. На
представленном ниже фрагменте диаграммы развертывания (рис. 11) определены
не только требования к скорости передачи данных по локальной сети с помощью
помеченного значения, но и рекомендации по технологии физической реализации
соединений в форме примечания.
Рис. 42 Фрагмент диаграммы развертывания с соединениями между
узлами
Кроме соединений на диаграмме развертывания могут присутствовать
отношения зависимости между узлом и развернутыми на нем компонентами.
Подобный
способ
является
альтернативой
вложенному
изображению
компонентов внутри символа узла, что не всегда удобно, поскольку делает этот
символ излишне объемным. Поэтому при большом количестве развернутых на
узле компонентов соответствующую информацию можно представить в форме
отношения зависимости (рис. 12).
Диаграммы развертывания могут иметь более сложную структуру,
включающую вложенные компоненты, интерфейсы и другие аппаратные
устройства. На изображенной ниже диаграмме развертывания (рис. 13)
представлен
фрагмент
физического
представления
системы
удаленного
обслуживания клиентов банка. Узлами этой системы являются удаленный
терминал (узел-тип) и сервер банка (узел-экземпляр).
Рис. 43 Диаграмма развертывания с отношением зависимости между
узлом и развернутыми на нем компонентами
Рис. 44 Диаграмма развертывания
обслуживания клиентов банка
для
системы
удаленного
Вариант физического представления этой транспортной системы показан на
следующей диаграмме развертывания (рис. 14).
Рис. 45 Диаграмма развертывания для модели системы управления
транспортной платформой
Данная диаграмма содержит самую общую информацию о развертывании
рассматриваемой системы и в последующем может быть детализирована при
разработке собственно программных компонентов управления.
2.4 Тестирование программного обеспечения
2.4.1 Основы тестирования
Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества
программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и
проблем в программных системах.
Тестирование программных систем состоит из динамической верификации поведения программ на
конечном (ограниченном) наборе тестов (set of test cases), выбранных соответствующим образом из
обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия
ожидаемому поведению системы.
В данном определении тестирования выделены слова, определяющие основные вопросы, которым
адресуется данная область знаний:

Динамичность (dynamic): этот термин подразумевает тестирование всегда предполагает
выполнение тестируемой программы с заданными входными данными. При этом, величины,
задаваемые на вход тестируемому программному обеспечению, не всегда достаточны для
определения теста. Сложность и недетерминированность систем приводит к тому, что система
может по разному реагировать на одни и те же входные параметры, в зависимости от состояния
системы. В данной области знаний термин “вход” (input) будет использоваться в рамках
соглашения о том, что вход может также специфицировать состояние системы, в тех случаях,
когда это необходимо. Кроме динамических техник проверки качества, то есть тестирования,
существуют также и статические техники, рассматриваемые в области знаний “Software Quality”.

Конечность (ограниченность, finite): даже для простых программ теоретически возможно столь
большое количество тестовых сценариев, что исчерпывающее тестирование может занять
многие месяцы и даже годы. Именно поэтому, с практической точки зрения, всестороннее
тестирование считается бесконечным. Тестирование всегда предполагает компромисс между
ограниченными ресурсами и заданными сроками, с одной стороны, и практически
неограниченными требованиями по тестированию, с другой. То есть мы снова говорим об
определении характеристик “приемлемого” качества, на основе которых планируем необходимы
объем тестирования.

Выбор (selection): многие предлагаемые техники тестирования отличаются друг от друга в том,
как выбираются сценарии тестирования. Инженеры по программному обеспечению должны
обладать представлением о том, что различные критерии выбора тестов могут давать разные
результаты, с точки зрения эффективности тестирования. Определение подходящего набора
тестов для заданных условий является очень сложной проблемой. Обычно, для выбора
соответствующих тестов совместно применяют техники анализа рисков, анализ требований и
соответствующую экспертизу в области тестирования и заданной прикладной области.

Ожидаемое поведение (expected behaviour): Хотя это не всегда легко, все же необходимо
решить, какое наблюдаемое поведение программы будет приемлемо, а какое – нет. В противном
случае, усилия по тестированию – бесполезны. Наблюдаемое поведение может рассматриваться
в контексте пользовательских ожиданий (подразумевая “тестирования для проверки” - testing for
validation), спецификации (“тестирование для аттестации” - testing for verification) или, наконец, в
контексте предсказанного поведения на основе неявных требований или обоснованных
ожиданий. См. тему SWEBOK 6.4 “Приемочные тесты” области знаний “Software Requirements”.
Общий взгляд на тестирование программного обеспечения последние годы активно эволюционировал,
становясь все более конструктивным, прагматичным и приближенным к реалиям современных проектов
разработки программных систем. Тестирование более не рассматривается как деятельность,
начинающаяся только после завершения фазы конструирования. Сегодня тестирование
рассматривается как деятельность, которую необходимо проводить на протяжении всего процесса
разработки и сопровождения и является важной частью конструирования программных продуктов.
Действительно, планирование тестирования должно начинаться на ранних стадиях работы с
требованиями, необходимо систематически и постоянно развивать и уточнять планы тестов и
соответствующие процедуры тестирования. Даже сами по себе сценарии тестирования оказываются
очень полезными для тех, кто занимается проектированием, позволяя выделять те аспекты требований,
которые могут неоднозначно интерпретироваться или даже быть противоречивыми.
Не секрет, что легче предотвратить проблему, чем бороться с ее последствиями. Тестирование, наравне
с управлением рисками, является тем инструментом, который позволяет действовать именно в таком
ключе. Причем действовать достаточно эффективно. С другой стороны, необходимо осознавать, что
даже если приемочные тесты показали положительные результаты, это совсем не означает, что
полученный продукт не содержит ошибок. Этим вопросам, в частности, адресована область знаний
“Сопровождение программного обеспечения” (Software Maintenance). Однако, адекватное внимание
вопросам тестирования качественно снижает риск возникновения ошибок на этапе эксплуатации,
обеспечивая более высокую удовлетворенность пользователей, что и является, по существу, целью
любого проекта.
В области знаний “Качество программного обеспечения” (Software Quality) техники управления качеством
четко разделены на статические (без выполнения кода) и динамические (с выполнением кода). Обе эти
категории важны. Данная область знаний - “Тестирование” – касается динамических техник.
Как уже отмечалось ранее, тестирование тесно связано с областью знаний “Конструирование” (Software
Construction). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как
неотъемлемый элемент деятельности по конструированию.
Рисунок 5. Область знаний “Тестирование программного обеспечения” [SWEBOK, 2004, с.5-2, рис. 1]
Критерии отбора тестов могут использоваться как для создания набора тестов, так и для проверки,
насколько выбранные тесты адекватны решаемым задачам (тестирования). При этом, обсуждаемые
критерии помогают определить, когда можно или необходимо прекратить тестирование.
Эффективность тестирования/Цели тестирования (Test effectiveness/Objectives for testing)
Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с
заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или
целями тестирования. Эффективность теста может быть определена только в контексте заданных
условий.
Тестирование для идентификации дефектов (Testing for defect identification)
Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден.
Это отличается от подхода в тестировании, когда тесты запускаются для демонстрации того, что
программное обеспечение удовлетворяет предъявляемым требованиями и, соответственно, тест
считается успешным, если не найдено дефектов.
Проблема оракула (The oracle problem)
“Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение
программы, формулируя вердикт - тест пройден (“pass”) или нет (“fail”).
Теоретические и практические ограничения тестирования (Theoretical and practical limitation of testing)
Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных
тестов. К сожалению, большинство установленных результатов теории тестирования – негативны,
означая, по словам Дейкстры (Dijkstra), то, что “тестирование программы может использоваться для
демонстрации наличия дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том,
что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения.
Проблема неосуществимых путей (The problem of infeasible paths)
Эта сложнейшая проблема автоматизированного тестирования связана с тем, что путь, по которому
выполняются потоки работ тестируемой программной системы, не могут быть заданы входными
параметрами.
Тестируемость (Testability)
Это понятие может подразумевать две различных идеи. Первая описывает степень легкости описания
критериев покрытия тестами для заданной программной системы. Вторая определяет возможность
вероятность, возможность статистического измерения того, что при тестировании проявится сбой
программной системы. Обе интерпретации этого понятия одинаково важны для тестирования.
Тестирование программного обеспечения отличается от статических техник управления качеством,
проверки корректности, отладки и программирования, но связано со всеми этими работами. Полезно
рассматривать тестирование с точки зрения аналитиков и специалистов по сертификации качества.
2.4.2 Уровни тестирования
2.4.2.1 Над чем производятся тесты
Тестирование обычно производится на протяжении всей разработки и сопровождения на разных
уровнях. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем,
группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться
приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и
методологий.
2.1.1 Модульное тестирование (Unit testing)
Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента
системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный
вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем
интегрированную концепцию систематического и документированного подхода к модульному
тестированию.
2.1.2 Интеграционное тестирование (Integration testing)
Данный уровень тестирования является процессом проверки взаимодействия между программными
компонентами/модулями.
Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются
для традиционных, иерархически структурированных систем и их сложно применять, например, к
тестированию слабосвязанных систем, построенных в сервисно-ориентированных архитектурах (SOA).
Современные стратегии в большей степени зависят от архитектуры тестируемой системы и строятся на
основе идентификации функциональных “потоков” (например, потоков операций и данных).
Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на
достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования
базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов,
связанных с тестированием результатов очередного длительного этапа работ, когда количество
выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска
и тестирования только крупных релизов называют “big bang”).
2.1.3 Системное тестирование (System testing)
Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев
должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь,
системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности,
производительности, точности, надежности т.п.
На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению,
операционной среде и т.д.
2.4.2.2 Цели тестирования
Тестирование проводится в соответствии с определенными целями (могут быть заданы явно или
неявно) и различным уровнем точности. Определение цели точным образом, выражаемым
количественно, позволяет обеспечить контроль результатов тестирования.
Тестовые сценарии могут разрабатываться как для проверки функциональных требований (известны как
функциональные тесты), так и для оценки нефункциональных требований. При этом, существуют такие
тесты, когда количественные параметры и результаты тестов могут лишь опосредованно говорить об
удовлетворении целям тестирования (например, “usability” – легкость, простота использования, в
большинстве случаев, не может быть явно описана количественными характеристиками).
Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно,
виды) тестирования:
2.2.1 Приёмочное тестирование (Acceptance/qualification testing)
Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том
случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как
сторона “принимающая” программную систему, или специфицированы типовые задачи, успешная
проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика.
Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них.
2.2.2 Установочное тестирование (Installation testing)
Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы
в целевом окружении.
2.2.3 Альфа- и бета-тестирование (Alpha and beta testing)
Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии
альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных
внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий
продукта, обрабатываются в соответствии с определенными процедурами, включающими
подтверждающие тесты (любого уровня), проводимые специалистами группы разработки.
Данный вид тестирования не может быть заранее спланирован.
2.2.4 Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness
testing)
Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы,
предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.
2.2.5 Достижение и оценка надежности (Reliability achievement and evaluation)
Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности
программных систем. Случайно генерируемые сценарии тестирования могут применяться для
статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться
при использовании моделей повышения надежности. Эти вопросы затрагиваются и в тематическом
фрагменте 4.1.4 “Life test, reliability evaluation”.
2.2.6 Регрессионное тестирование (Regression testing)
Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering
Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки
сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это
означает, что если система успешно проходила тесты до внесения модификаций, она должна их
проходит и после внесения таковых. Основная проблема регрессионного тестирования заключается в
поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких тестов по мере
внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить
критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты.
2.2.7 Тестирование производительности (Performance testing)
Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к
параметрам производительности. Существует особый подвид таких тестов, когда делается попытка
достижения количественных пределов, обусловленных характеристиками самой системы и ее
операционного окружения.
2.2.8 Нагрузочное тестирование (Stress testing)
Необходимо понимать отличия между рассмотренным выше тестированием производительности с
целью достижения ее реальных (достижимых) возможностей производительности и выполнением
программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик
и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.
2.2.9 Сравнительное тестирование (Back-to-back testing)
Единичный набор тестов, позволяющих сравнить две версии системы.
2.2.10 Восстановительные тесты (Recovery testing)
Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster),
влияющей на функционирование операционной среды, в которой выполняется система.
2.2.11 Конфигурационное тестирование (Configuration testing)
В случаях, если программное обеспечение создается для использования различными пользователями (в
терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности
системы в различных конфигурациях.
2.2.12 Тестирование удобства и простоты использования (Usability testing)
Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не
только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно
пользователь может выполнять задачи, автоматизация которых осуществляется с использованием
данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных
сбоев) от ошибок пользователя.
2.2.13 Разработка, управляемая тестированием (Test-driven development)
По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки,
жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих
спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке
удовлетворения требований программной системой.
Иногда говорят о таком стиле разработки как о самостоятельной методологии – TDD. Насколько это
верно, зависит от того, что именно понимать под методологией разработки. Скорее, с точки зрения
автора, это техника, практика или стиль организации работы, чем самостоятельная методология.
В меньшей степени это относится к FDD – Feature-Driven Development (разработка на основе
функциональных возможностей). TDD может естественно рассматриваться как составная часть XP или,
как минимум Agile-методов. В свою очередь, FDD может рассматриваться как один из методов гибкой
разработки.
В чем отличие столь близких, на первый взгляд, подходов (и, кстати, соответствующих аббревиатур)?
Причина – проста. Тесты – инструмент достижения характеристик системы, удовлетворяющей
заданным требованиям, то есть потребностям пользователей, а “возможности” (features) – практически
сами (чаще – функциональные) требования, воплощенные (в идеальном случае) в код.
2.4.3 Техники тестирования
3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software
engineer’s intuition and experience)
3.1.1 Специализированное тестирование (Ad hoc testing)
Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции и знаниях
инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. Данный вид
тестирования может быть полезен для идентификации тех тестов, которые не охватываются
рассматривавшимеся выше более формализованными техниками.
3.1.2 Исследовательское тестирование (Exploratory testing)
Такое тестирование определяется как одновременное обучение, проектирование теста и его
исполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тесты
создаются, выполняются и модифицируются динамически, по мере необходимости. Эффективность
исследовательских тестов напрямую зависит от знаний инженера, формируемых на основе поведения
тестируемого продукта в процессе проведения тестирования, степени знакомства с приложением,
платформой, типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным
продуктом и т.п.
3.2 Техники, базирующиеся на спецификации (Specification-based techniques)
3.2.1 Эквивалентное разделение <приложения> (Equivalence partitioning)
Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов,
которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик
<спецификации>. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов
эквивалентных классов (или наборов классов).
3.2.2 Анализ граничных значений (Boundary-value analysis)
Тесты строятся с ориентацией на использование тех величин, которые определяют предельные
характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести
(robustness testing) системы, проводимые с величинами, выходящими за рамки специфицированных
пределов значений.
3.2.3 Таблицы принятия решений (Decision table)
Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве
“входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится
последовательным рассмотрением всех возможных кросс-связей в такой таблице.
3.2.4 Тесты на основе конечного автомата (Finite-state machine-based)
Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в
соответствующей модели (переходов и состояний приложения).
3.2.5 Тестирование на основе формальной спецификации (Testing from formal specification)
Для спецификации, определенных с использованием формального языка, возможно автоматически
создавать и тесты для функциональных требований. В ряде случаев могут строится на основе модели,
являющейся частью спецификации, не использующей формального языка описания.
3.2.6 Случайное тестирование (Random testing)
В отличие от статистического тестирования (будет рассматриваться в 3.5.1 “Operational profile”), сами
тесты генерируются случайным образом по списку заданного набора специфицированных
характеристик.
3.3 Техники, ориентированные на код (Code-based techniques)
3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)
Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени
напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов. Максимальная
отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы –
по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов
оценивается как процент покрытия всех возможных путей блок-схемы.
3.3.2 Тесты на основе потоков данных (Data-flow-based criteria)
В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения
(определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В
реальной практике используются нестрогое тестирование такого вида, ориентированное, например,
только на проверку задания начальных значений всех переменных или всех вхождений переменных в
код, с точки зрения их использования.
3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based
testing – flowgraph, call graph)
Является не столько техникой тестирования, сколько контролем структуры программы, представленной
в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на
основе анализа кода).
3.4 Тестирование, ориентированное на дефекты (Fault-based techniques)
Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно,
ориентированы на ошибки. Точнее – на специфические категории ошибок.
3.4.1 Предположение ошибок (Error guessing)
Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате
анализа рисков.
3.4.2 Тестирование мутаций (Mutation testing)
Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных
синтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаются для
оригинального и всех “мутировавших” вариантов тестируемой программы.
SWEBOK фокусируется на возможности, с помощью тестов, определять отличия между мутантами и
исходным вариантом кода. Если такое отличие установлено, мутанта “убивают”, а тест считается
успешным. Обычно, данный подход фокусируется на синтаксических ошибках, на практике
отслеживаемых современными средами разработки и, конечно, компиляторами.
3.5 Техники, базирующиеся на условиях использования (Usage-based techniques)
3.5.1 Операционный профиль (Operational profile)
Базируется на условиях использования системы.
Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении,
которое максимально приближено к реальным условиям работы системы. Результаты таких тестов
позволяют оценить поведение системы в реальных условиях. Входные параметры тестов задаются на
основе вероятностного распределения соответствующих параметров или их наборов при эксплуатации
(входные данные могут прогнозироваться исходя из частоты возможных сценариев работы
пользователей).
3.5.2 Тестирование, базирующееся на надежности инженерного процесса (Software Reliability Engineered
Testing)
Базируется на условиях разработки системы.
Соответствующие тесты (обозначаемые также аббревиатурой SRET от Software Reliability Engineered
Testing) проектируются в контексте используемого процесса разработки и методик тестирования.
3.6 Техники, базирующиеся на природе приложения (Techniques based on the
nature of the application)
Описанные выше техники могут применяться к любым типам программных систем. В то же время, в
зависимости от технологической или архитектурной природы приложений, могут также применять
специфические техники, важные именно для заданного типа приложения. Среди таких техник:





Объектно-ориентированное тестирование
Компонентно-ориентированное тестирование
Web-ориентированное тестирование
Тестирование на соответствие протоколам
Тестирование систем реального времени
3.7 Выбор и комбинация различных техник (Selecting and combining techniques)
3.7.1 Функциональное и структурное (Functional and structural)
Техники тестирования, строящиеся на основе спецификаций или кода часто называют
функциональными или структурными, соответственно. Оба подхода не должны противопоставляться, но
дополнять друг друга.
3.7.1 Определенное или случайное (Deterministic vs. random)
Обычно тесты можно распределить по данным группам на основе используемой политики выбора или
определения входных параметров тестов.
2.4.3.1 Техники, базирующиеся на интуиции и опыте инженера
2.4.3.2 Техники, базирующиеся на спецификации
2.4.3.3 Техники, ориентированные на код
2.4.3.4 Тестирование, ориентированное на дефекты
2.4.3.5 Техники, базирующиеся на условиях использования
2.4.3.6 Техники, базирующиеся на природе приложения
2.4.3.7 Выбор и комбинация различных техник
2.4.4 Измерение результатов тестирования
2.4.4.1 Оценка программ в процессе тестирования
Часто техники тестирования путают с целями тестирования. Степень покрытия тестами - не то же самое,
что высокое качество тестируемой системы. Однако, эти вопросы связаны. Чем выше степень покрытия,
чем больше вероятность обнаружения скрытых дефектов. Когда мы говорим о результатах
тестирования, мы должны подходить к их оценке, как оценке самой тестируемой системы. Именно
количественные оценки результатов тестирования (но не самих тестов, например, покрытия ими
возможных сценариев работы системы) освещаются ниже. В свою очередь, метрики самих тестов или
процесса тестирования, как такового – вопросы, рассматриваемые в областях знаний “Процессы
программной инженерии” (Software Engineering Process) и “Управление инженерной деятельностью”
(Software Engineering Management).
Измерения являются инструментом анализа качества. Измерение результатов тестирования касается
оценки качества получаемого продукта – программной системы. История измерений демонстрирует
прогресс достижения приемлемого качества. Такая история является инструментом менеджмента
качества.
4.1 Оценка программ в процессе тестирования (Evaluation of the program under
test, IEEE 982.1-98)
4.1.1 Измерения программ как часть планирования и разработки тестов (Program measurements to aid in
planning and design testing)
Данные измерения могут базироваться на размере программ (например, в терминах количества строк
кода или функциональных точек) или их структуре (например, с точки зрения оценки ее сложности в тех
или иных архитектурных терминах). Структурные измерения могут также включать частоту обращений
одних модулей программы к другим.
4.1.2 Типы дефектов, их классификация и статистика возникновения (Fault types, classification and
statistics)
В литературе по тестированию встречается большое количество различных классификаций дефектов.
Эффективность тестирования может быть достигнута в том случае, если мы понимаем какие типы
дефектов могут быть найдены в процессе тестирования программной системы и как изменяется их
частота во времени (подразумевая историческую перспективу развития системы, а не её сбоев в
процессе работы). Эта информация позволяет прогнозировать качество системы и помогает
совершенствовать процесс разработки, в целом.
Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”.
4.1.3 Плотность дефектов (Fault density)
Тестируемая программа может оцениваться на основе подсчета и классификации найденных дефектов.
Для каждого класса дефектов можно определить отношение между количеством соответствующих
дефектов и размером программы (в терминах выбранных метрик оценки размера).
4.1.4 Жизненный цикл тестов, оценка надежности (Life test, reliability evaluation)
Статистические ожидания в отношении надежности программной системы (см. выше 2.2.5 “Достижение и
оценка надежности ”) могут использоваться для принятия решения о продолжении или прекращении
(окончании) тестирования, исходя из заданных параметров приемлемого качества (например, плотности
дефектов заданного класса).
4.1.5 Модели роста надежности (Reliability growth models)
Данные модели обеспечивают возможности прогнозирования надежности системы, базируясь на
обнаруженных сбоях (см. выше 2.2.5). Модели такого рода разбиваются на две группы – по количеству
сбоев (failure-count) и времени между сбоями (time-between-failure).
2.4.4.2 Оценка выполненных тестов
4.2.1 Метрики покрытия/глубины тестирования (Coverage/thoroughness measures)
Критерии “адекватности” тестирования, в ряде случаев, требуют систематического выполнения тестов
для определенных набора элементов программы, задаваемых ее архитектурой или спецификацией.
Соответствующие метрики позволяют оценить степень охвата характеристик системы (например,
процент различных тестируемых параметров производительности) и глубину их детализации (например,
случайное тестирование параметров производительности или с учетом граничных значений и т.п.).
Такие метрики помогают прогнозировать вероятностное достижение заданных параметров качества
системы.
4.2.2 Введение искусственных дефектов (Fault seeding)
“Своими руками?! Никогда! ...” – такова, обычно, первая реакция на идею искусственного внесения
дефектов, например, в программный код. На практике, этот подход помогает классифицировать
возможные ошибки и следующие за ними сбои, применяя в дальнейшем полученные результаты для
моделирования (пусть, часто, и интуитивного) возможных причин реальных сбоев, обнаруженных в
процессе тестирования.
Безусловно, данная техника должна использоваться с максимальной осторожностью опытными
специалистами, хорошо представляющими общую архитектуру тестируемой программной системы и
разбирающимеся во её внутренних связях.
4.2.3 Оценка мутаций (Mutation score)
Получаемое в процессе тестирования мутаций (см. выше 3.4.2) отношение “убитых” к общему числу
сгенерированных мутантов помогает измерить эффективность выполняемых тестов. В силу специфики
такой техники тестирования, количественные оценки мутаций имеют практическое значение только для
определенных типов систем.
4.2.4 Сравнение и относительная эффективность различных техник тестирования (Comparison and
relative effectiveness of different techniques)
Различные исследования в области тестирования связаны с попытками сравнения (с точки зрения
достигаемого качества продукта) разных подходов к тестированию. Когда мы говорим об
“эффективности” тестирования надо чётко договориться, что именно мы подразумеваем под
эффективностью, желательно, в количественном выражении. Возможные варианты интерпретации этого
понятия – число тестов (данной техники), необходимых для обнаружения первого дефекта; отношение
количества всех обнаруженных дефектов к дефектам, найденным с применением заданного подхода и
т.п. Только обладая такого рода данными можно говорить о корректности сравнения и оценки
эффективности.
2.4.5 Процесс тестирования
2.4.5.1 Практические соображения
Концепции, стратегии, техники и измерения тестирования должны быть объеденены в единый процесс
тестирования как деятельности по обеспечению качества. Процесс тестирования поддерживает работы
по тестированию и определяет “правила игры” для членов команды тестирования – от планирования
тестов до оценки их результатов. Хотя, в большинстве современных методов разработки, в частности,
гибких (agile) подходов, тестирование выходит на передний план и является одной из базовых практик,
многостороннее тестирование и, тем более, прогнозирование на основе полученных результатов, часто
подменяется отдельными работами в этой области, не позволяющими добиться необходимых
параметров качества (что, кстати, ясно показывают уже упоминавшиеся результаты исследований
Standish Group [Chaos, 2004]). Только в том случае, если тестирование рассматривать как один из
важных процессов всей деятельности по созданию и поддержке программного обеспечения, можно
добиться оценки стоимости соответствующих работ и, в конце концов, соблюсти те ограничения,
которые определены для проекта.
2.4.5.2 Тестовые работы
Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, что успешное
управление тестовыми работами сильно зависит от процессов конфигурационного управления (Software
Configuration Management), рассматриваемых позднее как самостоятельная область знаний.
5.2.1 Планирование (Planning)
Также как и другие аспекты управления проектами, работы по тестированию должно планироваться
заранее. Как минимум, на уровне организации соответствующего процесса. Ключевые аспекты
планирования тестовой деятельности включают:



координацию персонала
управление оборудованием и другими средствами, необходимыми для организации
тестирования
планирование обработки нежелательных результатов (т.е. является управлением
определенными видами рисков)
В случае одновременной поддержки и сопровождения нескольких версий программной системы или
нескольких систем, необходимо уделять особое внимание планированию времени, усилий и ресурсов,
связанных с проведением работ по тестированию. Данная позиция перекликается с вопросами
управления портфелями проектов с точки зрения общего управления проектами.
5.2.2 Генерация сценариев тестирования (Test-case generation)
Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты
должны находиться под управлением системы конфигурационного управления и описывать ожидаемые
результаты тестирования.
5.2.3 Разработка тестового окружения (Test environment development)
Используемое для тестирования окружение должно быть совместимо с инструментами программной
инженерии (будут рассматриваться позднее как тема самостоятельной области знаний). Это окружение
должно обеспечивать разработку и контроль тестовых сценариев, ведение журнала тестирования, и
возможности восстановления ожидаемых и отслеживаемых результатов тестирования, самих
сценариев, а также других активов тестирования.
5.2.4 Выполнение тестов (Execution)
Выполнение тестов должно содержать основные принципы ведения научного эксперимента:




должны фиксироваться все работы и результаты процесса тестирования
форма журналирования таких работ и их результатов должна быть такой, чтобы
соответствующее содержание было понятно, однозначно интрепретируемой и повторяемо
другими лицами (не теми, кто первоначально проводил тестирование)
тестирование должно проводиться в соответствии с заданными и документированными
процедурами
тестирование должно производиться над однозначно идентифицируемой версией и
конфигурацией программной системы
Ряд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 1008-87.
5.2.5 Анализ результатов тестирования (Test results evaluation)
Для определения успешности тестов их результаты должны оцениваться, анализироваться. В
большинстве случаев, “успешность” тестирования подразумевает, что тестируемое программное
обеспечение функционирует так, как ожидалось и в процессе работы не приводит к непредусмотренным
последствиям. Не все такие последствия обязательно являются сбоями, они могут восприниматься как
“помехи”. Однако, любое непредусмотренное поведение может стать источником сбоев при изменении
конфигурации или условий функционирования системы, поэтому требуют внимания, как минимум, с
точки зрения идентификации причин таких помех. Перед устранением обнаруженного сбоя, необходимо
определить и зафиксировать те усилия, которые необходимы для анализа проблемы, отладки и
устранения. Это позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, в
перспективе, иметь возможность улучшения самого процесса тестирования. В тех случаях, когда
результаты тестирования особенно важны, например, в силу критичности обнаруженного сбоя, может
быть сформирована специальная группа анализа (review board).
5.2.6 Отчёты о проблемах/журнал тестирования (Problem reporting/Test log)
Во многих случаях, в процессе тестовой деятельности ведётся журнал тестирования, фиксирующий
информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой
конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии
контекста конфигурационного управления) и т.п. Неожиданные или некорректные результаты тестов
могут записываться в специальной подсистеме ведения отчетности по сбоям (problem-reporting system,
обеспечивая формирование базы данных, используемой для отладки, устранения проблем и
дальнейшего тестирования. Кроме того, аномалии (помехи), которые нельзя идентифицировать как
сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом
случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать
вопросы повышения надежности самой тестируемой системы. Отчёты по тестам могут являться входом
для процесса управления изменениями и генерации запросов на изменения (change request) в рамках
процессов конфигурационного управления (см. далее соответствующую область знаний “Software
Configuration Management”).
5.2.7 Отслеживание дефектов (Defect tracking)
Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками,
присутствующими в тестируемой программной системе (также они могут быть следствием поведения
операционного
и/или
тестового
окружения).
Такие
дефекты
могут
(и,
чаще
всего,
должны)
анализироваться для определения момента и места первого появления данного дефекта в системе,
какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования,
некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые. Вся эта
информация используется для определения того, как может быть улучшен сам процесс тестирования и
насколько критична необходимость таких улучшений.
2.5 Сопровождение программного обеспечения
Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию
программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе
эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при
реальном использовании скрытых дефектов, изменениями в операционном окружении, необходимостью
покрытия новых требований и т.п.
Фаза сопровождения в жизненном цикле, обычно, начинается сразу после приемки/передачи продукта и
действует в течение периода гарантии или, чаще, технической поддержки. Однако, сама деятельность,
связанная с сопровождением, начинается намного раньше.
Сопровождение программного обеспечения является составной частью жизненного цикла. К сожалению,
так сложилось, что вопросам сопровождения уделяется существенно меньше внимания, чем другим
фазам жизненного цикла. Исторически, в большинстве организаций, разработка программных систем
явно в фаворе, по сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно
начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний ITIL* – IT Infrastructure Library,
уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных
технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций
организаций непосредственно в разработку программных систем, с целью увеличения сроков
использования уже существующего и применяемого ПО. Конечно, с точки зрения автора, это не
единственная причина. Скорее вопросы постоянно изменяющихся бизнес-потребностей, динамика
бизнеса и желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли
поддержки и сопровождения программного обеспечения и естественной интеграции такой деятельности
в бизнес-процессы подразделений информационных технологий.
* ITIL, в частности, определяет три аспекта управления жизненным циклом приложений – определение
требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте
программного обеспечения, относится к деятельности по управлению приложениями – Application
Management в ITIL ICT Infrastructure Management (ICT - Information and Communications Technology).
Если проблема 2000 года, в свое время, оказала особое влияние на изменение отношения к
сопровождению на Западе, то расширение применения продуктов Open Source во всем мире и
связанная с ним волна надежд на получение дешевого решения существующих задач привела к тому,
что вопросы сопровождения вышли для многих организаций на первый план. Ситуация во многих ИТподразделениях показывает, что такие надежды оправдались только частично. Использование
продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело даже к бОльшим
проектным затратам именно в силу недостаточно проработанной политики эксплуатации и
сопровождения построенных на их основе прикладных решений. Это ни в коем случае не значит, что
волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости
сопровождения привело к превышению бюджетов, недостатку ресурсов и, в конце концов, частому
провалу инициатив по использованию таких продуктов в корпоративной среде. Неготовность
рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в
эксплуатацию, непроработанность соответствующих процедур корректировки продукта после его
выпуска – основная беда и в бизнесе-среде, для которой программное обеспечение лишь инструмент, и
в компаниях-интеграторах, “забывающих” о необходимости развития успеха после внедрения системы у
заказчика, и у независимых поставщиков программных продуктов, которые, выпуская новую версию
лучшего в своем классе продукта, начинают работать над новой версией, уделяя недостаточное
внимание поддержке и обновлению уже существующих версий.
Сопровождение программного обеспечения в SWEBOK определяется как вся совокупность
деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки
программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после
этого. Предварительные работы включают планирование деятельности по сопровождению системы, а
также организацию перехода к ее полнофункциональному использованию. Если новая система должна
заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне
эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно
обеспечить плавный переход со старой системы на новую, максимально естественный для
пользователей. С этим связано не только планирование, например, переноса информации, хранимой в
соответствующих базах данных, но и обучение пользователей, подготовка, настройка и проверка
“боевой” конфигурации, определение последовательности операций, организация и обучение службы
поддержки (help-desk) и т.п.
Область знаний “Сопровождение программного обеспечения” связана с другими аспектами программной
инженерии. По-сути, описание этой области знаний непосредственно пересекается со всеми другими
дисциплинами.
Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1]
2.5.1 Основы сопровождения программного обеспечения
2.5.1.1 Определения и терминология
Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software
Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для
устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов)
продукта, или адаптации продукта для использования в модифицированном окружении. Интересно, что
данный стандарт также касается вопросов подготовки к сопровождению до передачи системы в
эксплуатацию, однако, структурно это сделано на уровне соответствующего информационного
приложения, включенного в стандарт.
В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует
сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает
сопровождение как процесс модификации программного продукта в части его кода и документации для
решения возникающих проблем <при эксплуатации> или реализации потребностей в улучшениях <тех
или иных характеристик продукта>. Задача состоит в модификации продукта при условии сохранения его
целостности. Международный стандарт ISO/IEC 14764 (Standard for Software Engineering - Software
Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт
12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи
системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по
сопровождению.
2.5.1.2 Природа сопровождения
Сопровождение поддерживает функционирование программного продукта на протяжении всего
операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения
фиксируются и отслеживаются запросы на модификацию (также называемые “запросами на изменения”
– change requests, в частности, в контексте конфигурационного управления), оценивается влияние
предлагаемых изменений, модифицируется код и другие активы (артефакты) продукта, проводится
необходимое тестирование и, наконец, выпускается обновленная версия продукта. Кроме того,
проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей
версией продукта. В SWEBOK отмечается, что сопровождение, с точки зрения операций отслеживания и
контроля, обладает большим содержанием, чем разработка (в общем понимании). Объем и активность
операций по контролю разработки в большой степени зависит от сложившихся практик,
внутрикорпоративных регламентов и требований, а также применяемых методологий и концепции
управления (в частности – проектного менеджмента). Так или иначе, отслеживание и контроль –
ключевые элементы деятельности по сопровождению программного обеспечения (как и других ИТактивов предприятия).
Стандарт 12207 определяет понятие “maintainer” - в соответствующем ГОСТ он именуется как “персонал
сопровождения”, подразумевая организацию, выполняющая работы по сопровождению. SWEBOK
использует данный термин, также, и в отношении лиц (individuals), проводящих определенные работы по
сопровождению, в отличие, например, от разработчиков, занимающихся реализацией системы в
программном коде.
Стандарт жизненного цикла 12207 также идентифицирует основные работы по сопровождению:
реализация процесса <сопровождения>, анализ проблем и модификаций (изменений), реализаций
модификаций, обзор (оценка)/принятие <решений> по сопровождению, миграция (с одной версии
программного продукта на другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти
работы описываются далее в теме 3.2 “Работы по сопровождению” (Maintenance Activities).
Специалисты по сопровождению (персонал сопровождения) могут получать знания о программном
продукте непосредственно от разработчиков. Взаимодействие с разработчиками и раннее привлечение
этих специалистов помогает уменьшить усилия, необходимые для адекватного сопровождения
программной системы. По мнению автора, передача знаний персоналу сопровождения, его обучение,
должно начинаться не позднее начала опытной эксплуатации продукта. В противном случае, усилия на
одновременную поддержку прикладной системы и обучение соответствующих специалистов не только
превысит реально допустимые нормы загрузки персонала (как группы или службы сопровождения и
техподдержки, так и разработчиков системы), но снизит эффективность поддержки пользователей на
критически важном этапе первоначального использования новой системы. По опыту автора и
результатам обсуждения этого вопроса с сотрудниками внутрикорпоративных ИТ-департаментов,
обычно, в зависимости от сложности системы, пик нагрузки на службу сопровождения приходится в
течении первых 2 - 6 недель, с момента передачи системы в реальную эксплуатацию, тем более, при
отказе от использования старой системы или ее предыдущей версии. SWEBOK отмечает, что, в
некоторых случаях, инженеры (создававшие систему) не могут быть привлечены к обучению и
поддержке персонала сопровождения. Особенно часто это касается тиражируемых или “коробочных”
систем. Это создает дополнительные трудности для специалистов, обеспечивающих сопровождение. В
то же время, инженеры, занимающиеся технической поддержкой (несколько боле узкий круг в команде
сопровождения, включающей менеджеров, администраторов и других специалистов), должны (в
зависимости от типа продукта) иметь доступ к активам проекта (например, описанию его внутренней
архитектуры), включая код, документацию и т.п. Именно таким образом начинает формироваться
информационная инфраструктура службы технической поддержки и сопровождения у производителей
программных продуктов.
Практика показывает, что инженеры по технической поддержке производителя программного
обеспечения (не только “коробочного”, но и создаваемого и настраиваемого интеграторами,
обладающими собственными программными решениями) должны не просто иметь доступ ко всем
ключевым активам проекта (код, документация, спецификации требований, внутренние модели и т.п.), но
в их обязанности входит создание “патчей” (patch – “заплата”), исправлений ошибок и, в особых случаях,
такие изменения, до выпуска новой версии продукта, создаются с привлечением непосредственно
разработчиков продукта (групп и подразделений R&D – Research and Development). При этом,
разработчики продукта информируются о найденных ошибках и, в случае нахождения соответствующих
решений специалистами технической поддержки, такие решения передаются разработчикам с тем,
чтобы те либо включили такие изменения в новую версию программного продукта (безусловно, в случае
успешного прохождения всех необходимых тестов), либо нашли более адекватное решение в контексте
новой функциональности либо тех изменений, которые включены в новую версию продукта. В
обязанности инженеров службы сопровождения, в общем случае, входит: проверка пользовательского
сценария, приводящего к сбою; идентификация причин сбоя, т.е локализация ошибки/причин ее
появления; предоставление соответствующих исправлений или, при невозможности создания таковых
на данном этапе либо в заданные сроки – предоставление обходного пути решения проблемы для
достижения требуемых бизнес-задач (такие обходные пути, обычно, называют “workaround”);
журналирование всех работ и операций; помещение описания проблемы и ее решения в базу знаний
службы сопровождения; передача всей информации разработчикам; своевременное информирование
пользователя о статусе запроса и некоторые другие работы, содержание которых может варьироваться,
в зависимости от регламентов и корпоративных стандартов в конкретной организации, либо параметров
контракта на сопровождение и техническую поддержку, если таковой есть.
2.5.1.3 Потребность в сопровождении
Сопровождение необходимо для обеспечения того, чтобы программный продукт на протяжении всего
периода эксплуатации удовлетворяет требованиям пользователей. Деятельность по сопровождению
применима для программного обеспечения, созданного с использованием любой модели жизненного
цикла (например, спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK
может показаться тривиальным. Однако, обратитесь к своему опыту разработки и использования
различного программного обеспечения. Наверняка, Вы найдете случаи из собственной практики или
практики коллег, когда столь очевидное утверждение хорошо бы донести до разработчика того или иного
программного продукта. Изменения программной системы могут быть обусловлены как действиями по
корректировке ее поведения или несвязанные с необходимостью корректировки (подразумевая уже не
исправление ошибок, а, например, повышение производительности или расширение
функциональности).
В общем случае, работы по сопровождению должны проводиться для решения следующих задач:







устранение сбоев
улучшение дизайна
реализация расширений <функциональных возможностей>
создание интерфейсов взаимодействия с другими (внешними) системами
адаптация (например, портирование) для возможности работы на другой аппаратной платформе
(или обновленной платформе), применения новых системных возможностей, функционирования
в среде обновленной телекоммуникационной инфраструктуры и т.п.
миграции унаследованного (legacy) программного обеспечения
вывода программного обеспечения из эксплуатации
Деятельность персонала сопровождения включает четыре ключевых аспекта:




поддержка контроля (управляемости) программного обеспечения в течение всего цикла
эксплуатации
поддержка модификаций программных систем
совершенствование существующих функций (судя по всему, SWEBOK в данном случае
подразумевает функции не программного обеспечения, а процессов сопровождения и функции
персонала сопровождения, как таковые)
предотвращение падения производительности программной системы до неприемлемого уровня
Говоря о предотвращении деградации производительности, мы должны понимать, что это, при всем
желании совершенствования системы, может делаться и за счет обновления мощности аппаратной
части и/или соответствующей телекоммуникационной инфраструктуры, если это более обосновано, чем
модификация самой программной системы. На самом деле это вопрос того, что окажется дешевле (и
менее рискованно), т.е. связано с затратами/ стоимостью соответствующих работ, оборудования и
поддержки обновленного системного окружения (что, к сожалению, часто также не учитывается даже при
более-менее сложившейся практике сопровождения).
2.5.1.4 Приоритет стоимости сопровождения
Работы по сопровождению потребляют если не большую (как отмечает SWEBOK), то значительную
часть финансовых ресурсов жизненного цикла программного обеспечения. Общее понимание
сопровождения подразумевает лишь устранение сбоев. Однако, исследования и опросы на протяжении
многих лет показывают, что более 80% усилий по сопровождению связаны не столько устранением
сбоев, сколько с другими работами, не связанными с исправлением дефектов. Многие менеджеры по
сопровождению объединяют в отчетности вопросы расширения функциональности и исправления
ошибок в поддерживаемых программных системах. Такое смешение качественно различных работ
приводит к неправильному представлению о реальной, на самом деле, не столь высокой стоимости
сопровождения в части устранения дефектов. Понимание различных категорий работ в рамках
деятельности по сопровождению помогает понять структуру реальных затрат. Кроме того, понимание
факторов, влияющих на возможности сопровождения системы, помогают не только сохранять
необходимый уровень затрат, но и снижать их.
Существуют как технические, так и другие (например, организационные, являющиеся, по мнению
автора, наиболее сильно влияющими на объем затрат) факторы, оказывающие влияние на стоимость
сопровождения, в целом:






тип приложения
новизна программного обеспечения
наличие и квалификация персонала по сопровождению
длительность использования программной системы
характеристики и специфика аппаратной части (а также телекоммуникационной инфраструктуры)
качество дизайна (например, модульность или масштабируемость), кода, документации и
соответствующих работ по тестированию системы
2.5.1.5 Эволюция программного обеспечения
В 1969 году Леман (см. рекомендуемую литературу к данной секции SWEBOK) впервые связал
деятельность по сопровождению и вопросы эволюции программного обеспечения. Результаты более
чем 20-ти летних исследований во главе с Леманом привели к формулированию ряда важных
положений, ключевое из которых утверждает, что деятельность по сопровождению, по-сути,
представляет собой эволюционную разработку программных систем. Принятию тех или иных решений в
процессе сопровождения, помогает понимание того, что происходит с программной системой в процессе
ее эксплуатации. Существующее (особенно, корпоративное) программное обеспечение никогда не
бывает полностью завершенным и продолжает эволюционировать в течение всего срока эксплуатации.
В процессе эволюционирования, программная система становится все более сложной до тех пор, пока
не предпринимаются специальные усилия (в том числе, в рамках специального проекта по
модификации) по уменьшению его сложности.
В то же самое время, если можно выделить тенденции развития программной системы и ее поведение
достаточно стабильно, его эволюционирование можно измерить. Последние годы делаются попытки
разработать соответствующие модели оценки усилий по сопровождению. В результате уже создаются
определенные средства (численные и инструментальные) управления работами по сопровождению, ряд
из которых приводится в ссылках к данной секции SWEBOK.
2.5.1.6 Категории сопровождения
Многие источники, в частности, стандарт IEEE 1216, определяют три категории работ по сопровождению:
корректировка, адаптация и совершенствование. Такая классификация была обновлена в стандарте
ISO/IEC 14764 Standard for Software Engineering - Software Maintenance введением четвертой
составляющей. Таким образом, сегодня говорят о четырех категориях сопровождения:



Корректирующее сопровождение (corrective maintenance): “реактивная” модификация
программного продукта, выполняемая уже после передачи в эксплуатацию для устранения
сбоев;
Адаптирующее сопровождение (adaptive maintenance): модификация программного продукта на
этапе эксплуатации для обеспечения продолжения его использования с заданной
эффективностью (с точки зрения удовлетворения потребностей пользователей) в изменившемся
или находящемся в процессе изменения окружении; в первую очередь, подразумевается
изменение бизнес-окружения, порождающее новые требования к системе;
Совершенствующее сопровождение (perfective maintenance): модификация программного
продукта на этапе эксплуатации для повышения характеристик производительности и удобства
сопровождения;

Профилактическое сопровождение (preventive maintenance): модификация программного
продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до
того, когда они приведут к реальным сбоям.
ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) классифицирует адаптивное и
совершенствующее сопровождение как работы по расширению <функциональности> продукта. Этот
стандарт также объединяет корректирующую и профилактическую деятельность в общую категорию
работ по корректировке системы. Профилактическое сопровождение (новейшая категория работ по
сопровождению) наиболее часто проводится для программных систем, связанных с вопросами
безопасности <людей>.
Таблица 1. Категории сопровождения программного обеспечения.
2.5.2 Ключевые вопросы сопровождения программного обеспечения
Для обеспечения эффективного сопровождения программных систем необходимо решать целый
комплекс вопросов и проблем, связанных с соответствующими работами. Необходимо понимать, что
процесс сопровождения предъявляет уникальные технические и управленческие требования к
персоналу, занимающемуся сопровождениям и, в первую очередь, специалистам-инженерам. Попытка
найти дефект в продукте, содержащем 500 тысяч строк кода, написанных другими инженерами – яркий
пример сложностей, с которыми приходится сталкиваться инженерам по сопровождению. Другой
пример, уже организационный, постоянная борьба за ресурсы с разработчиками (это чаще всего
проявляется в вопросах отвлечения разработчиков от текущей работы для помощи в решении проблем
сопровождения, а также в конкуренции за приоритеты финансирование разработки новой системы или
сопровождения существующей). Одновременное планирование перспективной версии системы,
реализация следующей версии и подготовка критических патчей для текущей версии – еще один
классический пример проблем, с которыми приходится сталкиваться в процессе эксплуатации
программного обеспечения.
Данная секция представляет некоторые технические и управленческие вопросы, связанные с
сопровождением программных систем. Эти вопросы и проблемы сгруппированы в набор тем:




Технические вопросы
Управленческие вопросы
Оценка стоимости
Измерения
2.5.2.1 Технические вопросы
2.1.1 Ограниченное понимание (Limited understanding)
Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять где
необходимо внести исправления или изменения в код системы, которую он не разрабатывал.
Исследования показывают, что от 40 до 60 процентов усилий по сопровождению тратится на анализ и
понимание сопровождаемого программного обеспечения. Формирование целостного взгляда о системе
представляет большое значение для инженеров. Этот процесс более сложен в случае анализа
текстового представления системы – ее исходного кода, особенно, когда процесс эволюции системы от
сборки к сборки, от релиза к релизу, в нем никак не отмечен, не документирован и когда разработчики не
могут объяснить историю и структуру изменений, что, к сожалению, случается достаточно часто.
Для объектно-ориентированных программ качественно упрощает задачу понимания кода использование
UML-инструментария, способного на основе кода восстановить не только модель классов, но и их
взаимодействия в форме диаграмм классов (class diagram), коммуникаций или сотрудничества
(collaboration в UML1.x, переименованная в communication в UML 2.0) и, особенно, последовательностей
(sequence diagram), демонстрирующая структуру взаимных вызовов во времени. Если соответствующий
инструментарий предоставляет одновременную визуализацию кода и диаграммы и обеспечивает
взаимную синхронизацию их с точки зрения навигации (выбор метода в любой из представленных
диаграмм автоматически позиционирует соответствующим образом редактор кода и, наоборот) – такие
средства автоматизации могут качественно сократить время, необходимое для формирования
представления о системе, иногда – даже не в разы, а на порядок (конечно, при достаточном уровне
знания используемых технологий со стороны инженера по сопровождению). Если к этому добавить
документированность (и доступность соответствующих активов –спецификаций, моделей) архитектуры и
ключевых технологических решений со стороны разработчиков системы – обсуждаемый вопрос,
конечно, не становится тривиальным, однако, превращается во вполне решаемую задачу. Вообще
говоря, использование соответствующих средств автоматизации построения моделей по коду (задача
обратного инжиниринга – reverse engineering) является обоснованной практикой изучения любой
системы или фреймворка. Опыт показывает, что при достаточной квалификации инженера,
формирование общего архитектурного представления о системе (или фреймворке), понимания того,
какие технологические и структурные подходы и шаблоны использовались при ее построении, позволяет
решать возникающие вопросы корректировки кода и расширения функциональности системы, не
нарушая общие принципы ее построения, естественным образом обеспечивая ее эволюцию, без ущерба
ее целостности. При таком понимании, даже не заглядывая в код системы или фреймворка, инженер
способен с очень большой вероятностью предположить возможные причины сбоя, а, в общем случае, и
любых аспектов поведения системы. Тема обратного инжиниринга освещается SWEBOK как
самостоятельная техника сопровождения (4.3), однако, здесь показалось важным особо акцентировать
на ней внимание именно в этой части обсуждения вопросов сопровождения.
2.1.2 Тестирование (Testing)
Стоимость повторения полного набора тестов для основных модулей системы может быть
существенным как по времени, так и по стоимости. Для сопровождения системы особо значимым
является выборочное регрессионное тестирование (см. область знаний Software Testing, тему 2.2.6
Регрессионное тестирование) системы или его компонент для проверки того, что внесенные изменения
для привели к непреднамеренному изменению поведения программного обеспечения. Вопрос состоит в
том, что часто сложно найти время для необходимого тестирования. Не меньшей проблемой является и
координации в проведении тестов различными членами группы сопровождения, занимающимеся
решением различных задач. Если же система выполняет критичные <для бизнеса> функции, временный
вывод системы из эксплуатации (как говорят, перевод системы в offline) для выполнения тестов часто
оказывается просто невозможен.
Таким образом, одним из ключевых вопросов сопровождения является организация работ по
тестированию модификаций эксплуатируемых систем, вплоть до предварительного планирования и
разработки регламентов, в соответствии с которыми, например, основываясь на оценке критичности
запросов на изменения (как дефектов, так и важных расширений – будь то новая функциональность или
необходимое расширение интеграционных возможностей), затрагиваемых модулях, персоналом
сопровождения будут проводиться стандартные процедуры. К таким процедурам, наравне с
журналированием запросов и проводимых работ, могут и, скорее, должны относиться: анализ влияния
<изменений> (impact analysis – см. ниже), оценка рисков, тестирование (различными методами, в
различном объеме), выпуск предварительных версий патчей/обновлений в ограниченное использование
(если это позволяет спецификация системы), использование “клона” системы (развертывание ее на
идентичном оборудовании в идентичной конфигурации) и т.п.
2.1.3 Анализ влияния (Impact analysis)
Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат) полный
анализ возможных последствий и влияний изменений, вносимых в существующую систему. Персонал
сопровождения должен обладать необходимыми знаниями о специфике системы (в идеальном случае,
иметь полное представление о системе на уровне ее разработчиков) – ее содержании и структуре.
Инженеры используют эти знания для выполнения работ по анализу влияния, идентифицируя все
системы* и программные продукты, на которые могут повлиять изменения, вносимые в обслуживаемую
программную систему. При этом, должны быть определены риски, связанные с внесением обсуждаемых
изменений.
* Как мы видим из описания данных работ в SWEBOK, речь идет не только о компонентах системы, но и
о ее окружении, включая другие системы, функционирующие в том же операционном/системном
окружении.
Запросы на изменения** (change requests - CR), иногда упоминаемые как запросы на модификацию
(modification request - MR), часто также называемые отчетами о проблемах (problem report - PR), должны
анализироваться и трансформироваться в термины программной системы. Эти шаги выполняются после
того, как соответствующий запрос на изменение начинает обрабатываться в рамках процесса
управления изменениями или, как принято называть, конфигурационного управления, и фиксируется в
системе конфигурационного управления (см. область знаний Configuration Management).
** Обычно запросы на изменения разделяют на две категории – “пожелания” (suggestions), относящиеся
к расширению системы, и “отчеты об ошибках” (defect или bug report), направляемые пользователями в
службу сопровождения или инженерами по тестированию разработчикам.
Цели анализа влияния могут быть сформулированы следующим образом:




Определение содержания изменений для задания работ по планированию и реализации
Получение максимально возможной оценки ресурсов, необходимых для проведения
соответствующих работ
Анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается пожеланий,
запросов на расширение системы)
Обсуждение сложности вопросов, связанных с внесением соответствующих изменений
Сложность решения вопроса, поставленного соответствующим запросом на изменения, часто является
основным фактором определения того, когда и как будет решена проблема. Инженеры идентифицирую
компоненты, в которые необходимо внести изменения. Обычно рассматривается несколько вариантов
решения проблемы и вырабатывается (также, обязательно, фиксируются в соответствующей системе
обработки запросов на изменения) наиболее оптимальный путь ее решения.
При этом, оптимальность пути не всегда означает наиболее ”красивое” технологическое решение.
Иногда это может быть временное решение, может быть даже нарушающее архитектурные шаблоны
системы, однако, обоснованное с точки зрения сроков и стоимости его реализации. В то же самое время,
результаты анализа направляются разработчикам системы, обычно работающим над следующей
версией, для включения соответствующего изменения уже в рамках принятого стиля кодирования,
соглашений, архитектурных шаблонов и т.п. Безусловно, такой путь многим может показаться просто
неэтичным, с точки зрения “настоящего” инженерного подхода. Однако, если разработчики готовят
следующую версию системы, затрагивая модуль, модифицируемый службой сопровождения, с точки
зрения бизнес-решений, “некрасивый”, но быстрый путь достижения требуемого поведения системы, в
большинстве случаев, будет выглядеть более обоснованным, чем принятие на себя персоналом
сопровождения функций разработчиков системы. Иногда, если требуемое изменение не столь критично,
чтобы решение было предоставлено “вчера” (хотя пользователи, практически всегда, именно так
характеризуют свои запросы в терминах приоритета), логичным выглядит откладывание проведения
соответствующих модификаций и передача этих работ непосредственно разработчикам. Как это часто
можно услышать – “будет доступно в следующем релизе”. Ничего не напоминает? Но, экономически, это
часто бывает более чем оправдано.
Если программное обеспечение изначально разрабатывалось с учетом дальнейшей поддержки, это
может существенно облегчить анализ влияний, как одной из ключевых работ по сопровождению.
2.1.4 Возможность сопровождения (Maintainability)
Возможность сопровождения или сопровождаемость программной системы определяется, например,
глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление
2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения
заданных требований. Стандарт ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality
Model, 2001 г.) определяет возможность сопровождения как одну из характеристик качества.
Для уменьшения стоимости дальнейшего сопровождения, на протяжении всего процесса разработки
необходимо специфицировать, оценивать и контролировать характеристики, влияющие на возможность
сопровождения. Если такие работы проводятся регулярно, это облегчает дальнейшее сопровождение,
повышая его сопровождаемость (в частности, как
х
2.5.2.2
аструктур
у. В то же время, существенно более часто, сопровождение передается другим организациям только для
“второстепенных” программных систем (или, как минимум, не критичных для выполнения бизнесфункций), так как владельцы таких систем не желают терять контроль над ассоциированными с этими
системами данными и/или функциональностью. Отмечается, что некоторые передают работы по
сопровождению “в аутсоурсинг” только в тех случаях, если убеждены в стратегическом контроле над
сопровождением.
Часто можно наблюдать, когда для решения вопросов сопровождения (при сохранении “стратегического
контроля”), компании, для которых информационные технологии не являются профильными, но
воспринимаются в качестве актива, формируют специализированные дочерние бизнес-структуры,
которым и передаются функции сопровождения, а также и непосредственно разработки программных
систем и, более того, поддержки и развития всей ИТ-инфраструктуры. Это делается с тем, чтобы
функционируя в качестве самостоятельной бизнес-сущности, уже бывшие внутрикорпоративные
подразделения автоматизации, могли обеспечить большую прозрачность финансовых потоков, затрат,
связанных с информационным технологиями. Но, это тема уже относится к общим вопросам управления
и, безусловно, требует самостоятельного обсуждения, в контексте, опять-таки, конкретной организации
или бизнес-структуры. Однако, нельзя было не обозначить важность обсуждаемого вопроса в данном
контексте, ведь именно деятельность по сопровождению часто подвигает организации-потребители ИТ к
принятию столь серьезных организационных и бизнес-решений.
При этом, подчеркивает SWEBOK, контроль сложно измерить. В свою очередь, перед аутсоурсером
(организацией, принимающей на себя ответственность по сопровождению) стоит серьезная проблема по
определению содержания соответствующих работ, в том числе, для описания содержания
соответствующего контракта. Отмечается, что около 50% сервисов, предоставляемых аутсоурсером,
проводятся без соответствующего детального и однозначно интерпретируемого соглашения (service
level agreement, SLA). Компании, занимающиеся аутсоурсингом, обычно затрачивают несколько месяцев
на оценку программного обеспечения прежде, чем заключают соответствующий контракт. Еще один
вопрос, требующий специального внимания, заключается в необходимости определения процесса и
процедур передачи программного обеспечения на внешнее сопровождение.
2.5.2.3 Оценка стоимости сопровождения
Как уже отмечалось, инженеры должны понимать разницу в различных категориях сопровождения. Это,
в большой степени, необходимо для оценки соответствующих затрат. С точки зрения планирования, как
составной части проектной и управленческой деятельности, оценка стоимости является важным
аспектом деятельности по сопровождению программного обеспечения.
2.3.1 Оценка стоимости (Cost Estimation)
При обсуждении анализа влияния (см. 2.1.3 Impact Analysis) говорилось о том, что такой анализ помогает
в оценке стоимости работ по сопровождению. На эти затраты оказывает влияние множество технических
и других факторов. ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance)определяет,
что “существует два наиболее популярных метода оценки стоимости сопровождения – параметрическая
модель и использование опыта”. Чаще всего, оба этих подхода комбинируются для повышения точности
оценки.
2.3.2 Параметрические модели (Parametric models)
SWEBOK приводит ряд источников, подробно рассматривающих вопросы оценки стоимости
сопровождения и, в частности, параметрические модели. Для использования таких моделей
используются данные предыдущих проектов. Наравне с историческими данными используется метод
функциональных точек (см. стандарт IEEE 14143.1-00).
2.3.3 Опыт (Experience)
Среди тех подходов, которые позволяют повысить точность оценок, полученных при использовании
параметрических моделей – применение опыта (в форме экспертного мнения, например, при
использовании техники оценки “Delphi”, название которой происходит от “делфийского оракула”),
аналогий, а также структуры декомпозиции работ. Наилучшие результаты получаются в случае
сочетания эмпирических методов с имеющимся опытом. Получаемые данные используются как
результат программы измерения аспектов сопровождения.
2.5.2.4 Измерения в сопровождении программного обеспечения
Формы и данные измерений в процессе сопровождения могут объединяться в единую программу
корпоративную программу количественных оценок, проводимых в отношении программного
обеспечения. Многие организации используют популярный и практичный подход для измерений,
базирующийся на оценке количества проблем и статуса их решений (issue-driven measurement). Идеи
этого подхода систематизированы в проекте Practical Software and Systems Measurement (PSM).
Существуют общие (для всего жизненного цикла) метрики и, соответственно, их категории, в частности,
определяемые Институтом Программной Инженерии университета Карнеги-Меллон (Software
Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, усилия, расписание и качество.
Применение этих метрик является хорошей отправной точкой для оценки работ со стороны организации,
отвечающей за сопровождение.
Более детальное обсуждение вопросов измерений в отношении продуктов и процессов представлено в
области знаний “Процесс программной инженерии (Software Engineering Process). В свою очередь,
вопросы организации программы измерений относятся к области знаний “Управление программной
инженерией” (Software Engineering Management).
2.4.1 Специализированные метрики (Specific Measures)
Существуют различные методы внутренней оценки продуктивности (benchmarking) персонала
сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая
сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы.
Стандарты IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 9126-01 (Software Engineering –
Product Quality – Part 1: Quality Model, 2001 г.) предлагают специализированные метрики,
ориентированные именно на вопросы сопровождения и соответствующие программы.
Ниже представлены типичные метрики оценки работ по сопровождению, соответствующих
распространенной классификации эксплуатационных характеристик программного обеспечения:

Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) усилий или
ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для
идентификации тех фрагментов программной системы, которые должны быть модифицированы.

Изменяемость (Changeability): оценка усилий, необходимых для проведения заданных
модификаций.

Стабильность (Stability): оценка случаев непредусмотренного поведения системы, включая
ситуации, обнаруженные в процессе тестирования.

Тестируемость (Testability): оценка усилий персонала сопровождения и пользователей по
тестированию модифицированного программного обеспечения.
2.5.3 Процесс сопровождения
Вопросы организации процесса сопровождения напрямую связаны с соответствующими стандартами и
de facto практиками реализации такого процесса. Тема “Работы по сопровождению” (Maintenance
Activities) различает вопросы сопровождения и разработки и показывает взаимосвязь c другими
аспектами деятельности программной инженерии.
Типичные и распространенные потребности в процессах программной инженерии подробно описаны и
документированы в различных источниках. Одна из наиболее детально проработанных и
распространенных (на уровне стандарта de facto) процессных моделей, изначально созданных с
ориентацией на программное обеспечение – CMMI (Capability Maturity Model Integration –
интегрированная модель зрелости), разработанная в Институте программной инженерии университета
Карнеги-Меллон (SEI CMU). CMMI, в частности, уделяет специальное внимание процессам
сопровождения. Существуют и другие, менее распространенные, но тем не менее развивающиеся
модели.
2.5.3.1 Процессы сопровождения
Процессы сопровождения описывают необходимые работы и детальные входы/выходы этих работ. Эти
процессы рассматриваются в стандартах IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 14764
(Standard for Software Engineering - Software Maintenance).
Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи программной системы
в эксплуатацию (post-delivery stage) и касается таких вопросов, как планирование деятельности по
сопровождению (см. рисунок 2).
Рисунок 2. Работы в процессе сопровождения по стандарту IEEE 1219.
Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, стандарта
жизненного цикла 12207. Работы по сопровождению, описанные в этом стандарте аналогичны работам в
IEEE 1219, за исключением того, что сгруппированы несколько иначе (см. рисунок 3).
Рисунок 3. Процесс сопровождения по стандарту ISO/IEC 14764.
Работы по сопровождению в стандарте 14764 разбиты на задачи:



Process Implementation – реализация процесса
Problem and Modification Analysis – анализ проблем и <необходимых> модификаций
Modification Implementation –проведение модификаций (реализация изменений)



Maintenance Review/Acceptance – оценка и принятие <проведенных работ> при сопровождении
Migration – миграция (на модифицированную или новую версию программного обеспечения)
Software Retirement – вывод из эксплуатации (прекращение эксплуатации программного
обеспечения)
В представленных в SWEBOK источниках можно найти описание истории эволюции соответствующих
процессных моделей упоминаемых стандартов ISO/IEC и IEEE. Кроме того, существует и общая
(обобщенная) модель процессов сопровождения. Agile-методологии, активно развивающиеся в
последние годы, предлагают “облегченные” (light или lightweight) процессы, в том числе, и для
организации деятельности по сопровождению, например, Extreme maintenance (см. соответствующие
источники, указанные в SWEBOK).
2.5.3.2 Работы по сопровождению
Как уже отмечалось, многие работы по сопровождению похожи на аспекты деятельности по разработке.
В обоих случаях необходимо проводить анализ, проектирование, кодирование, тестирование и
документирование. Специалисты по сопровождению должны отслеживать требования так же, как и
инженеры-разработчики и обновлять документацию по мере разработки и/или выпуска обновленных или
новых релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или организации,
отвечающие за сопровождение, в случае использования элементов процессов разработки в своей
деятельности, адаптировали эти процессы <целиком> в соответствии со своими потребностями. В то же
время, деятельность по сопровождению обладает и определенными уникальными чертами, что
приводит к необходимости использования специализированных процессов.
3.2.1 Уникальные работы (Unique activities)
Существует ряд процессов, работ и практик, уникальных для деятельности по сопровождению. SWEBOK
приводит следующие примеры такого рода уникальных характеристик:

Передача (Transition): контролируемая и координируемая деятельность по передаче
программного обеспечения от разработчиков группе, службе или организации, отвечающей за
дальнейшую поддержку;

Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection):
запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться по
различным обоснованным причинам – объему и/или сложности требуемых изменений, а также
необходимых для этого усилий. Cоответствующие решения могут также приниматься на основе
приоритетности, оценке обоснованности, отсутствии ресурсов (в том числе, отсутствия
возможности привлечения разработчиков к решению задач по модификации, при реальном
наличии такой потребности), утвержденной запланированности к реализации в следующем
релизе и т.п.

Средства извещения персонала сопровождения и отслеживания статуса запросов на
модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk): функция
поддержки конечных пользователей, инициирующая работы по оценке (assessment,
подразумевая в том числе оценку необходимости), анализу приоритетности и стоимости
модификаций, связанных с поступившим запросом или сообщенной проблемой.

Анализ влияния (Impact Analysis): анализ возможных последствий изменений, вносимых в
существующую систему - рассматривался выше в теме 2.1.3.

Поддержка программного обеспечения (Software Support): работы по консультированию
пользователей, проводимые в ответ на их информационные запросы (request for information),
например, касающиеся соответствующих бизнес-правил (см. область знаний “Требования к
программному обеспечению”), проверки, содержания данных и специфических (ad hoc) вопросов
пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению,
непониманию аспектов работы с системой и т.п.).

Контракты и обязательства: к ним относятся классическое соглашение об уровне
предоставляемого сервиса - Service Level Agreement (SLA), а также другие договорные аспекты,
на основании которых, группа/служба/организация по сопровождению выполняет
соответствующие работы.
На практике сложно провести грань между разделяемыми в SWEBOK функциями Help Desk и Software
Support – эти функции, обычно, совмещены с процессной точки зрения.
3.2.2 Дополнительные работы, поддерживающие процесс сопровождения (Support activities)
Столь длинный перевод названия данной темы связан с содержанием соответствующих работ,
описываемых SWEBOK, как работы персонала сопровождения, не включающие явного взаимодействия
с пользователями, но необходимые для осуществления соответствующей деятельности. К таким
работам относятся: планирование сопровождения. Конфигурационное управление (software configuration
management), проверка и аттестация (V&V – verification and validation), оценка качества программного
обеспечения (software quality assessment), различные аспекты обзора, анализа и оценки (reviews), аудит
(audit) и обучение (training) пользователей.
Также, к таким специальным (внутренним) работам относится обучение персонала сопровождения.
В силу особой значимости (с точки зрения автора - обязательности) ряда упомянутых работ, им
посвящены следующие под-темы данной секции области знаний по сопровождению программного
обеспечения.
3.2.3 Работы по планированию сопровождения (Maintenance planning activity)
Планирование является более чем необходимым для адекватного проведения работ по сопровождению
и должно касаться связанных с этим вопросов с нескольких точек зрения:




Бизнес-планирование (организационный уровень)
Планирование непосредственных работ по сопровождению (уровень передачи программного
обеспечения – см. выше 3.2.1)
Планирование релизов/версий (уровень программного обеспечения)
Планирование обработки конкретных запросов на изменение (уровень запроса)
На уровне индивидуального запроса, работы по планированию проводятся вместе с проведением
анализа влияния (см. 2.1.3). В свою очередь, планирование релизов/версий требует от персонала
сопровождения выполнения задач:





Получения и сбора информации о датах размещения индивидуальных запросов и отчетов
Достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.)
последующих релизов/версий программного обеспечения
Идентификации потенциальных конфликтов и возможных альтернатив <реализации
необходимых запросов>
Оценки рисков для <функционирования> текущего релиза и разработки плана “отката” на
немодифицированный (текущий, до внесения изменений, касающихся рассматриваемого
запроса) вариант системы, в случае возникновения проблем, связанных с модификацией
Информирования всех заинтересованных лиц
Несмотря на то, что разработка программных системы, обычно, занимает от несколько месяцев (что
более типично) до нескольких лет, сопровождение (как деятельность по поддержке использования) и
активная эксплуатация систем занимает несколько лет, а то и более * (5-10-...). Проведение оценки
ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть
оценены и заложены в бюджет еще при разработке системы. Планирование работ по сопровождению
должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями
обеспечения качества (отмечается в IEEE 1061-98 Standard for a Software Quality Metrics Methodology).
* эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он принимал непосредственное
участие в проектировании и разработке системы автоматизации добровольного медицинского
страхования (в одной из крупнейших российских страховых компаний), выведенной, в дальнейшем, из
эксплуатации на рубеже 2000 года, то есть система функционировала около 7 лет, а некоторые ее
фрагменты как самостоятельные приложения и того дольше. Многие банковские приложения, особенно,
на западе, в первых своих версиях были разработаны еще в середине 80-х, а некоторые ИТ-системы в
мире были созданы (в своем изначальном варианте) и в 70-е годы, что, в частности, привело к
усиленному вниманию к проблеме 2000 года (Y2K problem).
Вначале необходимо определить концепцию сопровождения. Такой документ, например, по стандарту
ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) должен касаться следующих
вопросов:




Содержания деятельности по сопровождению
Адаптации процесса сопровождения
Идентификации организации, которая будет заниматься сопровождением
Оценки стоимости сопровождения
После разработки концепции деятельности по сопровождению должен быть сформирован
соответствующий план сопровождения. Этот план должен подготавливаться одновременно с
разработкой программной системы. План должен определять как пользователи будут размещать свои
запросы на модификацию (изменения) или сообщать об ошибках, сбоях и проблемах. Вопросам
планирования уделяют специальное внимание уже упоминавшиеся стандарты IEEE 1219 (Standard for
Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance).
Стандарт ISO/IEC 14764 предоставляет специальные рекомендации (guidelines) по организации плана
сопровождения.
Наконец, на уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводить
общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового
менеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе,
профильное, если речь идет о потребителях ИТ) подразделение организации/компании. Необходимые
знание в области управления также затрагиваются в области знаний SWEBOK “Связанные дисциплины”.
3.2.4 Конфигурационное управление (Software configuration management)
Стандарт IEEE 1219, посвященный организации сопровождения программного обеспечения, определяет
конфигурационное управление как критически важный элемент процесса сопровождения. Процедуры
конфигурационного управления должны обеспечивать проверку, аттестацию и аудит на всех шагах,
требуемых для идентификации, авторизации, реализации и выпуска программного продукта.
Более того, недостаточно просто отслеживать запросы на изменения и сообщения о проблемах
(modification requests, problem reports). Должны быть контролируемы и сам программный продукт, и
любые изменения (не только в коде, но документации, спецификациях и т.п., то есть любых активах
продукта и проекта, прим. автора). Такой контроль устанавливается реализацией и строгим
следованием утвержденным процессам конфигурационного управления (software configuration
management, SCM). Область знаний “Конфигурационное управление” подробно описывает и обсуждает
процессы, в соответствии с которыми, размещаются, оцениваются и утверждаются запросы на
изменения. В ряде отдельных аспектов и характеристик, конфигурационное управление при
сопровождении и разработке несколько отличается, что должно контролироваться уже на операционном
уровне. Реализация SCM-процесса обеспечивается разработкой и следованием плану
конфигурационного управления и соответствующим процедурам (operating procedures). Организация,
подразделение или группа сопровождения (в лице представителей) участвует в работе часто
формируемого органа Configuration Control Board, отвечающего за рассмотрение и принятие в работу
запросов на изменения. Основной целью такого участия является, по мнению SWEBOK, определение
содержания следующих релизов/версий.
3.2.5 Качество программного обеспечения (Software quality)
Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения, качество
программного обеспечения будет повышаться. Для поддержки процесса сопровождения должны
планироваться и реализовываться соответствующие процедуры и процессы, направленные на
повышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA),
проверке и аттестации (V&V, verification and validation), обзору, анализу и оценке (review), а также аудиту,
должны отбираться в контексте взаимодействия и согласования со всеми другими процессами,
направленными на достижение желаемого уровня качества. SWEBOK, основываясь на стандарте
ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance), рекомендует адаптировать
соответствующие процессы, техники и активы, относящиеся к разработке программного обеспечения. К
ним, например, относятся документация по тестированию и результаты тестов. Дополнительные
подробности можно найти в соответствующей области знаний “Качество программного обеспечения”
(Software Quality).
2.5.4 Техники сопровождения
2.5.4.1 Понимание программных систем
Для реализации изменений программисты тратят значительную часть времени на чтение и
формирование понимания программного продукта. Средства работы с кодом являются ключевым
инструментом для решения этой задачи. Четкая, однозначная и лаконичная документация обеспечивает
адекватное понимание программных систем.
2.5.4.2 Реинжиниринг
Реинжиниринг определяется как детальная оценка (examination) и перестройка программного
обеспечения для формирования понимания, воссоздания (на уровне модели и, в ряде случаев,
требований) и дальнейшей реализации его <функций> в новой форме (например, с использованием
новых технологий и платформ, при сохранении существующей и расширением и облегчением
возможностей добавлений новой функциональности). Отмечается, что в индустрии существуют
различные позиции в отношении реинжиниринга – одни считают, что реинжиниринг является наиболее
радикальной и затратной формой изменений программных систем, другие, что такой подход может
применяться и для не столь кардинальных изменений (например, как смена платформы или
архитектуры). Реинжиниринг, обычно, провидится не столько для улучшения возможностей
сопровождения (maintainability), сколько для замены устаревшего программного обеспечения. В
принципе, реинжиниринг можно рассматривать как самостоятельный проект, включающий в себя, как
отмечает SWEBOK, формирование концепции, применение соответствующих инструментов и техник,
анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ,
связанных с такими работами.
Необходимо отметить, что реализация продукта в новом качестве (форме) при сохранении основной
функциональности оригинального продукта, является неотъемлемой и определяющей частью
реинжиниринга, в отличие от обратного инжиниринга, рассматриваемого ниже и являющегося важной
составной частью реинжиниринга.
2.5.4.3 Обратный инжиниринг
“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это
процесс анализа программного обеспечения с целью идентификации программных компонент и связей
между ними, а также формирования представления о программном обеспечении, с дальнейшей
перестройкой в новой форме (уже, в процессе реинжиниринга). Обратный инжиниринг является
пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного
обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов (call
graphs) и потоков управления (control flow graphs) на основе исходного кода системы. Один из типов
обратного инжиниринга – создание новой документации на существующую систему (redocumentation).
Другой из распространенных типов – восстановление дизайна системы (design recovery).
К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по
рефакторингу (см. работы Мартина Фаулера, впервые систематизировавшего и описавшего
рефакторинг). Рефакторинг – трансформация программного обеспечения, в процессе которой
программная система реорганизуется (не переписываясь) с целью улучшения структуры, без изменения
поведения. Сохранение “формы” (платформы, архитектурных и технологических решений)
существующей программной системы позволяет рассматривать рефакторинг как один из вариантов
обратного инжиниринга.
* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в зависимости от контекста,
означающее как полную перестройку или воссоздание чего-либо, идентичного по определенным
характеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся
и/или доступным внешним признакам, где восстановление может подразумевать опять-таки создание
нового образца или представления об оригинальной сущности.
В принципе, возможно объединение тем данной секции, включая реинжиниринг и обратный инжиниринг,
в общую тему 4.1 “Reverse and Re-engineering” данной области знаний “Сопровождение”, с дальнейшей
детализаций в виде “под-тем” 4.1.x. Такой подход соответствует структуре SWEBOK. При этом,
соответствующая структура может быть организована, например, следующим образом:

4.1.1 Формирование представления об эксплуатируемой/сопровождаемой системе: включает
восстановление, в первую очередь, бизнес- и функциональных требований к системе;

4.1.2 Восстановление детального дизайна системы: включает идентификацию всех
компонентов системы и создание модели вызовов и других связей между компонентами;

4.1.3 Рефакторинг: как возможный процесс структурных изменений, вносимых в систему, в
частности для улучшения возможностей по ее дальнейшему сопровождению (включая
модификацию, связанную с расширением функциональности);

4.1.4 Переработка системы: создание нового релиза/версии системы в той же форме
(например, с использованием той же технологической платформы), что и текущая
(эксплуатируемая) версия;

4.1.5 Создание новой системы: рассматривает текущую версию и систему в целом, как
устаревшую – legacy.
2.6 Конфигурационное управление
Работы по конфигурационному управлению программного обеспечения
включают: управление и планирование процессов управления конфигурацией ПО
(SCM), идентификацию программных конфигураций, контроль конфигураций,
учет статусов конфигураций, аудит, а также управление выпуском (release
management) и поставкой (delivery).
Управление конфигурацией
связано с
всеми областями
знаний
в
программной инженерии, так как объектами её приложения являются все
компоненты продукта, создаваемые и используемые в процессах программной
инженерии.
2.6.1 Управление конфигурационным процессом
Управление
конфигурацией
ПО
(SCM-деятельность)
контролирует
эволюцию и целостность продукта, идентифицируя его элементы, управляя и
контролируя изменения, а также, проверяя, записывая и обеспечивая отчетность
по конфигурационной информации. С инженерной точки зрения,
SCM
способствует разработке и реализации изменений. Успешное внедрение SCM
требует точного планирования и управления, что предполагает понимание
организационного
контекста
и
тех
ограничений,
которые
связаны
с
проектированием и реализацией процесса конфигурационного управления.
2.6.1.1 Организационный контекст управления конфигурацией ПО
Для планирования SCM-процесса важно понимать организационный
контекст и связи между организационными элементами. Организационные
элементы, отвечающие за процессы поддержки программной инженерии, могут
быть
структурированы
ответственность
за
несколькими
выполнение
способами.
определенных
Несмотря
SCM-задач
на
то,
может
что
быть
распределена между различными лицами или подразделениями организации,
общая ответственность за конфигурационное управление часто возлагается на
отдельный (специализированный) организационный элемент или назначенную
персону.
Программное обеспечение в предметной области прикладной информатики
обычно разрабатывается как составная часть большей системы, содержащей
аппаратные и программно-аппаратные/встраиваемые элементы. В этом случае,
деятельность по управлению конфигурацией ПО ведется параллельно с работами
по конфигурационному управлению (CM) в отношении аппаратной или
программно-аппаратной части, строго согласуясь с общим конфигурационным
управлением на уровне системы, в целом. Иными словами, SCM осуществляется в
сочетании с контекстом, в рамках которого проводится такая деятельность.
SCM может играть роль интерфейса к работам, направленным на
обеспечение качества. Некоторые элементы, находящиеся под управлением SCM,
могут также служить объектами рассмотрения в рамках организационных
программ по обеспечению качества. Управление несогласующемися элементами
обычно относится к работам по управлению качеством, но и SCM может
обеспечить существенную помощь в отслеживании и создании отчетности по
элементам программных конфигураций, попадающих в такую категорию.
В зависимости от контекста, существует множество подходов и практик в
части выполнения задач конфигурационного управления в приложении к
программному обеспечению. Часто, одни и те же инструменты поддерживают и
разработку, и сопровождение, обеспечивая достижение целей и содержания SCM.
2.6.1.2 Ограничения и правила управления конфигурацией ПО
Ограничения и правила в отношении процесса конфигурационного управления порождаются
различными источниками. Политики и процедуры, формулируемые на корпоративном или другом
организационном уровне, могут влиять или предписывать структуру и реализацию SCM-процесса для
заданного проекта. Кроме того, контракт между заказчиком и поставщиком может содержать положения,
затрагивающие процесс конфигурационного управления. Например, может требоваться проведение
определенных процедур проверки (аудита) или специфицирован набор элементов (активов,
артефактов), передаваемых под управление <процедур и системы> конфигурационного управления (или
в части формализации обработки и контроля реализации запросов на изменения, поступающих от
заинтересованных лиц). Когда разрабатываемый программный продукт потенциально затрагивает
аспекты публичной безопасности, могут налагаться определенные ограничения со стороны
соответствующих регулирующих органов (например, USNRC Regulatory Guide 1.169, “Configuration
Management Plans for Digital Computer Software Used in Safety Systems of Nuclear Power Plants”, U.S.
Nuclear Regulatory Commission, 1997). Наконец, на структуру и реализацию SCM-процесса в проекта
влияют выбранные (с точки зрения модели и адаптированных характеристик) процессы жизненного
цикла и инструменты, применяемые для реализации программной системы.
Рекомендации по структуре и реализации SCM-процесса могут быть также результатом применения
лучших практик (best practices), представленных в стандартах, выпущенных соответствующими
стандартизирующими организациями. Лучшие практики также отражены в моделях совершенствования и
оценки процессов, например, в CMMI – Capability Maturity Model Integration Института программной
инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон (Carnegie-Mello University)
и ISO/IEC 15504 (SPICE) “Software Engineering – Process Assessment”.
2.6.1.3 Планирование при управлении конфигурацией ПО
Планирование процесса конфигурационного управления для заданного проекта должно
согласовываться с организационным контекстом, соответствующими ограничениями, общепринятыми
рекомендациями, а также характеристиками и природой самого проекта (например, его размером или
значимостью). Основные работы, проводимые при планировании SCM-деятельности включают:





Идентификацию программных конфигураций (Software Configuration Identification)
Контроль конфигураций (Software Configuration Control)
Учет статусов конфигураций (Software Configuration Status Accounting)
Аудит конфигураций (Software Configuration Auditing)
Управление выпуском и поставкой (Software Release Management and Delivery)
Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как
организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация,
контроль поставщиков и субподрядчиков, а также, контроль интерфейсов <взаимодействия программных
модулей>. Результаты планирования сводятся в план конфигурационного управления (SCM Plan SCMP), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению
качества (SQA – Software Quality Assurance).
1.3.1 Организация и обязанности (SCM organization and responsibilities)
Для предотвращения путаницы в том, кто будет выполнять заданные работы и задачи
конфигурационного управления, должны быть четко идентифицированы организации (организационные
структуры), вовлеченные в SCM-процесс. Конкретные обязанности по выполнению заданных работ и
задач SCM должны быть назначены соответствующим организационным сущностям. Также, должны
быть идентифицированы общие полномочия и пути отчетности, даже если это выполняется в процессе
планирования управления проектом или деятельности по обеспечению качества.
1.3.2 Ресурсы и расписание (SCM resources and schedules)
В процессе планирования конфигурационного управления идентифицируется персонал и инструменты,
привлекаемые для выполнения соответствующих работ и задач SCM. Планирование касается вопросов
определения расписания, устанавливая последовательность задач конфигурационного управления и
идентифицируя их связь с расписанием проекта и его вехами, определенными на стадии планирования
проекта. Также должны быть специфицированы требования по обучению персонала, необходимые для
реализации планов.
1.3.3 Выбор инструментов и реализация (Tool selection and implementation)
SCM-деятельность поддерживается различными типами инструментальных средства и процедур по их
использованию. В зависимости от ситуации, эти инструменты могут включать комбинацию различных
возможностей – автоматизированные средства могут решать отдельные задачи SCM, интегрированные
средства могут обслуживать потребности многих участников процесса программной инженерии
(например, SCM, разработку, проверку и аттестацию и т.п.). Значимость инструментальной поддержки
конфигурационного управления (как и других аспектов деятельности в области программной инженерии)
растет с каждым днем вместе со сложностью внедрения, ростом размера проектов и сложности
проектного окружения. Возможности инструментальных средств развиваются для обеспечения
поддержки:








SCM-библиотек (проектно-ориентированных баз знаний, прим. автора)
Запросов на изменения (software change request - SCR) и процедур утверждения (approval)
Управления кодом (и связанных рабочих продуктов) и изменениями
Отчетности по статусу конфигураций и сбору соответствующих метрических показателей
Аудиту конфигураций
Управлению и отслеживанию <состояния и полноты> программной документации
Выполнению задач по сборке программных продуктов и их модулей
Управлению, контролю и поставке выпусков (релизов) программных продуктов
Инструменты, используемые для обеспечения конфигурационного управления, могут также
предоставлять метрики, необходимые для совершенствования процессов. SWEBOK обращает внимание
(рекомендуя соответствующий первоисточник) на следующие ключевые индикаторы: работы и прогресс
<по их выполнению> (Work and Progress) и индикаторы качества – поток изменений (Change Traffic),
стабильность <конфигураций> (Stability), раздробленность (Breakage), модульность (Modularity),
переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF – Mean Time
Between Failures), зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может
быть организована различным образом, например, по элементам конфигураций или по типу запросов на
изменения.
Рисунок 3 демонстрирует отображение инструментальных возможностей и процедур на работы по
конфигурационному управлению.
Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]
В этом примере система управления кодом поддерживает программные библиотеки контролируя доступ
к элементам библиотек, координирует действия множества пользователей и помогает в проведении
рабочих процедур. Другие инструменты поддерживают процесс сборки и выпуска программного
обеспечения и документации на основе программных элементов, содержащихся в библиотеках.
Инструменты для управления запросами на изменения программного обеспечения используются для
контролируемых <системой конфигурационного управления> программных элементов. Другие
инструменты могут обеспечивать управление базой данных и необходимыми менеджменту отчетными
средствами, а также деятельностью по разработке и обеспечению качества. Как уже упоминалось выше,
в рамках SCM-системы может быть объединен целый ряд инструментов различных типов. При этом
сама система конфигурационного управления может быть тесно связана и поддерживать другие виды
работ, касающиеся не только SCM.
В процессе планирования инженеры выбирают те SCM-средства, которые применимы для решения
стоящих перед ними задач.
Вопрос выбора SCM-системы должен решаться исходя из целей, сформулированных в отношении
используемых процессов программной инженерии и уровня зрелости этих процессов. Кроме того,
необходимо учитывать и вопросы унификации программных средств, используемых для поддержки
инфраструктуры разработки и сопровождения всего портфеля программных проектов, выполняемых в
организации. В силу фундаментальной значимости SCM-системы для обеспечения базовых процессов
программной инженерии и управления всеми проектными активами, принимать решение об
использовании той или иной SCM-системы для каждого отдельно взятого проекта выглядит
необоснованным. SCM-система, система управления требованиями (более чем желательно, связанная с
SCM), средства бизнес-моделирования и проектирования, среды разработки – все это должно быть
стандартизировано в рамках организации, за исключением тех случаев, когда требования в отношении
тех или иных инструментальных средств сформулированы со стороны заказчика и являются составной
частью требований, предъявляемых к проекту. Возвращаясь к вопросу выбора SCM-системы,
безусловно, необходимо учитывать мнение инженеров, однако, сложившиеся привычки не должны
“перевешивать” функциональность предлагаемых к унификации SCM-средств, обеспечиваемую ими
доступность и прозрачность информации о состоянии проекта в любой момент времени и, конечно,
возможность эффективного администрирования активов проекта, в том числе, в контексте необходимых
для этого трудозатрат.
В процесс планирования рассматриваются аспекты, которые могут “всплыть” в процессе внедрения (и,
даже, на этапе эксплуатации) выбираемой системы конфигурационного управления. В частности,
обсуждаются и вопросы возможных “культурных” изменений, если это необходимо (с точки зрения
поставленных целей – проекта и/или совершенствования процессов). Дополнительная информация,
затрагивающая SCM-инструментарий, представлена в области знаний SWEBOK “Software Engineering
Tools and Methods”.
1.3.4 Контроль поставщиков/подрядчиков (Vendor/Subcontractor Control)
Программные проекты могут требовать необходимости приобретать или использовать уже
приобретенное программное обеспечение – компиляторы и другие инструменты (среды разработки,
библиотеки компонент). Планирование должно касаться вопросов – надо и, если надо, то как помещать
эти инструменты (например, интегрируя в программные библиотеки проекта) под управление SCMсистемы и как их изменения и обновления будут оцениваться и управляться.
Аналогичные соображения существуют и в отношении программного обеспечения, создаваемого
подрядчиками. В этом случае, в отношении SCM-процесса подрядчика предъявляются специальные
требования со стороны заказчика и они вносятся в контракт, предполагая не только возможность
мониторинга, но и соответствие его возможностей заданным требованиям. В последнее время все чаще
отмечается важность доступности SCM-информации для эффективного мониторинга соответствия
(compliance monitoring).
1.3.5 Контроль интерфейсов (Interface Control)
Когда программные элементы должны связываться с другими программными или аппаратными
элементами, изменения в одних элементах могут влиять на другие элементы. Планирование SCMпроцесса рассматривает, в частности, как будут идентифицироваться связанные элементы и как будут
управляться и сообщаться их изменения. Конфигурационное управление может быть частью более
масштабного процесса системного уровня (т.е. в рамках всей системы, к которой относятся
соответствующие программные элементы) по определению и контролю интерфейсов, включая описание
в соответствующих спецификациях интерфейсов, планах контроля интерфейсов и других документах. В
этом случае, SCM-планирование контроля интерфейсов проводится в контексте процесса системного
уровня.
2.6.1.4 План конфигурационного управления
Результаты SCM-планирования для заданного проекта определяются в плане конфигурационного
управления (Software Configuration Management Plan, SCMP), который является документом,
используемом в качестве описание SCM-процесса. Он всегда поддерживается в актуальном состоянии
(обновляясь и утверждаясь по мере внесения в него необходимых изменений) на протяжении всего
жизненного цикла. При описании SCM-плана обычно необходимо разработать ряд детальных процедур,
определяющих как конкретные требования будут выполняться в повседневной деятельности.
Создание и сопровождение плана конфигурационного управления основывается на информации,
получаемой в процессе работ по планированию. Рекомендации по созданию и сопровождению SCMP
можно найти, например, в одном из ключевых SCM-стандартов IEEE 828-98 “Standard for Software
Configuration Management Plans”. Этот стандарт описывает требования к информации, содержащейся в
плане конфигурационного управления, а также определяет шесть категорий SCM-информации,
содержащейся в плане (обычно, представленных в виде соответствующих разделов, прим. автора):






Введение (Introduction) – описывает цели, содержание и используемые термины.
Управление (SCM Management) – описывает структуру, обязанности, полномочия, политики,
директивы (указания, обязательные для исполнения) и процедуры.
Работы (SCM Activities) – определяет идентификацию конфигураций, их контроль и т.п.
Расписание (SCM Schedule) – определяет связь работ по конфигурационному управлению с
другими аспектами и процессами проектной деятельности.
Ресурсы (SCM Resources) – описывает инструменты, физические ресурсы, персонал и т.п.
Сопровождение плана (SCMP Maintenance) – определяет правила, по которым в план вносятся
изменения и описывает как эти изменения внедряются в повседневный SCM-процесс.
2.6.1.5 Контроль выполнения процесса управления конфигурацией ПО
После того, как внедрен процесс конфигурационного управления, может быть необходимо
контролировать (проводить надзор) над SCM-процессом для обеспечения того, что SCM-план
исполняется надлежащим образом. В ряде случаев определяются конкретные требования по
обеспечению качества (SQA), контролирующие исполнение процессов и процедур конфигурационного
управления. Для этого может быть необходимо введение соответствующих полномочий и назначение
обязанностей по контролю выполнения задач SCM. Аналогичные полномочия и обязанности по надзору
над SCM-процессом могут существовать в контексте SQA-деятельности.
Использование интегрированных SCM-инструментов с возможностью контроля процесса может сделать
процедуру надзора более легкой и прозрачной. Некоторые инструменты предоставляют высокий
уровень настраиваемости для обеспечения гибкой адаптации процессов. Другие инструменты являются
менее гибкими, диктуя те или иные процессы и их характеристики. Требования контроля (надзора), с
одной стороны, и уровень гибкости и адпатируемости, с другой, являются определяющими критериями
выбора того или иного инструмента.
1.5.1 Метрики и процесс количественной оценки в SCM (SCM measures and measurement)
Количественные показатели (метрики) могут определяться для обеспечения информации о
разрабатываемом продукте или для оценки исполнения самого процесса конфигурационного
управления. Связанной целью SCM-мониторинга может быть и раскрытие возможностей по
совершенствованию процесса (не только SCM-процесса, но и других процессов программной
инженерии). Количественная оценка SCM-процессов предоставляет хорошие средства для мониторинга
эффективности деятельности по конфигурационному управлению на постоянной основе. Эти измерения
полезны для оценки текущего состояния процесса и проведения сравнений во времени (как прогресса в
отношении развития продукта, так и качества выполнения процесса, как такового). Анализ измерений
позволяет понять причины изменения процесса и внести соответствующие коррективы в план
конфигурационного управления (SCMP).
Программные библиотеки и различные возможности SCM-средств предоставляют источники для
получения информации о характеристиках SCM-процесса (наравне с проектной информацией и
данными, необходимыми для принятия тех или иных управленческих решений). Например, информация
о времени, необходимом для выполнения различных типов изменений, может быть полезна для оценки
критериев того, какой уровень полномочий оптимален для утверждения определенных типов изменений.
Необходимо сохранять фокус на проведении анализа измерений и формировании соответствующих
выводов, вместо проведения “измерений ради измерений” (к сожалению, последнее встречается
слишком часто, чтобы не отметить этот факт). Обсуждение количественных оценок в отношении
процесса и продукта представлено в области знаний “Процесс программной инженерии”. Программа
проведения количественных оценок обсуждается в области знаний “Управление программной
инженерией”.
1.5.2 Аудит в рамках SCM (In-process* audits of SCM)
Аудит может проводится на протяжении всего процесса программной инженерии для определения
текущего статуса заданных элементов конфигураций или оценки реализации процесса
конфигурационного управления. SCM-аудит предоставляет более формальный механизм мониторинга
выбранных аспектов процесса и может координироваться с работами в области обеспечения качества
(SQA; см. секцию “5. Software Configuration Auditing”).
* “in-process” подчеркивает непрерывность/периодичность аудита и его позиционирование как
неотъемлемой составной части конфигурационного управления.
2.6.2 Идентификация программных конфигураций
Работы по идентификации конфигураций программного обеспечения определяют контролируемые
элементы (items), устанавливают схемы идентификации для элементов и их версий, а также задают
инструменты и описывают техники, используемые для управления этими элементами (включая их
передачу под управление SCM-процесса и системы). Данная деятельность является основой для всех
других работ по конфигурационному управлению.
2.6.2.1 Идентификация элементов, требующих контроля
Первый шаг в организации контроля изменений состоит в идентификации программных элементов,
которые необходимо контролировать в рамках SCM-процесса. Это предполагает понимание
программной конфигурации в контексте системной конфигурации, выбор элементов программной
конфигурации, разработку стратегии отметки (labeling) программных элементов и описание связи между
ними, а также идентификацию базовых линий (baselines, это понятие будет обсуждаться позднее в этой
теме) вместе с процедурами включения элементов в базовую линию.
2.1.1 Программная конфигурация (Software configuration)
Программная конфигурация – набор функциональных и физических характеристик программного
обеспечения, сформулированная в документации или воплощенная в продукте (см. IEEE 610.12-90,
Standard Glossary for Software Engineering Terminology). Программная конфигурация может
рассматриваться как составная часть общей системной конфигурации.
2.1.2 Элемент конфигурации (Software configuration item)
Элемент программной конфигурации (software configuration item, SCI) – фрагмент программного
обеспечения, вовлеченный в процесс конфигурационного управления (и, возможно, помещенный под
управление SCM-системы) и рассматриваемый как одна (атомарная) сущность в рамках SCM-процесса
(см. IEEE 610.12-90). SCM контролирует множество различных элементов, включая не только
программный код. Программные элементы, потенциально полезные в качестве элементов программной
конфигурации (SCI), включают планы, спецификации и документы (например, полученные в результате
моделирования и проектирования), программные инструменты, исходный и исполнимый код, библиотеки
кода, данные и словари данных, а также документацию по установке, сопровождению, эксплуатации и
использованию программного обеспечения.
Выбор SCI является важным процессом, в рамках которого необходимо достигать баланса между
обеспечением адекватного уровня прозрачности представления (дословно – “видимости”, visibility) в
контексте контроля проекта. Правильный выбор элементов конфигурации важен для обеспечения
управляемого набора контролируемых элементов. SWEBOK дает ссылку на источник, описывающий
список критериев по выбору элементов конфигураций.
2.1.3 Связи между элементами конфигурации (Software configuration item relationships)
Структурные связи между выбранными элементами конфигурации (и их составляющими) влияют на
другие SCM работы и задачи, например, сборку программного обеспечения или анализ влияний (impact
analysis) предлагаемых изменений. Надлежащее отслеживание этих связей является важным для
поддержания актуальной трассировки (traceability) между активами проекта. Разработка схемы
идентификации элементов конфигураций (SCI) должна учитывать отображение между
идентифицируемыми элементами и структурой программного обеспечения, а также потребность в
поддержке эволюционирования программных элементов и их связей по мере развития системы.
2.1.4 Версия программного обеспечения (Software version)
Программные элементы развиваются по мере выполнения проекта. Версия (version) программного
элемента – конкретно идентифицированный и специфицированный элемент. Версия элемента может
также рассматриваться в качестве определенного состояния (state) эволюционирующего элемента.
Обновление (revision) – новая версия элемента, предназначенная для замены его старой версии.
Вариант (variant) – новая версия элемента, добавляемая в конфигурацию без замены старой версии (то
есть сосуществующая с другой версией того же элемента).
2.1.5 Базовая линия, срез (Baseline)
Базовая линия или <фиксированный> срез (baseline) программного обеспечения –набор элементов
программной конфигурации, формально определенный и зафиксированный по времени в процессе
жизненного цикла программного обеспечения. Этот термин также иногда используется для указания
конкретной версии элемента конфигурации, если это согласовано заранее. В определенных случаях,
базовая линия может изменяться только через формальную процедуру контроля изменений.
Фиксированный срез в сочетании со всеми утвержденными изменениями в отношении его представляет
собой текущую утвержденную конфигурацию.
Хотя, упоминаемая в SWEBOK классификация базовых линий в определенной степени является
умозрительной и, безусловно, не единственно возможной, она полезна для адаптации и выработки
внутрикорпоративных стандартов, на основе которых, в дальнейшем строятся соответствующие планы
конфигурационного управления (SCMP). Приведенную ниже классификацию, соответственно, стоит
рассматривать лишь как пример, но пример достаточно полезный для данного контекста обсуждения.
В общем случае, используются следующие типы базовых линий – функциональные, утвержденные,
эволюционные или промежуточные, а также, базовые линии продукта. Функциональный срез
соответствует принятым программным требованиям. Утвержденный срез соответствует принятым
программным требованиям и требованиям в отношении интерфейсов. Базовая линия продукта
представляет собой срез активов, относящихся к продукту, на заданный момент времени (при этом,
базовая линия продукта не всегда является его версией, готовой к выпуску, т.е. к передаче в
эксплуатацию). Полномочия по изменению заданной базовой линии обычно находятся в ведении
организационной структуры, отвечающей за разработку программного обеспечения, но могут также
разделяться и с другими организационными структурами (например, отвечающей за конфигурационное
управление или тестирование). Базовая линия продукта соответствует завершенному программному
продукту, готовому для проведения работ по интеграции в рамках целевой системы (system integration).
Базовые линии, используемые для данного проекта, вместе с ассоциированным уровнем полномочий,
необходимым для утверждения изменений, обычно идентифицируется в конфигурационном плане –
SCMP.
Здесь уместно провести параллель между вехами (milestone) проекта и базовыми линиями. Выглядит
вполне обоснованным отображение вех проекта на базовые линии, как “выходы” (результаты)
выполнения процессов проекта к моменту достижения соответствующей проектной вехи.
2.1.6 Включение элементов в программную конфигурацию (Acquiring software configuration items)
Различные элементы программной конфигурации передаются под управление SCM-процесса в
различные моменты времени и включаются в базовые линии в определенных точках жизненного цикла.
Инициирующим событием является завершение определенных форм формального утверждения задач,
таких как формальная оценка (review). Рисунок 4 характеризует развитие базовой линии в процессе
жизненного цикла. Этот рисунок базируется на каскадной (waterfall) модели только в целях иллюстрации;
нижние индексы используются для обозначения версий эволюционирующих элементов. Запросы на
изменения (software change requests, SCR), присутствующие на рисунке, описываются в теме 3.1
“Requesting, Evaluating, and Approving Software Changes”.
Рисунок 4. Включение элементов в конфигурацию. [SWEBOK, 2004, с.7-7, рис. 4]
После включения элемента в конфигурацию в качестве SCI, изменения элементов должны утверждаться
формально, как связанные с соответствующими элементами (SCI) и базовыми линиями, следуя плану
конфигурационного управления (SCMP). После утверждения <запроса на изменение и проведения работ
по изменению>, <измененный> элемент включается в конфигурацию, в соответствии с заданной
процедурой утверждения.
2.6.2.2 Программная библиотека
Программная библиотека – контролируемая коллекция программных приложений и связанной с ними
документации, предназначенная для использования в процессе разработки, эксплуатации и
сопровождения программного обеспечения (см. IEEE 610.12-90). В качестве <элемента> программной
библиотеки, также, может рассматриваться инструментарий, используемый в работах по выпуску
программного обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике могут
использоваться различные типы библиотек, каждая из которых соответствует определенному уровню
зрелости элементов программного обеспечения. Например, “рабочая библиотека” (working library) может
поддерживать работы по кодированию, “библиотека поддержки проекта” (project support library) может
поддерживать тестирование, “мастер-библиотека” (master library) может использоваться для
завершенных продуктов (например, как вся совокупность средств, используемых для разработки и/или
выпуска продукта). С каждой библиотекой ассоциирован соответствующий уровень контроля
конфигурационного управления, также ассоциированный с базовой линией и уровнем полномочий по
внесению изменений. Безопасность (в терминах контроля доступа и средств резервного копирования)
является одним из ключевых аспектов управления библиотеками. SWEBOK отмечает, что существуют
различные модели программных библиотек, а также приводит соответствующие первоисточники по этой
теме.
Используемые для каждой библиотеки инструменты должны поддерживать контроль SCM, необходимый
для данной библиотеки, как в терминах управления элементами конфигурации (SCI), так и с точки
зрения контроля доступа к библиотеке. На уровне рабочей библиотеки – это средства управления
кодом, обслуживающие разработчиков, специалистов по сопровождению и SCMпроцесс/инструментарий (например, среда разработки должна обеспечивать интеграцию с SCMсистемой). В данном контексте, рабочая библиотека фокусируется на управлении версиями
программных элементов (к которым, безусловно, относится не только код, но и запросы на изменения,
включая сообщения об обнаруженных дефектах, и т.п.) в многопользовательской среде. На более
высоком уровне контроля, доступ ограничен сильнее и SCM (процесс и/или система) является основным
пользователем <библиотеки> (например, для осуществления автоматической сборки продукта по
расписанию).
Все эти библиотеки также являются важным источником информации для количественной оценки работ,
их результата и прогресса <в развитии программных элементов>.
2.6.3 Контроль программных конфигураций
Контроль программных конфигураций касается вопросов управления изменениями в течение жизненного
цикла программного обеспечения. Он включает процесс определения того, какие именно изменения
должны быть сделаны, какие полномочия необходимы для утверждения определенных <типов>
изменений, в чем состоит поддержка реализации этих изменений, а также концепцию формального
утверждения отклонений от проектных требований, также как и отказа от внесения изменений.
Получаемая в результате этого информация полезна для количественной оценки потока изменений,
нарушения целостности <системы> и аспектов “переработки” в проекте (в большинстве случаев, по
времени, стоимости и усилиям - трудозатратам).
2.6.3.1 Предложение, оценка и утверждение изменений
Первый шаг по управлению изменениями контролируемых элементов состоит в определении того, какие
именно изменения надо производить. Процесс обработки запросов на изменения (software change
request process), представленный на рисунке 5, включает формальные процедуры по предложению
(submitting) и записи (recording) запросов на изменения, оценки потенциальной стоимости и влияния
предлагаемых изменений, а также принятию, модификации или отказу от внесенных предложений по
изменениям. Запросы на изменения элементов программных конфигураций могут вноситься любым
лицом в любой точке жизненного цикла и может включать предлагаемые решения и соответствующий
уровень приоритетности. Один из источников запросов на изменения состоит в инициировании
корректирующих действий в ответ на сообщения о проблемах (problem reports). Вне зависимости от
источника запроса, в самом запросе на изменение (software change request, SCR) обычно записывается
информация о его типе (например, “дефект” или “заявка на расширение функциональных
возможностей”/”пожелание” – enchancement/suggestion).
Рисунок 5. Поток процесса контроля изменений. [SWEBOK, 2004, с.7-7, рис. 5]
Такой подход обеспечивает возможность отслеживания дефектов и сбора метрических показателей о
деятельности по обработке и внесению изменений, с группировкой по типу изменений. Как только
получен запрос на изменение (SCR), производится техническая оценка (включающая, а иногда и
называемая анализом влияний – impact analysis) запрашиваемых изменений для определения
масштабов модификаций, необходимых для удовлетворения параметров запрашиваемых изменений
(достаточно часто, в результате такого анализа формулируются соответствующие требования,
определяющие содержание необходимых работ). Четкое понимание связей между программными (и,
возможно, аппаратными) элементами системы является важной составной частью данной задачи.
Наконец, органы, обладающие полномочиями, соответствующими затрагиваемой базовой линии,
элементам программной конфигурации и природе изменений, должны оценить технические и
управленческие (организационные) аспекты внесения запрашиваемых изменений, а также принять,
модифицировать, отклонить или отложить предлагаемые изменения.
3.1.1 Совет по конфигурационному контролю (Software Configuration Control Board)
Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются на
<организационную> сущность, называемую совет по конфигурационному контролю - Configuration
Control Board (чаще звучит как совет по координации изменений - Change Control Board, CCB). В
небольших проектах такие полномочия могут, в действительности, принадлежать лидеру или одному
назначенному лицу из числа членов проектной команды. В общем случае может существовать несколько
уровней полномочий в части принятия решений в отношении изменений, в зависимости от различных
критериев, таких как критичность предлагаемых изменений, их приоритет, природа изменений
(например, параметры бюджета или расписания) или текущая точка жизненного цикла. Решения о том,
кто именно будет включен в CCB для данной системы (проекта) могут варьироваться, в зависимости от
данных критериев. Однако, в CCB всегда должно присутствовать лицо, вовлеченное в организацию
конфигурационного управления. В CCB входят все заинтересованные лица, чья роль соответствует
уровню CCB. Когда содержание полномочий CCB охватывает только аспекты программного
обеспечения, такой совет называется Software Configuration (Change) Control Board – SCCB.
Деятельность CCB обычно является объектом аудита качества или оценки.
Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB,
более обоснованным выглядит использование именно названия Change Coordination & Control Board – в
общем случае звучащий как совет по координации и контролю изменений.
3.1.2 Процесс обработки запросов на изменения (Software change request process)
Эффективный процесс <обработки> запросов на изменения (SCR process) требует использования
соответствующих средств поддержки и процедур <для данного вида деятельности>, от “бумажных” форм
и документированных процедур (как последовательности действий или сценариев) до программных
инструментов, позволяющих отсылать запросы на изменения, выполнять процесс обработки таких
запросов (изменять их статус, комментировать, детализировать и т.п.), фиксировать решения, принятые
CCB, а также генерировать отчетную информацию по процессу обработки запросов на изменения. Связь
между этими средствами и инструментами обработки отчетов об ошибках может существенно облегчить
определение решений для обнаруженных проблем.
Обработка различных типов запросов на изменения в отношении разрабатываемых или
модифицируемых программных систем, будь то сообщения о проблемах (defect report) или запросы на
расширение функциональности (enchancement request), даже при разных процессах принятия решений в
отношении их, должны быть объединены в единую систему (в единой базой данных), являющуюся
составной и неотъемлемой частью единой среды конфигурационного управления. Только в этом случае
можно обеспечить однозначную и актуальную связь между запросами различных типов и другими
активами проекта (кодом, документацией, проектными моделями, задачами, ресурсами и т.п.), что
позволяет не только получать актуальную информацию в любой момент времени, но и оперативно
принимать те или иные (в том числе, управленческие) решения в отношении проекта, основываясь на
максимально полном и корректном объеме информации.
SWEBOK отмечает, что описания процессов и соответствующих форм (например, формы сообщения о
проблеме) можно найти в большом количестве внешних источников, в частности, указанных
непосредственно в библиографии SWEBOK.
2.6.3.2 Реализация изменений
Принятые (утвержденные) запросы на изменения (SCR) реализуются используя определенные
процедуры, в соответствии с подходящими требованиями в отношении расписания. Если набор
утвержденных запросов на изменения может выполняться одновременно, необходимо обеспечить
отслеживание того, какие именно SCR реализованы в конкретной версии программного продукта и
базовой линии <конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии с
closure - “закрытием”, то есть завершением проекта), является аудит(ы) конфигурации(й) и верификация
качества программного обеспечения. Это обеспечивает гарантию того, что были внесены только
утвержденные изменения. Описанный выше процесс обработки запросов на изменения обычно
включает документирование всей информации, связанной с принятым изменением.
Фактическая реализация изменений поддерживается инструментальными средствами соответствующей
программной библиотеки (см. выше 2.2 “Программная библиотека”), обеспечивающими управление
версиями и поддержку <единого> репозитория кода. Как минимум, эти инструменты должны
поддерживать операции chek-in/check-out (помещение в репозиторий/ получение из репозитория) и
ассоциированные возможности по контролю версий (например, отметка версии – labeling, сравнение –
compare/diff, слияние – merge и т.п.). Более мощные инструменты могут поддерживать параллельную
разработку (parallel development) и среду географически распределенной разработки (geographically
distributed environment). Эти инструменты могут объявляться (в рамках организации) как отдельные
специализированные приложения, целиком находящиеся под контролем независимой SCM-группы (как
самостоятельной/выделенной организационной сущности). Наконец, они могут быть столь
элементарными, что включают только упрощенный контроль версий, например, на уровне файловой
системы операционной среды.
Безусловно, существует широкий спектр, обоснованных функциональных возможностей
инструментальных средств, используемых для решения различных задач конфигурационного
управления. При этом, при выборе соответствующего инструмента или комплекса инструментов,
необходимо точно понимать их функциональную нагрузку, уровень интегрируемости, возможности по
адаптации с учетом конкретных процессов жизненного цикла в проектной команде или организации, в
целом. Только с учетом этих критериев и других ограничений можно сформировать оптимальное и
эффективное решение по программному обеспечению SCM-процесса в том объеме, который обоснован
в каждом конкретном случае.
2.6.3.3 Отклонения и отказ от изменений
Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных работ
<программной инженерии>, как и спецификации, созданные в процессе разработки, могут содержать
условия, которые не могут быть удовлетворены в заданной точке жизненного цикла. Отклонение
(deviation) - утверждение изменений, внесенных относительно предварительно сформулированных
условий к разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver) –
утверждение дальнейшего использования элемента, которое отличается в той или иной степени от
предварительно заданных условий. В обоих случаях используются формальные процессы (точнее,
процедуры) для получения одобрения на отклонение или отказ от предопределенных ранее условий.
В большинстве случаев, говорят об отклонении от требований (изменении реализации требований с
одновременной их корректировкой) и отказе от выполнения запросов на изменения (или отклонении
запросов). Как вы уже обратили внимание, использование слова “отклонение” сильно зависит от
контекста, подразумевая, в первом случае, определенную корректировку условий и работ и, во втором
случае, полный отказ от внесения изменений с утверждением и обоснованием такого отказа.
2.6.4 Учет статусов конфигураций
Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA)
подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации,
необходимой для эффективного управления конфигурациями программного обеспечения.
2.6.4.1 Информация о статусе конфигураций
Деятельность по учету статуса конфигураций (SCSA) предназначена и выполняется для получения (и
генерации отчетов) информации, необходимой для осуществления процессов жизненного цикла
системы. Как и в любой информационной системе, информация о статусе конфигураций должна
идентифицироваться, собираться и поддерживаться <в актуальном состоянии> по мере эволюции этих
конфигураций. Различная информация и количественные показатели необходимы для поддержки
процесса конфигурационного управления, а также для генерации отчетности (о статусе конфигураций),
необходимой для управления, выполнения процессов программной инженерии и других связанных
видов деятельности. Типы доступной информации обычно включают идентификацию утвержденных
конфигураций, наравне с идентификацией и текущим статусом реализации изменений, отклонений и
отказов от изменений. SWEBOK дает ссылки на источники, содержащие возможные (частные) списки
важных информационных элементов.
Современные инструментальные средства SCM должны включать определенные формы поддержки
сбора и данных и подготовки SCSA-отчетности. Это может быть реализовано на уровне обращения к
соответствующим базам данных, может быть представлено и в виде самостоятельных приложений, а
также являться функциональной составляющей более крупных интегрированных инструментальных
средств.
Логично, что только такие интегрированные многофункциональные средства возможно считать
полноценными SCM-инструментами, образующими категорию систем конфигурационного управления.
В противном случае, мы говорим лишь об отдельно взятых (пусть и взаимодействующих, в той или иной
степени) инструментах - “системе управления заявками на изменения” (change request submission),
“системе сообщения и отслеживания дефектов” (defect-tracking), “системе контроля версий” (version
control), “системе генерации отчетности” (configuration reporting) и т.п.
2.6.4.2 Отчетность по статусу конфигураций
Отчетная информация может быть использована различными организационными единицами или
проектными группами, включая команду разработки, команду сопровождения, управляющих проектами и
персоналом, обеспечивающим проверку качества. Отчетность может предоставляться в специальной
форме, следуя специфическим запросам, но может генерироваться на постоянной основе (с
определенной периодичностью) в соответствии с заданными шаблонами. Определенные элементы
информации, получаемой в процессе деятельности по учету статуса конфигураций, может становиться
составной частью данных, необходимых и используемых в работах по обеспечению качества (как
продуктов, так и процессов).
В дополнение к отчетности по текущему статусу конфигураций, информация, получаемая в процессе
SCSA-деятельности, может использоваться как основа для проведения различных количественных
оценок в интересах менеджмента, разработки или конфигурационного управления. Например, к такого
рода данным относятся: количество запросов на изменения на один конфигурационный элемент;
среднее время, необходимое для реализации запрошенных изменений <заданного типа>.
2.6.5 Аудит конфигураций
Аудит программного обеспечения – деятельность, выполняемая для независимой оценки программных
продуктов и процессов на <формальное> соответствие (conformance) применимым в данном случае
инструкциям, стандартам, руководящим документам, планам и процедурам (см. IEEE 1028-97 “Standard
for Software Reviews”). Аудиты проводятся в <строгом> соответствии с четко определенными
процессами, содержащими и определяющими различные роли аудиторов и из обязанности. Каждый
аудит должен быть, в свою очередь, четко спланирован и может требовать привлечения многих
специалистов для выполнения различных задач (определяемых процедурой аудита) за достаточно
короткий промежуток времени. Автоматизированные средства, обеспечивающие поддержку
планирования и проведения аудита, могут существенно облегчить и ускорить этот процесс. SWEBOK
отмечает, что рекомендации по проведению аудита можно найти во многих источниках, в том числе,
включая стандарт IEEE 1028-97 “Standard for Software Reviews”.
Деятельность по аудиту программных конфигураций определяет степень, в которой элемент
<конфигурации> (SCI) удовлетворяет заданным (например, на уровне требований и/или запросов на
изменения) функциональным и физическим характеристикам. Неформальный аудит такого типа может
быть связан с ключевыми точками жизненного цикла (вехами проекта, в терминах управления проектами
- milestones). Существует два достаточно распространенных типа формального аудита (требуемого
определенными категориями контрактов, например, на создание критически-важного программного
обеспечения): функциональный аудит конфигураций (Functional Configuration Audit, FCA) и физический
аудит конфигураций (Physical Configuration Audit, PCA). Успешное (в терминах соответствия результатов
заданным условиям) завершение этих аудитов может быть обязательным требованиям для
фиксирования базовой линии продукта. В то же время, если сравнивать контекст FCA и PCA для
программного и аппаратного обеспечения, перед их выполнением необходимо четко оценивать
реальные потребности в таких видах аудита (так как они требуют существенных, иногда, просто
“неподъемных” затратах ресурсов, если оценивать их в рамках заданных ограничений проекта).
2.6.5.1 Функциональный аудит программных конфигураций
Цель FCA состоит в том, чтобы убедиться, что контролируемый программный элемент полностью
соответствует заданным спецификациям. “Выход”, то есть результат проверки и аттестации (V&V,
verification and validation) программного обеспечения является ключевым “входом” (исходными данными)
для проведения этого аудита.
2.6.5.2 Физический аудит программных конфигураций
Цель PCA состоит в том, чтобы убедиться, что дизайн и документация точно согласуются с самим
программным продуктом.
2.6.5.3 Внутренние аудиты базовых линий
Как уже упоминалось выше, аудиты могут выполняться на протяжении всего процесса разработки для
получения текущего статуса заданных элементов конфигураций. В данном случае, аудит может
проводиться в отношении к выборочным элементам базовых линий с тем, чтобы убедиться, что
соблюдаются заданные спецификациями характеристики процесса, скорости и качества развития
продукта, а также того, что документация соответствует и поддерживается в согласованном состоянии с
документируемыми элементами продукта в процессе их эволюционирования/на протяжении жизненного
цикла.
2.6.6 Управление выпуском и поставкой
Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая распространение <и
использование> элементов конфигураций за рамками работ по разработке программного обеспечения.
Это может включать как внутренние релизы, так и выпуск и передачу программного обеспечения
заказчикам. В ситуациях, когда доступны для поставки различные версии программных элементов (в
частности, различные версии для разных платформ или редакции с различным набором
функциональных возможностей), часто бывает необходимо создавать специализированные версии и
пакеты (сборки) соответствующих материалов (элементов, активов) для выпуска в качестве
<самостоятельной> версии. Программная библиотека (предоставляющая соответствующий
инструментарий для такой сборки) играет ключевую роль в выполнении таких работ.
2.6.6.1 Сборка программного обеспечения
Сборка (building) программного обеспечения – деятельность по комбинированию корректных версий
элементов программных конфигураций, проводимая с использованием соответствующих
конфигурационных данных, с целью получения исполняемой программы (программной системы) для
передачи заказчику и/или другим получателям (например, выполняющим работы по тестированию).
Исполняемая программа для аппаратных и программно-аппаратных систем получается в результате
деятельности по системной сборке (system building). Инструкции по сборке предоставляют описание
необходимых для сборки шагов, представленных в заданной (корректной) последовательности. Работы
по сборке программного обеспечения выполняются не только для получения нового релиза, но и для
повторного создания предыдущих релизов в целях их восстановления, тестирования, сопровождения
или каких-либо других необходимых действий.
Программное обеспечение собирается с использованием заданных версий таких средств поддержки
(supporting tools), как компиляторы. В ряде случаев может требоваться повторная сборка точной копии
ранее собранного элемента конфигурации. В этом случае, средства поддержки и ассоциированные
инструкции по сборке должны находиться под контролем SCM (подразумевая, в зависимости от
контекста, в определенных ситуациях, SCM-систему или только процесс) для обеспечения доступности
корректной версии инструментария.
Часто бывают полезны возможности инструментов, позволяющие выбирать корректные для заданного
окружения версии программных элементов, а также обеспечивать автоматизацию процесса сборки
(например, по расписанию) программного обеспечения на основы выбранных версий и соответствующих
конфигурационных данных. Такие возможности инструментов особенно необходимы для крупных
проектов с параллельной разработкой и/или распределенной средой разработки (географически
распределенной команды разработки). Большинство программных средств, обеспечивающих
инфраструктуру разработки поддерживают такую возможность (или, как минимум, декларируют ее). Эти
инструменты сильно отличаются (по степени комплексности предоставляемого функционала и) по своей
сложности, требуя в ряде случаев изучения специализированного (специфичного для конкретного
инструмента) языка сценариев, или предоставляя графические возможности, скрывающие сложность
настройки “интеллектуальных” средств сборки программного обеспечения.
Процесс и результаты сборки могут быть необходимы для последующего использования <в других
процессах, работах и проектах> и часто являются объектом верификации (проверки) в рамках
деятельности по обеспечению качества (SQA).
2.6.6.2 Управление выпуском программного обеспечения
Управление выпуском (release management) программного обеспечения охватывает идентификацию,
упаковку (сборку) и передачу элементов продукта, например, исполняемых программ, документации,
аннотацию релиза (release note) и конфигурационные данные. Понимая, что изменения в продукте
происходят постоянно, одной из задач управления выпуском продукта является определение момента
времени, когда именно выпускать продукт (в этом контексте, управление выпуском может быть тесно
связано как с деятельностью по обеспечению качества, так и с маркетинговыми соображениями в
отношении выпускаемого продукта). На это решение также влияет серьезность проблем, решению
которых адресуется релиз, и количественная оценка плотности сбоев (fault densities) в предыдущих
релизах. Задача упаковки (packaging) состоит в идентификации того, какие элементы продукта должны
быть выпущены (например, на основании функциональных требований и их трассировки на элементы
конфигурации), и в последующем выборе корректных вариантов этих элементов, задаваемом аспектами
применения продукта. Документирование информации о физическом содержании релиза, обычно,
включают в документ описания версии (version description document). В свою очередь, аннотация релиза
(release note) содержит информацию о новых возможностях, известных проблемах, а также требованиях
к платформе(ам), которые необходимо соблюдать для предусмотренного режима эксплуатации
продукта. Подготовленный к выпуску пакет (package) также включает инструкции по установке и
обновлению <предыдущей версии>. Создание такой инструкции может быть осложнено тем, что
некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем предыдущий
выпущенный релиз. Наконец, в ряде случаев, деятельность по управлению выпуском может требовать
отслеживание распространения (поставки) продукта различным заказчикам или в рамках заданных
целевых систем. Например, возможны ситуации, когда поставщику требуется уведомить заказчика об
обнаруженных проблемах.
Для поддержки таких функций управления выпуском могут требоваться соответствующие возможности
инструментария поддержки (средств поддержки или “вспомогательных средств”, если, например,
попытаться максимально приблизиться к русскоязычной терминологии ГОСТ 12207). Также полезна и
связь с инструментальными возможностями поддержки процесса обработки запросов на изменения для
отображения содержимого релиза на полученные запросы на изменения (SCR - software change request,
включая сообщения об обнаруженных ранее и исправленных в данном релизе ошибках, прим. автора).
Эти инструментальные средства <поддержки управления выпуском продуктов> также могут
поддерживать информацию о различных целевых платформах и <операционном> окружении,
используемом у заказчиков.
3 Инструменты и методы программной инженерии
3.1 Инструменты
Программные инструменты предназначены для обеспечения поддержки
процессов
жизненного
цикла
программного
обеспечения,
позволяя
автоматизировать отдельные повторяющиеся действия и уменьшить загрузку
специалистов
по
программной
Инструменты
составляют
инженерии
однообразными
средства программной
инженерии.
операциями.
По
своему
содержанию они могут варьироваться от поддержки отдельных индивидуальных
задач до охвата всего жизненного цикла (платформа разработки).
В свою очередь, методы программной инженерии формируют некоторую
процедуру действий, направленных на достижение успеха в некоторой
конкретной сфере. Методы обычно предоставляют соответствующие нотации,
словари терминов и процедуры выполнения определённого набора задач, а также
рекомендации по оценке и проверке выполняемого процесса и получаемого в его
результате продукта. Методы, как и инструменты могут иметь различный
масштаб. В данном разделе рассматриваются только методы, охватывающих
несколько
этапов
жизненного
соответствующих разделах.
цикла.
Конкретные
методы
описаны
в
Рисунок 1. Область знаний “Инструменты и методы программной инженерии” [SWEBOK, 2004, с.10-1,
рис. 1]
3.1.1 Инструменты работы с требованиями
Согласно SWEBOK [25] инструменты, применяемые для работы с
требованиями, могут быть классифицированы на средства моделирования и
средства трассировки. На практике моделирование требований, как и трассировка,
являются частью управления требований. Но в силу своей значимости при
проведении
анализа
требований
инструменты
трассировки
могут
быть
рассмотрены как самостоятельная категория. Но моделирование требований лишь
часть управления требованиями. Поэтому согласно [7] используется термин
«инструменты управления требованиями», что отличается от оригинального
текста SWEBOK. Таким образом, для работы с требованиями используются:
– инструменты управления требованиями, применяемые для извлечения,
анализа, специфицирования и проверки программных требований;
– инструменты трассировки требований, применяемые для представления
отношений между требованиями различного уровня в системе.
3.1.2 Инструменты проектирования и конструирования
К инструментам проектирования относятся инструменты, используемые для
создания и проверки программного дизайна. В качестве классификационных
признаков можно выделить такие критерии как:
– применяемые
базовые
нотации
моделирования
и
проектирования
(SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т.п.);
– целевые задачи (бизнес-моделирование, проектирование БД, объектноориентированное проектирование, интеграционное/SOA-проектирование и т.п.)
[7].
К инструментам конструирования относятся инструменты, используемые
для производства и трансляции программного представления (например,
исходного кода), достаточно детального и явного для машинного выполнения [7]:
– Редакторы, применяемые для создания и модификации исходного кода
программ и ассоциированной с ними документации. Это могут быть как
редакторы “общего назначения” (что на протяжении многих лет наблюдается в
UNIX и unix-подобных средах) или специализированные редакторы с поддержкой
специфики целевого языка программирования (что является, в большинстве
случаев, прерогативой интегрированных сред разработки – IDE). В то же время,
документирование все же является не только и не столько частью редактора,
сколько
самостоятельной
функциональностью,
пусть
часто
и
тесно
интегрированной с редактором.
– Компиляторы
и
генераторы
кода,
традиционно
выполнявшие
покомандную трансляцию исходного кода. Однако существует тенденция
интеграции
компиляторов
программирования.
К
и
этому
редакторов
классу
также
в
интегрированные
относятся
среды
препроцессоры,
линковщики/загрузчики, а также генераторы кода (за исключением, объектноориентированных средств проектирования).
– Интерпретаторы, обеспечивающие исполнение программ посредством
эмуляции. Они могут поддерживать действия по конструированию программного
обеспечения,
предоставляя
для
исполнения
программ
окружение,
более
контролируемое и поддающееся наблюдению, чем это обычно способна сделать
та или иная операционная система. Существует явная тенденция к интеграции
функций компиляторов и интерпретаторов в единых инструментах. Например,
компиляция
just-in-time
(компиляции
«на
лету»),
когда
промежуточный
программный код, по мере исполнения или с опережением преобразуется в набор
инструкций, исполняемых непосредственно средствами операционной системы,
но под контролем среды исполнения. Такого рода подход стал родоначальником
ряда современных программных платформ, например, Java и .NET.
– Отладчики,
которые
поддерживают
процесс
конструирования
программного обеспечения, но, в то же время, функционально отличаются от
редакторов и компиляторов.
Кроме того, необходимо выделить «интегрированные средства разработки»
(IDE – integrated developers environment), программные библиотеки/библиотеки
компонент, а также «программные платформы» (например, Java, J2EE и Microsoft
.NET) и «платформы облачных вычислений» (например, Microsoft Azure, Amazon
и др.), которые включают наравне с инструментами, как таковыми, и
определенные модели конструирования, преобразования и выполнения кода.
3.1.3 Инструменты тестирования
К числу инструментов данного класса относятся:
– генераторы тестов, поддерживающие функцию разработки сценариев
тестирования;
– средства выполнения тестов, формирующие среду исполнения тестовых
сценариев в окружении, позволяющем отслеживать поведение тестируемого
объекта;
– средства
оценки
тестов,
поддерживающие
оценку
результатов
выполнения тестов для определения соответствия наблюдаемого поведения
тестируемого объекта ожидаемому;
– менеджеры тестами, обеспечивающие поддержку всех аспектов процесса
тестирования программного обеспечения;
– инструменты
количественной
обеспечения,
средства
анализа
оценки
включающие
тестирования
и
производительности,
анализа
используемые
производительности
для
программного
инструменты
функционального
тестирования,
безопасности,
инструменты
тестирования
пользовательского интерфейса, инструменты нагрузочного тестирования и
прочие.
3.1.4 Инструменты сопровождения
Инструменты сопровождения существующего программного обеспечения,
согласно SWEBOK [25] можно поделить две категории:
– инструменты облегчения понимания (демонстрации), служащие для
помощи в понимании человеком программ, например, различные средства
визуализации;
– инструменты
реинжиниринга,
обеспечивающие
функции
по
реорганизации процессов жизненного цикла для повышения их эффективности,
управляемости, безопасности и т.д.
Средства «обратного» инжиниринга помогают в процессе восстановления
для
существующего
программного
обеспечения
таких
артефактов,
как
спецификация и описание дизайна (архитектуры), которые, в дальнейшем, могут
быть
трансформированы
для
генерации
нового
продукта
на
основе
функциональности существующего [7].
3.1.5 Инструменты конфигурационного управления
Инструменты конфигурационного управления по [25] делятся на три
категории:
– инструменты отслеживания дефектов, расширений и проблем;
– инструменты управления версиями;
– инструменты сборки и выпуска, предназначенные для управления
задачами сборки и выпуска продуктов, а также включают средства инсталляции.
3.1.6 Инструменты управления инженерной деятельностью
Средства управления деятельностью по программной инженерии делятся на
три категории [25]:
– инструменты планирования и отслеживания проектов, применяемые для
календарного планирования работ, количественной оценки усилий и стоимостных
ожиданий, связанных с проектами (например, Microsoft Project);
– инструменты управления рисками, используемые для идентификации,
оценки ожиданий и мониторинга рисков (например, Project Expert).
– инструменты
количественной
оценки,
обеспечивающие
ведение
измерений и помогающие в выполнении работ, связанных с программой
количественной оценки, проводимой в отношении проектов программного
обеспечения.
3.1.7 Инструменты поддержки процессов
К числу поддерживающих процессы можно отнести инструменты,
используемые для создания условий для разработки ПС:
– инструменты моделирования, позволяющие, описать модели процессов,
именно как модели;
– инструменты управления проектами, обеспечивающие возможности для
управления процессами.
– инструменты конфигурационного управления, поддерживающие работу с
актуальными версиями и задающие основные параметры проекта.
– ролевые
платформы
разработки
программного
обеспечения,
охватывающие все стадии жизненного цикла и, на сегодняшний день,
являющиеся
развитием
интегрированных
средств
разработки
и
CASE-
инструментов в направлении поддержки “смежной” функциональности –
управления
требованиями,
работ
по
конфигурационному
управлению
с
поддержкой управления изменениями, тестирования и оценки качества [7].
3.1.8 Инструменты обеспечения качества
Средства обеспечения качества делятся на две категории [25]:
– инструменты инспектирования, служащие для поддержки обзора и аудита
процессов;
– инструменты
анализа,
используемые
для
анализа
программных
артефактов, данных, потоков работ и зависимостей и для проверки определенных
свойств или артефактов на соответствие заданным характеристикам.
3.2 Методы
3.2.1 Эвристические методы
Эвристические методы – последовательность предписаний или процедур
обработки информации, выполняемая с целью поиска более рациональных и
новых конструктивных решений [википедия].
Эвристические методы обычно противопоставляют формальным методам
решения, опирающимся на точные математические модели. В психологической и
кибернетической литературе под эвристическими методами понимаются любые
методы, направленные на сокращение перебора, или индуктивные методы
решения задач. К их числу относят:
– структурные
функциональной
методы,
точки
предполагающие
зрения,
начиная
с
построение
системы
высокоуровневого
с
понимания
поведения системы с постепенным уточнением деталей на более низких уровнях;
– методы, ориентированные на данные, ориентированные на разработку
структур
данных,
которыми
манипулирует
создаваемое
программное
обеспечение, а функции при этом рассматриваются как вторичные.
– объектно-ориентированные
методы,
представляющие
программную
систему в виде совокупности объектов;
– методы, ориентированные на конкретную область применения и
специализированные методы разрабатываются с учетом конкретных решаемых
задач, например, всевозможные системы защиты информации.
3.2.2 Формальные методы
«Термин формальные методы подразумевает ряд операций, в состав
которых входит создание формальной спецификации системы, анализ и
доказательство спецификаций, реализация системы на основе преобразования
формальной спецификации в программы и верификация программ. Все эти
действия зависят от формальной спецификации программного обеспечения.
Формальная спецификация – это системная спецификация, записанная на языке,
словарь, синтаксис и семантика которого определены формально. Необходимость
формального определения языка предполагает, что этот язык основывается на
математических концепциях. Здесь используется область математики, которая
называется дискретной математикой и основывается на алгебре, теории множеств
и алгебре логики» [8].
Формальные методы можно классифицировать на следующие категории:
– языки и нотации спецификаций, которые могут быть ориентированы на
модель, свойства и поведение, например формальные методы описания
требований;
– методы трансформации, основанные на уточнении (трансформации)
превращении спецификаций в конечный результат, максимально близкий
желаемому – исполнимый программный продукт;
– методы подтверждения, основывающиеся на строгом математическом
доказательстве точности любых характеристик исходных предпосылок и
получаемого продукта с использованием теорем и проверки точности моделей.
Следует отметить, что строгие формальные методы обычно не эффективны
в области разработки прикладных систем, поскольку они требуют выполнения
сложных и трудоёмких доказательств на основе обычно весьма неполных данных.
Более того, успех проекта по разработке ПС зависит от такого количества
непредсказуемых факторов, то формальные методы далеко не всегда гарантируют
его достижение.
3.2.3 Методы прототипирования
Методы прототипирования можно разделить на три категории:
– стили
прототипирования,
подразумевающие
создание
временно
используемых прототипов и эволюционное прототипирование;
– цели прототипирования, такие как требования, архитектурный дизайн или
пользовательский интерфейс;
– техники
оценки
/
исследования
результатов
прототипирования,
касающиеся того, как будут использованы результаты создания прототипа.
4 Качество и эффективность в программной инженерии
4.1 Обеспечение качества программного обеспечения
Качество – степень, с которой совокупность собственных характеристик
объекта выполняет требования [определение международного стандарта ISO
9000-2008].
Качество
программного
средства
–
совокупность
свойств
программного продукта, которые обуславливают возможность удовлетворить
определенные потребности пользователя в соответствии с его назначением.
Такое понятное для сферы материального производства, понятие качества
очень сложно и неоднозначно в сфере информационных технологий. Между тем,
единое представление о качестве разрабатываемого продукта должно быть и у
заказчиков, и у разработчиков, и у специалистов по сопровождению.
4.1.1 Качество программного продукта
Формирование представлений о
разрабатываемого
программного
качестве, вернее, уровне качества
средства
закладывается
ещё
на
этапе
формирования требований к нему. Следовательно, аналитики (специалисты по
управлению требованиями) должны во взаимодействии, в первую очередь с
заказчиками, извлечь требования к качеству и определить приоритеты в
соотношении скорость разработки – качество конечного продукта.
Стандарт ISO 9126 [‘] служит гидом в деле определения качества
программных средств и определяет для двух из трех описанных в нем моделей,
связанные характеристики качества, а также метрики, полезные для оценки
качества программных продуктов. В стандарте понятие «продукт» расширено
включением
всех
элементов,
создаваемых
на
выходе
всех
процессов,
используемых для создания конечного программного продукта, таких как:
спецификация системных требований, спецификация программных требований
для программных компонент системы, модели, код, тестовая документация,
отчеты, создаваемые в результате работ по анализу качества. Обычно термин
«качество» используется в отношении конечного продукта и поведения системы в
процессе эксплуатации.
4.1.2 Культура и этика программной инженерии
С
точки
программному
зрения
SWEBOK
обеспечению
[]
предполагается,
должны
воспринимать
что
инженеры
вопросы
по
качества
программного обеспечения как часть своей профессиональной культуры.
Этические аспекты могут играть значительную роль в обеспечении качества
программного обеспечения, культуре и отношении инженеров к своей работе.
IEEE Computer Society и ACM разработали кодекс этики («моральный кодекс») и
профессиональной практики, основанный на восьми принципах, помогающих
инженерам укрепить их отношение к качеству и независимость в решении
вопросов обеспечения достойного качества создаваемых программных продуктов
в их повседневной работе.
4.1.3 Значение и стоимость качества
Не все характеристики качества могут быть необходимы в конкретном
проекте, некоторые из них могут требоваться не полно, в определённой степени.
Значит, возникает возможность уменьшить трудоёмкость разработки, исключив
из проекта избыточные требования. В зависимости от этого формируется и
себестоимость качества.
Стоимость
качества
может
быть
дифференцирована
на
стоимость
предупреждения дефектов, стоимость оценки (контроля), стоимость внутренних, а
также внешних сбоев [Кросби – затраты на качество].
Затраты на качество
программного продукта
Затраты на поддержание
Затраты на устранение
соответствия
несоответствия
Стоимость
Стоимость
Стоимость
Стоимость
предупреждения
оценки
внутренних сбоев
внешних сбоев
дефектов
(контроля)
(дефектов)
(дефектов)
Рис. 46 Составляющие затрат на качество
Создаваемое программное средство должно
обладать определенной
ценностью для потребителя, которая может выражаться как в форме стоимости,
так и в других формах. Заказчик имеет свои представления о максимальных
возможностях по инвестированию в разработку и свои ожидания в отношении
качества программного средства, которые являются ограничениями для проекта.
Хотя нет универсальных рекомендаций о правилах выбора подходов к
обеспечению качества, инженеры должны уметь генерировать альтернативы,
определяющие
соотношение
различного
уровня
качества
и
стоимости,
основываясь на идеи уменьшения затрат за счёт использования процессного
подхода.
4.1.4 Повышение качества ПС с использованием процессного подхода
Качество программного обеспечения можно повышать за счет итеративного
процесса постоянного улучшения с одновременным управлением:
– процессами жизненного цикла;
– процессом обнаружения, устранения и предотвращения сбоев/дефектов;
– процессов улучшения качества.
К
качества,
программной
известные
инженерии
в
применимы
промышленности.
методы
Например,
совершенствования
предотвращение
несоответствий, непрерывное улучшение, ориентация на потребителя и др. В
основу этих методов положена идея о том, что качество продукта определяется
качеством используемых для его создания процессов.
Подходы TQM (Total Quality Management – всеобщее управление
качеством) PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка,
Реакция/Корректировка), являются инструментами в сфере управления качеством
и также вполне применимы в рамках программной инженерии.
Уточнение требований к процессу
Документы, отражающие системную модель в
виде требований: СТП, ДИ, положения и т.д.
Требования к выполнению
Цикл PDCA
Планирование
бизнес-процессов:
установление
показателей
достижения целей
Подтверждение
планов
Стандартизация
полученного
опыта
Заключение
Цели
Контроль
результатов
бизнес-процесса,
анализ достижения
цели
Планы, цели
Реализация
бизнеспроцесса
Результаты
Рис. 4.47 Цикл управления PDCA (взято из [])
4.1.5 Показатели качества программных средств
Основные затруднения в определении показателей связаны с тем, что они
носят качественный характер и должны оценивать различные свойства
сопоставляемых программных изделий. А эти свойства присущи не самому
программному изделию, а связаны с объектом применения ПС. Таким образом,
качество ПС относительное понятие, которое имеет смысл только лишь в связи с
реальными условиями применения. Рассмотрим показатели, приведённые в ISO
9126 []:
1. Функциональная пригодность – набор атрибутов характеризующий,
соответствие
функциональных
возможностей
ПС
набору
требуемой
пользователем функциональности. Это наиболее неопределенная и объективно
трудно
оцениваемая
характеристика
программного
средства.
Области
применения, номенклатура и функции комплексов программ охватывают столь
разнообразные сферы деятельности человека, что невозможно выделить и
унифицировать небольшое число атрибутов для оценки и сравнения этой
характеристики в различных комплексах программ.
Функциональная пригодность ПС и конкретные показатели для её оценки:
 пригодность
по
применению
для
решения
задач
–
связь
функционального назначения ПС с задачами, которые оно должно решать;
 корректность (точность) – возможность ведения БД,
насколько
алгоритм формирования результата обеспечивает точность его получения;
 защищенность – требования к надежности из ТЗ (от ошибок,
несанкционированного доступа, возможность восстановления)
 способность к взаимодействию – с другими ПС, включающую;
 согласованность со стандартами отрасли;
 согласованность со стандартами проектирования.
2. Надежность – набор атрибутов, относящихся к способности ПО
сохранять свой уровень качества функционирования в установленных условиях за
определенный
период
времени.
Надёжность
определяет
измерение
количественных метрик атрибутов характеристик в использовании.
Надежность характеризуется:
– уровнем завершенности и готовности (отсутствие остаточных ошибок
после ввода в эксплуатацию);
– устойчивостью к ошибкам в эксплуатации;
– обратной связью по оценке продукта потребителем;
– восстанавливаемостью – возможностью восстановления БД в случае
нарушения её работы.
3. Практичность (применимость) программных средств – набор
атрибутов, относящихся к объему работ, требуемых для исполнения и
индивидуальной оценки такого исполнения определенным или предполагаемым
кругом
пользователей.
Практичность
включает
определение
понятности,
простоты использования, изучаемости и привлекательности программного
средства. В основном это качественная (и субъективная) оценка в баллах, однако
некоторые атрибуты можно оценить количественно по трудоемкости и
длительности выполнения операций при использовании программного средства, а
также по объему документации, необходимой для их изучения.
Применимость включает:
 понятность
пользовательского
интерфейса
(насколько
интерфейс
приспособлен к уровню подготовки пользователя);
 привлекательностью (визуальная привлекательность для пользователя);
 характер предоставления эксплуатирующей документации (её вид, носит
ли она функциональную направленность);
 простоту обучения (наличие тематических справочников и развитой
советующей и обучающей системой).
4. Эффективность – набор атрибутов, относящихся к соотношению между
уровнем качества функционирования ПО и объемом используемых ресурсов при
установленных условиях. Для корректного определения предельной пропускной
способности информационной системы с данным программным средством нужно
измерить экстремальные и средние значения длительностей исполнения
функциональных групп программ и маршруты, на которых они достигаются. Если
предварительно в процессе проектирования производительность компьютера не
оценивалась, то, скорее всего, понадобится большая доработка или даже замена
компьютера на более быстродействующий.
Эффективность включает:
 ресурсную эффективность – насколько требования к использованию
ресурсов применимы к результатам решения задач;
 временную эффективность.
5. Сопровождаемость – набор атрибутов, относящихся к объему работ,
требуемых
для
проведения
конкретных
изменений
(модификаций).
Сопровождаемость можно оценивать полнотой и достоверностью документации о
состояниях программного средства и его компонентов, всех предполагаемых и
выполненных изменениях, позволяющей установить текущее состояние версий
программ в любой момент времени и историю их развития. Она должна
определять стратегию, стандарты, процедуры, распределение ресурсов и планы
создания, изменения и применения документов на программы и данные.
Сопровождаемость включает:
 удобство
для
структурированных ПС);
анализа
(удобство
локализации
ошибок,
хорошо
 изменяемость (возможность проводить изменения);
 стабильность (сроком безотказной работы);
 тестируемость (простотой формирования тестов).
6. Мобильность (переносимость) – набор атрибутов, относящихся к
способности ПС быть перенесенным из одного окружения в другое.
Количественно эту характеристику программного средства и совокупность
ее атрибутов можно (и целесообразно) оценить в экономических показателях:
стоимости, трудоемкости и длительности реализации процедур переноса на иные
платформы определенной совокупности программ и данных.
Переносимость характеризуется:
 адаптируемостью – простотой адаптации пользователя и аппаратных
средств;
 замещаемостью – возможностью замещения ПС своей предыдущей
версии и возможностью испытания элементов ПС в следующих версиях
замещающего его ПС;
 сосуществованием – возможностью без конфликтов с другими ПС
функционировать в новом операционном окружении;
 внедряемостью – трудоемкостью работ по установке ПС.
4.1.6 Количественная оценка качества программного обеспечения
Если характеристики качества выбраны правильно, такие измерения могут
поддержать качество (уровень качества) многими способами. Метрики могут
помочь
в
управлении
процессом
принятия
решений.
Метрики
могут
способствовать поиску проблемных аспектов и узких мест в процессах. Метрики
являются инструментом оценки качества своей работы самими инженерами – как
в целях, определенных при управлении качеством, так и с точки зрения более
долгосрочного процесса совершенствования качества [орлик].
По мере увеличения внутренней сложности программного обеспечения, всё
острее встаёт вопрос – насколько достигаются количественно оцениваемые цели в
области качества программного средства.
Хотя, как количественные оценки характеристик качества могут полезны
сами по себе, могут эффективно применяться математические и графические
техники, облегчающие интерпретацию значений метрик. Такие техники вполне
естественно классифицируются, например, следующим образом:
– статистические методы (анализ Парето, нормальное распределение и т.п.);
– статистические тесты;
– анализ тенденций (сравнительный анализ);
– предсказание (модели надежности).
Техники, основанные на статистических методах и статистические тесты,
обычно
используются
для
выявления
проблемных
мест
исследуемого
программного продукта. Результирующие графики и диаграммы визуально
помогают лицам, принимающим решения, в определении аспектов, на которых
необходимо сфокусировать ресурсы проекта.
Результаты анализа тенденций, позволяющие выявить скрытые дефекты,
проявляющиеся в негативных тенденциях изменения отдельных характеристик.
Техники предсказания помогают в планировании времени тестов и в
предсказании сбоев.
На основе методов количественной оценки могут быть сформированы, так
называемые профили дефектов для конкретных прикладных областей. В
дальнейшем, для будущих программных систем в данной организации, такие
профили могут направлять процессы обеспечения качества программных средств,
увеличивая усилия, направленные на наиболее вероятные источники проблем в
создаваемых продуктах. Аналогично этому, результаты эталонных сравнений или
типовое для данной прикладной области количество дефектов могут служить в
качестве вспомогательных средств для определения момента, когда продукт готов
для передачи в эксплуатацию.
4.2 Модели качества процессов конструирования
В условиях жесткой конкуренции, важно гарантировать высокое качество
процесса конструирования программных средств.
4.2.1 Качество процессов
ISO/IEC определяет три связанных модели качества программного
обеспечения (ISO 9126-01 Software Engineering - Product Quality, Part 1: Quality
Model) – внутреннее качество, внешнее качество и качество в процессе
эксплуатации, а также
набор соответствующих работ по оценке качества
программного обеспечения (ISO 14598-98 Software Product Evaluation).
Модели качества в современном понимании строятся на управлении
качеством и обеспечении качества процессов, в частности, программной
инженерии. Качество процесса напрямую влияет на характеристики качества
продукта, которые, в свою очередь, отражаются в восприятии качества продукта в
процессе эксплуатации со стороны заказчика.
Существует два основных подхода в области качества программного
обеспечения:
– Европейский
подход
TickIT,
рассмотривающий
общую
системы
менеджмента качества ISO 9001 в приложении к программным проектам и
представленный, также, в виде специальных рекомендаций ISO 90003-04.
– Американский подход CMMI предоставляющий рекомендации по
совершенствованию (повышению зрелости) отдельных процессов.
4.2.2 CMM/CMMI
Наверное, самым именитым стандартом качества следует считать Capability
Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки
вместе с его производными. Он был создан SEI (Software Engineering Institute),
который финансируется за счет Министерства обороны США и является
структурной единицей Университета Карнеги-Меллона. Первая официальная
версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше
– основные его положения были опубликованы еще в 1986 г.
Успех CMM предопределило несколько факторов. Этот стандарт был одним
из первых, изначально учитывающих специфику создания ПО. Он оказался
достаточно прост и прозрачен как для понимания, так и для использования, и
регламентировал, «что», а не «как» делать, а потому подходил для различных
моделей жизненного цикла, методологий разработки и не накладывал каких-либо
ограничений на стандарты документирования, инструментарий, среду и языки,
применяемые в проектах. И, пожалуй, основным фактором, предопределившим
популярность CMM, явилось сотрудничество SEI с Министерством обороны
США, что де-факто означало использование стандарта при реализации проектов
по заказу этого ведомства.
Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из
которых соответствуют определенные ключевые области процессов (Key Process
Areas, KPA).
Таблица 1. Уровни модели CMM
Название уровня
Ключевые области процесса
Начальный
Если организация находится на этом уровне, то ключевых областей
процессов для нее не предусмотрено
Управление программными конфигурациями. Обеспечение качества
программных продуктов. Управление контрактами подрядчиков.
Контроль за ходом проектов. Планирование программных проектов.
Управление требованиями
Экспертные оценки. Координация взаимодействий проектных групп.
Инженерия программного продукта. Комплексный менеджмент ПО.
Программа обучения персонала. Определение организационного
процесса. Область действия организационного процесса
Менеджмент качества ПО. Управление процессом на основе
количественных методов
Управление изменением процесса. Управление технологическими
изменениями. Предотвращение дефектов
Повторяющийся
Определенный
Управляемый
Оптимизируемый
Деление на уровни и определение KPA для каждого из них позволяет
последовательно внедрять CMM, используя стандарт в качестве руководства,
которое может обеспечить постоянное совершенствование процесса разработки.
Стандарт CMM оказался весьма успешным, и впоследствии на его основе
была создана целая серия стандартов (табл. 2). Притом он получил новое имя –
SW-CMM (Capability Maturity Model for Software), точнее отражающее его
положение в достаточно многочисленном семействе стандартов.
Таблица 2. Развитие стандартов CMM
Название
Описание
стандарта
Ориентирован на вопросы системного инжиниринга – разработку продуктов
(анализ требований, проектирование систем продукта и их интеграция) и их
производство (планирование производственных линий и функционирование)
Trusted CMM (T-CMM) Предназначен для обслуживания чувствительных и закрытых программных
систем, которые требуют гарантии высокого качества ПО
System Security
Сфокусирован на аспектах безопасности программной инженерии,
Engineering CMM
обеспечивает безопасный процесс разработки, в том числе и безопасность
(SSE-CMM)
членов команды создателей
People CMM (P-CMM) Рассматривает вопросы развития персонала в софтверных организациях
Software Acquisition
Охватывает вопросы приобретения программных продуктов у внешних
CMM (SA-CMM)
организаций
Integrated Product
Служит средой для интеграции усилий по разработке на всех этапах
Development CMM
жизненного цикла и со стороны каждого отдела компании
(IPD-CMM)
System Engineering
CMM (SE-CMM)
Однако практическое применение стандартов серии CMM показало, что они
не обеспечивают безоговорочного успеха в разработке ПС. Эти стандарты не
были хорошо согласованы между собой – одновременное внедрение различных
модификаций CMM могло оказаться достаточно сложной задачей и приводило в
недоумение специалистов организаций, которые с этим сталкивались.
Также
существенная
проблема
CMM
состоит
в
необходимости
«выравнивания» всех процессов. Если организация пытается сертифицироваться
на определенный уровень, то она должна обеспечить соответствующий уровень
для всех своих процессов. Даже если специфика, методология или особенности
разработки
не
располагают
сертификация это требует.
к
выполнению
определенных
процессов,
Еще одна проблема вызвана тем положением, которое заняли стандарты
CMM в современной индустрии ПС. Поскольку организация, обладающая
высоким уровнем в соответствии с CMM, должна обеспечивать более высокие
показатели программных продуктов по сравнению с теми, кто сертифицирован на
низших уровнях, то стандарт стал применяться в качестве критерия отбора для
участия в тендерах на разработку ПС или в аутсорсинговых проектах. Спрос на
сертифицированные
организации
породил
предложение
по
«быстрой
и
безболезненной сертификации».
Подобная ситуация стала возможной благодаря недостаткам процесса
сертификации. Сертификации подлежит не вся организация в целом, а только
определенный проект. Ничто не мешает организации создать «образцовопоказательный» проект, выполняемый с учетом всех требований высоких уровней
стандарта CMM, получить соответствующий уровень сертификации и заявить о
том, что все продукты отвечают такому-то уровню стандарта.
Разрешить большинство проблем CMM призван новый стандарт SEI –
Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки
уровня зрелости процессов разработки. Стандарт CMMI изначально создавался
таким образом, чтобы объединить существующие варианты CMM и исключить
какие-либо противоречия при его практическом применении в различных сферах
деятельности высокотехнологичных компаний.
Для того чтобы устранить необходимость «выравнивания» процессов
организации и быть более приспособленным к ее бизнес-потребностям, а не
наоборот, стандарт CMMI имеет две формы представления – классическую,
многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная
форма представления рассматривает не уровни зрелости (Maturity Levels), а
уровни возможностей (Capability Levels), которые оцениваются для отдельных
областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней
зрелости
стандарта
CMM,
а
также
уровней
зрелости
многоуровневого
представления CMMI и уровней возможностей непрерывного представления
CMMI.
Таблица 3. Соответствие уровней CMM/CMMI
№
Уровень
Уровень зрелости
Уровень возможностей
многоуровневого
непрерывного
представления CMMI
представления CMMI
–
Начальный
Управляемый
Определенный
Управляемый количественно
Оптимизируемый
Незавершенный
Выполнимый
Управляемый
Определенный
Управляемый количественно
Оптимизируемый
уровня зрелости CMM
0
1
2
3
4
5
–
Начальный
Повторяющийся
Определенный
Управляемый
Оптимизируемый
SEI отказывается от CMM и взамен активно продвигает CMMI, обещая
ужесточить контроль за процессом сертификации, вводя новые классы,
позволяющие сократить затраты на него и сделать его более привлекательным для
небольших организаций; обеспечивая совместимость со стандартами ISO. Однако
факт
остается
фактом:
в
современных
условиях
наличие
сертификата
определенного уровня CMM/CMMI не является таким значимым фактором, как
несколько лет назад, и принимается без дополнительных вопросов разве что в
проектах, выполняемых по государственному заказу.
4.2.3 TickIT
TickIT – схема сертификации систем менеджмента качества ИТ–компаний
на основе стандартов ISO серии 9000, предложенная группой ведущих фирм и
некоммерческих
организаций
Великобритании,
работающих
в
области
информатики.
Стандарты ISO серии 9000 – обширная и наиболее распространенная во
всем мире серия стандартов качества. Они охватывают множество отраслей
современной индустрии и периодически обновляются.
Изначально стандарты ISO серии 9000 слабо учитывали специфику отрасли
ПО и были больше ориентированы на производственную сферу. Однако в конце
1980-х годов был выпущен первый ориентированный на области разработки ПО
стандарт, получивший название ISO 9000-3:1997. Несмотря на то, что ISO 9000-3
оперировал терминологией, которая используется при разработке ПО, и
рассматривал характерные для программной индустрии вопросы, он являлся не
более чем расширенным вариантом ISO 9001:1994, а потому не всегда
соответствовал специфике программных проектов.
Сегодня на смену ISO 9000-3 пришел стандарт ISO/IEC 90003:2004,
который, в свою очередь, является проекцией промышленного стандарта ISO
9001:2000 на программную индустрию. По сравнению с предыдущим он гораздо
более приспособлен к специфике отрасли, в частности, ссылается на модели
жизненного цикла программных систем и детально рассматривает вопросы,
характерные для разработки ПО. Однако стандарт ISO 90003:2004 – это стандарт
обеспечения качества и не может быть использован для оценки уровня зрелости и
предсказания результата программного проекта. В таких случаях прибегают к
стандарту
ISO/IEC
15504:2004.
«Информационные
технологии.
Оценка
процессов» (в 5 частях). Стандарт ISO/IEC 15504 предназначен для оценки
процесса разработки информационных систем, в частности, программного
обеспечения. Он изначально был спроектирован таким образом, чтобы в
значительной степени соответствовать существующим в отрасли стандартам
оценки процесса создания ПО. Именно это требование определило схожесть
стандарта с основными принципами CMM/CMMI. Его текущая версия
предусматривает шесть уровней возможностей (от нулевого до пятого), которые
соответствуют уровням возможностей непрерывного представления стандарта
CMMI (табл. 4).
Таблица 4. Уровни CMMI (2004)
№
Название уровня
Название уровня возможностей
уровня
возможностей стандарта
непрерывного представления
ISO/IEC 15504
CMMI
Незавершенный
Выполнимый
Управляемый
Установленный
Предсказуемый
Оптимизируемый
Незавершенный
Выполнимый
Управляемый
Определенный
Управляемый количественно
Оптимизируемый
0
1
2
3
4
5
Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI
взаимозаменяемы,
в
сертификации,
соответствии
в
частности,
сертификация по ISO/IEC 15504.
для
с
CMMI
которым
предусматривается
одновременно
режим
проводится
и
Качество программного продукта регламентирует стандарт ISO/IEC 9126,
состоящий из отдельных частей, которые выпускаются независимо. ISO/IEC 9126
предлагает комплексную иерархическую структуру для описания качественных
характеристик ПО.
Несмотря на то, что ISO позже, чем SEI взялась за разработку стандартов
для программной индустрии, она имеет немало шансов завоевать передовую
позицию. Стандарты ISO весьма обширны, процедура сертификации хорошо
отработана. Отметим, что ISO требует периодической ресертификации, чего SEI
не проводила для CMM.
4.2.4 Прочие подходы
Начало методологии шести сигм (Six Sigma) было положено в Motorola в
конце 1980-х годов. Motorola провозгласила курс на повышение качества
производимой продукции, одним из направлений которого было снижение
количества дефектов до уровня 6σ (где σ – дисперсия) – 3,4 дефекта на миллион
возможных (на самом деле 3,4 дефекта на миллион возможных означает не 6, а
4,5 сигмы, однако разработчики методологии добавили полторы сигмы для того,
чтобы учесть нестабильность процессов). Подобное значение было избрано не
случайно – в результате проведенных в компании исследований было
установлено, что именно такой уровень качества обеспечит, кроме явных
преимуществ в виде повышения конкурентоспособности продукции, также
сокращение издержек за счет уменьшения затрат на доводку некачественных
разработок и устранение дефектов.
Реализация шести сигм происходит в виде процесса DMAIC (Define,
Measure, Analyze, Improve, Control):
 определение;
 измерение;
 анализ;
 совершенствование;
 управление.
Этот процесс построен на количественных методах принятия решений.
Сильная сторона шести сигм – ориентация на интенсивное применение
математического аппарата.
Несмотря на промышленное происхождение, методология шесть сигм
получила популярность среди разработчиков ПО. Ориентация на количественные
методы позволила применять шесть сигм как инструмент для обеспечения
постоянного совершенствования процесса. Особенно заметно его преимущество
при использовании в организациях, которые достигли высоких уровней зрелости
в соответствии с CMM/CMMI и ISO/IEC 15504.
Недостатки:
1 Основное преимущество шести сигм одновременно является и основным
недостатком
методологии:
ориентация
на
количественные
методы
предусматривает наличие возможностей для их применения. Организация должна
приложить
определенные
усилия
для
того,
чтобы
внедрить
методы
количественной оценки производительности труда, показателей качества и т. д.
Количественная оценка в отрасли ПО – весьма сложная задача.
2 Шесть сигм ориентирована на совершенствование процесса и не
предусматривает изначального повышения показателей его эффективности. Для
этих целей необходимы другие подходы.
На практике шесть сигм очень часто успешно применяется совместно с
другими стандартами и системами обеспечения качества, позволяя выявить
причины проблем и помочь их устранить.
Весьма популярная в Европе методология ITIL (IT Infrastructure Library)
ориентирована на обеспечение функционирования IT-инфраструктуры. ITIL
разработана при участии правительства Великобритании в конце 80-х – начале 90х годов XX в. и первоначально получила распространение в правительственных
проектах этой страны.
ITIL – это зрелая и обширная методология, охватывающая практически все
вопросы, связанные с разворачиванием и использованием информационных
систем.
В
настоящий
момент
она
имеет
следующие
составляющие,
соответствующие ключевым вопросам взаимодействия технологий и бизнеса:
служба
поддержки,
оказание
услуг,
управление
безопасностью,
IT-
инфраструктурой, цепочками поставок, программными проектами и активами,
бизнес-вопросы обеспечения IT-проектов, в том числе и аутсорсинг. ITIL хорошо
согласуется со стандартами серии ISO 9000 и может служить основой для
проведения по ним последующей сертификации.
Однако данная методология не затрагивает непосредственно процессов
разработки ПО, а потому обычно в софтверных компаниях применяется
совместно с другими, более ориентированными на специфику ПО стандартами,
например CMMI. Особую популярность ITIL получила в таких смежных с
разработкой ПО областях, как служба поддержки, внедрение и сопровождение
ПО, предоставление услуг по поддержке IT-инфраструктуры.
Заметим, что эта методология допускает достаточно неоднозначную
интерпретацию, поэтому ее внедрение
должно происходить при участии
опытных специалистов во избежание упрощения и неверной трактовки ее
положений.
4.3 Процессы управления качеством программного обеспечения
Процессы управления качеством многообразны: одни процессы позволяют
напрямую находить дефекты, другие помогают определить где именно может
быть важно провести более детальные исследования.
Специализированные
процессы
управления
качеством
программного
обеспечения определены в стандарте 12207 []:
– процесс обеспечения качества;
– процесс верификации;
– процесс аттестации;
– процесс совместного анализа;
– процесс аудита.
Процессы управления качеством помогают в обеспечении лучшего качества
программного
обеспечения
в
конкретном
проекте.
Они
предоставляют
менеджерам основную информацию по каждому продукту и, кроме того,
включают параметры качества всего процесса программной инженерии.
Процессы
управления
качеством
состоят
из
задач
и
техник,
предназначенных для оценки того, как начинают реализовываться планы по
созданию программного обеспечения и насколько хорошо промежуточные и
конечные
продукты
соответствуют
заданным
требованиям.
Результаты
выполнения этих задач представляются в виде отчетов для менеджеров перед тем,
как будут предприняты соответствующие корректирующие действия.
Процессы управления качеством тесно связаны между собой. Они могут
перекрываться, а иногда даже и совмещаться.
4.3.1 Подтверждение качества программного обеспечения
Процессы подтверждения качества программных средств обеспечивают
подтверждение того, что программные продукты и процессы жизненного цикла
проекта соответствуют заданным требованиям [25]. Подтверждение проводится
на основе планирования, постановки задач (работ) и исполнения набора действий,
направленных на то, чтобы качество стало неотъемлемой частью программного
обеспечения. Такой подход обеспечивает точное формулирование требований к
соответствующему решению. Процессы подтверждения качества функционируют
для обеспечения качества в процессе разработки и сопровождения за счет
выполнения различных действий на всех этапах жизненного цикла, что позволяет
идентифицировать проблемы на ранних стадиях, которые практически неизбежны
в любой сложной деятельности. Такая идентификация возможна во многих
случаях, когда проблема еще является риском и ее предотвращение возможно.
Поэтому управление рисками является серьезным дополнительным инструментом
для обеспечения качества программного обеспечения.
Роль процессов подтверждения качества состоит в том, чтобы обеспечить
соответствующее планирование процессов, дальнейшее исполнение процессов на
основе заданного плана и проведение необходимых измерений процессов с
передачей
результатов
измерений
заинтересованным
сторонам
(организационными структурам и лицам).
4.3.2 Проверка (верификация) и аттестация
Проверка и аттестация программного обеспечения – упорядоченный подход
в оценке программных продуктов, применяемый на протяжении всего жизненного
цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации,
направлены
на
обеспечение
качества
как
неотъемлемой
характеристики
программного обеспечения и удовлетворение пользовательских требований [25].
Верификация и аттестация напрямую адресуется вопросам качества
программного обеспечения и использует соответствующие техники тестирования
для обнаружения тех или иных дефектов. Верификация и аттестация может
применяться для промежуточных продуктов, однако, в том объеме, который
соответствует промежуточным шагам процессов жизненного цикла.
Процесс верификации и аттестации определяет степень соответствия
продукта (результата) тех или иных работ по разработке и сопровождению
требованиям, сформулированным в рамках этих работ, а конечного продукта
заданным целям и пользовательским требованиям. Верификация – попытка
обеспечить правильную разработку продукта, в том значении, что получаемый в
рамках соответствующей деятельности продукт соответствует спецификациям,
заданным в процессе предыдущей деятельности. Аттестация – попытка
обеспечить создание правильного продукта, с точки зрения достижения
поставленной цели применения. Оба процесса – верификация и аттестация –
начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают
исследованию (экспертизу) ключевых возможностей продукта как в контексте
непосредственно предшествующих результатов (промежуточных продуктов), так
и с точки зрения удовлетворения соответствующих спецификаций.
4.3.3 Оценка и аудит
Оценки можно поделить на управленческие и технические:
1 Назначение управленческих оценок состоит в отслеживании развития
проекта (продукта), определения статуса планов и расписаний, утверждения
требования
и
распределения
ресурсов,
или
оценки
эффективности
управленческих подходов, используемых для достижения поставленных целей.
[IEEE 1028-97 “IEEE Standard for Software Reviews”]. Управленческие оценки
поддерживают принятие решений о внесении изменений и выполнении
корректирующих действий, необходимых в процессе выполнения программного
проекта. Управленческие оценки определяют адекватность планов, расписаний и
требований, в то же время, контролируя их прогресс или несоответствие. Эти
оценки могут выполняться в отношении продукта, будучи фиксируемы в форме
отчетов аудита, отчетов о состоянии (развитии),
2 Назначением технических оценок является исследование программного
продукта для определения его пригодности для использования в надлежащих
целях.
Цель
состоит
в
идентификации
расхождений
с
утвержденными
спецификациями и стандартами. [IEEE 1028-97 “IEEE Standard for Software
Reviews]. Для обеспечения технических оценок необходимо распределение
следующих ролей: лицо, принимающее решения, лидер оценки, регистратор, а
также технический персонал, поддерживающий (непосредственно исполняющий)
действия по оценке. Техническая оценка требует, в обязательном порядке,
наличия следующих входных данных:
– формулировки целей;
– конкретного программного продукта (подвергаемого оценке);
– заданного плана проекта (плана управления проектом);
– списка проблем (вопросов), ассоциированных с продуктом;
– процедуры технической оценки.
Команда технической оценки следует заданной процедуре оценки.
Квалифицированные лица представляют обзор продукта (представляя команду
разработки). Исследование продукта проводится в течение одной и более встреч с
разработчиками. Техническая оценка завершается после того, как выполнены все
предписанные действия по исследованию продукта.
В дополнение к оценкам ISO 12207 [”] вводит понятия инспекций, прогонок
и аудитов:
1 Назначение инспекций состоит в обнаружении и идентификации аномалий
в программном продукте. [IEEE 1028-97 “IEEE Standard for Software Reviews”].
Существует два серьезных отличия инспекций от оценок (управленческой и
технической):
– лица, занимающие управленческие позиции (менеджеры) в отношении к
любым членам команды инспектирования, не должны участвовать в инспекциях;
– инспекция
(независимого
должна
от
проекта
вестись
и
его
под
целей)
руководством
лидера,
непредвзятого
обученного
техникам
инспектирования.
Инспектирование программного обеспечения всегда вовлекает авторов
промежуточного или конечного продукта, в отличие от оценок, которые не
требуют
этого
в
обязательном
порядке.
Инспекции
(как
временные
организационные единицы – группы, команды) включают лидера, регистратора,
рецензента и нескольких (от 2 до 5) инспекторов.
Инспекционные встречи занимают, обычно, несколько часов, в отличие от
технической оценки и аудита, предполагающих, в большинстве случаев, больший
объем работ и, соответственно, длящиеся дольше.
2 Назначение прогонки состоит в оценке программного продукта. Прогонка
может проводиться с целью ознакомления (обучения) аудитории с программным
продуктом. [IEEE 1028-97 “IEEE Standard for Software Reviews”].
Главные цели прогонки состоят (по IEEE 1028) в:
– Поиске аномалий
– Улучшении продукта
– Обсуждении альтернативных путей реализации
– Оценке соответствия стандартам и спецификациям
Прогонка похожа на инспекцию, однако, обычно проводится менее
формальным образом. В основном, прогонка организуется инженерами для
других членов команды с целью получения отклика от них на свою работу, как
одного из элементов (техник) обеспечения качества.
3 Назначением аудита программного обеспечения является независимая
оценка программных продуктов и процессов на предмет их соответствия
применимым регулирующим документам, стандартам, руководящим указаниям,
планам и процедурам. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Аудит
является
формально
организованной
деятельностью,
участники
которой
выполняют определенные роли, такие как главный аудитор, второй аудитор,
регистратор
и
инициатор.
В
аудите
принимает
участие
представитель
оцениваемой организации/организационной единицы. В результате аудита
идентифицируются случаи несоответствия и формируется отчет, необходимый
команде разработки для принятия корректирующих действий.
4.3.4 Характеристика дефектов
Процессы управления качеством обеспечивают нахождение несоответствий
(дефектов), описание которых играет основную роль в понимании продукта,
облегчает корректировку процесса или продукта, а также
информирует
менеджеров проектов и заказчиков о статусе (состоянии) процесса или продукта.
Существуют множество классификаций дефектов (сбоев). Характеристика
дефектов (аномалий) также используется в аудите и оценках, когда лидер оценки
часто представляет для обсуждения на соответствующих встречах список
аномалий, сформированный членами оценочной команды.
Управления качеством ПС обеспечивает сбор информации на всех стадиях
разработки и сопровождения программного обеспечения. Различные стандарты
предполагают различное смысловое наполнение терминов, связанных с понятием
«дефект». Частичные определения понятий такого рода (из стандарта IEEE
610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”)
выглядят следующим образом:
– Ошибка (error): “Отличие … между корректным результатом и
вычисленным результатом < полученным с использованием программного
обеспечения>”
– Недостаток (fault): “Некорректный шаг, процесс или определение
данных в компьютерной программе”
– Сбой (failure): “<Некорректный> результат, полученный в результате
недостатка”
– Человеческая/пользовательская ошибка (mistake): “Действие человека,
приведшее к некорректному результату”
Под дефектом будем понимать результат сбоя программного обеспечения.
По
результатам
работ,
направленных
на
обнаружение
дефектов,
выполняются действия по удалению дефектов из исследуемого продукта. Кроме
того, проводится анализ и подведение итогов по обнаруженным несоответствиям /
дефектам, использование техник количественной оценки (получение метрик) для
улучшения продукта и процесса, отслеживание дефектов и удаления их из
системы (с управленческим и техническим контролем проведения необходимых
корректирующих действий).
Данные о несоответствиях и дефектах, найденных в процессе реализации
процессов обеспечения качества, должны фиксироваться для предотвращения их
потери. Для некоторых техник, присутствие регистратора – обязательно, именно
для фиксирования такой информации, наравне с вопросами и принятыми
решениями.
Отчеты
о
дефектах
направляются
управленческому
звену
организации/организационной единицы или структуры.
4.3.5 Методы управления качеством программного обеспечения
Методы
управления
качеством
программных
средств
могут
быть
распределены по нескольким категориям:
– статические;
– техники коллективной оценки;
– аналитические;
– динамические.
Статические техники
Статические техники предполагают детальное исследование проектной
документации, программного обеспечения и другой информации о программном
продукте без его исполнения. Эти техники могут включать другие, действия по
коллективной оценке или индивидуальному анализу, вне зависимости от степени
использования средств автоматизации.
Техники коллективной оценки
Форма такого рода техник, включая оценку и аудит, может варьироваться
от формальных собраний до неформальных встреч или обсуждения продукта
даже без обращения к его коду. Обычно, такого рода техники предполагают
очного взаимодействия минимум двух, а в большинстве случаев, и более
специалистов. При этом, такие встречи могут требовать предварительной
подготовки.
К
ресурсам,
используемым
в
таких
техниках,
наравне
с
исследуемыми артефактами могут относиться листы проверки и результаты
аналитических техник и работ по тестированию.
Аналитические техники
Инженеры, занимающиеся программным обеспечением, как правило,
применяют аналитические техники. Иногда, несколько инженеров используют
одну и ту же технику, но в отношении разных частей продукта. Некоторые
техники базируются на специфике применяемых инструментальных средств,
другие – предполагают “ручную” работу. Многие могут помогать находить
дефекты напрямую, но чаще всего они используются для поддержки других
техник. Ряд техник также включает различного рода экспертизу (assessment) как
составной элемент общего анализа качества.
Каждый тип анализа обладает конкретным назначением и не все типы
применимы к любому проекту. Примером техники поддержки является анализ
сложности, который полезен для определения фрагментов дизайна системы,
обладающих слишком высокой сложностью для корректной реализации,
тестирования или сопровождения.
Для программного обеспечения с обширной алгоритмической логикой
крайне важно применять алгоритмические техники, особенно в тех случаях, когда
некорректный алгоритм может привести к катастрофическим результатам
(например,
программное
обеспечение
авионики,
для
которой
вопросы
безопасности использования играют решающую роль).
Другие, более формальные типы аналитических техник известны как
формальные методы. Они иногда применяются для проверки требований и
дизайна. Проверка корректности применяется к критическим фрагментам
программного обеспечения. Чаще всего они используются для верификации особо
важных частей критически-важных систем, например, конкректных требований
информационной безопасности и надежности.
Динамические техники
В процессе разработки и сопровождения программного обеспечения
приходится обращаться к различным видам динамических техник. В основном,
это техники тестирования. Однако, в качестве динамических техник могут
рассматриваться техники симуляции, проверки моделей и “символического”
исполнения (предполагает использование модулей-“заглушек” с точки зрения
выполняемой
логики
при
рассмотрении
общего
сценария
поведения
многомодульных систем).
В зависимости от организации ведения проекта, определенные работы по
тестированию могут выполняться при разработке программных систем в
процессах управления качеством и процессах верификации и аттестации.
4.4 Стандартизация качества программного обеспечения
4.4.1 Стандарты в сфере программной инженерии
Реальное применение любой технологии проектирования, разработки и
сопровождения ИС в конкретной организации и конкретном проекте невозможно
без выработки ряда стандартов (правил, соглашений), которые должны
соблюдаться всеми участниками проекта. К таким стандартам относятся
следующие:
– стандарт проектирования;
– стандарт оформления проектной документации;
– стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
– набор
необходимых
моделей
(диаграмм)
на
каждой
стадии
проектирования и степень их детализации;
– правила фиксации проектных решений на диаграммах, в том числе:
правила именования объектов (включая соглашения по терминологии), набор
атрибутов для всех объектов и правила их заполнения на каждой стадии, правила
оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
– требования к конфигурации рабочих мест разработчиков, включая
настройки операционной системы, настройки CASE-средств, общие настройки
проекта и т. д.;
– механизм обеспечения совместной работы над проектом, в том числе:
правила интеграции подсистем проекта, правила поддержания проекта в
одинаковом для всех разработчиков состоянии (регламент обмена проектной
информацией, механизм фиксации общих объектов и т.д.), правила проверки
проектных решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
– комплектность, состав и структуру документации на каждой стадии
проектирования;
– требования к ее оформлению (включая требования к содержанию
разделов, подразделов, пунктов, таблиц и т.д.),
– правила
подготовки,
рассмотрения,
согласования
и
утверждения
документации с указанием предельных сроков для каждой стадии;
– требования к настройке издательской системы, используемой в качестве
встроенного средства подготовки документации;
– требования к настройке CASE-средств для обеспечения подготовки
документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
– правила оформления экранов (шрифты и цветовая палитра), состав и
расположение окон и элементов управления;
– правила использования клавиатуры и мыши;
– правила оформления текстов помощи;
– перечень стандартных сообщений;
– правила обработки реакции пользователя.
4.4.2 Стандартизация программных продуктов в ЕСПД
В процессе стандартизации вырабатываются нормы, правила, требования,
характеристики, касающиеся объекта стандартизации, которые оформляются в
виде нормативного документа.
Документирование разработки, сопровождения и эксплуатации программ
выполняют в соответствии с группой стандартов ГОСТ 19.ХХХ-ХХ.
Предусматривается построение обозначений стандартов в следующем
порядке:
– номер 19 – класс стандартов ЕСПД;
– после 19 ставится точка и далее одна цифра – код классификационной
группы стандартов, определенной группы стандартов;
– далее идет двузначное число – порядковый номер стандарта в группе;
– через тире за ним ставится двузначное число – год регистрации стандарта.
Ниже
приведены
государственные
стандарты
на
компоненты,
стандартизируемой продукции.
ГОСТ 19.101—77, введен с 1981 г. Виды программ и программных
документов.
ГОСТ 19.102—77. Стадии разработки.
ГОСТ 19.103—77. Обозначения программ и программных продуктов.
ГОСТ 19.104—78, введен с 1981 г. Основные надписи.
ГОСТ 19.105—78, введен с 1981 г. Общие требования к программным
документам.
ГОСТ 19.106—78, введен с 1981 г. Требования к программным документам,
выполненным печатным способом.
ГОСТ 19.201—78, введен с 1981 г. ТЗ. Требования к содержанию и
оформлению.
ГОСТ 19.202-78. Спецификация.
ГОСТ 19.301—79, введен с 1983 г. Программа и методика испытаний.
ГОСТ 19.401—78, введен с 1983 г. Текст программы.
ГОСТ 19.402—78, введен с 1981 г. Описание программы.
ГОСТ 19.403—79. Ведомость держателей подлинников.
ГОСТ 19.404—79. Пояснительная записка.
ГОСТ 19.501-78. Формуляр.
ГОСТ 19.502—78, введен с 1981 г. Описание применения.
ГОСТ 19.503—79, введен с 1981 г. Руководство системного программиста.
ГОСТ 19.504—79, введен с 1981 г. Руководство программиста.
ГОСТ 19.505—79, введен с 1981 г. Руководство оператора.
ГОСТ 19.506—79, введен с 1981 г. Описание языка.
ГОСТ 19.507—79, введен с 1981 г. Ведомость эксплуатационных
документов.
ГОСТ 19.508—79. Руководство по техническому обслуживанию.
ГОСТ 19.601—78. Общие правила дублирования, учета и хранения.
ГОСТ 19.602—78. Правила дублирования, учета и хранения программных
документов, выполненным печатным способом.
ГОСТ 19.603—78, введен с 1981 г. Общие правила внесения изменений.
ГОСТ 19.604—78, введен с 1981 г. Правила внесения изменений в
программные документы, выполненные печатным способом.
ГОСТ 19.701—90, введен с 1992 г. Схемы алгоритмов, программ, данных и
систем.
Стандартизация помогла унифицировать и автоматизировать процесс
создания программ на базе инструментальных и программных средств, создать
системы
автоматизированного
программирования
с
использованием
инструментальных и программных средств. К настоящему времени АС позволяют
унифицировано выполнять следующие процессы:
– анализ задачи, разбиение её на подзадачи;
– анализ структур данных;
– запись требований к программе и разработку ее общей структуры;
– выделение
модулей,
написание
их
спецификаций,
определение
интерфейса между ними;
– вычерчивание блок-схем алгоритмов;
– непосредственно программирование (кодирование);
– отладку и тестирование;
– анализ качества и количества затраченного труда на разработку ПС.
Стандартизация улучшает контроль и регламентацию труда программистов,
поэтому иногда она встречает у них психологический барьер.
4.4.3 Виды стандартных программных документов
Программные документы и их содержание:
– спецификация – перечень и назначение всех файлов ПС, включая файлы
документации;
– ведомость держателей подлинников – список предприятий, хранящих
подлинники программных документов, составляется только для сложных ПС;
– текст программы – запись кодов программы и комментарии к ним;
– описание
программы
функционировании программы;
–
информация
о
логической
структуре
и
– программа и методика испытаний – перечень и описание требований,
которые должны быть проверены в ходе испытания программы, методы контроля;
– техническое задание – документ, в котором излагаются назначение и
область применения программы, требования к ПС, стадии и сроки разработки,
виды испытаний;
– пояснительная записка – обоснование принятых и примененных
технических и технико-экономических решений, схемы и описание алгоритмов,
общее описание работы ПС.
К программным документам отнесены также документы, обеспечивающие
функционирование и эксплуатацию программ – эксплуатационные документы:
– ведомость
эксплуатационных
документов
–
содержит
список
эксплуатационных документов на ПС, к которым относятся формуляр, описание
применения, руководство системного программиста, руководство программиста,
руководство
оператора,
описание
языка,
руководство
по
техническому
обслуживанию;
– формуляр – содержит основные характеристики ПС, состав и сведения об
эксплуатации программы;
– описание применения – содержит информацию о назначении и области
применения ПИ, ограничениях при применении, классе и методах решаемых
задач, конфигурации технических средств;
– руководство системного программиста – содержит сведения для
проверки,
настройки
и
функционирования
программы при конкретном
применении;
– руководство программиста – содержит сведения для эксплуатации ПС;
– руководство оператора – содержит подробную информацию для
пользователя, обеспечивающую его общение с ЭВМ в процессе выполнения ПС;
– описание языка – содержит синтаксис и семантику языка;
– руководство по техническому обслуживанию – содержит сведения для
применения
тестовых
технических средств.
и
диагностических
программ
при
обслуживании
Необходимость составления остальных документов устанавливается при
разработке и утверждении технического задания (ТЗ).
Допускается объединять отдельные виды эксплуатационных документов.
Например,
часто
разрабатывают
документ,
называемый
«Руководство
пользователя», в который включают различные сведения из руководства
системного программиста, руководства программиста и оператора. «Руководство
пользователя» должно учитывать все требования инструкций, необходимых
пользователю и содержать, как правило, общие сведения о ПС, описание
установки и запуска, подробные инструкции по работе, т. е. описание режимов
работы, форматов ввода-вывода информации, различных настроек и другой
необходимой информации для пользователя.
Большую роль для унификации при программировании играет стандарт
ГОСТ 19.701-90 (ИСО 5807-85) «Схемы алгоритмов, программ, данных и
систем», где приведены условные обозначения в схемах алгоритмов, программ,
данных и систем, устанавливаются правила выполнения схем для решения
различных задач. В этом стандарте описаны последовательности описания схем:
– данных (отображают путь данных, этапы обработки, носители);
– программы (отображают последовательность операций в программе);
– работы системы (отображают управление операциями и поток
– данных в системе);
– взаимодействия программ (отображают путь активаций программ и
взаимодействий с соответствующими данными);
– ресурсов системы (отображают конфигурацию блоков: данных и
обрабатывающих).
Виды программных документов и их содержание
Код Вид программного
документа
Спецификация
05 Ведомость
держателей
подлинников
12 Текст программы
13 Описание
программы
51 Программа и
методика
Содержание программного документа
Состав программы и документации на нее
Перечень предприятий, на которых хранят подлинники
программных документов
Запись программы с необходимыми комментариями
Сведения о логической структуре и функционировании
программы
Требования, подлежащие проверке при испытании программы, а
также порядок и методы их контроля
Код Вид программного
документа
испытаний
Техническое
задание
81
-
Пояснительная
записка
Эксплуатационные
документы
Содержание программного документа
Назначение и область применения программы, технические,
технико-экономические и специальные требования,
предъявляемые к программе, необходимые стадии и сроки
разработки, виды испытаний
Схема алгоритма, общее описание алгоритма и (или)
функционирования программы, а также обоснование принятых
технических и технико-экономических решений
Сведения для обеспечения функционирования и эксплуатации
программы
Виды эксплуатационных документов и их содержание
Код Вид
Содержание эксплуатационного документа
эксплуатационного
документа
20 Ведомость
Перечень эксплуатационных документов на программу
эксплуатационных
документов
30 Формуляр
Основные характеристики программы, комплектность и сведения
об эксплуатации программы
31 Описание
Сведения о назначении программы, области применения,
применения
применяемых методах, классе решаемых задач, ограничениях для
применения, минимальной конфигурации технических средств
32 Руководство
Сведения для проверки, обеспечения функционирования и
системного
настройки программы на условия конкретного применения
программиста
33 Руководство
Сведения для эксплуатации программы
программиста
34 Руководство
Сведения для обеспечения процедуры общения оператора с
оператора
вычислительной системой в процессе выполнения программы
35 Описание языка
Описание синтаксиса и семантики языка
46 Руководство по
Сведения для применения тестовых и диагностических программ
техническому
при обслуживании технических средств
обслуживанию
4.4.4 Действующие международные стандарты в сфере разработки
программных средств и информационных технологий
1
ISO/IEC
90003:2004.
Техника
программного
обеспечения.
Рекомендации по применению ISO 9001:2000 к компьютерному программному
обеспечению.
2
ISO/IEC
15504-1:2004.
Информационные
процессов. Часть 1. Общие понятия и словарь.
технологии.
Оценка
3
ISO/IEC
15504-2:2003.
Информационные
технологии.
Оценка
процессов. Часть 2. Выполнение оценки
4
ISO/IEC 15504-3:2004. Информационные технологии. Оценка процесса.
Часть 3. Руководство по выполнению оценки.
5
ISO/IEC 15504-4:2004. Информационные технологии. Оценка процесса.
Часть 4. Руководство для усовершенствования процессов и определения их
результативности.
6
ISO/IEC TR 15504-5:1999. Информационные технологии. Оценка
процессов программного обеспечения. Часть 5. Оценочная модель и руководящие
указания по индикации.
7
оценка
ISO/IEC 14756:1999. Информационные технологии. Измерение и
эксплуатационных
характеристик
автоматизированных
систем
программного обеспечения.
8
ISO/IEC TR 14759:1999. Разработка программного обеспечения. Макет
и прототип. Категоризация моделей макета и прототипа программного
обеспечения и их применение.
9
ISO/IEC TR 12182:1998. Информационные технологии. Классификация
программного обеспечения
10 ISO/IEC
12207:1995.
Информационные
технологии.
Процессы
жизненного цикла программного обеспечения.
11 ISO/IEC TR 15271:1998. Информационные технологии. Руководство по
применению ISO/IEC 12207 (Процессы жизненного цикла программных средств).
12 ISO/IEC TR 16326:1999. Разработка программного обеспечения.
Руководство по применению ISO/IEC 12207 к управлению проектом.
13 ISO/IEC
12207:1995/Amd.1:2002.
Информационные
технологии.
Процессы жизненного цикла программного обеспечения. Изменение 1
14 ISO/IEC
12207:1995/Amd.2:2004.
Информационные
технологии.
Процессы жизненного цикла программного обеспечения. Изменение 2.
15 ISO/IEC
16085:2004.
Информационные
технологии.
жизненного цикла программного обеспечения. Управление рисками.
Процессы
16 ISO/IEC
TR
19759:2005.
Совокупность
знаний
о
разработке
программного обеспечения. Руководство.
17 ISO/IEC 15026:1998. Информационные технологии. Системные и
программные уровни целостности.
18 ISO/IEC
25000:2005.
Технология
программного
обеспечения.
Требования и оценка качества программного продукта. Руководство.
19 ISO/IEC 9126-1:2001. Программная инженерия. Качество продукта.
Часть 1. Модель качества.
20 ISO/IEC TR 9126-2:2003. Программная инженерия. Качество продукта.
Часть 2. Внешние метрики.
21 ISO/IEC TR 9126-3:2003. Программная инженерия. Качество продукта.
Часть 3. Внутренние метрики.
22 ISO/IEC TR 9126-4:2004. Программная инженерия. Качество продукта.
Часть
4.
Показатели
качества
в
использовании.ISO/IEC
12119:1994.
Информационные технологии. Пакеты программ. Требования к качеству и
тестирование.
23 ISO/IEC
14598-1:1999.
Информационные
технологии.
Оценка
программного продукта. Часть 1. Общий обзор.
24 ISO/IEC 14598-2:2000. Разработка программного обеспечения. Оценка
программного продукта. Часть 2. Планирование и руководство.
25 ISO/IEC 14598-3:2000. Разработка программного обеспечения. Оценка
программного продукта. Часть 3. Процесс для разработчиков.ISO/IEC 145984:1999. Разработка программного обеспечения. Оценка продукта. Часть 4.
Процесс для закупщика.
26 ISO/IEC
14598-5:1998.
Информационные
технологии.
Оценка
программного продукта. Часть 5. Процесс для оценщика.
27 ISO/IEC 14598-6:2001. Разработка программного обеспечения. Оценка
продукта. Часть 6. Документирование модулей оценки
28 ISO/IEC 15939:2002. Технология программного обеспечения. Процесс
измерения программного обеспечения
29 ISO/IEC
TR
9294:2005.
Руководство
по
управлению
документированием программного обеспечения.
30 ISO/IEC 15910:1999. Информационные технологии. Процесс создания
документации пользователя программного обеспечения.
31 ISO/IEC 18019:2004. Программное обеспечение и системотехника.
Рекомендации по проектированию и подготовке документации пользователя для
прикладного программного обеспечения.
32 ISO/IEC
6592:2000.
Информационные
технологии.
Руководящие
указания по разработке документации на компьютерные прикладные системы.
33 ISO 9127:1988. Системы обработки информации. Документация
пользователя
и
сопроводительная
информация
программных
пакетов
потребителя.
34 ISO/IEC 14764:1999. Информационные технологии. Сопровождение
программного обеспечения.
35 ISO/IEC TR 15846:1998. Информационные технологии. Процессы
жизненного цикла программного обеспечения. Управление конфигурацией.
36 ISO/IEC 15408-1:2005. Информационные технологии. Методы защиты.
Критерии оценки для информационных технологий. Часть 1. Введение и общая
модель.
37 ISO/IEC 15408-2:1999. Информационные технологии. Методы и
средства
обеспечения
информационных
безопасности.
технологий.
Часть
Критерии
2.
оценки
безопасности
Функциональные
требования
безопасности.
38 ISO/IEC 15408-3:1999. Информационные технологии. Методы защиты.
Критерии
оценки
безопасности
информационных
технологий.
Часть
3.
Требования к обеспечению защиты.
39 ISO/IEC 13335-1:2004. Информационные технологии. Способы защиты.
Управление защитой информационных и коммуникационных технологий. Часть
1.
Понятия
и
модели
для
коммуникационных технологий.
управления
защитой
информационных
и
40 ISO/IEC TR 13335-3:1998. Информационные технологии. Руководящие
указания по управлению защитой информационных технологий. Часть 3. Методы
управления защитой информационных технологий.
41 ISO/IEC
TR
13335-4:2000.
Информационные
технологии
(ИТ).
Руководящие указания по управлению защитой ИТ. Часть 4. Выбор защитных
мер.
42 ISO/IEC
TR
13335-5:2001.
Информационные
технологии
(ИТ).
Руководящие указания по управлению защитой ИТ. Часть 5. Административное
руководство по обеспечению безопасности сетей.
43 ISO/IEC
14143-1:1998.
Информационные
технологии.
Оценка
программного обеспечения. Измерение функционального размера. Часть 1.
Определение понятий.
44 ISO/IEC
14143-2:2002.
Информационные
технологии.
Оценка
программного обеспечения. Измерение функционального размера. Часть 2.
Оценка соответствия методов измерения размера программного обеспечения
стандарту ИСО/МЭК 14143-1:1998.
45 ISO/IEC TR 14143-3:2003. Информационные технологии. Оценка
программного обеспечения. Измерение функционального размера. Часть 3.
Проверка методов измерения функционального размера.
46 ISO/IEC TR 14143-4:2002. Информационные технологии. Оценка
программного обеспечения. Измерение функционального размера. Часть 4.
Эталонная модель.
47 ISO/IEC TR 14143-5:2004. Информационные технологии. Оценка
программного обеспечения. Измерение функционального размера. Часть 5.
Определение
функциональных
доменов,
используемых
для
измерения
функционального размера.
48 ISO/IEC 2382-20:1990. Информационные технологии. Словарь. Часть
20. Разработка системы.
49 ISO/IEC 8211:1994. Информационные технологии. Спецификация
описательного файла данных для обмена информацией.
50 ISO/IEC 14102:1995. Информационные технологии. Руководство по
оцениванию и выбору инструментальных CASE-средств.
4.5 Документирование программных средств
4.6 Сертификация программных средств
4.6.1 Правовые акты по сертификации программных продуктов
Прежде всего, программист должен хорошо знать действующие в стране
законы, регламентирующие области работ, с которыми он соприкасается. Ему
должны быть хорошо известны основные положения следующих федеральных
законов:
1. «О сертификации продукции и услуг» от 27 апреля 1993 г. № 5151-1 (в
ред. от 27 декабря 1995г. № 211-ФЗ; от 2 марта 1998 г. № 30-ФЗ; от 31 июля 1998
г. № 154-ФЗ);
2. «Об информации, информатизации и защите информации» от 20 февраля
1995 г. № 24-ФЗ;
3. «О правовой охране программ для электронных вычислительных машин и
баз данных» от 23 сентября 1992 г. № 3523-1;
4. «Об участии в международном информационном обмене» от 4 июля 1996
г. № 85-ФЗ;
5. «Об авторском праве и смежных правах» от 9 июля 1993 г. № 5351-1 (в
ред. от 19 июля 1995 г. № 110-ФЗ).
В соответствии со первым законом «сертификация продукции (далее –
сертификация) – процедура подтверждения соответствия, посредством которой
независимая от изготовителя (продавца, исполнителя) и потребителя (покупателя)
организация удостоверяет в письменной форме, что продукция соответствует
установленным требованиям».
Сертификация осуществляется в целях:
 содействия потребителям в компетентном выборе продукции;
 зашиты потребителя от недобросовестности изготовителя (продавца,
исполнителя);
 контроля безопасности продукции для окружающей среды, жизни,
здоровья и имущества;
 подтверждения
показателей
качества
продукции,
заявленных
изготовителем.
Сертификация может иметь обязательный и добровольный характер».
Обязательная сертификация проводится в случаях, предусмотренных
законодательными актами РФ. Организация и проведение работ по обязательной
сертификации возложены на Госстандарт России и другие федеральные органы
исполнительной власти РФ.
Добровольная
(изготовителей,
сертификация
продавцов,
проводится
исполнителей)
для
по
инициативе
того,
чтобы
заявителей
подтвердить
соответствие продукции требованиям стандартов, технических условий и других
документов, определяемых заявителем. Проводится она на условиях договора
между заявителем и органом по сертификации.
Во втором законе определены основные принципы разработки, производства,
сертификации и лицензирования информационных систем, технологий и средств их
обеспечения (а следовательно и ПО).
В третьем законе установлены многие основные понятия и определения
создания и использования программ. Например, программа для ЭВМ определяется
как «объективная форма представления совокупности данных и команд,
предназначенных для функционирования ЭВМ и других компьютерных устройств с
целью
получения
определенного
результата,
включая
подготовительные
материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею
аудиовизуальные отображения». База данных определяется как «объективная форма
представления и организации совокупности данных, систематизированных таким
образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ».
В четвёртом законе определен правовой режим участия в международном
информационном обмене и установлены правила контроля и ответственности при
осуществлении международного информационного обмена.
В пятом законе даны основные понятия авторского права, правила
использования и зашиты авторских произведений, в том числе программ для
ЭВМ. В ст. 25 этого закона «Свободное воспроизведение программ для ЭВМ и
баз данных. Декомпилирование программ для ЭВМ» описаны условия, при
которых можно использовать программу без получения разрешения автора или
иного обладателя прав на нее. Это только лица, правомерно владеющие экземпляром программы для ЭВМ или БД. Ни при каких обстоятельствах не должны
быть
ущемлены
законные
интересы
автора
или
иного
обладателя
исключительных прав на программу для ЭВМ или БД.
4.6.2 Сертификация ПС
Имеется два сертификационных документа: сертификат соответствия и знак
соответствия.
Сертификат соответствия – это документ, выданный по правилам системы
сертификации для подтверждения соответствия сертифицированной продукции
установленным требованиям.
Знак соответствия – это зарегистрированный в установленном порядке знак,
которым по правилам определенной системы сертификации подтверждается
соответствие маркированной им продукции установленным требованиям
Система сертификации – совокупность участников сертификации, которые
проводят сертификацию продукции по устанавливаемым в этой системе
определенным правилам в соответствии с законом. Система сертификации
создается федеральными органами исполнительной власти.
Сертификация включает следующие этапы:
1. подача заявки на сертификацию;
2. рассмотрение и принятие решения по заявке;
3. проведение необходимых проверок (анализ документов, испытания,
проверка и т. п.);
4. анализ полученных результатов и принятие решения о возможности
выдачи сертификата соответствия;
5. выдача сертификата и лицензии (разрешения) на применение знака
соответствия;
6. инспекционный
контроль
соответствии со схемой сертификации.
за
сертифицированным
объектом
в
Все данные, в том числе выявленные несоответствия, полученные при
анализе документации ПО, заносятся в протоколы испытаний. Перечень
документов, сопровождающих ПО, объем и методы проверки документации
могут корректироваться соглашением между исполнителем и заказчиком
аттестации ПО.
В соответствии со ст. 21 Федерального закона «О техническом
регулировании» орган по сертификации:
 осуществляет подтверждение соответствия объектов добровольного
подтверждения соответствия, в том числе при необходимости создает или
привлекает на договорной основе испытательные лаборатории, в которых
организует проведение испытаний ПО (ПП) по согласованным с заказчиком
методикам;
 выдает
Сертификаты
соответствия
на
объекты,
прошедшие
добровольную сертификацию;
 предоставляет заявителю право на применение знака соответствия;
 приостанавливает
или
прекращает
действие
выданных
им
Сертификатов соответствия.
Испытательные лаборатории выполняют следующие функции:
 проводят испытания ПО (ПП) по согласованным с заказчиком
методикам;
 оформляют результаты испытаний соответствующими протоколами, на
основании которых орган по сертификации принимает решение о выдаче или об
отказе в выдаче Сертификатов соответствия.
Схема сертификации – определенная совокупность действий, официально
принимаемая в качестве доказательства соответствия продукции заданным
требованиям.
4.6.3 Перечень объектов, подлежащих сертификации и их
характеристики
Объектами, подлежащими добровольной сертификации, являются:
 программное обеспечение средств измерений как автономное, так и
встроенное;
 программное
обеспечение
измерительных
и
информационно-
измерительных систем;
 программное обеспечение контроллеров и вычислительных блоков, не
входящих в состав информационно-измерительных систем.
Каждая позиция в перечне программного обеспечения (программных
продуктов), подаваемом заявителем для прохождения процедуры добровольной
сертификации, должна содержать следующую информацию:
 описание структуры ПО (ПП) и выполняемых функций, в том числе
последовательность обработки данных;
 описание
функций
и
параметров
ПО
(ПП),
подлежащих
метрологическому контролю;
 описание реализованных в ПО (ПП) расчетных алгоритмов, а также их
блок-схемы;
 описание модулей ПО (ПП);
 перечень интерфейсов и перечень команд для каждого интерфейса,
включая заявление об их полноте;
 список, значение и действие всех команд, получаемых от клавиатуры,
мыши и других устройств ввода;
 описание реализованной методики идентификации ПО (ПП);
 описание реализованных методов защиты ПО (ПП) и данных;
 описание интерфейсов пользователя, всех меню и диалогов;
 описание хранимых или передаваемых наборов данных;
 руководство пользователя;
 характеристики требуемых системных и аппаратных средств, если эта
информация не приведена в руководстве пользователя.
Перечень документов, сопровождающих ПО (ПП), может корректироваться
соглашением между исполнителем и заказчиком сертификации ПО.
Графическая и текстовая информация в документации выполняется таким
образом, чтобы она была пригодна для полного и однозначного понимания.
Характеристиками ПО СИИИС, подлежащими процедуре добровольного
подтверждения
соответствия,
являются
характеристики,
являющиеся
количественными
или
качественными
представлениями
требований,
предъявляемых к ПО (ПП) и устанавливаемых НД ПО, а именно:
а) требований к структуре, т.е. к выделению частей, подлежащих
метрологическому
контролю,
а
также
к
наличию
и
правильности
функционирования защищенных интерфейсов;
б) требований к идентификации;
в) требований к защите измерительной и иной хранимой и передаваемой
информации;
г) требований
к
соответствию
характеристик
тем,
которые
были
установлены и приписаны ПО (ПП) при испытаниях СИ и других устройств с
целью утверждения типа;
д) требований к степени влияния на метрологические и информационные
характеристики средств измерений, информационно-измерительных систем.
Для
подтверждения
гарантий
обеспечения
соответствия
ПО
(ПП)
установленным СДС ПО СИИИС требованиям в любой период деятельности
заявителя в организации (фирме) должна быть организована документально
оформленная Система контроля ПО СИИИС.
Заключение
Библиография
1. Макконнелл Стив Влияние итеративных подходов на предварительные
условия // Совершенный код (пер. с англ.). — СПб.: Русская Редакция, Питер,
2005. - 896 с.
2. Страуструп
Бьярн
Программирование.
Принципы
и
практика
использования C++ (пер. с англ.) – М.: Вильямс, 2011. – 1136 с.
3. Библиография
4. В.В. Липаев. Программная инженерия. Методологические основы. М.:
Теис, 2006 - 608 стр.
5. ГОСТ Р ИСО/МЭК ТО 16326-2002
6. ГОСТ Р ИСО/МЭК 12207-99
7. Орлик Сергей. Основы Программной Инженерии (по SWEBOK)
http://swebok.sorlik.ru/software_engineering.html
8. Соммервилл Иан. Инженерия программного обеспечения Издательство:
Вильямс 2002 г.
9. [Ambler, 2004] - Scott W. Ambler. One Piece at a Time. Software
Development Magazine, December 2004. http://www.sdmagazine.com/
10.[Ambler, 2005] - Scott W. Ambler, John Nalbone, Michael J. Vizdos. The
Enterprise Unified Process: Extending the Rational Unified Process. Prentice Hall PTR
(ISBN 0-13-191451-0) 2005
11.[APM PMBoK, 2000] - Project Management Body of Knowledge. Fourth
Edition. Association of Project Management, 2000. http://www.apm.org.uk/
12.[Boehm, 1988] – Barry W. Boehm. A Spiral Model of Software Development
and
Enhancement,
Computer,
May
1988,
pp.
61-72.
http://www.computer.org/computer/homepage/misc/Boehm/index.htm
13.[Boehm, 2000] – Barry W. Boehm. Spiral Development: Experience,
Principles, and Refinements. Spiral Experience Workshop, February 9, 2000 / Special
Report.
CMU/SEI-2000-SR-008,
http://www.sei.cmu.edu/cbs/spiral2000/Boehm
July,
2000.
14.[Chaos, 2004] – CHAOS Research Results. 2004 Third Quarter Research
Report. The Standish Group International, Inc., 2004.
15.[CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1.
[CMMI 1.1, 2002] - Capability Maturity Model Integration, Version 1.1. CMMISM for
Systems Engineering, Software Engineering, Integrated Product and Process
Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1).Software
Engineering
Institute
(SEI),
Carnegie
Mellon
University
(CMU),
2002.
http://www.sei.cmu.edu/cmmi/
16.[DeMarco, 1999] – The Paradox of Software Architecture and Design”,
Stevens Prize Lecture, August, 1999.
17.[E-Gov, 2002] – E-Gov Enterprise Architecture Guidance (Common
Reference
Model),
FEA
Working
Group
(Draft),
July
25,
2002].
http://www.feapmo.gov/resources/E-Gov_Guidance_Final_Draft_v2.0.pdf
18.[Fred Brooks, 1987] – Классическая статья Фреда Брукса (Frederick P.
Brooks, Jr.), заставившая по-новому взглянуть индустрию программного
обеспечения на самою себя. - No Silver Bullet: Essence and Accidents of Software
Engineering.
IEEE
Computer,
April,
1987.
http://www.computer.org/computer/homepage/misc/Brooks/
19.[PMBOK US DoD Ext, 2003] - U.S. Department of Defense (DoD) Extension
to: A Guide to the Project Management Body of Knowledge (PMBOK Guide). First
Edition, Version 1.0. PMI Standard. The Defense Acquisition University (DAU), June,
2003. http://www.dau.mil/pubs/gdbkspmbok.asp
20.[PMI PMBOK, 2000] – A Guide to the Project Management Body of
Knowledge. (PMBOK® Guide). Second Edition. Project Management Institute, Inc.,
2000. http://www.pmi.org/
21.[PMI PMBOK3, 2004] – A Guide to the Project Management Body of
Knowledge. (PMBOK® Guide). Third Edition. Project Management Institute, Inc.,
2004. http://www.pmi.org/
22.[PMI PMBOK3, 2004, Рус] – Руководство к Своду знаний по управлению
проектами. (Руководство PMBOK®). Третье издание. Издание на русском языке.
Project Management Institute, Inc., 2004. http://www.pmi.org/
23.[PMI WBS, 2001] - Practice Standard for Work Breakdown Structures.
Project Management Institute, Inc., 2001. http://www.pmi.org/
24.[SE, 2004] - Software Engineering 2004. Curriculum Guidelines for
Undergraduate Degree Programs in Software Engineering. A Volume of the Computing
Curricula Series. The Joint Task Force on Computing Curricula, IEEE Computer
Society,
Association
for
Computing
Machinery,
August
23,
2004.
http://sites.computer.org/ccse/
25.[SWEBOK, 2004] - Guide to Software Engineering Base of Knowledge
(SWEBOK). IEEE Computer Society, 2004. http://www.swebok.org/
26.[TOGAF, 2003] – The Open Group Architecture Framework (TOGAF).
Version
8.1
The
Open
Group,
2003.
http://www.opengroup.org/architecture/togaf8/index8.htm
27.[Zachman] – The Zachman Framework for Enterprise Architecture, John A.
Zachman, ZIFA - Zachman Institute for Framework Advancement. http://www.zifa.com
28.[Амблер, 2002] – Скотт Амблер. Гибкие технологии: экстремальное
программирование и унифицированный процесс разработки. Wiley (ISBN 0-47120282-7), 2002 - Scott W. Ambler, Agile Modeling: Effective Practices for Extreme
Programming, 2002; перевод и издание на русском языке: ЗАО Издательский дом
“Питер” (ISBN 5-94723-545-5), 2005
29.[Арчибальд, 2003] – Рассел Д. Арчибальд. Управление высокотехнологичными программами и проектами. Издание третье, переработанное и
дополненное. John Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russel D.
Archibald, 2003; перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3)
- ДМК Пресс (ISBN 5-94074-214-9) 2004.
30.[Арчибальд, 2005] – Рассел Д. Арчибальд. Искусство управления
проектами: состояние и перспективы. Возможности и уровень зрелости
организации в управлении проектами.
31.Информационно-аналитический журнал “Управление проектами”, N1
(1), март 2005, стр. 14-23. http://www.pmmagazine.ru
32.[Брукс, 1995] – Фредерик Брукс. Мифический человеко-месяц или как
создаются программные системы. 2-е издание, юбилейное. Addison-Wesley
Longman, Inc. (ISBN 0-201-83595-9), 1995.Издательство Символ-Плюс (ISBN 593286-005-7), 2000, 2005.
33.[Вигерс, 2003] – Карл И. Вигерс. Разработка требований к программному
обеспечению. Издательско-торговый дом “Русская редакция”, перевод на русский
язык второй редакции книги – Microsoft Corporation (ISBN 5-7502-0240-2), 2004.
Оригинальное издание на английском языке: Software Requirements. Second
Edition. Karl E. Wiegers, Microsoft Press (ISBN 0-7356-1879-8), 2003.
34.[Грей и Ларсон, 2003] – Клиффорд Ф. Грей, Эрик У. Ларсон. Управление
проектами: Практическое русководство. Издательство “Дело и Сервис” (ISBN 58018-0152-9), 2003. The McGraw-Hill Companies, Inc. (ISBN 0-07-365812-X), 2000.
35.[ГОСТ
12207,
1999]
–
Информационная
технология.
Процессы
Жизненного Цикла Программных Средств. ГОСТ Р ИСО/МЭК 12207-99,
Государственный Стандарт Российской Федерации, 1999. Госстандарт России,
Москва, 2000.
36.[ГОСТ 34, 1990] – Информационная технология. Комплекс стандартов и
руководящих
документов
определения.
ГОСТ
на
автоматизированные
34.003-90,
Государственный
системы.
Стандарт
Термины
и
Российской
Федерации, 1999. Госстандарт России, Москва, 1990.
37.[Кантор, 2002] – Марри Кантор. Управление программными проектами.
Практическое руководство по разработке успешного программного обеспечения.
Издательский дом “Вильямс” (ISBN 5-8459-0294-0), 2002. Addison Wesley (ISBN
0-2017-0044-1), 2002.
38.[СОВНЕТ НТК, 2000] - Национальные требования к компетентности
специалистов по Управлению Проектами (НТК). Ассоциация по Управлению
Проектами СОВНЕТ, 2000. http://www.sovnet.ru/ntk2000/index.php
39.
[Товб А., Ципес Г., 2003] – А.С. Товб, Г.Л. Ципес. Управление
проектами: стандарты, методы, опыт. Второе издание. Товб А.С., Ципес Г.Л., 2003
– ЗАО “Олимп-Бизнес” (ISBN 5-9693-0038-1) 2003, 2005.
40.
[Фатрелл, Шафер и Шафер, 2003] – Роберт Т. Фатрелл, Дональд Ф.
Шафер, Линда И. Шафер. Управление программными проектами: достижение
оптимального качества при минимуме затрат. Издательский дом “Вильямс” (ISBN
5-8459-0413-7), 2003. Addison-Wesley Publishing Company, Inc. (ISBN 0-13-0912972), 2002.
41.
[Фаулер, 2004] – Мартин Фаулер. UML. Основы. Краткое руководство
по стандартному языку объектного моделирования. 3-е издание. Издательство
“Символ-Плюс” (ISBN 5-93286-060-X), Санкт-Петербург, 2004.