Лекция 1

Введение в учебный курс

Цели и задачи учебного курса.

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

Цель учебной дисциплины: освоение методов и технологических средств

проектирования и эксплуатации информационных систем различных классов или
внедрения готовых решений, имеющихся на рынке.
Задачи:
— изучение технологической среды обработки информации на предприятии;
— изучение информационных потоков внутри предприятия;
— изучение информационных потоков, поступающих извне;
— изучение методологических основ проектирования информационных
систем;
— изучение технологических средств проектирования информационных
систем;
— изучение существующих программных и технических средств
информационных систем;
— разработка технической документации по функциональной части
информационных систем;
— разработка информационных сервисов информационных систем;
— изучение порядка внедрения эксплуатации информационных систем;
— изучение экономических аспектов внедрения и эксплуатации
информационных систем.

Понятие программной инженерии.

На современном этапе своего развития разработка программного
обеспечения (ПО) превратилась в целую индустрию, охватывающую такие
аспекты, как управление проектами и персоналом, работа с требованиями,
проектирование программного обеспечения, непосредственно написание
программного кода, его оптимизация, оценка качества выполняемых работ,
дальнейшее сопровождение программного продукта.
Поэтому сегодня имеет смысл вести речь об инженерии программного
1
обеспечения, или программной инженерии (научной дисциплине, охватывающей
все аспекты жизненного цикла программного продукта). Говоря проще,
программная инженерия – это деятельность, связанная с созданием
(производством) программного обеспечения.
Программная инженерия включает в себя следующие десять областей знаний:
1) требования (software requirements);
2) проектирование (software design);
3) конструирование (software construction);
4) тестирование (software testing);
5) поддержка и эксплуатация (software maintenance);
6) конфигурационное управление (software configuration management);
7) управление инженерной деятельностью (software engineering management);
8) процессы инженерной деятельности (software engineering process);
9) инженерные инструменты и методы (software engineering tools and methods);
10) качество (software quality).

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

Виды программного обеспечения по назначению

Существует три основных типа программного обеспечения:
системное (называемое также общим)
прикладное (называемое специальным)
инструментальное.

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

К системному ПО относятся:

Базовое ПО – самый низкий уровень ПО. Базовое ПО отвечает за

взаимодействие с базовыми аппаратными средствами. Базовое ПО в архитектуре
компьютера занимает особое положение. С одной стороны, его можно
рассматривать как составную часть аппаратных средств, с другой стороны, оно
2
является одним из программных модулей операционной системы. Базовое ПО, или
BIOS, представляет собой программу, которая отвечает за управление всеми
компонентами, установленными на материнской плате. Фактически BIOS является
неотъемлемой составляющей системной платы и поэтому может быть отнесена к
особой категории компьютерных компонентов, занимающих промежуточное
положение между аппаратурой и программным обеспечением. Функцией базового
программного обеспечения является проверка состава и работоспособности
вычислительной системы.

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

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

К дополнительным программам относится и Служебное (сервисное) ПО.

Основное назначение служебных программ (утилит) состоит в автоматизации
работ по проверке, наладке и настройке компьютерной системы.
Некоторые служебные программы (как правило, это программы
обслуживания) изначально включаются в состав ОС, но большинство служебных
программ являются для ОС внешними и служат для расширения ОС и ее функций.
Это различные сервисные программы, используемые при работе или техническом
обслуживании компьютера, — редакторы, отладчики, диагностические
программы, архиваторы, антивирусы, программы, обеспечивающие работу
компьютеров в сети и др.
Классификация служебных программных средств:
1. Средства диагностики. Предназначены для автоматизации процесса
диагностики аппаратного и программного обеспечения. Используются не только
для устранения неполадок, но и для оптимизации работы компьютерной системы.
Например, Утилита «Дефрагментация диска» позволяет данные, принадлежащие
одному файлу, объединить в одну непрерывную область данных
2. Средства сжатия данных (архиваторы). Предназначены для создания
архивов. Архивирование данных упрощает их хранение за счет того, что большая
группа файлов и каталогов сводятся в один архивный файл. Наиболее известными
архиваторами являются WinZip, WinRAR.
3. Средства обеспечения компьютерной безопасности. Это средства
пассивной и активной защиты данных от повреждения, а также средства от
несанкционированного доступа, просмотра и изменения данных.
Средства пассивной защиты – служебные программы, предназначенные для
резервного копирования (нередко они обладают базовыми свойствами
архиваторов).
Средства активной защиты – антивирусное программное обеспечение. Для
защиты данных от несанкционированного доступа, их просмотра и изменения
служат специальные системы, основанные на криптографии.
3
 4. Средства контроля (мониторинга). Они позволяют следить за процессами.
происходящими в компьютерной системе.
5. Диспетчеры файлов. Программы для выполнения большинства операций,
связанных с обслуживанием файловой системы: копирование, перемещение и
переименование файлов, создание каталогов (папок), удаление файлов и каталогов,
поиск файлов, навигация в файловой структуре. Наиболее популярными являются
Total Commander (бывший Windows Commander).
6. Мониторы установки Предназначены для контроля над установкой ПО.
7. Средства коммуникаций. Они позволяют устанавливать соединение с
удаленными компьютерами, обслуживают передачу сообщений электронной
почты, работу с телеконференциями и др

Прикладное
Наиболее обширная доля классификации. Сюда относятся графические и
текстовые редакторы, браузеры, базы данных и все, что люди используют в
привычной работе за компьютером.
Смысл этой разновидности в выполнении четко поставленной задачи:
рисовать, учитывать, набирать текст и т.д. Если утилита нужна для конкретного
выполнения действия, то она является прикладным ПО.

Примеры прикладных программных средств: Текстовые редакторы

(процессоры), Графические редакторы, Системы управления базами данных,
Электронные таблицы, Системы автоматизированного проектирования,
Настольные издательские системы, Экспертные системы, WEB-редакторы,
Браузеры, Бухгалтерские системы, Геоинформационные системы,
интегрированные системы делопроизводства, Финансовые аналитические
системы, Системы видеомонтажа и т.д.

Инструментальное
Специфическое обеспечение любой компьютерной техники. Его можно было
бы отнести к прикладному, но из-за специфики применения его выделили в
отдельный вид. Основная функция – отладка, настройка, переписывание
программного кода.
Сюда входят компиляторы, отладчики, переводчики высокого уровня,
редакторы, интерпретаторы и другие средства. Они необходимы, потому что
техника не понимает человеческих слов. Чтобы ей «объяснить», что надо сделать,
требуется специальный «машинный язык».
Постоянно пользоваться этим кодом базовым пользователям довольно
сложно, поэтому были разработаны системы, которые позволяют переводить
обычную речь в двоичную, привычную для ПК.

Классификация ПО по способу распространения и использованию

Выделяют следующие виды ПО в зависимости от того, кто им будет
пользоваться и на каких основаниях.

Бесплатно распространяемые программы (Free). Их разрешается свободно

распространять, копировать и использовать без оплаты. При этом создатель
4
компонента может брать оплату за отдельные услуги софта – копирование данных
на диск, увеличения объема памяти и другие.

Свободно распространяемое ПО (Freeware). Как и в случае с «бесплатным»

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

Adware
Само программное обеспечение распространяется бесплатно, однако автор
или распространитель приложения получает доход за счет показа рекламы. Кроме
того, внутри могут содержаться функции, которые открываются только при
условии покупки. Еще один вариант – необходимость установки дополнительных
утилит для работы.

Shareware
Для некоммерческого условно-бесплатного использования. То есть один
пользователь использует ее для личных потребностей. Для регулярного
пользования компанией любого размера предусмотрена оплата или запрет на
работу.

Trial
Скрипт без внесения финансовых средств. Ограниченно время, которое
допускает пользоваться программным обеспечением. Все функции работают в
течение 10-30 суток или 10-30 запусков. Потом потребуется ввести ключ и
оплатить.

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

Открытое ПО. ПО условиям лицензии в обязательном порядке

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

Закрытое ПО. Является частной собственностью своих авторов и

распространяется строго на определённых условиях. Это может быть, как денежное
вознаграждение, так и иные виды вознаграждений, не противоречащие
законодательству, которые разработчик может потребовать за его использование.
Например, это может быть условно бесплатное распространение, при котором для
возможности использования программы потребуется пройти регистрацию на сайте.
Как правило, распространяется без исходных кодов.

5
 Понятие, цели и задачи информационной системы
Информационная система – система, предназначенная для хранения, поиска
и обработки информации, и соответствующие организационные ресурсы
(человеческие, технические, финансовые и т.д.), которые обеспечивают и
распространяют информацию
Цель ИС – обеспечение специалистов информацией для решения стоящих
перед ними задач.
Кроме того, результатом работы ИС должно быть требуемое качество
информационной продукции. Отсюда цель ИС – это также и повышение уровня
качества информации, выдаваемой специалистам-пользователям ИС.
Основные задачи ИС
Задачи, которые решаются информационной системой (ИС), без привязки к
предметной области управления, состоят в следующем:
– создание единого информационного пространства для всех пользователей
системы, где бы они ни находились, реализация территориально распределенной
системы управления,
– разделение прав доступа к данным в соответствии с полномочиями
пользователей,
– обеспечение одновременного доступа множества пользователей к одним и
тем же данным: благодаря этому не происходит размножения экземпляров записей
данных, как в случае с «бумажной» организацией управления; поддержка
актуальности данных становится проще,
– однократность ввода данных, возможность их многократного извлечения:
тем самым исключается появление дублирующих, часто противоречащих друг
другу данных, как это зачастую бывает в отсутствие информационной системы,
– унификация форматов сбора и хранения данных: это позволяет иметь
данные, пригодные для автоматизированной обработки по определенному
алгоритму
– сокращение времени задержки получения данных в местах их
использования
– сокращение времени анализа информации: информация концентрируется
в единой базе данных, достаточно применить стандартные запросы к базе, чтобы
получить аналитическую выборку
– реализация многомерного анализа данных
– автоматизация рутинных операций, расчетов, сокращение трудозатрат
исполнителей на выполнение тех или иных функций: зачастую это позволяет
сделать наиболее трудоемкие операции реально выполнимыми (например,
перепланирование, или корректировка цен в масштабе реальной динамики их
изменения),
– отделение данных и методик управления от конкретного сотрудника
предприятия, повышение устойчивости системы управления при кадровых
изменениях,
– интеграция существующих информационных систем в единое
пространство, автоматический импорт/экспорт данных между информационными
системами.

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

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

техническое, математическое, программное, организационное и правовое
обеспечение.

Информационное обеспечение
Назначение подсистемы информационного обеспечения состоит в
своевременном формировании и выдаче достоверной информации для принятия
управленческих решений.
Информационное обеспечение — совокупность единой системы
классификации и кодирования информации, унифицированных систем
документации, схем информационных потоков, циркулирующих в организации, а
также методология построения баз данных.
Унифицированные системы документации создаются на государственном,
республиканском, отраслевом и региональном уровнях. Главная цель — это
обеспечение сопоставимости показателей различных сфер общественного
производства. Разработаны стандарты, где устанавливаются требования:
1. к унифицированным системам документации;
2. к унифицированным формам документов различных уровней управления;
3. к составу и структуре реквизитов и показателей;
4. к порядку внедрения, ведения и регистрации унифицированных форм
документов.
Построение схем информационных потоков, позволяющих выявить объемы
информации и провести ее детальный анализ, обеспечивает:
1. исключение дублирующей и неиспользуемой информации;
2. классификацию и рациональное представление информации.

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

7
 3. устройства передачи данных и линий связи;
4. оргтехника и устройства автоматического съема информации;
5. эксплуатационные материалы и др.

Математическое и программное обеспечение

Математическое и программное обеспечение — совокупность математических
методов, моделей, алгоритмов и программ для реализации целей и задач
информационной системы, а также нормального функционирования комплекса
технических средств.
К средствам математического обеспечения относятся:
1. средства моделирования процессов управления;
2. типовые задачи управления;
3. методы математического программирования, математической статистики,
теории массового обслуживания и др.

В состав программного обеспечения входят общесистемные и специальные

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

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

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

Правовое обеспечение этапов функционирования информационной системы

включает:
1. статус информационной системы.
2. права, обязанности и ответственность персонала.
3. правовые положения отдельных видов процесса управления.
4. порядок создания и использования информации и др.

9
 Лекция 2
Процессы разработки программного обеспечения

Понятие процесса разработки программного обеспечения.

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

Шаги процесса
Процесс разработки состоит из множества подпроцессов.
1. Анализ требований включает в себя сбор требований к программному
обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также
документирование.
Анализ требований включает три типа деятельности:
Сбор требований — общение с клиентами и пользователями, чтобы определить,
каковы их требования; анализ предметной области.
Анализ требований — определение, являются ли собранные требования
неясными, неполными, неоднозначными или противоречащими; решение этих проблем;
выявление взаимосвязи требований.
Документирование требований — требования могут быть задокументированы в
различных формах, таких как простое описание, сценарии использования,
пользовательские истории, или спецификации процессов (Спецификация требований
программного обеспечения — структурированный набор требований
(функциональность, производительность, конструктивные ограничения и атрибуты) к
программному обеспечению и его внешним интерфейсам. Предназначен для того,
чтобы установить базу для соглашения между заказчиком и разработчиком (или
подрядчиками) о том, как должен функционировать программный продукт).
2. Проектирование ПО
Целью проектирования является определение внутренних свойств системы и
детализации её внешних (видимых) свойств на основе выданных заказчиком требований
к ПО (исходные условия задачи). Эти требования подвергаются анализу.
Проектирование ПО включает следующие основные виды деятельности:
выбор метода и стратегии решения;
выбор представления внутренних данных;
разработка основного алгоритма;
документирование ПО;
тестирование и подбор тестов;
выбор представления входных данных.
3. Кодирование (программирование) — в обычном понимании, это
непосредственно сам процесс создания компьютерных программ.
4. Тестирование и отладка — процесс исследования, испытания программного
продукта, имеющий своей целью проверку соответствия между реальным поведением
программы и её ожидаемым поведением на конечном наборе тестов, выбранных
определённым образом.
5. Документирование — это документы, сопровождающие программное
обеспечение (ПО). Эти документы описывают то, как работает программа и/или то, как
её использовать.
1
 6. Внедрение — процесс настройки программного обеспечения под
определенные условия использования, а также обучения пользователей работе с
программным продуктом.
7. Сопровождение — процесс улучшения, оптимизации и устранения дефектов
программного обеспечения (ПО) после передачи в эксплуатацию. Сопровождение ПО
— это одна из фаз жизненного цикла программного обеспечения, следующая за фазой
передачи ПО в эксплуатацию. В ходе сопровождения в программу вносятся изменения,
с тем, чтобы исправить обнаруженные в процессе использования дефекты и
недоработки, а также для добавления новой функциональности, с целью повысить
удобство использования (юзабилити) и применимость ПО.

Проблемы разработки программного обеспечения.

Наиболее распространёнными проблемами, возникающими в процессе
разработки ПО, считают:
Несогласованность. Программист не всегда является экспертом в той области,
где будет применена программа, а заказчик не всегда четко выражает свои требования
и поэтому зачастую возникает недопонимание вследствие различия взглядов на
будущий программный продукт. И соответственно создается не то, что требуется. ПО
является достаточно гибким, часто оно представляет результат работы большого
коллектива, однако у потребителей постоянно возникают новые идеи относительно
данного программного продукта. Например, люди редко просят конструктора моста
внести изменения в середине проекта, тогда как пользователи ПО часто обращаются с
такими просьбами. Влияние таких изменений может быть просто огромно, или
катастрофическое.
Недостаток прозрачности.
В отличие от моста, здания или любого другого физического объекта, сложно
посмотреть на программный продукт и оценить степень его завершенности. Без
жесткого руководства проектом разработка ПО будет завершена не полностью. Без
точной оценки процесса разработки срываются графики выполнения работ и
превышаются установленные бюджеты.
Недостаточная надёжность. Самый сложный процесс — поиск и исправление
ошибок в программах. Поскольку число ошибок в программах заранее неизвестно, то
заранее неизвестна и продолжительность отладки программ, и отсутствие гарантий
отсутствия ошибок в программах.
Несовершенство пользовательского интерфейса. Одной из проблем
внедрения нового ПО является консервативность пользователей, которые зачастую
просто не могут найти в программе нужную им функцию (операцию). От части тут
может помочь подробнейшим образом составленная инструкция пользователя и
служба поддержки.

Жизненный цикл программного обеспечения.

Это период времени, который начинается с момента принятия решения о
необходимости создания программного продукта и заканчивается в момент его полного
изъятия из эксплуатации.
Под жизненным циклом (ЖЦ) подразумевается совокупность процессов, работ и
задач, включающая в себя разработку, эксплуатацию и сопровождение ПС, начиная с
анализа его концепции или потребности в заказе до прекращения его использования.
2
 Группы процессов жизненного цикла в соответствии с ISO/IEC 12207.
В настоящее время во всем мире ведутся активные работы в направлении
стандартизации ЖЦ программных средств (ПС). Стандартизация ЖЦ позволяет
упорядочить вопросы создания, сопровождения и управления ПС.
На уровне международных стандартов жизненный цикл сложных программных
средств наиболее полно отражен в международном стандарте ISO/IEC 12207.
В Республике Беларусь этот стандарт введен в действие в 2004 г. под
обозначением СТБ ИСО/МЭК 12207–2003.
В соответствии с данным стандартом ЖЦ ПС и систем имеет трехуровневую
иерархическую структуру. Основу жизненного цикла составляет набор процессов.
Каждый процесс разделен на набор работ. Каждая работа разделена на набор задач.

Процессы ЖЦ ПС делятся на три группы:

− основные;
− вспомогательные;
− организационные.

Основные процессы.
Основные процессы жизненного цикла – это процессы, которые реализуются под
управлением основных сторон, участвующих в ЖЦ ПС. Основными сторонами
являются заказчик, поставщик, разработчик, оператор и персонал сопровождения
программных продуктов.
Заказчик – это организация, которая приобретает систему, программный
продукт (ПП) или программную услугу.
Поставщик – это организация, которая поставляет систему, ПП или программную
услугу заказчику.
Разработчик – это организация, которая разрабатывает ПП.
Оператор – это организация, которая производит эксплуатационное
обслуживание системы, содержащей ПП, в заданных условиях.
Персонал сопровождения – это организация, которая предоставляет услуги по
сопровождению программного продукта.
Таким образом, основные процессы состоят из пяти процессов:
• заказ;
• поставка;
• разработка;
3
 • эксплуатация;
• сопровождение.

Процесс заказа
Процесс заказа определяет работы и задачи заказчика. Процесс заказа состоит из
определения потребностей заказчика в системе, программном продукте или
программной услуге, подготовки и выпуска заявки на подряд, выбора поставщика и
управления процессом заказа до завершения приемки системы, программного продукта
или программной услуги.
Процесс заказа состоит из 5 работ:
1. Подготовка процесса заказа.
2. Подготовка заявки на подряд
3. Подготовка и корректировка договора
4. Надзор за поставщиком
5. Приемка и закрытие договора

Общее число задач по данным работам равно 23 (см. СТБ ИСО/МЭК 12207–2003)

Процесс поставки
Процесс поставки определяет работы и задачи поставщика. Процесс поставки
начинается с решения о подготовке предложения в ответ на заявку на подряд,
присланную заказчиком, или с подписания договора с заказчиком на поставку системы,
ПП или программной услуги. Затем определяются процедуры и ресурсы, необходимые
для управления и обеспечения проекта, включая разработку проектных планов и их
выполнение.
Процесс поставки состоит из 7 работ:
1. Подготовка процесса поставки.
2. Подготовка ответа
3. Подготовка договора
4. Планирование
5. Выполнение и контроль
6. Проверка и оценка
7. Поставка и закрытие договора
Общее число задач по данным работам равно 23 (см. СТБ ИСО/МЭК 12207–2003).

Процесс разработки
Процесс разработки определяет работы и задачи разработчика. Данный процесс
включает работы по анализу требований, проектированию, программированию, сборке,
тестированию, вводу в действие и приемке программного продукта или системы.
Процесс разработки состоит из 13 работ:
1. Подготовка процесса разработки.
2. Анализ требований к системе
3. Проектирование системной архитектуры
4. Анализ требований к программной системе
5. Проектирование программной архитектуры
6. Техническое проектирование программной системы
7. Программирование и тестирование программной системы
8. Сборка программной системы
4
 9. Квалификационные испытания ПС
10.Сборка системы
11.Квалификационные испытания системы
12.Ввод в действие ПС
13.Обеспечение приемки ПС

Общее число задач по данным работам равно 55 (см. СТБ ИСО/МЭК 12207–2003).

Процесс эксплуатации
Процесс эксплуатации определяет работы и задачи оператора. Данный процесс
включает эксплуатацию программного продукта и поддержку пользователей в процессе
эксплуатации.
Процесс эксплуатации состоит из 4 работ:
1. Подготовка процесса эксплуатации
2. Эксплуатационные испытания
3. Эксплуатация системы
4. Поддержка пользователей

Общее число задач по данным работам равно 9 (см. СТБ ИСО/МЭК 12207–2003).

Процесс сопровождения
Процесс сопровождения определяет работы и задачи персонала сопровождения и
реализуется при модификациях программного продукта. Цель процесса – изменение
существующего ПП при сохранении его целостности. Процесс охватывает вопросы
переносимости и снятия ПП с эксплуатации.
Процесс сопровождения состоит из 6 работ:
1. Подготовка процесса сопровождения
2. Анализ проблем и изменений
3. Внесение изменений
4. Проверка и приемка сопровождения
5. Перенос
6. Снятие с эксплуатации
Общее число задач по данным работам равно 24 (см. СТБ ИСО/МЭК 12207–2003).

Организационные процессы.
Организационные процессы жизненного цикла − это ряд мер, направленных
на повышение организации и качества разработки программного обеспечения. Обычно
их выделяют четыре вида:
Управление
Создание инфраструктуры
Усовершенствование
Обучение

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

персоналом компании-исполнителя. За это отвечают люди, находящиеся на
руководящих постах, а также специальный отдел в фирме.
Процесс создания инфраструктуры. Разработка программных продуктов
требует наличия огромного количества инфраструктурных компонентов: компьютеров,
5
серверов, специальных программ для разработки и т.д. Кроме того, готовый продукт
требует наличия определённых единиц для его работы. Данный процесс необходим для
подготовки оборудования и ПО для разработчиков, а также для успешного
функционирования готового ПП у заказчика.
Процесс усовершенствования. Направлен на усовершенствование всех
остальных процессов жизненного цикла программного обеспечения.
Усовершенствование может повысить производительность разработчиков и добиться
большей выгоды от выполнения заказа на производство программы.
Процесс обучения. Постоянное обучение сотрудников и повышение их
квалификации – это залог производства качественных продуктов и программ. Процесс
обучения направлен на организацию мероприятий для повышения уровня и получения
новых навыков сотрудниками компании-разработчика.

Вспомогательные процессы
Документирование
Управление конфигурацией
Обеспечения качества
Верификация
Аттестация
Совместный анализ
Аудит
Решение проблем

Процесс документирования. В процессе разработки и далее исполнитель пишет

документацию и руководства пользователя к разрабатываемому программному
продукту. Данные документы помогут разработчикам вспомнить/разобраться структуру
и код ПО, а пользователям освоить работу с программой.
Процесс управления конфигурацией. Данный процесс включается в себя
работы по управлению наборами разрабатываемых компонентов ПО и по управлению
версиями ПП.
Процесс обеспечения качества. Он отвечает за то, чтобы разрабатываемый
программный продукт соответствовал предварительным требованиям к разработке, а
также стандартам организаций исполнителя и заказчика.
Процесс верификации. Нужен для того, чтобы выявить ошибки, внесённые в ПО
во время конструирования, а также выявить несоответствия разрабатываемого ПО
выработанной архитектуре.
Процесс аттестации. Процесс направлен на подтверждение соответствия
получаемых величин эталонным. То есть, выходные данные должны иметь
погрешность, удовлетворяющую требованиям и установленным стандартам.
Процесс совместной оценки. Нужен для контроля и проверки состояния
персонала и разрабатываемого программного продукта. Выполняется обеими
сторонами (заказчиком и исполнителем) на протяжении времени всех работ по проекту.
Процесс аудита. Аудит направлен на независимую оценку текущих положений,
состояния проекта, документации и отчетов. При аудите выполняется сравнение с
договором и документами, определяющими стандарты. Может выполняться также
обеими сторонами.
Процесс разрешения проблем. Реализует устранение недочётов, выявленных во
время всех процессов, связанных c контролем и оценкой.
6
 Модели жизненного цикла программного обеспечения.
Модель жизненного цикла программного обеспечения характеризует подход
команды к разработке ПП. Она отражает акценты и приоритеты во всём процессе
изготовления программы, а самое главное, порядок следования этапов создания
программных продуктов.
На сегодняшний день существует множество моделей жизненного цикла
разработки программного продукта. Мы кратко рассмотрим основные из них и выделим
их ключевые особенности.
Каскадная (водопадная) модель (waterfall)
Общая концепция подхода была представлена доктором Уинстоном Ройсом ещё
в 1970 году. В его основе лежит логическая последовательность шагов, которые должна
быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап
согласовывается компетентными сотрудниками, документируется и передаётся дальше.
Таким образом, каскадная модель строго следует последовательности всех этапов
разработки ПО и не предполагает возвращения с текущего этапа на предыдущий.

Преимущества каскадной модели

Устойчива к изменению кадрового состава. Разработчики могут приходить и
уходить на протяжении всего жизненного цикла проекта, но благодаря подробному
документированию это практически не влияет на сроки исполнения проекта.
Дисциплина. Модель водопада заставляет разработчиков, вовлечённых в проект
быть дисциплинированными, оставаться в рамках намеченного плана. При
необходимости в общей модели добавляется орган управления, ответственный за
принятие решений, исполнители же обязаны работать в рамках системы.
Гибкость на ранних этапах. Изменения в первых трёх фазах могут быть сделаны
немедленно и с минимальными усилиями, поскольку они не подкреплены кодом. Таким
образом, заказчик и исполнитель имеют значительный временной запас для
кардинального изменения концепции работы ПО.
Ориентация на сроки и финансы. Благодаря тому, что каждый этап полностью
очерчивает контур будущего ПО, все разработчики понимают свою роль, границы
работы и сроки исполнения. Это позволяет оперировать реальными цифрами перед
заказчиком, что делает модель проекта привлекательной.

Недостатки каскадной модели

Неадаптивная структура ПО. На первых этапах модель водопада может быть
гибкой, но если на фазе тестирования выявляются проблемы в общей структуре – это

7
влечёт за собой плачевные последствия в виде сорванных сроков и даже отказов
заказчика. Таким образом, возрастает роль руководителей и ответственных
разработчиков, с уровнем компетентности которых в любой компании часто бывают
проблемы.
Игнорирует конечного пользователя. Чем ниже продвигается процесс в водопаде,
тем меньше в нём роль заказчика, не говоря уже о клиентах, которых он представляет.
Внесение каких-либо изменений в функциональность ПО запускает всю цепочку этапов
заново, поэтому продукты, полученные по каскадной модели далеки от ориентации на
массового пользователя.
Позднее тестирование. На этапе тестирования чаще всего выявляются ошибки,
допущенные на каждом из этапов. Более гибкие методологии используют тестирование
в качестве фундаментальной операции, происходящей непрерывно. «Водопад» же
допускает низкую квалификацию сотрудников на каждом этапе и плохое качество
исполнения, ведь при запоздалом тестировании проблемы невозможно решить
фундаментально, только при помощи «заплаток».

Итеративная и инкрементальная модель

Итеративный инкрементный подход к разработке ПО (IID) берет свое начало с
середины 50-х годов прошлого столетия. Но если в те времена понятие «итеративная
разработка» сводилась к исправлению уже сделанного, то в контексте современных
методов быстрой разработки этот термин означает нечто иное: не просто пересмотр
проделанной работы, но и эволюционное продвижение вперед.
Итеративный инкрементный подход основывается на базовом формальном
описании системы, дающем возможность создать первую исполняемую
функциональную модель. Полученная модель проверяется на соответствие описанию
системы, а затем расширяется далее, последовательно преобразуясь в новые модели, в
которых отражается увеличение требований к системе и уточнение деталей их
реализации. Процесс продолжается до трансформации модели в реальную
программную систему.

С точки зрения структуры жизненного цикла такую модель называют

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

Достоинства:
− снижение неопределённости в требованиях по мере проектирования,
позволяющее уменьшать число откатов;
− совмещение относительно строгой последовательности шагов и итеративного
подхода обеспечивает достаточно сбалансированный по рискам затрат план работ.
8
 Недостатки:
− трудность прогнозирования сроков окончания проекта;
− возможность отката при интеграции отдельных компонентов, что может
приводить к откатам и связанным с ними затратам.

Спиральная модель
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков.
Была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Боэм
формулирует 10 наиболее распространенных (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание
деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение
системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту)
ресурсами.
9. Недостаточная производительность получаемой системы.
10. «Разрыв» в квалификации специалистов разных областей знаний.

Спиральная модель предполагает 4 этапа для каждого витка:

− планирование;
− анализ рисков;
− конструирование;
− оценка результата и при удовлетворительном качестве переход к новому
витку.

1. начальный сбор требований и планирование проекта;

2. эта же работа, но на основе рекомендаций заказчика;
3. анализ риска на основе начальных требований;
9
 4. анализ риска на основе реакции заказчика;
5. переход к комплексной системе;
6. начальный макет системы;
7. следующий уровень макета;
8. сконструированная система;
9. оценивание заказчиком.

Достоинства спиральной модели:

наиболее реально (в виде эволюции) отображает разработку программного
обеспечения;
позволяет явно учитывать риск на каждом витке эволюции разработки;
включает шаг системного подхода в итерационную структуру разработки;
использует моделирование для уменьшения риска и совершенствования
программного изделия.

Недостатки спиральной модели:

сравнительная новизна (отсутствует достаточная статистика эффективности
модели);
повышенные требования к заказчику;
трудности контроля и управления временем разработки.

Макетирование
Достаточно часто заказчик вначале проекта не может точно и однозначно
сформулировать подробные требования по вводу, обработке и выводу данных.
С другой стороны, разработчик может сомневаться в переносимости продукта на
другую программную или аппаратную платформу, а также в эффективности
реализуемых алгоритмов. В этих случаях целесообразно использовать макетирование.
Основная цель макетирования – снять неопределенности в требованиях заказчика.
Макетирование (прототипирование) – это процесс создания модели требуемого
программного продукта. Модель может принимать одну из трех форм:
1. бумажный макет, на котором изображен человеко-машинный диалог;
2. работающий макет, который выполняет некоторую часть требуемых функций;
3. существующая программа, характеристики которой должны быть улучшены.
Макетирование основано на многократном повторении операций, в которых
участвуют разработчик и заказчик.

Макетирование начинается со сбора и уточнения требований, задаваемых

программному обеспечению. Разработчик и заказчик определяют все цели создания
программного обеспечения, устанавливают, какие требования известны, а какие
предстоит доопределить. Затем выполняется быстрое проектирование, при котором
внимание сосредотачивается на тех характеристиках программного обеспечения,
10
которые должны быть видимы пользователю. Быстрое проектирование приводит к
построению макета. Макет оценивается заказчиком и используется для уточнения
требований к программному обеспечению. Итерации повторяются до тех пор, пока
макет не выявит все требования заказчика и тем самым не даст возможность
разработчику понять, что должно быть сделано.
Достоинство макетирования заключается в том, что оно дает возможность
определить полные требования к программному обеспечению.
Недостаток макетирования состоит в том, что разработчик и заказчик могут
принять макет за готовый программный продукт. Когда заказчик видит работающую
версию программного обеспечения, он забывает о нерешенных вопросах качества и
удобства сопровождения программного обеспечения.
С другой стороны, для быстрого получения работающего макета разработчик
часто идет на определенные компромиссы. В частности, могут быть использованы не
самый подходящий язык программирования или неэффективный алгоритм.
Спустя некоторое время разработчик забывает о причинах, по которым эти
средства не подходят. В результате далеко неидеальный вариант реализации
компонента интегрируется в рабочую систему.

11
 Лекция 3

Методологии разработки программного обеспечения (ч.1)

Семейство гибких методологий Agile.

В 1970 году доктор Уинстон Ройс, американский ученый-компьютерщик
раскритиковал последовательную разработку в статье, которая называлась «Управление
развитием крупных программных систем». Как утверждал, разработка программного
обеспечения не должна быть похожа на сборку автомобиля на конвейере, где каждая
деталь ставится в последовательные фазы. В таких следующих друг за другом этапах
любая фаза проекта должна закончиться прежде, чем начнется новый этап. У. Ройс
предложил применять фазовый подход, где в каждую фазу разработчиками собираются
все требования по проекту, затем завершается вся архитектура и дизайн, далее
записывается весь код и т. д.
После знакомства с этой идеей подход к работе у программистов поменялся: они
стали на каждом этапе делать мини-тестирования, чтобы получить обратную связь и
внести правки в продукт, который еще не готов. Обратная связь запрашивалась и у
заказчика до того, как ему сдавали итоговый вариант.
Результаты экспериментов оказались весьма успешными и получили широкое
признание – продукты стали более качественными, клиенты выражали удовлетворение,
а программисты начали опережать запланированные сроки. Такой подход к делу
получил название «гибкий» – ведь на любом из этапов создания продукта теперь была
возможность внесения корректировок, чтобы результат получился безупречным.
Для систематизации и объединения в одно целое всех подходов к управлению
проектами (а их на тот момент насчитывалось больше десяти) 17 человек — крупные
IT-специалисты и разработчики — собрались на горном курорте в штате Юта.
Отдохнули, пообщались и составили небольшой документ, который носит название
Agile-манифест.

С английского agile переводится как «подвижный, быстрый, проворный». Но в

русской IT-лексике за этой группой методологий закрепилось определение «гибкие».
Agile-подход динамично организует программирование, постоянно адаптируя проект к

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

Waterfall:
1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.

Теоретически в Waterfall возможен возврат на предыдущие ступени — например,

если оказывается, что ту или иную задачу невозможно выполнить по техническим
причинам. В этом случае ТЗ пересматривают, но это скорее чрезвычайная ситуация. В
норме конечный продукт должен идеально соответствовать требованиям, целям и
задачам, которые были сформулированы до разработки.
1
 В Agile-методологии в приоритете не исходные установки, а актуальные
потребности пользователя. Постоянно вносить изменения в ТЗ, даже в самый разгар
разработки, для Agile нормально. В гибкой методологии не предусмотрен
предварительный генеральный план — напротив, программный продукт пишется
практически экспромтом.

Разработка проходит через ряд циклов — итераций. Каждая итерация — это

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

Чтобы понять, как это работает, представим коллектив разработчиков, создающих

аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал.
Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи
предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы
быстро управлять плеером.

Начинается новая итерация разработки. Коллеги-программисты собираются на

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

На этом итерация завершается — и начинается новый виток разработки.

Итак, Agile – процессная методология, состоящая из серии подходов к разработке
программного обеспечения или информационного продукта, ориентированная на
использование итеративной разработки, динамическое формирование требований и
обеспечение их реализации, в результате постоянного взаимодействия внутри
самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

Это основное и общепринятое определение Agile, но, как это часто бывает в
мейнстримных направлениях, которым Agile стала на сегодня, единого определения не
существует и есть множество альтернативных толкований этого термина.

Принципы Agile.
Гибкая методология — набор идей и принципов, на которых основаны
конкретные практические решения. Можно считать это особой философией, которая
задает вектор, а не предписывает действия. Эти идеи и принципы были впервые
сформулированы в Agile-манифесте.

4 центральных идеи Agile Manifesto

 Люди и взаимодействие важнее, чем процессы и инструменты.
 Работающее ПО важнее, чем исчерпывающая документация.
 Сотрудничество с заказчиком важнее, чем согласование условий контракта.
 Готовность к изменениям важнее, чем следование первоначальному плану.

2
 12 принципов Agile
1. Задача высшего приоритета — регулярно и как можно раньше удовлетворять
потребности заказчика, предоставляя ему программное обеспечение.
2. Учитывать, что требования могут измениться на любом этапе разработки.
Если изменения быстро вносятся в проект, заказчик может получить конкурентные
преимущества.
3. Выпускать версии готовой программы как можно чаще — с промежутком от
двух недель до двух месяцев.
4. Ежедневно вместе работать над проектом — разработчикам и заказчикам.
5. Поручить работу мотивированным профессионалам. Обеспечить поддержку и
условия, довериться им — и работа будет сделана.
6. Общаться напрямую — это самый эффективный способ взаимодействия
внутри команды и вне ее.
7. Считать главным показателем прогресса работающий продукт.
8. Поддерживать постоянный ритм работы — касается и разработчиков, и
заказчиков.
9. Уделять пристальное внимание техническому совершенству и качеству
проектирования — это повышает гибкость проекта.
10. Минимизировать лишнюю работу.
11. Стремиться к самоорганизующейся команде — в ней рождаются наиболее
эффективные и качественные решения.
12. Всем участникам команды — постоянно искать способы повышать
эффективность работы.

Сравнение классического и гибкого управлений

Чтобы понять разницу между двумя подходами – классическим и гибким
управлением, рассмотрим ее на примере хлебозавода.
В первом случае это будет ситуация на предприятии, где не применяется
интересующая нас методология, во втором – представим гипотетический завод, на
котором внедрили данный метод управления:

1. Обычный хлебозавод
Технолог получает от генерального директора задание на разработку нового вида
хлебной продукции. Что он делает дальше? Допустим, направляется к маркетологам
предприятия и поручает им провести соответствующие исследования. Но, скорее всего,
этот шаг продиктован не желанием узнать истинные предпочтения потребителей, а
стремлением угодить вкусам руководителя.
Получив результаты маркетинговых исследований, технолог создаст хлебную
новинку на свой вкус и представит ее директору. Тот продегустирует продукт и решит:
похвалить и поощрить технолога или забраковать разработку, отправив подчиненного
все переделывать. В итоге после одобрения руководством пекари получат
технологические карты, чтобы начать массовый выпуск новой продукции, и, наконец,
испеченный хлеб поступит в торговлю. Так выглядит традиционный вариант: персонал
всего лишь получает указания для работы, а оценивается результат одной личностью
(иногда бывает, что несколькими).

3
 2. Agile-хлебозавод
У генерального директора рождается идея о выпуске нового сорта хлеба. А
дальше происходит что-то невероятное. Создавать продукт зовут и технолога, и группу
маркетинга, и отдел продаж, и логистов, и поваров с кондитерами, а еще, представьте,
обычных покупателей.
В этой сборной команде не будет никакой иерархии (разве что генеральный
директор сохранит руководящую роль), итогом же общих усилий станет не
персональная награда одного лучшего сотрудника, а то, что появится новый сорт хлеба
и он будет нарасхват у покупателей. Кстати, во время всего процесса каждое из
действующих лиц оценивает результат и выдает обратную связь для лучших
показателей.
Короче говоря, благодаря такому подходу компания может быстро
переориентироваться на какую-то цель и выдать отличный продукт, который способен
выдержать конкуренцию, а главное, по душе покупателям. Это хорошо для продаж,
ценно с точки зрения экономии времени и помогает избежать ошибок.

Недостатки методологии Agile

В Аgile слабо представлено понятие управления требованиями и связанные с ним
процессы, так как, будучи гибкой моделью разработки, она не предполагает
планирование на долгую перспективу (только краткосрочное). В итоге выпадает целый
фрагмент формирования плана развития продукта, или, в другой терминологии,
дорожной карты. Что получается? Планирование идет на короткий срок (на ближайшую
итерацию разработки), а клиент в финале каждой итерации утверждает результат и
предъявляет новые требования, так что заказ может кардинально измениться, а
требования, которые выставляются вновь и вновь, будут вступать в противоречие со
структурой и архитектурой уже поставляемого заказчикам продукта.
Если у клиента нет четкого понимания, каким он хочет видеть конечный продукт,
а ясность наступает только в процессе разработки (такое происходит в подавляющем
большинстве случаев), то процесс перетекает в стандартную бюрократию – доработки
продукта могут длиться нескончаемо, пока не иссякнут финансы или внимание
заказчика не переключится на другую продукцию. При этом заказчик изначально
осознает, чем это чревато, и самостоятельно принимает решение о целесообразности
платы за разработку – команда исполнителей только воплощает желания клиента. К
чему это приводит? К полной неразберихе, нарушению дедлайнов и авралам, в
результате возникают новые претензии, из-за которых продукт изменяется явно не к
лучшему. Однозначно страдает качество разработки, потому что в Аgile действует
подход: «пожары» надо тушить быстро простыми подручными способами.
Написание кода происходит без соблюдения требований платформы, на которой
продукт разрабатывают, возникает масса обходных решений и дефектов, которые
делают конструкцию неустойчивой и опасной, клиенты все больше раздражаются и
негодуют из-за систематических сбоев в программном обеспечении. Что в итоге? Бизнес
несет убытки, качество планирования снижается.

Применение Agile
В настоящее время проект-менеджмент с поддержкой Аджайл по большей части
распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система
применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на
вооружение множеством компаний и государственных структур.
4
 Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский
пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo
(производство печенья), компания Aviasales (крупнейший поисковик авиабилетов),
компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк»
(Россия), Альфа-банк.
Если говорить о динамике распространения Agile в Беларуси, то пока чувствуется
некоторое шевеление в банковском секторе, чуть меньше проявляют интерес к Agile в
R&D-департаментах (от англ. Research & Developmet) (отдел НИОКР – отдел научно-
исследовательских и опытно-конструкторских разработок) производственных
компаний, появляется небольшое движение в сторону Agile у сервисных компаний.

Популярные методы управления проектами

Kanban, Lean (бережливая разработка), Scrum, XP-программирование
(экстремальное программирование), SAFe (это слоеный пирог из различных методик
Agile), FDD (Feature driven development – разработка, управляемая функциональностью)

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

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

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

Достоинства Scrum
 Scrum ориентирован на клиента, адаптивен.
 Scrum дает клиенту возможность делать изменения в требованиях в любой
момент времени, но не гарантирует то, что эти изменения будут выполнены.
(Возможность изменения требований привлекательна для многих заказчиков)
 Scrum достаточно прост в изучении, позволяет экономить время за счет
исключения некритичных активностей.
 Scrum позволяет получить потенциально рабочий продукт в конце каждой
итерации работ.

5
  Scrum делает упор на самоорганизующуюся многофункциональную команду,
способную решить необходимые задачи с минимальной координацией.
Это особенно привлекательно для малых компаний, так как избавляет от
необходимости найма или обучения специализированного персонала дорогостоящих
руководителей.

Недостатки Scrum.
Ввиду простоты и минималистичности, Scrum задает небольшое количество
довольно жестких правил. Однако это вступает в конфликт с идеей "клиент всегда прав",
так как заказчикам не важны внутренние правила команды разработки, особенно если
они его ограничивают.
Так же общеизвестной проблемой Scrum являются большие издержки на
обсуждения, встречи и большие потери времени на стыках спринтов. Как минимум день
уходит на закрытие очередного спринта, а потом день – на открытие нового. В условиях,
когда спринт длится 2 недели, 2 дня составляют 20% рабочего времени. Итог – 30-40%
времени при применении Scrum тратится на поддержание самого процесса (ежедневные
встречи, планирование и детализирование работ, презентация полученных результатов
и пр.)

Сложности при заключении договоров. Scrum в принципе не подразумевает

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

Общая схема Scrum

6
7
8
 Лекция 4
Методологии разработки программного обеспечения (ч.2)

Роли Scrum

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

Характеристиками эффективных команд являются следующие:

 Стремление к совершенству. Лучшие группы объединены единой целью. Для
достижения поставленных задач они постоянно используют наиболее эффективные
варианты, не пользуясь теми, которые плохо зарекомендовали себя в прошлом,
1
благодаря чему переходят в ранг от посредственных до высоких уровней, получают
понятие своих возможностей и имеют повышенные требования к получаемым
результатам.
 Независимость. Обладающие этим качеством штаты работников
самоорганизованны и самоуправляемы. У них есть возможность принимать решения,
переходить к их реализации. Они научены действовать самостоятельно.
 Универсальность. В состав лучших команд включены специалисты профилей
(планирования, разработки, продажи и реализации производства), необходимых для
самодостаточной работы команды. Главными качествами являются взаимная
поддержка, взаимодействие и понимание между членами трудового процесса.
Кроме того, есть набор несложных правил, которые укладываются в единый
лозунг: «Одна команда – от старта до финиша».
Главное требование к команде, которая должна создавать необходимый продукт,
– многофункциональность. Это выражается в наличии всех специалистов, необходимых
знаний и практики для успешного выполнения заданий.

Характеристики команды разработки

Самоорганизующаяся: никто (даже Скрам-мастер) не может указывать Команде
Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты.
Кросс-функциональна: команда обладает всеми навыками, которые необходимы
для создания Инкремента Продукта.
Разработчик — единственная роль для членов Команды Разработки, независимо
от типа задач, которые он выполняет. Скрам не признает других ролей в Команде
Разработки, это правило не имеет исключений.
Скрам не признает подкоманд в Команде Разработки, независимо от областей, над
которыми необходимо работать (например, тестирование, архитектура, эксплуатация
или бизнес-аналитика). Это правило не имеет исключений.
Команда Разработки несет коллективную ответственность за создание
Инкремента Продукта. При этом отдельные члены Команды Разработки могут обладать
различными специализированными навыками и экспертизой.

Этапы командообразования
Чтобы группа людей превратилась в сплоченную и эффективную команду,
необходимо пройти несколько этапов.
Наиболее распространенной моделью, описывающей стадии
командообразования, является модель Такмана.

2
 В своем развитии все команды обязательно проходят несколько этапов.

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

Бурление
На этом этапе все члены команды отчетливо осознают свои и общие цели,
задающие вектор движения коллектива. В период бурления часто возможны конфликты
и противостояние между отдельными членами команды, формирование мелких
группировок, поэтому особенно возрастает роль Scrum-мастера (SM) как модератора (о
нем чуть позже). Этап бурления – самое время для определения формальных и
неформальных лидеров Scrum-команды.

Нормализация
На этапе нормализации происходит "притирание" членов команды друг к другу.
Закрепляются лидеры команды, и она начинает демонстрировать стабильные
результаты деятельности. Основная задача Scrum-мастера на этом этапе – помощь
команде для перехода на следующий этап.

Функционирование
Функционирование – это этап, на котором команда переходит к
самоуправляемости. На этом этапе команда способна оптимизировать свою
производительность, существующие неформальные связи между членами команды

3
закрепляются окончательно. Это период наибольшей эффективности и
производительности.

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

Чтобы работать эффективно, команда должна как можно дольше находиться на

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

Разработчик
Scrum-команда должна состоять из мотивированных профессиональных
сотрудников. Члены команды отвечают за разработку программного продукта высокого
качества. Они должны обладать множеством различных навыков, необходимых для
создания эффективного программного обеспечения:
 Бизнес и системный анализ.
 Проектирование архитектуры программного продукта.
 Программирование.
 Тестирование.
 Настройка баз данных.
 Разработка эргономичных пользовательских интерфейсов.

Члены команды участвуют в планировании работ на временной интервал,

который в Scrum принято называть "спринт". Команда может включать опытных
разработчиков и новичков, которые в процессе работы должны совершенствоваться при
обмене знаниями. Члены команды отвечают за следующие задачи в проекте:
 обязательное выполнение элементов работ, включенных в текущий спринт:
 акцент на взаимосвязанных задачах спринта;
 совершенствование личной и командной работы.
Основной движущей силой команды является ее участник, которого принято
называть разработчик (Development member) – специалист, представляющий собой
«ядро» Scrum. От его навыков, умения, квалификации, опыта будет зависеть
дальнейшее развитие продукта и Scrum-команды.

Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно

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

Помимо владения теоретическими знаниями каждый член команды должен уметь

практически применить следующие навыки:
 общаться с пользователями для понимания целей производимых разработок;
 собирать "правильные" требования, которые в дальнейшем можно сопоставить
с ожиданиями ключевых пользователей;
 планировать дальнейшую работу над продуктом в виде его инкрементного
развития;
 документировать в минимальном объеме требования;
 выполнять синтез разрозненных и противоречивых требований в единое
комплексное рабочее решение;
 создавать удобный, читаемый, понятный, однозначный код ИС в целях его
дальнейшего развития;
 проводить полный цикл разных видов тестирования;
 выполнять установку программного обеспечения;
 поддерживать пользователей и отвечать на любые, даже глупые, вопросы.

Scrum-мастер
Scrum-мастер – движущая сила Scrum-процесса. Он призван помогать команде в
освоении гибкой методологии. Его роль является определяющей при внедрении Scrum.
Для того чтобы Scrum получился успешным, Scrum-мастер должен обладать
следующими качествами:
 быть ответственным;
 отдавать должное команде, а не личным достижениям;
 всегда быть готовым к диалогу;
 выкладываться по максимуму;
 обладать умением влиять на других;
 обладать развитым профессиональным кругозором;
 разбираться в профессиональных и технических вопросах.
Scrum-мастер призван помогать команде в использовании Scrum. Его функции
сопоставимы с функциями тренера, который помогает спортсменам соблюдать
спортивный режим и поддерживать физическую форму. Scrum-мастер создает
мотивации и в то же время следит за тем, чтобы члены команды не увиливали от
выполнения "тяжелых физических упражнений". Однако его полномочия ограничены.
Он не может заставить сотрудника выполнять то или иное упражнение, которое тот не
желает выполнять. Вместе с тем он напоминает о целях и о том, как необходимо их
достигать. Scrum-мастер обладает властью в той мере, в какой этой властью наделила
его команда.

Услуги Скрам-мастера для владельца продукта

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

5
  объясняет Скрам-команде необходимость кратких и понятных Элементов
Бэклога Продукта;
 объясняет особенности планирования продукта в эмпирической среде;
 помогает Владельцу Продукта упорядочить Бэклог Продукта, чтобы получить
максимальную ценность продукта;
 способствует лучшему пониманию гибкости и её применения;
 фасилитирует (облегчает выполнение заданий) события Скрама при
необходимости.

Услуги Скрам-мастера для команды

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

Услуги Скрам-мастера для Организации

Скрам-мастер оказывает услуги Организации:
 направляет и коучит организацию при внедрении Скрама;
 планирует переход на Скрам в организации;
 помогает сотрудникам и заинтересованным лицам понять теорию и практику
Скрама, правильно реализовать принципы эмпирической разработки продуктов;
 способствует изменениям, направленным на повышение продуктивности
Скрам-команд;
 сотрудничает с другими Скрам-мастерами для повышения эффективности
применения Скрама в организации

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

Владелец продукта (Product Owner) – сотрудник, который указывает Scrum-

команде ее цель и не позволяет отклоняться от нее. Указание цели происходит за счет:
 четкого определения выполняемых задач (бэклог продукта);
 установки приоритетов выполнения задач;
 повышения ценности работы, выполняемой командой;
 обеспечения видимости, прозрачности, понятности выполняемых задач,
формирования понятных и непротиворечивых требований к ним.

На нем лежит ответственность за то, как члены команды поймут задачи,

необходимые для реализации. Для эффективного выполнения роли PO необходимо
иметь следующие качества:
 быть доступным для вопросов от членов команды;
 досконально знать профильное направление бизнеса;
 быть коммуникабельным;
 быть решительным;
 иметь определенные властные полномочия в организации.

Самоорганизация членов команды

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

После того как задания на ближайший спринт определены, команда должна

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

7
 Лекция 5
Методологии разработки программного обеспечения (ч.3)

Атрибуты SCRUM

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

Карта историй представляется в виде двух последовательностей зависящих друг

от друга активностей. Таким образом, мы получаем матричный вид карты историй.
Она представляет собой последовательные стадии, выполняющиеся в
автоматизируемом процессе/продукте. На самом верхнем уровне располагается
наиболее верхнеуровневое представление стадий или компонентов разрабатываемого
продукта. Далее, по мере снижения, каждый компонент раскладывается на
составляющие, и так до самого низкоуровневого представления автоматизируемого
продукта.

Процесс построения карты историй

Сначала выделяют ключевые виды деятельности. Каждый вид фиксируется на
отдельной карточке.
Они располагаются в функциональном порядке использования слева направо.
После этого определяются отдельные задачи, определяющие каждую активность,
и также фиксируются на карточках.
Все задачи располагаются в логическом порядке.
Карта историй содержит каркас из задач, представляющих собой "кирпичики",
составляющие конечный продукт. Этот каркас покрывает крупный набор функций,
реализуемых в соответствии с приоритетами пользователей.
Таким образом, Story mapping − это архитектурное представление задач
пользователя.

1
 Под каркасом находятся подробные требования, которые описывают конкретные
функциональные части для выполнения задач. В Scrum, когда речь заходит о работе с
требованиями, применяют определенную технику работы с ними, которая называется
User Story (пользовательские истории).

Пользовательские истории (User story)

User story является неотъемлемой частью гибких методик разработки. С помощью
нее можно разбить свою работу на серию задач, выполнение каждой из которых
привносит ощутимую ценность в процесс реализации проекта. Все эти задачи можно
обсуждать и распределять по важности
User story вкратце описывает:
человека, использующего систему (заказчик);
то, что должно содержаться в данной системе (примечание);
то, для чего она нужна пользователю (цель).

User story может быть добавлена к бэклогу проекта на любом этапе спринта
любым членом команды. Владелец проекта решает, как координировать и
приоритезировать пожелания пользователя, и подбирает их вначале каждого цикла
спринта.

Карточки пожеланий пользователя

Пожелание пользователя представляет собой карточку с заголовком и
несколькими строчками текста. Карточки могут быть как виртуальными, так и
материальными. Пожелание пользователя должно быть хорошо сформулировано. Если
пожелание слишком объемное, его необходимо разбить на более мелкие части.

Структура
Карточка составляется по стандартной схеме:
Заголовок (должен описывать действие);
Заказчик (роль);
Примечание (функционал);
Цель (выгода).

Она не отражает каждую мелочь, но вы должны детально обсудить

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

2
История: Владелец карточки снимает наличку

Я как Владелец карточки

Хочу снять наличку в банкомате
Для того чтобы я мог получить деньги, когда банк

Движение «от цели»

В гибких методологиях применяют подход «от обратного» – что пытается
получить пользователь системы на выходе? Поэтому самой важной частью user story
является её цель.

Use Case
В практике подготовки требований, которые в дальнейшем составят каркас
разрабатываемого программного продукта, в Scrum принято использовать один из
стандартизированных подходов для их описания − Use Cases ("сценарии
использования").
Use Case − это сценарная пошаговая техника описания взаимодействия двух или
более участников, задействованных в автоматизации. С помощью Use Case может быть
описано и пользовательское требование, и требование к взаимодействию систем, и
описание взаимодействия людей и компаний в реальной жизни.
Таким образом, каждый квадратик в Story Mapping можно представить в виде Use
Case. Разработать оптимальную пользовательскую историю не так просто, нужен
определенный навык, который позволит создать качественное описание требований
пользователей к реализуемому программному продукту, но в награду за это получаются
следующие преимущества:
Краткость. Пользовательская история описывает небольшую часть бизнес-
ценности, которую возможно реализовать за период спринта.
"Незатратность" создания и сопровождения. За счет своей "компактности"
пользовательские требования достаточно просто создать и сопровождать их изменения
на всем протяжении жизненного цикла продукта.
Вовлечение ключевых пользователей в процесс создания продукта. За счет своей
доступности бизнес-требования смогут стать реальным "мостиком" между
пользователями и Scrum-командой. Это позволит более адекватно управлять
ожиданиями пользователей и вовлечь их на нужную степень погружения в процесс
разработки продукта.
Облегчают оценку заданий. Формат пользовательских историй способствует
более точной оценке необходимых системных разработок/доработок.

3
4
 Основной поток событий

Определение приоритетов пользователей

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

5
 При использовании этой матрицы по ее "частям" распределяются задачи в
соответствии с их важностью и срочностью.
Важные и срочные задачи. Это те задачи, которые важны, и выполнить их
необходимо срочно. Без них все порушится, ничего работать не будет, и сделать их
завтра – будет уже поздно.
Важные, но не срочные задачи. Это те, которые срочными станут в скором
времени. Успешные команды и сотрудники в первую очередь обращают свое внимание
именно на этот тип задач, чтобы они постепенно не перешли в разряд "Важные и
срочные задачи".
В момент усталости многие разработчики начинают заниматься сторонними
делами, чтобы отдохнуть. Это неправильно. Правильно –запланировать качественный
отдых в соответствии с индивидуальными особенностями каждого разработчика. Это
задача из категории "Важно и не срочно".
Не важные, но срочные. Это тип задач, которые никак не приближают к
достижению необходимого результата, которые надо делать, но исключительно для
того, чтобы их делать.
Не важные и не срочные. Эти задачи не важны, они не срочны, но именно их
хочется делать. Это пожиратели времени, и от них необходимо избавляться.
Принцип Эйзенхауэра – очень эффективная техника расстановки приоритетов. Но
ее особенности больше направлены на расстановку приоритетов отдельного
сотрудника, а не команды в целом.

Методика «АБВ».
В соответствии с этой методикой задачи делятся на три категории: жизненно
важное, важное, приятное. Эта методика является логическим (более "глубинным")
продолжением принципа Эйзенхауэра.
Применение принципа Парето (принцип 80/20 – 20 % усилий дают 80 %
результата, а остальные 80 % усилий — лишь 20 % результата) конкретизируется,
если все задачи проанализировать в соответствии с их долей в итоговом результате и
затем распределить по категориям важности. АБВ основывается на следующих трех
закономерностях, подтвержденных опытом:

6
 Самые критичные задачи (категория "А") составляют ~ 15-20% всех задач.
Значимость этих задач, вклада в достижение конечного результата составляет ~ 60-65%.
Менее важные задачи (категория "Б") составляют ~ 20 % от общего числа. Их
значимость – также 20% конечного результата.
Неважные и несущественные задачи (категория "В") составляют до 65% от
общего числа задач. Они имеют незначительную долю – 15% в достижение конечного
результата

Расстановка приоритетов с помощью АБВ-анализа проходит в пять этапов:

1. Составить список задач на планируемый промежуток времени
2. Расположить задачи по их важности. Для этого нужно оценить, насколько та
или иная задача приближает вас к достижению целей.
3. Перенумеровать получившийся список. Первые 15% задач пометить буквой А,
следующие 20% — буквой Б, а оставшиеся 65% — буквой В.
4. Изменить бюджет времени на эти группы задач:
65% времени должно приходиться на задачи А;
20% на задачи Б;
15% на задачи В.
Стоит продумать, как сократить время на выполнение задач из категорий Б и В.
Например: можно ли их кому-нибудь делегировать или перепоручить?

Метод MoSCoW (Oracle). Один из консультантов Oracle (Dai Clegg) предложил

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

7
MoSCoW позволяет сосредоточить фокус внимания как владельца продукта, так и
Scrum-команды на задачах конкретного спринта.
Все имеющиеся задачи в бэклоге продукта следует сгруппировать в четыре
приоритетные корзины по следующим правилам:
M (must) – задачи должно быть реализованы в первую очередь, без них
программный продукт не имеет смысла. От этих задач нельзя отказаться. В них
заключен залог успеха. Задачи, отмеченные как must, должны быть включены в текущий
спринт.
S (should) – следовало бы иметь, но можно отложить на более позднее время.
Задачи этого типа также критичны для успеха разрабатываемого продукта, но не
необходимы в ближайшее время. Такие задачи, как правило, имеют альтернативные
пути решения.
C (could) – можно было бы иметь, но если нет возможности их разработать сейчас,
то можно и отложить. Задачи этого типа менее критичны. Они обычно относятся к типу
"хотелось бы иметь".
W (would) – в этот раз стоит отказаться от этих задач, но в следующий раз можно
их сделать. Наименее критичные. Задачи данной категории не планируются к
разработке в ближайшие спринты, но при будущих поставках их статус может быть
пересмотрен.

Доска задач
Рассмотреть еще один очень важный артефакт каждой Scrum-команды, цель
которого – визуализировать состояния задач в Scrum. Речь идет о Scrum-доске.

8
 Каждый рабочий день все члены команды собираются на 15-минутное daily, на
котором они обмениваются информацией по состоянию текущих дел ("Что сделано с
момента предыдущей встречи?", "Чем планирую заниматься сегодня?", "Какие есть
препятствия?").

На доске команды развешены задачи, каждой из которых выделен бумажный

стикер, на котором написано, в чем состоит суть задачи.
Доска задач должна минимум делиться на три колонки:
– запланировано (To Do);
– в работе (In Progress);
– завершено (Done).

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

помещаются в колонку "Запланировано". Каждый день, когда член команды берет в
работу определенную задачу, он говорит: "Я начал работать над…" и перемещает
карточку в столбец "In Progress". После того как задача выполнена, исполнитель говорит
о том, что работа над задачей закончена, и карточка перемещается в соответствующую
колонку "Завершено".

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

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

задач, являются:
– наглядность спринтов;
– прозрачность состояния задач и проблемы;
– простой контроль за "загрузом" разработчиков и прочее.

В начале своей деятельности каждая команда должна попробовать именно

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

Бэклог продукта
После того как необходимые требования к продукту собраны, их необходимо
зафиксировать и "взять на учет" для дальнейшей реализации. Для этого в Scrum есть
артефакт, который называется бэклог продукта (Product Backlog, PB).
Бэклог продукта – это упорядоченный список задач, которые должны быть
реализованы в конечном продукте.
PB является единственным источником требований для любых изменений,
которые может потребоваться внести в ПО. Ответственность за бэклог продукта несет
владелец продукта, включая его содержимое, доступность, упорядочение и
приоритизацию.

9
 PB никогда не является полным. В начале (сверху) – только первоначально
известные и наиболее понятные требования. Бэклог постоянно обновляется по мере
обновления самого продукта и окружающей его среды, поэтому PB "живет" вместе с
продуктом. PB является динамическим, постоянно изменяющимся для соответствия
требованиям продукта, его конкурентоспособности и пригодности. PB существует
ровно до тех пор, пока существует и сам продукт:
PB содержит все "фичи", функции, требования, усовершенствования и
информацию по исправлению дефектов, то есть те данные, которые и определяют
изменения, необходимые в следующих релизах продукта. Каждому элементу PB
присваивается:
– описание
– порядковый номер
– оценка объема работы
– ценность.
Элементы Бэклога Продукта часто содержат описания тестов, которые позволят
убедиться в завершённости Элемента, когда он будет «Готов».

Если над одним продуктом работает несколько Скрам-команд, для описания

предстоящей работы используется один Бэклог Продукта. При этом его элементы могут
быть сгруппированы по атрибутам.
Уточнение Бэклога Продукта – это деятельность, направленная на уточнение,
оценку и упорядочивание элементов в Бэклоге Продукта. Речь идет о непрерывном
процессе, в рамках которого Владелец Продукта и Команда Разработки обсуждают
детали Элементов Бэклога Продукта, тем самым проверяя и пересматривая эти
элементы. Скрам-команда решает, как и когда должно производиться Уточнение
Бэклога Продукта. Обычно этот процесс занимает не более 10% от доступного времени
Скрам-команды. При этом Элементы Бэклога Продукта в любой момент времени могут
быть изменены как самим Владельцем Продукта, так и по его указанию.
Элементы вверху списка обычно лучше детализированы, чем элементы внизу.
Чем детальнее и яснее описание Элементов Бэклога Продукта, тем точнее может быть
их оценка. В свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем
меньше они детализированы.

Бэклог спринта
Бэклог спринта (Sprint Backlog SB) – это набор элементов Product Backlog,
выбранных для выполнения в текущем спринте.
SB – это прогноз и обязательства Scrum-команды относительно
функциональности, которая станет частью разрабатываемого инкремента за время
спринта.
Бэклог спринта:
– наполняется во время планирования работ на спринт;
– визуализируется на доске задач;
– определяет тот объем работы, которую Scrum-команда должна выполнить,
чтобы превратить требования и задачи в готовый для использования в бизнес-процессах
инкремент.

10
 Бэклог спринта должен быть достаточно "глубоко" детализирован по сравнению
с задачами в Product Backlog, чтобы прогресс работы над ним можно было видеть
ежедневно, не уделяя дополнительное время сбору необходимых деталей.
Scrum-команда работает над бэклогом спринта на всем его протяжении, и он
постоянно изменяется вместе с прогрессом команды.
Изменения происходят потому, что в процессе работы возникают всё новые и
новые задачи, которые нужно выполнить для достижения конечного результата.
Если возникает необходимость в дополнительном объеме работы, то эти задачи
добавляются в бэклог продукта и планируются к выполнению в следующих спринтах.
После того как они выполнены, оценки оставшегося объема работ обновляются.
Если некоторые задачи считаются уже неактуальными, то их удаляют.
Только Scrum-команда может изменять свой бэклог во время спринта. По
решению команды и ее участников задачи могут добавляться или удаляться, но
необходимо четко обосновать, почему это необходимо.

Инкремент продукта
Цель команды Scrum в отдельно взятом спринте – предоставлять работающий
инкремент продукта.
Работающий "прирост" продукта (инкремент) – обязательный результат каждого
спринта Scrum.
Инкремент по своей сути – это продукт, который будет приносить бизнес-пользу
в момент своей разработки после того, как результаты определенного спринта
реализованы Scrum-командой и приняты заказчиком.

Наглядный пример инкремента в строительстве.

Левая часть иллюстрирует неинкрементальный процесс организации постройки

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

К концу Спринта Инкремент должен быть «Готов», что подразумевает его

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

11
 Критерии Готовности
Когда Элемент Бэклога Продукта или Инкремент описывается как «Готовый»,
каждый в команде должен понимать, что именно означает «Готовый». Хотя понимание,
при каких условиях работа является выполненной, может значительно отличаться от
команды к команде, оно должно быть едино для всех участников одной Скрам-команды.
Это необходимо для обеспечения прозрачности.
Решение о готовности Инкремента продукта принимается исходя из Критериев
Готовности, принятых Скрам-командой.
Если над выпуском одной системы или продукта работает несколько Скрам
Команд, то их Команды Разработки должны совместно выработать Критерии
Готовности.
Каждый Инкремент прибавляется ко всем предыдущим Инкрементам и
тщательно тестируется, чтобы убедиться, что все Инкременты работают вместе.
По мере того, как Скрам-команда будет становиться более зрелой, Критерии
Готовности, скорее всего, будут становиться строже, обеспечивая более высокое
качество разрабатываемого продукта. Применение новых критериев может привести к
тому, что в уже принятых «Готовых» Инкрементах обнаружится работа, которую
необходимо будет выполнить.
Любая система или продукт должны иметь Критерии Готовности, это
обязательный стандарт для любой выполняемой работы в рамках этой системы или
продукта.

12
 Лекция 6
Методологии разработки программного обеспечения (ч.4)

Планирование спринта

При использовании Scrum в качестве основной методологии при разработке

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

Принцип быстрого планирования

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

Для Scrum подходит вид планирования, при котором работа, которую надо будет
выполнить в ближайшей перспективе, подробно планируется с глубоким раскрытием
структуры необходимых работ. Далеко отстоящая работа планируется с относительно
неглубоким раскрытием иерархии работ. По мере выполнения глубоко раскрытой и
понятной работы производится более подробное планирование последующих задач с
возможной корректировкой общих целей.
Но тут появляется проблема: не всегда есть возможность прогнозировать даже
ближайшее будущее, даже в процессах и командах с постоянным прогрессом. Поэтому
планирование выполняется «волнами» или этапами, где действия ближнего этапа
детально планируются, а действия в далеком будущем отложены. Необходимо
выполнять столько волн планирования, сколько итераций работы необходимо провести
для достижения конечного и удовлетворяющего потребностям результата.
Такой подход к планированию называется планированием методом «набегающей
волны».
Он наиболее полно соответствует принципам Scrum и поддерживает процесс
поэтапной разработки программного продукта.

Поэтапное уточнение планов

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

1
 Эта деятельность прекрасно сочетается с техникой планирования методом
набегающей волны и называется поэтапным уточнением ранее намеченных планов.

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

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

Поэтапное уточнение планов происходит на Backlog grooming

Backlog Grooming — это регулярные мероприятия по уходу за бэклогом продукта.
По факту, это особый вид встреч команды, в ходе которой происходит анализ,
расстановка приоритетов и подготовка к планированию спринта. Backlog Grooming
позволяет решить 3 задачи:
– Подготовка задач разработки к их реализации
– Задачу необходимо декомпозировать, т.е. разбить на более мелкие подзадачи,
определить ее важность и приоритет.
– Уточнение актуальности
Все задачи из бэклога пересматриваются, их актуальность уточняется —
возможно, некоторые задачи уже потеряли актуальность или, наоборот, спустя время
стали более важными

Актуализация данных
Имеющаяся информация о задачах актуализируется, отсутствующая
запрашивается или добавляется.
Не следует совмещать встречу для Backlog Grooming с планированием спринта.
Груминг в обязательном порядке должен проводится в формате отдельной встречи.
Именно груминг позволит проработать имеющиеся задачи к этапу планирования
спринта. На груминге обязательно должен присутствовать владелец продукта и scrum-
команда. По возможности стоит пригласить представителя клиента.

Этапы проведения Backlog Grooming

1. Чистка списка задач. Удаляются из бэклога неактуальные задачи.
2. Дополнение бэклога. Добавляются новые задачи разработки, сформированные
на основе списка потребностей бизнеса.
3. Декомпозиция. Разбиваются объемные задачи на небольшие, которые могут
быть решены отдельно друг от друга. Следует помнить, что каждая такая подзадача
должна нести в себе ценность для проекта и потребителей.
4. Расстановка приоритетов. Актуализируется приоритет имеющихся задач,
приоритезируются новые.
5. Оценка задач. Оцениваются пользовательские истории, ранее не
подвергавшиеся оценке. Если в бэклоге присутствуют задачи, по которым изменилась
или дополнилась информация, они переоцениваются.
6. Суммирование опыта. Заключительный этап Backlog Grooming, в ходе которого
командой оптимизируется план развития продукта на основе опыта, полученного в
течение предыдущих спринтов.

Результат хорошего груминга

Результатом grooming является здоровый вид бэклога:
– Когда задач вверху бэклога достаточно для 2-3 спринтов
2
 – Пользовательские истории понятны всем членам команды
– Истории оценены командой
– User stories имеют размер, позволяющий реализовать несколько из них за один
спринт

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

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

Одной из наиболее эффективных методик оценки работ, применяемых в гибких

методологиях разработки программного обеспечения, является техника Planning Poker
(впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-
манифеста).

Техника Planning Poker (покер планирования)

Planning Poker (PP) − это коллективное обсуждение задачи или проблемы с целью
выработки единой оценки по ее решению. Этот вид техники оценки основан на
достижении договоренности между всеми участниками команды, участвующими в
процессе планирования.
Суть подхода состоит в том, что оценка задач выполняется не в виде часов или
альтернативных шкал, представляющих трудозатраты, а в виде сравнительной оценки
(story points), которая показывает относительный «размер» требований. Можно
встретить Scrum-команды, которые оценивают работы в виде «пунктов», «попугаев»,
«маек», «грибов» и т.д. Важны относительные значения, и не может быть абсолютного
эталона. Единицы измерения не имеют физического эквивалента.
В процессе проведения PP вся команда должна прийти к единому пониманию
размеров, чтобы представление о том, сколько сил затратить на реализацию задачи, у
всех было одинаковым.

Подготовка
Для проведения покера планирования необходимо подготовить список
обсуждаемых функций и несколько колод пронумерованных карт. Список функций
(product backlog) либо пользовательские истории (user stories) описывают
разрабатываемое программное обеспечение. Карты в колодах должны быть
пронумерованы. Обычно колода содержит карты, содержащие числа Фибоначчи,
3
включая ноль: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; другие разновидности колод могут
использовать аналогичные последовательности. Например, одна из имеющихся в
продаже колод содержит следующую последовательность: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40,
100. (Ноль означает, что функция или уже реализована, или настолько мала, что нет
смысла присваивать ей число.)

В колоде могут быть также специальные карты:

− знак вопроса (?), означающий неуверенность;
− бесконечность (∞), означающая, что обсуждаемая функция или принципиально
не может быть реализована, или слишком велика, чтобы присваивать ей число;
− чашка кофе (☕) (может быть пивной бокал), означающая требование перерыва.

Аргумент в пользу использования последовательности Фибоначчи — отражение

возрастающей неопределённости с ростом сложности оцениваемых функций или задач.
Некоторыми организациями используются обычные игральные карты,
включающие туз, 2, 3, 5, 8 и короля. Король буквально означает: «Данный пункт
слишком большой или его слишком сложно оценить».
Закономерность чисел на картах, независимо от того, какой ряд выбран, сводится
к следующему: 0 — задача настолько проста или настолько близка к завершению, что
нет смысла выделять ей место в плане, 1-3 — мелкие задачи, 5-13 — задачи средней
сложности, 20-40 — крупные задачи, 100 — глобальная задача, ∞ - эпохальная по
масштабности и важности задача.

Процедура проведения
Каждому участнику обсуждения выдаётся по одной колоде карт. Все колоды
идентичны друг другу.
Scrum-мастер, не участвующий в обсуждении, ведёт собрание.
Владелец продукта представляет краткие обзоры каждого пункта из бэклог.

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

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

Достоинства метода
 В планировании участвует вся команда.
 У каждого члена команды есть возможность высказаться, не испытав влияния
более авторитетных коллег.
 Все члены команды берут на себя ответственность за сроки.
 Оценки, полученные PP, более точные в сравнении с оценками, полученными с
помощью альтернативных методов оценок.
 Техника PP минимизирует эффект привязки путём опроса каждого из
участников команды таким образом, что никто не знает чужого решения до
одновременного оглашения выбора каждого из участников.

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

Если начинающий обсуждение говорит: «Думаю, это займёт 50 дней», — он
сразу устанавливает рамки мышления остальных участников; возникает эффект
привязки, то есть число 50 подсознательно будет отправной точкой для всех
участников.
Те, кто хотел назвать число 100, захотят уменьшить свою оценку, а те, кто
задумал число 10, захотят увеличить её. Это становится серьёзной проблемой, если
число 50 произносится влиятельным участником в то время, когда остальная команда
преимущественно останавливает свой выбор на бо́льших или меньших значениях

Правила, которым подчинена техника Planning Poker:

 Scrum-мастер не участвует, а только ведет общее собрание.
 Владелец продукта представляет краткие обзоры каждой из задач.
 Члены команды задают вопросы и ведут дискуссию о предложениях и рисках.
 Итог обсуждения записывается Scrum-мастером.

Если речь идет о команде, которая раньше не работала вместе, или

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

Диаграмма сгорания работ

Один из самых важных артефактов, которые использует Scrum-команда для
контроля за запланированными показателями выполнения работ в течение спринта, −
диаграмма сгорания работ (Burndown Chart).

5
 Синим на диаграмме сгорания отмечена идеальная линия выполнения задач, на
которую и следует опираться.
Красным отмечена реальная история выполнения задач.
По шкале Y отмечают количество запланированных story points. По шкале X
отмечают количество дней до окончания Sprint.

Цель каждой Scrum-команды - "сжечь" все взятые в спринт задачи до того, как
приблизится конец намеченного срока. Если фактическая кривая отличается от
идеальной, то по ситуации необходимо корректировать действия команды.

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

оставшихся "пунктов" путем сравнения реального графика с идеальным:

 Если реальный график выше идеального − значит, команда отстает от плана

(опоздали)

6
 Один из видов негативных диаграмм сгорания задач.
Одной из возможных причин здесь может быть постоянное добавление новых задач
во время спринта, что увеличило нагрузку.
Второй частой проблемой является недоделанность задач, когда задачи сделаны
наполовину.
В такой ситуации на Daily Scrum Meeting обязательно нужно говорить о проблемах,
мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла выше,
сразу надо решать проблему – это также один из постулатов методологии Scrum.

 Если реальный график ниже идеального − команда опережает план (слишком

рано).

По «Диаграмме сгорания
задач» (Burndown Chart)
отчетливо видно, что команда
все задачи выполнила раньше
срока. Такая ситуация тоже не
является позитивной, так как
это означает ряд совершенных
проблем:
Команда сделала
неправильную оценку
предстоящей работы;
В случае быстрого
выполнения задач
разработчики не добавляли
задачи из следующего спринта;
Команда сильно перестраховалась, включив изначально дополнительный срок.
В случае такой проблемы чаще всего Scrum Master спрашивает команду о
возможности добавления дополнительных задач из Product Backlog.

 Без оценок.
Команда работала, но забыла
или не захотела использовать
диаграмму (дурной тон)

7
  Конечная оценка.
Равна предыдущей.
Оценки были внесены в
диаграмму в последний
день после завершения
работы.

 Zero.
Либо работа не
производилась, либо не
оценивалась. Сделать
выводы нельзя. Команда
не стремилась к
развитию.

 Релаксирующая команда.
Похоже на «слишком рано»,
но решили не заканчивать
раньше, а более расслабленно
вели работу.

8
  Совершенствование.
По линиям видно, что
вначале были трудности, но
во время Daily все вопросы
вскрывались (возможно,
были дополнительные
задачи)

 Опыт.
Опытная команда, сразу
преодолевает трудности и
совершенствуется так, что
переходит к активному
сжиганию задач.

 А++.
Бесконечно можно смотреть
на три вещи: как горит огонь,
как течет вода и как строится
идеальный график.

9
 Лекция 7
Методологии разработки программного обеспечения (ч.5)

Спринт
Спринт служит ядром Скрама. Спринт — временной отрезок длительностью
месяц или меньше, в течение которого создается «Готовый», то есть пригодный к
использованию и выпуску Инкремент продукта.
Желательно сохранять неизменную продолжительность Спринта на протяжении
всего процесса разработки. Новый Спринт начинается сразу после окончания
предыдущего.

Цель Sprint
Это краткое описание бизнес-цели, ради которой выполняется данный спринт.
В методологии Scrum по завершении спринта должен обязательно получиться
готовый продукт, который можно передавать заказчикам. Стоит, однако, понимать, что
это может быть не законченный продукт как таковой, ведь он может
совершенствоваться бесконечно. Здесь нужно держаться ориентира: окончание спринта
= рабочий продукт, на котором можно что-то делать. Следующий спринт уже, к
примеру, улучшает его, и, опять же, в конце спринта даёт полностью рабочий продукт.
Жизненный цикл методологии Scrum состоит из подготовительных этапов для
спринта и завершающих этапов. На каждом этом этапе существуют различные события.

Таким образом, спринт состоит из Планирования Спринта, Ежедневного Скрама,

разработки, Обзора Спринта и Ретроспективы Спринта.
Во время Спринта:
• не допускаются изменения, которые могут поставить под угрозу Цель Спринта;
• качество продукта не должно снижаться;
• по мере появления новых знаний, объём работ может быть уточнен и заново
согласован между Владельцем Продукта и Командой Разработки.

1
 Остановка Спринта (Abnormal Termination, Отмена Спринта)
Спринт может быть отменен досрочно. Право на отмену Спринта имеет только
Владелец Продукта, хотя на данное решение могут повлиять заинтересованные лица,
Команда Разработки или Скрам-мастер.
Существует единственное основание для отмены Спринта — потеря актуальности
Цели Спринта. Причиной этому могут быть смена направления работы компании,
изменения рыночных условий или технологий. То есть Спринт может быть отменен,
если он потерял смысл в контексте сложившихся обстоятельств. Но подобные отмены
происходят крайне редко благодаря короткой длительности Спринтов.
При отмене Спринта все завершенные и «Готовые» Элементы Бэклога Продукта
пересматриваются. Владелец Продукта принимает часть работы, представляющую
готовый к выпуску Инкремент. Все незаконченные Элементы Бэклога Продукта
переоцениваются и возвращаются обратно в Бэклог Продукта. Недоделанная работа по
этим Элементам быстро теряет ценность, поэтому её нужно пересматривать и оценивать
в новых условиях.
Отмена Спринта требует много усилий и ресурсов, так как предполагает
переориентацию всех участников, чтобы начать новый Спринт и его Планирование.
Отмены Спринта болезненны для Скрам-Команды, поэтому к ним прибегают крайне
редко.

Планирование Спринта
Как и все основательные дела в нашей жизни начинаются с планирования, так и
сам Scrum Sprint начинается с планирования, только не обычного, а специального, со
своими законами и порядками. На первых митингах встречаются Development Team,
Scrum Master, Product Owner, Managers, Stakeholders. Первая встреча называется Sprint
Planning Meeting.

Задачи, над которыми будет трудиться Команда Разработки во время Спринта,

определяются на Планировании Спринта. План создается совместными усилиями всей
Скрам-Команды.
Планирование Спринта ограничено по времени. Для Спринта длительностью
один месяц Планирование не должно занимать более 8 часов. Если Спринт короче, то и
Планирование проводится быстрее.
Скрам-мастер убеждается, что событие состоялось, а участники понимали его
цель. Скрам-мастер обучает Скрам-Команду соблюдать временное ограничение.
По результатам Планирования Спринта Скрам-команда решает:
• каким будет Инкремент в конце Спринта;
• как организовать работу, чтобы получить готовый Инкремент Продукта.

Тема первая: что будет сделано?

Команда Разработки прогнозирует объём функциональности, который будет
разработан в течение Спринта. Владелец Продукта выносит на обсуждение два важных
вопроса: бизнес-цели, которые должны быть достигнуты в Спринте, и Элементы
Бэклога Продукта, необходимые для достижения Цели Спринта. На основании этих
данных Скрам Команда формирует единое понимание о всей работе в Спринте.

2
 Для проведения Планирования Спринта нужны: Бэклог Продукта, последний
Инкремент продукта, прогноз возможностей Команды Разработки в будущем Спринте,
статистика её прошлой производительности.
При этом только Команда Разработки определяет количество Элементов Бэклога
Продукта, которые могут быть выполнены в Спринте. Ей же принадлежит
исключительное право оценивать объём работ, который по силам завершить в текущем
Спринте. Во время Планирования Спринта Скрам-команда также формирует Цель
Спринта.

Тема вторая: как будет выполнена работа?

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

Ежедневный Скрам
Ежедневный Скрам – это встреча Команды Разработки, которая проводится
каждый день во время Спринта. Встреча не должна занимать более 15 минут, за которые
Команда разработки планирует свою работу на ближайшие 24 часа. Команда
оптимизирует взаимодействие между её членами и повышает свою производительность,
анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт
работу. Для упрощения Ежедневный Скрам проводится каждый день в одно и то же
время.
Команда Разработки использует это событие для отслеживания прогресса по
работе над Бэклогом Спринта, а также для того, чтобы понять, успевает ли она
завершить задачи Спринта в срок.
Команда сама определяет формат встречи, но акцент всегда остается на
достижении Цели Спринта. Какие-то команды проведут дискуссию, какие-то будут
использовать вопросы,
например:
• Что я сделал вчера, что помогло Команде Разработки приблизиться к Цели
Спринта?
• Что я сделаю сегодня, чтобы помочь Команде Разработки достичь Цели
Спринта?
• Вижу ли я какие-либо препятствия, которые могут помешать мне или Команде
Разработки достичь Цели Спринта?
Часто сразу после Ежедневного Спринта Команда Разработки в полном составе
или её отдельные участники встречаются для более детального обсуждения, или для
изменения, или перепланирования оставшейся в Спринте работы.

3
 Скрам-мастер следит, чтобы встреча Команды Разработки состоялась, но за
проведение Ежедневного Скрама отвечает сама команда. Скрам-мастер обучает
Команду Разработки проводить Ежедневный Скрам за 15 минут или быстрее.
Ежедневный Скрам — это внутренняя встреча Команды Разработки. Если на ней
присутствует кто-то ещё, Скрам-мастер следит, чтобы они не мешали встрече.

Обзор Спринта
Обзор Спринта проводится в конце Спринта с целью инспекции Инкремента и, по
необходимости, адаптации Бэклога Продукта.
Скрам-команда и заинтересованные лица во время Обзора Спринта совместно
обсуждают, что было сделано за Спринт. Эти данные, как и любые изменения Бэклога
Продукта в течение Спринта, служат основанием для обсуждения следующих шагов к
оптимизации ценности Продукта.
Обзор Спринта — не статусная встреча, а неформальная. На ней проводится
демонстрация Инкремента Продукта для получения обратной связи и развития
сотрудничества. Для Спринтов длительностью один месяц продолжительность встречи
не превышает 4 часов.

Чем короче Спринт, тем короче его Обзор.

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

понимали её цель. Скрам-мастер обучает всех участников укладываться в отведенное на
событие время.

Ключевые элементы Обзора Спринта:

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

4
 Ретроспектива Спринта
Ретроспектива Спринта — это возможность для Скрам-команды провести
инспекцию, направленную на себя, и создать план улучшений командной работы в
следующем Спринте.
В качестве примера можно привести автомобиль и замену его масла. Грубым
интервалом замены масла считается порядка 15 000 км., то есть через такое число
километров необходимо слить старое масло и залить новое, иначе качество работы
двигателя может ухудшиться или, более того, это может привести к серьезной поломке
автомобиля и даже его выходу из строя. Scrum Team также нуждается в подобной
«замене масла», чтобы работа всегда была в наивысшей степени эффективной.

Ретроспектива Спринта проводится после Обзора Спринта и перед

Планированием следующего Спринта.
У ретроспективы нет очень сильных временных ограничений, но есть формула
золотой середины: длина Sprint Retrospective Meeting равна 75% часа (45 минут),
умноженные на количество недель в Sprint. Если у вас четырехнедельный Спринт, то
время на ретроспективу в Scrum следует выделить равное 60 * 0.75 * 4 = 180 минутам.
То есть на ретроспективу следует потратить 180 минут, что равняется трем часам.
Иногда, правда, некоторые команды не придерживаются этой формулы и просто
отводят час для такого анализа, а если происходят горячие споры, то время
увеличивается.
Скрам-мастер убеждается, что событие проходит позитивно и продуктивно,
обучает всех участников укладываться в отведенное на событие время. Он принимает
участие в Ретроспективе наравне с другими членами команды, но продолжает нести
ответственность за Скрам-процесс.

Самым распространенным и простым способом (что не отменяет его

эффективности), является способ Start-Stop-Continue.
При этом способе каждого члена команды просят определить, какие конкретные
вещи должна делать команда, а какие нет, а также какие действия необходимо
продолжить. Он распределяет свои ответы по трем возможным вариантам:
Начать делать;
Прекратить делать;
Продолжить делать.
Опять же, варианты исполнения здесь могут быть разными. На самом деле для
ведения более эффективных встреч и нужен Scrum Master, который, к примеру, может
попросить команду выкрикнуть идеи во время схватки. Scrum Master может так и не
делать, а вообще пойти по кругу и попросить каждого участника назвать одну любую
вещь на выбор, которую команда должна начать делать, или прекратить, или
продолжить.
После мозгового штурма Sprint Retrospective Meeting может начаться голосование
по конкретным вопросам, которые будут учитываться в следующем спринте. В
следующей ретроспективе будут рассматриваться оставшиеся пункты из прошлой
встречи.

5
 Пример Sprint Retrospective Meeting в разработке интернет-магазина
После завершения Sprint и проведения Sprint Reviews Meeting, команда Scrum
собралась для обсуждения эффективности её работы, которая была оценена каждым
самостоятельно.
Scrum Master решает задать вопрос каждому лично и узнать ответы на все три
вопроса.
Участник №1:
1. Я считаю, что команде следует начать использовать более развернутые
листы тестирования
2. ----
3. Я считаю, что команда должна продолжить использовать текущий вид
Product Backlog, он оптимально подходит.

Участник №2
1. -----
2. Мне кажется, команде надо прекратить использовать текущую IDE, её
«неповоротливость» замедляет работу.
3. Команде однозначно следует продолжить использовать текущую систему
контроля версий и облачных сохранений, с ней мы менее беспокоимся о потерях и более
концентрируемся на работе.

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

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

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

как с Scrum, так и с его участниками:
Команда полагает, что у нее нет проблем, Scrum-процесс хорош, и она не видит
смысла в его улучшении. Ошибка. Но команде этого так просто не объяснить. Чтобы
сдвинуть ее с мертвой точки, полезно пригласить на ретроспективу кого-то из
менеджеров компании − заказчика или пользователей, которые имеют конкретные
претензии к команде или продукту. Пользователи очень редко полностью
удовлетворены. Они могут быть удовлетворены до определенной степени, но у них все
равно есть какие-то мысли на тему того, что можно сделать лучше. Если такой заказчик
приходит на ретроспективу и рассказывает это команде, то она вынуждена обсуждать
направления для дальнейшего развития.
На ретроспективе говорит в основном один или 2-3 человека. Ошибка. Людям
всегда есть что сказать. Если внимание забирает негласный лидер, то своим
доминированием он подавляет остальных членов команды. Если каждый будет
высказывать свое мнение, то вероятность найти лучшие решения намного возрастет.
Групповая дискуссия побуждает всех участников высказываться. Это помогает
посмотреть на проблему с разных точек зрения и придумать лучшее решение. Часто
справиться с этой проблемой помогает ведущий ретроспективы, который будет следить
за тем, чтобы каждый из присутствующих обязательно высказал свою точку зрения.

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

Velocity Scrum
Если представить себе движение автомобиля, то скорость в нём оценивается по
спидометру. Глядя на него всё предельно ясно. Однако в жизни в целом и в каком-то
конкретном деле нет спидометра, и как оценить скорость объективно – уже вопрос.
Если представить, что в автомобиле сломался спидометр, то скорость может быть
оценена постфактум, то есть когда человек будет ехать 60 минут и проедет, например,
100 км, затем за 60 минут – 120 км, то он будет видеть, с какой скоростью двигался –
около 110 км/ч. При этом, если во время следующих 60 минут он остановится и потратит
на заправку 12 минут, на обед 15 минут и проедет 55 км, то средняя скорость за весь
путь составит – 98 км/ч.

Как и при движении на автомобиле, скорость можно измерять и в Scrum, и

называется это Velocity (скорость).
Расчет Scrum Velocity очень простой и также состоит из поставленных отметок,
как, например, определённое количество километров через каждые 60 минут.
Для примера предоставим график Velocity, отображающий по горизонтальной оси
количество Sprints, а по вертикальной – Story Points.

7
 В таком графике, по сути, изображено Story Points, и на основе этих показателей
выстраивается среднее значение скорости. Однако график Velocity может быть и иной,
с простым отображением Story Points, на основе которых визуально видна тенденция.

Если сравнивать с движением по дороге, то список ассоциаций, влияющих на

скорость, может быть такой:
Дорога – она же препятствия;
Топливо – мотивация, что движет нами;
Опыт водителя – знание / опыт / компетенция разработчика;
Условия для автомобилей – DEV-среда;
Видимость – прозрачность проекта;
Направление – цели проекта;
Трафик / правила вождения – процессы;
8
 Пункт назначения – продукт.
Хочется, однако, отметить, что по поводу метрики Velocity в Scrum ходят споры,
и кто-то считает данные графики не очень полезными и сложными в определении
возможных проблем, да и самого разгона. В целом все сходятся во мнении, что Velocity
должен использоваться специалистом как дополнительное наглядное отображение
эффективности, которое, как калька, накладывается на другие данные, помогая
скорректировать аналитическую работу Scrum Master.

Скрам над скрамом (SCRUM of SCRUMs)

Если коллектив больше 11 человек, то команда больше рекомендуемого SCRUM
размера. Для расширения SCRUM предложена методика SCRUM of SCRUMs.
Тогда коллектив разбивается на несколько SCRUM-команд. В каждой cвой скрам-
мастер и скрам-владелец продукта.

Ведя свою команду к цели спринта, можно успешно достигнуть её, но при этом
упустить, что происходит на уровне продукта. А ведь порой из-за этого нарушается
целостность всей разработки.
Представьте, что вы едете на автомобиле в сторону цели, параллельно едет ещё
одна команда, но между вами находится преграда, и вы понятия не имеете, как движутся
соседи. Если представить, что обе команды везут некий груз и успех всей поездки
зависит от того, обе ли команды довезли его в сохранности, то их взаимодействие
просто необходимо.
Подобные встречи могут касаться вопросов взаимной интеграции или разговора о
проделанной работе и ближайших планах. Одним из важных плюсов таких встреч
является то, что со стороны можно увидеть те проблемы, которые не видно вблизи.

Команды проводят Daily SCRUM.

После ежедневного скрам-совещания проводится митинг SCRUM of SCRUMs

(SoS).

9
 Это значит следующее: От каждой команды выбирается по представителю.
Представители разбиваются по 5-9 человек. Каждой группе назначается главный скрам-
мастер (Chief SCRUM Master) и главный скрам-владелец продукта (Chief SCRUM
Product Owner) из числа скрам-мастеров и скрам-владельцев продукта, участвующих в
проекте. Команда представителей из разных SCRUM Team называется SCRUM of
SCRUMs Team. В таком составе проводят 15-минутный стоячий скрам-митинг —
SCRUM of SCRUMs (SoS) или Meta SCRUM или Scaled Daily SCRUM(SDS).
Рекомендуется проводить SCRUM of SCRUMs каждый день.
Однако некоторые команды SCRUM of SCRUMs проводят не каждый день, а 2—
3 раза в неделю. Это нарушает базовые принципы SCRUM и является классическим
примером SCRUMbut. Это не позволяет в полной мере использовать все преимущества
SCRUM.
SCRUM of SCRUMs позволяет нескольким скрам-командам обсуждать работу,
фокусируясь на общих областях и взаимной интеграции. Главный скрам-мастер задает
всем членам SCRUM of SCRUMs-команды четыре вопроса, три первых вопроса
повторяют вопросы Daily SCRUM:
1. Что каждая команда сделала с момента предыдущего совещания SCRUM of
SCRUMs для достижения цели спринта?
2. Что каждая команда сделает к следующему ежедневному совещанию SCRUM
of SCRUMs для достижения цели спринта?
3. Есть ли проблемы, мешающие команде достичь цели спринта?
4. Нужно ли другой команде сделать что-то из задач вашей команды для того,
чтобы помочь ей достичь цели спринта?
Если SCRUM of SCRUMs не охватывает весь коллектив, может быть проведен
митинг SCRUM of SCRUM of SCRUMs (SCRUM-3, SoSoS), SCRUM of SCRUM of
SCRUM of SCRUMs (SCRUM-4, SoSoSoS), и так далее. Последний MetaSCRUM
называется Executive Meta SCRUM(EMS) или Executive Action Team (EAT). Такой
подход позволяет всего за час организовать работу 4096 человек.
Порядок проведения SCRUM of SCRUMs такой же как у Daily SCRUM -
 в одно и то же время, в одном и том же месте,
 все могут наблюдать, но только разработчики говорят,
 в митинге участвуют Chief SCRUM Master, Chief SCRUM Product Owner и
SCRUM of SCRUMs Team,
 длится ровно 15 минут,
 все участники SCRUM of SCRUMs стоят (митинг в формате Daily Standup).

SCRUMbut
Только следуя всем правилам SCRUM, можно прийти к успеху проекта. Каждый
принцип SCRUM приносит прибыль, а отказ от него — убыток. В этом заключается
особенность SCRUM.
SCRUMbut — это использование лишь части принципов SCRUM, сохраняя
убежденность в работе по SCRUM. Это не только не позволяет в полной мере
использовать все преимущества SCRUM, но и ухудшает производительность по
сравнению с полным отсутствием методологии.
Исследования показали, что SCRUMbut снижает ежегодную прибыль с 400 % до
0—35 %. При этом за 100 % принята производительность работы по «водопаду», а за
400 % — по SCRUM.
10
 Классические примеры SCRUMbut:
Проведение Daily SCRUM или SCRUM of SCRUMs не каждый день
Отсутствие ретроспектив
Спринты длиннее 4 недель
Отсутствие Definition Of Done
Большое число примеров SCRUMbut приведено на сайте Джеффа Сазерленда —
SCRUM ALLIANCE.

LeSS — Scrum на больших масштабах

Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших

масштабах.
LeSS — это Скрам, применяемый к множеству команд, работающих совместно
над одним продуктом.Это не новый или улучшенный Скрам. И это не разделение на
«Скрам на уровне каждой команды» и «что-то другое на уровне выше».
Масштабированный Скрам — это тот же Скрам, но работающий на большем масштабе.
В LeSS основная часть команд — это кросс-функциональные, обладающие всеми
необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9
нацеленных на обучение участников, выполняющих всю работу (от пользовательских
интерфейсов и разработки до снятия продуктовых метрик) для создания полноценного
рабочего продукта.
Эти команды работают вместе над одним Бэклогом Продукта, потому что у них
есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к
поставке продукт, и каждая команда вовлечена в это, потому что она является не
компонентной, а продуктовой командой (feature-team), и отвечает за end-to-end продукт,
а не только за его отдельную часть.

11
 Что представляет собой продукт в LeSS? Это полноценное (end-to-end),
клиенториентированное решение, которое будет использоваться реальными людьми.
Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или
библиотека.
LeSS включает в себя:
 фундаментальные принципы, формирующие основу для других элементов
LeSS;
 два процессных фреймворка;
 руководства по запуску LeSS в компании;
 реальные эксперименты в компаниях, которые привели к созданию LeSS.

Скрам на больших масштабах состоит из двух фреймворков:

LeSS — от 2 до 8 команд;
LeSS Huge — 8+ команд.

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

LeSS Huge
В какой-то момент, когда один Владелец Продукта более не может держать в
голове полный контекст, у него не получается соблюдать баланс между внутренними и
внешними коммуникациями, а Бэклог Продукта разрастается настолько, что один
человек более не способен с ним справляться. Это сигнал для перехода от обычного
LeSS к LeSS Huge.
В LeSS Huge по-прежнему есть один владелец Продукта, но у него есть команда
помощников (Area Product Owners). В LeSS Huge работа над продуктом разделяется по
12
Областям Требований (Requirement Areas). Область требований — это не компонент
продукта, а определённая группа end-to-end функционала продукта с точки зрения
клиента, то есть каждый элемент Бэклога Области Требований (Area Backlog) несет
конечную ценность для клиента. Работа над Requirement Area осуществляется Area
Product Owner и от 3-х до 8-ми команд.

13
 Лекция 8
Методологии разработки программного обеспечения (ч.6)

Lean
В конце 1973 года арабские члены Организации стран-экспортеров нефти (ОПЕК)
заявили о прекращении поставок нефти в страны, поддержавшие Израиль в
Октябрьской войне того же года. Прямым ударом затронуло США и большинство стран
Западной Европы, косвенным - почти весь мир. Принятое ОПЕК решение привело к
крупнейшему энергетическому кризису XX века. В течение года цены на баррель нефти
выросли в 4 раза. Многие государства ввели особые условия продажи бензина
автолюбителям, что негативно сказалось на продажах автомобилей по всему миру.
Автомобильные компании терпели значительные убытки, многие из них
обанкротились. На фоне общего упадка выгодно отличалась японская компания Toyota:
в тяжелых условиях кризиса она не только не пострадала, но и грамотно
воспользовалась резко возросшей популярностью экономичных малолитражных
автомобилей: уже в 1975 году Toyota обошла Volkswagen по количеству проданных
автомобилей в США. Успех Toyota был обусловлен не только общеизвестным
трудолюбием японцев, но и особенной концепцией менеджмента - Toyota Production
System. Эта концепция основана на истреблении всех ненужных трат. Именно эта
бережливость в производстве помогла компании остаться на плаву во время кризиса.
Оценив успех Toyota, другие японские автомобилестроительные компании также
начали использовать ее принципы управления. Как следствие, в 1980х годах японские
автомобили заполнили рынок США.

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

предприятием, основанная на постоянном стремлении к устранению всех видов потерь.
Бережливое производство предполагает вовлечение в процесс оптимизации бизнеса
каждого сотрудника и максимальную ориентацию на потребителя.
Бережливая разработка программного обеспечения − методология разработки
программного обеспечения, использующая методы концепции бережливого
производства.
Бережливая разработка программного обеспечения впервые освещена в
одноимённой книге Мэри Поппендик и Toма Поппендика. В книге представлены
традиционные принципы бережливого производства применительно к разработке
программного обеспечения, также набор из 22 инструментов (практик) и их сравнение
с гибкой методологией разработки.
Lean добавляет к принципам Agile схему потока операций (workflow) для того,
чтобы каждая из итераций выполнялась одинаково качественно.
Так же, как и в Scrum, в Lean работа разбивается на небольшие пакеты поставки,
которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета
поставки существует поток операций с этапами. Как и в классическом проектном
менеджменте, это могут быть этапы планирования, разработки, производства,
тестирования и поставки – или любые другие необходимые для качественной
реализации проектов этапы.

1
 Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть
проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов,
как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического
проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на
разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов.
Как и Agile, Lean это скорее концепция, образ мышления. Это не методология,
поэтому в ней нет набора готовых практик. Конкретных правил тоже нет, но есть
приемы, которые помогают извлекать пользу. Но как разобраться, что значит Lean, если
нет методологии и правил? И как придерживаться философии, в которой не на что
опереться?
Придерживаться Lean ― значит всегда использовать системный подход, искать и
устранять потери, создавать поток. Поток ― это непрерывный процесс создания
ценности — не любого продукта, а именно того, который нужен потребителю.

Принципы бережливого производства

 Исключение потерь. Потерями считается всё, что не добавляет ценности для
потребителя.
В японском языке траты обозначаются как 無駄, что в звуковом эквиваленте
представляется как "мУда". Это слово теперь активно используется в компаниях,
практикующих бережливую разработку ПО. Простым примером трат в разработке ПО
является незавершенная работа, например, недоделанная и временно замороженная
функциональность. Она периодически требует внимания, когда-то ее придется
доделывать, а пока она не сделана, следует постоянно учитывать ее доработку и
стараться не причинить вред уже написанному. Еще одним примером муды является
лишняя функциональность. Казалось бы, кому она мешает? Само наличие лишней
функциональности вытекает из того, что есть нелишняя функциональность − именно та,
2
которая нужна пользователю. Наличие лишней функциональности замедляет
разработку полезных вещей, приносит дополнительные дефекты и оттягивает внимание
команды.
 Качество
Согласно принципам бережливой разработки, проблему можно либо обнаружить
по факту ее появления, либо заранее устранить причины, приводящие к этой проблеме.
В идеале следует заранее устранять причины проблем, но это, увы, далеко не всегда
возможно. В случае обнаружения проблемы ее следует устранять немедленно. Для этого
стоит двигаться небольшими шагами и проверять качество после каждого шага.
 Знание
Разработка ПО – интеллектуальный процесс, который получает прямую выгоду
от генерирования и накапливания знания. Бережливая разработка ПО рекомендует
проводить практические эксперименты как можно раньше с целью получения
практических знаний о системе, коде или дизайне. Накапливание знания в процессе
разработки ПО позволяет со временем улучшить этот процесс. С ростом сложности
производимой продукции растет и сложность проблем, ей сопутствующих, –
следовательно, лишь генерируя и накапливая знание о причинах проблем и способах их
устранения, можно избежать больших проблем в будущем.
 Предельно отсроченное принятие решений. В какой момент вы будете обладать
самым большим объемом информации о каком-либо событии до его фактического
свершения? За мгновение до этого события. Следуя этой логике, необходимо
откладывать принятие решения как можно дольше, фактически принимая его за
мгновение до момента, когда оно уже должно быть принято. С точки зрения трат такой
подход легко объяснить: чем раньше принимается решение, тем больше риск того, что
что-то изменится и уже принятое решение окажется бесполезной (а может даже и
вредной) мудой. Решения можно разделить на отменяемые и неотменяемые.
Желательно, чтобы все принимаемые решения были отменяемыми − в таком случае их
легко отменить и сделать так, как было раньше. Также есть решения неотменяемые −
те, последствия которых отменить совсем не просто. Принципами бережливой
разработки рекомендуется сделать отменяемыми как можно больше принимаемых вами
решений, а принятие неотменяемых решений отдалить настолько, насколько это
возможно.
 Предельно быстрая доставка заказчику. Откладывание принятия решения
позволяет избежать муды в виде уже не нужных действий. Однако есть и другой способ
избежать этой же муды: можно не давать потребителю времени поменять свой взгляд
на вещи.
 Мотивация команды, уважение. Нельзя рассматривать людей исключительно
как ресурс. Людям нужно нечто большее, чем просто список заданий.
 Интегрирование и Целостное видение. Передать целостную информацию
заказчику. Стремиться к целостной архитектуре. Рефакторинг (Контролируемый
процесс улучшения кода, без написания новой функциональности. Результатом
рефакторинга является чистый код и простой дизайн). Стандартизация, установление
отношений между разработчиками. Разделение разработчиками принципов
бережливости. «Мыслить широко, делать быстро, ошибаться мало, учиться
стремительно».

3
 Сильные стороны Lean
Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого
исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти
требования. Lean сочетает гибкость и структурированность.

Слабые стороны Lean

Не каждая часть проекта требует одинаково детальной и дотошной проработки и
внимания. Но Lean предполагает именно такой подход к каждой задаче и этапу. Это
основной минус применения Lean для крупных и неоднородных проектов.
А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для
реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта
проблема может быть решена при помощи эффективного руководства и чётких
коммуникаций ̶ главное помнить об этом.

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

Экстремальное программирование или XP, eXtreme Programming — гибкая
методология разработки программного обеспечения. Как и у других agile-методологий,
у нее есть особенные инструменты, процессы и роли. Автор XP не придумал ничего
нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому
программирование и зовется экстремальным.
Автор методики — американский разработчик Кент Бек. В конце 90-х он
руководил проектом Chrysler Comprehensive Compensation System и там впервые
применил практики экстремального программирования. Свой опыт и созданную
концепцию он описал в книге Extreme Programming Explained, опубликованной в 1999
году.
XP отличается от других гибких методологий тем, что применимо только в
области разработки программного обеспечения. Оно не может быть использовано в
другом бизнесе или повседневной жизни, как scrum, kanban или lean.
Цель методики XP — справиться с постоянно меняющимися требованиями к
программному продукту и повысить качество разработки. Поэтому XP хорошо
подходит для сложных и неопределенных проектов

Методология XP строится вокруг четырех процессов:

кодирования
тестирования
дизайна
слушания.

Кроме того, экстремальное программирование имеет ценности (принципы):

простоту,
коммуникацию,
обратную связь,
смелость
уважение.

Сформулировал первые 4 из них Кент Бек в своей первой книге.

В новом издании книги он добавил пятый принцип — уважение.

4
 1. Простота
В XP разработка начинается с самого простого решения, которое удовлетворит
текущую потребность в функциональности. Члены команды учитывают только то, что
должно быть сделано сейчас, и не закладывают в код функциональность, которая
понадобится завтра, через месяц или никогда.
2. Коммуникация
В XP коммуникация между разработчиками ведется не посредством
документации, а вживую. Команда активно общается между собой и с заказчиком.
3. Обратная связь
Обратная связь в XP реализуется сразу в трех направлениях:
 фидбек от системы при постоянном тестировании модулей
 фидбек от заказчика, т.к. он входит в команду и участвует в написании
приемочных тестов
 фидбек от команды во время планирования касательно времени на разработку.
4. Смелость
Некоторые методики экстремального программирования настолько непривычны,
что требует смелости и постоянного контроля над собой.
5. Уважение
В экстремальном программировании уважение рассматривается с точки зрения
уважения к команде и самоуважения. Члены команды не должны заливать изменения,
которые поломают компиляцию, модульные тесты, или замедлят работу коллег.
Каждый стремится к высшему качеству кода и дизайна.

13 практик экстремального программирования

1. Вся команда
Все участники проекта с применением XP работают как одна команда. В нее
обязательно входит представитель заказчика, лучше, если это будет реальный конечный
5
пользователь продукта, разбирающийся в бизнесе. Заказчик выдвигает требования к
продукту и расставляет приоритеты в реализации функциональности. Ему могут
помогать бизнес-аналитики. Со стороны исполнителей в команду входят разработчики
и тестировщики, иногда коуч, направляющий команду, и менеджер, который
обеспечивает команду ресурсами.
2. Игра в планирование
Планирование в XP проводят в два этапа — планирование релиза и планирование
итераций.
На планировании релиза команда программистов встречается с заказчиком, чтобы
выяснить, какую функциональность он хочет получить к следующему релизу, то есть
через 2-6 месяцев. Так как требования заказчика часто размытые, разработчики
конкретизируют их и дробят на части, реализация которых занимает не более одного
дня. Важно, чтобы заказчик разбирался в операционной среде, в которой будет работать
продукт.
Задачи записываются на карточки, а заказчик определяет их приоритет. Дальше
разработчики оценивают, сколько времени уйдет на каждую задачу. Когда задачи
описаны и оценены, заказчик просматривает документацию и дает добро на начало
работы. Для успеха проекта критично, чтобы заказчик и команда программистов играли
на одном поле: заказчик выбирает действительно необходимую функциональность в
рамках бюджета, а программисты адекватно сопоставляют требования заказчика со
своими возможностями.
В XP если команда не успевает выполнить все задачи к дате релиза, то релиз не
отодвигается, а режется часть функционала, наименее важная для заказчика.
Планирование итераций проводится каждые две недели, иногда чаще или реже.
Заказчик обязательно присутствует: он определяет функциональность на следующую
итерацию и вносит изменения в требования к продукту.
3. Частые релизы версий
В XP версии выпускаются часто, но с небольшим функционалом. Во-первых,
маленький объем функциональности легко тестировать и сохранять работоспособность
всей системы. Во-вторых, каждую итерацию заказчик получает часть функционала,
несущую бизнес-ценность.
4. Пользовательские тесты
Заказчик сам определяет автоматизированные приемочные тесты, чтобы
проверить работоспособность очередной функции продукта. Команда пишет эти тесты
и использует их для тестирования готового кода.
5. Коллективное владение кодом
В XP любой разработчик может править любой кусок кода, т.к. код не закреплен
за своим автором. Кодом владеет вся команда.
6. Непрерывная интеграция кода
Это значит, что новые части кода сразу же встраиваются в систему — это
происходит каждые несколько часов и чаще. Во-первых, сразу видно, как последние
изменения влияют на систему. Если новый кусок кода что-то сломал, то ошибку найти
и исправить в разы проще, чем спустя неделю. Во-вторых, команда всегда работает с
последней версией системы.
7. Стандарты кодирования

6
 Когда кодом владеют все, важно принять единые стандарты оформления, чтобы
код выглядел так, как будто он написан одним профессионалом. Можно выработать
свои стандарты или принять готовые.
8. Метафора системы
Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать
у команды общее видение. Обычно метафору системы продумывает тот, кто
разрабатывает архитектуру и представляет систему целиком.
9. Устойчивый темп
XP команды работают на максимуме продуктивности, сохраняя устойчивый темп.
При этом экстремальное программирование негативно относится к переработкам и
пропагандирует 40-часовую рабочую неделю.
10. Разработка, основанная на тестировании
Одна из самых трудных практик методологии. В XP тесты пишутся самими
программистами, причем ДО написания кода, который нужно протестировать. При
таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара
программистов заливают код в репозиторий, сразу запускаются модульные тесты. И
ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в
правильном направлении.
11. Парное программирование
Представьте двух разработчиков за одним компьютером, работающих над одним
куском функциональности продукта. Это и есть парное программирование, самая
спорная практика XP. Старая поговорка «одна голова хорошо, а две лучше» отлично
иллюстрирует суть подхода. Из двух вариантов решения проблемы выбирается лучший,
код оптимизируется сразу же, ошибки отлавливаются еще до их совершения. В итоге
имеем чистый код, в котором хорошо разбираются сразу двое разработчиков.
12. Простой дизайн
Простой дизайн в XP означает делать только то, что нужно сейчас, не пытаясь
угадать будущую функциональность. Простой дизайн и непрерывный рефакторинг
дают синергетический эффект — когда код простой, его легко оптимизировать.
13. Рефакторинг
Процесс постоянного улучшения дизайна системы, чтобы привести его в
соответствие новым требованиям. Рефакторинг включает удаление дублей кода,
повышение связности и снижение сопряжения. XP предполагает постоянные
рефакторинги, поэтому дизайн кода всегда остается простым.

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

Экстремальное программирование — недостатки:

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

Kanban
Менеджмент Канбан в экономической практике означает такую организацию
предпринимательской деятельности − будь то производство, логистика или розничная
торговля − которую можно охарактеризовать как система «точно в срок». В самом
термине «Kanban», который переводится с японского как «видимая карточка», заложен
подход к оптимизации бизнеса за счет деления на операции и визуализации рабочего
процесса. И хотя философию Kanban впервые применили в фирме «Toyota» более
полувека назад, этот метод в современном понимании был разработан и предложен
экономистом Дэвидом Андерсоном.
Экономист Дэвид Андерсон, будучи весной 2005 года в Токио, во время прогулки
в Восточных садах Императорского дворца пришел к выводу, что многоразовые
разноцветные пластиковые билеты для туристов, называемые Kanban могут стать
инструментом экономической деятельности в условиях неопределенности. Совершив
прогулку и сдав Канбан, он, по сути, завершил «условную работу». Отметки о выдаче
карточек посетителям и получении их обратно контролёры делали на специальной доске
с колонками.
Андерсон пришёл к выводу, что посредством карточек и колонок можно,
например, контролировать запасы на складе или поставки товаров. За счет концепции
«точно в срок» удастся минимизировать материальные издержки и оптимизировать
продажи.

Чтобы понять и успешно применять в своем бизнесе систему «точно в срок»,

нужно обратить внимание на девять фундаментальных вещей Канбан: 4 принципа и 5
правил.
8
 Принципы
Всегда оценивайте то, что делаете.
Будьте готовы к эволюционным изменениям.
Уважайте роли, обязанности и титулы.
Поощряйте неформальных лидеров.

5 правил Канбан
1. Визуализация рабочего процесса.
2. Ограничение незавершенных производств (WIP — Work-In-Progress).
3. Управление потоком работ.
4. Понятность и прозрачность изменений.
5. Улучшение совместной работы (с использованием моделей и научного
метода).

Визуализация бизнес-процессов – очень эффективный метод. Визуализировать

можно посредством так называемой доски Канбан
Если грамотно визуализировать рабочий процесс, то легко найти фрагменты WIP,
которые называют «убийцами бизнеса».
Очень важна обратная связь. Внеся изменения, следует убедиться, что и впрямь
произошло улучшение.
Чтобы процесс внедрения изменений не «зашёл в тупик», он должен быть понятен
всем участникам проекта.
В методе Канбан ключевым является понятие Кайдзен, означающее непрерывные,
инкрементные и позитивные изменения.

Достоинства и недостатки канбан

Kanban имеет такие достоинства:
Гибкость планирования. Команда концентрируется только на текущей работе,
приоритет задачи выставляется менеджером.
Высокое вовлечение команды в процесс разработки. Благодаря постоянным
собраниям, прозрачности процессов и возможностям самоорганизации работники
сплачиваются и проявляют искренний интерес.
Меньшая продолжительность цикла. Если несколько человек обладает схожими
навыками, продолжительность сокращается, если же только один — появляется узкое
место. Поэтому сотрудники должны делиться знаниями и тем самым оптимизировать
продолжительность цикла. Тогда вся команда сможет взяться за работу, которую
забуксовала, и восстановить плавный поток.
Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и
проблемные места, которые появились из-за дефицита внимания, людей или навыков.
Наглядность. Когда все исполнители имеют доступ к данным, то узкие места
легче заметить. Kanban-команды, помимо самих карточек, обычно используют два
общих отчета: графики управления и совокупного потока.

Недостатки:
 Система плохо работает с командами численностью более 5 человек
 Он не предназначен для долгосрочного планирования.

9
 Scrum (Скрам) и Kanban (Канбан) – это методы управления проектами. Они
являются представителями популярной методологии Agile-семейства. Эти методы
гибкие и итеративные, они могут использоваться для работы в любой отрасли, однако
лучше всего они подходят для IT-сферы. Оба метода близки, поэтому их инструменты
можно использовать в комбинации. Очень часто применяют гибридный подход. При
этом используют лучшее из Scrum и Kanban.

Они объединяют основополагающие принципы Agile-манифеста:

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

Несмотря на то, что данные методологии близки и имеют много общего, у них
достаточно много различий.

1. Команды

10
 Команда специалистов в Scrum универсальна. Она состоит из такого количества
широких специалистов, которое нужно для решения каждой задачи проекта. В
большинстве случаев достаточно 5-7 человек. При большем количестве людей
результат менее очевиден из-за бесчисленного количества разговоров. При этом у
специалистов Scrum-команды нет формальной компетенции, например: тестировщик
может помогать дизайнеру, а аналитик – разработчику или наоборот.
В Kanban же основная задача состоит в том, чтобы сбалансировать разных
узкопрофильных специалистов внутри команды. Над задачей может работать несколько
узкопрофильных команд. Например, сначала работает аналитический отдел, после –
дизайнерский отдел, и только
потом к работе приступают
разработчики. При этом не
запрещаются и универсальные
команды.

2. Роли

В Scrum-команде
требуется больше ресурсов, чем
в Kanban-команде. Для
управления всем процессом
разработки требуются
дополнительные роли: Scrum
master (скрам-мастер) и Product
owner (владелец продукта).
Scrum master – это организатор. Он не управляет и не раздает указания. Скрам-
мастер организовывает совещания, устраняет бытовые и другие проблемы, мотивирует
команду, отслеживает статус задач, следит за соблюдением скрам-подхода. Помимо
выполняемых задач организатора, скрам-мастер работает над проектом, как и другие
сотрудники команды.

11
 Product owner взаимодействует с клиентом, связывает заказчика и команду,
отслеживает развитие проекта, но при этом не является формальным руководителем
команды. Он выставляет задачам приоритеты. Именно ему команда предоставляет
результат работы.
В Kanban-команде такие ресурсы не требуются, потому что процесс линейный и
более прост в организационном плане. В команде нет ролей Scrum master и Product
owner. Команда едина.
3. Планирование

В обоих методах проект делится на десятки, а может и сотни более мелких задач.
Все предстоящие задачи проекта, складываются в общий список задач – бэклог. Каждая
задача имеет свой приоритет и актуальность.
Отличие в том, что приоритеты в Scrum расставляет владелец продукта, а в Kanban
– команда.

4. Временные рамки
В Scrum время работы над проектом разбивается командой на равные отрезки –
спринты, длительностью от одной до четырех недель, но чем короче отрезок, тем легче
вносить изменения. В Scrum сроки соблюдаются командой в обязательном порядке.

12
 Каждый спринт состоит из четырех последовательных этапов:
Планирование. Команда проверяет задачи в общем списке задач по проекту и
выстраивает их по приоритету. На спринт берут столько задач, по мнению команды,
сколько успеют сделать.
Выполнение. Участники команды работают одновременно, например:
программист создает код, в это время тестировщик пишет к нему тесты, а технический
писатель – документацию.
Релиз. К моменту каждого релиза, продукт должен быть работоспособным,
полезным для пользователя и более совершенным, чем до спринта.
Ретроспектива. Члены команды вместе обсуждают спринт и возникшие в
процессе проблемы. Совместно думают, как повысить качество работы и сделать в
следующем спринте больше.
Scrum менее гибок, так как в этом методе категорически запрещено добавлять
задачи в текущий спринт. Даже самая срочная и важная задача пойдет в работу со
следующего спринта.
В конце отрезка недоделанные задачи уходят обратно в бэклог. А на этапе
планирования следующего спринта определяется необходимость и время их
завершения.
Также в Scrum требуется выделять время на ежедневные митинги, на которых
планируются спринты и решаются организационные вопросы.

В Kanban же не требуются обязательные встречи-отчеты. Они могут проводиться

раз в месяц или неделю.
В Kanban методологии проект делится не на универсальные спринты, а на этапы
выполнения конкретных задач, например: «Планируется», «Разрабатывается»,
«Тестируется», «Завершено» и т.д. Данные этапы могут быть различной длины. Новые
задачи можно добавлять в любое время. Если нужно срочно что-то сделать, то команда
не будет ждать следующего этапа для выполнения срочного задания. Задача может
находиться в работе столько, сколько потребуется для нее времени, до тех пор, пока
команда не завершит ее или не отменит.
Следовательно, в Kanban сложнее контролировать время разработки продукта и
прогнозировать сроки завершения модуля, чем в Scrum.

13
 5. Доски

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

доски. Они позволяют сделать рабочий процесс максимально открытым и понятным для
всех специалистов команды. А также распланировать задачи и поставить некоторые
ограничения.
Доска разделяется на столбцы, которым присваивается разное состояние задачи,
например: «To do», «In progress», «Review», «Test», «Done» и др. Количество и названия
столбцов, конечно же, зависят от конкретного проекта, но в целом, чем их меньше, тем
лучше. В карточках описывают задачи, а также указывают приоритет. По мере
выполнения задач, они перемещаются по доске в другой столбец, что позволяет увидеть,
как выполняются задачи и где возникают проблемы.
Отличие методов в том, что при Kanban доска находится постоянно в заполненном
состоянии. А в Scrum доска очищается каждый раз при новой итерации.

6. Показатели

В Scrum измеряется общий вес всех задач, которые выполняются за спринт.

Разделив общий вес задач проекта на производительность за спринт, получают
примерный срок окончания проекта. Повышение производительности – это главный
показатель команды в Scrum.
14
 В Kanban измеряется среднее время прохождения одной задачи по доске. Это
время – показатель эффективности команды. Члены команды не сосредотачиваются на
выполнении конкретных задач, они следят за тем, чтобы среднее время выполнения
было минимальным.
Как мы видим, Kanban и Scrum имеют свою специфику. Тот или иной проект
требует определенного подхода к разработке. В одних случаях нужно использовать
Scrum, в других – Kanban.
Scrum идеально подходит для управления одним масштабным проектом
длительностью от трех месяцев, который имеет исчерпывающую спецификацию и
требования перед началом разработки. В этом случае команда легко подготовит
детальный план разработки и весь процесс разделит на спринты.
Kanban же отлично подходит для маленьких проектов, для которых не требуется
так много времени на планирование. Также он идеально подходит для долгосрочных
проектов, в которых отсутствует четкая спецификация и задания формируются в
процессе разработки.

15
 Лекция 9
Разработка требований к программному обеспечению (ч.1)

«Привет, Фил, это Мария из отдела персонала. У нас проблема с

системой управления персоналом, которую вы разрабатывали для нас. Одна
из сотрудниц изменила имя на Спаркл Старлайт, а система не принимает
это изменение. Ты можешь помочь?»
«Она вышла замуж за парня по имени Старлайт?»
«Нет, она просто взяла другое имя, — ответила Мария. — В этом-то
и
проблема. Похоже, что мы можем менять имя только при изменении
семейного положения».
«Да, я не предусмотрел такой возможности. Я не помню, чтобы и ты
говорила мне о ней, когда мы обсуждали систему», — сказал Фил.
«Я полагала, ты знаешь, что люди могут законным образом менять
имена, когда захотят, — ответила Мария. — Мы должны исправить это к
пятнице, а то Спаркл не сможет обналичить чек. Ты сможешь исправить
этот дефект к этому сроку?»
«Это не дефект, — резко парировал Фил. — Я и не знал, что вам нужна
эта функциональность. Сейчас я занимаюсь новой системой оценки
производительности системы, и скорее всего смогу исправить это в конце
месяца, но не к пятнице. Приношу свои извинения. Но в следующий раз с
такими просьбами обращайся пораньше и, пожалуйста, излагай их
письменно».
«А что же я скажу Спаркл? — возмутилась Мария. — Она сильно
расстроится, если не сможет обналичить чек».
«Эй, Мария, это не моя вина, — запротестовал Фил. — Если бы ты
сказала мне с самого начала, что вам понадобится изменять имена в любое
время, этого не произошло бы. Я не медиум и читать твои мысли не умею».
Сердитая и смирившаяся, Мария отрезала: «Это как раз то, из-за чего
я ненавижу компьютерные системы. Позвони мне, как только сможешь
исправить недостаток».
Не очень приятно находится в милости разработчиков, которые может
быть удовлетворят ваш запрос. Разработчики тоже не очень довольны, когда
узнают о функциональности, которую пользователи ожидали получить,
только после развертывания системы.
Масса проблем с ПО возникает из-за несовершенства способов,
которые люди применяют для сбора, документирования, согласования и
модификации требований к ПО. Как в случае с Филом и Марией, проблемы
могут возникать из-за неформального сбора информации, предполагаемой
функциональности, ошибочных или несогласованных предположений,

1
недостаточно определенных требований и бессистемного изменения
процесса. Некорректные сведения от пользователей и недостатки
определения и управления требованиями клиентов — основные причины
провалов проектов.
Нигде более, как на стадии сбора требований так тесно не связаны
интересы всех заинтересованных в проекте лиц с успехом проекта.
Заинтересованные лица являются людьми или организациями
(юридические лица, такие как компании, комитеты по стандартизации), у
которых есть действительный интерес к системе. Они могут быть затронуты
этой системой прямо или косвенно.
К заинтересованным лицам также относятся:
− любой, кто пользуется системой (пользователи и обслуживающий
персонал)
− любой, кто извлекает выгоду из системы (функциональную,
политическую, финансовую и социальную)
− любой вовлечённый в покупку или обеспечение системы
− организации, которые регулируют аспекты системы (финансовые,
безопасность, и другие)
− люди или организации, настроенные против системы
(отрицательные заинтересованные лица),
− организации, ответственные за системы, которые
взаимодействуют с системой согласно проекту
− те организации, которые объединяются горизонтально с
организацией, для которой аналитик проектирует систему

Определение требований к ПО
Разные эксперты, говоря об одном и том же документе, могут называть
его пользовательскими требованиями, требованиями к ПО, бизнес-
требованиями, функциональными требованиями, системными
требованиями, требованиями к продукту или проекту, пользовательской
точкой зрения, функцией или ограничением. Имена, которые они применяют
к различным требованиям, также различаются. Заказчики зачастую считают,
что определенные ими требования — это высокоуровневая концепция
продукта, предназначенная для разработчиков. Те, в свою очередь, полагают,
что в отношении клиентов это детализированная разработка интерфейса
пользователя.
Мы будем считать, что Требования − это спецификация того, что
должно быть реализовано. В них описано поведение системы, свойства
системы или ее атрибуты. Они могут служить ограничениями в процессе
разработки системы.
Требования охватывают как видение пользователя, так и внешнее

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

Классификация требований

3
 Классификация требований по К. Вигерсу

Рисунок 1

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

функциональные, нефункциональные и требования предметной области.
Функциональные требования задают «что» система должна делать;
нефункциональные – с соблюдением “каких условий” (например, скорость
отклика при выполнении заданной операции); часто функциональные
требования представляют в виде сценариев (вариантов использования) Use
Сase.
Функциональные требования. Это перечень сервисов, которые должна
выполнять система, причем должно быть указано, как система реагирует на
те или иные входные данные, как она ведет себя в определенных ситуациях
и т.д. В некоторых случаях указывается, что система не должна делать.
Нефункциональные требования. Описывают характеристики системы и
ее окружения, а не поведение системы. Здесь также может быть приведен
перечень ограничений, накладываемых на действия и функции,
выполняемые системой. Они включают временные ограничения,
ограничения на процесс разработки системы, стандарты и т.д.
Требования предметной области. Характеризуют ту предметную
область, где будет эксплуатироваться система. Эти требования могут быть
4
функциональными и нефункциональными.
В действительности четкой границы между этими типами требований
не существует. Например, пользовательские требования, касающиеся
безопасности системы, можно отнести к нефункциональным. Однако при
более детальном рассмотрении такое требование можно отнести к
функциональным, поскольку оно порождает необходимость включения в
систему средства авторизации пользователя. Поэтому мы должны всегда
помнить, что данная классификация в значительной степени искусственна.
Ошибка, допущенная в функциональном требовании, может снизить
качество системы, ошибка в нефункциональных требованиях может
сделать систему неработоспособной.

Группа функциональных требований

Бизнес-требования (business requirements) описывают, почему
организации нужна такая система, то есть цели, которые организация
намерена достичь с ее помощью. Основное их содержание — бизнес-цели
организации или клиента, заказывающих систему.
Допустим, что авиакомпания хочет на 25% снизить затраты на
сотрудников у стойки в аэропорту. В процессе достижения этой цели
может возникнуть идея поставить терминал, который пассажиры будут
использовать для самостоятельной регистрации в аэропорту.
Как правило, бизнес-требования высказывают те, кто финансируют
проект, покупатели системы, управляющий реальными пользователями,
отдел маркетинга или ответственный за концепцию продукта.

Пользовательские требования (user requirements) описывают цели или

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

Собственно, функциональные требования (functional requirements)

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

5
пользователи смогли выполнить свои задачи (пользовательские требования)
в рамках бизнес-требований.
Функциональные требования описываются в форме традиционных
утверждений со словами «должен» или «должна»: «У пассажира должна
быть возможность распечатать посадочные талоны на все рейсы, на
которые он зарегистрировался» или «Если в профиле пассажира не указаны
предпочтения по выбору места, система резервирования должна сама
назначить ему место».
Бизнес-аналитик документирует функциональные требования в
спецификации требований к ПО (software requirements specification, SRS), где
описывается так полно, как необходимо, ожидаемое поведение системы

Системные требования (System Requirements) – иногда

классифицируются как составная часть группы функциональных
требований. Описывают высокоуровневые требования к программному
обеспечению, содержащему несколько или много взаимосвязанных
подсистем и приложений. При этом, система может быть как целиком
программной, так и состоять из программной и аппаратной частей. В общем
случае, частью системы может быть персонал, выполняющий определенные
функции системы, например, авторизация выполнения определенных
операций с использованием программно-аппаратных подсистем.
Хороший пример «системы» — рабочее место кассира в супермаркете.
В нем есть сканер штрих-кода, интегрированный с весами, а также
ручной сканер штрих-кода. У кассира есть клавиатура, монитор и
выдвижной ящик-касса. Есть также устройство чтения кредитных
карточек и клавиатура для ввода ПИН-кода и чтения карт постоянного
покупателя. На рабочем месте может быть до трех принтеров: для печати
чека, квитанции кредитной карты и купонов на скидку. Все эти устройства
взаимодействуют под управлением программного обеспечения.

Характеристика (feature) — это набор логически связанных

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

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

Группа нефункциональных требований

Бизнес-правила (business rules) включают корпоративные политики,
правительственные постановления, отраслевые стандарты и
вычислительные алгоритмы. Бизнес-правила не являются требованиями к
ПО. Однако они часто налагают ограничения, определяя, какими функциями
должна обладать система, подчиняющаяся соответствующим правилам.
Иногда, как в случае с корпоративными политиками безопасности,
бизнес-правила становятся источником атрибутов качества, которые
реализуются в функциональности.
Внешние интерфейсы. Речь идет о подключениях к другим
программным системам, аппаратным устройствам и пользователям, а также
коммуникационные интерфейсы.
Атрибуты качества (quality attributes) еще называют параметрами
качества, требованиями по уровню обслуживания и т.п. Они представляют
собой описание различных измерений характеристик продукта, которые
важны для пользователей или для разработчиков и тех, кто будет
обслуживать систему, таких как производительность, доступность и
переносимость.
Ограничения (constraints) проектирования и реализации накладывают
границы на возможности выбора разработчика при проектировании
продукта.

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

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

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

Количественные показатели нефункциональных требований

Показатель Единицы измерения
Скорость Количество выполненных транзакций в секунду;
время реакции на действия пользователя;
время обновления экрана
Размер Килобайты;
количество модулей памяти
Простота Время обучения персонала;
эксплуатации
количество статей в справочной системе
Надежность Средняя продолжительность времени между двумя
последовательными проявлениями ошибок в системе;
вероятность выхода системы из строя;
коэффициент готовности системы
Устойчивость Время восстановления системы после сбоя;
к сбоям процент событий, приводящих к сбоям;
вероятность порчи данных при сбоях
Переносимость Процент машинно-зависимых операторов;
количество машинно-зависимых подсистем

До этого момента мы обсуждали требования, описывающие свойства

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

Для проекта, как правило, создаются требования других типов:

документ, где описана среда разработки, ограничения бюджета, руководство
пользователя или требования для выпуска продукта и продвижения его в
поддерживаемую среду.
Требования к проекту мы не будем рассматривать. Это не значит, что
они не важны, — просто они находятся за рамками нашей тематики,
посвященной разработке и управлению требованиям к программному
продукту.
8
 На первом рисунке были показаны три главных документа требований:
документ концепции и границ, документ пользовательских требований и
спецификация программных требований. Не всегда обязательно создавать
эти три отдельных документа в каждом проекте. Часто имеет смысл
объединять часть информации, особенно в небольших проектах. Однако
надо понимать, что эти три документа содержат разную информацию,
разрабатываются на разных этапах проекта, возможно даже разными людьми
с разными целями и разной целевой аудиторией.
Рисунок 1 показывает простой «сверху вниз» поток информации
требований. В реальности возможно наличие циклов и итераций
пользовательских, функциональных и бизнес-требований. Каждый раз, когда
кто-то предлагает ввести новую функцию, пользовательское требование или
улучшение функциональности, аналитик должен задаться вопросом:
«Укладывается ли это в рамки проекта?» Если ответ положительный,
требование должно присутствовать в спецификации. В противном случае
требования в спецификации быть не должно, по крайней мере в текущем
выпуске или итерации. Третий возможный ответ звучит так: «Нет, но это
поддерживает бизнес-цели, поэтому должно быть в спецификации». В этом
случае, ответственный за область действия проекта — куратор, менеджер
или ответственный за проект, должен решить, нужно ли расширять рамки
текущего проекта или итерации, чтобы включить новое требование. Это
бизнес-решение, которое оказывает влияние на график и бюджет проекта и
может требовать пожертвовать другими возможностями.

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

Полнота.
Требование полноты можно рассматривать в двух аспектах: полнота
отдельного требования и полнота системы требований.

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

Ясность (недвусмысленность, определенность, однозначность

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

Корректность и согласованность (непротиворечивость).

Требования не должны противоречить требованиям своего уровня
иерархии и требованиям "родительского" уровня. Так, требования
пользователей не должны противоречить бизнес-требованиям, а
функциональные требования − требованиям пользователя.

Верифицируемость (пригодность к проверке).

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

Необходимость и полезность при эксплуатации.

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

10
соображениями, либо опытом внедрения информационных систем на
аналогичных предприятиях, он должен проявить инициативу и собрать
совместное совещание сторон. Аргументы в пользу отсутствия
необходимости требования несомненно будут восприняты, особенно если
они будут мотивированы в бизнес-терминологии Заказчика и подтверждены
выкладками, прогнозирующими соотношение затрат на выполнение
требования и ожидаемой от него эффективности.
Более слабой, чем "необходимость" формулировкой обладает свойство
"полезность при эксплуатации". Разграничение между данными свойствами
можно провести следующим образом. Необходимыми следует считать
свойства, без выполнения которых невозможно, либо затруднено
выполнение автоматизированных бизнес-функций пользователей;
полезными при эксплуатации следует считать любые свойства, повышающие
эргономические качества продукта.

Осуществимость (выполнимость).
Выполнимость требования на практике определяется разумным
балансом между ценностью (степенью необходимости и полезности) и
потребными ресурсами. Так, если стоимость контракта на разработку
информационной системы составляет $10000, а затраты на выполнение
нового требования, возникшее в момент, когда проект выполнен наполовину,
оценивается в $4000, является ли оно невыполнимым? Скорее всего, да, если
Исполнитель докажет Заказчику новизну требования (требование не входило
в согласованные спецификации) и сложность его исполнения. Но, если
требование является критически важным, необходимым, но выпало из поля
зрения при подписании контракта Заказчик готов выделить дополнительно
финансирование, а Исполнитель − трудовые ресурсы − значит, требование
выполнимо. Таким образом, требование осуществимости в ряде случаев
также следует считать субъективным, а критерии его оценки лежат в области
договоренностей между Заказчиком и Исполнителем.

Трассируемость
Трассируемость требования определяется возможностью отследить
связь между ним и другими артефактами информационной системы
(документами, моделями, текстами программ и пр.). Отдельная трасса
представляет собой направленное бинарное отношение, заданное на
множестве артефактов ИС, где первый элемент отношения представляет
соответствующее требование, а второй − артефакт, зависимый от данного
требования.

11
 На практике трассировки анализируются с помощью графовых, либо
табличных моделей.

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

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

Матрица трассировки (матрицы трассируемости, traceability matrix) –

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

Матрицы трассировки, как способ наглядного представления связей,

применяются при анализе и проектировании систем для:
12
  определения покрытия исходных требований (все ли требования
потребителя, заказчика учтены в проекте?),
 определения связей между требованиями и функциями, данными
и функциями проектируемой системы,
 распределения функций по элементам физической архитектуры
системы,
 управления другими типами проектных данных, например,
распределение User Story по спринтам (в рамках методологии Scrum).
Системные аналитики любят использовать матрицы трассировки
потому, что они наглядны и позволяют быстро найти "подозрительные"
точки в проектных решениях, а также оценить область изменений при
изменении исходных требований.
Например, по матрице трассировки легко увидеть, что
спроектированная функция не попала ни в один компонент. Также можно
оценить перегруженность компонентов.

13
 Упорядоченность по важности и стабильности
Приоритет требования представляет собой количественную оценку
степени значимости (важности) требования. Приоритеты требований обычно
назначает представитель Заказчика. Разработчик, отталкиваясь от
приоритетности требований, управляет процессом реализации
информационной системы.
Стабильность требования характеризует прогнозную оценку
неизменности требований во времени.
Наличие количественной метрики
Количественные метрики играют важную роль в верификации и
аттестации информационных систем. В первую очередь это относится к
нефункциональным требованиям, которые, как правило, должны иметь под
собой количественную основу (запрос должен отрабатываться не более, чем
___ секунд; средняя наработка на отказ должна составлять не менее, чем ___
часов). Функциональные требования также могут расширяться
количественными мерами при помощи так называемых аспектов
применимости.

Каких требований не должно быть

Спецификация требований не должна содержать деталей
проектирования или реализации (кроме известных ограничений). Иными
словами, требования должны отвечать на вопрос: "что должна делать
система", абстрагируясь от вопроса "как она это должна делать".
14
 Разработка требований
Разработка требований − это процесс, включающий мероприятия,
необходимые для создания и утверждения документа, содержащего
спецификацию системных требований.
Различают четыре основных этапа процесса разработки требований:
– анализ технической осуществимости создания системы,
– формирование и анализ требований,
– специфицирование требований
– создание соответствующей документации, а также аттестация этих
требований.
На рисунке показаны взаимосвязи между этими этапами и документы,
сопровождающие каждый этап процесса разработки системных требований.

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

должен начинаться с анализа осуществимости.
Началом такого анализа является общее описание системы и ее
назначения.
Результатом анализа − отчет, в котором должна быть четкая
рекомендация, продолжать или нет процесс разработки требований
проектируемой системы.
Другими словами, анализ осуществимости должен осветить
следующие вопросы:
1. Отвечает ли система общим и бизнес-целям организации-заказчика и
организации-разработчика?
2. Можно ли реализовать систему, используя существующие на данный
момент технологии и не выходя за пределы заданной стоимости?
3. Можно ли объединить систему с другими системами, которые уже
15
эксплуатируются?

После выполнения анализа осуществимости следующим этапом

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

Процесс формирования и анализа требований достаточно сложен

по ряду причин.
1. Лица, участвующие в формировании требований, часто не знают
конкретно, чего они хотят от компьютерной системы, за исключением
наиболее общих положений; им трудно сформулировать, что они ожидают
от системы; они могут предъявлять нереальные требования, так как не
подозревают, какова стоимость их реализации.
2. Лица, участвующие в формировании требований, выражают в этих
требованиях собственные точки зрения, основываясь на личном опыте
работы.
3. Лица, участвующие в формировании требований, имеют различные
предпочтения и могут выражать их разными способами. Разработчики
должны определить все потенциальные источники требований и выделить
общие и противоречивые требования.
4. На требования к системе могут влиять политические факторы. Они
могут исходить от руководителей, которые предъявляют требования только
для того, чтобы усилить свое влияние в организации.
5. Экономическая и бизнес-обстановка, в которой происходит
формирование требований, неизбежно будет меняться в ходе выполнения
этого процесса. Следовательно, и важность отдельных требований может
изменяться. Новые требования могут быть выдвинуты новым лицом, с
которым первоначально не консультировались.

16
 Обобщенная модель процесса формирования и анализа требований.

Каждая организация использует собственный вариант этой модели,

зависящий от "местных" факторов: опыта работы коллектива разработчиков,
типа разрабатываемой системы, используемых стандартов и т.д.
Процесс формирования и анализа требований проходит через ряд
этапов:
1. Анализ предметной области. Аналитики должны изучить
предметную область, где будет эксплуатироваться система.
2. Сбор требований. Это процесс взаимодействия с лицами,
формирующими требования. Во время этого процесса продолжается анализ
предметной области.
3. Классификация требований. На этом этапе бесформенный набор
требований преобразуется в логически связанные группы требований.
4. Разрешение противоречий. Без сомнения, требования
многочисленных лиц, занятых в процессе формирования требований, будут
противоречивыми. На этом этапе определяются и разрешаются
противоречия такого рода.
5. Назначение приоритетов. В любом наборе требований одни из них
будут более важны, чем другие. На этом этапе совместно с лицами,
формирующими требования, определяются наиболее важные требования.
6. Проверка требований. На этом этапе определяется их полнота,
последовательность и непротиворечивость.
Процесс формирования и анализа требований циклический, с обратной
связью от одного этапа к другому. Цикл начинается с анализа предметной
области и заканчивается проверкой требований. Понимание требований
предметной области увеличивается в каждом цикле процесса формирования
требований.
Существуют разные подходы к формированию требований: метод,
основанный на множестве опорных точек зрения, сценарии,
этнографический метод, метод структурного анализа, метод
17
прототипирования и др. Не существует универсального подхода к
формированию и анализу требований. Обычно для разработки требований
одновременно используется несколько подходов.

Специфицирование требований
Клиенты и конечные пользователи описывают свои требования на
естественном языке. После анализа этих требований происходит их
документирование. Этот документ называется Спецификацией требований к
программному обеспечению (Software Requirements Specification, SRS).
Эта спецификация работает как соглашение между заказчиком и
командой разработчиков о том, что должен делать программный продукт.
Правильная спецификация помогает предотвратить сбои программного
обеспечения. Это также помогает команде разработчиков получить четкое
представление о продукте, который они должны разработать.
Разница между Требованием и Спецификацией в разработке
программного обеспечения заключается в том, что Требования — это
потребности заказчика, которые должны быть решены программным
обеспечением, тогда как Спецификация — это технический документ с
проанализированными требованиями.

Аттестация должна продемонстрировать, что требования

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

18
одной и той же системной функции.
3. Проверка на полноту. Спецификация требований должна содержать
требования, которые определяют все системные функции и ограничения,
налагаемые на систему.
4. Проверка на выполнимость. На основе знания существующих
технологий требования должны быть проверены на возможность их
реального выполнения. Здесь также проверяются возможности
финансирования и график разработки системы.

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

использовать совместно или каждый в отдельности:
1. Обзор требований. Требования системно анализируются
рецензентами. Этот процесс обсуждается в следующем разделе.
2. Прототипирование. На этом этапе прототип системы
демонстрируется конечным пользователям и заказчику. Они могут
экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их
потребностям.
3. Генерация тестовых сценариев. В идеале требования должны быть
такими, чтобы их реализацию можно было протестировать. Если тесты для
требований разрабатываются как часть процесса аттестации, то часто это
позволяет обнаружить проблемы в спецификации. Если такие тесты сложно
или невозможно разработать, то обычно это означает, что требования трудно
выполнить и поэтому необходимо их пересмотреть.
4. Автоматизированный анализ непротиворечивости. Если
требования представлены в виде структурных или формальных системных
моделей, можно использовать инструментальные CASE-средства для
проверки непротиворечивости моделей.

Для автоматизированной проверки непротиворечивости необходимо

построить базу данных требований и затем проверить все требования в этой
19
базе данных. Анализатор требований готовит отчет обо всех обнаруженных
противоречиях.

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

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

Определение основных профилей пользователей

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

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

Пример диаграммы профилей пользователей продукта

Профили пользователей явно или неявно уже должны содержаться в

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

Сбор пользовательских историй

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

22
 Лекция 10
Разработка требований к программному обеспечению (ч.2)

Особенности сбора бизнес-требований

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

Определение стимулов
На данном этапе указываются основные причины, которые стимулируют
принятие решения о создании этого продукта.
Как правило, причиной создания продукта может служить одна или несколько
проблем: потребность, производственная необходимость, потребность заказчика,
технический, юридические ограничения или нормы и т.д.
Определение целей продукта и критериев успеха
Необходимо описать основные преимущества, которые предоставит продукт для
бизнеса. Сделать это надо в измеряемом виде. Также нужно определить механизм для
измерения успеха продукта в конечном итоге.
Например, основные цели
Финансовые:
Освоить Х% рынка за Y месяцев.
Увеличить сектор рынка в стране X на Y% за Z месяцев.
Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев.
Получить Х% прибыли или дохода по инвестициям в течение Y месяцев.
1
 Достигнуть положительного баланса по этому продукту в течение Y месяцев.
Сэкономить $Х в год, которые в настоящий момент расходуются на
обслуживание системы.
Уменьшить затраты на поддержку на Х% за Z месяцев.
Получить не более X звонков в службу обслуживания по каждой единице
товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после
выпуска товара.
Увеличить валовую прибыль для существующего бизнеса с Х до Y%.

Нефинансовые:
Достигнуть показателя удовлетворения покупателей, равного, по крайней мере,
X, в течение Y месяцев со времени выпуска товара.
Увеличить производительность обработки транзакций на Х% и снизить
уровень ошибок данных до величины не более Y%.
Достигнуть определенного времени для достижения доминирующего
положения на рынке.
Разработать надежную платформу для семьи связанных продуктов.
Разработать специальную базовую технологическую основу для организации.
Получить X положительных отзывов в отраслевых журналах к определенной
дате.
Добиться признания продукта лучшим по надежности в опубликованных
обзорах продуктов к определенной дате.
Соответствовать определенным федеральным и государственным
постановлениям.
Уменьшить время оборота до X часов на Y% звонков покупателей в службу
поддержки.

Определение целевого сегмента рынка

Этот элемент, как правило, требуется только для продуктов, ориентированных
на широкий рынок. Принято сегментировать рынок следующим образом:
– Рынок домашних пользователей (может быть также разделен на обычных и
продвинутых пользователей).
– Рынок корпоративных пользователей.
1. SMB (Small and Medium Business) — компании, насчитывающие от 1 до
250 сотрудников. Также может быть разделен на Micro (или Soho) –10 сотрудников,
Small — 10–25 и Medium — 25–250.
2. Large — компании, насчитывающие 250–2500 сотрудников.
3. Corporation — корпорации с числом сотрудников более 2500.
Это разделение принято использовать в связи с тем, что требования, налагаемые
пользователями, которые принадлежат к разным сегментам рынка, кардинально
отличаются. Это касается как функциональности, способов администрирования, так и
вопросов лицензирования и поддержки продукта. Практически невозможно создать
продукт, который бы подошел одновременно домашним пользователям и в тоже время
мог бы эксплуатироваться в крупной компании.
Для того чтобы правильно выбрать сегмент рынка, необходимо определить
требования, налагаемые каждым из сегментов рынка с учетом предметной области
продукта.

2
 Часто встречающиеся нефункциональные требования

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

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

Определение потребностей клиентов или рынка (от сценариев к

требованиям)
Теперь, когда определен целевой сегмент для вашего продукта, следует
определить кто, какие проблемы и в каких условиях будет решать при помощи
будущего продукта.

Создание сценариев
Наиболее эффективным способом получения ответа на эти вопросы является
определение сценариев работы пользователей с будущим продуктом.
Сценарий — это совокупность всех процессов, в которых будет участвовать
продукт, а также описание окружения, в котором его планируется использовать.
Сценарий не должен являться описанием работы отдельного пользователя для
достижения конкретной цели. Его ценность состоит в том, что он описывает способы
взаимодействия с продуктом всех его пользователей одновременно на протяжении
всего цикла эксплуатации продукта. Таким образом, сценарий гарантирует отсутствие
взаимоисключающих требований к продукту и дает возможность легко убедиться, что
никто и ничто не забыто. Для проверки сценария надо всего лишь проанализировать
его выполнение всеми заинтересованными лицами (проиграть его).
3
 Для продуктов под заказ сценарии использования продукта формируются самим
заказчиком. Как правило — сколько заказчиков, столько и сценариев. Наиболее
эффективным методом является живой диалог с заказчиком, в котором аналитик
задает наводящие вопросы (пытается разговорить заказчика), а заказчик отвечает на
них.
Если личный контакт невозможен, как правило, помогают вопросники,
содержащие «нужные» вопросы, по которым заказчику легче будет написать
сценарий.
Для открытого рынка сначала определяются профили будущих клиентов
продукта, а затем для каждого из них создается подробный сценарий его
использования. Аналитик может описывать сценарии самостоятельно, используя
информацию из личного опыта или открытых источников. Другой вариант,
позволяющий достичь явного преимущества — найти клиентов или компании,
подходящие под ранее определенные профили и получить сценарии непосредственно
от них.

Каждый сценарий должен содержать:

Имя конкретного заказчика или его профиль (в качестве заголовка).
Информацию обо всех типах пользователей, которые будут работать с
продуктом.
Все процессы, которые будут затрагивать продукт.
Операционная среда, в которой будет использоваться продукт.
Требования к дизайну: операционная система; приложения, с которыми
интегрируется, форматы ввода вывода.
Приоритет. Зависит от того, насколько важен этот заказчик или как много
покупателей будут попадать под профиль клиента, описанного в сценарии.
Определение функциональных требований и требований к дизайну
Теперь, имея всю необходимую информацию от пользователей, следует заняться
еe систематизацией.
Сценарии избыточны. Они содержат большое количество повторений или
дополнений. В процессе выделения требований должен быть создан список
уникальных требований к продукту, которые не должны повторяться, но могут
дополнять друг друга.
Необходимо выделить два типа требований: функциональные бизнес требования
и требования к дизайну (нефункциональные требования).
Функциональные бизнес-требования описывают потребность бизнеса
(заказчика/покупателя), которую должен удовлетворить будущий продукт.
Требования к дизайну описывают операционную среду, в которой будет
функционировать продукт, интерфейсы взаимодействия с пользователем или другими
системами, форматы хранения и передачи данных, а также требования к надежности,
производительности, обслуживанию и доступности системы.
В процессе структурирования нужно выделить основные требования и
дополнения к ним. Требования удобно отображать в виде дерева. Независимые
требования являются требованиями первого уровня, а их дополнения дочерними
элементами.
Разбивая требования на отдельные элементы, основным критерием должна быть
возможность реализации этих требований отдельно друг от друга (реализовать первое

4
и не реализовать второе). Если требования столь сильно зависят друг от друга, что
должны быть реализованы только вместе, лучше их объединить.
Как только все требования структурированы, следует назначить им приоритет.
Обзор конкурентов
Для определения текущего положения на рынке крайне важно серьезно подойти
к обзору конкурентов.
Еще одна цель обзора конкурентов — рассмотрение идей, реализованных в
продукте.
Цель проста — использовать наиболее удачные решения, реализованные в
конкурирующих продуктах, и исключить неудачные. Так сказать, сделать работу над
ошибками других.
Структура обзора конкурентов обычно следующая:
1. Конкурентное положение на рынке.
2. Список конкурентов (Резюме по каждому конкуренту).
3. Список проблем, которые призваны решать продукты.
4. Список возможностей продуктов.
В процессе создания обзора вам потребуется пройти этапы, описанные ниже.
1. Определить список конкурентов на рынке и выделить лидеров. Вся
дальнейшая работа проводится с лидерами на рынке. Определить лидеров можно,
используя различные обзоры, результаты опросов или продаж. Следует учесть, что в
числе лидеров может оказаться не только продукт с отличным функционалом, но и
бесплатное приложение, предоставляющее необходимый минимум возможностей.
Если предметная область продуктов достаточно популярна, то в сети можно
найти уже готовый обзор, который будет содержать необходимую для вас
информацию.
2. Узнать цену и способ доставки конкурентов. Также нужно постараться
достать демонстрационную версию продукта. Если это не удалось, то надо хотя бы
найти маркетинговые материалы, содержащие список возможностей и руководство
пользователя.
3. Составить список проблем, которые решает каждый конкурент. Этот
раздел обзора конкурентов особенно интересен при проектировании продукта для
открытого рынка, так как благодаря ему аналитик сможет определить максимальное
количество проблем, для решения которых пользователи захотят купить будущий
продукт.
Составить список проблем можно, исследовав продукт самостоятельно, но более
эффективный способ — просмотреть документацию по продукту. Качественные
продукты содержат сценарии использования продукта в тех или иных ситуациях, а
маркетинговые материалы — выгоды, которые сулит продукт при его использовании.
Все проблемы, для решения которых созданы продукты, должны отвечать на
вопрос «зачем?».
Суммарную информацию о конкурентах желательно поместить в таблицу. В ней
нужно указать, кто имеет возможность решать указанную проблему (сегмент рынка
или профиль пользователей) и насколько важно иметь возможность ее решать
(обязательно (essential), полезно (useful), желательно (desirable)). В ячейке продукта
напротив каждой проблемы нужно указать предоставляет ли конкурент эту
возможность или нет (обычно помечаются как «+», «−» или «+/−»). Также полезно
дополнять записи кратким описанием проблемы и заметками о конкурентах.

5
 По завершении исследования проблем, которые решают продукты конкурентов,
следует провести повторный анализ бизнес требований к своему продукту.
Полученная информация о конкурентах поможет вам сделать бизнес требования к
вашему продукту лучше.
Совет: Если вы занимаетесь проектированием новой версии продукта, то
имеет смысл добавить предыдущую его версию в качестве конкурента. Это
поможет вам увидеть текущее конкурентное положение продукта и различия между
старой и новой его версиями.
4. Составить список возможностей. Здесь нужно описать все важные
возможности, которые были реализованы в конкурентных продуктах для
удовлетворения проблем. На основе этого списка можно узнать, как хорошо продукт
решает заявленные проблемы, какие у него сильные и слабые стороны.
На этом этапе вам придется работать либо с самим продуктом, либо с его
документацией.
Результатом работы будет таблица со списком возможностей, которые
предоставляют все продукты. В столбце продукта напротив каждой возможности
должно быть указано предоставляет ли конкретный продукт эту возможность (обычно
помечаются как «+» или «−»). Также полезно дополнять записи кратким описанием
возможности и заметками о конкурентах.

5. Обобщая всю полученную информацию, полезно составить резюме по

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

Источники требований
Основным источником требований к информационной системе, безусловно,
являются соображения, высказанные представителями Заказчика. Данная информация
структурируется как минимум на 2 уровня:
– бизнес-требования
– требования пользователей.
Наряду с требованиями, высказанными Заказчиком, целесообразно собирать и
требования от других совладельцев системы: сотрудников аналитической группы
исполнителя, внешних экспертов и т.д.
Результирующий, часто достаточно сырой материал рассматривается, как
документ "Требования совладельцев". На требования совладельцев обычно не
накладывается никаких специальных ограничений.
Другим важным источником информации, помимо выявления требований,
являются артефакты, описывающие предметную область. Это могут быть документы с
описанием бизнес-процессов предприятия, должностные инструкции, распоряжения,
своды бизнес-правил, принятые на предприятии.
Таким образом, основными источниками, образующими "вход" процесса
выявления требований, являются требования, высказанные совладельцами, как
таковые или (и) артефакты, описывающие объект исследования.
Однако, это достаточно упрощенный взгляд: чтобы данные поступили "на вход",
аналитики требований должны проделать немалую работу, связанную с подбором
респондентов и информационных материалов, организацией интервью и т.д.

Стратегии выявления требований

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

7
 При выборе собеседника для целей сбора требований определяющими являются
две вещи:
– Он действительно является экспертом по данному вопросу;
– Его мнение действительно является ценным при формировании целевого
набора требований.
Важно заранее оговорить цель встречи и ограничить беседу в пределах часа или
менее. Если этого времени недостаточно, можно спланировать несколько встреч.
Полезными приемами являются формирование программы беседы и
ознакомление с ней респондента, подробное планирование беседы вплоть до записи
подготовленных вопросов. Подготовленное таким образом интервью называют
структурированным. В дополнение к так построенному интервью автор предлагает
проводить неструктурированное интервью, "представляющее собой неформальную
встречу, которой не свойственны заготовленные впрок вопросы или заранее
поставленные цели". Цель такого интервью – пробудить респондента к креативу в
области, в которой интервьюер недостаточно хорошо ориентируется.

2. Проведение опроса
В проведении опроса самое важное – правильно организовать и поддерживать
поток информации от эксперта к вам. Рекомендуется потратить время на обдумывание
верного начала опроса, при сборе информации по возможности использовать записи,
заканчивать разговор плавно.
3. Завершение
Следует следить за возникновением следующих ситуаций:
– вы уже получили достаточно информации;
– вы получаете большой объем неподходящей информации;
– обилие информации вас подавляет;
– эксперт начинает уставать;
– у вас с экспертом часто возникают конфликты.
Любая из этих причин – достаточное основание для завершения беседы.
Материалы опроса необходимо оформить сразу же после встречи с экспертом.

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

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

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

Самостоятельное описание требований

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

Совместные семинары
Помимо классического интервью "тет а тет", существует значительное
количество методик, предполагающих широкое участие представителей Заказчика и
Исполнителя.
Правила мозгового штурма предполагают полную раскрепощенность и свободу
мнений.
Первое правило мозгового штурма – "полный запрет на любую критику". Всякое
высказанное мнение представляет ценность, а полное отсутствие запретов позволяет
полноценным образом подключить творческую фантазию.
На втором этапе, все высказанные мнения тщательным образом обсуждаются,
заведомо неприемлемые варианты отсеиваются, формируются коллективные
предложения.
JAD (Joint Application Development or Design) – cовместная разработка (или
проектирование) приложений. JAD – это семинар с участием модератора,
использующийся в области разработки программного обеспечения.
Участники JAD-совещания:
Ведущий – специалист в области межличностных коммуникаций. Должен
ориентироваться в предметной области, но не обязательно хорошо ориентироваться в
проблемах IT.
Секретарь – стенографист встречи. Фиксирует ее результаты на компьютере.
Заказчики – пользователи или руководители, основные участники,
формирующие, обсуждающие требования и принимающие решения.
Разработчики – аналитики и другие участники проектной команды. Работают в
большей части в пассивном режиме с целью наилучшего понимания проблемной
области.
Совместные семинары, сохраняя все преимущества режима интервью, привносят
дополнительные бонусы: работа в группе более продуктивна, группы быстрее
обучаются, более склонны к квалифицированным заключениям, позволяют исключить
многие ошибки.

Прототипирование
При разработке требований трудно предвидеть, как система будет
взаимодействовать с другими системами, как она повлияет на трудовой процесс, какие
операции нужно автоматизировать. Анализ требований позволяет снять некоторую

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

Прототип – это начальная версия программной системы, которая используется

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

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

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

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

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

Процесс использования экспериментального прототипа для анализа требований.

Обобщенные Разработка Оценка Системные

требования прототипа прототипа требования

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

На основе обобщенных требований к системе строится ее прототип, который

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

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

11
 Разработка
Разработка Использование
обобщенной специфи-
прототипа системы прототипа системы
кации

Система не соот-
ветствует целям
Законченная Проверка
система системы
Система
соответствует целям
Основные преимущества эволюционного прототипирования заключаются в том,
что они позволяют:
– Ускорить разработку программной системы. В некоторых случаях быстрая
разработка и поставка системы, удобство и простота использования перевешивают
факт ее функциональной неполноты.
− Участвовать пользователям в процессе разработки. Взаимодействие
пользователя с системой – это гарантии более полного учета их требований.
Проблемы эволюционного прототипирования возникают при разработке
достаточно больших систем. Основная проблема – управление проектом. Если процесс
разработки выполняется в соответствии с некоторой моделью, то для оценки
выполнения работ на каждом этапе используются вехи и определенные контрольные
артефакты. Прототипы могут изменяться так быстро, что создание контрольных
элементов станет нерентабельным, и будет только задерживать проект.

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

Основными процессами управления требованиями являются следующие:

• разработка требований – выявление, анализ и формализация новых требований:
требования создаются или изменяется их содержание;
• контроль реализации требований – контроль и фактическое изменение
состояния, значения атрибутов и содержания существующих требований;
• управление изменениями ИТ-проекта – контроль и фактическое внесение
изменений в ИТ-проект согласно требованиям.

12
 Все процессы и входящие в их состав процедуры должны быть четко
регламентированы и описаны формальным образом в виде внутренних инструкций,
стандартов предприятия и т.д.
Обязательно должны быть регламентированы следующие процедуры:
• процедура выявления требований;
• процедура верификации требований;
• процедуры изменения требований.

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

управления требованиями.

Программное обеспечение управления требованиями

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

Выделяют следующие критерии выбора системы управления требованиями:

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

В случае соответствия вышеперечисленным критериям ПО управления

требованиями помогает участникам ИТ-проекта осуществлять сбор и анализ

13
информации, создавать качественные сценарии использования, расширять
возможности отслеживания, повышать эффективность совместной работы, уменьшать
потребность в доработках и повышать качество ИТ-продукта.
Использование такого инструмента разработки:
• снижает сложность благодаря подробным представлениям с возможностью
трассировки, в которых показаны отношения между родительскими и дочерними
элементами;
• снижает связанные с проектом риски, показывая требования, которые могут
быть затронуты изменениями требований более низкого или более высокого уровня;
• обеспечивает совместную работу географически распределенных рабочих
групп благодаря применению полнофункционального, масштабируемого веб-
интерфейса и цепочек обсуждения;
• обеспечивает сбор и анализ сведений о требованиях с возможностью точной
настройки атрибутов и фильтрации;
• повышает производительность труда, позволяя отслеживать изменения путем
сравнения версий проекта с начальными характеристиками, описанными с помощью
XML;
• обеспечивает соответствие результатов проекта поставленным задачам и
бизнес-целям благодаря интеграции со средствами разработки и выпуска ПО.
Таким образом, ПО управления требованиями предоставляет следующие
преимущества:
• повышение эффективности процесса сбора и анализа требований путем
вовлечения всех участников процесса, включая представителей заказчиков, в
обсуждение и работу над требованиями;
• уменьшение затрат на создание, рецензирование и поддержку
многостраничных документов требований;
• снижение риска возникновения неактуальных, не покрытых, не реализованных
требований;
• совместная работа, управление и анализ требований из любой точки мира;
• использование древовидной структуры небольших разделов требований;
• трассирование разделов требований между собой (построение матрицы
трассировки) и с другими проектными артефактами с поддержкой актуальности
связей;
• автоматическая подготовка сводных документов требований на основе
корпоративных шаблонов документов.
В настоящее время наиболее популярными являются следующие системы
управления требованиями: IBM Rational RequisitePro, Telelogic DOORS, Sybase
PowerDesigner и Borland Caliber RM, OpenSource Requirements Management Tool,
Requirements Win, 3SL Cradle и многие другие.

14
 Лекция 11
Методы анализа и проектирования программного обеспечения (ч.1)

Цель проектирования программного обеспечения.

Проектирование программного обеспечения — процесс создания проекта
программного обеспечения (ПО), а также дисциплина, изучающая методы
проектирования. Проектирование ПО является частным случаем проектирования
продуктов и процессов.
Целью проектирования является определение внутренних свойств системы и
детализации её внешних (видимых) свойств на основе выданных заказчиком требований
к ПО (исходные условия задачи). Эти требования подвергаются анализу.
Проектирование ПО включает следующие основные виды деятельности:
− выбор метода и стратегии решения;
− выбор представления внутренних данных;
− разработка основного алгоритма;
− документирование ПО;
− тестирование и подбор тестов;
− выбор представления входных данных.
Первоначально программа рассматривается как чёрный ящик. Ход процесса
проектирования и его результаты зависят не только от состава требований, но и
выбранной модели процесса, опыта проектировщика.
Модель предметной области накладывает ограничения на бизнес-логику и
структуры данных.
В зависимости от класса создаваемого ПО, процесс проектирования может
обеспечиваться как «ручным» проектированием, так и различными средствами его
автоматизации. В процессе проектирования ПО для выражения его характеристик
используются различные нотации — блок-схемы, ER-диаграммы, UML-диаграммы,
DFD-диаграммы, а также макеты.

Объекты проектирования.
Проектированию обычно подлежат:
Архитектура ПО;
Устройство компонентов ПО;
Пользовательские интерфейсы.

Стадии и этапы проектирования в соответствии с ГОСТ 34.601-90.

Проектирование ведется поэтапно в соответствии со стадиями,
регламентированными ГОСТ 34.601-90 (Комплекс стандартов на автоматизированные
системы):
Стадии Этапы
Формирование Обследование объекта и обоснование необходимости
требований к АС создания АС
Формирование требований пользователя к АС
Оформление отчета о выполненной работе и заявки на
разработку АС (тактико-технического задания)

1
Разработка концепции Изучение объекта
АС
Проведение необходимых научно-исследовательских
работ
Разработка вариантов концепции АС и выбор варианта
концепции АС, удовлетворяющего требованиям
пользователя
Оформление отчета о выполненной работе
Техническое задание Разработка и утверждение технического задания на
создание АС
Эскизный проект Разработка предварительных проектных решений по
системе и ее частям
Разработка документации на АС и ее части
Технический проект Разработка проектных решений по системе и ее частям
Разработка документации на АС и ее части
Разработка и оформление документации на поставку
изделий для комплектования АС и (или) технических
требований (технических
заданий) на их разработку
Разработка заданий на проектирование в смежных
частях проекта объекта автоматизации
Рабочая документация Разработка рабочей документации на систему и ее части
Разработка или адаптация программ
Ввод в действие Подготовка объекта автоматизации к вводу АС в
действие
Подготовка персонала
Комплектация АС поставляемая изделиями
(программными и техническими средствами,
программно-техническими комплексами,
информационными изделиями)
Строительно-монтажные работы
Пусконаладочные работы
Проведение предварительных испытаний
Проведение опытной эксплуатации
Проведение приемочных испытаний
Сопровождение АС Выполнение работ в соответствии с гарантийными
обязательствами. Послегарантийное обслуживание
2
 Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на
всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в
одну стадию «Техно-рабочий проект». В зависимости от специфики создаваемых АС и
условий их создания допускается выполнять отдельные этапы работ до завершения
предшествующих стадий, параллельное во времени выполнение этапов работ,
включение новых этапов работ.
На этапе "Обследование объекта и обоснование необходимости создания АС"
в общем случае проводят:
- сбор данных об объекте автоматизации и осуществляемых видах деятельности;
- оценку качества функционирования объекта и осуществляемых видов
деятельности, выявление проблем, решение которых возможно средствами
автоматизации;
- оценку (технико-экономической, социальной и т.п.) целесообразности создания
АС.

На этапе "Формирование требований пользователя к АС" проводят:

- подготовку исходных данных для формирования требований к АС;
- формулировку и оформление требований пользователя к АС.

На этапе "Оформление отчета о выполненной работе и заявки на разработку

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

На этапах "Изучение объекта" и "Проведение необходимых научно-

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

На этапе "Разработка вариантов концепции АС и выбор варианта концепции

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

На этапе "Оформление отчета о выполненной работе" подготавливают и

оформляют отчет, содержащий описание выполненных работ на стадии, описание и
обоснование предлагаемого варианта концепции системы.

На этапе "Разработка и утверждение технического задания на создание АС"

проводят разработку, оформление, согласование и утверждение технического задания
на АС и, при необходимости, технических заданий на части АС.

3
 На этапе "Разработка предварительных проектных решений по системе и ее
частям" определяются: функции АС; функции подсистем, их цели и эффекты; состав
комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная
структура; функции системы управления базой данных; состав вычислительной
системы; функции и параметры основных программных средств.

На этапе "Разработка проектных решений по системе и ее частям"

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

На этапах "Разработка документации на АС и ее части" проводят разработку,

оформление, согласование и утверждение документации в объеме, необходимом для
описания полной совокупности принятых проектных решений и достаточном для
дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201.

На этапе "Разработка и оформление документации на поставку изделий для

комплектования АС и (или) технических требований (технических заданий) на их
разработку" проводят: подготовку и оформление документации на поставку изделий
для комплектования АС; определение технических требований и составление ТЗ на
разработку изделий, не изготавливаемых серийно.

На этапе "Разработка заданий на проектирование в смежных частях

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

На этапе "Разработка рабочей документации на систему и ее части"

осуществляют разработку рабочей документации, содержащей все необходимые и
достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее
эксплуатации, а также для поддерживания уровня эксплуатационных характеристик
(качества) системы в соответствии с принятыми проектными решениями, ее
оформление, согласование и утверждение. Виды документов − по ГОСТ 34.201.

На этапе "Разработка или адаптация программ" проводят разработку

программ и программных средств системы, выбор, адаптацию и (или) привязку
приобретаемых программных средств, разработку программной документации в
соответствии с ГОСТ 19.101.

На этапе "Подготовка объекта автоматизации к вводу АС в действие"

проводят работы по организационной подготовке объекта автоматизации к вводу АС в
действие, в том числе: реализацию проектных решений по организационной структуре
АС; обеспечение подразделений объекта управления инструктивно-методическими
материалами; внедрение классификаторов информации.

4
 На этапе "Подготовка персонала" проводят обучение персонала и проверку его
способности обеспечить функционирование АС.

На этапе "Комплектация АС поставляемыми изделиями" обеспечивают

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

На этапе "Строительно-монтажные работы" проводят: выполнение работ по

строительству специализированных зданий (помещений) для размещения технических
средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу
технических средств и линий связи; испытание смонтированных технических средств;
сдачу технических средств для проведения пусконаладочных работ.

На этапе "Пусконаладочные работы" проводят автономную наладку

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

На этапе "Проведение предварительных испытаний" осуществляют

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

На этапе "Проведение опытной эксплуатации" проводят: опытную

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

На этапе "Проведение приемочных испытаний" проводят: испытания на

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

На этапе "Выполнение работ в соответствии с гарантийными

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

На этапе "Послегарантийное обслуживание" осуществляют работы по:

- анализу функционирования системы;
- выявлению отклонений фактических эксплуатационных характеристик АС от
проектных значений;
- установлению причин этих отклонений;

5
 - устранению выявленных недостатков и обеспечению стабильности
эксплуатационных характеристик АС;
- внесению необходимых изменений в документацию на АС.

Документирование программного обеспечения

Составление программной документации – очень важный этап жизненного цикла
программной системы.
Существует четыре основных типа документации на ПО:
− архитектурная/проектная — обзор программного обеспечения,
включающий описание рабочей среды и принципов, которые должны быть
использованы при создании ПО
− техническая — документация на код, алгоритмы, интерфейсы, API (API −
программный интерфейс приложения, интерфейс прикладного программирования)
− пользовательская — руководства для конечных пользователей,
администраторов системы и другого персонала
− маркетинговая

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

Техническая документация
При создании программы, одного лишь кода, как правило, недостаточно. Должен
быть предоставлен некоторый текст, описывающий различные аспекты того, что
именно делает код. Такая документация часто включается непосредственно в исходный
код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технический характер и в
основном используется для определения и описания API, структур данных и
алгоритмов.
Часто при составлении технической документации используются
автоматизированные средства — генераторы документации, такие как Doxygen, javadoc,
NDoc и другие. Они получают информацию из специальным образом оформленных
комментариев в исходном коде, и создают справочные руководства в каком-либо
формате, например, в виде текста или HTML.
Использование генераторов документации и документирующих комментариев
многими программистами признаётся удобным средством, по различным причинам. В
частности, при таком подходе документация является частью исходного кода, и одни и
те же инструменты могут использоваться для сборки программы и одновременной
сборки документации к ней. Это также упрощает поддержку документации в
актуальном состоянии.

6
 Пользовательская документация
Отличие от технической документации, сфокусированной на коде и том, как он
работает, пользовательская документация описывает лишь то, как использовать
программу.
Обычно, пользовательская документация представляет собой руководство
пользователя, которое описывает каждую функцию программы, а также шаги, которые
нужно выполнить для использования этой функции. Хорошая пользовательская
документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае
возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение
и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если
имеется сквозной предметный указатель. Логическая связность и простота также имеют
большое значение.
Существует три подхода к организации пользовательской документации.
Вводное руководство, наиболее полезное для новых пользователей,
последовательно проводит по ряду шагов, служащих для выполнения каких-либо
типичных задач.
Тематический подход, при котором каждая глава руководства посвящена какой-
то отдельной теме, больше подходит для совершенствующихся пользователей.
В последнем, третьем подходе, команды или задачи организованы в виде
алфавитного справочника — часто это хорошо воспринимается продвинутыми
пользователями, хорошо знающими, что они ищут.
Жалобы пользователей обычно относятся к тому, что документация охватывает
только один из этих подходов, и поэтому хорошо подходит лишь для одного класса
пользователей. Во многих случаях разработчики программного продукта ограничивают
набор пользовательской документации лишь встроенной системой помощи,
содержащей справочную информацию о командах или пунктах меню. Работа по
обучению новых пользователей и поддержке совершенствующихся пользователей
перекладывается на частных издателей, часто оказывающих значительную помощь
разработчикам.

Маркетинговая документация
Для многих приложений необходимо располагать рядом с ними рекламные
материалы, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая
форма документации имеет целью:
− подогреть интерес к продукту у потенциальных пользователей
− информировать их о том, что именно делает продукт, с тем чтобы их ожидания
совпадали с тем, что они получат
− объяснить положение продукта по сравнению с конкурирующими решениями
Одна из хороших маркетинговых практик — предоставление слогана— простой
запоминающейся фразы, иллюстрирующей то, что мы хотим донести до пользователя,
а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы дают
более ясную картину о возможностях и способах использования программы, чем всё
остальное.

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

со стандартами ЕСПД (группа стандартов − ГОСТы 19.ХХХ).

7
 В соответствии с данными стандартами должны оформляться следующие
программные документы:
Спецификация должна содержать перечень и краткое описание назначения всех
файлов программного обеспечения, в том числе и файлов документации на него.
Спецификация является обязательной для программных систем, а также их
компонентов, имеющих самостоятельное применение.
Ведомость держателей подлинников (код вида документа – 05) должна
содержать список предприятий, на которых хранятся подлинники программных
документов.
Текст программы (код вида документа – 12) должен содержать текст программы
с необходимыми комментариями.
Описание программы (код вида документа – 13) должно содержать сведения о
логической структуре и функционировании программы.
Ведомость эксплуатационных документов (код вида документа – 20) должна
содержать перечень эксплуатационных документов на программу, к которым относятся
документы с кодами 30, 31, 32, 33, 34, 35, 46.
Формуляр (код вида документа – 30) должен содержать основные характеристики
программного обеспечения, комплектность и сведения об эксплуатации программы.
Описание применения (код вида документа – 31) должно содержать сведения о
назначении программного обеспечения, области применения, применяемых методах,
класс решаемых задач, ограничениях для применения, минимальной конфигурации
технических средств.
Руководство системного программиста (код вида документа – 32) должно
содержать сведения для проверки, обеспечения функционирования и настройки
программы на условия конкретного применения.
Кроме того, в него часто включают и описание необходимого обслуживания,
которое раньше приводилось в руководстве оператора (ГОСТ 19.505-79) и/или
руководстве по техническому обслуживанию (ГОСТ 19.508-79). В настоящее время
данную схему используют для составления руководства системному администратору.
Руководство системного программиста должно содержать следующие разделы:
• общие сведения о программном продукте,
• структура,
• настройка,
• проверка,
• дополнительные возможности,
• сообщения системному программисту.
Раздел Общие сведения о программе должен включать описание назначения и
функций программы, а также сведения о технических и программных средствах,
обеспечивающих выполнение данной программы (например, объем оперативной
памяти, требования к составу и параметрам внешних устройств, требования к
программному обеспечению и т. п.).
В разделе Структура программы должны быть приведены сведения о структуре
программы, ее составных частях, о связях между составными частями и о связях с
другими программами.
В разделе Настройка программы должно быть приведено описание действий по
настройке программы на условия практического применения.

8
 В разделе Проверка программы должно быть приведено описание способов
проверки работоспособности программы, например, контрольные примеры.
В разделе Дополнительные возможности должно быть приведено описание
дополнительных возможностей программы и способов доступа к ним.
В разделе Сообщения системному программисту должны быть указаны тексты
сообщений, выдаваемых в ходе выполнения настройки и проверки программы, а также
в ходе ее выполнения, описание их содержания и действий, которые необходимо
предпринять по этим сообщениям.

Руководство программиста (код вида документа – 33) должно содержать

сведения для эксплуатации программного обеспечения.
Руководство оператора (код вида документа – 34) должно содержать сведения
для обеспечения процедуры общения оператора с вычислительной системой в процессе
выполнения программного обеспечения.
Описание языка (код вида документа – 35) должно содержать описание
синтаксиса и семантики языка.
Руководство по техническому обслуживанию (код вида документа – 46) должно
содержать сведения для применения тестовых и диагностических программ при
обслуживании технических средств.
Программа и методика испытаний (код вида документа – 51) должны
содержать требования, подлежащие проверке при испытании программного
обеспечения, а также порядок и методы их контроля.
Пояснительная записка (код вида документа – 81) должна содержать
информацию о структуре и конкретных компонентах программного обеспечения, в том
числе схемы алгоритмов. Их общее описание, а также обоснование принятых
технических и технико-экономических решений.
Пояснительная записка должна включать следующие разделы:
– введение;
– назначение и область применения;
– технические характеристики;
– ожидаемые технико-экономические показатели;
– источники, используемые при разработке.
В разделе Введение указывают наименование программы и документа, на
основании которого ведется разработка.
В разделе Назначение и область применения указывают назначение программы и
дают краткую характеристику области применения.
Раздел Технические характеристики должен содержать следующие подразделы:
– постановку задачи, описание применяемых математических методов и
допущений и ограничений, связанных с выбранным математическим аппаратом;
– описание алгоритмов и функционирования программы с обоснованием
принятых решений;
– описание и обоснование выбора способа организации входных и выходных
данных;
– описание и обоснование выбора состава технических и программных средств на
основании проведенных расчетов или анализов.

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

Руководство пользователя. Составление документации для пользователей имеет

свои особенности, связанные с тем, что пользователь, как правило, не является
профессионалом в области разработки программного обеспечения. Руководство
пользователя должно содержать краткие инструкции, написанные на понятном для
непрофессионала языке.
Руководство пользователя, как правило, содержит следующие разделы:
– общие сведения о программном продукте;
– описание установки;
– описание запуска;
– инструкции по работе (или описание пользовательского интерфейса);
– сообщения пользователю.
Раздел Общие сведения о программе обычно содержит наименование
программного продукта, краткое описание его функций, реализованных методов и
возможных областей применения.
Раздел Установка обычно содержит подробное описание действий по установке
программного продукта и сообщений, которые при этом могут быть получены.
В разделе Запуск, как правило, описаны действия по запуску программного
продукта и сообщения, которые при этом могут быть получены.
Раздел Инструкции по работе обычно содержит описание режимов работы,
форматов ввода-вывода информации и возможных настроек.
Раздел Сообщения пользователю должен содержать перечень возможных
сообщений, описание их содержания и действий, которые необходимо предпринять по
этим сообщениям.

Функции программной документации

Для эффективного управления документированием программного обеспечения,
важно осознавать различные функции, выполняемые документацией.
Программную документацию можно рассматривать как имеющую шесть
основных функций:
1) информация для управления;
2) связь между задачами;
3) обеспечение качества;
4) инструкции и справки;
5) сопровождение программного обеспечения;
6) исторические справки.

Информация для управления

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

10
представляют планы на следующий период, обеспечивают контрольные механизмы и
обзор проекта.

Связь между задачами

Большинство проектов разработки программного обеспечения разделяется на
задачи, зачастую выполняемые различными группами.
В типовом варианте:
− специалисты в предметной области начинают проект;
− аналитики формулируют требования к системе;
− проектировщики разрабатывают системный и программный проекты;
− специалисты по изданиям создают пользовательскую документацию в
соответствии со стратегией и стандартами по документированию;
− специалисты по обеспечению качества и ревизоры оценивают общую
полноту и качество функционирования программного обеспечения;
− сопровождающие программисты улучшают эксплуатируемое программное
обеспечение и разрабатывают его изменения или расширения.

Этим людям необходимы средства общения друг с другом, обеспечивающие

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

Обеспечение качества
Требуется документация разработки и документация продукции для выполнения
задач, связанных с обязанностями по обеспечению качества программного обеспечения.

Инструкции и справки
Документация, требующаяся операторам, пользователям, руководителям и
другим заинтересованным лицам для того, чтобы понимать и использовать
программную продукцию.

Сопровождение программного обеспечения

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

Исторические справки
Документация, требуемая в качестве исторической справки по проекту. Данная
документация может помочь в переносе и переводе программного обеспечения в новое
окружение.

11
 Понятие и основные процессы инициации проекта
Инициация проекта (Project Initiating) – стадия процесса управления проектом,
результатом которой является санкционирование начала проекта или очередной фазы
его жизненного цикла
Основными причинами появлениями (источниками идей) проектов являются:
• Неудовлетворенный спрос;
• Избыточные ресурсы;
• Инициатива предпринимателей;
• Реакция на политическое давление;
• Интересы кредиторов.

Примеры причин отклонения проекта:

• Недостаточный спрос на продукцию проекта или отсутствие его реальных
преимуществ перед аналогичными видами продукции;
• Чрезмерно высокая стоимость проекта (экономическая, экологическая,
социальная и др.);
• Отсутствие необходимых гарантий со стороны заказчика проекта;
• Чрезмерный риск;
• Высокая стоимость сырья.

Инициация проекта включает следующие задачи и процедуры:

1. Разработка концепции проекта:
• Анализ проблемы и потребности в проекте
• Сбор исходных данных
• Определение целей и задач проекта
• Разработка концепции по отдельным функциям управления проекта:
• Предметная область:
• Рассмотрение альтернативных вариантов
• Время:
• Выбор методов и определение процедур управления проектом по
временным параметрам
• Выбор программного обеспечения для календарного планирования
• Определение временных ограничений
• Разработка укрупненного календарного плана осуществления проекта
• Определение требований к системе управления проектом по
временным параметрам
• Стоимость:
• Выработка стратегии управления стоимостью и финансами проекта
(определение целей и задач, критериев успеха и неудач, ограничений и допущений)
• Проведение экономического анализа и обоснования проекта
(проведение маркетинга, оценка стоимости и источников финансирования, прогноз
выполнения)
• Общая экономическая оценка проекта
• Разработка укрупненного графика финансирования
• Определение требований к системе управления стоимостью и
финансированием в проекте

12
 • Качество:
• Выработка стратегии управления качеством в проекте (определение
целей и задач, критериев успеха и неудач, ограничений и допущений)
• Определение общих требований и принципов обеспечения качества
(Стандарты и правила)
• Требования к системе управления качеством
• Риски:
• Определение целей управления рисками в проекте
• Идентификация факторов риска и неопределенности
• Определение возможных источников рисков
• Выбор стратегии управления рисками в проекте
• Анализ альтернатив
• Определение требований к системе управления рисками
• Персонал:
• Выработка стратегии управления персоналом (определение цели и
задач управления персоналом, требований к персоналу, ограничений)
• Определение потребности в трудовых ресурсах проекта
• Определение структуры и функций команды проекта
• Формирование жизненного цикла команды
• Анализ возможностей обеспечения проекта нужными
специалистами
• Определение требований к управлению персоналом
• Коммуникации:
• Определение участников проекта
• Определение базовой документации проекта
• Определение требований к коммуникациям
• Обоснование и выбор коммуникационных технологий для управления
проектом
• Оценка альтернатив
• Контракты:
• Проведение маркетинга рынка продуктов и услуг
• Разработка стратегии управления контрактами
• Составление спецификации продуктов и услуг
• Определение возможных источников приобретения ресурсов
• Анализ альтернатив
• Изменения:
• Выработка стратегии управления изменениями
• Анализ возможных изменений
• Определение принципов интеграции процессов управления
изменениями
2. Рассмотрение и утверждение концепции
3. Собственно инициирование:
• Принятие решения о начале проекта
• Определение и назначение управляющего проектом
• Принятие решения об обеспечении ресурсами выполнения первой фазы
проекта

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

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

• Формирование команды проекта
• Определение целей и масштабов проекта
• Определение необходимого оборудования и материалов
• Пояснение и разработка основных условий
• Определение и создание организации проекта
• Определение процедур сотрудничества
• Первоначальное планирование проекта
• Разработка резюме (паспорта) проекта

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

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

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

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

14
 Структурно-функциональная методология
В структурном анализе и проектировании используются различные модели,
описывающие:
Функциональную структуру системы;
Последовательность выполняемых действий;
Передачу информации между функциональными процессами;
Отношения между данными.
Наиболее распространенными реализациями этих моделей являются:
− Функциональная модель SADT (Structured Analysis and Design Technique);
− Модель IDEF3;
− DFD (Data Flow Diagrams) — диаграммы потоков данных.
− Диаграмма «сущность — связь» (ERD — Entity-Relationship Diagram).

Метод SADT (IDEF0)

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную

функцию в рамках рассматриваемой системы. На диаграмме функциональный блок
изображается прямоугольником. Каждая из четырех сторон функционального блока
имеет свое определенное значение (роль), при этом:
верхняя сторона имеет значение «Управление» (Control);
левая сторона имеет значение «Вход» (Input);
правая сторона имеет значение «Выход» (Output);
нижняя сторона имеет значение «Механизм» (Mechanism).

В пояснительном тексте к контекстной диаграмме должна быть указана цель

(Purpose) построения диаграммы в виде краткого описания и зафиксирована точка
зрения (Viewpoint).

Интерфейсная дуга (Arrow)

15
 Также интерфейсные дуги часто называют потоками или стрелками.
Интерфейсная дуга отображает элемент системы, который обрабатывается
функциональным блоком или оказывает иное влияние на функцию, отображенную
данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная
стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование
(Arrow Label).
С помощью интерфейсных дуг отображают различные объекты, в той или иной
степени определяющие процессы, происходящие в системе. Такими объектами могут
быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных
и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она
носит название “входящей”, “исходящей” или “управляющей”. Кроме того,
“источником” (началом) и “приемником” (концом) каждой функциональной дуги могут
быть только функциональные блоки, при этом “источником” может быть только
выходная сторона блока, а “приемником” любая из трех оставшихся.
Имя стрелки обычно задается именем существительным.
В методологии IDEF0 требуется только пять типов взаимодействий между
блоками для описания их отношений:
- связь по входу (output-input), когда выход вышестоящей работы соединяется с
входом нижестоящей;

- связь по управлению (output-control), когда выход вышестоящей работы

соединяется с управлением нижестоящей;

- обратная связь по входу (output-input feedback), когда выход нижестоящей

работы соединяется с входом вышестоящей;

16
 - обратная связь по управлению (output-control feedback), когда выход
нижестоящей работы соединяется с входом по управлению вышестоящей работы;

- связь выход-механизм (output-mechanism), когда выход одной работы

направляется на механизм другой.

При построении IDEF0 – диаграмм важно правильно отделять входящие

интерфейсные дуги от управляющих, что часто бывает непросто.

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

Декомпозиция (Decomposition)
Принцип декомпозиции применяется при разбиении сложного процесса на
составляющие его функции. При этом уровень детализации процесса определяется
непосредственно разработчиком модели.

18
 Декомпозиция позволяет постепенно и структурированно представлять модель
системы в виде иерархической структуры отдельных диаграмм, что делает ее менее
перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого –
одного функционального блока с интерфейсными дугами, простирающимися за
пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком
называется контекстной диаграммой, и обозначается идентификатором “А-0”.

В пояснительном тексте к контекстной диаграмме должна быть указана цель

(Purpose) построения диаграммы в виде краткого описания и зафиксирована точка
зрения (Viewpoint).
Цель определяет соответствующие области в исследуемой системе, на которых
необходимо фокусироваться в первую очередь.
Точка зрения определяет основное направление развития модели и уровень
необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить
модель, отказавшись от детализации и исследования отдельных элементов, не
являющихся необходимыми, исходя из выбранной точки зрения на систему. Например,
функциональные модели одного и того же предприятия с точек зрения главного
технолога и финансового директора будут существенно различаться по направленности
их детализации. Это связано с тем, что в конечном итоге, финансового директора не
интересуют аспекты обработки сырья на производственных станках, а главному
19
технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор
точки зрения существенно сокращает временные затраты на построение конечной
модели.
В процессе декомпозиции, функциональный блок, который в контекстной
диаграмме отображает систему как единое целое, подвергается детализации на другой
диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки,
отображающие главные подфункции функционального блока контекстной диаграммы
и называется дочерней (Child diagram) по отношению к нему (каждый из
функциональных блоков, принадлежащих дочерней диаграмме соответственно
называется дочерним блоком – Child Box). В свою очередь, функциональный блок -
предок называется родительским блоком по отношению к дочерней диаграмме (Parent
Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent
Diagram). Каждая из подфункций дочерней диаграммы может быть далее
детализирована путем аналогичной декомпозиции соответствующего ей
функционального блока. Существует взаимосвязь нумерации функциональных блоков
и диаграмм − каждый блок имеет свой уникальный порядковый номер на диаграмме
(цифра в правом нижнем углу прямоугольника), а обозначение под правым углом
указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения
говорит о том, что декомпозиции для данного блока не существует.

Глоссарий (Glossary).
Для каждого из элементов IDEF0: диаграмм, функциональных блоков,
интерфейсных дуг существующий стандарт подразумевает создание и поддержание
набора соответствующих определений, ключевых слов, повествовательных изложений
и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор
называется глоссарием и является описанием сущности данного элемента. Например,
для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может
содержать перечень полей соответствующего дуге документа, необходимый набор виз
и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая
диаграммы необходимой дополнительной информацией.

20
 Метод моделирования IDEF3 предназначен для таких моделей процессов, в
которых важно понять последовательность выполнения действий и взаимозависимости
между ними.

21
 Единицы работы — Unit of Work (UOW) (работы), являются центральными
компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя,
обозначающее процесс действия и номер (идентификатор).
Связи IDEF3 показывают взаимоотношения работ. Все связи в IDEF3 являются
однонаправленными и имеют следующие типы:
− временное предшествование,
− объектный поток,
− нечеткое отношение.

Изобра-
Название Назначение
жение

Временное Исходное действие должно завершиться,

предшествование прежде чем конечное действие сможет
(Temporal precedence) начаться

Выход исходного действия является входом

конечного действия. Из этого, в частности,
Объектный поток
следует, что исходное действие должно
(Object flow)
завершиться, прежде чем конечное действие
сможет начаться
Вид взаимодействия между исходным и
Нечеткое отношение конечным действиями задается аналитиком
(Relationship) отдельно для каждого случая использования
такого отношения

Связь типа «временное предшествование». Исходное действие должно

полностью завершиться, прежде чем начнется выполнение конечного действия.
Связь типа «объектный поток». Одна из наиболее часто встречающихся причин
использования связи типа «объектный поток» заключается в том, что некоторый объект,
являющийся результатом выполнения исходного действия, необходим для выполнения
конечного действия. Обозначение такой связи отличается от связи временного
предшествования двойной стрелкой.
Связь типа «нечеткое отношение». Связи этого типа используются для
выделения отношений между действиями, которые невозможно описать с
22
использованием предшественных или объектных связей. Значение каждой такой связи
должно быть определено, поскольку связи типа «нечеткое отношение» сами по себе не
предполагают никаких ограничений. Одно из применений нечетких отношений —
отображение взаимоотношений между параллельно выполняющимися действиями.
Наиболее часто нечеткие отношения используются для описания специальных случаев
связей предшествования, например, для описания альтернативных вариантов
временного предшествования.

Перекрестки (Junction) Соединения — используются для отображения логики

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

Пример разворачивающих и сворачивающих соединений

Графическое
Название Вид Правила инициации
обозначение
Разворачи- Каждое конечное действие
Соединение «и»
вающее обязательно инициируется
Сворачи- Каждое исходное действие
вающее обязательно должно завершиться
Соединение
Разворачи- Одно и только одно конечное дей-
«эксклюзивное
вающее ствие инициируется
"или"»
Сворачи- Одно и только одно исходное
вающее действие должно завершиться

23
 Соединение Развора- Одно или несколько конечных
«или» чивающее действий инициируются
Сворачи- Одно или несколько исходных
вающее действий должны завершиться

«И»-соединения. Соединения этого типа инициируют выполнение конечных

действий. Все действия, присоединенные к сворачивающему «и»-соединению, должны
завершиться, прежде чем начнется выполнение следующего действия.

На рисунке после обнаружения пожара инициируются включение пожарной

сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал
производится только тогда, когда все три перечисленных действия завершены.
Соединение «эксклюзивное "или "». Вне зависимости от количества действий,
связанных со сворачивающим или разворачивающим соединением «эксклюзивное
«или», инициировано будет только одно из них, и поэтому только оно будет завершено
перед тем, как любое действие, следующее за сворачивающим соединением
«эксклюзивное «или», сможет начаться. Если правила активации соединения известны,
они обязательно должны быть документированы либо в его описании, либо пометкой
стрелок, исходящих из разворачивающего соединения, как показано на рисунке
На рисунке соединение «эксклюзивное «или» используется для отображения того
факта, что студент не может одновременно быть направлен на лекции по двум разным
курсам.

Соединение «или» предназначено для описания ситуаций, которые не могут быть

описаны двумя предыдущими типами соединений. Аналогично связи нечеткого

24
отношения соединение «или» в основном определяется и описывается непосредственно
системным аналитиком.

Указатели
Указатели — это специальные символы, которые ссылаются на другие разделы
описания процесса. Они используются при построении диаграммы для привлечения
внимания пользователя к каким-либо важным аспектам модели.
Указатель изображается на диаграмме в виде прямоугольника, похожего на
изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ,
UOB и т.п.) и идентификатор
Тип указателя Назначение
Для описания того, что в действии принимает
ОБЪЕКТ (OBJECT) участие какой-либо заслуживающий отдельного
внимания объект
Для реализации цикличности выполнения
ССЫЛКА (GOTO) действий. Указатель ССЫЛКА может относиться и
к соединению
Для многократного отображения на диаграмме
одного и того же действия. Например, если
ЕДИНИЦА ДЕЙСТВИЯ (Unit of действие «Подсчет наличных» выполняется
Behavior — UOB) несколько раз, в первый раз оно создается как
действие, а последующие его появления на
диаграмме оформляются указателями UOB
Для документирования любой важной информации
общего характера, относящейся к изображенному
ЗАМЕТКА (NOTE) на диаграммах. В этом смысле ССЫЛКА служит
альтернативой методу помещения текстовых
заметок непосредственно на диаграммах
Для уточнения или более подробного описания,
УТОЧНЕНИЕ (Elaboration — изображенного на диаграмме. Указатель
ELAB) УТОЧНЕНИЕ обычно используется для описания
логик

Декомпозиция действий
Действия в IDEF3 могут быть декомпозированы или разложены на составляющие
для более детального анализа. Метод IDEF3 позволяет декомпозировать действие
несколько раз, что обеспечивает документирование альтернативных потоков процесса
в одной модели.
Для корректной идентификации действий в модели с множественными
декомпозициями схема нумерации действий расширяется и наряду с номерами действия
и его родителя включает в себя порядковый номер декомпозиции. Например, в номере
действия 1.2.5: 1 — но мер родительского действия, 2 — номер декомпозиции, 5 —
номер действия.

25
 Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой
иерархию функциональных процессов, связанных потоками данных.
Цель такого представления – продемонстрировать, как каждый процесс
преобразует свои входные данные в выходные, а также выявить отношения между
этими процессами.
Здесь источники информации (внешние сущности) порождают информационные
потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те,
в свою очередь, преобразуют информацию и порождают новые потоки, которые
переносят информацию к другим процессам или подсистемам, накопителям данных или
внешним сущностям – потребителям информации.
При создании диаграммы потоков данных используются четыре основных
понятия:
− потоки данных,
− процессы (работы) преобразования входных потоков данных в выходные,
− внешние сущности,
− накопители данных (хранилища).

SADT создавалось как средство моделирования систем в целом, а DFD как

средство проектирования ИС, поэтому DFD более перспективно для использования, тем
более DFD согласовано с ERD, поскольку в DFD присутствует описание структур
данных, непосредственно используемое для построения ERD.
Моделирование данных необходимо для обеспечения разработчика
концептуальной схемой базы данных в форме одной модели или нескольких локальных
моделей, которые относительно легко могут быть отображены в любую систему баз
данных.
Наиболее распространенным средством моделирования данных являются
диаграммы «сущность-связь» (ERD).
Базовыми понятиями ERD являются: сущности, их свойства (атрибуты) и
отношения друг с другом (связи). Кроме того, ERD связываются с такими понятиями
как: мощность и тип связи, первичный и внешние ключи, индексы, нормализация
диаграммы и т.д.
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов
(людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами
или характеристиками. Любой объект системы может быть представлен только одной
сущностью, которая должна быть уникально идентифицирована. При этом имя
сущности должно отражать тип или класс объекта, а не его конкретный экземпляр
(например, АЭРОПОРТ, а не ВНУКОВО).
Каждая сущность должна
− обладать уникальным идентификатором.
− иметь уникальное имя; к одному и тому же имени должна всегда применяться
одна и та же интерпретация; одна и та же интерпретация не может применяться к
различным именам, если только они не являются псевдонимами;
− иметь один или несколько атрибутов, которые либо принадлежат сущности,
либо наследуются через связь;
− иметь один или несколько атрибутов, которые однозначно идентифицируют
каждый экземпляр сущности.

26
 − Каждая сущность может обладать любым количеством связей с другими
сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями,
значимая для рассматриваемой предметной области. Связь — это ассоциация между
сущностями, при которой каждый экземпляр одной сущности ассоциирован с
произвольным (в том числе нулевым) количеством экземпляров второй сущности, и
наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для
рассматриваемой предметной области и предназначенная для квалификации,
идентификации, классификации, количественной характеристики или выражения
состояния сущности. Атрибут представляет тип характеристик или свойств,
ассоциированных с множеством реальных или абстрактных объектов (людей, мест,
событий, состояний, идей, предметов и т.д.).
Экземпляр атрибута — это определенная характеристика отдельного элемента
множества. Экземпляр атрибута определяется типом характеристики и ее значением,
называемым значением атрибута.
На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными
сущностями. Таким образом, экземпляр сущности должен обладать единственным
определенным значением для ассоциированного атрибута.

27
 Лекция 12
Методы анализа и проектирования программного обеспечения (ч.2)

Объектно-ориентированная методология
Объектный подход к разработке систем следует итеративному процессу с
наращиванием возможностей. Единая модель конкретизируется на этапах анализа,
проектирования и реализации – в результате успешных итераций добавляются новые
детали, при необходимости вводятся изменения и усовершенствования.

Объектно-ориентированный подход обладает следующими преимуществам:

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

К недостаткам объектно-ориентированного подхода относятся:

− высокие начальные затраты. Этот подход не дает немедленной отдачи.
Эффект от его применения сказывается после разработки двух-трех проектов и
накопления повторно используемых компонентов.
− Сложно осуществлять управление проектом. Менеджеры измеряют
степень продвижения разработки, с помощью четко определенной декомпозиции
работ, элементов комплекта поставки и ключевых этапов. При объектной разработке с
помощью «детализации» не существует четких границ между этапами, а проектная
документация непрерывно развивается. Приемлемое решение в такой ситуации лежит
в делении проекта на небольшие модули и управлении ходом разработки за счет
частого выпуска выполняемых версий этих модулей (некоторые из этих выпусков
могут быть для внутреннего применения, а другие – поставляться заказчику).
− Возрастающая сложностью решения, что, в свою очередь, сказывается на
таких характеристиках ПО, как приспособленность к сопровождению и
масштабируемость.

Концептуальной основой объектно-ориентированного подхода является

объектная модель, которая строится с учетом следующих принципов:
Абстрагирование – это выделение наиболее важных, существенных
характеристик некоторого объекта, которые отличают его от всех других видов
объектов и, таким образом, четко определяют его концептуальные границы с точки
зрения дальнейшего рассмотрения и анализа, и игнорирование менее важных или
незначительных деталей.
Инкапсуляция – физическая локализация свойств и поведения в рамках
единственной абстракции (рассматриваемой как «черный ящик»), скрывающая их
реализацию за общедоступным интерфейсом.

1
 Модульность – это свойство системы, связанное с возможностью ее
декомпозиции на ряд внутренне сильно сцепленных, но слабо связанных между собой
подсистем (модулей).
Иерархия – это ранжированная или упорядоченная система абстракций,
расположение их по уровням.

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

объект и класс.
Объект – предмет или явление, имеющее четко определенное поведение и
обладающие состоянием, поведением и индивидуальностью. Структура и поведение
схожих объектов определяют общий для них класс.
Класс – это множество объектов, связанных общностью структуры и поведения.
Следующую группу важных понятий объектного подхода составляют
наследование и полиморфизм.
Понятие полиморфизм может быть интерпретировано как способность класса
принадлежать более чем одному типу.
Наследование означает построение новых классов на основе существующих с
возможностью добавления или переопределения данных и методов. Объекты одного
класса имеют одинаковые операции и атрибуты, но значения их атрибутов могут быть
разными.
Состояние объекта определяется значениями его атрибутов; поведение – его
операциями. При вызове операций, которые могут изменить значение атрибутов
объекта, возможен переход объекта из одного состояния к другому. Для
осуществления функций системы между объектами устанавливаются связи, по
которым они обмениваются сообщениями.

Унифицированный язык моделирования (UML)

Унифицированный язык моделирования UML является методологией объектно-
ориентированного подхода, представляющей набор диаграмм для проектирования
информационных систем.
UML — язык графического описания для объектного моделирования в области
разработки программного обеспечения, моделирования бизнес-процессов, системного
проектирования и отображения организационных структур.
UML позволяет также разработчикам программного обеспечения достигнуть
соглашения в графических обозначениях для представления общих понятий (таких как
класс, компонент, обобщение, агрегация и поведение) и больше сконцентрироваться
на проектировании и архитектуре.
Язык моделирования UML предоставляет своему пользователю большое
количество предопределённых разновидностей диаграмм. Как правило, тип каждой
диаграммы определяется большинством элементов, которые она отображает. Однако,
ничто не мешает проектировщику определить и свой собственный вид диаграммы
исходя из требований данной конкретной задачи.
Для диаграмм языка UML существуют три типа визуальных обозначений,
которые важны с точки зрения заключенной в них информации:
 связи, которые представляются различными линиями на плоскости;
 текст, содержащийся внутри границ отдельных геометрических фигур;

2
  графические символы, изображаемые вблизи визуальных элементов
диаграмм.

При графическом изображении диаграмм рекомендуется придерживаться

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

Сущности в UML
В UML определены четыре типа сущностей: структурные, поведенческие,
группирующие и аннотационные. Сущности являются основными объектно-
ориентированными элементами языка, с помощью которых создаются модели.
Структурные сущности - это имена существительные в моделях на языке UML.
Как правило, они представляют статические части модели, соответствующие
концептуальным или физическим элементам системы. Примерами структурных
сущностей являются "класс", "интерфейс", "кооперация", "прецедент", "компонент",
"узел", "актер".
Поведенческие сущности являются динамическими составляющими модели
UML. Это глаголы, которые описывают поведение модели во времени и в
пространстве. Существует два основных типа поведенческих сущностей:
 взаимодействие - это поведение, суть которого заключается в обмене
сообщениями между объектами в рамках конкретного контекста для достижения
определенной цели;
 автомат - алгоритм поведения, определяющий последовательность состояний,
через которые объект или взаимодействие проходят в ответ на различные события.
Группирующие сущности являются организующими частями модели UML. Это
блоки, на которые можно разложить модель. Такая первичная сущность имеется в
единственном экземпляре - это пакет.
Пакеты представляют собой универсальный механизм организации элементов в
группы. В пакет можно поместить структурные, поведенческие и другие
группирующие сущности. В отличие от компонентов, которые реально существуют во
время работы программы, пакеты носят чисто концептуальный характер, то есть
существуют только в процессе разработки.
Аннотационные сущности - это пояснительные части модели UML:
комментарии для дополнительного описания, разъяснения или замечания к любому
элементу модели. Имеется только один базовый тип аннотационных элементов -

3
примечание. Примечание используют, чтобы снабдить диаграммы комментариями или
ограничениями, выраженными в виде неформального или формального текста.
Отношения в UML
В языке UML определены следующие типы отношений: зависимость,
ассоциация, обобщение и реализация. Эти отношения являются основными
связующими конструкциями UML и также как сущности применяются для построения
моделей.
Зависимость (dependency) - это семантическое отношение между двумя
сущностями, при котором изменение одной из них, независимой, может повлиять на
семантику другой, зависимой.
Ассоциация (association) - структурное отношение, описывающее совокупность
смысловых или логических связей между объектами.
Обобщение (generalization) - это отношение, при котором объект
специализированного элемента (потомок) может быть подставлен вместо объекта
обобщенного элемента (предка). При этом, в соответствии с принципами объектно-
ориентированного программирования, потомок (child) наследует структуру и
поведение своего предка (parent).
Реализация (realization) является семантическим отношением между
классификаторами, при котором один классификатор определяет обязательство, а
другой гарантирует его выполнение. Отношение реализации встречаются в двух
случаях:
 между интерфейсами и реализующими их классами или компонентами;
 между прецедентами и реализующими их кооперациями.

Наименование Обозначение Определение (семантика)

Отношение, описывающее значимую связь между
Ассоциация
двумя и более сущностями. Наиболее общий вид
(association)
отношения
Подвид ассоциации, описывающей связь "часть"–
"целое", в котором "часть" может существовать
Агрегация
отдельно от "целого". Ромб указывается со стороны
(aggregation)
"целого". Отношение указывается только между
сущностями одного типа
Подвид агрегации, в которой "части" не могут
Композиция существовать отдельно от "целого". Как правило,
(composition) "части" создаются и уничтожаются одновременно с
"целым"
Отношение между двумя сущностями, в котором
изменение в одной сущности (независимой) может
Зависимость
влиять на состояние или поведение другой сущности
(dependency)
(зависимой). Со стороны стрелки указывается
независимая сущность
Отношение между обобщенной сущностью
Обобщение
(предком, родителем) и специализированной
(generalization)
сущностью (потомком, дочкой). Треугольник
4
 указывается со стороны родителя. Отношение
указывается только между сущностями одного типа
Отношение между сущностями, где одна сущность
определяет действие, которое другая сущность
обязуется выполнить. Отношения используются в
Реализация двух случаях: между интерфейсами и классами (или
(realization) компонентами), между вариантами использования и
кооперациями. Со стороны стрелки указывается
сущность, определяющее действие (интерфейс или
вариант использования)

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

соответствующими элементами со стрелкой на одном из ее концов, при этом стрелка
направлена от класса-клиента зависимости к независимому классу или классу-
источнику.

Над стрелкой могут находится специальные ключевые слова (стереотипы):

"access" – служит для обозначения доступности открытых атрибутов и операций
класса-источника для классов-клиентов;
"bind" – класс-клиент может использовать некоторый шаблон для своей
последующей параметризации;
"derive" – атрибуты класса-клиента могут быть вычислены по атрибутам класса-
источника;
"import" – открытые атрибуты и операции класса-источника становятся частью
класса-клиента, как если бы они были объявлены непосредственно в нем;
"refine" – указывает, что класс-клиент служит уточнением класса-источника в
силу причин исторического характера, когда появляется дополнительная информация
в ходе работы над проектом.

Отношение ассоциации обозначается сплошной линией с дополнительными

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

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

Отношение композиции является частным случаем отношения агрегации. Это

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

Для ассоциации, агрегации и композиции может указываться кратность (англ.

multiplicity), характеризующая общее количество экземпляров сущностей,
участвующих в отношении. Она, как правило, указывается с каждой стороны
отношения около соответствующей сущности. Кратность может указываться
следующими способами:
- * – любое количество экземпляров, в том числе и ни одного;
- целое неотрицательное число – кратность строго фиксирована и равна
указанному числу (например: 1, 2 или 5);
- диапазон целых неотрицательных чисел "первое число .. второе число"
(например: 1..5, 2..10 или 0..5);
6
 - диапазон чисел от конкретного начального значения до произвольного
конечного "первое число .. *" (например: 1..*, 5..* или 0..*);
- перечисление целых неотрицательных чисел и диапазонов через запятую
(например: 1, 3..5, 10, 15..*).
Если кратность не указана, то принимается ее значение, равное 1.

Отношение обобщения является отношением между более общим элементом

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

Кратность экземпляров сущностей, участвующих в зависимости, обобщении и

реализации, всегда принимается равной 1.
Общие механизмы UML
Для точного описания системы в UML используются, так называемые, общие
механизмы:
 спецификации (specifications);
 дополнения (adornments);
 деления (common divisions);
 расширения (extensibility mechanisms).

a) стандартное обозначение б) стандартное обозначение с в) графический

текстовым стереотипом стереотип

UML является не только графическим языком. За каждым графическим

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

7
класса, отражающее совершенно иные его аспекты, но, тем не менее, соответствующее
спецификации. Таким образом, графическая нотация UML используются для
визуализации системы, а с помощью спецификаций описывают ее детали.
Практически каждый элемент UML имеет уникальное графическое изображение,
которое дает визуальное представление самых важных его характеристик. Нотация
сущности "класс" содержит его имя, атрибуты и операции. Спецификация класса
может содержать и другие детали, например, видимость атрибутов и операций,
комментарии или указание на то, что класс является абстрактным. Многие из этих
деталей можно визуализировать в виде графических или текстовых дополнений к
стандартному прямоугольнику, который изображает класс.
При моделировании объектно-ориентированных систем существует
определенное деление представляемых сущностей.
Во-первых, существует деление на классы и объекты. Класс − это абстракция, а
объект − конкретное воплощение этой абстракции. В связи с этим, практически все
конструкции языка характеризуются двойственностью "класс/объект". Так, имеются
прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы
и экземпляры узлов. В графическом представлении для объекта принято использовать
тот же символ, что и для класса, а название подчеркивать.
Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс
декларирует обязательства, а реализация представляет конкретное воплощение этих
обязательств и обеспечивает точное следование объявленной семантике. В связи с
этим, почти все конструкции UML характеризуются двойственностью
"интерфейс/реализация". Например, прецеденты реализуются кооперациями, а
операции - методами.
UML является открытым языком, то есть допускает контролируемые
расширения, чтобы отразить особенности моделей предметных областей.

В общем случае, механизм расширения представляет собой строку текста,

заключенную в скобки или кавычки
Помимо стереотипов, указываемых в виде строки текста в кавычках, на
диаграммах могут использоваться графические стереотипы. На следующем рисунке
приведены примеры стандартного и стереотипного отображения класса-сущности
Механизмы расширения UML включают:
 стереотипы (stereotype) - расширяют словарь UML, позволяя на основе
существующих элементов языка создавать новые, ориентированные для решения
конкретной проблемы;
 помеченные значения (tagged value) - расширяют свойства основных
конструкций UML, позволяя включать дополнительную информацию в спецификацию
элемента;
 ограничения (constraints) - расширяют семантику конструкций UML,
позволяя создавать новые и отменять существующие правила.
Совместно эти три механизма расширения языка позволяют модифицировать его
в соответствии с потребностями проекта или особенностями технологии разработки.

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

примитивов: пиктограммы, маршруты, двумерные символы и строки. Каждая
диаграмма может быть представлена в виде рамки с графическим содержимым.

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

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

Структурные диаграммы:
Диаграмма классов
Диаграмма компонентов
Диаграмма композитной/составной структуры
Диаграмма кооперации (UML2.0)
Диаграмма развёртывания
Диаграмма объектов
Диаграмма пакетов
Диаграмма профилей (UML2.2)

Диаграммы поведения:
Диаграмма деятельности
Диаграмма состояний
Диаграмма вариантов использования
9
 Диаграммы взаимодействия:
Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
Диаграмма обзора взаимодействия (UML2.0)
Диаграмма последовательности
Диаграмма синхронизации (UML2.0)

Диаграмма классов.
Диаграмма классов является ключевым элементом в объектно-ориентированном
моделировании.
Это статическая структурная диаграмма, описывающая структуру системы,
демонстрирующая классы системы, их атрибуты, методы и зависимости между
классами.
Существуют разные точки зрения на построение диаграмм классов в
зависимости от целей их применения:
концептуальная точка зрения — диаграмма классов описывает модель
предметной области, в ней присутствуют только классы прикладных объектов;
точка зрения спецификации — диаграмма классов применяется при
проектировании информационных систем;
точка зрения реализации — диаграмма классов содержит классы, используемые
непосредственно в программном коде (при использовании объектно-ориентированных
языков программирования).
На диаграмме классы представлены в рамках, содержащих три компонента:
В верхней части написано имя класса. Имя класса выравнивается по центру и
пишется полужирным шрифтом. Имена классов начинаются с заглавной буквы. Если
класс абстрактный — то его имя пишется полужирным курсивом.
Посередине располагаются поля (атрибуты) класса. Они выровнены по левому
краю и начинаются с маленькой буквы.
Нижняя часть содержит методы класса. Они также выровнены по левому краю и
пишутся с маленькой буквы.

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

Диаграмма компонентов (Component diagram) — статическая структурная

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

12
 Диаграмма композитной/составной структуры (Composite structure diagram)
— статическая структурная диаграмма, демонстрирует внутреннюю структуру классов
и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Диаграммы композитной структуры могут использоваться совместно с
диаграммами классов.

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

(Collaboration diagram, введены в UML 2.0), которые показывают роли и
взаимодействие классов в рамках кооперации. Кооперации удобны при
моделировании шаблонов проектирования.
.

13
 Диаграмма развёртывания (Deployment diagram, диаграмма размещения) —
служит для моделирования работающих узлов (аппаратных средств, англ. node) и
артефактов, развёрнутых на них. В UML2 на узлах разворачиваются артефакты (англ.
artifact), в то время как в UML1 на узлах разворачивались компоненты. Между
артефактом и логическим элементом (компонентом), который он реализует,
устанавливается зависимость.

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный

снимок моделируемой системы в заданный момент времени. На диаграмме объектов
отображаются экземпляры классов (объекты) системы с указанием текущих значений
их атрибутов и связей между объектами.

14
 Диаграмма пакетов (Package diagram) — структурная диаграмма, основным
содержанием которой являются пакеты и отношения между ними. Диаграммы пакетов
служат, в первую очередь, для организации элементов в группы по какому-либо
признаку с целью упрощения структуры и организации работы с моделью системы.

Пакет Client содержит два пакета - ClientGUI, в котором находится описание

пользовательского интерфейса, и ClientNetwork, отвечающий за сетевое
взаимодействие с сервером. При этом первый пакет зависит от второго.
Пакет Server содержит все проекты приложения, которые реализуют работу
сервера. ServerBusinessLogic содержит весь код, реализующий бизнес-логику сервера,
ServerNetwork реализует сетевое сообщение с клиентом, RequestDB − примитивы
доступа и логику работы с базой данных запросов. Пакет Util является служебным
пакетом где находятся все вспомогательные типы данных, классы, операции и т.д.,
которые используются всеми пакетами сервера.

Диаграмма профилей описывает механизм расширения, позволяющий

приспособить UML к разнообразным предметным областям и сферам деятельности.

Диаграмма деятельности (Activity diagram) — диаграмма, на которой

показано разложение некоторой деятельности на её составные части.
Под деятельностью (англ. activity) понимается спецификация исполняемого
поведения в виде координированного последовательного и параллельного выполнения
подчинённых элементов — вложенных видов деятельности и отдельных действий,
соединённых между собой потоками, которые идут от выходов одного узла к входам
другого.
Диаграммы деятельности
используются при моделировании
бизнес-процессов, технологических
процессов, последовательных и
параллельных вычислений.

Диаграмма автомата
(состояний) (State Machine diagram,
диаграмма конечного автомата,
диаграмма состояний) — диаграмма, на
которой представлен конечный автомат
с простыми состояниями, переходами и
композитными состояниями.

15
 Конечный автомат (англ. State machine) — спецификация последовательности
состояний, через которые проходит объект или взаимодействие в ответ на события
своей жизни, а также ответные действия объекта на эти события. Конечный автомат
прикреплён к исходному элементу (классу, кооперации или методу) и служит для
определения поведения его экземпляров.

Диаграмма последовательности − диаграмма, на которой для некоторого

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

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

Для построения диаграммы последовательности необходимо:

− идентифицировать каждое действующее лицо (объект) и изобразить для него
линию жизни. Крайним слева на диаграмме изображается объект, который является
инициатором взаимодействия. Правее изображается другой объект, который
непосредственно взаимодействует с первым, и т. д.;
− из описания варианта использования определить множество системных
сообщений и их последовательность;
− изображают системные сообщения в виде линий со стрелкой на конце между
линиями жизни действующих лиц и системы. Затем указывают имена сообщений и
списки передаваемых значений.
На диаграмме последовательности изображаются только те объекты, которые
непосредственно участвуют во взаимодействии, и не указываются возможные
статические ассоциации с другими объектами.

Линия жизни объекта (object lifeline) служит для обозначения периода

времени, в течение которого объект существует в системе и, следовательно, может
потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни
изображается пунктирной вертикальной линией, ассоциированной с единственным
объектом. Если объект существует в системе постоянно, то и его линия жизни должна
продолжаться по всей плоскости диаграммы последовательности от самой верхней ее
части до самой нижней.
Если объекты разрушаются в какой-то момент для освобождения ресурсов
системы, то их линия жизни обрывается в момент уничтожения. Для обозначения
такого момента используется специальный символ в форме латинской буквы «X».
Объекты на диаграмме последовательности могут находиться в двух состояниях,
активном — непосредственно выполняя какие-либо действия, и пассивном, ожидая
сообщения от других объектов. Чтобы явно выделить подобную активность объектов,
применяется фокус управления (focus of control). Фокус управления изображается в
17
форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает
начало получения фокуса управления объекта (начало активности), а ее нижняя
сторона – окончание фокуса управления (окончание активности).
Каждое взаимодействие между объектами описывается совокупностью
сообщений, которыми объекты обмениваются между собой или операций, которые
объекты вызывают для выполнения определенных действий. Сообщение (message)
представляет собой законченный фрагмент информации, который отправляется одним
объектом другому. Объект, принявший сообщение, должен отреагировать на него
какой-либо последовательностью действий, направленных на решение поставленной
задачи. Порядок сообщений указывается в вертикальном направлении.

Тип сообщения отражается с

помощью разнообразных стрелок:
Simple (1) — простая посылка
сообщения;
Synchronous (2) — операция
происходит только в том случае, когда
клиент посылает сообщение, а сервер
может принять сообщение клиента;
Самоделегирование (3) —
распространенное явление в ООП,
например, когда объект вызывает свой
собственный (как правило, защищенный)
метод;
Balking (4) — операция происходит
только в том случае, когда сервер готов
немедленно принять сообщение, если
сервер не готов к приему, клиент не
выдает сообщение;
Timeout (5) — клиент отказывается
от выдачи сообщения, если сервер в
течение определенного времени не может
его принять;
Procedure Call (6) — клиент
вызывает процедуру сервера и полностью
передает ему управление;
Asynchronous (7) — клиент выдает
сообщение, и, не ожидая ответа сервера,
продолжает выполнение своего программного кода;
Return (8) — определяет, что происходит возврат из процедуры;

Частота посылки сообщений может иметь два варианта:

Periodic – сообщения поступают от клиента с заданной периодичностью;
Aperiodic – сообщения поступают от клиента нерегулярно.

Диаграмма коммуникации / диаграмма кооперации описывает организацию

объектов, участвующих во взаимодействии

18
 На рисунке изображается, как выглядит ситуация поступления в систему
звонка от клиента. Эта диаграмма может быть полезной в случае, если нужно
определить, как информация о звонке распространяется через компоненты ПО, какие
процессы при этом происходят в его различных частях и какие данные передаются.
Звонок от клиента приходит на офисную АТС, оттуда уходит на телефонный
аппарат свободного оператора и на сервер. От сервера через локальную сеть этот
звонок приходит на клиентское ПО того же оператора.
Из этой диаграммы становится понятно, что PBX (телефонная система
частного пользования, Офисная АТС) должен передавать серверу вместе с
информацией о звонке еще также информацию и об операторе, с которым он
прокоммутировал этого клиента. Ведь сервер должен послать информацию о новом
звонке на клиентское ПО именно этого оператора. Получая информацию о звонке,
клиентское ПО автоматически открывает оператору специальный диалог, в
который тот вводит информацию о звонке прямо во время разговора с клиентом.
Еще один важный момент, который следует из этой диаграммы: телефонный звонок
на аппарате оператора должен прозвенеть одновременно (или почти одновременно) с
появлением на его мониторе диалогового окна для внесения информации о звонке.
На диаграммах коммуникаций изображается взаимодействие ролей классов,
компонент, а не конкретные экземпляры. Роль – более общее понятие, чем объект
(экземпляр), и является гнездом, куда могут быть вставлены различные объекты. В
синтаксисе UML имена ролей обозначаются без подчеркивания, а имена экземпляров –
с подчеркиванием.
Диаграммы коммуникаций могут использоваться для пояснения кооперации,
композитной компоненты или другого композитного объекта. Поэтому в ней и
используются роли, а не объекты. Имя этого композитного объекта указывается в
заголовке диаграммы. Там же, в заголовке, используется тег comm для обозначения
диаграммы коммуникаций.

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

Диаграмма обзора взаимодействия (англ. interaction overview diagram) —

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

20
 Диаграмма синхронизации (Timing diagram) — альтернативное представление
диаграммы последовательности, явным образом показывающее изменения состояния
на линии жизни с заданной шкалой времени. Может быть полезна в приложениях
реального времени.

Элементами диаграммы являются:

– линия жизни;

– множество состояний объекта;

– ограничения интервала времени (относительного);

– ограничения времени (абсолютного);

– точка уничтожения

21
 Диаграмма вариантов использования (Use case diagram, диаграмма
прецедентов) — диаграмма, на которой отражены отношения, существующие между
актёрами и вариантами использования.
Основная задача — представлять собой единое средство, дающее возможность
заказчику, конечному пользователю и разработчику совместно обсуждать
функциональность и поведение системы.

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

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

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

которым указано его имя:

Помните, что акторами могут быть не только люди, но и неодушевленные

предметы, например, сканер штрих-кода или датчик охранной сигнализации.
Прецедент изображается в виде эллипса, в котором содержится имя прецедента:

22
 Как вариант возможно расположение надписи под эллипсом; это может
оказаться полезным в случае длинного имени прецедента.
На диаграмме прецеденты обычно располагаются в середине листа, а акторы —
слева. В случае, если прецедент активирует один актор, а результат выполнения
достается другому, актор-получатель располагается справа:

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

(иногда вместо линий применяются стрелки, направленные от актора к прецеденту, но
на мой взгляд это не совсем корректно, поскольку связи актор-прецедент в
большинстве случаев двунаправленные).
В приведенном примере Actor1 инициирует прецеденты UseCase1 и UseCase2, и
он же получает их результат. Actor2 инициирует прецеденты UseCase3, UseCase4 и
UseCase5, однако результат выполнения UseCase5 получает Actor3.

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

23
устойчивости) эти описания сменит наглядная и непротиворечивая графическая
диаграмма.
Например, сценарий публикации статьи мог бы выглядеть примерно таким
образом:
− Заполнить сведения об авторе.
− Заполнить аннотацию.
− Скопировать текст статьи в соответствующее окно.
− Выполнить предварительный просмотр статьи.
− Подтвердить публикацию.
Несмотря на кажущуюся простоту, картина усложняется за счет того, что
сценарий помимо основного потока событий, который характеризует нормальное
поведение системы, зачастую включает один или несколько альтернативных потоков,
описывающих нетипичные случаи.
Например, в предыдущем примере во время предварительного просмотра
публикации автор может обнаружить, что статья выглядит не так, как он задумывал,
или содержит ошибки, которые следует исправить. В этом случае следует ожидать, что
он не будет подтверждать публикацию статьи, а либо перейдет к ее редактированию,
либо прекратит сеанс публикации вовсе, решив внести исправления автономно в свою
рабочую копию. Подобные возможности следует также не забыть включить в
прецедент, описав каждый альтернативный поток максимально кратко.

Структурирование модели прецедентов

Таким образом, прецеденты можно уподобить подпрограммам, на которые
разделяется объемная программа. Однако структура достаточно сложной программы
редко бывает плоской, однородной. Обычно главная программа содержит вызов
нескольких подпрограмм, те в свою очередь вызывают подпрограммы второго уровня
и т.д.
Аналогичным образом и прецеденты могут образовывать иерархическую
структуру. Однако в отличие от подпрограмм, которые обычно образуют простое
отношение типа "А вызывает В", отношения между прецедентами несколько сложнее
и разбиваются на 3 категории: включение, расширение и обобщение.

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

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

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

На данной диаграмме прецедент "Edit article" расширяет прецедент "Publish

article". Смысл этой конструкции заключается в следующем: при определенном
условии, не отраженном на данной диаграмме (а именно — автор недоволен
содержимым статьи и не намерен выставлять ее на общее обозрение), процесс
публикации приостанавливается, и автор производит редактирование.

Обобщение
Если включение прецедента можно уподобить вызову подпрограммы, то
обобщение скорее напоминает наследование объектов: производные прецеденты могут
наследовать поведение базовых, при этом при необходимости уточняя либо
переопределяя их поведение.

Данная диаграмма сообщает нам, что поиск может осуществляться в двух

вариантах: по автору либо по ключевым словам в теле сообщения. При этом оба
прецедента являются вариантами базового прецедента "Search".

25
 Диаграммы прецедентов определяют зачем (или с какой целью) актеры
взаимодействуют с системой. Для того, чтобы ответить не только на вопрос «Зачем
происходит взаимодействие с системой? Но и как происходит взаимодействие?»
необходимо будет обратиться к диаграммам коммуникации и последовательности
(sequence и collaboration) и деятельности (activity).

Взаимодействие актеров с системой в целом или взаимодействие отдельных

модулей (классов) системы между собой происходит посредством обмена
сообщениями (или запросами). Для моделирования такого взаимодействия UML
включает в свой состав диаграммы последовательности действий (Sequence Diagram) и
диаграммы коммуникации (Collaboration Diagram), которые позволяют с разных точек
зрения рассмотреть взаимодействие объектов в создаваемой системе.

Персоны (персонажи) пользователей при разработке ПО

Персоны или персонажи пользователей являются одним из инструментов
дизайна продукта или услуги, ориентированного на пользователя (user-centered design),
который основывается на идее, что создавать продукты нужно «вокруг» людей и их
целей, а не обучать людей тому, как использовать продукты и не делать «дизайн для
всех». Ключевая задача в данном случае – это понять, что нужно пользователю через
его поведение, отношение, потребности и цели, проявляя эмпатию и дизайн-
мышление.

26
 Персона (персонаж) — это обобщенное, но реалистичное описание типичного
или целевого пользователя продукта, то есть архетип, а не реальный живой человек, но
персонажи должны описываться так, как если бы они были настоящими людьми.
Персонаж не должен документировать каждый аспект жизни воображаемого человека,
а должен фокусироваться на тех характеристиках, которые влияют на то, что
разрабатывается.
Персонажи нужны для того, чтобы приблизиться к реальному клиенту и не
забывать его при разработке продукта.
Создавать персонажей стоит «Как можно раньше». В идеале процесс создания
персоны должен быть частью фазы продуктового исследования, прежде чем начнется
фактический процесс проектирования и разработки. Поведение каждого
вымышленного пользователя должно быть основано на фактических агрегированных
данных, полученных на основании поведения реальных пользователей.
Создание персонажа лучше всего делать в команде: не потому, что это сложно, а
потому, что он получит больше поддержки для дальнейшего использования. Чтобы
инициировать процесс создания персоны, стоит начать с определения характеристик
пользователей, наблюдаемых в пользовательских исследованиях. Далее следует
сгруппировать эти характеристики в кластеры. Если несколько кластеров кажутся
слишком похожими, объединить их вместе или устранить любые атрибуты, которые
кажутся менее важными для бизнеса. После появления отдельных кластеров добавить
детали, чтобы сделать персонажа более реалистичным, правдоподобным и
запоминающимся.
Для этого необходимо указать следующую информацию о персонаже:
– Имя, возраст, пол и фотографию
– Ключевые слова, описывающие, что он делает в «реальной жизни»
– Уровень опыта в области использования вашего продукта или продуктов
конкурентов
– Контекст того, как они будут взаимодействовать с вашим продуктом
– Как часто они будут использовать его
– Цели и проблемы, для решения которых будут использовать ваш продукт
– Цитаты для подведения итогов

27
 Ваша цель должна заключаться в создании правдоподобного и живого
персонажа. Стоит избегать добавления посторонних деталей, которые не имеют каких-
либо последствий для дизайна. Хотя имя и фотография могут показаться
неактуальными, их функция заключается в том, чтобы помочь запоминанию, что
является № 1 задачей персоны: чтобы все члены команды помнили пользователей, для
которых они создают продукт.

28
 Лекция 13
Проектирование графического пользовательского интерфейса (ч.1)

Опыт взаимодействия (user experience)

Опыт пользователя, опыт взаимодействия (User eXperience, UX) — это
восприятие и ответные действия пользователя, возникающие в результате
использования и/или предстоящего использования продукции, системы или услуги.
Опыт пользователя включает все эмоции, убеждения, предпочтения, ощущения,
физические и психологические реакции пользователя, поведение и достижения,
которые возникают до, во время и после использования системы. Опыт пользователя
сочетает образ торговой марки, способ представления, функциональность,
производительность системы, интерактивное поведение и вспомогательные
возможности интерактивной системы, физическое и психологическое состояние
пользователя, являющееся результатом предшествующего опыта, привычек, навыков и
индивидуальности.
Все объекты вокруг нас имеют опыт взаимодействия – от тач-скрин киосков до
элитных кофе-машин, которые позволяют налить себе чашечку кофе. Возможность
использовать мобильный телефон или любой другой девайс на ходу улучшает UX,
также как взаимодействие с автомобилем с помощью тач-скрина и голосовых команд
делает управление автомобилем проще и удобнее.
Опыт взаимодействия в информационных технологиях
Данный термин широко применяется в информационных технологиях (ИТ) для
описания субъективного отношения, возникающего у пользователя в процессе
использования как информационной системы в целом, так и отдельной её части (веб-
сайта, приложения и пр.). Опыт пользователя, в том числе, связан с таким понятием
как юзабилити, применяемым при разработке и анализе пользовательских
интерфейсов приложений.
В целом, UX дизайн подразумевает комплексный подход к взаимодействию
пользователя с интерфейсом, будь-то веб-сайт, мобильное приложение или любая
другая программа. Человек, который занимается этой работой – UX-дизайнер (в
последнее время все чаще можно услышать названия UX-архитектора, UX-инженера
или стратега, так как слово «дизайн» в данном контексте скорее нарицательное, чем
то, что мы на самом деле привыкли понимать под значением этого слова) – при
разработке интерфейса должен по возможности максимально учесть все мелочи,
начиная от среды пользователя и типа электронного устройства и заканчивая
способами ввода и отображения информации.
Пример. Допустим, вы вложили внушительную сумму денег, чтобы продвинуть
ваш ресурс на первые строчки поисковых систем, однако его удобство оставляет
желать лучшего. В таком случае внушительное количество пользователей просто
уйдет с сайта и эффект от этого будет минимальным. Именно поэтому необходимо
проводить постоянный анализ действий посетителей ресурса, совершенствовать свой
сайт и следить за современными тенденциями.

1
 Основные вопросы, решаемые UX дизайном
Успех продукта основывается на том, как пользователи его воспримут.
Используя продукт, люди обычно оценивают свой опыт взаимодействия следующим
образом:
 Получил ли я пользу от этого продукта?
 Легко ли его использовать?
 Приятно ли его использовать?

Таким образом основные вопросы, решаемые UX дизайном следующие:

 Постановка целей и задач – чего в итоге нам необходимо достичь?
 Подбор подходящих UX инструментов для реализации целей
 Разработка продукта, максимально удобного и легкого в восприятии целевой
аудиторией
 Анализ конечного результата – соответствует ли продукт ожиданиям
заказчика и насколько высок уровень удовлетворенности пользователей.
Именно грамотная продуманность всех деталей на этих этапах позволит создать
армию поклонников вашего продукта. Ярким примером здесь является компания
Apple, которая пошла по такому пути и завоевала сердца тысяч и миллионов.
Некоторые дизайнеры считают, что UX — это только про посещение сайта или работа
с приложением. На деле же опыт пользователя этим не ограничивается. Например, если
клиент оставил заявку, но не получил смс с подтверждением или звонок от менеджера, —
это симптомы плохого UX. Если же пользователь легко и без преград сделал заказ, оплатил
сервис или купил товар,— это положительный UX.
UX не заканчивается на красивой и понятной форме на сайте. UX — это путь
пользователя от точки входа до точки выхода, из пункта А в пункт Б.

Компоненты UX-дизайна
Существует пять основных компонентов UX:
 Информационная архитектура (ИА)
 Проектирование взаимодействия
 Юзабилити
 Прототипирование
 Визуальный дизайн

1. Информационная архитектура (ИА)

Информационная архитектура − способ предоставить людям контент, как можно
более понятным и удобным для них образом.
Это ДНК проекта. То, что создаётся, определяет существование проекта и всех
его последующих воплощений на годы вперёд.

Принципы информационной архитектуры

8 принципов IA, которые могут послужить хорошей базой для любого проекта.
1. Принцип объектов. Принцип предписывает рассматривать контент как
развивающуюся сущность, которая имеет собственный жизненный цикл. Разный
контент будет иметь разные атрибуты и поведение, и это нужно учесть при
проектировании дизайна.
2
 2. Принцип выбора. Принцип означает, что вы должны предлагать вашим
пользователям осмысленный выбор. Тем не менее, вы должны убедиться, что выбор
будет сосредоточен на чем-то конкретном: слишком много вариантов может
дезориентировать пользователя. Информацию тоже стоит подавать в виде иерархии,
категорий и суб-категорий, вместо того, чтобы приводить ее просто длинным списком.
3. Принцип раскрытия. Важно дать пользователю необходимую ему
информацию. Однако стоит убедиться, что это действительно то, что ему нужно, а не
то, что вам захотелось дать. Принцип говорит также о том, что нужно сразу давать
пользователю информацию, необходимую для понимания: что он сможет найти на
других страницах сайта, а что нет. Информацию нужно подавать постепенно, от
страницы к странице, а не пытаться вывалить все и сразу.
4. Принцип примеров. Использование принципа существенно улучшает
пользовательский опыт. Например, когда вы заходите в определенную категорию
товаров на Amazon, на сайте выводятся примеры товаров, которые попадают в эту
категорию. Это помогает пользователю быстрее сориентироваться, особенно, если он
не до конца понимает, что значит название категории.
5. Принцип парадного входа. Половина посетителей попадают на ваш сайт
не через главную страницу. Это значит, что любая страница должна содержать
необходимый минимум текстовой информации — чтобы пользователи поняли, где они
находятся. Также это лишний раз подтверждает пункт 3, не нужно пытаться уместить
всю информацию на домашней странице сайта.
6. Принцип множественной классификации. Этот принцип говорит о том,
что разные пользователи используют ваш сайт по-разному, у них могут быть разные
методы для нахождения одной и той же информации. Например, одни будут
пользоваться поиском, другие предпочтут поблуждать по сайту. Контент нужно
адаптировать к различным сценариям пользовательского поведения.
7. Принцип целенаправленной навигации. Не так важно, где находится
меню, важно то, что на нем написано. Постарайтесь, чтобы ваше меню и панель
навигации показывали, где находится пользователь сейчас и куда он может попасть с
текущей страницы.
8. Принцип роста. На подавляющем большинстве сайтов контент —
текучая, изменчивая сущность. Количество контента у вас на сайте сегодня может
быть лишь малой долей того, чтобы там может быть завтра. Организуйте контент
таким образом, чтобы позволять ему расти в будущем. Причем не только в плане
расширения какого-то блока с текстом: контент может добавляться совершенно
разных типов.

2. Проектирование взаимодействия
Проектирование взаимодействия отвечает за определённые взаимодействия
пользователя и экрана монитора. Визуальный дизайн реагирует на действия
пользователя. Данные действия и цели пользователя рассматриваются во время
проектирования взаимодействия, чтобы бренд мог взаимодействовать с пользователем
посредством изображений, графики, шрифтов, определённых цветов, иконок и т.д.
Также проектирование взаимодействия использует прототипирования, для
определения специфичного поведения и функционирует с различными компонентами.
Например, во время дизайна мобильных приложений, для страницы входа будет
применена анимация сворачивания ("ease"), или она будет блекнуть (fade in), или

3
выезжать справа. Данные переходы должны быть изучены во время фазы создания
концепции взаимодействия, чтобы финальный продукт как можно ближе
соответствовал изначальной задумке дизайнера.

3. Юзабилити
Юзабилити заключается в использовании данных для определения валидности
решений дизайна. Роль UX дизайнера понять и воплотить потребности пользователей
и избавить их от любого разочарования во время использования продукта.
Эти данные могут быть получены различными способами − начиная от работы с
фокус-группой для исследования, изучения юзабилити в лаборатории, интервью один
на один, с посетителями сайта, отслеживанием поведения глаз, сортировка карточек,
A/B тестирование, телеметрии и так далее.
Юзабилити-тестирование призвано понять площадь охвата продукта, в то же
время определить поведение и потребности пользователя. На высшем уровне, хорошая
практика − проверить свои гипотезы на настоящих пользователях, проверить
изменения продукта, так чтобы он соответствовал потребностям аудитории.

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

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

С технической точки зрения UX включает практические, эмпирические,

аффективные, значимые и ценные аспекты взаимодействия. Соты Питера Морвилла
(Peter Morville) – это инструмент, который помогает найти правильный баланс между
различными областями эффективного UX.
(Питер Морвилл является президентом Semantic Studios, консалтинговой фирмы
по информационной архитектуре и находчивости. Он известен как влиятельная
фигура и "отец-основатель" информационной архитектуры, став соавтором самой
продаваемой книги в этой дисциплине)

4
  Usable: Продукт должен быть простым и легким в использовании. Он
должен быть разработан так, чтобы быть знакомым и понятным.
 Useful: Продукт должен удовлетворять потребности. Если он этого не
делает, что у пользователя нет причин его использовать.
 Desirable: Визуальная эстетика продукта должна быть привлекательна.
Элементы дизайна могут вызывать позитивные эмоции и симпатию.
 Findable: Если у пользователя возникли проблемы с продуктом, то они
должны быть в состоянии быстро найти решение.
 Accessible: Дизайн продукта должен быть таким, чтобы даже физически
неполноценные люди могли иметь такой же опыт как и все остальные.
 Credible: Компания и ее продукты должны вызывать доверие.
Когда дизайн продукта сочетает в себе эти 6 элементов, тогда он будет ценен для
пользователей, а максимизация ценности – основная цель UX.

Интерфейс
Интерфейс – совокупность технических, программных и методических
(протоколов, правил, соглашений) средств сопряжения в вычислительной системе
пользователей с устройствами и программами, а также устройств с другими
устройствами и программами.
Интерфейс – в широком смысле слова, это способ (стандарт) взаимодействия
между объектами. Интерфейс в техническом смысле слова задаёт параметры,
процедуры и характеристики взаимодействия объектов

Пользовательский интерфейс
Интерфейс пользователя (UI – англ. user interface) – разновидность интерфейсов,
в котором одна сторона представлена человеком (пользователем), другая –
машиной/устройством. Представляет собой совокупность средств и методов, при

5
помощи которых пользователь взаимодействует с различными, чаще всего сложными,
машинами, устройствами и аппаратурой.
Весьма часто термин применяется по отношению к компьютерным программам,
однако под ним может подразумеваться набор средств, методов и правил
взаимодействия любой системы, управляемой человеком.
Несколько широко распространённых примеров:
- меню на экране телевизора + пульт дистанционного управления;
- дисплей электронного аппарата (автомагнитолы, часов) + набор кнопок и
переключателей для настройки;
- приборная панель (автомобиля, самолёта) + рычаги управления.
Интерфейс двунаправленный (интерактивный) – когда устройство, получив
команды от пользователя и исполнив их, выдаёт информацию пользователю
некоторыми средствами – визуальными, звуковыми, тактильными и т.п. (приняв
которую, пользователь выдаёт устройству последующие команды предоставленными в
его распоряжение средствами: кнопки, переключатели, регуляторы, сенсоры, голосом,
и т. д.).
Поскольку интерфейс есть совокупность, то есть он состоит из элементов,
которые, сами по себе, также могут состоять из элементов (так, экран дисплея может
содержать в себе другие окна, которые, в свою очередь, могут содержать панели,
кнопки и прочие интерфейсные элементы).
Особое и отдельное внимание в интерфейсе пользователя традиционно
уделяется его эффективности и удобству пользования (юзабельности). Понятный,
удобный, дружественный – его основные характеристики.

Средства интерфейса:
- вывода информации из устройства к пользователю – весь доступный диапазон
воздействий на организм человека (зрительных, слуховых, тактильных, обонятельных
и т.д.) — экраны (дисплеи, проекторы) и лампочки, динамики, зуммеры и сирены и т.д.
- ввода информации/команд пользователем в устройство – множество
всевозможных устройств для контроля состояния человека – кнопки, переключатели,
потенциометры, датчики положения и движения, сервоприводы, жесты лицом и
руками, даже съём мозговой активности пользователя.
По наличию тех или иных средств ввода, интерфейсы разделяются на типы
жестовый, голосовой, брэйн (Нейрокомпьютерный интерфейс — система, созданная
для обмена информацией между мозгом и электронным устройством), и т.д.,
возможны смешанные варианты.

Методы интерфейса:
- набор правил, заложенных разработчиком устройства, согласно которым
совокупность действий пользователя должна привести к необходимой реакции
устройства и выполнения требуемой задачи – т.н. логический интерфейс. Правила эти
должны быть достаточно ясны для понимания, естественны и легки для запоминания
(всё это входит в понятие юзабилити);
Увеличение в устройстве (при равной функциональности) средств ввода-вывода
даёт упрощение построения методов управления и упрощение правил пользования, но
зато приводит к сложности восприятия информации пользователем – интерфейс
становится перегруженным. И наоборот – уменьшение средств отображения и

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

Типы интерфейсов
Интерфейсы пользователя бывают двух типов:
1) процедурно-ориентированные:
– примитивные
– меню
– со свободной навигацией
2) объектно-ориентированные:
– прямого манипулирования.
Процедурно ориентированный интерфейс использует традиционную модель
взаимодействия с пользователем, основанную на понятиях "процедура" и "операция".
В рамках этой модели программное обеспечение предоставляет пользователю
возможность выполнения некоторых действий, для которых пользователь определяет
соответствие данных и следствием выполнения которых является получение
желаемого результата.

Процедурно-ориентированные интерфейсы:
1) обеспечивают пользователю функции, необходимые для выполнения задач;
2) акцент делается на задачи;
3) пиктограммы представляют приложения, окна или операции;
4) содержание папок и справочников отражается с помощью таблицы-списка.

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

пользователем и используется в консольном режиме. Единственное отклонение от
последовательного процесса, который обеспечивается данными, заключается в
организации цикла для обработки нескольких наборов данных.
Интерфейс Меню. В отличие от примитивного интерфейса, позволяет
пользователю выбирать операцию из специального списка, выводимого ему
программой. Эти интерфейсы предполагают реализацию множества сценариев работы,
последовательность действий в которых определяется пользователями. Древовидная
организация меню предполагает строго ограниченную реализацию.
Интерфейс со свободной навигацией (графический интерфейс). Поддерживает
концепцию интерактивного взаимодействия с ПО, визуальную обратную связь с
пользователем и возможность прямого манипулирования объектом (кнопки,
индикаторы, строки состояния). В отличие от интерфейса Меню, интерфейс со
свободной навигацией обеспечивает возможность осуществления любых допустимых
в конкретном состоянии операций, доступ к которым возможен через различные
интерфейсные компоненты ("горячие" клавиши и т.д.). Интерфейс со свободной

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

Объектно-ориентированный интерфейс предполагает, что взаимодействие с

пользователем осуществляется посредством выбора и перемещения пиктограмм
соответствующей объектно-ориентированной области. Различают однодокументные
(SDI) и многодокументные (MDI) интерфейсы.
Объектно-ориентированные интерфейсы:
1) обеспечивает пользователю возможность взаимодействия с объектами;
2) акцент делается на входные данные и результаты;
3) пиктограммы представляют объекты;
4) папки и справочники являются визуальными контейнерами объектов.
Интерфейсы данного типа на внешнем уровне используют директивную форму
диалога: ввод команды осуществляется при выполнении определенных действий с
пиктограммой объекта мышью. Основными элементами этих интерфейсов являются:
метафоры, объекты, представления объектов и технология DragandDrop («перетащил и
бросил»).
Метафора − мысленный перенос свойств или признаков одного объекта на
другой, чем-то аналогичный первому. Использование метафор в интерфейсах
предполагает активизацию имеющегося у пользователя опыта (ментальных моделей
выполнения аналогичных действий в повседневной жизни или на рабочем месте).
Три основные типа объектов интерфейсов прямого манипулирования:
- объекты-данные,
- объекты контейнеры,
- объекты устройства.
Объекты-данные снабжают пользователя информацией (тексты, изображения,
электронные таблицы, музыка, видео). В рамках операционной системы таким
объектам соответствуют приложения, которые запускаются при раскрытии объекта.
Объекты-контейнеры могут манипулировать своими внутренними объектами, в
том числе и другими контейнерами (копировать их или сортировать в любом порядке).
К типичным контейнерам относятся папки, корзины. При раскрытии контейнера
демонстрируются сохраняемые им компоненты, и появляется возможность ими
манипулировать. Компоненты могут обозначаться пиктограммами или представляться
в виде таблицы.
Объекты-устройства представляют устройства, существующие в реальном
мире: телефоны, факсы, принтеры и т.д. их используют для обозначения этих
устройств в абстрактном мире интерфейса. При раскрытии такого объекта можно
увидеть его настройки.
Каждому объекту соответствует одно окно. В исходном состоянии это окно
представлено пиктограммой, но при необходимости его можно раскрыть и выполнить
требуемые операции, например, настройки объекта. Окно объекта в раскрытом
состоянии может содержать меню и панели инструментов. Пиктограмме же должно
соответствовать контекстное меню, содержащее перечень операций над объектом.
Имя пиктограммы формируют по-своему для каждого типа объектов.
Пиктограммам объектов-данных присваивают имена, соответствующие именам
хранимых данных, а тип данных кодируется самой пиктограммой. Имя пиктограммы

8
контейнера или пиктограммы устройства обозначает сам объект, а потому не зависит
от содержимого.
Различие между типами объектов является условным, так как один и тот же
объект в разных ситуациях может вести себя то, как объект-данные, то, как объект-
устройство, то, как объект-контейнер (принтер – объект-устройство, может обладать
свойствами объекта-контейнера, может содержать объекты-данные в очереди на
печать).
Технология DragandDrop. («перетащил и бросил») − способ оперирования
элементами интерфейса в интерфейсах пользователя (как графическим, так и
текстовым, где элементы GUI реализованы при помощи псевдографики) при помощи
манипулятора «мышь» или сенсорного экрана.
Способ реализуется путём «захвата» (нажатием и удержанием главной (первой,
чаще левой) кнопки мыши) отображаемого на экране компьютера объекта,
программно доступного для подобной операции, и перемещении его в другое место
(для изменения расположения) либо «бросания» его на другой элемент (для вызова
соответствующего, предусмотренного программой, действия). По отношению к окнам
(также способным к перемещению подобным способом) данный термин обычно не
употребляется.
Существует два вида пунктов назначения: один принимает объект, а другой его
копию (Пользователь «бросает» документ в «корзину» – уничтожается сам документ, а
если на принтер, то передается копия документа).
Базовыми действиями и самыми простыми примерами drag-and-drop действий
являются: перемещение объекта, перемещение объекта из панели в панель.

Подтипы пользовательских интерфейсов:

1) Командный интерфейс. Он называется так потому, что в этом виде
интерфейса человек подает "команды" компьютеру, а компьютер их выполняет и
выдает результат человеку. Командный интерфейс реализован в виде пакетной
технологии и технологии командной строки.

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

Технология командной строки

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

2) WIMP-интерфейс (Window − окно, Image − образ, Menu − меню, Pointer −

указатель). Хотя и в этом интерфейсе машине подаются команды, но это делается
"опосредственно", через графические образы. Этот вид интерфейса реализован на двух
уровнях технологий: простой графический интерфейс и "чистый" WIMP интерфейс.

Простой графический интерфейс

Отличительные особенности этого интерфейса:
− Выделение областей экрана.

9
 − Переопределение клавиш клавиатуры в зависимости от контекста.
− Использование манипуляторов и серых клавиш клавиатуры для управления
курсором.

Собственно, WIMP
Этот подтип интерфейса характеризуется следующими особенностями:
− Вся работа с программами, файлами и документами происходит в окнах;
− Все программы, файлы, документы, устройства и другие объекты
представляются в виде значков;
− Все действия с объектами осуществляются с помощью меню;
− Широкое использование манипуляторов для указания на объекты.

3) SILK-интерфейс (Speech − речь, Image − образ, Language − язык, Knowlege −

знание). Компьютер находит для себя команды, анализируя человеческое поведение,
т.е. на экране по речевой команде происходит перемещение от одних поисковых
образов к другим по смысловым семантическим связям.

Речевая технология
При этой технологии команды подаются голосом путем произнесения
специальных зарезервированных слов-команд.

Биометрическая технология
Здесь человек предстаёт как совокупность признаков поведения. Картинка
считывается с цифровой видеокамеры, а затем с помощью специальных программ
распознавания образов из этого изображения выделяются команды.

Семантический интерфейс
Об этой технологии известно крайне мало. Похоже, что она тесно связана с
искусственным интеллектом и сходна со всеми подтипами SILK и другими типами
тоже. Возможно, что в связи с важным военным значением этих разработок эти
направления были засекречены.

4) Графический интерфейс пользователя

Графический пользовательский интерфейс (англ. Graphical user interface, GUI) –
разновидность пользовательского интерфейса, в котором элементы интерфейса (меню,
кнопки, значки, списки и т.п.), представленные пользователю на дисплее, исполнены в
виде графических изображений.
В отличие от интерфейса командной строки, в GUI пользователь имеет
произвольный доступ (с помощью устройств ввода – клавиатуры, мыши, джойстика и
т.п.) ко всем видимым экранным объектам (элементам интерфейса) и осуществляет
непосредственное манипулирование ими. Чаще всего элементы интерфейса в GUI
реализованы на основе метафор и отображают их назначение и свойства, что облегчает
понимание и освоение программ неподготовленными пользователями.

Метафора – перенесение свойств одного предмета (явления) на другой на

основании общего признака («говор волн», «бронза мускулов»).

10
 Метафора в пользовательском интерфейсе – такая организация интерфейса,
при которой обстановка на экране и способы взаимодействия с системой апеллируют к
ситуации, хорошо знакомой пользователю.
Метафора помогает объяснить новое, незнакомое явление через то, что
пользователь уже знает. Самая знаменитая метафора в сфере взаимодействия между
человеком и компьютером и дизайне пользовательского опыта — это «метафора
рабочего стола» Алана Кея. Она помогла перейти от ввода команд в командную строку
к управлению визуальными объектами, представленными в цифровой форме,
напрямую (Рисунок 1).
С помощью метафор можно вызывать эмоциональный отклик. Когда в Apple
велась работа над вторым поколением iMac, Стив Джобс и Джони Айв как-то раз
прогуливались в саду и пытались представить, как будет выглядеть новая модель
девайса. Стиву на глаза попался подсолнух, и он предложил сделать iMac второго
поколения похожим на подсолнух. На рисунке 2 своей гибкой ножкой, с помощью
которой можно менять положение экрана, девайс действительно напоминает
подсолнух.

Рисунок 1. Первый рабочий стол на Mac OS 1984 года, который принес

широкую известность новому графическому пользовательскому
интерфейсу.

11
 Рисунок 2. Использование метафоры подсолнуха делает iMac более
«человечным».
Если предлагать людям самобытный продукт, не похожий на тот, что уже
существует, нужно описывать его хотя бы отчасти при помощи понятий, которые
аудитория хорошо понимает. Например, Pinterest, завоевавший 10 миллионов
пользователей за рекордное для социальной платформы время, построен на метафоре
доски для заметок. Пользователи «прикрепляют» к себе на доску фотографии, которые
нашли в Сети, и составляют из них тематические коллекции. Такая метафора
вдохновляет людей на творчество.

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

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

12
 Правила применения метафор:
- опасно полностью копировать метафору, достаточно взять из неё самое
лучшее;
iBooks от Apple – отличный пример подобной ошибки. В iBooks был
использован дизайн, имитирующий книжный шкаф, вплоть до 3D полок и текстур под
дерево. Метафора книжного шкафа была призвана помочь пользователям перенести
то, что они знают о книжных шкафах в реальности (место для хранения и
упорядочивания материальных носителей информации), на реалии виртуальной среды.
Полки и оформление под дерево не имели никакого отношения к функционалу
приложения, они использовались, чтобы сделать метафору очевиднее. Позже
компания Apple отказалась от этого дизайна интерфейса.

В iBooks от Apple применялся знакомый и ясный для всех образ книжного шкафа, чтобы
дать пользователю понять, что он видит перед собой, и помочь установить эмоциональную
связь.
- следует остерегаться фотографической похожести среды в компьютере с
выбранным аналогом.
- эффективнее всего метафорически объяснять значение отдельных объектов;
- если метафора хоть как-то ограничивает систему, от неё необходимо
немедленно отказаться.
- следует избегать примитивных, буквальных метафор
Подобрать хорошую метафору для дизайна очень сложно. Всегда есть риск, что
вы сделаете неверный выбор и все пойдет кувырком. Как мы все знаем по опыту,
плохая метафора может сбить с толку. Один из таких примеров — Скрепыш от
Microsoft. Он получил известность как одно из самых неудачных решений для
интерфейса, когда-либо предложенных широкой публике, и оказался в числе самых
непопулярных функций за всю историю франшизы.

13
 Скрепыш от Microsoft — надоедливая анимированная
скрепка, которая появлялась в углу экрана и
отвлекала пользователей от рабочего процесса.

Графический интерфейс пользователя является частью

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

Можно выделить следующие виды GUI:

- простой: типовые экранные формы и стандартные
элементы интерфейса, обеспечиваемые самой подсистемой GUI;
- истинно-графический, двухмерный: нестандартные
элементы интерфейса и оригинальные метафоры,
реализованные собственными средствами приложения или
сторонней библиотекой;
- трёхмерный.

Преимущества графического интерфейса

− графический интерфейс является интуитивно понятным, «дружелюбным»
для пользователей любого уровня;
− для работы с программами обработки графики графический интерфейс
является единственно возможным.

Недостатки
− графический интерфейс использует больше потребление памяти по
сравнению с текстовым интерфейсом;
− сравнительная сложность организации удаленной работы;
− невозможна автоматизация работы при условии, если она не была заложена
разработчиком программы;
− к графическому интерфейсу трудно привыкнуть пользователям, которые
работали с интерфейсом командной строки.

Основные элементы графического интерфейса

Элемент интерфейса,
элемент управления, виджет –
примитив графического
интерфейса пользователя,
который имеет стандартный
внешний вид и выполняет
стандартные действия.

Окно − один из основных

элементов интерфейса
операционной системы
Windows.
Рабочий стол – область
на экране, где расположены
программы и инструменты в виде значков или иконок.
14
 Окна папок Windows имеют одинаковый вид или интерфейс, что облегчает
работу на ПК.

Диалоговое окно – в графическом

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

Диалоговые окна бывают модальными и немодальными, в зависимости от

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

15
 Переключатель – значок в виде черного кружка в круглом окошке,
установленный слева от команды. Включение/отключение, как и у выключателя,
происходит щелчком мыши, но в отличие от выключателя, может быть включен
только у одной команды из
списка.
Окно приложения.
Приложениями принято называть
прикладные программы. Каждое
приложение имеет главное окно. В
ходе работы с приложением могут
открываться дополнительные
подчиненные окна.
Окно документа не может
существовать самостоятельно, оно
управляется каким-либо
приложением. Такие окна
называются дочерними. Они
размещаются только внутри
главного окна приложения и
исчезают при закрытии главного окна.

Окно документа, управляемое приложением MS Word

Меню является важным элементом графического интерфейса пользователя, с

помощью которого можно выбрать одну из нескольких перечисленных опций
программы. Выбор пунктов меню может осуществляться пользователем любым из
указательных устройств ввода, которые предоставляет электронное устройство (с
помощью мыши, клавиатуры, тачпада и т.п.).
Контекстное меню – элемент графического интерфейса операционной системы
в виде списка команд, который вызывается пользователем для выбора необходимого
действия над выбранным объектом. Команды контекстного меню относятся лишь к
тому объекту, для которого это меню вызвано.
Элементами графического интерфейса операционной системы Windows также
являются: Значки, которыми обозначаются программы и документы. Для запуска
16
выполняется двойной щелчок кнопки мыши по значку. Панель задач располагается в
нижней части экрана. На ней располагаются кнопка Пуск, кнопки открытых окон,
индикаторы и время.
Взаимодействие человека и современного ПК осуществляется с помощью
объектно-ориентированного графического интерфейса, в котором: все объекты
представлены в виде значков; операции над объектами осуществляются в окнах;
основным элементом программного управления является меню; основным элементом
аппаратного управления являются различные манипуляторы.

5) Пользовательский Web-интерфейс
Базовый WUI-стиль (англ. Web user interface, WUI) весьма схож с меню
иерархической структуры, которые пользователи знают по опыту работы в средах с
неграфическим интерфейсом за исключением более наглядного представления и
использования гиперссылок. Необходимая навигация выполняется в рамках одного
или нескольких приложений с использованием текстовых или визуальных
гиперссылок. Основные особенности приложения, использующего WUI-стиль:
- информация обычно отображается в единственном окне, называемом
браузером, хотя для представления данных в приложении могут использоваться
несколько окон браузеров;
- браузер обеспечивает меню для Web-приложения;
- выбор действий ограничен, так как меню, обеспечивающее обращение к
функциям, не является легкодоступным для приложения;
- Web-страница обладает небольшой степенью внутреннего контроля над
клиентской областью для открытия специализированных всплывающих меню;
- создание специализированных меню требует дополнительной работы по
программированию;
- клиентская область не содержит традиционных пиктограмм;
- многие приложения используют графику и анимацию в эстетических или
навигационных целях. Это таит в себе потенциальную угрозу возникновения внешнего
визуального шума и увеличения времен отклика при загрузке и раскрытии
графических файлов;
- браузер и приложения обеспечивают возможности отключения графики,
содержащейся в Web-страницах, так что на экране отображается только их текстовая
версия;
- поддержка указателя осуществляется в основном для выбора с помощью
одного щелчка мышью или выбора по навигационным ссылкам. Технология "drag and
drop" ("перетащить и поместить") не поддерживается за исключением случаев
специального программирования в определенных средах.

Навигация. Переход от одной страницы к другой с использованием гиперссылок

или поискового механизма – наиболее часто выполняемая функция WUI-интерфейса.
Страницы, с которыми встречается пользователь, существуют в пределах того же
самого или другого Web-узла
Web-браузер обеспечивает базовые возможности навигации для перемещения по
Web-узлам и в пределах Web-узлов линейным способом с помощью кнопок панели
инструментов Back (Назад) и Forward (Вперед). Навигация от одной страницы

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

6) Пользовательский интерфейс карманных устройств (HUI).

Сегодня широко известны компьютеры двух основных классов PDA (Personal
Digital Assistant − персональный цифровой ассистент – "карманный" компьютер,
предназначенный для выполнения некоторых специальных функций) – в одних
используется настоящий GUI-стиль как по внешнему виду, так и по поведению, в
других применяется подмножество GUI-интерфейса. Для ввода данных пользователем
применяется "жестикуляционный" стиль с пером и сенсорным экраном.
Обычно подобные устройства обладают очень маленьким экраном. Для
поддержки PDA обычно используется GUI-ориентированное ПО для портативных или
настольных компьютеров.
HUI-интерфейс (Human User Interface) обеспечивает некоторые возможности
GUI-интерфейса, а именно пиктограммы, меню и аналогичное поведение указателя. В
окне устройства одновременно отображается один объект. Общий стиль для HUI-
интерфейса можно назвать SIMP-стилем (Screen – экран, Icon – пиктограмма, Menu –
меню и Pointer – указатель). При этом обеспечиваются многие свойства GUI-
интерфейса, например, такие как пиктограммы для представления объектов, действий
и атрибутов, меню, перо как указатель, диалоги (отображаются как окна, которые
перекрывают вызывающий объект). К некоторым PDA можно подключить клавиатуру.
Некоторые команды можно выполнять с помощью "жестикуляционных" комбинаций
клавиш, эквивалентных клавишам быстрого выбора команд GUI-интерфейса.
Основные проблемы проектирования HUI-ориентированных приложений:
а) Упрощение требований к пользователю по вводу данных и взаимодействию.
б) Использование ограниченной области дисплея.

7) Текстовый пользовательский интерфейс

ТПИ (англ. Text user interface, TUI; также Character User Interface, CUI) –
разновидность интерфейса пользователя, использующая при вводе-выводе и
представлении информации исключительно набор буквенно-цифровых символов и
символов псевдографики.
Характеризуется малой требовательностью к ресурсам аппаратуры ввода-вывода
(в частности, памяти) и высокой скоростью отображения информации, поэтому
широко использовался на начальном этапе развития вычислительной техники.
Интерфейс командной строки является его разновидностью.

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

19
 Лекция 14
Проектирование графического пользовательского интерфейса (ч.2)

Этапы разработки
Полный цикл разработки интерфейса включает следующие этапы:
− Исследование
− Пользовательские сценарии
− Структура интерфейса
− Прототипирование интерфейса
− Определение стилистики
− Дизайн концепция
− Оформление всех экранов
− Анимация интерфейса
− Подготовка материалов для разработчиков

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

Этап 2: Пользовательские сценарии

На основе предоставленного описания работы интерфейса создается список
задач (пользовательских сценариев), которые может выполнять пользователь в рамках
интерфейса. Например, обновить аватарку в профиле.
Все задачи расписываются по шагам, которые необходимо предпринять для
решения задачи. Например:
Зайти на сайт
Авторизоваться
Перейти в профиль
Нажать на аватарку
Выбрать файл
Подтвердить или изменить кадрирование изображения
Сохранить

Этап 3: Структура интерфейса

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

Этап 4: Прототипирование интерфейса

В основном делается два схематичных прототипа: черновой и финальный.
Исключения составляют небольшие интерфейсы: простенькие мобильные приложения
или маленькие сайты.

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

Этап 5: Определение стилистики

После этапа исследования и параллельно с этапами проектирования идет
определение будущей стилистики интерфейса.
Для выбора стилистики готовятся несколько наборов изображений (moodboards).
Потом один из этих наборов ляжет в основу дизайн концепции.

Этап 6: Дизайн концепция

Дизайн концепция призвана показать оформление (цвета, шрифты и т.д.) и дать
понять будущий вид проекта. Если предыдущий этап определения стилистики только
дал направление, то дизайн концепция призвана скрестить выбранное направление с
имеющимся содержанием интерфейса.
Дизайн концепция может быть представлена любым объемом. Обычно
концепция представлена 1—3 экранами интерфейса. Если речь идет о сайте, то нужно
показать вид одной и той же страницы для нескольких устройств. Если в интерфейсе
предполагается анимация на экране, участвующих в концепции, то нужно показать и
ее.

Этап 7: Оформление всех экранов

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

Этап 8: Анимация интерфейса

Часто этот этап начинается еще с момента дизайн концепции и продолжается на
протяжении всего этапа оформления всех экранов.
Можно показать только какие-либо нестандартные случаи анимации интерфейса,
которые не предусмотрены операционной системой. Например, нет никакой
надобности показывать с какой скоростью будет выезжать следующий экран в
интерфейсе приложения под iOS.

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

Этап 9: Подготовка материалов для разработчиков

Макеты интерфейса во всех состояниях уже есть. Прототип, связывающий весь
интерфейс воедино — есть. Видеоролики, показывающие анимацию, готовы. Чтобы
помочь разработчикам в реализации интерфейса, следует подготовить все
необходимые для этого материалы.
Это могут быть: спрайты, шрифт со всеми иконками, UI Kit (готовый набор
графических элементов в формате исходного файла (например, PSD или Sketch)) с
повторяющимися элементами интерфейса и их состояниями.
Бывает, что исследования проведены, схематичные прототипы интерфейса уже
готовы, стилистика известна. Остается только все это оформить и передать
разработчикам.

Факторы удобства использования и принципы создания удобного ПО

Основные факторы, с помощью которых можно оценить или даже измерить
удобство использования программы, следующие:
Адекватность интерфейса.
Адекватность пользовательского интерфейса программы — это его соответствие
тем задачам, которые пользователи должны и хотели бы решать с ее помощью.
Это соответствие имеет два аспекта: во-первых, все нужные пользователям
задачи должны быть разрешимы (если это не так — у программы большие проблемы),
во-вторых, те действия, которые пользователи выполняют чаще, должны требовать
меньше усилий.
Производительность работы пользователей.
Это количество однотипных реальных задач, которые пользователь может
решить с помощью ПО за единицу времени.
Скорость обучения новых пользователей.
Это количество задач, выполнению которых новый пользователь самостоятельно
обучается за единицу времени.
Кроме того, важным показателем является соответствие обучения частоте
возникновения задач — чем чаще на практике возникает необходимость решить
определенную задачу, тем быстрее пользователь должен научиться делать это.
Эффективность предотвращения и преодоления ошибок пользователей.
Этот показатель тем лучше, чем реже пользователи ошибаются при работе с
данным интерфейсом и чем меньше времени и усилий требуется для преодоления
последствий уже сделанных ошибок.
Стоит особо отметить, что предотвращение ошибок, в том числе "правильное"
понимание программой действий пользователя, не вполне совпадающих с теми,
которые в данном контексте хотели бы видеть ее разработчики, гораздо важнее.
Предотвращенная ошибка — это ошибка несделанная, пользователь не считает ее
ошибкой и не испытывает никакого стресса по ее поводу, она не снижает его
производительность.
Большое значение имеет также риск, связанный с возникновением ошибки.
Удобное ПО не должно требовать от пользователя серьезных усилий для совершения
4
действий, ошибки в которых не слишком накладны; но, если последствия ошибки
катастрофичны, необходимо всячески препятствовать ее совершению. Именно
поэтому запуск боевой ракеты или открытие хранилища банка не выполняются
нажатием одной кнопки, которая всегда под рукой, а обставлены трудностями, вроде
необходимости сделать два-три существенно разных действия, одновременно
повернуть два ключа, и пр.
Субъективное удовлетворение пользователей.
Этот фактор наиболее тяжело проанализировать, хотя измерить его довольно
просто — нужно попросить группу пользователей оценить, понравилась им система
или нет, по какой-то шкале (обычно используются 5 или 7 балльные шкалы). Средний
результат полученных оценок можно использовать как числовое значение этого
показателя.
Тяжелее добиться, чтобы интерфейс хорошо воспринимался пользователями в
среднем — простое внесение исправлений, подсказанных одними пользователями,
может отрицательно сказаться на оценках других. Считается, что субъективное
удовлетворение пользователей почти всегда повышается в следующих случаях:
− Если интерфейс программы эстетичен и элегантен, т.е. построен на немногих
и близких к гармоничному (1:1,618) соотношениях между размерами отдельных
элементов и расстояниями между ними, на мягких, неброских цветах и не режущих
глаз их сочетаниях, небольшом количестве контрастов, слегка сглаженных углах, на
аккуратном выравнивании отдельных элементов.
− Если в работе системы не возникает долгих пауз, во время которых
пользователи не знают, чем заняться. Даже если системе требуется много времени для
выполнения каких-то действий, показываемые в это время картинки и
предоставляемая дополнительная информация могут снизить
субъективную длительность ожидания.
− Если у пользователей, даже достаточно неопытных, не возникает стресса при
работе с системой. Стресс может возникнуть по многим причинам:
− От осознания ответственности за производимые действия и невозможности
отменить их, если они вдруг окажутся неправильными.
− От необходимости поддерживать высокий уровень внимания, запоминать
какие-то вещи, чтобы использовать их позднее, или серьезно обдумывать выполнение
каждого очередного действия.
− От отсутствия контроля за поведением системы, когда она выполняет
непонятные действия или сообщает о событиях, которые сам пользователь не
инициировал (или не может связать их со своими предыдущими действиями).
− Другой источник потери ощущения контроля — изменчивость самого
интерфейса. Если кнопки, элементы меню и пр. то появляются в определенных местах,
то исчезают или становятся неактивными по неизвестным (ненаблюдаемым
непосредственно) причинам, пользователь теряется. Связанный с таким поведением
системы стресс объясняется также невозможностью быстро построить в сознании
модель ее поведения — система становится чем-то зыбким, неустойчивым.
− От частых, категоричных и неинформативных сообщениях об ошибках.
− Удовлетворение пользователей выше, если дается возможность настроить
интерфейс программы так, как им нравится, но при этом предоставленных вариантов
не чересчур много, чтобы пользователь не мог в них "заблудиться".

5
 Специалисты по удобству использования обычно формулируют некоторый
набор принципов и правил, позволяющих как оценивать удобство интерфейса, так и
предлагать решения, повышающие его удобство:
Правило доступности.
Система должна быть настолько понятной, чтобы пользователь, никогда раньше
не видевший ее, но хорошо разбирающийся в предметной области, мог без всякого
обучения начать ее использовать.
Это правило служит некоторым идеалом, к которому надо стремиться,
поскольку на практике достичь такой степени понятности почти никогда не удается.
Тем не менее, все, что можно сделать для достижения этого идеала, делать нужно.
Правило эффективности.
Система не должна препятствовать эффективной работе опытных пользователей,
работающих с ней долгое время.
Очевидным примером нарушения этого правила является нацеленность системы
только на новичков, например, выполнение почти всех операций с помощью мастеров
(wizards), которые хорошо подходят для неопытного пользователя, ограничивая его в
возможности сделать что-то не так, но неэффективны для эксперта, который и так
знает, что и где ему нужно сделать.
Правило непрерывного развития.
Система должна способствовать непрерывному росту знаний, умений и навыков
пользователя и приспосабливаться к его меняющемуся опыту.
Плохие результаты приносит предоставление только базовых возможностей или
оставление начинающего пользователя наедине со сложным интерфейсом, которым
уверенно пользуются эксперты. Нарушение непрерывности при переходе от одного
набора возможностей к другому также приносит неудобства, поскольку пользователь
вынужден разбираться с добавленными возможностями в новом контексте.
Большинство пользователей можно поместить в три группы: новичков, опытных
и средних, которые уже знают больше, чем новички, и не делают столько ошибок, но
еще не приобрели автоматизма при выполнении большинства операций и иногда
путаются в интерфейсе. Новичкам необходима помощь в освоении новой для них
системы и контроль их действий, опытным пользователям — высокая эффективность
выполнения часто требующихся действий и возможность гибкого управления
системой в таких ситуациях, которые встречаются реже, но способны вызвать
проблемы при их неадекватной поддержке. Про средних же пользователей часто
забывают, хотя подавляющее большинство пользователей ПО относится к этой
категории. Им нужны достаточно высокие эффективность и гибкость вместе с
возможностью быстро получать адекватную помощь по возникающим время от
времени разнообразным вопросам.
Правило поддержки.
Система должна способствовать более простому и быстрому решению задач
пользователя.
Это означает, прежде всего, что система должна действительно решать задачи
пользователя. Кроме того, она должна решать их лучше, проще и быстрее, чем
имевшиеся до ее появления инструменты и методы.
Правило соблюдения контекста.
Система должна быть согласована с контекстом, в котором ей предстоит
работать.

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

Следующие принципы позволяют находить решения, повышающие удобство

пользовательского интерфейса.
Принцип структуризации.
Пользовательский интерфейс должен быть целесообразно структурирован.
Близкие по смыслу, родственные его части должны быть связаны видимым образом, а
независимые — разделены; похожие элементы должны выглядеть похоже, а
непохожие — различаться.
Принцип простоты.
Наиболее распространенные операции должны выполняться максимально
просто. При этом должны быть видимые ссылки на более сложные процедуры.
Принцип видимости.
Все функции и данные, необходимые для решения определенной задачи, должны
быть видны, когда пользователь пытается ее решить.
Принцип обратной связи.
Пользователь должен получать сообщения о действиях системы и о важных
событиях внутри нее. Сообщения должны быть информативными, краткими,
однозначными и написанными на языке, понятном пользователю.
Принцип толерантности.
Интерфейс должен быть гибким и терпимым к ошибкам пользователя. Ущерб от
ошибок должен снижаться за счет возможности отмены и повтора действий и за счет
разумной интерпретации любых разумных действий пользователя и введенных им
данных. По возможности, следует избегать обязывающего взаимодействия (модальных
диалогов), основанного на ограничении свободы пользователя.
Принцип повторного использования.
Следует стараться использовать многократно внутренние и внешние
компоненты, обеспечивая тем самым унифицированность интерфейса и сходство
между его похожими элементами.

Преимущества и недостатки стилей взаимодействия пользователя с

системой.
Разработчику интерфейса пользователя вычислительных систем необходимо
решить две главные задачи: каким образом пользователь будет вводить данные в
систему и как данные будут представлены пользователю. "Правильный" интерфейс
должен обеспечивать и взаимодействие с пользователем, и представление
информации.
Интерфейс пользователя обеспечивает ввод команд и данных в вычислительную
систему. На первых вычислительных машинах был только один способ ввода данных –
через интерфейс командной строки, причем для взаимодействия с машиной
использовался специальный командный язык. Такой способ годился только для

7
опытных пользователей, поэтому позже были разработаны более упрощенные способы
ввода данных. Все эти виды взаимодействия можно отнести к одному из пяти
основных стилей взаимодействия.
1. Непосредственное манипулирование.
Пользователь взаимодействует с объектами на экране. Например, для удаления
файла пользователь просто перетаскивает его в корзину.
2. Выбор из меню. Пользователь выбирает команду из списка пунктов меню.
Очень часто выбранная команда воздействует только на тот объект, который выделен
(выбран) на экране. При таком подходе для удаления файла пользователь сначала
выбирает файл, а затем команду на удаление.
3. Заполнение форм. Пользователь заполняет поля экранной формы. Некоторые
поля могут иметь свое меню (выпадающее меню или списки). В форме могут быть
командные кнопки, при щелчке мышью на которых инициируют некоторое действие.
Чтобы удалить файл с помощью интерфейса, основанного на форме, надо ввести в
поле формы имя файла и затем щелкнуть на кнопке удаления, присутствующей в
форме.
4. Командный язык. Пользователь вводит конкретную команду с параметрами,
чтобы указать системе, что она должна дальше делать. Чтобы удалить файл,
пользователь вводит команду удаления с именем файла в качестве параметра этой
команды.
5. Естественный язык. Пользователь вводит команду на естественном языке.
Чтобы удалить файл, пользователь может ввести команду "удалить файл с именем
XXX".

Каждый из этих стилей взаимодействия имеет преимущества и недостатки и

наилучшим образом подходит разным типам приложений и различным категориям
пользователей.
Стиль Основные Основные недостатки Примеры
взаимодействия преимущества приложений
Прямое Быстрое и Сложная реализация. Видеоигры;
манипулирование интуитивно Подходит только там, системы
понятное где есть зрительный автоматического
взаимодействие. образ задач и объектов проектирования
Легок в изучении
Выбор из меню Сокращение Медленный вариант Главным образом
количества ошибок для опытных системы общего
пользователя. Ввод пользователей. Может назначения
с клавиатуры быть сложным, если
минимальный меню состоит из
большого количества
вложенных пунктов
Заполнение форм Простой ввод Занимает Системы
данных. Легок в пространство на управления
изучении экране запасами;
обработка
финансовой
информации
8
Командный язык Мощный и гибкий Труден в изучении. Операционные
Сложно системы;
предотвратить ошибки библиотечные
ввода системы
Естественный Подходит Требует большого Системы
язык неопытным ручного набора расписания;
пользователям. системы хранения
Легко настраивается данных WWW

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

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

Факторы проектирования текстовых сообщений

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

Юзабилити
Крупные компании ПО тратят уйму денег на юзабилити. Юзабилити — это
степень эффективности, продуктивности и удовлетворенности, с которыми продукт
может быть использован определенными пользователями в определенном контексте
использования для достижения определенных целей.

9
 Принципы юзабилити
Заимствуйте. Если пользователь привык к чему-либо, он быстрее научится
работать и будет получать больше удовольствия от работы с вашей программой, так
как сможет использовать приобретенные навыки. Базовое заимствование — это
использование стандартных элементов, общих для всех программ Windows: меню,
списки, кнопки и т.п. Не стоит, например, вместо стандартных RadioButton
использовать для тех же целей (одиночного выбора) CheckBox, которые применяются
несколько для других целей (мультивыбора).
Не прерывайте пользователя. Представьте, что вы печатаете текст и
одновременно скачиваете из Интернета десяток файлов. После каждого скачанного
файла программа сообщает вам эту радостную новость, вам приходится передвигать
указатель мыши к кнопке OK, щелкать на нее и вспоминать, что же вы писали. Мне
кажется, что эта программа со временем будет выключена из-за ее чрезмерной
радости. Это правило можно обойти: например, сообщить тихонько эту информацию
пользователю на несколько секунд, но не отвлекая его от его работы. Очень хорошо
решила эту проблему компания Microsoft (Windows XP), предложив программам,
которые запускаются в системном трее, выдавать пользователю всплывающие
подсказки на несколько секунд, после чего они исчезают.
Бритва Оккама. Любая задача должна решаться минимальным числом действий.
Если вы хотите отправить письмо Васе, и только ему, то вовсе не обязательно
предлагать пользователю выбрать других адресатов, копии писем, спрашивать, нужен
ли отчет о доставке, подтверждение прочтения, в каком формате пересылать
прикрепленные файлы... — ему нужно просто отправить письмо Васе. Или вот еще
один всем хорошо знакомый пример. Окно, которое появляется при первом запуске
справки. Вряд ли кто-то может решить, должна ли база данных быть
оптимизированной по размеру или по скорости доступа. Первая проблема этого окна в
том, что оно отрывает вас от ваших мыслей. Вы обращаетесь за помощью к файлу
справки, и вам нет никакого дела, по крайней мере, в этот момент, до того, будет ли
база данных маленькой или большой. Тем временем эта наглая программа читает вам
лекцию о том, что она должна создать список (или базу данных). Там же встречается
совершенно неуклюжая фраза: "your help file(s)". То есть у вас может быть один или
несколько файлов. Как будто для вас это имеет какое-то значение. Но программист,
работавший над этим окном, очевидно, понимал, что файлов может быть много,
поэтому просто сказать "help file" было бы неправдой. В данной ситуации даже
"продвинутые" пользователи, программисты с научной степенью, которые знают все о
полнотекстовых индексах, не способны понять, что у них спрашивают. Наконец, это
окно даже не диалог, а "мастер" (вторая страница которого, если перефразировать,
говорит что-то типа "спасибо за то, что вы бесполезно потратили свое время").
Очевидно, что у разработчиков была какая-то идея, какой из способов лучше, но они
так и не смогли выбрать для пользователя ни один из вариантов.
Информативность. Пользователь всегда должен знать, что происходит с
программой, и когда ему следует подождать некоторое время. Например, при
копировании файлов будет полезно вывести окно, в котором "градусник" будет
показывать, сколько процентов файла уже скопировано. Он, конечно, не уменьшит
времени, которое пользователю придется потратить на копирование этого файла,
однако скрасит его ожидание. Этот "градусник" также сообщит пользователю, успеет
ли тот сварить себе чашку кофе. Еще один вариант сообщить пользователю о том, что

10
ему нужно подождать, — песочные часы. Именно они говорят о том, что сейчас
происходит какая-то обработка или загрузка данных и что через несколько секунд
работа программы возобновится, иначе у него может возникнуть чувство, что
программа просто-напросто зависла. В любой среде программирования существует
возможность делать кнопку неактивной. Это можно делать, когда введенные
пользователем данные ошибочны. Однако если пользователь не понимает, где он
совершил ошибку, эта кнопка начинает исполнять роль этакого раздражителя с
издевательским подтекстом: "нажми, если сможешь". Поэтому лучше оставлять эту
кнопку активной, а при неправильном вводе каких-либо данных сообщать
пользователю о сделанной ошибке и о том, как ее исправить.
Кошелек Миллера. Принцип назван в честь ученого-психолога Г.А. Миллера,
который исследовал кратковременную память, проверяя выводы, сделанные ранее его
коллегой Г.Эббингаузом. Эббингауз пытался выяснить, сколько информации может
запомнить человек без каких-либо специальных мнемонических приемов. Оказалось,
что обычно емкость памяти ограничена семью цифрами, буквами или названиями
предметов. Это "магическое число" семь, служащее своего рода меркой памяти, и
было проверено Миллером, который показал, что память действительно в среднем не
может хранить более семи элементов ± два. Поэтому рекомендуется разделять окно
программы на отдельные блоки и в каждом блоке хранить как можно меньше
элементов (не больше семи).
Память. Когда парень дарит девушке на день рождения ее любимые цветы, ей
приятно. Ей приятно, что не нужно было опять говорить про то, какие цветы ей
нравятся и когда у нее день рождения. Ей приятно, что он помнит это. Пользователь
тоже девушка по отношению к программе. Программа не должна многократно
спрашивать, куда необходимо сделать резервную копию базы данных, если в
предыдущий раз пользователь выбирал директорию. Также программа не должна
предлагать сделать резервную копию тогда, когда пользователю не нужна такая
функция. Программа должна ухаживать за пользователем.
Золотое сечение. Принцип, согласно которому отношение высоты к ширине
должно быть равно отношению ширины к сумме высоты и ширины. Т.е. если за y взять
высоту окна, а за x — ширину, то y/x=x/(x+y). Это самая приятная для глаза
пропорция. Золотое сечение успешно использовано в программе Chameleon Clock. По
словам автора, ее дизайн очень понравился бета-тестерам.
Не трогайте чужое. Изменение системных файлов и настроек операционной
системы — плохой поступок. Никогда не записывайте информацию в папку Windows.
Исключение допустимо лишь в том случае, если вы создаете программу для
управления или изменения настроек операционной системы. Не забудьте
предупредить об этом пользователя. Если программа будет изменять все стандартные
настройки без разрешения пользователя, ей гарантирован нокаут. Не нужно менять
стандартные цвета. Предоставьте пользователю выбор цветовой гаммы, потому как
"на вкус и цвет друга нет". Необходимо помнить о том, что интерфейс должен быть
простой и не перенасыщенный.
Не спрашивать о непонятном. Если бы при установке электронного учебника по
химии необходимо было пройти тест по химии, никто бы сей прекрасный учебник не
оценил. Не стоит спрашивать пользователя о параметрах функции, которой он еще не
пользовался. Также многие программы при установке предлагают выбрать тип
установки: обычная или выборочная. Получается, что если выбрать выборочную, мы

11
будем выбирать то, о чем не знаем, а если обычную — то окажемся лопухами. Лучше
давать пользователю варианты: сделать это конкретное действие так, как предлагает
программа установки, или по-другому.
Подводя итоги, можно сформулировать концепцию профессионального
юзабилити: пользователю должно быть уютно (т.е. все знакомо); все действия
пользователя должны быть логичны; все используемые функции должны быть под
рукой.

12
 Лекция 15
Управление качеством и надежностью программного обеспечения (ч.1)

Качество программного обеспечения

Как проверить, что требования определены достаточно полно и описывают все,
что ожидается от будущей программной системы? Это можно сделать, проследив, все
ли необходимые аспекты качества ПО отражены в них.
Именно понятие качественного ПО соответствует представлению о том, что
программа достаточно успешно справляется со всеми возложенными на нее задачами
и не приносит проблем ни конечным пользователям, ни их начальству, ни службе
поддержки, ни специалистам по продажам. Да и самим разработчикам создание
качественной программы приносит гораздо больше удовольствия.
Если попросить группу людей высказать свое мнение по поводу того, что такое
качественное ПО, можно получить следующие варианты ответов:
 Его легко использовать.
 Оно демонстрирует хорошую производительность.
 В нем нет ошибок.
 Оно не портит пользовательские данные при сбоях.
 Его можно использовать на разных платформах.
 Оно может работать 24 часа в сутки и 7 дней в неделю.
 В него легко добавлять новые возможности.
 Оно удовлетворяет потребности пользователей.
 Оно хорошо документировано.
Все это действительно имеет непосредственное отношение к качеству ПО. Но
эти ответы выделяют характеристики, важные для конкретного пользователя,
разработчика или группы таких лиц. Для того чтобы удовлетворить потребности всех
сторон (конечных пользователей, заказчиков, разработчиков, администраторов систем,
в которых оно будет работать, регулирующих организаций и пр.), для достижения
прочного положения разрабатываемого ПО на рынке и повышения потенциала его
развития необходим учет всей совокупности характеристик ПО, важных для всех
заинтересованных лиц.

Качество ПО – комплекс характеристик программного продукта,

определяющих способность выполнять возложенные на него функции.

Основные аспекты качества программного обеспечения

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

1
 Качество продукта − качество основного производимого продукта
(программного обеспечения или системы) и всех его составляющих (например,
компонентов, подсистем, архитектуры и т. д.).

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

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

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

Факторы качества программного обеспечения

Различные факторы, которые влияют на программное обеспечение, называются
программными факторами. Их можно широко разделить на две категории.
Первая категория факторов – это те, которые могут быть измерены напрямую,
например, число логических ошибок, а вторая категория объединяет те факторы,
которые могут быть измерены только косвенно. Например, ремонтопригодность, но
каждый из факторов должен быть измерен для проверки содержания и контроля
качества.
Несколько моделей факторов качества программного обеспечения и их
категоризация были предложены за эти годы. Классическая модель факторов качества
программного обеспечения, предложенная McCall, состоит из 11 факторов (McCall et
al., 1977). Аналогично, модели, состоящие из 12-15 факторов, были предложены
Дойчем и Уиллисом (1988) и Эвансом и Марсиниаком (1987).
Все эти модели существенно не отличаются от модели Маккола. Факторная
модель Макколла предоставляет практичный, современный метод классификации
требований к программному обеспечению (Pressman, 2000).

Модель Маккола
Эта модель классифицирует все требования к программному обеспечению по 11
показателям качества программного обеспечения. Эти 11 факторов сгруппированы в
три категории:
эксплуатация продукта,
пересмотр продукта
факторы перехода продукта.

Факторы работы продукта – правильность, надежность, эффективность,

целостность, удобство использования.
2
 Факторы пересмотра продукта – ремонтопригодность, гибкость,
тестируемость.
Факторы перехода продукта – переносимость, возможность повторного
использования, совместимость.

Согласно модели Макколла, категория работы продукта включает пять

факторов качества программного обеспечения, которые отвечают требованиям,
которые непосредственно влияют на ежедневную работу программного обеспечения.
Они заключаются в следующем:

правильность
Эти требования касаются правильности вывода программного обеспечения
системы:
− Выходная миссия
− Требуемая точность вывода, на которую могут отрицательно повлиять
неточные данные или неточные расчеты.
− Полнота выводимой информации, на которую могут повлиять неполные
данные.
− Актуальность информации, определяемой как время между событием и
ответом системы программного обеспечения.
− Доступность информации.
− Стандарты кодирования и документирования программного обеспечения
системы.

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

Эффективность (КПД)
Он касается аппаратных ресурсов, необходимых для выполнения различных
функций системы программного обеспечения. Он включает в себя возможности
обработки (в МГц), емкость хранения (в МБ или ГБ) и возможность передачи данных
(в МБПС или ГБПС).
Он также касается времени между подзарядкой портативных блоков системы,
таких как блоки информационной системы, расположенные в портативных
компьютерах, или метеорологические блоки, размещенные на открытом воздухе.

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

Юзабилити
Требования юзабилити связаны с кадровыми ресурсами, необходимыми для
обучения нового сотрудника и эксплуатации системы программного обеспечения.

3
 Согласно модели Маккола, три категории качества программного
обеспечения включены в категорию редакции продукта. Эти факторы заключаются
в следующем:

Ремонтопригодность
Этот фактор учитывает усилия, которые потребуются пользователям и
обслуживающему персоналу для определения причин сбоев программного
обеспечения, исправления сбоев и проверки успешности исправлений.

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

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

Согласно модели Макколла, три категории качества программного

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

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

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

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

Проблемы разработки ПО
В современных условиях вопрос качества поставляемого на рынок
программного обеспечения становится все более актуальным — с ростом количества
компаний-разработчиков, а также независимых коллективов программистов, готовых
предоставить потребителям готовый продукт, заинтересованность в скорейшем выводе
в продажу коммерческого решения возрастает. Часто в погоне за прибылью ключевые
проблемы разработки ПО уходят на второй план — сроки одерживают верх в борьбе
за высокое качество программных решений.
Основные факторы, оказывающие негативное влияние на качественные
показатели выпускаемых на рынок программ:
Достаточно крупные коллективы разработчиков, планируя создание нового
программного обеспечения, как правило, совершают первую ошибку уже на этапе
формирования технического задания. Вопреки отработанной технологии разработки
качественного ПО, заказчики не редко ограничивают сроки реализации проекта,
вынуждая команду разработчиков исключать из перечня задач процесс отладки
написанного программистами кода. Вместо оптимизации каждого компонента
программного продукта, задача по «вылавливанию багов» возлагается на
тестировщиков, берущихся за работу на самом последнем этапе разработки ПО, когда
все модули программы уже собраны воедино.
Чуть менее значимой ошибкой, ведущей к появлению проблем при разработке
программного обеспечения, является игнорирование весьма нужной процедуры
анализа формируемых заказчиком и исполнителем требований к будущей программе.
Нечеткое понимание целей, преследуемых заказчиком, а также несогласованность
бизнес-деталей, подлежащих реализации в продукте, ведет к сдаче низкокачественной
программы, имеющей существенное количество недоработок. Особенно остро эта
проблема стоит в сфере разработки мобильных приложений, где ключевым фактором
для заказчиков становится как можно более ранний вывод решения на рынок, чтобы
успеть заработать деньги от продажи программы потребителям.

Пути решения
Чтобы избежать упомянутых проблем при разработке программного
обеспечения, и заказчики, и исполнители, будь то крупная компания или небольшой
коллектив программистов, должны придерживаться методики обеспечения качества
ПО, состоящей всего из нескольких пунктов.
1. Анализ требований
Еще на этапе формирования технического задания на разработку ПО требуется
согласовать ключевые вопросы, связанные с механикой работы и составом ключевых
компонентов программы. Также стороны должны прийти ко взаимному пониманию в
вопросе функциональности создаваемого программного продукта, что позволит
добиться принятия работы сразу после демонстрации рабочего образца программы.

5
 2. Анализ и сквозной контроль кода
Контроль работоспособности программного кода, наличие ошибок и
корректность их обработки, должны осуществляться постоянно, в течение всего
процесса разработки ПО. Перекладывать необходимость поиска проблемных участков
кода на плечи тестировщиков, занимающихся проверкой выполнения основных
функций ПО уже после выполнения основных этапов разработки, категорически
нельзя.
3. Сессионное тестирование
Методика сессионного тестирования, предложенная одним из ведущих
специалистов в области программирования Джеймсом Бахом, позволяет осуществлять
качественную проверку работоспособности созданного решения. В отличие от
технологии поиска «точечных» недоработок кода, при сессионном тестировании
тестировщик получает свободу действий, пытаясь выявить необычные дефекты,
фактически моделируя поведение предполагаемого пользователя.

Характеристики качества программного обеспечения

Совокупность свойств ПО, которая образует удовлетворительное для
пользователя качество ПО, зависит от условий и характера эксплуатации этого ПО, т.е.
от позиции, с которой должно рассматриваться качество этого ПО. Поэтому при
описании качества ПО, прежде всего, должны быть фиксированы критерии отбора
требуемых свойств ПО. В настоящее время критериями качества ПО (criteria of
software quality) принято считать:
- функциональность;
- надежность;
- легкость применения;
- эффективность;
- сопровождаемость;
- мобильность.
Функциональность − это способность ПО выполнять набор функций,
удовлетворяющих заданным или подразумеваемым потребностям пользователей.
Набор указанных функций определяется во внешнем описании ПО.
Надежность (reliability) ПО − это его способность безотказно выполнять
определенные функции при заданных условиях в течение заданного периода времени с
достаточно большой вероятностью. При этом под отказом в ПО понимают проявление
в нем ошибки. Таким образом, надежное ПО не исключает наличия в нем ошибок -
важно лишь, чтобы эти ошибки при практическом применении этого ПО в заданных
условиях проявлялись достаточно редко. Убедиться, что ПО обладает таким свойством
можно при его испытании путем тестирования, а также при практическом применении.
При оценке степени надежности ПО следует также учитывать последствия
каждого отказа. Некоторые ошибки в ПО могут вызывать лишь некоторые неудобства
при его применении, тогда как другие ошибки могут иметь катастрофические
последствия, например, угрожать человеческой жизни. Поэтому для оценки
надежности ПО иногда используют дополнительные показатели, учитывающие
стоимость (вред) для пользователя каждого отказа.
Легкость применения − это характеристики ПО, которые позволяют
минимизировать усилия пользователя по подготовке исходных данных, применению

6
ПО и оценке полученных результатов, а также вызывать положительные эмоции
определенного или подразумеваемого пользователя.
Эффективность − это отношение уровня услуг, предоставляемых ПО
пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость − это характеристики ПО, которые позволяют
минимизировать усилия по внесению изменений для устранения в нем ошибок и по
его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность − это способность ПО быть перенесенным из одной среды
(окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надежность являются обязательными критериями качества
ПО, причем обеспечение надежности должно красной нитью проходить по всем
этапам и процессам разработки ПО. Остальные критерии используются в зависимости
от потребностей пользователей в соответствии с требованиями к ПО. Для
конкретизации качества ПО по каждому из критериев используется
стандартизованный набор достаточно простых свойств, однозначно интерпретируемых
разработчиками. Такие свойства называются примитивами качества ПО. Некоторые
из примитивов могут использоваться по нескольким критериям. Ниже приводится
зависимость критериев качества от примитивов качества ПО.
Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость,
защищенность.
Легкость применения: П-документированность, информативность (только
применительно к документации по применению), коммуникабельность, устойчивость,
защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам (по
памяти), эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных примитивов
качества. Однако их можно распределить по двум группам, выделив два подкритерия
качества: изучаемость и модифицируемость. (Изучаемость − это характеристики ПО,
которые позволяют минимизировать усилия по изучению и пониманию программ и
документации ПО. Модифицируемость − это характеристики ПО, которые позволяют
автоматически настраивать на условия применения ПО или упрощают внесение в него
вручную необходимых изменений и доработок).
Изучаемость: С-документированность, информативность (здесь
применительно к документации по сопровождению), понятность,
структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком
смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность,
модульность.
Ниже даются определения используемых примитивов качества ПО.
Завершенность (completeness) − свойство, характеризующее степень обладания
ПО всеми необходимыми частями и чертами, требующимися для выполнения своих
явных и неявных функций.
Точность (accuracy) − мера, характеризующая приемлемость величины
погрешности в выдаваемых программами ПО результатах с точки зрения
предполагаемого их использования.

7
 Автономность (self-containedness) − свойство, характеризующее способность
ПО выполнять предписанные функции без помощи или поддержки других компонент
программного обеспечения.
Устойчивость (robustness) − свойство, характеризующее способность ПО
продолжать корректное функционирование, несмотря на неправильные (ошибочные)
входные данные.
Защищенность (defensiveness) − свойство, характеризующее способность ПО
противостоять преднамеренным или нечаянным деструктивным (разрушающим)
действиям пользователя.
П-документированность (u. documentation) − свойство, характеризующее
наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и
справочной документации, необходимой для применения ПО.
Информативность (accountability) − свойство, характеризующее наличие в
составе ПО информации, необходимой и достаточной для понимания назначения ПО,
принятых предположений, существующих ограничений, входных данных и
результатов работы отдельных компонент, а также текущего состояния программ в
процессе их функционирования.
Коммуникабельность (communicativeness) − свойство, характеризующее степень,
в которой ПО облегчает задание или описание входных данных, и способность
выдавать полезные сведения в достаточно простой форме и с простым для понимания
содержанием.
Временнáя эффективность (time efficiency) − мера, характеризующая
способность ПО выполнять возложенные на него функции в течение определенного
отрезка времени.
Эффективность по ресурсам (resource efficiency) − мера, характеризующая
способность ПО выполнять возложенные на него функции при определенных
ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency) − мера, характеризующая
экономичность использования устройств машины для решения поставленной задачи.
С-документированность (documentation) − свойство, которое характеризуют
написание документации, отражающей требования к ПО и результаты различных
этапов разработки данной ПО, включающие возможности, ограничения и другие
черты ПО, а также их обоснование.
Понятность (understandability) − свойство, характеризующее степень, в которой
ПО позволяет изучающему его лицу понять его назначение, сделанные допущения и
ограничения, входные данные и результаты работы его программ, тексты этих
программ и состояние их реализации.
Структурированность (structuredness) − свойство, характеризующее программы
ПО с точки зрения организации взаимосвязанных их частей в единое целое
определенным образом (например, в соответствии с принципами структурного
программирования).
Удобочитаемость (readability) − свойство, характеризующее легкость
восприятия текста программ ПО (отступы, фрагментация, форматированность).
Расширяемость (augmentability) − свойство, характеризующее способность ПО к
использованию большего объема памяти для хранения данных или расширению
функциональных возможностей отдельных компонент.

8
 Модифицируемость (modifiability) − мера, характеризующая ПО с точки зрения
простоты внесения необходимых изменений и доработок на всех этапах и стадиях
жизненного цикла ПО.
Модульность (modularity) − свойство, характеризующее ПО с точки зрения
организации его программ из таких дискретных компонент, что изменение одной из
них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств (device independence) − свойство,
характеризующее способность ПО работать на разнообразном аппаратном
обеспечении (различных типах, марках, моделях ЭВМ).
Разработка программного средства завершается его аттестацией. Аттестация
программного средства − это авторитетное подтверждение его качества. Как правило,
для аттестации создается комиссия экспертов. Эта комиссия проводит приемо-
сдаточные испытания программного средства с целью получения необходимой
информации для оценки его качества. При этом оцениваются только установленные
критерии качества и примитивы качества.

Показатели программного продукта

Показатели программного обеспечения — это количественные показатели,
которые можно измерить и которые характеризуют программную систему, процесс
разработки ПО или сопровождающую документацию. Например, это может быть
размер программного продукта, равный количеству строк кода, индекс непонятности,
который является мерой читабельности письменного текста, количество
зарегистрированных ошибок в программном продукте, а также количество человеко-
дней, требующихся для создания системных компонентов.

Таким образом, эти показатели отображают свойства программного продукта в

целом. К сожалению, такие легко измеримые показатели, как размер и
цикломатическая сложность программы, не имеют прямой и универсальной
взаимосвязи с такими показателями качества, как надежность или удобство
сопровождения. Эти взаимосвязи могут изменяться в процессе разработки продукта,
зависят от технологии разработки и типа разрабатываемой программной системы.
Организации-разработчики обязательно должны вести базу статистических данных.
Именно такая база данных поможет в дальнейшем разобраться, какие свойства
продукта соотносятся с теми показателями качества, в которых заинтересована
организация.

Показатели программного продукта можно разделить на два класса.

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

9
время, необходимое для запуска системы. Именно эти показатели соотносятся с
эффективностью системы. Таким же образом можно регистрировать количество
системных ошибок и их типы, что напрямую связано с надежностью системы.
Статические показатели, как правило, имеют отдаленное отношение к
качественным характеристикам ПО. Было предложено достаточное количество таких
показателей, с которыми был проведен ряд экспериментов для выявления и оценки
возможных взаимосвязей между этими показателями и такими свойствами, как
сложность, понятность и удобство эксплуатации системы.
В таблице приведено несколько статических показателей, которые могут
использоваться при оценке качества. Среди них объем программного кода и
сложность управления являются наиболее надежными показателями для
прогнозирования сложности, понятности и удобства сопровождения программного
продукта.
Показатели Описание
Нагрузочный множитель Нагрузочный множитель по входу пропорционален
по входу и нагрузочный количеству функций, которые вызывают другую функцию
множитель по выходу (назовем ее X). Нагрузочный множитель по выходу
пропорционален количеству функций, которые
вызываются функцией X. Высокие значения для
множителя по входу означают, что функция X тесно
связана с остальными компонентами системы и изменения
в этой функции могут привести к существенным
изменениям во всей системе. Высокое значение
множителя по выходу означает высокую сложность самой
функции X, которая вытекает из сложности логической
схемы управления вызываемых ею компонентов
Объем программного кода Этот показатель определяет размер программы. В общем
случае, чем больше объем кода программного
компонента, тем более сложным и подверженным
ошибкам будет сам компонент
Цикломатическая Это мера сложности логической структуры программы. В
сложность свою очередь, сложность структуры программы связана с
таким показателем, как понятность программного кода.
Длина идентификаторов Этот показатель измеряется как среднее длин
идентификаторов в программе. Чем длиннее
идентификаторы, тем понятнее, что они означают, а
следовательно, более понятна и сама программа
Глубина вложения Здесь измеряется глубина вложений условных операторов
условных операторов в программе. Большая глубина вложения условных
операторов затрудняет чтение программы, что ставит ее в
разряд потенциально ошибочных программ
Индекс непонятности Измеряется как среднее длин слов и предложений в
документах. Чем выше показатель индекса непонятности,
тем труднее понять документ

Измерение показателей ПО – получение числовых значений определенных

показателей программного продукта или процесса его разработки.
10
 Показатели делятся на два вида: контрольные и прогнозируемые.
Контрольные показатели обычно соотносятся с процессом разработки ПО, а
прогнозируемые — с готовым программным продуктом.
Примером контрольного показателя (показателя процесса) может быть среднее
значение затрат и времени, расходуемых на исправление зарегистрированных
неполадок. В качестве примера прогнозируемого показателя можно привести
цикломатическую сложность программных модулей, среднюю длину
идентификаторов в программе, а также количество атрибутов и операторов,
относящихся к объектами системной структуры.
Процесс измерений состоит из пяти основных этапов:

1. Выбор показателей для измерения. Определяются измеряемые показатели.

2. Отбор системных компонентов. Часто совсем необязательно оценивать
показатели всех компонентов программной системы.
3. Измерение показателей компонентов. Это процесс измерения значений
выбранных показателей для отобранных компонентов.
4. Определение аномальных данных. Значения измеренных показателей нужно
сравнить между собой и с предыдущими измерениями, занесенными в базу данных.
5. Анализ аномальных компонентов. Определив компоненты с аномальными
показателями, их следует изучить для выявления возможного отрицательного влияния
на качество программного продукта в целом.

Методы контроля качества ПО

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

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

Методы верификации делятся на следующие группы:

• Методы экспертизы (review, inspection). При экспертизе верификацию
проводит человек, обладающий значительным опытом проведения такого рода
проверок (часто также в экспертизу включаются неопытные сотрудники с целью их
обучения). Экспертиза бывает общей, нацеленной на выявление любых дефектов и
ошибок, или специализированной, направленной на оценку отдельных характеристик
качества (например, гибкости архитектуры, удобства использования или
защищенности ПО).

• Методы статического анализа (static analysis). Такие методы используют

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

• Методы динамического анализа (dynamic analysis). Эти методы выполняют

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

12
или внешних систем производится их эмуляция). При этом собирается информация о
результатах работы в различных ситуациях, и эта информация далее подвергается
анализу на предмет соответствия требованиям или проектным решениям. Обычно к
таким методам относят
− тестирование, при котором работа ПО проверяется на заранее выбранном
наборе ситуаций;
− мониторинг, в рамках которого работа ПО протоколируется и оценивается
при его обычной или пробной эксплуатации;
− профилирование − специфический вид мониторинга временных
характеристики работы ПО и использования им отдельных ресурсов.
К динамическим методам анализа относят также и имитационное тестирование,
и имитационный мониторинг, при которых ПО выполняется в рамках какого-то
модельного окружения, построенного с использованием симуляторов и эмуляторов.

• Формальные методы верификации (formal verification) используют формальные

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

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

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

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

формальные модели требований к ПО и принятых проектных решений.

Расширенный статический анализ (extended static checking) использует

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

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

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

13
 Стандартизация в области оценки качества программного обеспечения
Стандарты ISO 9000
Стандарты ISO 9000 приняты более чем 90 странами мира (в том числе и в РБ) и
применимы к любым предприятиям, независимо от их размера и сферы деятельности.
Стандарты серии ISO 9000 регламентируют осуществление двух основных видов
деятельности:
− Формирование на предприятии системы управления качеством;
− Разработка руководств по качеству, которые содержит детальное описание
процедур управления качеством на предприятии.
Система управления качеством нужна как самому предприятию, так и его
потребителям, и поставщикам:
− потребителям наличие системы управления качеством гарантирует высокий
уровень качества покупаемой продукции и предоставляемых услуг;
− поставщикам ее наличие гарантирует четкие и своевременные требования
производителя к поставляемым материалам, а также перспективы долгосрочного
сотрудничества;
− предприятию система управления качеством позволяет более эффективно
организовать управление функциональными процессами.
Структура ISO 9000
Серия стандартов ISO 9000 содержит требования и способы реализации системы
управления качеством и обеспечения качества и включает пять стандартов:
ISO 9000 – руководство по выбору и использованию имеющихся стандартов
ISO 9001 – спецификации по конструированию, производству, установке и
сервисному обслуживанию
ISO 9002 – спецификации по производству, установке и сервисному
обслуживанию
ISO 9003 – спецификации по инспектированию и проверке продукции
ISO 9004 – описание основных понятий и приложений, используемых в полной
системе управления качеством

Таким образом, международные стандарты ISO 9001, 9002 и 9003 содержат

требования к системе качества и определяют различные модели его обеспечения на
разных этапах производственного цикла.
Стандарты обеспечения качества не ставят целью навязать некую
единообразную систему качества. Все их формулировки никак не связаны с
конкретной отраслью промышленности или экономическим сектором. На разработку и
внедрение системы качества оказывает влияние специфика задач и потребностей
организации, поставляемая продукция и услуги, реализованные в организации
процессы и накопленный опыт.
Общие формулировки по руководству качеством и стандарты их обеспечения
даны в спецификации ISO 9000, состоящей из трех частей:
ISO 9000-1: Руководящие указания по выбору и применению;
ISO 9000-2: Общие руководящие указания по применению стандартов ISO 9001,
9002, 9003;
ISO 9000-3: Руководящие указания по применению ISO 9001 при разработке,
поставке и обслуживании программного обеспечения.
Собственно, третья часть стандарта ISO 9000 нас и интересует.

14
 Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001,
а также необходимые дополнения к ним, относящиеся к разработке, поставке и
обслуживанию ПО.
ISO 9001 устанавливает требования к системе качества поставщика и позволяет
оценивать его возможности по проектированию и поставке продукции,
соответствующей этим требованиям. Требования стандарта направлены в первую
очередь на то, чтобы удовлетворить запросы пользователя, предупредив появление
каких-либо несоответствий продукции на всех стадиях ее жизненного цикла − от
проектирования до обслуживания.

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

положениях стандарта, в том числе:
продукт − результат действий или процессов;
программный продукт − набор компьютерных программ, процедур и, возможно,
связанных с ними документов и данных;
элемент программного обеспечения (software item) − любая идентифицируемая
часть программного продукта;
основание (baseline) − формально утвержденная версия элемента конфигурации,
зафиксированная в определенный момент времени в процессе жизненного цикла
элемента конфигурации;
разработка (development) − процесс жизненного цикла программного продукта,
охватывающий анализ требований, проектирование, кодирование, интеграцию,
тестирование, установку и поддержку;
модель жизненного цикла (life cycle model) − базовая модель, включающая
процессы, действия и задачи, вовлеченные в разработку, функционирование и
сопровождение программного продукта и охватывающие весь жизненный цикл
системы от определения требований до завершения использования;
этап (phase) − определенный сегмент работы;
регрессионное тестирование (regression testing) − тестирование, позволяющее
убедиться в том, что изменения, внесенные с целью исправления обнаруженных
ошибок, не породили новых;
репликация (replication) − копирование программного продукта с одного
носителя на другой.
Важно отметить, что в большинстве пунктов стандарта поставщик обязывается
не только определять соответствующие действия, но и оформлять их документально,
регистрировать результаты и периодически анализировать, для того чтобы внести
необходимые усовершенствования или полностью заменить.

Основные разделы стандарта

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

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

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

Анализ контракта
Система качества предусматривает определенные действия по анализу
контракта. Программный продукт может разрабатываться по контракту с заказчиком,
как коммерческий продукт для определенного сектора рынка, как система, встроенная
в аппаратное обеспечение, или как система поддержки бизнес-процессов поставщика.
Общие положения анализа контрактов, определенные в ISO 9000-3, применимы ко
всем этим ситуациям.
Поставщик должен проанализировать заявку на тендер, контракт или заказ до
подачи заявки или заключения контракта. Это позволит гарантировать адекватное
определение требований к проекту и возможность выполнить контракт.
При анализе контрактов на ПО могут учитываться различные моменты
взаимодействия с заказчиком, технические соображения, аспекты управления и
факторы обеспечения защиты и конфиденциальности. Например, могут
анализироваться оговоренные с заказчиком критерии принятия или отказа от готовой
системы, терминология, степень участия заказчика в совместной работе,
ответственность заказчика по предоставлению определенных данных или
оборудования, обязательства заказчика перед поставщиком по замене на новые версии
системы или обязательства поставщика поддерживать старые версии и т.д. Здесь же
могут рассматриваться стандарты и процедуры, которые будут использоваться при
разработке программной системы, операционная и аппаратная платформа, требования
к репликации и распределению системы, требования к установке, сопровождению и
поддержке системы и ряд других.

16
 Управление проектированием
Это самый обширный раздел стандарта, поскольку он затрагивает базовую
составляющую общего процесса создания продукта, программного продукта в
частности, решающим образом влияющую на его качество.
Поставщик устанавливает и документирует методики управления и верификации
проекта с целью обеспечения выполнения установленных требований. Этот раздел
стандарта ISO 9000-3 дает руководящие указания по основным действиям в процессе
разработки, таким как анализ требований к проекту, проектирование архитектуры
системы, детальное проектирование и кодирование, а также планирование разработки.
Проект разработки программного продукта организуется в соответствии с
определенной моделью жизненного цикла. ISO 9000-3 не определяет, какой должна
быть модель жизненного цикла, это зависит от специфики решаемой задачи. Стандарт
дает лишь общее определение модели жизненного цикла как множества процессов.
Модель показывает, когда и как эти процессы подключаются к реализации проекта.
Разработка системы − это процесс преобразования исходных требований в
конечный программный продукт. Стандарт оговаривает, что этот процесс должен
проводиться в строго определенном порядке. Это позволит предотвратить появление
ошибок и снизит зависимость от процессов проверки и утверждения как единственных
методов определения проблемных ситуаций. Требование строгой дисциплины
процесса разработки подразумевает наличие и поддержку в рабочем состоянии
документированных процедур, которые послужат гарантией того, что программный
продукт создается в соответствии с заданными требованиями и планами разработки и
обеспечения качества.
Управление проектом должно учитывать такие аспекты, как используемый
метод проектирования и его соответствие конкретной задаче, опыт предыдущих
проектов, требования последующих процессов: тестирования, установки,
сопровождения и использования, наконец, соображения защиты и безопасности. В тех
случаях, когда сбои системы могут нанести ущерб людям, собственности или
окружающей среде, при проектировании должно быть сформулированы специальные
требования, гарантирующие устойчивость системы или ее ответные действия на
потенциальные аварийные ситуации.
Для процессов кодирования должны задаваться правила использования языков
программирования, принципы кодирования и правила составления адекватных
комментариев.
Инструментальные средства и методы, используемые в разработке
программного продукта, такие, например, как системы анализа и проектирования и
компиляторы, должны заранее утверждаться и контролироваться системой
конфигурационного управления. Область применения инструментария должна быть
задокументирована, а его использование периодически анализироваться, дабы выявить
необходимость усовершенствования инструментальных систем или замены на новые
продукты.
Проектирование и разработка должны тщательно планироваться. План
разработки программного продукта формулирует строго документированные действия
по анализу требований к системе, проектированию, кодированию, интеграции,
тестированию, установке и поддержке системы. План разработки должен быть
проанализирован и утвержден.

17
 План разработки включает также связанные с основным процессом планы
обеспечения качества, управления рисками и конфигурацией, планы интеграции,
тестирования, установки, обучения сотрудников и др.
Должны быть определены и задокументированы принципы организационно-
технического взаимодействия между различными группами, участвующими в
разработке. Здесь четко определяются границы ответственности каждого участника
разработки и то, каким образом техническая информация будет передаваться между
участниками. Здесь же оговаривается ответственность заказчика проекта, если он
принимает участие в разработке: необходимость участвовать в проекте, обязательства
по своевременному предоставлению нужной информации. В случае обоюдной
договоренности между поставщиком и заказчиком может быть запланирован
совместный анализ ведения проекта, регулярно или на определенных его этапах. Этот
анализ затрагивает такие факторы, как ход разработки со стороны поставщика, участие
в разработке со стороны заказчика, соответствие системы требованиям заказчика,
результаты проверок, результаты тестирования.
Входные проектные требования к продукции. Требования формулирует
заказчик, а поставщик анализирует, насколько они адекватны. Неполные,
двусмысленные или противоречивые требования являются предметом урегулирования
с лицами, ответственными за их предъявление.
Выходные проектные данные также оформляются документально, причем таким
образом, чтобы их можно было проверить и подтвердить относительно входных
проектных требований. Выходные данные проекта программной системы могут
включать: спецификацию архитектуры проекта, детальную спецификацию проекта,
исходные коды, руководство пользователя.
Поставщик программного продукта должен планировать и проводить
официальный, документально оформленный анализ результатов проектирования.
Анализ проектирования затрагивает такие аспекты, как выполнимость проекта,
удовлетворение требованиям защиты и безопасности системы, выполнение правил
программирования и возможность тестирования.
На определенных стадиях проектирования проводится проверка соответствия
выходных данных входным требованиям. Такая верификация проекта может включать
анализ выходных данных, демонстрации, в том числе с помощью прототипов и
моделирования, или тестирование. Только проверенные выходные проектные данные
утверждаются для окончательного приема и последующего использования. Все
обнаруженные в процессе проверки проблемные ситуации должны адекватно
разрешаться.
Прежде чем система будет передана заказчику, поставщик должен утвердить
систему на соответствие заданному назначению. Заказчику может быть передан только
утвержденный программный продукт.
Все изменения и модификации проекта должны быть идентифицированы,
документально оформлены, проанализированы и утверждены до их реализации.
Поставщик устанавливает и поддерживает в рабочем состоянии процедуры
управления изменениями в проекте, которые могут возникнуть на любой стадии
жизненного цикла системы.

18
 Управление документацией и данными
Поставщик должен разработать и поддерживать в рабочем состоянии
документированные процедуры управления всеми спецификациями и данными,
относящимися к требованиям стандарта ISO 9001, включая и документы внешнего
происхождения (стандарты и чертежи потребителя). Документы и данные могут
размещаться на любом бумажном или электронном носителе.
Для реализации контроля за документами и данными могут использоваться
процедуры управления конфигурацией. В область действия этого раздела стандарта
попадают контракты, специфицирующие требования к продукту; документы,
описывающие систему качества, содержащие различные планы поставщика и
взаимодействие поставщика с потребителем; документы и данные, описывающие
конкретный программный продукт.

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

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

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

19
 Управление процессами
Поставщик должен определить и спланировать процессы разработки, установки
и обслуживания продукта. Процесс разработки программной системы организован как
множество процессов, преобразующих исходные требования в программный продукт
(см. раздел "Управление проектированием"). Раздел стандарта оговаривает требования
к репликации, доставке и инсталляции программных продуктов.

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

Управление несоответствующей продукцией

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

20
изоляция аппаратного компонента, содержащего несоответствующий прикладной
элемент.

Корректирующие и предупреждающие действия

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

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

Этот раздел стандарта ISO 9000-3 конкретизирует специфику возможных
повреждений программного продукта, средства хранения, методы упаковки,
консервации и поставки ПО.
Повреждение программного обеспечения означает изменение его
информационного содержимого. Стандарт оговаривает, что заражение программного
продукта компьютерным вирусом считается повреждением ПО. Меры защиты от
вирусов описываются в руководстве по репликации.
Термин "изнашивание" не применим к той информации, которую содержит
программная система. Однако изнашиваться может носитель, на котором хранится
система, и поставщик должен принять соответствующие меры предосторожности.
Поставщик должен определить систему хранения элементов программного
обеспечения, управления доступом к этим элементам и поддержки версий продукта.
Для того чтобы поддержать целостность системы и обеспечить базис для управления
изменениями элементы программного обеспечения следует хранить в среде, которая
способна защитить их от несанкционированных изменений и обеспечивает
контролируемый доступ и выборку основной и любых других копий. Кроме того,
должны быть учтены условия хранения носителей, в особенности возможное
электромагнитное и электростатическое воздействие.
Возможности консервации элементов программного продукта также потребуют
от поставщика создания определенной системы, которая будет поддерживать,
например, регулярное резервирование, гарантированное копирование ПО на сменный
носитель через определенные промежутки времени, хранение носителей в
защищенной среде и отказоустойчивой среде, позволяющей гарантировать
восстановление в случае катастроф.

Управление регистрацией данных о качестве

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

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

Внутренний аудит качества

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

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

Обслуживание
Что касается программного обеспечения, то обслуживание здесь понимается как
сопровождение системы (maintanance) и поддержка заказчиков (customer support).
Поддержка заказчиков обсуждается в стандарте ISO 9000-2.
Сопровождение системы, как правило, включает в себя обнаружение и анализ
несоответствий в программной системе, вызывающих сбои в ее работе; коррекцию
программных ошибок; модификацию интерфейсов, что необходимо в случае внесения
добавлений или изменений в аппаратуру; функциональное расширение или улучшение
производительности
Все действия по сопровождению должны проводиться и контролироваться в
соответствии с планом сопровождения, который заранее определяется и
согласовывается поставщиком и заказчиком.

Стандарт ISO/IEC 9126

В стандарте ISO 9126 Качество программного обеспечения определяется как
вся совокупность его характеристик, относящихся к возможности удовлетворять
высказанные или подразумеваемые потребности всех заинтересованных лиц.
Первая часть стандарта ISO9126-1 распределяет атрибуты качества
программных средств по шести характеристикам, используемым в остальных частях

22
стандарта. Исходя из принципиальных возможностей их измерения, все
характеристики могут быть объединены в три группы, к которым применимы разные
категории метрик:
− категорийным, или описательным (номинальным) метрикам наиболее
адекватны функциональные возможности программных средств;
− количественные метрики применимы для измерения надежности и
эффективности сложных комплексов программ;
− качественные метрики в наибольшей степени соответствуют практичности,
сопровождаемости и мобильности программных средств.

В части стандарта ISO 9126-1 даются определения с уточнениями из остальных

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

Функциональность (functionality)
Способность ПО в определенных условиях решать задачи, нужные
пользователям. Определяет, что именно делает ПО, какие задачи оно решает.
Функциональная пригодность (suitability). Способность решать нужный набор
задач.
Точность (accuracy). Способность выдавать нужные результаты.
Способность к взаимодействию (interoperability). Способность
взаимодействовать с нужным набором других систем.
Соответствие стандартам и правилам (compliance). Соответствие ПО
имеющимся индустриальным стандартам, нормативным и законодательным актам,
другим регулирующим нормам.
Защищенность (security). Способность предотвращать неавторизированный,
т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к
данным и программам.

23
 Надежность (reliability).
Способность ПО поддерживать определенную работоспособность в заданных
условиях.
Зрелость, завершенность (maturity). Величина, обратная частоте отказов ПО.
Обычно измеряется средним временем работы без сбоев и величиной, обратной
вероятности возникновения отказа за данный период времени.
Устойчивость к отказам (fault tolerance). Способность поддерживать заданный
уровень работоспособности при отказах и нарушениях правил взаимодействия с
окружением.
Способность к восстановлению (recoverability). Способность восстанавливать
определенный уровень работоспособности и целостность данных после отказа,
необходимые для этого время и ресурсы.
Соответствие стандартам надежности (reliability compliance). Этот атрибут
добавлен в 2001 году.

Удобство использования (usability) или практичность.

Способность ПО быть удобным в обучении и использовании, а также
привлекательным для пользователей.
Понятность (understandability). Показатель, обратный к усилиям, которые
затрачиваются пользователями на восприятие основных понятий ПО и осознание их
применимости для решения своих задач.
Удобство обучения (learnability). Показатель, обратный усилиям,
затрачиваемым пользователями на обучение работе с ПО.
Удобство работы (operability). Показатель, обратный усилиям,
предпринимаемым пользователями для решения своих задач с помощью ПО.
Привлекательность (attractiveness). Способность ПО быть привлекательным
для пользователей. Этот атрибут добавлен в 2001 году.
Соответствие стандартам удобства использования (usability compliance). Этот
атрибут добавлен в 2001 году.

Производительность (efficiency) или эффективность.

Способность ПО при заданных условиях обеспечивать необходимую
работоспособность по отношению к выделяемым для этого ресурсам. Можно
определить ее и как отношение получаемых с помощью ПО результатов к
затрачиваемым на это ресурсам всех типов.
Временная эффективность (time behaviour). Способность ПО выдавать
ожидаемые результаты, а также обеспечивать передачу необходимого объема данных
за отведенное время.
Эффективность использования ресурсов (resource utilisation). Способность
решать нужные задачи с использованием определенных объемов ресурсов
определенных видов. Имеются в виду такие ресурсы, как оперативная и
долговременная память, сетевые соединения, устройства ввода и вывода и пр.
Соответствие стандартам производительности (efficiency compliance). Этот
атрибут добавлен в 2001 году.

24
 Удобство сопровождения (maintainability).
Удобство проведения всех видов деятельности, связанных с сопровождение
программ.
Анализируемость (analyzability) или удобство проведения анализа. Удобство
проведения анализа ошибок, дефектов и недостатков, а также удобство анализа
необходимости изменений и их возможных последствий.
Удобство внесения изменений (changeability). Показатель, обратный
трудозатратам на выполнение необходимых изменений.
Стабильность (stability). Показатель, обратный риску возникновения
неожиданных эффектов при внесении необходимых изменений.
Удобство проверки (testability). Показатель, обратный трудозатратам на
проведение тестирования и других видов проверки того, что внесенные изменения
привели к нужным результатам.
Соответствие стандартам удобства сопровождения (maintainability
compliance). Этот атрибут добавлен в 2001 году.

Переносимость (portability).
Способность ПО сохранять работоспособность при переносе из одного
окружения в другое, включая организационные, аппаратные и программные аспекты
окружения.
Иногда эта характеристика называется в русскоязычной литературе
мобильностью.
Адаптируемость (adaptability). Способность ПО приспосабливаться различным
окружениям без проведения для этого действий, помимо заранее предусмотренных.
Удобство установки (installability). Способность ПО быть установленным или
развернутым в определенном окружении.
Способность к сосуществованию (coexistence). Способность ПО
сосуществовать с другими программами в общем окружении, деля с ними ресурсы.
Удобство замены (replaceability) другого ПО данным. Возможность
применения данного ПО вместо других программных систем для решения тех же задач
в определенном окружении.
Соответствие стандартам переносимости (portability compliance). Этот
атрибут добавлен в 2001 году.

Вторая и третья части стандарта ISO 9126-2 и ISO 9126-3 посвящены

формализации соответственно внешних и внутренних метрик характеристик качества
сложных программных средств. Все таблицы содержат унифицированную
рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ
измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для
измерения и сравнения; а также этапы жизненного цикла программного средства (по
ISO 12207), к которым применима метрика.
Четвертая часть стандарта ISO 9126-4 предназначена для покупателей,
поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества
программных средств. В ней обосновываются и комментируются выделенные
показатели сферы (контекста) использования программных средств и группы
выбранных метрик для пользователей.

25
 Эффективность (effectiveness). Способность ПО предоставлять пользователям
возможность решать их задачи с необходимой точностью при использовании в
заданном контексте.
Продуктивность (productivity). Способность ПО предоставлять пользователям
определенные результаты в рамках ожидаемых затрат ресурсов.
Безопасность (safety). Способность ПО обеспечивать необходимо низкий
уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности
или окружающей среде.
Удовлетворение пользователей (satisfaction). Способность ПО приносить
удовлетворение пользователям при использовании в заданном контексте.

В серии стандартов ISO/IEC 14598 определены процессы оценки качества ПП,

содержатся руководство и требования к оценке. Серия применяется при разработке,
приобретении и независимой оценке ПС. Серия состоит из 6-и частей.
В 1-й части ISO/IEC 14598–1:1999 приведен обзор остальных частей, определена
связь серии ISO/IEC 14598 с серией ISO/IEC 9126 и стандартом ISO/IEC 12207:1995. В
этой части представлены общие требования к спецификации и оценке качества,
разъяснены концепции оценки. Установлены требования к методам измерений и
оценки ПП. Определен общий процесс оценки качества ПП. Основой для данного
процесса оценки явился процесс оценки качества ПС из ISO/IEC 9126:1991. В 2011 г.
ISO/IEC 14598–1:1999 заменен на Стандарт ISO/IEC 25040:2011 серии SQuaRE.
Во 2-й части ISO/IEC 14598–2:2000 приводятся концепции планирования и
управления процессом оценки качества программного продукта, рассматривается
содержание плана количественной оценки качества.
Третья – пятая части ISO/IEC14598–3–5:1998–2000 предназначены для
организаций-разработчиков, организаций-заказчиков и оценщиков ПС соответственно.
В этих частях рассмотрены особенности процесса оценки качества ПС при его
выполнении вышеприведенными сторонами.
6-я часть ISO/IEC 14598–6:2001 содержит руководство по документированию
модулей оценки. Модуль оценки представляет собой полностью укомплектованную
информацию, необходимую для проведения процесса оценки некоторой
характеристики или подхарактеристики качества. Модуль содержит спецификацию
соответствующей модели качества (характеристика, подхарактеристики, метрики
качества), процедуры оценки, входные данные для оценки, структуру типового отчета
о результатах выполненной оценки. Рассмотрены примеры модулей оценки.
Дополнением к рассмотренным стандартам могут служить документы,
подготовленные в рамках международного проекта Software Engineering Body of
Knowledge (SWEBOK, например, руководство (Guide))

Серия стандартов SQuaRE разделена на следующие группы (разделы):

ISO/IEC 2500n – группа управления качеством. Стандарты из данной группы
определяют общие модели, термины и определения, которые используются в
остальных стандартах серии SQuaRE. Данная группа стандартов содержит также
руководство по использованию стандартов серии SQuaRE.
ISO/IEC 2501n – группа модели качества. В стандартах данной группы
представлены подробные модели качества для компьютерных систем и программных
продуктов, качества в использовании и качества данных. Данная группа стандартов

26
содержит также практическое руководство по использованию представленных
моделей качества.
ISO/IEC 2502n – группа измерения качества. Стандарты данной группы
включают эталонную модель измерений качества программного продукта,
математические определения мер качества и практическое руководство по их
применению. Даются примеры внутренних и внешних мер качества программных
продуктов и систем, а также мер качества в использовании. Определены и
представлены элементы мер качества, являющиеся основой этих мер.
ISO/IEC 2503n – группа требований к качеству. Стандарты данной группы
помогают определить требования к качеству, основываясь на моделях и мерах
качества. Эти требования к качеству могут использоваться в процессе выявления
требований к качеству разрабатываемого программного продукта или как входные
данные для процесса оценки.

27
 Лекция 16
Управление качеством и надежностью программного обеспечения (ч.2)

Современные модели качества программного обеспечения

Современная индустрия программного обеспечения (ПО) характеризуется очень
высокой степенью конкуренции. Для успешной работы на этом рынке компания должна
разрабатывать, внедрять и сопровождать программное обеспечение быстро, в срок и с
удовлетворительным качеством. Поэтому многие компании вкладывают деньги в
улучшение качества процесса, памятуя о том, что подобное вложение денег обязательно
окупается.
Существуют десятки различных подходов к обеспечению качества ПО, и у всех
есть свои преимущества. Одной из первых моделей качества стал стандарт ISO
(Международной организации по стандартизации) серии 9000, первая версия которого
была выпущена в 1987 году. С тех пор сертификаты ISO серии 9000 сохраняют
неизменную популярность и признаются во всем мире.
Однако время не стоит на месте, и методики, положенные в основу стандартов
серии ISO 9000, постепенно устаревают.
Выделим наиболее существенные недостатки:
− недостаточная подробность стандарта, возможность самых различных его
толкований в зависимости от представлений аудитора;
− неточность оценки качества процессов, задействованных при создании и
внедрении программного обеспечения;
− отсутствие в стандарте механизмов, способствующих улучшению
существующих процессов.
Перечисленные проблемы заставили экспертов разрабатывать более совершенные
решения в области обеспечения качества, что привело к созданию в начале 90-х годов
целого ряда новых стандартов и методологий.
Мы рассмотрим два наиболее удачных и содержательных стандарта – Capability
Maturity Model (CMM) и ISO/IEC 15504 (SPICE).

Capability Maturity Model

Официальная история CMM (Capability Maturity Model Intagration, что обычно
переводят как "модель зрелости процесса разработки ПО", хотя более верным по смыслу
был бы перевод "модель совершенствования возможностей") начинается в 1991 году,
когда американский институт SEI (Software Engineering Institute – Институт системного
программирования при университете Карнеги-Меллон) опубликовал первую версию
этого стандарта.
Изначальной целью разработки стандарта было создание методики, позволяющей
крупным правительственным организациям США выбирать наилучших поставщиков
ПО. Для этого предполагалось создать исчерпывающее описание способов оценки
процессов разработки ПО и методики их дальнейшего усовершенствования. В
результате, авторам удалось добиться такой степени подробности и детализации, что
стандарт оказался пригодным и для обычных компаний-разработчиков, желающих
улучшить существующие процессы.
Главным понятием стандарта является зрелость организации. Незрелой считается
организация, в которой процесс разработки программного обеспечения зависит только
от конкретных исполнителей и менеджеров, и решения зачастую просто

1
импровизируются "на ходу". В этом случае велика вероятность превышения бюджета
или заваливания сроков сдачи проекта, и потому менеджеры вынуждены заниматься
только разрешением ближайших проблем.
С другой стороны, в зрелой организации имеются четко определенные процедуры
создания программных продуктов и управления проектами. Эти процедуры по мере
необходимости уточняются и совершенствуются в пилотных проектах или с помощью
анализа стоимость/прибыль. Оценки времени и стоимости выполнения работ
основываются на накопленном опыте и достаточно точны. Наконец, в компании
существуют стандарты на процессы разработки, тестирования и внедрения ПО, правила
оформления конечного программного кода, компонент, интерфейсов и т.д. Все это
составляет инфраструктуру и корпоративную культуру, поддерживающую процесс
разработки программного обеспечения.
Таковы базовые посылки стандарта CMM. Можно сказать, что стандарт в целом
состоит из критериев оценки зрелости организации и рецептов улучшения
существующих процессов. В этом наблюдается принципиальное различие с моделью,
принятой в ISO 9001, так как в ISO 9001 сформулированы только необходимые условия
для достижения некоторого минимального уровня организованности процесса, и не
дается никаких рекомендаций по дальнейшему совершенствованию процессов.
В модели CMM определено пять уровней зрелости организаций. В результате
аттестации компании присваивается определенный уровень, который в дальнейшем
может повышаться или (теоретически) понижаться.

На рисунке перечислены некоторые технологии, внедрение которых необходимо

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

Пять уровней зрелости в модели CMM.

Начальный уровень (initial level) описан в стандарте в качестве основы для

сравнения со следующими уровнями. На предприятии начального уровня организации
не существует стабильных условий для созданий качественного программного
обеспечения. Результат любого проекта целиком и полностью зависит от личных
2
качеств менеджера и опыта программистов, причем успех в одном проекте может быть
повторен только в случае назначения тех же менеджеров и программистов на
следующий проект. Более того, если такие менеджеры или программисты уходят с
предприятия, то с их уходом резко падает качество производимых программных
продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и
его минимальному тестированию.

Для достижения повторяемого уровня (repeatable level) на предприятии должны

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

Далее следует определенный уровень (defined level), который характеризуется

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

На управляемом уровне (managed level) в организации устанавливаются

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

Наконец, оптимизирующий уровень (optimizing level) характеризуется тем, что

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

3
 1. Заинтересованность руководства в данной области (планируется ли
практическое внедрение данной ключевой области, существует ли понимание у
руководства необходимости данной области и т.д.).
2. Насколько широко данная область применяется в организации (например,
оценке в 4 балла соответствует фрагментарное применение).
3. Успешность использования данной области на практике (например, оценке в 0
баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов
выставляется при наличии систематического и измеримого положительного результата
практически во всей организации).
В принципе, можно сертифицировать только один процесс или подразделение
организации, например, подразделение разработки программного обеспечения
компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем
немного компаний, которые могут похвастаться наличием у них пятого уровня CMM
хотя бы в одном из подразделений – таких всего около 50. С другой стороны,
насчитывается несколько тысяч компаний, сертифицированных по 3 или 4 уровню.
Свыше 70% всех компаний-разработчиков находится на первом уровне CMM.
Интересен вопрос о соотношении уровней CMM со стандартом ISO 9001: на каком
уровне CMM должна находиться организация, чтобы получить сертификат
соответствия ISO 9001? На первый взгляд, для этого необходимо иметь как минимум 3
или 4 уровень CMM. Тем не менее, существуют примеры организаций 1-го уровня,
имеющих сертификат ISO 9001. Одной из причин для возникновения подобных
несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим свобода
его интерпретации аудитором.
Естественно, особенно важен подбор сотрудников для организаций первого
уровня, так как сотрудники для них являются единственной гарантией качества. Но и на
более высоких уровнях зрелости "человеческий фактор" сохраняет свою значимость.
Поэтому в 1995 году был опубликован стандарт People CMM, являющийся дополнением
к Software CMMI и имеющий, в целом, похожую структуру. Внедрение этого стандарта
параллельно с обычным CMM обеспечивает организацию целым набором процедур по
оценке и развитию всей системы найма, обучения и сохранения квалифицированных
сотрудников.
Кроме People CMM, возникло еще несколько моделей, дополняющих CMM,
например, в приобретении ПО или разработке крупных систем. В целях полной
интеграции этих моделей и снижения общих затрат по их внедрению, был предпринят
проект CMM Integration (ради его выполнения в 1998 году был даже отменен выпуск
CMM версии 2.0).
К сожалению, использование CMM затрудняют следующие проблемы:
• стандарт CMM является собственностью Software Engineering Institute и не
является общедоступным (в частности, дальнейшая разработка стандарта ведется самим
институтом, без заметного влияния остальной части программистского сообщества);
• оценка качества процессов организаций может проводиться только
специалистами, прошедшими специальное обучение и аккредитованными SEI;
• стандарт ориентирован на применение в относительно крупных компаниях;

4
 SPICE – оценка и аттестация зрелости процессов создания и сопровождения
программных средств и информационных систем.
В 1991 году Международная организация по стандартизации инициировала
работу по созданию единого стандарта оценки программных процессов. Стандарт
получил имя SPICE (сокращение от Software Process Improvement and Capability
dEtermination, определение возможностей и улучшение процесса создания
программного обеспечения). Официально стандарт называется "ISO/IEC 15504:
Information Technology − Software Process Assessment.
Задачей SPICE является создание международного стандарта, в котором был бы
учтен весь накопленный опыт в области разработки ПО.

На рисунке показаны наиболее значительные стандарты, идеи которых были

использованы при создании SPICE:

Предшественники стандарта SPICE.

Итак, стандарт SPICE унаследовал многие черты более ранних стандартов, в том
числе и уже упоминавшихся ISO 9001 и CMM. Для этого пришлось прибегнуть к
повышению уровня детализации стандарта. Следствием такого основательного подхода
является большой объем стандарта: документация к нему содержит около 500 страниц!
Больше всего SPICE напоминает CMM. Точно так же, как и в CMM, основной
задачей организации является постоянное улучшение процесса разработки ПО. Кроме
того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE
определено 6 различных уровней), но эти уровни применяются не только к организации
в целом, но и к отдельно взятым процессам.

5
 В таблице приведен список уровней способностей модели SPICE и характерные
для них процедуры управления. На данный момент не существует русского перевода
стандарта SPICE, поэтому использованные термины не являются общепринятыми
или официально зарегистрированными

Уровни Название
Уровень 0 Процесс не выполняется
Уровень 1 Выполняемый процесс
1.1 Измерение производительности процесса
Уровень 2 Управляемый процесс
2.1 Управление производительностью
2.2 Управление созданием продуктов
Уровень 3 Установленный процесс
3.1 Документирование процесса
3.2 Отслеживание ресурсов процесса
Уровень 4 Предсказуемый процесс
4.1 Измерение процесса
4.2 Управление процессом
Уровень 5 Оптимизирующий процесс
5.1 Изменение процесса
5.2 Постоянное совершенствование
Уровни способностей процесса в стандарте SPICE

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

образом:

Упрощенная модель оценки процессов в стандарте SPICE

Здесь Pn обозначает процессы, а CL (Capability Levels) обозначает уровни

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

6
 Во время оценки и улучшения качества процессов выполняются следующие
задачи:

Основные элементы стандарта SPICE.

1. Оценка процесса происходит путем сравнения процесса разработки ПО,

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

Структура документации по стандарту SPICE.

Набор документов по SPICE состоит из 9 частей. Первая часть "Введение и
основные концепции" и девятая часть "Словарь" носят чисто информативный характер.
Самым важным элементом SPICE является оценка процессов, поэтому ей посвящена
наибольшая часть документов, а именно части со второй по шестую. Например, вторая
часть стандарта содержит так называемую "эталонную модель" (reference model),
которая описывает процессы. Практически, это модель процессов из ISO 12297, хотя эти
модели не полностью идентичны.
Остальные части стандарта – седьмая и восьмая – посвящены соответственно
улучшению процесса, и определению возможностей процесса.
Одним из важных достоинств SPICE является его открытость и свободное
распространение.

7
 Преимущества SPICE по сравнению с ISO 9001.

SPICE ISO 9001

Объемный и подробный документ Краткий документ
Детальная модель Абстрактная модель
Улучшение процесса и определение Только сертификация
возможностей
Шесть уровней возможностей Сертификация/отказ
процессов
Требования к оценке процесса, Только модель
руководство по применению
Дополняет ISO 9001 Может быть детализирован с
помощью SPICE
Сравнение стандартов SPICE и ISO 9001

SPICE предоставляет более полный набор средств по обеспечению качества и

улучшению процессов, чем ISO 9001. Поэтому для обеспечения качества процессов
разработки ПО рекомендуется использовать именно SPICE. Это поможет организации
заметно улучшить существующие процессы, а затем при необходимости получить и
сертификат ISO 9001.
Использовать SPICE можно и в небольших компаниях – об этом свидетельствуют
результаты работы проекта SPIRE, в рамках которого проводилось внедрение процессов
улучшения качества в малых (менее 50 человек) компаниях из различных стран Европы.
Как показал этот опыт, и при небольших денежных вложениях в маленьких компаниях
можно добиться существенного увеличения производительности труда и улучшения
качества произведенных продуктов.

Управление качеством программного обеспечения (SQM, Software Quality

Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM
определяет процессы, владельцев процессов, а также требования к процессам,
измерения процессов и их результатов, плюс – каналы обратной связи.
Процессы управления качеством содержат много действий. Некоторые из них
позволяют напрямую находить дефекты в то время, как другие помогают определить,
где именно может быть важно провести более детальные исследования, после чего,
опять-таки, проводятся работы по непосредственному обнаружению ошибок. Многие
действия также могут вестись с целью достижения и тех и других целей.
SQM может использоваться для оценки и конечных и промежуточных продуктов.
Некоторые из специализированных процессов SQM определены в стандарте 12207:
• Процесс обеспечения качества (quality assurance process);
• Процесс верификации (verification process);
• Процесс аттестации (validation process);
• Процесс совместного анализа (оценки) (joint review process);
• Процесс аудита (audit process).

Все эти процессы поддерживают стремление к достижению качества и, кроме

того, помогают в поиске возможных ошибок.

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

Обеспечение (подтверждение) качества программного обеспечения (Software

Quality Assurance, SQA)
Software Quality Assurance (SQA) – это комплекс мероприятий, направленных на
обеспечение качества процессов разработки программного обеспечения, которые в
конечном итоге приводят к качественным программным продуктам. Деятельность
устанавливает и оценивает процессы, которые производят продукты.

Другими словами, процессы SQA обеспечивают подтверждение того, что

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

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

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

9
 Проверка (верификация) и аттестация (валидация) программного
обеспечения – упорядоченный подход в оценке программных продуктов, применяемый
на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по
проверке и аттестации, направлены на обеспечение качества как неотъемлемой
характеристики программного обеспечения и удовлетворение пользовательских
требований.
Проверка и аттестация ПО напрямую адресуется вопросам качества
программного обеспечения и использует соответствующие техники тестирования для
обнаружения тех или иных дефектов, может применяться для промежуточных
продуктов, однако, в том объеме, который соответствует промежуточным шагам
соответствующих процессов жизненного цикла.
Верификация – попытка обеспечить правильную разработку продукта (продукт
построен правильным образом; обычно, для промежуточных, иногда, для конечного
продукта), в том значении, что получаемый в рамках соответствующей деятельности
продукт соответствует спецификациям, заданным в процессе предыдущей
деятельности.
Аттестация (валидация) – попытка обеспечить создание правильного продукта
(построен правильный продукт; обычно, в контексте конечного продукта), с точки
зрения достижения поставленной цели.
Оба процесса – верификация и аттестация – начинаются на ранних стадиях
разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых
возможностей продукта как в контексте непосредственно предшествующих результатов
(промежуточных продуктов), так и с точки зрения удовлетворения соответствующих
спецификаций. Целью планирования проверки и аттестации ПО является обеспечение
процессов верификации и аттестации необходимыми ресурсами, четкое назначение
ролей и обязанностей. Получаемый план документирует и детально описывает
различные ресурсы, роли и действия, а также используемые техники и инструменты.
План также касается аспектов управления, коммуникаций (взаимодействия),
политик и процедур в отношении действий по верификации и аттестации и их
взаимодействия. Кроме того, в нем могут быть отражены вопросы формирования
отчетности по дефектам и документирования требований.

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

результатов какой-либо работы. Данный процесс может использоваться двумя любыми
сторонами, когда одна из сторон (проверяющая) проверяет другую сторону
(проверяемую) на совместном совещании.
Данный процесс состоит из следующих работ:
1) подготовка процесса;
2) анализы управления проектом;
3) технические анализы.

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

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

Анализы управления проектом

Состояние проекта должно быть оценено на соответствие проектным планам,
графикам, стандартам и руководствам. Итоговый результат анализа должен быть
обсужден между двумя участвующими сторонами и должен включать:
a) предложения по активизации работ в соответствии с планом, основанные на
оценке состояний работ или программных продуктов;
b) предложения по проведению общего контроля проекта посредством
соответствующего перераспределения ресурсов;
c) предложения по изменению хода проекта или определению потребности в
перепланировании проекта;
d) предложения по оценке и управлению критическими ситуациями, могущими
угрожать успешному ходу проекта.

Технические анализы
Должны быть проведены технические анализы для оценки создаваемых
программных продуктов или услуг с точки зрения их просмотра и представления
доказательств того, что:
a) они полностью реализованы на данный момент;
b) они соответствуют принятым стандартам и техническим требованиям;
c) изменения к ним выполнены должным образом и влияют только на те области,
которые определены процессом управления конфигурацией
d) они полностью придерживаются установленных графиков работ;
e) они готовы к последующим работам;
f) их разработка, эксплуатация или сопровождение проводятся в соответствии с
проектными планами, графиками, стандартами и руководствами.

Оценка (обзор) и аудит (Review and Audits)

Пять типов оценок и аудитов:
• Управленческие оценки (management reviews)
• Технические оценки (technical reviews)
• Инспекции (inspections)
• Прогонки (walk-throughs)
• Аудиты (audtis)

11
 Управленческие оценки (Management Reviews)
Назначение управленческих оценок состоит в отслеживании развития
проекта/продукта, определения статуса планов и расписаний, утверждения требования
и распределения ресурсов, или оценки эффективности управленческих подходов,
используемых для достижения поставленных целей.
Управленческие оценки поддерживают принятие решений о внесении изменений
и выполнении корректирующих действий, необходимых в процессе выполнения
программного проекта.
Управленческие оценки определяют адекватность планов, расписаний и
требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки
могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита,
отчетов о состоянии (развитии), отчетов проверки и аттестации, а также различных
типов планов – управления рисками проекта/проектного управления,
конфигурационного управления, безопасности использования программного
обеспечения, оценки рисков и т.п.

Технические оценки (Technical Reviews)

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

Техническая оценка требует, в обязательном порядке, наличия следующих

входных данных:
• Формулировки целей
• Конкретного программного продукта (подвергаемого оценке)
• Заданного плана проекта (плана управления проектом)
• Списка проблем (вопросов), ассоциированных с продуктом
• Процедуры технической оценки

Команда технической оценки следует заданной процедуре оценки.

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

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

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

Инспекции (Inspections)
Назначение инспекций состоит в обнаружении и идентификации аномалий в
программном продукте.
Существует два серьезных отличия инспекций от оценок (управленческой и
технической):

12
 1. Лица, занимающие управленческие позиции (менеджеры) в отношении к
любым членам команды инспектирования, не должны участвовать в инспекциях.
2. Инспекция должна вестись под руководством непредвзятого (независимого от
проекта и его целей) лидера, обученного техникам инспектирования.
Инспектирование программного обеспечения всегда вовлекает авторов
промежуточного или конечного продукта, в отличие от оценок, которые не требуют
этого в обязательном порядке.
Инспекции (как временные организационные единицы – группы, команды)
включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов.
Члены команды инспектирования могут специализироваться в различных
областями экспертизы (обладать различными областями компетенции), например,
предметной области, методах проектирования, языке и т.п.
В заданный момент (промежуток) времени инспекции проводятся в отношении
отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на
отдельных функциональных или других характеристиках; часто, отталкиваясь от
отдельных бизнес-правил, функциональных требований или атрибутов качества).
Каждый член команды должен исследовать программный продукт и другие
входные данные до проведения инспекционной встречи, применяя, возможно, те или
иные аналитические техники к небольшим фрагментам продукта или к продукту, в
целом, рассматривая в последнем случае только один его аспект, например,
интерфейсы. Любая найденная аномалия должна документироваться, а информация
передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией
инспекции и проверяет, что все члены команды подготовились к инспектированию.

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

проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами
программного продукта, вызывающими интерес. Результирующий лист часто
классифицирует аномалии и оценивается командой с точки зрения его завершенности и
точности.
Решение о завершении инспекции принимается в соответствии с одним (любым)
из трех критериев:
1. Принятие продукта с отсутствием либо малой необходимостью переработки
2. Принятие продукта с проверкой переработанных фрагментов
3. Необходимость повторной инспекции
Инспекционные встречи занимают, обычно, несколько часов, в отличие от
технической оценки и аудита, предполагающих, в большинстве случаев, больший объем
работ и, соответственно, длящиеся дольше.

Прогонки (Walk-throughs)
Назначение прогонки состоит в оценке программного продукта. Прогонка может
проводиться с целью ознакомления (обучения) аудитории с программным продуктом.
Главные цели прогонки состоят в:
• Поиске аномалий
• Улучшении продукта
• Обсуждении альтернативных путей реализации
• Оценке соответствия стандартам и спецификациям

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

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

SQM-процессы обеспечивают нахождение дефектов.

Дефект – обобщенный критерий, определяющий любое отклонение от
установленных для проекта стандартов качества. Например, недостаток
функциональности или лишняя функциональность — дефект; неудобный интерфейс —
дефект; плохой дизайн или грязный код, который негативно скажется на
сопровождаемости — дефект; неприемлемая производительность — дефект;
некорректная работа программы — частный случай дефекта; орфографическая ошибка
в документации — дефект.
Дефекты можно классифицировать по следующим параметрам:
• тип (определяется фазой разработки или активностью, на которой был
внесен дефект);
• критичность (насколько критично наличие дефекта в программном
продукте);
• приоритет (насколько важно исправить дефект);
• сложность (насколько трудоемко исправить дефект);
• и т.д.
Имея подобный обобщенный показатель, становится проще оценивать и
анализировать качество разрабатываемого программного продукта, а также качество
самого процесса разработки. Можно считать количество дефектов или сумму их весов
(по какому-либо параметру), можно оценивать плотность дефектов на единицу объема
продукта, анализировать, какие фазы процесса являются наиболее проблемными и т.д.,
сведя борьбу за качество к борьбе с дефектами. Можно нарисовать график изменения
количества дефектов в проекте с течением времени.

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

Эффективность поиска дефектов

Рассмотрим, например, фазу системного тестирования, в ходе которой
обнаруживается некое количество дефектов Dfound, но сколько-то дефектов остается
ненайденным на момент завершения фазы Dmissed (см. рисунок). Общее число дефектов,
прошедших через фазу, будет равно Dfound + Dmissed.

15
 Отношение найденных дефектов к их общему числу, выраженное в процентах,
назовем эффективностью поиска дефектов — это одна из основных характеристик
качества процесса разработки, которую необходимо постоянно контролировать.
Для каждой фазы, в ходе которой находятся и исправляются дефекты, при
стабильном и предсказуемом процессе и прочих равных условиях эту величину можно
считать приблизительно постоянной, что позволяет количественно оценивать уровень
качества (выраженный в количестве ненайденных дефектов) для текущего и для
планируемых проектов.
Эффективность поиска дефектов можно рассматривать как для отдельных фаз, так
и для всего жизненного цикла разработки. При этом эффективности отдельных фаз
определяют эффективность для всего жизненного цикла.
Каждую фазу поиска дефектов можно рассматривать как своего рода фильтр,
который удерживает некую часть дефектов, а весь жизненный цикл — как систему
фильтров. Если на ранних этапах жизненного цикла стоят плохие фильтры, которые
пропускают много дефектов, то эти дефекты накапливаются, и, чтобы их хорошо
отфильтровать, в конце жизненного цикла (фаза тестирования) будет необходим очень
хороший фильтр.
Дефекты со временем имеют тенденцию не только накапливаться, если не
предпринимать ранних мер по их устранению, но и увеличивать стоимость их
исправления, причем часто эта зависимость— экспоненциальная.

Для водопадной модели жизненного цикла эта зависимость хорошо

иллюстрируется графиком.

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

только надписи: вместо названий фаз будут номера итераций.

Комплексный подход к управлению качеством

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

16
всего жизненного цикла проекта. Кроме того, надо принять все меры по
предотвращению или недопущению дефектов.
Применение методов поиска дефектов на протяжении всего жизненного цикла
проекта поднимает кривую найденных дефектов вверх, а применение методов
предотвращения дефектов опускает кривую вносимых дефектов вниз (рис. 4).

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

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

Методы поиска и предотвращения дефектов

Известно немало методов поиска дефектов.
• Ручной анализ, или обзор разрабатываемых артефактов. Персональные
проверки, формальные инспекции, групповые обзоры, парное программирование,
групповое проектирование и т.п.
• Автоматическая статическая проверка. Компиляция (помимо явных
дефектов компилятор умеет находить неявные), статический анализ кода с помощью
специальных анализаторов, проверка на соблюдение принятого код-стандарта и стиля.
• Автоматизированное тестирование. Модульное или блочное
тестирование, функциональное (комплексное) тестирование, тестирование
графического интерфейса пользователя, тестирование производительности, стресс-
тестирование, использование утверждений и т.д.
• Ручное тестирование. Интеграционное, системное, сравнительное,
верификация требований, «охота за ошибками», пошаговая трассировка и т.д.

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

Вряд ли возможно разрабатывать ПО вообще без дефектов, но попытаться

уменьшить число вносимых дефектов стоит попробовать.
Наиболее известные методы предотвращения дефектов.
• Прототипирование. Создание и опробование модели разрабатываемой
системы с целью проверить ее характеристики и выявить неверные предположения и
решения, которые могли бы привести к серьезным дефектам (и переделкам) при
разработке.
• Использование стандартов на все виды продуктов, производимых в
ходе разработки ПО (требования, дизайн, код, различная документация и т.д.).
• Применение компонентного подхода.
• Использование готовых компонентов — чем меньше приходится
разрабатывать новых решений, тем меньше ошибок.
• Предварительная разработка тест-кейсов (до этапа кодирования)
позволяет глубже понять требования к разрабатываемой системе и лучше
спроектировать ее.
• Рефакторинг кода, то есть приведение его в надлежащий вид.
• Регулярный анализ причин появления наиболее серьезных дефектов и
поиск путей устранения этих причин. Это может происходить на периодических
собраниях команды разработчиков, или можно проводить такой анализ для каждого
серьезного дефекта, найденного на этапах системного тестирования или после
внедрения. Результатом такого анализа должны быть модификации процесса
разработки, направленные на устранение причин появления дефектов или, как
минимум, способствующие более раннему обнаружению подобных дефектов.
Стоит также упомянуть человеческий фактор — никакие методы не заменят
профессионализм и опыт разработчиков и менеджеров. Опытные профессионалы, как
правило, делают меньше ошибок, что дает хороший задел для качественной разработки.

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

методов его повышения — необходимо их осознанное систематическое применение,
которое стало бы неотъемлемой частью процесса разработки ПО, ориентированного на
качество. Необходим постоянный контроль качества разрабатываемого ПО через
метрики качества (плотность дефектов, размер переделок, среднее время между
отказами и др.), а также контроль качества отдельных подпроцессов, составляющих
целостный процесс разработки.
Методы, которые хорошо работали вчера, сегодня могут представлять собой
пустую трату времени. У каждого проекта может быть своя специфика, требующая
иного набора методов повышения качества. Например, одни проекты (особо критичные)
могут потребовать тщательнейшего тестирования всех тест-кейсов, в других (когда
тестирование очень трудоемко) больше внимания следует уделять инспекциям, третьи
(инновационные) потребуют предварительного прототипирования, четвертые
(критичные к ресурсам) потребуют стресс-тестирования и т.д. Если постоянно не
контролировать эффективность методов, то со временем она может значительно
снизиться.

18
 Пример управления качеством ПО
Компания CQG является одним из поставщиков биржевой информации и
программных продуктов для биржевой торговли.
В компании используются следующие методы повышения качества ПО:
– Персональные проверки.
– Обязательные формальные инспекции всех артефактов (требования, архитектура,
проектные модели, тест-планы, код).
– Автоматизированное модульное тестирование.
– Различные виды тестирования вручную (интеграционное, системное, релиз,
верификация требований, «охота за ошибками»).
– Автоматизированное функциональное тестирование (для некоторых систем).
– Обязательные стандарты на все артефакты: планы проектов, требования, дизайн,
тест-планы, код.
– Прототипирование на самых ранних стадиях проектов.
– Регулярные собрания команд разработчиков с целью анализа причин появления
наиболее серьезных дефектов и поиска путей устранения этих причин.
– Контроль качества процесса и проектов осуществляется регулярно с помощью
следующих метрик.
– Плотности дефектов на 1000 строк кода, найденных на разных стадиях, таких как
инспекции кода, интеграционное, системное, релиз-тестирование.
– Эффективность инспекций (плотность найденных замечаний, скорость проверки,
процент найденных дефектов, покрытие кода инспекциями).
– Процент переделок (размер кода для исправления дефектов по отношению к
общему числу разработанного кода).
– Покрытие кода юнит-тестами.
– Покрытие кода формальными требованиями.
– При планировании каждого проекта обязательно составляется план качества,
отражающий особенности проекта с точки зрения обеспечения качества. В этом плане
приводится перечень необходимых методов контроля качества, определенные параметры
этих методов и ожидаемые характеристики качества будущего продукта, которых
следует достигнуть.
Использование разнообразных методов повышения качества и регулярный контроль
качества процесса позволяет компании обходиться довольно малым количеством
тестировщиков по отношению к количеству разработчиков. При этом основной целью
работы отдела тестирования является не поиск дефектов в разработанном ПО, а
проверка его высокого качества.
Все новые разработчики, приходящие в компанию, проходят через обязательные
тренинги по процессам, методам и стандартам, принятым в компании, а также по
используемым инструментам автоматизации управления разработкой программного
обеспечения.

19
 Лекция 17
Тестирование программного обеспечения (ч.1)

В проектах по разработке программного обеспечения (ПО) помимо основной

задачи по реализации заявленной функциональности существует не менее важная
задача по обеспечению качества ПО.
Одним из устоявшихся способов контроля качества является тестирование.
Тестирование ПО (Software testing) — проверка соответствия между реальным
и ожидаемым поведением программы, осуществляемая на конечном наборе тестов,
выбранном определенным образом.
Тест – это набор входных значений, условий выполнения и ожидаемых значений
на выходе, разработанных для проверки конкретного пути выполнения программы
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых
результатов и постусловий выполнения, разработанный для определённой цели или
тестового условия, таких как выполнения определённого пути программы или же для
проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить,
для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное
описание содержит: действия, которые надо выполнить до начала проверки —
предусловия; действия, которые надо выполнить для проверки — шаги; описание того,
что должно произойти, после выполнения действий для проверки — ожидаемый
результат.

Эволюция представлений о тестировании

На протяжении десятилетий развития разработки ПО к вопросам тестирования и
обеспечения качества подходили очень и очень по-разному. Можно выделить
несколько основных «эпох тестирования».

В 50–60-х годах прошлого века процесс тестирования был предельно

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

В 70-х годах фактически родились две фундаментальные идеи тестирования:

тестирование сначала рассматривалось как процесс доказательства работоспособности
программы в некоторых заданных условиях (positive testing), а затем — строго
наоборот: как процесс доказательства неработоспособности программы в некоторых
заданных условиях (negative testing). Это внутреннее противоречие не только не
исчезло со временем, но и в наши дни многими авторами совершенно справедливо
отмечается как две взаимодополняющие цели тестирования.
Стоит отметить, что «процесс доказательства неработоспособности программы»
ценится чуть больше, т.к. не позволяет закрывать глаза на обнаруженные проблемы.

1
 В 80-х годах произошло ключевое изменение места тестирования в разработке
ПО: вместо одной из финальных стадий создания проекта тестирование стало
применяться на протяжении всего цикла разработки (software lifecycle), что позволило
в очень многих случаях не только быстро обнаруживать и устранять проблемы, но
даже предсказывать и предотвращать их появление.
В этот же период времени отмечено бурное развитие и формализация
методологий тестирования, и появление первых элементарных попыток
автоматизировать тестирование.

В 90-х годах произошёл переход от тестирования как такового к более

всеобъемлющему процессу, который называется «обеспечение качества (quality
assurance)», охватывает весь цикл разработки ПО и затрагивает процессы
планирования, проектирования, создания и выполнения тест-кейсов, поддержку
имеющихся тест-кейсов и тестовых окружений. Тестирование вышло на качественно
новый уровень, который естественным образом привёл к дальнейшему развитию
методологий, появлению достаточно мощных инструментов управления процессом
тестирования и инструментальных средств автоматизации тестирования, уже вполне
похожих на своих нынешних потомков.

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

контексте поиска всё новых и новых путей, методологий, техник и подходов к
обеспечению качества. Серьёзное влияние на понимание тестирования оказало
появление гибких методологий разработки и таких подходов, как «разработка под
управлением тестирования (test-driven development, TDD)».
Автоматизация тестирования уже воспринималась как обычная неотъемлемая
часть большинства проектов, а также стали популярны идеи о том, что во главу
процесса тестирования следует ставить не соответствие программы требованиям, а её
способность предоставить конечному пользователю возможность эффективно решать
свои задачи.

Основные характеристики тестирования на современном этапе развития:

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

Стоимость ошибок
Зачем нужно тестировать ПО? Для компании, создающей программные
продукты, ошибка в программе − это экономические потери:
1) расходы компании на тестирование и отладку программы. Расходы такого
типа поддаются приблизительной оценке;
2) убытки, которые несет компания от того, что ошибка не была найдена
вовремя. В большинстве случаев оценить потери от ошибок такого рода невозможно.

2
 В первом случае, если программа содержала ошибку, и эта ошибка была
обнаружена в процессе тестирования, стоимость ошибки вычисляется как суммарные
затраты следующих составляющих:
1) оплата времени работы специалиста по тестированию;
2) оплата времени работы программиста, который реализовал модуль,
содержащий ошибку, а затем исправил ее;
3) стоимость реализации "неправильного" модуля;
4) стоимость тестирования "неправильного" модуля;
5) стоимость исправления ошибки и проблем, появившихся из-за ее наличия.
Очевидно, слагаемые поддаются приблизительной оценке.

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

формуле предыдущего случая, могут прибавиться другие убытки, например:
1) время службы поддержки;
2) компенсации пользователю понесенных затрат;
3) иски против компании;
4) утраченная потенциальная оплата услуг компании ушедшими пользователями
и пользователями, которые могли бы стать клиентами компании, но не стали ими из-за
ухудшения репутации.
Такие убытки, как правило, не поддаются объективной оценке.

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

пользователи, а иногда даже люди, которые не имеют совершенно никакого
отношения к программе.
Часто в качестве примера ПО с наиболее губительными последствиями
эксплуатации приводятся катастрофа Ariane 5 и инциденты с Therac-25.
Ariane 5 − ракета-носитель, запуск которой был произведен 4 июня 1996 года.
Полет продлился неполные 40 сек., после чего произошел взрыв.
Из-за ошибок в программной части медицинского комплекса Therac-25 минимум
шесть человек получили передозировки радиации, некоторые пациенты получили
дозы в десятки тысяч рад (рад — внесистемная единица измерения поглощённой дозы
ионизирующего излучения). Как минимум двое умерли непосредственно от
передозировок.
В истории РФ также были примеры катастрофических последствий ошибок в
программном обеспечении. Например, 5 декабря 2010 года три спутника, критически
важные для завершения составления группировки российской навигационной системы
ГЛОНАСС упали в Тихий океан недалеко от Гавайских островов вскоре после их
запуска ракетой "Протон-М". Финансовые потери оцениваются в 4 миллиарда рублей.
В результате расследования виной аварии была признана ошибка в программировании,
которая привела к тому, что в ракету залили неправильное количество топлива.
Такие глобальные катастрофы являются редкими, чаще потери от ошибок носят
исключительно финансовый характер. Однако, если учесть тот факт, что 45,1%
ошибок находят пользователи, то сумма потерь становится колоссальной.

Причины и источники ошибок программного обеспечения

В краткой классификации выделяются следующие ошибки.
− Ошибки пользовательского интерфейса.

3
 − Ошибки вычислений.
− Ошибки управления потоком.
− Ошибки передачи или интерпретации данных.
− Перегрузки.
− Контроль версий.
− Ошибка выявлена и забыта.
− Ошибки тестирования.

Ошибки пользовательского интерфейса.

Многие из них субъективны, т.к. часто они являются скорее неудобствами, чем
«чистыми» логическими ошибками. Однако они могут провоцировать ошибки
пользователя программы или же замедлять время его работы до неприемлемой
величины. В результате чего мы будем иметь ошибки информационной системы (ИС)
в целом. Основным источником таких ошибок является сложный компромисс между
функциональностью программы и простотой обучения и работы пользователя с этой
программой. Проблему надо начинать решать при проектировании системы на уровне
ее декомпозиции на отдельные модули, исходя из того, что вряд ли удастся
спроектировать простой и удобный пользовательский интерфейс для модуля,
перегруженного различными функциями. Кроме того, необходимо учитывать
рекомендации по проектированию пользовательских интерфейсов. На этапе
тестирования ПО полезно предусмотреть встроенные средства тестирования, которые
бы запоминали последовательности действий пользователя, время совершения
отдельных операций, расстояния перемещения курсора мыши. Кроме этого возможно
применение гораздо более сложных средств психо-физического тестирования на этапе
тестирования интерфейса пользователя, которые позволят оценить скорость реакции
пользователя, частоту этих реакций, утомляемость и т.п. Необходимо отметить, что
такие ошибки очень критичны с точки зрения коммерческого успеха разрабатываемого
ПО, т.к. они будут в первую очередь оцениваться потенциальным заказчиком.

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

Ошибки управления потоком

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

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

Ошибки обработки или интерпретации данных

Выделяются подпункты:
− проблемы при передаче данных между подпрограммами (сюда включены
несколько видов ошибок: параметры указаны не в том порядке или пропущены,
несоответствие типов данных, псевдонимы и различная интерпретация содержимого
одной и той же области памяти, неправильная интерпретация данных, неадекватная
информация об ошибке, перед аварийным выходом из подпрограммы не
восстановлено правильное состояние данных, устаревшие копии данных, связанные
переменные не синхронизированы, локальная установка глобальных данных (имеется
в виду путаница локальных и глобальных переменных), глобальное использование
локальных переменных, неверная маска битового поля, неверное значение из
таблицы);
− границы расположения данных (сюда включены несколько видов ошибок: не
обозначен конец нуль-терминированной строки, неожиданный конец строки,
запись/чтение за границами структуры данных или ее элемента, чтение за пределами
буфера сообщения, чтение за пределами буфера сообщения, дополнение переменных
до полного слова, переполнение и выход за нижнюю границу стека данных, затирание
кода или данных другого процесса);
− проблемы с обменом сообщений (сюда включены несколько видов ошибок:
отправка сообщения не тому процессу или не в тот порт, ошибка распознавания
полученного сообщения, недостающие или несинхронизированные сообщения,
сообщение передано только N процессам из N+1, порча данных, хранящихся на
внешнем устройстве, потеря изменений, не сохранены введенные данные, объем
данных слишком велик для процесса-получателя, неудачная попытка отмены записи
данных).

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

5
 В этом разделе хотелось бы обратить внимание на следующее:
1) Часть ошибок из этого раздела могут проявляться и при не очень высоких
нагрузках, но, возможно, они будут проявляться реже и через более длительные
интервалы времени;
2) Многие ошибки из 2-х предыдущих разделов уже в своей формулировке носят
вероятностный характер, поэтому следует предположить возможность использования
вероятностных моделей и методов для их выявления.

Контроль версий и идентификаторов

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

Ошибки тестирования
Являются ошибками сотрудников группы тестирования, а не программы.
Выделяются подпункты:
− пропущенные ошибки в программе;
− не замечена проблема (отмечаются следующие причины этого: тестировщик
не знает, каким должен быть правильный результат, ошибка затерялась в большом
объеме выходных данных, тестировщик не ожидал такого результата теста,
тестировщик устал и невнимателен, ему скучно, механизм выполнения теста
настолько сложен, что тестировщик уделяет ему больше внимания, чем результатам);
− пропуск ошибок на экране;
− не документирована проблема (отмечаются следующие причины этого:
тестировщик неаккуратно ведет записи, тестировщик не уверен в том, что данные
действия программы являются ошибочными, ошибка показалась слишком
незначительной, тестировщик считает, что ошибку не будет исправлена, тестировщика
просили не документировать больше подобные ошибки).

Ошибка выявлена и забыта

Описываются ошибки использования результатов тестирования. Раздел можно
объединить с предыдущим. Выделяются подпункты: не составлен итоговый отчет;
серьезная проблема не документирована повторно; не проверено исправление; перед
выпуском продукта не проанализирован список нерешенных проблем.

Необходимо заметить, что изложенные в 2-х последних разделах ошибки

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

6
 Существуют различные принципы тестирования, но в качестве основных
можно назвать следующие:
1) тестирование показывает наличие дефектов, но не доказывает, что их нет.
Вероятность наличия дефектов снижается, но отсутствие дефектов не доказывает
абсолютную корректность программного обеспечения;
2) тестирование необходимо начинать как можно раньше в жизненном цикле
разработки системы. Тестирование не может быть бесцельным. У каждой активности
необходимо определить четкую цель;
3) полное или исчерпывающее тестирование невозможно, так как существует
огромное количество комбинаций, предусловий, постусловий и т. д. Для того чтобы
наиболее четко определить, как и что необходимо тестировать, применяются анализ
рисков, расстановка приоритетов, оценка критичности функционала;
4) парадокс пестицида – один из самых известных принципов, который
означает, что многократный прогон одних и тех же тестов при соблюдении
одинаковых условий неэффективен. Такие тесты перестают находить дефекты, но это
не означает, что их нет. Тесты должны наиболее полно охватывать систему, а для
этого они должны быть разноплановыми, разносторонними. Написание тестов –
творческая задача. Каждый тест может найти большое количество дефектов, если
написан грамотно и продуманно;
5) дефекты скапливаются в небольшом количестве модулей, на которых в
конечном счете необходимо сосредоточить основные усилия по тестированию;
6) тестирование напрямую зависит от объекта, который подвергается
испытаниям. Прежде чем начать тестирование, нужно изучить систему и понять
наиболее критичные и уязвимые места, важность тех или иных функций для
пользователей;
7) заблуждение об отсутствии ошибок в системе. Данный принцип состоит в
том, что, если система не подходит пользователю и изначально была спроектирована
неверно, то она не сможет удовлетворить потребности, даже если множество дефектов
были обнаружены и устранены.

Объекты тестирования
Известно, что существует несколько различных моделей жизненного цикла
программного обеспечения, отличающихся друг от друга некоторыми деталями. При
этом представление программы на разных фазах ЖЦ изменяется в соответствии с
поэтапным изменением программ от уровня первичных целей и алгоритмов до уровня
завершенного эксплуатируемого и сопровождаемого программного продукта.
С точки зрения тестирования наиболее значимыми являются следующие
объекты программного проекта:
− требования
− спецификации программных модулей, групп программ и программных
комплексов;
− программные модули (код программных модулей);
− группы программ, решающие законченные функциональные задачи;
− комплексы программ, для которых завершены все виды отладки;
− программные средства, подлежащие испытаниям перед сдачей в
эксплуатацию;

7
 − сопровождаемый программный продукт до завершения его жизненного
цикла.
Эти объекты различаются сложностью тестирования, уровнем теоретической
разработки методов и существующей степенью автоматизации процесса тестирования.

Приоритеты в тестировании
Ключевыми аспектами, которые помогают расставить приоритеты в
тестировании, являются:
Частота использования. Тут все должно быть понятно. Часто используемые
функции имеют высокий приоритет. Редко используемые функции или те, которые
обслуживают технические ресурсы, обычно имеют низкий приоритет.
Степень риска. Если сбой функциональности приведет к массовой утечке
финансовых документов компании, то, естественно, она обладает высокой степенью
риска и должна быть протестирована первой.
Потребности конечных пользователей. Некоторые требования очень важны для
конечных пользователей. Они должны иметь самый высокий приоритет. В противном
случае программа может не удовлетворить заказчика.

Жизненный цикл тестирования

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

Важно понимать, что длина такой итерации (и, соответственно, степень

подробности каждой стадии) может варьироваться в широчайшем диапазоне — от
единиц часов до десятков месяцев. Как правило, если речь идёт о длительном
промежутке времени, он разбивается на множество относительно коротких итераций,

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

Стадия 1 (общее планирование и анализ требований) объективно необходима как

минимум для того, чтобы иметь ответ на такие вопросы, как:
что нам предстоит тестировать;
как много будет работы;
какие есть сложности;
всё ли необходимое у нас есть и т.п.

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

требований, т.к. именно требования являются первичным источником ответов.

Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или

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

Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно

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

Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру,

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

Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов)

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

Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно

связаны между собой и выполняются практически параллельно. Формулируемые на
стадии анализа результатов выводы напрямую зависят от плана тестирования,
критериев приёмки и уточнённой стратегии, полученных на стадиях 1, 2 и 3.
Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 3
следующей итерации тестирования. Таким образом, цикл замыкается.

9
 Тестирование документации и требований
Требования являются отправной точкой для определения того, что проектная
команда будет проектировать, реализовывать и тестировать. Элементарная логика
говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не то»,
т.е. колоссальная работа множества людей будет выполнена впустую.
Вне зависимости от того, какая модель разработки ПО («водопад», «V»,
«итерация», «виток спирали», «гибкие методологии») используется на проекте, чем
позже будет обнаружена проблема, тем сложнее и дороже будет её решение. В самом
начале идёт планирование и работа с требованиями. Если проблема в требованиях
будет выяснена на этой стадии, её решение может свестись к исправлению пары слов в
тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях
и обнаруженная на стадии эксплуатации, может даже полностью уничтожить проект.
Пример. Допустим, вы с друзьями составляете список покупок перед поездкой в
гипермаркет. Вы поедете покупать, а друзья ждут вас дома. Сколько «стоит»
дописать, вычеркнуть или изменить пару пунктов, пока вы только-только
составляете список? Нисколько. Если мысль о несовершенстве списка настигла вас
по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). Если вы
поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в
торговый зал и тратить время. Если проблема выяснилась по пути домой или даже
дома, придётся вернуться в гипермаркет. И, наконец, клинический случай: в списке
изначально было что-то уж совсем неправильное (например, «100 кг конфет — и
всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут
выясняется, что «ну мы же пошутили».
Ещё одним аргументом в пользу тестирования требований является то, что, по
разным оценкам, в них зарождается от ⅟2 до ⅔ всех проблем с программным
обеспечением. В итоге есть риск, что получится так:

Т.е. программное обеспечение не удовлетворяет ожиданием заказчика.

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

даже отдельного документа определяется большим количеством факторов, но
неизменным остаётся общий принцип: всё, что мы создаём в процессе разработки
10
проекта (даже рисунки маркером на доске, даже письма, даже переписку в скайпе),
можно считать документацией и так или иначе подвергать тестированию (например,
вычитывание письма перед отправкой — это тоже своего рода тестирование
документации).

Техники тестирования требований и документации

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

Взаимный просмотр. Взаимный просмотр («рецензирование») является одной

из наиболее активно используемых техник тестирования требований и может быть
представлен в одной из трёх следующих форм (по мере нарастания его сложности и
цены):
Беглый просмотр может выражаться как в показе автором своей работы
коллегам с целью создания общего понимания и получения обратной связи, так и в
простом обмене результатами работы между двумя и более авторами с тем, чтобы
коллега высказал свои вопросы и замечания. Это самый быстрый, дешёвый и часто
используемый вид просмотра. Для запоминания: аналог беглого просмотра — это
ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг
друга, чтобы найти описки и ошибки.
Технический просмотр выполняется группой специалистов. В идеальной
ситуации каждый специалист должен представлять свою область знаний. Тестируемый
продукт не может считаться достаточно качественным, пока хотя бы у одного
просматривающего остаются замечания. Для запоминания: аналог технического
просмотра — это ситуация, когда некий договор визирует юридический отдел,
бухгалтерия и т.д.
Формальная инспекция представляет собой структурированный,
систематизированный и документируемый подход к анализу документации. Для его
выполнения привлекается большое количество специалистов, само выполнение
занимает достаточно много времени, и потому этот вариант просмотра используется
достаточно редко (как правило, при получении на сопровождение и доработку
проекта, созданием которого ранее занималась другая компания). Для запоминания:
аналог формальной инспекции — это ситуация генеральной уборки квартиры
(включая содержимое всех шкафов, холодильника, кладовки и т.д.).

Вопросы. Следующей очевидной техникой тестирования и повышения качества

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

11
 В таблице приведено несколько плохо сформулированных требований, а также
примеров плохих и хороших вопросов. Плохие вопросы провоцируют на бездумные
ответы, не содержащие полезной информации.
Плохое
Плохие вопросы Хорошие вопросы
требование
Приложение «Насколько быстро?» (На это «Каково максимально
должно вы рискуете получить ответы в допустимое время запуска
быстро стиле «очень быстро», приложения,
запускаться «максимально быстро», «нууу… на каком оборудовании и при
просто быстро»). какой загруженности этого
«А если не получится быстро?» оборудования операционной
(Этим вы рискуете просто системой
удивить или даже разозлить и другими приложениями? На
заказчика.) достижение каких целей влияет
«Всегда?» («Да, всегда». Хм, а скорость запуска приложения?
вы ожидали другого ответа?) Допускается ли фоновая
загрузка отдельных
компонентов приложения? Что
является критерием того, что
приложение закончило запуск?»
«Опционально «Любых документов?» (Ответы «Насколько возможность
должен «да, любых» или «нет, только экспорта в PDF важна? Как
поддерживаться открытых» вам всё равно не часто, кем и с какой целью она
экспорт помогут.) будет использоваться? Является
документов в «В PDF какой версии должен ли PDF единственным
формат PDF». производиться экспорт?» (Сам допустимым форматом для этих
по себе вопрос хорош, но он не целей или есть альтернативы?
даёт понять, что имелось в виду Допускается ли использование
под «опционально».) внешних утилит (например,
«Зачем?» («Нужно!» Именно виртуальных PDF-принтеров)
так хочется ответить, если для экспорта документов в
вопрос не PDF?»
раскрыт полностью.)
«Если дата «А если указана?» (То она «Возможно, имелось в виду, что
события не указана. Логично, не так ли?) дата генерируется
указана, она «А если дату невозможно автоматически, а не
выбирается выбрать автоматически?» (Сам выбирается? Если да,
автоматически». вопрос интересен, но без то по какому алгоритму она
пояснения причин генерируется? Если нет, то из
невозможности звучит как какого набора выбирается дата
издёвка.) и как генерируется этот набор?
«А если у события нет даты?» P.S. Возможно, стоит
(Тут автор вопроса, скорее использовать текущую дату?»
всего, хотел уточнить,
обязательно ли это поле для
заполнения. Но из самого
требования видно, что
12
 обязательно: если оно не
заполнено человеком, его
должен заполнить компьютер.)

Тест-кейсы и чек-листы.
Хорошее требование является проверяемым, а значит, должны существовать
объективные способы определения того, верно ли реализовано требование.
Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа
требований позволяет нам определить, насколько требование проверяемо. Если вы
можете быстро придумать несколько пунктов чек-листа, это ещё не признак того, что с
требованием всё хорошо (например, оно может противоречить каким-то другим
требованиям). Но если никаких идей по тестированию требования в голову не
приходит — это тревожный знак.
Рекомендуется для начала убедиться, что вы понимаете требование (в том числе
прочесть соседние требования, задать вопросы коллегам и т.д.).
Также можно пока отложить работу с данным конкретным требованием и
вернуться к нему позднее — возможно, анализ других требований позволит вам лучше
понять и это конкретное. Но если ничто не помогает — скорее всего, с требованием
что-то не так.
Справедливости ради надо отметить, что на начальном этапе проработки
требований такие случаи встречаются очень часто — требования сформированы очень
поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет
необходимости проводить сложный анализ, чтобы констатировать непроверяемость
требования.
На стадии же, когда требования уже хорошо сформулированы и протестированы,
можно продолжать использовать эту технику, совмещая разработку тест-кейсов и
дополнительное тестирование требований.

Исследование поведения системы.

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

Рисунки (графическое представление).

Чтобы увидеть общую картину требований целиком, очень удобно использовать
рисунки, схемы, диаграммы, интеллект-карты и т.д.
Графическое представление удобно одновременно своей наглядностью и
краткостью (например, UML-схема базы данных, занимающая один экран, может быть
описана несколькими десятками страниц текста). На рисунке очень легко заметить, что
какие-то элементы «не стыкуются», что где-то чего-то не хватает и т.д. Если для
графического представления требований использовать общепринятую нотацию
(например, уже упомянутый UML), то можно получить дополнительные
13
преимущества: схему, построенную одним тетировщиком, смогут без труда понимать
и дорабатывать коллеги, а в итоге может получиться хорошее дополнение к текстовой
форме представления требований.

Прототипирование. Можно сказать, что прототипирование часто является

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

Пример анализа и тестирования требований

Поскольку наша задача состоит в том, чтобы сформировать понимание логики
анализа и тестирования требований, мы будем рассматривать предельно краткий и
простой их набор.
Допустим, что у некоего клиента есть проблема: поступающие в огромном
количестве его сотрудникам текстовые файлы приходят в разных кодировках, и
сотрудники тратят много времени на перекодирование («ручной подбор кодировки»).
Соответственно, он хотел бы иметь инструмент, позволяющий автоматически
приводить кодировки всех текстовых файлов к некоей одной. Итак, на свет появляется
проект с кодовым названием «Конвертер файлов».

Уровень бизнес-требований. Бизнес-требования изначально могут выглядеть так:

«Необходим инструмент для автоматического приведения кодировок текстовых
документов к одной».
Здесь можно задать множество вопросов. Для удобства приведены как сами
вопросы, так и предполагаемые ответы клиента.
– В каких форматах представлены текстовые документы (обычный текст,
HTML, MD, что-то иное)? (Понятия не имею, я в этом не разбираюсь.)
– В каких кодировках приходят исходные документы? (В разных.)
– В какую кодировку нужно преобразовать документы? (В самую удобную и
универсальную.)
– На каких языках написан текст в документах? (Русский и английский.)
– Откуда и как поступают текстовые документы (по почте, с сайтов, по сети,
как-то иначе)? (Это неважно. Поступают отовсюду, но мы их складываем в одну
папку на диске, нам так удобно.)
– Каков максимальный объём документа? (Пара десятков страниц.)
– Как часто появляются новые документы (например, сколько максимум
документов может поступить за час)? (200–300 в час.)
С помощью чего сотрудники просматривают документы? (Notepad++.)

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

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

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

Цели проекта:
– Исключение необходимости ручного подбора кодировок текстовых
документов.
– Сокращение времени работы с текстовым документом на величину,
необходимую для ручного подбора кодировки.

Метрики достижения целей:

– Полная автоматизация определения и преобразования кодировки
текстового документа к заданной.
– Сокращение времени обработки текстового документа в среднем на 1–2
минуты на документ за счёт устранения необходимости ручного подбора кодировки.

Риски:
Высокая техническая сложность безошибочного определения исходной
кодировки текстового документа.

Почему решили, что среднее время на подбор кодировки составляет 1–2

минуты? Было проведено наблюдение. Также исходя из ответов заказчика на вопросы
об исходных форматах документов, исходных и конечной кодировках (заказчик честно
сказал, что не знает ответа), следует попросить заказчика предоставить доступ к
хранилищу документов. Допустим в результате анализ хранилища документов было
выяснено следующее:
– Исходные форматы: plain text, HTML, MD.
– Исходные кодировки: WIN1251, UTF8, CP866, KOI8R.
– Целевая кодировка: UTF8.

На данном этапе вполне можно решить, что стоит заняться детализацией

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

Уровень пользовательских требований.

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

Для начала создадим небольшую диаграмму вариантов использования, (её

создают после текстового описания требований, но иногда и до — нам сейчас удобнее
сделать это сначала).

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

Внимание! Это — ПЛОХИЕ требования. И далее будет их улучшение.

Системные характеристики
СХ-1: Приложение является консольным.
СХ-2: Для работы приложение использует интерпретатор PHP.
СХ-3: Приложение является кроссплатформенным.

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

ПТ-1: Запуск и остановка приложения.
ПТ-1.1: Запуск приложения производится из консоли командой «PHP
converter.php параметры».
ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C.

ПТ-2: Конфигурирование приложения.

16
 ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой
системе.
ПТ-2.2: Целевой кодировкой является UTF8.

ПТ-3: Просмотр журнала работы приложения.

ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в
консоль и лог-файл.
ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при
последующих — дописывается.

Бизнес-правила
БП-1: Источник и приёмник файлов
БП-1.1: Каталоги, являющиеся источником исходных и приёмником конечных
файлов не должны совпадать.
БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть
подкаталогом источника.

Атрибуты качества
АК-1: Производительность
АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек.

АК-2: Устойчивость к входным данным

АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ
включительно.
АК-2.2: Если входной файл не является текстовым, приложение должно
произвести обработку.
Поскольку не стоит изменять исходный формат файла и форматирование
документа, то хорошо бы использовать встроенные средства Word для отслеживания
изменений и добавления комментариев.

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

Но мы будем вписывать свои вопросы и комментарии прямо внутрь текста

требований. Проблемные места требований отмечены подчёркиванием, наши вопросы
17
отмечены курсивом, предполагаемые ответы заказчика (даже, если точнее,
технического специалиста заказчика) — жирным.

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

Системные характеристики
СХ-1: Приложение является консольным.
СХ-2: Для работы приложение использует интерпретатор PHP.
–Какая минимальная версия интерпретатора PHP поддерживается
приложением? (5.5.x)
–Существует ли некая специфика настройки интерпретатора PHP для
корректной работы приложения? (Наверное, должен работать mbstring.)
–Настаиваете ли вы на реализации приложения именно на PHP? Если да, то
почему. (Да, только PHP. У нас есть сотрудник, который его знает.)
–Должна ли в руководстве пользователя быть описана процедура установки и
настройки интерпретатора PHP? (Нет.)

СХ-3: Приложение является кроссплатформенным.

– Какие ОС должны поддерживаться? (Любая, где работает PHP.)
– В чём вообще цель кроссплатформенности? (Мы ещё не знаем, на чём
будет работать сервер.)

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

ПТ-1: Запуск и остановка приложения.
ПТ-1.1: Запуск приложения производится из консоли командой «PHP
(возможно, здесь опечатка: должно быть php (в нижнем регистре)) (Да, OK.)
converter.php параметры».
– Какие параметры передаются скрипту при запуске? (Каталог с
исходными файлами, каталог с конечными файлами.)
– Какова реакция скрипта на:
– отсутствие параметров; (Пишет хелп.)
– неверное количество параметров; (Пишет хелп и поясняет, что не
так.)
– неверные значения каждого из параметров. (Пишет хелп и
поясняет, что не так.)

ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C

(предлагаем дополнить это выражение фразой «в окне консоли, из которого было
запущено приложение») (Да, OK.).

ПТ-2: Конфигурирование приложения.

ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой
системе.
– Путей к чему? (Каталог с исходными файлами, каталог с конечными
файлами.)
ПТ-2.2: Целевой кодировкой является UTF8.

18
 – Предполагается ли указание иной целевой кодировки, или UTF8
используется в качестве целевой всегда? (Только UTF8, других не надо.)

ПТ-3: Просмотр журнала работы приложения.

ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в
консоль и лог-файл.
– Каков формат журнала? (Дата-время, что и с чем делали, что
получилось. Гляньте в логе апача, там нормально написано.)
– Различаются ли форматы журнала для консоли и лог-файла? (Нет.)
– Как определяется имя лог-файла? (Третий параметр при запуске. Если
не указан — пусть будет converter.log рядом с php-скриптом.)

ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при

последующих — дописывается.
– Как приложение различает свой первый и последующие запуски? (Никак.)
– Какова реакция приложения на отсутствие лог-файла в случае, если это
не первый запуск? (Создаёт. Тут идея в том, чтобы оно не затирало старый
лог — и всё.)

Бизнес-правила
БП-1: Источник и приёмник файлов
БП-1.1: Каталоги, являющиеся источником исходным (опечатка, исходных)
(Да.) и приёмником конечных файлов, не должны совпадать.
– Какова реакция приложения в случае совпадения этих каталогов? (Пишет
хелп и поясняет, что не так.)
БП-1.2: Каталог, являющийся приёмником конечных файлов, не может
– быть подкаталогом источника (предлагаем заменить слово «источника» на
фразу «каталога, являющегося источником исходных файлов»). (Хорошо,
пусть будет так.)

Атрибуты качества
АК-1: Производительность
АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек.
– При каких технических характеристиках системы? (i7, 4GB RAM)

АК-2: Устойчивость к входным данным

АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ
включительно.
– Какова реакция приложения на файлы, размер которых превышает 50
МБ? (Не трогает.)
АК-2.2: Если входной файл не является текстовым, приложение должно
произвести обработку.
– Обработку чего должно произвести приложение? (Этого файла. Не
важно, что станет с файлом, лишь бы скрипт не умер.)

Здесь есть несколько важных моментов, на которые стоит обратить внимание:

19
 Ответы заказчика могут быть менее структурированными и последовательными,
чем наши вопросы. Это нормально. Он может позволить себе такое, тестировщики —
нет.
Ответы заказчика могут содержать противоречия (в примере сначала заказчик
писал, что параметрами, передаваемыми из командной строки, являются только два
имени каталога, а потом сказал, что там же указывается имя лог-файла). Это тоже
нормально, т.к. заказчик мог что-то забыть или перепутать. Задача тестировщика —
свести эти противоречивые данные воедино (если это возможно) и задать уточняющие
вопросы (если это необходимо).
В случае если с нами общается технический специалист, в его ответах вполне
могут проскакивать технические жаргонизмы (как «хелп» в примере). Не надо
переспрашивать его о том, что это такое, если жаргонизм имеет однозначное
общепринятое значение, но при доработке текста задача тестировщика — написать то
же самое строгим техническим языком. Если жаргонизм всё же непонятен — тогда
лучше спросить (так, «хелп» — это всего лишь краткая помощь, выводимая
консольными приложениями как подсказка о том, как их использовать).

Уровень продуктных требований

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

Системные характеристики
СХ-1: Приложение является консольным.
СХ-2: Приложение разрабатывается на языке программирования PHP (причина
выбора языка PHP отражена в пункте О-1 раздела «Ограничения», особенности и
важные настройки интерпретатора PHP отражены в пункте ДС-1 раздела «Детальные
спецификации»).
СХ-3: Приложение является кроссплатформенным с учётом пункта О-4 раздела
«Ограничения».

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

ПТ-1: Запуск и остановка приложения.
ПТ-1.1: Запуск приложения производится из консоли командой «php
converter.php SOURCE_DIR DESTINATION_DIR [LOG_FILE_NAME]» (описание
параметров приведено в разделе ДС-2.1, реакция на ошибки при указании параметров
приведена в разделах ДС-2.2, ДС-2.3, ДС-2.4).
ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C в
окне консоли, из которого было запущено приложение.

ПТ-2: Конфигурирование приложения.

ПТ-2.1: Конфигурирование приложения сводится к указанию параметров
командной строки (см. ДС-2).

20
 ПТ-2.2: Целевой кодировкой преобразования текстов является кодировка UTF8
(также см. О-5).

ПТ-3: Просмотр журнала работы приложения.

ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в
консоль и лог-файл (см. ДС-4), имя которого определяется правилами, указанными в
ДС-2.1.
ПТ-3.2: Формат журнала работы и лог файла указан в ДС-4.1, а реакция
приложения на наличие или отсутствие лог-файла указана в ДС-4.2 и ДС-4.3
соответственно.

Бизнес-правила
БП-1: Источник и приёмник файлов
БП-1.1: Каталоги, являющиеся источником исходных и приёмником конечных
файлов, не должны совпадать (см. также ДС-2.1 и ДС-3.2).
БП-1.2: Каталог, являющийся приёмником конечных файлов, не может
находиться внутри каталога, являющегося источником исходных файлов или его
подкаталогов (см. также ДС-2.1 и ДС-3.2).

Атрибуты качества
АК-1: Производительность
АК-1.1: Приложение должно обеспечивать скорость обработки данных не менее
5 МБ/сек на аппаратном обеспечении, эквивалентном следующему: процессор i7, 4 ГБ
оперативной памяти, средняя скорость чтения/записи на диск 30 МБ/сек. Также см. О-
6.

АК-2: Устойчивость к входным данным

АК-2.1: Требования относительно форматов обрабатываемых файлов изложены
в ДС-5.1.
АК-2.2: Требования относительно размеров обрабатываемых файлов изложены в
ДС-5.2.
АК-2.3: Поведение приложения в ситуации обработки файлов с нарушениями
формата определено в ДС-5.3.

Ограничения
О-1: Приложение разрабатывается на языке программирования PHP,
использование которого обусловлено возможностью заказчика осуществлять
поддержку приложения силами собственного IT-отдела.
О-2: Ограничения относительно версии и настроек интерпретатора PHP
отражены в пункте ДС-1 раздела «Детальные спецификации».
О-3: Процедуры установки и настройки интерпретатора PHP выходят за рамки
данного проекта и не описываются в документации.
О-4: Кроссплатформенные возможности приложения сводятся к способности
работать под ОС семейства Windows и Linux, поддерживающих работу
интерпретатора PHP версии, указанной в ДС-1.1.
О-5: Целевая кодировка UTF8 является жёстко заданной, и её изменение в
процессе эксплуатации приложения не предусмотрено.

21
 О-6: Допускается невыполнение АК-1.1 в случае, если невозможность
обеспечить заявленную производительность обусловлена объективными внешними
причинами (например, техническими проблемами на сервере заказчика).

Созданные на основе таких пользовательских требований детальные

спецификации имеют следующий вид.

Детальные спецификации
ДС-1: Интерпретатор PHP
ДС-1.1: Минимальная версия — 5.5.
ДС-1.2: Для работы приложения должно быть установлено и включено
расширение mbstring.
ДС-2: Параметры командной строки
ДС-2.1: При запуске приложения оно получает из командной строки три
параметра:
SOURCE_DIR — обязательный параметр, определяет путь к каталогу с файлами,
которые необходимо обработать;
DESTINATION_DIR — обязательный параметр, определяет путь к каталогу, в
который необходимо поместить обработанные файлы (этот каталог не может
находиться внутри каталога SOURCE_DIR или в его подкаталогах (см. БП-1.1 и БП-
1.2));
LOG_FILE_NAME — необязательный параметр, определяет полное имя лог-
файла (по умолчанию лог-файл с именем «converter.log» размещается по тому же пути,
по которому находится файл скрипта converter.php);
ДС-2.2: При указании недостаточного количества параметров командной строки
приложение должно завершить работу, выдав сообщение об использовании (ДС-3.1).
ДС-2.3: При указании излишнего количества параметров командной строки
приложение должно игнорировать все параметры командной строки, кроме указанных
в пункте ДС-2.1.
ДС-2.4: При указании неверного значения любого из параметров командной
строки приложение должно завершить работу, выдав сообщение об использовании
(ДС-3.1), а также сообщив имя неверно указанного параметра, его значение и суть
ошибки (см. ДС-3.2).

ДС-3: Сообщения
ДС-3.1: Сообщение об использовании: «USAGE converter.php SOURCE_DIR
DESTINATION_DIR LOG_FILE_NAME».
ДС-3.2: Сообщения об ошибках:
Directory not exists or inaccessible.
Destination dir may not reside within source dir tree.
Wrong file name or inaccessible path.

ДС-4: Журнал работы

ДС-4.1: Формат журнала работы одинаков для отображения в консоли и записи в
лог-файл: YYYY-MM-DD HH:II:SS имя_операции параметры_операции
результат_операции.

22
 ДС-4.2: В случае если лог-файл отсутствует, должен быть создан новый пустой
лог-файл.
ДС-4.3: В случае если лог-файл уже существует, должно происходить
добавление новых записей в его конец.

ДС-5: Форматы и размеры файлов

ДС-5.1: Приложение должно обрабатывать текстовые файлы на русском и
английском языках в следующих исходных кодировках: WIN1251, CP866, KOI8R.
Обрабатываемые файлы могут быть представлены в следующих форматах,
определяемых расширениями файлов:
Plain Text (TXT);
Hyper Text Markup Language Document (HTML);
Mark Down Document (MD).

ДС-5.2: Приложение должно обрабатывать файлы размером до 50 МБ

(включительно), игнорируя любой файл, размер которого превышает 50 МБ.
ДС-5.3: Если файл с расширением из ДС-5.1 содержит внутри себя данные, не
соответствующие формату файла, допускается повреждение таких данных.

Итак, мы получили набор требований, с которым уже вполне можно работать.

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

23
 Лекция 18
Тестирование программного обеспечения (ч.2)

Типичные ошибки при анализе и тестировании требований

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

Изменение формата файла и документа.

По какой-то непонятной причине очень многие начинающие тестировщики
стремятся полностью уничтожить исходный документ, заменив текст таблицами (или
наоборот), перенеся данные из Word в Excel и т.д. Это можно сделать только в одном
случае: если вы предварительно договорились о подобных изменениях с автором
документа. В противном случае вы полностью уничтожаете чью-то работу, делая
дальнейшее развитие документа крайне затруднительным.
Самое худшее, что можно сделать с документом, — это сохранить его в итоге в
некоем формате, предназначенном скорее для чтения, чем для редактирования (PDF,
набор картинок и тому подобное).
Если требования изначально создаются в некоей системе управления
требованиями, этот вопрос неактуален, но высокоуровневые требования большинство
заказчиков привыкли видеть в обычном DOCX-документе, а Word предоставляет такие
прекрасные возможности работы с документом, как отслеживание изменений и
комментарии.

В итоге получается результат, представленный на рисунке ниже: исходный

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

Правильно выглядящий документ с правками

И ещё два маленьких, но неприятных момента относительно таблиц:

Выравнивание ВСЕГО текста в таблице по центру. Да, выравнивание по центру
хорошо смотрится в заголовках и ячейках с парой-тройкой слов, но если так выровнен
весь текст, читать его становится сложно.
Отключение границ ячеек. Такая таблица намного хуже читается.

Отметка того факта, что с требованием всё в порядке.

Если не возникло вопросов и/или замечаний к требованию — не надо об этом
писать. Любые пометки в документе подсознательно воспринимаются как признак
проблемы, и такое «одобрение требований» только раздражает и затрудняет работу с
документом — сложнее становится заметить пометки, относящиеся к проблемам.
1
 Описание одной и той же проблемы в нескольких местах.
Следует помнить, что все пометки, комментарии, замечания и вопросы тоже
должны обладать свойствами хороших требований (настолько, насколько эти свойства
к ним применимы).
Если много раз в разных местах написано одно и то же об одном и том же, то, как
минимум, нарушается свойство модифицируемости. В таком случае необходимо
вынести текст в конец документа, указать в нём же (в начале) перечень пунктов
требований, к которым он относится, а в самих требованиях в комментариях просто
ссылаться на этот текст.

Написание вопросов и комментариев без указания места требования, к которым

они относятся.
Если инструментальное средство позволяет указать часть требования, к которому
пишется вопрос или комментарий, следует сделать это (например, Word позволяет
выделить для комментирования любую часть текста — хоть один символ). Если это
невозможно, то нужно процитировать соответствующую часть текста. В противном
случае будет порождена неоднозначность или вовсе пометка станет бессмысленной, т.к.
становится невозможно понять, о чём вообще идёт речь.

Задавание плохо сформулированных вопросов.

Эта ошибка была подробно рассмотрена выше (Техники тестирования
требований), но есть ещё три вида плохих вопросов:
Первый вид возникает из-за того, что автор вопроса не знает общепринятой
терминологии или типичного поведения стандартных элементов интерфейса (например,
«что такое чек-бокс?», «как в списке можно выбрать несколько пунктов?», «как
подсказка может всплывать?»).
Второй вид плохих вопросов похож на первый из-за формулировок: вместо того,
чтобы написать «что вы имеете в виду под {чем-то}?», автор вопроса пишет «что такое
{что-то}?» То есть вместо вполне логичного уточнения получается ситуация, очень
похожая на рассмотренную в предыдущем пункте.
Третий вид сложно привязать к причине возникновения, но его суть в том, что к
некорректному и/или невыполнимому требованию задаётся вопрос наподобие «что
будет, если мы это сделаем?». Ничего не будет, т.к. мы это точно не сделаем. И вопрос
должен быть совершенно иным (каким именно — зависит от конкретной ситуации, но
точно не таким).

И ещё о точности формулировок: иногда одно-два слова могут на корню

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

2
 Написание очень длинных комментариев и/или вопросов. История знает случаи,
когда одна страница исходных требований превращалась в 20–30 страниц текста
анализа и вопросов. Это плохой подход. Все те же мысли можно выразить значительно
более кратко, чем сэкономить как своё время, так и время автора исходного документа.
Тем более стоит учитывать, что на начальных стадиях работы с требованиями они
весьма нестабильны, и может получиться так, что 5–10 страниц комментариев относятся
к требованию, которое просто удалят или изменят до неузнаваемости.

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

Категоричные заявления без обоснования. Как продолжение ошибки «критика

текста или даже его автора» можно отметить и просто категоричные заявления
наподобие «это невозможно», «мы не будем этого делать», «это не нужно».
Даже если понятно, что требование бессмысленно или невыполнимо, эту мысль
стоит сформулировать в корректной форме и дополнить вопросами, позволяющими
автору документа самому принять окончательное решение. Например, «это не нужно»
можно переформулировать так: «Мы сомневаемся в том, что данная функция будет
востребована пользователями. Какова важность этого требования? Уверены ли вы в его
необходимости?»

Указание проблемы с требованиями без пояснения её сути.

Автор исходного документа может не быть специалистом по тестированию или
бизнес-анализу. Потому просто пометка в стиле «неполнота», «двусмысленность» и т.д.
могут ничего ему не сказать. Следует пояснять свою мысль.
Сюда же можно отнести небольшую, но досадную недоработку, относящуюся к
противоречивости: если обнаружены некие противоречия, стоит сделать
соответствующие пометки во всех противоречащих друг другу местах, а не только в
одном из них. Например, обнаружено, что требование 20 противоречит требованию 30.
Тогда в требовании 20 стоит отметить, что оно противоречит требованию 30, и
наоборот, а также пояснить суть противоречия.

Плохое оформление вопросов и комментариев.

Необходимо сделать вопросы и комментарии максимально простыми для
восприятия. Следует помнить не только о краткости формулировок, но и об оформлении
текста. В тексте не должно быть опечаток, грамматических и пунктуационных ошибок.

Описание проблемы не в том месте, к которому она относится.

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

3
 Ошибочное восприятие требования как «требования к пользователю».
Требования в стиле «пользователь должен быть в состоянии отправить
сообщение» являются некорректными. И это так. Но бывают ситуации, когда проблема
намного менее опасна и состоит только в формулировке. Например, фразы в стиле
«пользователь может нажать на любую из кнопок», «пользователю должно быть видно
главное меню» на самом деле означают «все отображаемые кнопки должны быть
доступны для нажатия» и «главное меню должно отображаться». Да, эту недоработку
тоже стоит исправить, но не следует отмечать её как критическую проблему.

Скрытое редактирование требований.

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

Анализ, не соответствующий уровню требований.

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

Виды и направления тестирования

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

Итак, тестирование можно классифицировать:

4
 По запуску кода на исполнение:
Статическое тестирование — без запуска.
Динамическое тестирование — с запуском.

По доступу к коду и архитектуре приложения:

Метод белого ящика — доступ к коду есть.
Метод чёрного ящика — доступа к коду нет.
Метод серого ящика — к части кода доступ есть, к части — нет.

По степени автоматизации:
Ручное тестирование — тест-кейсы выполняет человек.
Автоматизированное тестирование — тест-кейсы частично или полностью
выполняет специальное инструментальное средство.

По уровню детализации приложения (по уровню тестирования):

Модульное (компонентное) тестирование — проверяются отдельные небольшие
части приложения.
Интеграционное тестирование — проверяется взаимодействие между
несколькими частями приложения.
Системное тестирование — приложение проверяется как единое целое.

По (убыванию) степени важности тестируемых функций (по уровню

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

По принципам работы с приложением:

Позитивное тестирование — все действия с приложением выполняются строго по
инструкции без никаких недопустимых действий, некорректных данных и т.д. Можно
образно сказать, что приложение исследуется в «тепличных условиях».
Негативное тестирование — в работе с приложением выполняются
(некорректные) операции и используются данные, потенциально приводящие к
ошибкам (классика жанра — деление на ноль).

Подробная классификация тестирования

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

5
 пересечений отмечены цветом и границей блоков в виде набора точек. Если вы видите
на схеме подобный блок — ищите одноимённый где-то в другом виде классификации.

Зачем вообще нужна классификация тестирования? Она позволяет упорядочить

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

Классификация по запуску кода на исполнение

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

Статическое тестирование — тестирование без запуска кода на исполнение. В

рамках этого подхода тестированию могут подвергаться:
– Документы (требования, тест-кейсы, описания архитектуры приложения,
схемы баз данных и т.д.).
– Графические прототипы (например, эскизы пользовательского интерфейса).
– Код приложения (что часто выполняется самими программистами в рамках
аудита кода, являющегося специфической вариацией взаимного просмотра в применении
к исходному коду). Код приложения также можно проверять с использованием техник
тестирования на основе структур кода.
– Параметры (настройки) среды исполнения приложения.
– Подготовленные тестовые данные.

Динамическое тестирование — тестирование с запуском кода на исполнение.

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

Классификация по доступу к коду и архитектуре приложения

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

Метод чёрного ящика — у тестировщика либо нет доступа к внутренней

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

6
большинство перечисленных в схеме видов тестирования работают по методу чёрного
ящика, идею которого в альтернативном определении можно сформулировать так:
тестировщик оказывает на приложение воздействия (и проверяет реакцию) тем же
способом, каким при реальной эксплуатации приложения на него воздействовали бы
пользователи или другие приложения. В рамках тестирования по методу чёрного ящика
основной информацией для создания тест-кейсов выступает документация (особенно —
требования) и общий здравый смысл (для случаев, когда поведение приложения в
некоторой ситуации не регламентировано явно; иногда это называют «тестированием
на основе неявных требований»).

Метод серого ящика — комбинация методов белого ящика и чёрного ящика,

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

Если сравнить основные преимущества и недостатки перечисленных методов,

получается следующая картина:
Метод Преимущества
белого • Показывает скрытые проблемы и
ящика упрощает их диагностику.
• Допускает достаточно простую
автоматизацию тест-кейсов и их
выполнение на самых ранних
стадиях развития проекта.
• Обладает развитой системой
метрик, сбор и анализ которых
легко автоматизируется.
• Стимулирует разработчиков к
написанию качественного кода.
• Многие техники этого метода
являются проверенными, хорошо
себя зарекомендовавшими
решениями, базирующимися на
строгом техническом подходе.
черного • Тестировщик не обязан
ящика обладать (глубокими) знаниями в
области программирования.
• Поведение приложения
исследуется в контексте реальной
среды выполнения и учитывает её
влияние.
• Поведение приложения
исследуется в контексте реальных
пользовательских сценариев.
Недостатки
• Не может выполняться
тестировщиками, не обладающими
достаточными знаниями в области
программирования.
• Тестирование сфокусировано на
реализованной функциональности,
что повышает вероятность пропуска
нереализованных требований.
• Поведение приложения
исследуется в отрыве от реальной
среды выполнения и не учитывает
её влияние.
• Поведение приложения
исследуется в отрыве от реальных
пользовательских сценариев
• Возможно повторение части
тест-кейсов, уже выполненных
разработчиками.
• Высока вероятность того, что
часть возможных вариантов
поведения приложения останется
непротестированной.
• Для разработки
высокоэффективных тест-кейсов
необходима качественная
документация.
7
 • Тест-кейсы можно создавать
уже на стадии появления
стабильных требований.
• Процесс создания тест-кейсов
позволяет выявить дефекты в
требованиях.
• Допускает создание тест-
кейсов, которые можно
многократно использовать на
разных проектах.
серого Сочетает преимущества и недостатки методов белого и чёрного ящика.
ящика
• Диагностика обнаруженных
дефектов более сложна в сравнении
с техниками метода белого ящика.
• В связи с широким выбором
техник и подходов затрудняется
планирование и оценка трудозатрат.
• В случае автоматизации могут
потребоваться сложные
дорогостоящие инструментальные
средства

Методы белого и чёрного ящика не являются конкурирующими или

взаимоисключающими — напротив, они гармонично дополняют друг друга,
компенсируя таким образом имеющиеся недостатки.

Классификация по степени автоматизации

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

Автоматизированное тестирование — набор техник, подходов и

инструментальных средств, позволяющий исключить человека из выполнения
некоторых задач в процессе тестирования.
Тест-кейсы частично или полностью выполняет специальное инструментальное
средство, однако разработка тест-кейсов, подготовка данных, оценка результатов
выполнения, написания отчётов об обнаруженных дефектах — всё это и многое другое
по-прежнему делает человек.
Некоторые авторы говорят отдельно о «полуавтоматизированном» тестировании
как варианте ручного с частичным использованием средств автоматизации и отдельно
об «автоматизированном» тестировании (относя туда области тестирования, в которых
компьютер выполняет ощутимо большой процент задач). Но т.к. без участия человека
всё равно не обходится ни один из этих видов тестирования, не станем усложнять набор
терминов и ограничимся одним понятием «автоматизированное тестирование».

У автоматизированного тестирования есть много как сильных, так и слабых

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

8
 – Минимизация затрат при многократном выполнении тест-кейсов (участие
человека здесь требуется лишь эпизодически).
– Способность средств автоматизации выполнить тест-кейсы, в принципе
непосильные для человека в силу своей сложности, скорости или иных факторов.
– Способность средств автоматизации собирать, сохранять, анализировать,
агрегировать и представлять в удобной для восприятия человеком форме колоссальные
объёмы данных.
– Способность средств автоматизации выполнять низкоуровневые действия с
приложением, операционной системой, каналами передачи данных и т.д.

Недостатки:
– Необходим высококвалифицированный персонал в силу того факта, что
автоматизация — это «проект внутри проекта» (со своими требованиями, планами,
кодом и т.д.)
– Высокие затраты на сложные средства автоматизации, разработку и
сопровождение кода тест-кейсов.
– Автоматизация требует более тщательного планирования и управления
рисками, т.к. в противном случае проекту может быть нанесён серьёзный ущерб.
– Средств автоматизации крайне много, что усложняет проблему выбора того
или иного средства и может повлечь за собой финансовые затраты (и риски),
необходимость обучения персонала (или поиска специалистов).
– В случае ощутимого изменения требований, смены технологического
домена, переработки интерфейсов (как пользовательских, так и программных) многие
тест-кейсы становятся безнадёжно устаревшими и требуют создания заново.

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

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

Классификация по уровню детализации приложения (по уровню

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

Модульное (компонентное) тестирование направлено на проверку отдельных

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

9
 Интеграционное тестирование направлено на проверку взаимодействия между
несколькими частями приложения (каждая из которых, в свою очередь, проверена
отдельно на стадии модульного тестирования). К сожалению, даже если ведется работа
с очень качественными отдельными компонентами, «на стыке» их взаимодействия
часто возникают проблемы. Именно эти проблемы и выявляет интеграционное
тестирование.

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

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

Для лучшего запоминания степень детализации в модульном, интеграционном и

системном тестировании показана схематично на следующем рисунке:

Классификация по (убыванию) степени важности тестируемых функций (по

уровню функционального тестирования)
В некоторых источниках эту разновидность классификации также называют «по
глубине тестирования».

Внимание! Возможна путаница, вызванная тем, что единого общепринятого

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

Дымовое тестирование направлено на проверку самой главной, самой важной,

самой ключевой функциональности, неработоспособность которой делает
бессмысленной саму идею использования приложения (или иного объекта,
подвергаемого дымовому тестированию).
Дымовое тестирование проводится после выхода новой версии (новый билд),
чтобы определить общий уровень качества приложения и принять решение о
10
(не)целесообразности выполнения тестирования критического пути и расширенного
тестирования. Поскольку тест-кейсов на уровне дымового тестирования относительно
немного, а сами они достаточно просты, но при этом очень часто повторяются, они
являются хорошими кандидатами на автоматизацию. В связи с высокой важностью
тест-кейсов на данном уровне пороговое значение метрики их прохождения часто
выставляется равным 100 % или близким к 100 %.

Тестирование критического пути направлено на исследование

функциональности, используемой типичными пользователями в типичной
повседневной деятельности. Пороговое значение метрики успешного прохождения
«теста критического пути» уже немного ниже, чем в дымовом тестировании, но всё
равно достаточно высоко (как правило, порядка 70–80–90 % — в зависимости от сути
проекта).

Суть тестирования критического пути

Расширенное тестирование направлено на исследование всей заявленной в

требованиях функциональности — даже той, которая низко проранжирована по степени
важности. При этом здесь также учитывается, какая функциональность является более
важной, а какая — менее важной. Но при наличии достаточного количества времени и
иных ресурсов тест-кейсы этого уровня могут затронуть даже самые
низкоприоритетные требования.
Ещё одним направлением исследования в рамках данного тестирования являются
нетипичные, маловероятные, экзотические случаи и сценарии использования функций
и свойств приложения, затронутых на предыдущих уровнях. Пороговое значение
метрики успешного прохождения расширенного тестирования существенно ниже, чем
в тестировании критического пути (иногда можно увидеть даже значения в диапазоне
30–50 %, т.к. подавляющее большинство найденных здесь дефектов не представляет
угрозы для успешного использования приложения большинством пользователей).

11
 Классификация тестирования по (убыванию) степени важности тестируемых
функций (по уровню функционального тестирования) графически:

Классификация по природе приложения

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

Тестирование веб-приложений сопряжено с интенсивной деятельностью в

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

Тестирование мобильных приложений также требует повышенного внимания к

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

Тестирование настольных приложений является самым классическим среди всех

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

Эту классификацию можно продолжать очень долго. Например, можно отдельно

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

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

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

12
 Тестирование уровня представления сконцентрировано на той части приложения,
которая отвечает за взаимодействие с «внешним миром» (как пользователями, так и
другими приложениями). Здесь исследуются вопросы удобства использования,
скорости отклика интерфейса, совместимости с браузерами, корректности работы
интерфейсов.

Тестирование уровня бизнес-логики отвечает за проверку основного набора

функций приложения и строится на базе ключевых требований к приложению, бизнес-
правил и общей проверки функциональности.

Тестирование уровня данных сконцентрировано на той части приложения,

которая отвечает за хранение и некоторую обработку данных (чаще всего — в базе
данных или ином хранилище). Здесь особый интерес представляет тестирование
данных, проверка соблюдения бизнес-правил, тестирование производительности.

Классификация по привлечению конечных пользователей

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

Альфа-тестирование выполняется внутри организации-разработчика с

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

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

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

Гамма-тестирование — финальная стадия тестирования перед выпуском

продукта, направленная на исправление незначительных дефектов, обнаруженных в
бета-тестировании. Как правило, также выполняется с максимальным привлечением
конечных пользователей / заказчиков. Может являться формой внешнего приёмочного
тестирования. Суть этого вида вкратце: продукт уже почти готов, и сейчас обратная
связь от реальных пользователей используется для устранения последних недоработок.

13
 Лекция 19
Тестирование программного обеспечения (ч.3)

Классификация по степени формализации

Тестирование на основе тест-кейсов — формализованный подход, в котором
тестирование производится на основе заранее подготовленных тест-кейсов, наборов
тест-кейсов и иной документации. Это самый распространённый способ тестирования,
который также позволяет достичь максимальной полноты исследования приложения за
счёт строгой систематизации процесса, удобства применения метрик и широкого набора
выработанных за десятилетия и проверенных на практике рекомендаций.

Исследовательское тестирование — частично формализованный подход, в

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

Свободное (интуитивное) тестирование — полностью неформализованный

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

Классификация по целям и задачам

По принципам работы с приложением
Позитивное тестирование (рассмотрено ранее).
Негативное тестирование (рассмотрено ранее).

Функциональное тестирование — вид тестирования, направленный на проверку

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

Нефункциональное тестирование — вид тестирования, направленный на

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

1
 Инсталляционное тестирование — тестирование, направленное на выявление
дефектов, влияющих на протекание стадии инсталляции (установки) приложения. В
общем случае такое тестирование проверяет множество сценариев и аспектов работы
инсталлятора в таких ситуациях, как:
– новая среда исполнения, в которой приложение ранее не было
инсталлировано;
– обновление существующей версии («апгрейд»);
– изменение текущей версии на более старую («даунгрейд»);
– повторная установка приложения с целью устранения возникших проблем
(«переинсталляция»);
– повторный запуск инсталляции после ошибки, приведшей к невозможности
продолжения инсталляции;
– удаление приложения;
– установка нового приложения из семейства приложений;
– автоматическая инсталляция без участия пользователя.

Регрессионное тестирование — тестирование, направленное на проверку того

факта, что в ранее работоспособной функциональности не появились ошибки,
вызванные изменениями в приложении или среде его функционирования. Фредерик
Брукс в своей книге «Мифический человеко-месяц» писал: «Фундаментальная
проблема при сопровождении программ состоит в том, что исправление одной ошибки
с большой вероятностью (20–50 %) влечёт появление новой». Потому регрессионное
тестирование является неотъемлемым инструментом обеспечения качества и активно
используется практически в любом проекте.

Повторное тестирование — выполнение тест-кейсов, которые ранее обнаружили

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

Приёмочное тестирование — формализованное тестирование, направленное на

проверку приложения с точки зрения конечного пользователя/заказчика и вынесения
решения о том, принимает ли заказчик работу у исполнителя (проектной команды).
Можно выделить следующие подвиды приёмочного тестирования (хотя упоминают их
крайне редко, ограничиваясь в основном общим термином «приёмочное
тестирование»):
– Производственное приёмочное тестирование — выполняемое проектной
командой исследование полноты и качества реализации приложения с точки зрения его
готовности к передаче заказчику. Этот вид тестирования часто рассматривается как
синоним альфа-тестирования.
– Операционное приёмочное тестирование — операционное тестирование,
выполняемое с точки зрения выполнения инсталляции, потребления приложением
ресурсов, совместимости с программной и аппаратной платформой и т.д.
– Итоговое приёмочное тестирование — тестирование конечными
пользователями (представителями заказчика) приложения в реальных условиях

2
эксплуатации с целью вынесения решения о том, требует ли приложение доработок или
может быть принято в эксплуатацию в текущем виде.

Тестирование удобства использования — тестирование, направленное на

исследование того, насколько конечному пользователю понятно, как работать с
продуктом, а также на то, насколько ему нравится использовать продукт. И это не
оговорка — очень часто успех продукта зависит именно от эмоций, которые он
вызывает у пользователей. Для эффективного проведения этого вида тестирования
требуется реализовать достаточно серьёзные исследования с привлечением конечных
пользователей, проведением маркетинговых исследований и т.д.

Тестирование удобства использования и тестирование интерфейса

пользователя — не одно и то же! Например, корректно работающий интерфейс
может быть неудобным, а удобный может работать некорректно.

Тестирование доступности — тестирование, направленное на исследование

пригодности продукта к использованию людьми с ограниченными возможностями
(слабым зрением и т.д.).

Тестирование интерфейса — тестирование, направленное на проверку

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

Тестирование безопасности — тестирование, направленное на проверку

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

Тестирование интернационализации — тестирование, направленное на проверку

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

Тестирование локализации — тестирование, направленное на проверку

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

3
 Тестирование совместимости — тестирование, направленное на проверку
способности приложения работать в указанном окружении. Здесь, например, может
проверяться:
– Совместимость с аппаратной платформой, операционной системой и
сетевой инфраструктурой (конфигурационное тестирование).
– Совместимость с браузерами и их версиями (кросс-браузерное
тестирование). (Cм. также тестирование веб-приложений).
– Совместимость с мобильными устройствами. (См. также тестирование
мобильных приложений).
И так далее.
В некоторых источниках к тестированию совместимости добавляют (хоть и
подчёркивая, что это — не его часть) т.н. тестирование соответствия.

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

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

Тестирование использования ресурсов — совокупность видов тестирования,

проверяющих эффективность использования приложением доступных ему ресурсов и
зависимость результатов работы приложения от количества доступных ему ресурсов.
Часто эти виды тестирования прямо или косвенно примыкают к техникам тестирования
производительности.

Сравнительное тестирование — тестирование, направленное на сравнительный

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

Демонстрационное тестирование — формальный процесс демонстрации

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

Исчерпывающее (избыточное) тестирование — тестирование приложения со

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

Тестирование надёжности — тестирование способности приложения выполнять

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

4
 Тестирование восстанавливаемости — тестирование способности приложения
восстанавливать свои функции и заданный уровень производительности, а также
восстанавливать данные в случае возникновения критической ситуации, приводящей к
временной (частичной) утрате работоспособности приложения.

Тестирование отказоустойчивости — тестирование, заключающееся в эмуляции

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

Тестирование производительности — исследование показателей скорости

реакции приложения на внешние воздействия при различной по характеру и
интенсивности нагрузке. В рамках тестирования производительности выделяют
следующие подвиды:
– Нагрузочное тестирование — исследование способности приложения
сохранять заданные показатели качества при нагрузке в допустимых пределах и
некотором превышении этих пределов (определение «запаса прочности»).
– Тестирование масштабируемости — исследование способности
приложения увеличивать показатели производительности в соответствии с увеличением
количества доступных приложению ресурсов.
– Объёмное тестирование — исследование производительности приложения
при обработке различных (как правило, больших) объёмов данных.
– Стрессовое тестирование — исследование поведения приложения при
нештатных изменениях нагрузки, значительно превышающих расчётный уровень, или
в ситуациях недоступности значительной части необходимых приложению ресурсов.
Стрессовое тестирование может выполняться и вне контекста нагрузочного
тестирования: тогда оно, как правило, называется «тестированием на разрушение» и
представляет собой крайнюю форму негативного тестирования.
– Конкурентное тестирование — исследование поведения приложения в
ситуации, когда ему приходится обрабатывать большое количество одновременно
поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу
данных, память, канал передачи данных, дисковую подсистему и т.д.). Иногда под
конкурентным тестированием понимают также исследование работы многопоточных
приложений и корректность синхронизации действий, производимых в разных потоках.

В качестве отдельных или вспомогательных техник в рамках тестирования

производительности могут использоваться тестирование использования ресурсов,
тестирование надёжности, тестирование восстанавливаемости, тестирование
отказоустойчивости и т.д.

Классификация по техникам и подходам

Позитивное тестирование (рассмотрено ранее).
Негативное тестирование (рассмотрено ранее).

Тестирование на основе опыта тестировщика, сценариев, чек-листов:

– Исследовательское тестирование (рассмотрено ранее).
– Свободное (интуитивное) тестирование (рассмотрено ранее).

5
 Классификация по степени вмешательства в работу приложения:
– Инвазивное тестирование — тестирование, выполнение которого может
повлиять на функционирование приложения в силу работы инструментов тестирования
(например, будут искажены показатели производительности) или в силу вмешательства
в сам код приложения (например, для анализа работы приложения было добавлено
дополнительное протоколирование, включён вывод отладочной информации и т.д.).
Некоторые источники рассматривают инвазивное тестирование как форму негативного
или даже стрессового тестирования.
– Неинвазивное тестирование — тестирование, выполнение которого
незаметно для приложения и не влияет на процесс его обычной работы.

Классификация по техникам автоматизации:

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

Классификация на основе (знания) источников ошибок:

– Тестирование предугадыванием ошибок — техника тестирования, в которой
тесты разрабатываются на основе опыта тестировщика и его знаний о том, какие
дефекты типичны для тех или иных компонентов или областей функциональности
приложения. Может комбинироваться с техникой т.н. «ошибкоориентированного»
тестирования, в котором новые тесты строятся на основе информации о ранее
обнаруженных в приложении проблемах.
– Эвристическая оценка — техника тестирования удобства использования,
направленная на поиск проблем в интерфейсе пользователя, представляющих собой
отклонение от общепринятых норм.
– Мутационное тестирование — техника тестирования, в которой
сравнивается поведение нескольких версий одного и того же компонента, причём часть
таких версий может быть специально разработана с добавлением ошибок (что позволяет
оценить эффективность тест-кейсов — качественные тесты обнаружат эти специально
добавленные ошибки). Может комбинироваться со следующим в этом списке видом
тестирования (тестированием добавлением ошибок).
– Тестирование добавлением ошибок — техника тестирования, в которой в
приложение специально добавляются заранее известные, специально продуманные
ошибки с целью мониторинга их обнаружения и устранения и, таким образом,
формирования более точной оценки показателей процесса тестирования. Может
комбинироваться с предыдущим в этом списке видом тестирования (мутационным
тестированием).

6
 Классификация на основе среды выполнения:
– Тестирование в процессе разработки — тестирование, выполняемое
непосредственно в процессе разработки приложения и/или в среде выполнения,
отличной от среды реального использования приложения. Как правило, выполняется
самими разработчиками.
– Операционное тестирование — тестирование, проводимое в реальной или
приближенной к реальной операционной среде, включающей операционную систему,
системы управления базами данных, серверы приложений, веб-серверы, аппаратное
обеспечение и т.д.

Классификация на основе выбора входных данных:

– Тестирование на основе классов эквивалентности — техника тестирования,
направленная на сокращение количества разрабатываемых и выполняемых тест-кейсов
при сохранении достаточного тестового покрытия. Суть техники состоит в выявлении
наборов эквивалентных тест-кейсов (каждый из которых проверяет одно и то же
поведение приложения) и выборе из таких наборов небольшого подмножества тест-
кейсов, с наибольшей вероятностью обнаруживающих проблему.
– Тестирование на основе граничных условий — инструментальная техника
тестирования на основе классов эквивалентности, позволяющая выявить
специфические значения исследуемых параметров, относящиеся к границам классов
эквивалентности. Эта техника значительно упрощает выявление наборов
эквивалентных тест-кейсов и выбор таких тест-кейсов, которые обнаружат проблему с
наибольшей вероятностью.
– Доменное тестирование — техника тестирования на основе классов
эквивалентности и граничных условий, позволяющая эффективно создавать тест-кейсы,
затрагивающие несколько параметров (переменных) одновременно (в том числе с
учётом взаимозависимости этих параметров). Данная техника также описывает подходы
к выбору минимального множества показательных тест-кейсов из всего набора
возможных тест-кейсов.
– Попарное тестирование — техника тестирования, в которой тест-кейсы
строятся по принципу проверки пар значений параметров (переменных) вместо того,
чтобы пытаться проверить все возможные комбинации всех значений всех параметров.
Эта техника является частным случаем N-комбинационного тестирования и позволяет
существенно сократить трудозатраты на тестирование (а иногда и вовсе сделать
возможным тестирование в случае, когда количество «всех комбинаций всех значений
всех параметров» измеряется миллиардами).

Попарное тестирование — это НЕ парное тестирование

– Тестирование на основе ортогональных массивов — инструментальная

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

7
 Ортогональные массивы — это НЕ ортогональные матрицы. Это
совершенно разные понятия!
Комбинаторные техники тестирования расширяют и дополняют только что
рассмотренный список видов тестирования на основе выбора входных данных.

Тестирование на основе кода.

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

Иногда эту технику тестирования также называют «тестированием по

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

– Инспекция (аудит) кода — семейство техник повышения качества

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

Тестирование на основе структур кода

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

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

Тестирование на основе (моделей) поведения приложения:

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

9
 «параллельное тестирование» также может использоваться для обозначения способа
проведения тестирования, когда несколько тестировщиков или систем автоматизации
выполняют работу одновременно, т.е. параллельно. Очень редко (и не совсем верно) под
параллельным тестированием понимают мутационное тестирование.
– Тестирование на основе случайных данных — техника тестирования
(по методу чёрного ящика), в которой входные данные, действия или даже сами тест-
кейсы выбираются на основе (псевдо)случайных значений так, чтобы соответствовать
операционному профилю — подмножеству действий, соответствующих некоей
ситуации или сценарию работы с приложением.
– A/B-тестирование (сплит-тестирование) — техника тестирования, в
которой исследуется влияние на результат выполнения операции изменения одного из
входных параметров. Однако куда чаще можно встретить трактовку A/B-тестирования
как технику тестирования удобства использования, в которой пользователям случайным
образом предлагаются разные варианты элементов интерфейса, после чего оценивается
разница в реакции пользователей.

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

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

Общая универсальная логика последовательности тестирования состоит в

том, чтобы начинать исследование каждой задачи с простых позитивных тест-кейсов, к
которым постепенно добавлять негативные (но тоже достаточно простые). Лишь после
того, как наиболее типичные ситуации покрыты простыми тест-кейсами, следует
переходить к более сложным (опять же, начиная с позитивных). Такой подход — не
догма, но к нему стоит прислушаться, т.к. углубление на начальных этапах в негативные
(к тому же — сложные) тест-кейсы может привести к ситуации, в которой приложение
отлично справляется с кучей неприятностей, но не работает на элементарных
повседневных задачах. Таким образом суть универсальной последовательности:
1) простое позитивное тестирование
2) простое негативное тестирование
3) сложное позитивное тестирование
4) сложное негативное тестирование

Последовательность тестирования, построенная по иерархии компонентов:

– Восходящее тестирование — инкрементальный подход к
интеграционному тестированию, в котором в первую очередь тестируются
низкоуровневые компоненты, после чего процесс переходит на всё более и более
высокоуровневые компоненты.
– Нисходящее тестирование — инкрементальный подход к
интеграционному тестированию, в котором в первую очередь тестируются

10
высокоуровневые компоненты, после чего процесс переходит на всё более и более
низкоуровневые компоненты.
– Гибридное тестирование — комбинация восходящего и нисходящего
тестирования, позволяющая упростить и ускорить получение результатов оценки
приложения.

Последовательность тестирования, построенная по концентрации внимания

на требованиях и их составляющих:
1) Тестирование требований, которое может варьироваться от беглой оценки
в стиле «всё ли нам понятно» до весьма формальных подходов, в любом случае
первично по отношению к тестированию того, как эти требования реализованы.
2) Тестирование реализации функциональных составляющих требований
логично проводить до тестирования реализации нефункциональных составляющих, т.к.
если что-то просто не работает, то проверять производительность, безопасность,
удобство и прочие нефункциональные составляющие бессмысленно, а чаще всего и
вовсе невозможно.
3) Тестирование реализации нефункциональных составляющих требований
часто становится логическим завершением проверки того, как реализовано то или иное
требование.

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

явных предпосылок к реализации иной стратегии. Такие сценарии могут
видоизменяться и комбинироваться (например, весь «типичный общий сценарий 1»
можно повторять на всех шагах «типичного общего сценария 2»).
Типичный общий сценарий 1:
1) Дымовое тестирование.
2) Тестирование критического пути.
3) Расширенное тестирование.

Типичный общий сценарий 2:

1) Модульное тестирование.
2) Интеграционное тестирование.
3) Системное тестирование.

Типичный общий сценарий 3:

1) Альфа-тестирование.
2) Бета-тестирование.
3) Гамма-тестирование.

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

Классификация тестирования согласно книге «Foundations of Software Testing:
ISTQB Certification» (Erik Van Veenendaal, Isabel Evans) представляет собой комбинацию
ранее рассмотренных видов и техник.

11
 Классификация тестирования согласно ISO/IEC/IEEE 29119-4 содержит много
новых определений. Здесь встречаются как уже рассмотренные пункты, так и ранее не
рассмотренные (отмечены пунктирной линией).

12
13
 Краткие определения не рассмотренных ранее видов тестирования:
Тестирование на основе дерева классификаций — техника тестирования (по
методу чёрного ящика), в которой тест-кейсы создаются на основе иерархически
организованных наборов эквивалентных входных и выходных данных.

Тестирование на основе синтаксиса — техника тестирования (по методу

чёрного ящика), в которой тест-кейсы создаются на основе определения наборов
входных и выходных данных.

Комбинаторные техники или комбинаторное тестирование — способ

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

Тестирование по графу причинно-следственных связей — техника

тестирования (по методу чёрного ящика), в которой тест-кейсы разрабатываются на
основе графа причинно-следственных связей (графического представления входных
данных и воздействий со связанными с ними выходными данными и эффектами).

Тестирование по потоку данных — семейство техник тестирования,

основанных на выборе отдельных путей из потока управления с целью исследования
событий, связанных с изменением состояния переменных. Эти техники позволяют
обнаружить такие ситуации, как: переменная определена, но нигде не используется;
переменная используется, но не определена; переменная определена несколько раз до
того, как она используется; переменная удалена до последнего случая использования.
Здесь придётся немного погрузиться в теорию. Над переменной в общем
случае может выполняться несколько действий (покажем на примере переменной x):
• объявление (declaration): int x;
• определение (definition, d-use): x = 99;
• использование в вычислениях (computation use, c-use): z = x + 1;
• использование в условиях (predicate use, p-use): if (x > 17) { … };
• удаление (kill, k-use): x = null;

Теперь можно рассмотреть техники тестирования на основе потока данных.

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

15
 Лекция 20
Тестирование программного обеспечения (ч.4)

Планирование тестирования
В общем случае планирование тестирования включает следующие основные
действия:
– создание тест-плана;
– продумывание стратегии тестирования;
– оценка трудозатрат и рисков;
– прогнозирование сроков и составление графика проведения
тестирования;
– определение используемых инструментов.

Тест-план – это основной документ в тестировании, относящийся к

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

Типовой схематичный шаблон тест-плана

1
 При планировании тестирования важно определять критерий входа и
критерий выхода. Критерий входа показывает, когда нужно начинать тестирование.
Обычно критерии входа покрывают:
– готовность и доступность тестового окружения;
– готовность средства тестирования в окружении;
– доступность тестируемого кода;
– доступность тестовых данных.

Критерий выхода определяет, когда нужно прекращать тестирование,

например по окончании уровня тестирования или когда набор тестов достиг
определенной цели.
Обычно критерии выхода покрывают:
– тщательность оценки, например покрытие кода, функциональности или
рисков;
– оценку плотности дефектов или измерение надежности;
– стоимость;
– остаточные риски, такие как неисправленные дефекты или недостаток
тестового покрытия какой-либо области;
– план, основанный на времени выхода ПО на рынок.

Стратегия тестирования может быть частью общего тест-плана или

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

Неотъемлемой частью планирования тестирования является стратегия

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

2
сотрудников, нескоординированные коммуникации с заказчиком, недостаток тестовых
инструментов, тестовых устройств, слабое понимание специалистами предметной
области, нескоординированное руководство, ненадлежащее планирование и т. д.

Помимо оценки рисков, требуется оценить трудозатраты в тестировании.

Зачастую выделяют два подхода к оценке трудозатрат:
– основанный на метриках: оценка трудозатрат основана на метриках
предыдущих или сходных проектов или на типичных значениях;
– основанный на экспертной оценке: оценка задач производится владельцем
этих задач или экспертом, например тестировщиком, который будет выполнять задачу
и уже имеет опыт работы с подобными задачами.

Как только оценка трудозатрат выполнена, определяют ресурсы и составляют

график тестирования. На этом этапе фиксируются сроки тестирования, которые при
успешном раскладе не должны быть превышены.

Работы по тестированию могут зависеть от многих факторов, включая:

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

В рамках планирования тестирования и проекта в целом также выбирают

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

Мониторинг и контроль
Мониторинг процесса тестирования – это постоянное наблюдение и
отслеживание процесса, его активностей и результатов в определенных временных
рамках. Мониторинг необходим для получения результата и обзора процесса
тестирования. Отслеживание может быть проведено вручную или автоматически при
помощи специальных инструментов. На основе полученной информации могут быть
измерены критерии выхода, например покрытие, плотность дефектов и т. д.

Для оценки результатов мониторинга используют всевозможные метрики

прогресса тестирования по сравнению с запланированным графиком и выделенным
бюджетом.
В качестве примеров тестовых метрик можно привести:
– процент работ по подготовке тестовых сред;
– процентное соотношение запланированных и подготовленных
тестовых сценариев;
– количество выполненных и невыполненных тестовых сценариев;
– процент пройденных успешно и проваленных тестовых сценариев;

3
 – процент заблокированных тестовых сценариев;
– процент неактуальных тестовых сценариев;
– количество найденных и исправленных дефектов;
– плотность дефектов;
– количество дефектов по критичности;
– количество переоткрытых в ходе повторного тестирования дефектов;
– интенсивность отказов;
– тестовое покрытие требований, рисков или кода;
– стоимость тестирования и др.

В рамках мониторинга тестирования наиболее часто используют так

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

Матрицу трассировки составляют в несколько этапов:

1) составление нумерованного списка требований к приложению;
2) составление нумерованного списка тестов;
3) непосредственное составление матрицы трассировки.

Рассмотрим процесс составления матрицы трассировки на примере

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

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

4
 Далее составим нумерованный список тестов, которые написаны для покрытия
перечисленных требований.

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

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

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

В рамках контроля тестирования могут приниматься решения на основании

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

5
 В ходе тестирования и по его завершении обязательным является составление
отчётности по тестированию. Формы отчетности могут быть самыми разными и, как
правило, зависят от потребностей и специфики проекта. Отчеты могут предоставить
заинтересованным лицам следующие сведения:
– сроки достижения критериев выхода;
– результаты анализа метрик тестирования для принятия дальнейших
решений.

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

решение о продолжении тестирования или его завершении, а также оцениваются
возможные риски и составляется общая картина качества тестируемого ПО.

Завершение процесса тестирования также включает в себя несколько видов

активности.

Во-первых, необходимо проверить завершение выполнения всех

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

Во-вторых, все артефакты тестирования (тесты, не исправленные по разным

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

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

их разрешения должны быть учтены, систематизированы, зафиксированы в виде
полезных статей/документов.

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

6
 Инструменты управления тестами

Инструмент Описание
Sitechco Веб-версия бесплатна и доступна на русском и английском языках.
Система позволяет создавать, редактировать и хранить чек-листы
(листы проверок, в которых, в отличие от тестов, отсутствует
подробное описание шагов и предусловий).
Результаты прохождения проверок могут документироваться, а также
есть возможность формировать отчеты. Подробнее об инструменте:
http://sitechco.ru/
TestLink Инструмент с открытым исходным кодом, позволяющий создавать и
поддерживать несколько проектов. Внутри каждого проекта могут
создаваться тесты, тестовые наборы и тест-планы. Результаты
выполнения тестов можно сохранять, благодаря чему легко
формировать различную отчетность, которая может быть разослана
заинтересованным лицам. Каждый пользователь в системе играет
свою роль, что дает возможность разделять функции обычных
тестировщиков и тест-менеджеров. Интеграция с системами
управления дефектами. Подробнее об инструменте: http://testlink.org/
TestRail Данный инструмент является платным. Бесплатен лишь доступ к
системе в течение 30 дней. По аналогии с остальными инструментами
здесь есть возможность создавать и импортировать тесты,
группировать их в тестовые наборы, создавать тест-планы, строить
отчёты
Подробнее об инструменте: http://www.gurock.com/testrail/
HP Quality Платный инструмент для управления процессом контроля качества на
Center различных этапах разработки ПО. Продукт включает в себя
несколько модулей: Requirements management, Management, Test Plan,
Test Lab, Defects management. Лицензия может быть приобретена как
для отдельных модулей, так и для всей системы в целом в
зависимости от потребностей проекта. Подробнее об инструменте:
http://www8.hp.com/ru/ru/software-
solutions/quality-center-quality-management/
Rational Платный инструмент, который подходит как для управления
Quality тестированием и тестами, так и для управления проектом в целом.
Manager Данный инструмент также хорошо подходит для управления
требованиями. Кроме того, есть возможность связывать между собой
различные браузеры, базы данных, операционные системы, т. е.
создавать различные тестовые конфигурации. Имеется бесплатная
пробная версия на 90 дней.
Подробнее об инструменте: http://www-03.ibm.com/software/
products/ru/ratiqualmana

7
 Управление дефектами
Дефект (баг или bug, от англ. «жук») – ошибка в программе или системе, которая
приводит к неожиданному и некорректному поведению и, как следствие, к
некорректному ожидаемому результату.
Помимо необходимости управлять тестами в рамках процесса тестирования
также существует необходимость управления дефектами. Для того чтобы понять, с
чего начинается дефект, рассмотрим его жизненный цикл.

Жизненный цикл дефекта (bug workflow) – это последовательность этапов,

которые проходит дефект с момента его создания до момента закрытия и завершения
работ по нему. Зачастую жизненный цикл зависит от выбранной системы управления
дефектами и специфики проекта.

Наиболее обобщенный жизненный цикл дефекта включает в себя следующие

состояния:
«Открыт» (Open) – статус присваивается автоматически после внесения баг-
репорта, т.е. создания дефекта в системе управления дефектами;
«Исправлен» (Resolved / Fixed) – данный статус присваивается специалистом
разработки после того, как ошибка была устранена;
«Открыт повторно» (Reopened) ‒ данный статус присваивается тестировщиком
при повторном возникновении ошибки после её предварительного исправления;
«Закрыт» (Closed) – дефект получает данный статус после проведения проверки,
которая выявила окончательное исправление.

8
 В жизненный цикл дефекта могут быть добавлены дополнительные статусы,
например «In Progress», чтобы показать, что в данный момент дефект исправляется,
или «Customer verify» ‒ для отражения того, что дефект был проверен заказчиком и
действительно исправлен.
Также может присутствовать статус «Отклонён» (Need More Info / Resolved as
Invalid, Won’t fix, Can’t reproduce или Not a bug) – ошибка была проанализирована
разработчиком или другим участником процесса разработки и по результатам анализа
выявлена недостаточность описания или дефект является дубликатом, не будет
исправлен по согласованию заинтересованных сторон, не может быть воспроизведён
или заведен по ошибке и не является дефектом согласно требованиям к системе.

Для того чтобы дефект появился в системе управления ошибками, его

необходимо правильно создать. Дефект – это такой же документ. Иными словами,
создание дефекта часто называют баг-репортом. Баг-репорт включает в себя
информацию о последовательности действий, которая привела к некорректной работе
тестируемой системы, описание самого некорректного поведения, а также подробное
указание на ожидаемый корректный результат.
Обычно в баг-репорте или описании дефекта содержится следующая
информация:
название проекта – зачастую выставляется автоматически системой управления
ошибками;

наименование найденной ошибки – должно быть лаконичным и содержательным,

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

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

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

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

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

severity (серьезность) – степень негативного влияния дефекта на продукт,

которая выставляется автором дефекта.

Градация серьезности дефектов:

Степень серьезности Описание
Блокирующая (Blocker) • Дефект приводит к невозможности завершить
выполнение бизнес-процесса;
• дефект приводит к непреднамеренному
завершению работы системы, либо к невозможности
запустить систему;
• производительность системы не позволяет
выполнять базовые бизнес-процессы
Критическая (Critical) • Дефект приводит к невозможности завершить
выполнение бизнес-процесса, но возможно завершить
этот процесс обходным путем;
9
 • система не учитывает ограничения в доступе или
другие настройки безопасности;
• дефект приводит к некорректным финансовым
вычислениям или к потере данных в БД
Значительная (Major) • Часто встречающийся дефект, который не ведёт к
потере данных в БД;
• система формирует некорректные сообщения об
ошибке, либо не формирует когда это необходимо
Незначительная (Minor) Дефекты пользовательского интерфейса, которые не
влияют на функционирование системы (грамматические
ошибки, лишние полосы прокрутки, обновления экрана и
т. д.)
Тривиальная (Trivial) Абсолютно незначительный дефект, например лишние
пробелы в тексте, практически незаметные дефекты в
дизайне и т. п.

priority (приоритет) – порядок исправления дефекта, который может быть

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

Градация приоритетов дефекта:

Приоритет Описание
Высокий (High) Требуется срочное исправление
Средний (Medium) Исправление важно, но не является срочным
Низкий (Low) Исправление может быть отложено на достаточно
длительный срок

версия ПО, в которой была найдена ошибка, – является обязательной к указанию

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

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

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

окружение, при котором проводилась проверка, – настройки тестовой среды,

данные тестового клиента;

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

ним можно было без затруднений воспроизвести ошибку.
Слишком краткое и слишком подробное описание зачастую приводят к
трудностям воспроизведения. Не нужно описывать лишние детали, которые никак не
влияют на результат. Перед тем как создать дефект, рекомендуется проанализировать
ошибку, а после формулировки шагов попытаться самостоятельно воспроизвести
дефект по описанному. Если возникли затруднения, то шаги, скорее всего, описаны
неверно и у разработчика возникнут трудности с воспроизведением и исправлением;

10
 фактический результат – описание некорректной работы программного
продукта;

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

Можно оставлять номера документов/ссылки на требования;

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

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

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

различными заинтересованными лицами.

Пример того, как могут соотноситься серьезность и приоритет дефекта.

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

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

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

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

tracking system, или BTS). Такие инструменты выполняют, как правило, следующие
основные функции:
− документирование дефектов и инцидентов, а также вопросов и
предложений по улучшению программного продукта;
− отслеживание хода работ по дефектам и инцидентам;
− сбор статистики.
Кроме того, с помощью систем багтрекинга выполняются и такие действия, как:
− фиксация времени, потраченного на исправление дефекта;
− оформление не только дефектов, но и задач внутри проекта;
− составление отчетности по проекту и т.д.

Описание различных систем управления дефектами

Bug tracking
Описание
system
Atlassian JIRA Гибко настраиваемая платная система управления проектами.
Имеется большое количество всевозможных плагинов, которые
11
 позволяют адаптировать JIRA под нужды конкретного проекта. Есть
возможность делать запросы к системе различными способами,
сохранять запросы в качестве персональных фильтров. При
определенной настройке JIRA способна рассылать уведомления о
создаваемых дефектах/задачах и других действиях участников
проектной команды по почте. Помимо всего прочего имеется
приложение для iPhone, позволяющее в удаленном режиме
отслеживать статус работ по проекту. JIRA может быть
интегрирована с системами контроля версий
Подробнее: https://www.atlassian.com/software/jira
Bugzilla Является предшественником JIRA и свободно распространяется.
Имеет доступ через веб-интерфейс. Имеется возможность
импортировать список багов, отслеживать изменения по дефектам,
создавать отчеты и новые дефекты с выбором нужных полей. Также
имеется интеграция с системами управления версиями
Подробнее: http://www.bugzilla.org/
Redmine Открытое серверное веб-приложение для отслеживания ошибок. С
помощью данного инструмента можно управлять не только
дефектами, но и проектом в целом, создавая задачи внутри проекта.
Как и в других подобных системах, имеется возможность настройки
почтовых уведомлений
Подробнее: http://www.redmine.org/
Mantis Практически чистая BTS, которая распространяется по специальной
лицензии. Для работы системы требуется web-сервер. Исходный код
системы открыт. Имеется функциональность базового управления
проектами без ограничения на их количество и дефектами.
Документация к системе довольно сложна, но настроить под себя
систему все-таки можно. Данная система написана на PHP и является
кроссплатформенной
Подробнее: https://www.mantisbt.org/
Microsoft Test Система является частью комплексного продукта Team Foundation
Manager Server (TFS). Главное преимущество ‒ наличие связки «задача –
дефекты – затраченное время». Имеется возможность записи
прохождения тестов и автосбора информации по дефектам, что
отличает данную систему от других подобных систем
Подробнее: https://msdn.microsoft.com/ru-ru/library/
jj635157.aspx
Trac Система написана на Python и является кроссплатформенной.
Исходный код открыт. Система имеет
возможность работать с различными базами данных. Изначально в
систему включен только базовый функционал, но можно настроить
ее под себя при помощи плагинов
Подробнее: https://trac.edgewall.org/
BugNet Бесплатная система для внесения и последующего отслеживания
ошибок с открытым исходным кодом. Имеется возможность
настройки почтовых уведомлений и экспорта списков оформленных
дефектов, а также функции составления отчётности
12
 Подробнее: http://www.bugnetproject.com/
Phabricator: Бесплатная система отслеживания ошибок, которая является частью
Мaniphest платформы Phabricator, предназначенной для разработки ПО.
Поддерживается работа через web-интерфейс. Задачи можно
создавать через e-mail или URL
Подробнее: http://phabricator.org/

Структура плана испытаний

План испытаний IEEE 829
Описывает базовый набор документов для тестирования программного
обеспечения. Стандарт также определяет форму и содержание тестовых документов.
Стандарт задает планку для индустрии ИТ по организации документирования
процесса тестирования. Разрабатывался с 1977 года и был утвержден в 1983 году, а
затем вновь подтвержден в 1991,1998, 2008 г. Несмотря на свою зрелость, он актуален
и в 21 веке.
В IEEE 829 задается формат и указывается содержимое следующих типов
документов.
1. План тестирования: затронуть такие проблемы планирования, как рамки
работы, разработка графика, кадровое обеспечение и то, какие функции будут
тестироваться.
2. Спецификация проекта тестирования: указать подход, который будет
использоваться для тестирования приложения.
3. Спецификация тестового примера: задать тестовый пример, установленный
проектом тестирования.
4. Спецификация процедуры тестирования: установить этапы, необходимые для
выполнения набора тестов.
5. Отчет о передаче тестируемого элемента: определить тестируемый элемент,
указав локализацию элемента, среду развертывания, а также имя специалиста,
ответственного за тестирование этого элемента.
6. Журнал тестирования: записать важные детали, касающиеся выполнения
теста. Во многих таблицах, показанных в предыдущих главах, содержатся сведения о
выполнении теста.
7. Отчет о происшествиях, возникших в ходе тестирования: документировать
обнаруженные во время тестирования события, которые требуют дополнительного
изучения. Система составления отчетов о неполадках — это один из способов
регистрации сведений.
8. Резюмирующий отчет о тесте: дать общую оценку работе по тестированию.

13
 Лекция 21
Внедрение, сопровождение и эксплуатация программного обеспечения

Использование программного обеспечения является заключительной фазой

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

Внедрение программного обеспечения

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

Процесс поэтапного внедрения программного обеспечения

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

Этап 1. Обследование компании

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

Качественно составленное ТЗ гарантирует точность выполнения работ.

1
 Этап 2. Составление контракта на производство работ
Контракт на производство работ составляется по совместному заключению
заказчика и компании после выполнения анализа ТЗ.
Этот период — оценочный. Поскольку план работ назначен и сроки
определены, компания-исполнитель может оценить всю процедуру в комплексе и
определиться с ценой. Чаще всего первичный этап производится бесплатно или
становится таковым на основании последующего заказа. Цена на выполнение работ
по интеграции программного обеспечения может зависеть от следующих факторов:
 состава и количества рабочих мест, подсистем и модулей;
 проведения дополнительных работ по интеграции с другими
подсистемами и системами, а также сложности ее исполнения;
 объема хранимой в БД информации и ее состояния (работоспособности
и наличие резервных копий).

Этап 3. Создание группы по внедрению ПО

Третий период также входит в подготовительные работы. Компанией-
исполнителем формируется группа внедрения программного обеспечения и
назначаются ответственные.

Этап 4. Инсталляция и наладка ПО

В этот период производится инсталляция программного обеспечения на
серверах и клиентских машинах, подключение связи, а также проверка и наладка
рабочего состояния системы и ее тестирование под нагрузкой. В стандартный
перечень работ по четвертому этапу входит:
 установка и подготовка общесистемного ПО сервера;
 инсталляция и наладка компонентов и функций серверной платформы;
 создание таблиц баз данных, загрузка информации и интеграция;
 перенос БД (при необходимости), конвертация в нужный формат,
наладка и создание рабочих копий ПО, подготовка программ;
 установка и подготовка клиентских машин (общеприкладное и
прикладное ПО);
 интеграция и адаптация с уже имеющимися системами и платформами;
 проверка работоспособности всей системы, тестирование
функционирования комплекса программного обеспечения;
 окончательная настройка по результатам тестирования с целью
получения максимальной производительности и оптимизации работы.
На этом процесс внедрения программного обеспечения завершен, однако
существуют дополнительные процедуры, которые множество компаний называет
постустановочными.

Этап 5. Завершение внедрения и проведение дополнительных работ

Завершение внедрения ПО включает выполнение следующих работ:
 обучение группы специалистов со стороны заказчика работе с новым
ПО — может производится удаленно или на территории заказчика;
 внесение изменений согласно опыту эксплуатации заказчиком нового
ПО;

2
  по окончании внесения условленных изменений и устранения
замечаний подписывается акт сдачи работ и приемки проекта согласно ТЗ, после
чего система передается заказчику и операция по внедрению считается
завершенной.

После интеграции программного обеспечения со стороны заказчика могут

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

Эффективность внедрения стратегии сильно зависит от управленческого

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

Применяются следующие виды контроля:

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

финансовый контроль — учет и анализ расходования финансовых ресурсов,

обеспечение финансовых потребностей организации. В современных системах
управления нередко принципы финансового аудита распространяются на сферу
маркетинга, контроля качества, процессы производства;

бюджетный контроль, включающий разработку системы бюджетов

подразделений организации и их объединение в главный бюджет организации.
Главное назначение этого контроля — связь финансовых ресурсов с результатами
производства.

контроль эффективности систем стимулирования и мотивации,

оценивающий степень заинтересованности работников и менеджеров в решении
задач организации;

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

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

контроль качества, включая оценку уровня качества, соблюдение

стандартов качества, причин отклонений от них.

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

функционировании его на ЭВМ для обработки информации и в получении

3
результатов, являющихся целью его создания, а также, в обеспечении
достоверности и надежности выдаваемых данных.
Программное изделие подобно живому организму должно развиваться во
времени. В процессе эксплуатации большого программного продукта возможно
обнаружение в нем ошибок, и появляется необходимость его модификации и
расширения его функций — дальнейшая разработка ПО.
Продолжением разработки программного обеспечения занимается группа
сопровождения, которая выполняет следующие функции:
− эксплуатационное обслуживание программного обеспечения;
− развитие функциональных возможностей программного обеспечения;
− повышение эксплуатационных характеристик программного
обеспечения;
− тиражирование программного обеспечения;
− перенос программного обеспечения на различные типы
вычислительных средств.

Выявление и исправление ошибок в программном обеспечении, а также его

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

Сопровождение программного обеспечения

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

4
со структурированной документацией на каждый его этап. Но на самом общем
уровне любые процессы сопровождения имеют общие этапы, а именно:
− анализ изменений
− планирование версий
− реализация новой версии системы
− поставка системы заказчику.

Процесс сопровождения начинается при наличии достаточного количества

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

Во время планирования анализируется возможность реализации всех

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

Схема процесса модернизации

В идеале процесс модернизации должен привести к изменению системной

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

Выполнение модернизации

Новые требования должны отражать изменения, вносимые в систему. Ввод в

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

Иногда в экстренных случаях требуется быстрое внесение изменений,

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

В таких случаях быстрая реализация изменений имеет большую важность,

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

Процесс экстренной модернизации системы

Однако этот подход опасен тем, что требования, системная архитектура и

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

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

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

В процессе сопровождения в программное обеспечение вносятся

следующие изменения, значительно различающиеся причинами и
характеристиками:

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

результаты в условиях, ограниченных техническим заданием и документацией.
Обычно ошибки в программировании достаточно легко устранимы, однако ошибки
проектирования стоят дорого и требуют корректировки или
перепрограммирования некоторых компонентов. Самые дорогие исправления
связаны с ошибками в системных требованиях, так как здесь может понадобиться
перепроектирование системы.
Исправление ошибок требуют около 20% общих затрат на сопровождение.
6
 регламентированная документами адаптация программного обеспечения к
условиям конкретного использования, с учетом характеристик внешней среды или
конфигурации аппаратуры, на которой предстоит функционировать программам.
Это может потребоваться при изменении определенных составляющих рабочего
окружения системы, например, аппаратных средств, операционной системы или
программных средств поддержки. Чтобы адаптироваться к этим изменениям,
система должна быть подвергнута определенным модификациям. Адаптация
занимает около 20% общих затрат на сопровождение.

модернизация − расширение функциональных возможностей или улучшение

характеристик решения отдельных задач в соответствии с новым или
дополнительным техническим заданием на программное изделие. В ответ на
организационные или деловые изменения в организации могут измениться
требования к программным средствам. В таких случаях применяется данный тип
сопровождения. Наиболее существенные изменения при этом претерпевает именно
программное обеспечение. Модернизация занимает до 60% общих затрат на
сопровождение.

На практике однозначно четкое разграничение между различными видами

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

Перечисленные типы сопровождения широко используются, хотя им подчас

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

Модернизация ПО 60%
Адаптация 20% Исправление ошибок 20%

7
 Как уже говорилось выше, 60% сопровождения связано с выполнением
новых требований, 20% отводится на изменения системы с целью адаптации к
новому окружению и 20% связано с исправлением ошибок.
Из этого можно определить, что исправление ошибок не является самым
распространенным видом сопровождения. Модернизация системы в соответствии
с новым рабочим окружением либо в соответствии с новыми требованиями более
эффективна. Поэтому сопровождение само по себе является естественным
процессом продолжения разработки системы со своими процессами
проектирования, реализации и тестирования.

Затраты на сопровождение программного обеспечения

Первый вид изменений (исправление ошибок) является непредсказуемым и
его трудно регламентировать.
Остальные виды корректировок носят упорядоченный характер и проводятся
в соответствии с заранее подготавливаемыми планами и документами. Эти
корректировки в наибольшей степени изменяют программные изделия и требуют
наибольших затрат.
Поэтому изменения, обусловленные ошибками, в большинстве случаев
целесообразно по возможности накапливать и реализовывать их, приурочивая к
изменениям, регламентированным модернизациями.
Однако некоторые ошибки вызывают необходимость срочного исправления
программ. В этих случаях допустимо некоторое отставание корректировки
документации при более срочном и регистрируемом исправлении самих программ.
Сопровождение программ — это «ложка дегтя» для каждого программиста,
всегда помеха при начале разработки какого-либо нового проекта, заставляющая
отвлекаться от его разработки и возвращаться к старым программам и старым
проблемам.

Что делает сопровождение программного обеспечения крайне

непривлекательным? Это плохо документированный код, недостаточно полное
начальное проектирование и отсутствие внешней документации.

Если все этапы жизненного цикла разработки программного обеспечения

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

Значительная часть бюджета большинства организаций уходит на

сопровождение ПО, а не на само использование программных систем. В 1980-х
годах было обнаружено, что во многих организациях по меньшей мере 50% всех
средств, потраченных на программирование, идет на развитие уже существующих
систем. При этом от 65% до 75% средств общего бюджета расходуется на
сопровождение. Так как предприятия заменяют старые системы коммерческим ПО,
например, программами планирования ресурсов, эти цифры никак не будут
уменьшаться. Поэтому можно утверждать, что изменение ПО все еще остается
доминирующим в статье затрат организаций на программное обеспечение.

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

Можно получить значительную общую экономию средств, если заранее

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

Ключевые факторы, которые определяют стоимость разработки и

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

2. Ответственность согласно контракту. Контракт на сопровождение

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

3. Квалификация специалистов. Специалисты, занимающиеся

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

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

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

Последняя проблема, а именно нарушение структуры, является самой

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

Прогнозирование сопровождения
Менеджеры терпеть не могут сюрпризов, особенно если они выливаются в
непредсказуемо высокие затраты. Поэтому лучше предусмотреть заранее, какие
изменения возможны в системе, с какими компонентами системы будет больше
всего проблем при сопровождении, а также рассчитать общие затраты на
сопровождение в течение определенного периода времени.

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

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

10
 Прогнозирование сопровождения

Прогнозирование количества запросов на изменения системы зависит от

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

1. Количество и сложность системных интерфейсов. Чем больше

системных интерфейсов и чем более сложными они являются, тем выше
вероятность изменений в будущем.

2. Количество изменяемых системных требований. Требования,

отражающие деловую сферу или стандарты организации, чаще изменяются, чем
требования, описывающие предметную область.

3. Бизнес-процессы, в которых используется данная система. По мере

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

Чтобы корректно спрогнозировать процесс сопровождения, нужно знать

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

После введения системы в эксплуатацию появляются данные, позволяющие

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

2. Среднее время, потраченное на анализ причин системных сбоев и отказов.

Этот показатель пропорционален количеству системных компонентов, в которые
требуется внести изменения. Если этот показатель возрастает, система требует
многочисленных изменений.

3. Среднее время, необходимое на реализацию изменений. Не следует путать

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

4. Количество незавершенных запросов на изменения. С возрастанием

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

Для определения стоимости сопровождения используется предварительная

информация о запросах на изменения и прогнозирование относительно удобства
сопровождения системы. В решении этого вопроса большинству менеджеров
поможет также интуиция и опыт.

Стандарт ISO/IEK 14764:2006

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

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

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

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

Общая структура процесса сопровождения основана на цикле Деминга PDCA

(Plan — Do — Check — Analyze) или «планируй — делай — проверяй —
анализируй»

Формирование процесса сопровождения начинается с разработки концепции

сопровождения. Такой документ по стандарту должен содержать следующие
разделы:
1. Область сопровождения программного средства.
1.1. Типы выполняемого сопровождения.
1.2. Сопровождаемый уровень документов.
1.3. Реакция (чувствительность) на сопровождение (определение
ожиданий к сопровождению заказчика).
1.4. Обеспечиваемый уровень обучения персонала.
1.5. Обеспечение поставки продукта.
1.6. Организация справочной службы («горячей линии»).

2. Практическое применение (адаптация) данного процесса.

3. Определение организаций (лиц), ответственных за сопровождение.

4. Оценка стоимости сопровождения:

4.1. Проезд до места расположения пользователя.
4.2. Обучение как сопроводителей, так и пользователей.
4.3. СПИ (среда программной инженерии) и СТПС (среда тестирования
программного средства) и их ежегодное сопровождение.
4.4. Персонал (зарплата и премии).

Должен быть сформирован соответствующий план сопровождения. Этот

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

13
запросы на модификацию (изменения) или сообщать об ошибках, сбоях и
проблемах.

Стандарт предлагает следующий состав такого плана:

a). Введение:
− описание сопровождаемой системы;
− определение исходных состояний программного средства;
− описание уровня требуемой поддержки;
− определение организаций, осуществляющих сопровождение;
− описание любых условий (протоколов), согласованных между
заказчиком и поставщиками;

b). Концепция сопровождения (уже кратко описанная выше):

− описание концепции;
− описание уровня поддержки системы;
− установление периода поддержки;
− адаптация (практическое применение) процесса сопровождения;

c). Организационные работы и работы по сопровождению:

1. роли и обязанности сопроводителя до поставки программного продукта:
− реализация процесса;
− определение инфраструктуры процесса;
− установление процесса обучения;
− установление процесса сопровождения;

2. роли и обязанности сопроводителя после поставки программного

продукта:
− реализация процесса;
− анализы проблем и модификаций (изменений);
− реализация (внесение) модификаций (изменений);
− рассмотрение и принятие модификаций (изменений);
− перенос программного средства в новую среду;
− снятие программного средства с эксплуатации;
− решение проблем (включая справочную службу);
− при необходимости — обучение персонала (сопроводителя и
пользователя);
− усовершенствование процесса;

3. роль пользователя:
− приемочные испытания;
− взаимосвязи (интерфейсы) с другими организациями;

d). Ресурсы:
1. персонал:
состав персонала для конкретного проекта; Структура, отвечающая за
сопровождение, должна проводить общую деятельность по бизнес-планированию,

14
касающуюся бюджетирования, финансового менеджмента и управления
человеческими ресурсами в области сопровождения.

2. программные средства:
определение программных средств, необходимых для поддержки
эксплуатации системы (с учетом системных требований и требований к СПИ,
СТПС и инструментальным средствам);

3. технические средства:
определение технических средств, необходимых для поддержки
эксплуатации системы (с учетом системных требований и требований к СПИ,
СТПС и инструментальным средствам);

4. оборудование (аппаратура):
определение требований к оборудованию (аппаратуре) системы (помимо
технических средств вычислительной техники);

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

6. данные;
7. другие требования к ресурсам (при необходимости);

e). Процесс (как должна быть выполнена конкретная деятельность):

1. процесс, выполняемый сопроводителем (приводят общее описание
процесса без детализации в плане сопровождения всего процесса);
2. процесс адаптации (практического применения сопровождения к условиям
проекта);

f). Обучение:
1. определение уровня обучения, необходимого для сопроводителя и
пользователей;

g). Протоколы и отчеты по сопровождению:

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

15
 4. контрольные данные, собранные при работах по сопровождению.

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

Снятие программного средства с эксплуатации и сопровождения должно

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

При снятии программного продукта с сопровождения следует определить

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

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

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

В содержание плана необходимо включить:

— анализ требований к снятию с сопровождения и эксплуатации;
— оценка влияния снятия с сопровождения программного продукта на
систему;
— установка программного продукта, заменяющего снимаемый (при его
наличии);
— график и программа снятия программного продукта с сопровождения и
эксплуатации;

16
 — определение и документирование всех процедур по снятию с
сопровождения и эксплуатации;
— определение сроков прекращения полной или частичной поддержки
сопровождения;
— требования по архивации версии и модификаций программного продукта
и соответствующих документов;
— определение сроков перехода, при необходимости, к новой версии
программного продукта;
— требования по доступу к архивным копиям данных проекта программного
продукта.

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

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

17
 Лекция 22
Управление конфигурацией и изменениями при разработке
программного обеспечения

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

книжных издательствах и пр. существуют склады. Основная задача склада –
обеспечить хранение и доступ к материальным активам: товарам, изделиям, книгам и
пр. То есть различных материальных активов становится так много, что необходима
специальная служба по их учету.
Оказывается, что недостаточно складывать, например, все, имеющиеся в
книгоиздательстве книги в специальную комнату и выдавать их владельцам тиража,
когда они за ними придут. Книг оказывается очень много, а процедура выдачи тиража
– не совсем тривиальной. Нужно, чтобы владелец принес большое количество
сопроводительных документов, и все они должны быть проверены перед выдачей книг.
А на самом складе необходимо поддерживать порядок, чтобы было возможно быстро
найти нужные книги (как показывает опыт, они могут там довольно долго находиться).
Еще более сложная процедура работы с книгами в библиотеке – там добавляются
еще каталоги, распределенные книжные хранилища, необходимость поддерживать
хорошее состояние книг, а также контролировать возврат их в библиотеку после
определенного срока. Аналогичным образом работает склад на любом заводе, фабрике
и т.д.
Рассмотрим теперь проект по разработке программного обеспечения. Что в нем
является аналогом материальных активов на обычном производстве? Определенно, не
столы и стулья, которыми пользуются разработчики. И даже не компьютеры, запчасти
к ним и прочее оборудование.
Учета и контроля, сродни складскому, требуют файлы проекта. В программном
проекте их очень много – сотни и тысячи даже для относительно небольших проектов.
Ведь создать новый файл очень легко. Многие технологии программирования
поддерживают стиль, когда, например, для каждого класса создается свой отдельный
файл.

Файл – это виртуальная информационная единица.

В чем главное отличие файла от материальных единиц учета? В том, что у файла
может быть версия, и не одна, и породить эти версии очень легко – достаточно
скопировать данный файл в другое место на диске. Тогда как материальные предметы
существуют на складе сами по себе, и для них нет понятия версии. Да, может быть
несколько однотипных предметов, разных заготовок изделия различной степени
готовности. Но все это не то…..

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

Часто в программном проекте начинают происходить мистические и загадочные

события.
1
  Тщательно оттестированная программа на показательных испытаниях не
работает
 Функциональность, о которой долго просил заказчик и которая была,
наконец, добавлена в продукт, и новая версия торжественно отослана заказчику,
таинственным образом исчезла из продукта.
 На компьютере разработчика программа работает, а у заказчика – нет….

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

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

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

Выделим две основные задачи в конфигурационном управлении – управление

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

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

основе специальных программных пакетов – средств версионного контроля.
Существует большое количество таких средств – Microsoft Visual SourceSafe, IBM
ClearCase, CVN, subversion и др.

Управление сборками – это автоматизированный процесс трансформации

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

Единицы конфигурационного управления

Так чем же мы управляем в рамках этой деятельности? Любыми ли файлами,
которые имеются в проекте? Нет, не любыми, а только теми, которые изменяются.
Например, файлы с используемым в проекте покупным ПО должны себе спокойненько
покоиться на CD-дисках или в локальной сети. Книги, документы с внешними
стандартами, используемыми в проекте (например, в телекоммуникациях очень много
разных стандартов на сетевые интерфейсы) и пр. также должны просто храниться там,
где каждый желающий их может взять. Как правило, такой информации в проекте
2
немного, но, разумеется, она должна быть в порядке и ради этого специальный вид
деятельности в проекте не нужен.

Итак, конфигурационное управление имеет дело с меняющимися в процессе

продуктами, состоящими из наборов файлов. Такие продукты принято называть
единицами конфигурационного управления (configuration management items).
Например, это может быть:
1. пользовательская документация;
2. проектная документация;
3. исходные тексты ПО;
4. пакеты тестов;
5. инсталляционные пакеты ПО;
6. тестовые отчеты.

У каждой единицы конфигурационного управления должно быть следующее:

1. Структура – набор файлов. Например, пользовательская документация в
html должна включать индекс-файл и набор html-файлов, а также набор вынесенных
картинок (gif или jpeg-файлы). Эта структура должна быть хорошо определена и
отслеживаться при конфигурационном управлении – что все файлы не потеряны и
присутствуют, имеют одинаковую версию, корректные ссылки друг на друга и т.д.

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

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

3. Практика конфигурационного управления – кто и в каком режиме, а также в

какое место выкладывает новую версию элемента конфигурационного управления в
средство управления версиями, правила именования и комментирования элемента в
этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые
правила, связанные, например, с правилами изменения тестов и тестовых пакетов при
изменении кода.

4. Автоматическая процедура контроля целостности элемента – например,

сборка для исходных текстов программ. Есть не у всех элементов, например, может не
быть у документации, тестовых пакетов.

Элементы конфигурационного
управления могут образовывать
иерархию.

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

Управление версиями составных конфигурационных объектов.

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

Остановимся чуть подробнее на втором случае.

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

В качестве примера можно рассмотреть следующую структуру разделения

проекта на ветки.
 V1.0 – ветвь, соответствующая выпущенному релизу. Внесение изменений
в такие ветви запрещены, и они хранят образ кода системы на момент выпуска релиза.
 Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к
определенной версии. Подобные ветви ответвляются от исходной версии, а не от
основной ветви и замораживаются сразу после выхода пакета исправлений.
 Upcoming (V1.1) – ветвь, соответствующая релизу, готовящемуся к
выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило,
действуют более строгие правила и работа в них ведется более формально.
 Mainline – ветвь, соответствующая основному направлению развития
проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов.
 WCF Experiment – ветвь, созданная для проверки некоторого технического
решения, перехода на новую технологию, или внесения большого пакета изменений,
потенциально нарушающих работоспособность кода на длительное время. Такие
ветви, как правило, делаются доступными только для определенного круга
разработчиков и убиваются по завершению работ после интеграции с основной
веткой.

Управление сборками
Итак, почему же процедура компиляции и создания exe, dll файлов по
исходникам проекта – такая важная процедура? Потому что она многократно в день
выполняется каждым разработчиком на его собственном компьютере, с его
собственной версией проекта.

4
 При этом могут отличаться:
 набор подпроектов, собираемых разработчиком; он может собирать не весь
проект, а только какую-то его часть; другая часть либо им не используется вовсе, либо
не пересобирается очень давно, а по факту она давно изменилась;
 параметры компиляции.

При этом если не собирать регулярно итоговую версию проекта, то общая

интеграция может выявить много разных проблем:
 несоответствие друг другу различных частей проекта;
 наличие специфических ошибок, возникших из-за того, что отдельные
проекты разрабатывались без учета параметров компиляции (в частности, переход в
Visual Studio c debug на release версию часто сопровождается появлением
многочисленных проблем).

В связи с этим процедуру сборки проекта часто автоматизируют, т.е. выполняют

не из среды разработки, а из специального скрипта – build-скрипта. Этот скрипт
используется тогда, когда разработчику требуется полная сборка всего проекта. А
также он используется в процедуре непрерывной интеграции (continues integration) –
то есть регулярной сборке всего проекта (в основном – каждую ночь). Процедура
непрерывной интеграции, как правило, включает в себя и регрессионное
тестирование, и часто – создание инсталляционных пакетов.

Общая схема автоматизированной сборки

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

версию продукта, так что результаты регулярной сборки оказываются очень
востребованы. Кроме того, наличие базовой, актуальной, целостной версии продукта
позволяет организовать разработку в итеративно-инкрементальном стиле, то есть на
основе внесения изменений. Такой стиль разработки называется baseline-метод.

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

5
 Baseline может быть совсем простой – веткой в средстве управления версиями,
где разработчики хранят текущую версию своих исходных кодов. Единственным
требованием в этом случае может быть лишь общая компилируемость проекта.

Но поддержка baseline может быть и сложной формальной процедурой:

Baseline может также поддерживаться непрерывной интеграцией.

Важно, что Baseline (особенно в случае с программными активами) не должна

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

Методологии управления конфигурацией

Рассмотрим два подхода к организации процессов управления конфигурациями
и изменениями — основанный на Information Technology Infrastructure Library (ITIL) и
предлагаемый IBM Rational Unified Process (RUP).

Чтобы эффективно бороться с проблемами разработки, необходимо

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

RUP — методология коллективной разработки, которая рассчитана на

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

В «чистом» виде RUP может оказаться слишком тяжеловесной для внедрения. В

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

Rational Unified Process — итерационный процесс. Создавать современные

сложные программные средства последовательно (сначала определяя все проблемы,
затем — проектные решения, потом кодируя и, наконец, тестируя результат)
невозможно. Такой подход, называемый «каскадным» или «водопадом», в
современной информационной индустрии себя не оправдывает, поскольку не
позволяет отслеживать изменения требований к программным продуктам в ходе
разработки.

Эффективной альтернативой «водопаду» служит итерационный процесс

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

Динамическая структура RUP состоит из четырех фаз: начальная стадия

(Inception), уточнение (Elaboration), конструирование (Construction) и внедрение
(Transition).

7
 Фазы могут подразделяться на итерации. Переход с одной на другую фазу
осуществляется только после выполнения задач предыдущей фазы и представляет
собой контрольную точку (milestone) процесса.

Статическая структура RUP состоит из процессов, в которые группируются

работы, задачи, артефакты и роли. Они описывают, кто, что, как и когда выполняет.

Интеграцию всех участников обеспечивает один из основных процессов —

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

Библиотека ITIL представляет собой набор книг по наиболее важным видам

деятельности ИТ-подразделений, составленных на основании лучших примеров
мирового опыта. Для наших целей важны три книги:
«Управление конфигурацией» (Configuration Management)
«Управление изменениями» (Change Management)
«Управление релизами» (Release Management).

Основными чертами ITIL являются представление об ИТ-деятельности как о

бизнесе и процессно-ориентированном подходе к управлению ИТ. Все процессы
рассматриваются во взаимосвязи, и большое значение придается правильному
внедрению процессов.
Безусловно, ITIL обеспечивает значительно более широкий «охват», чем RUP,
поскольку ориентирована на управление ИТ в целом, тогда как методология RUP
изначально ориентировалась на разработку программного обеспечения.

С точки зрения ITIL существуют следующие взаимосвязанные процессы:

 процесс управления конфигурациями
 процесс управления изменениями
 процесс управления релизами

В RUP управление релизами отдельно не выделяется (как и в ISO 12207), а его

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

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

актуальной достоверной информации об ИТ-инфраструктуре — ее элементах и их
взаимосвязях. Эта информация используется при анализе проблем и принятии
решений по изменениям, а хранится она в конфигурационной базе данных
(configuration management data base, CMDB).

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

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

8
 Состав CMDB приходится ограничивать некоторыми пределами. Обычно в нее
включаются документация, технические средства и программы, используемые в ИТ-
инфраструктуре организации. Также в CMDB могут входить процедуры и ИТ-сервисы.
Если еще больше расширить сферу применения процесса управления
конфигурациями, в CMDB можно включить информацию о пользователях, персонале
организации, ее организационной структуре и бизнес-процессах. При этом следует
помнить, что изменение или замена любой конфигурационной единицы,
зарегистрированной в CMDB, требует прохождения через процесс управления
изменениями.
А регистрация в CMDB каждой клавиатуры, мышки или сетевого фильтра
(которые являются элементами ИТ-инфраструктуры) может привести к излишнему
усложнению процесса и замедлить другие процессы.

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

изменениями, цель которого — контроль за изменениями и уменьшение связанных с
этим негативных последствий.
Область действия процесса управления изменениями соответствует области
действия процесса управления конфигурациями; все изменения фиксируются в CMDB,
и анализ предлагаемых изменений проводится на основании данных из CMDB.
Два этих процесса тесно связаны с процессом управления релизами, который
поддерживает контролируемое распространение версий программного и аппаратного
обеспечения. Каждый релиз является следствием запроса на изменение и включает в
себя определенный набор взаимосвязанных конфигурационных элементов.

Функциональность всех трех процессов в ITIL соответствует функциональности

процессов управления конфигурациями и управления изменениями в RUP.

Оба подхода оперируют схожими понятиями при определении процессов: роли,

задачи и элементы конфигурации. Процессы также в основном совпадают по задачам.
Например, RUP и ITIL указывают такие основные задачи управления конфигурациями,
как планирование, учет и контроль над конфигурацией.

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

Все средства управления конфигурациями можно разделить на четыре
категории.

Начальный уровень — Merant PVCS VM, Microsoft Visual SourceSafe.

Поддерживается базовый версионный контроль: обеспечивается только управление
версиями. Такие средства могут использоваться лишь в небольших проектах.

Продвинутый уровень — Merant PVCS Professional, Perforce, IBM Rational

ClearCase LT. Интегрированное управление изменениями предусматривает более
комплексный подход — не только управление версиями, но и управление
изменениями, например документирование ошибок и отслеживание их исполнения.

Экстра 1, параллельные разработка и процесс управления конфигурациями

— Borland StarTeam, MKS Source Integrity, IBM Rational ClearCase. Такие средства
подходят для средних и крупных компаний, а также для фирм, вынужденных
одновременно поддерживать множество релизов для множества заказчиков. Системы
9
данного класса позволяют делать это наиболее эффективно. Средства управления
конфигурациями на данном уровне — уже не просто инструменты, а системы
формирования жесткого прозрачного процесса разработки и сопровождения.

Экстра 2, географически распределенная разработка — IBM Rational

ClearCase MultiSite, Merant PVCS Dimensions, Telelogic Synergy. Средства для всех
компаний, чьи центры разработки, тестирования и сопровождения находятся в разных
городах или странах. Инструменты данной категории содержат механизмы
автоматической синхронизации проектных команд независимо от расстояния и
способа передачи данных.

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

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

10
 Лекция 23
Управление проектами по разработке
программного обеспечения (ч.1)

Программное обеспечение – сложный продукт и основная трудоёмкость его

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

Управление программными проектами – область деятельности, в ходе

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

Какие сроки проведения работ надо поставить на каждую из сотен позиций

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

Программные проекты подвержены воздействию множества недостаточно

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

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

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

Основной причиной большинства провалов программных проектов

является именно применение неадекватных методов управления его разработкой:
− отсутствие или частые изменения требований,
− отсутствие необходимых ресурсов людских, материальных, временных,
− ошибки в оценках трудоемкости и сроков работ,
− использование слишком новых, неопробованных и нестабильных
технологий разработки.
Необходимо учитывать эти причины при управлении программными
проектами и правильно управлять людьми.

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

человеческой деятельности: операционная и проектная.
Операционная деятельность применяется, когда внешние условия
хорошо известны и стабильны, когда производственные операции хорошо
изучены и неоднократно испытаны, а функции исполнителей определены и
постоянны. В этом случае основой эффективности служат узкая специализация и
повышение компетенции. «Если водитель трамвая начнет искать новые пути,
жди беды».
Там, где разрабатывается новый продукт, внешние условия и требования к
которому постоянно меняются, где применяемые производственные технологии
используются впервые, где постоянно требуются поиск новых возможностей,
интеллектуальные усилия и творчество, там требуются проекты.

Проект — временное предприятие, предназначенное для создания

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

У операционной и проектной деятельности есть ряд общих характеристик:

– выполняются людьми
– ограничены доступностью ресурсов
– планируются
– исполняются
– управляются

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

что операционная деятельность — это продолжающийся во времени и
повторяющийся процесс, в то время как проекты являются временными и
уникальными.

Ограничение по срокам означает, что у любого проекта есть четкое начало

и четкое завершение.
Завершение наступает, когда
– достигнуты цели проекта
– осознано, что цели проекта не будут или не могут быть достигнуты
2
 – исчезла необходимость в проекте, и он прекращается

Уникальность также важное отличие проектной деятельности от

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

Задача проекта — достижение конкретной бизнес-цели.

Задача операционной деятельности — обеспечение нормального течения
бизнеса.

Проект — это средство стратегического развития.

Цель — описание того, что мы хотим достичь.

Стратегия — констатация того, каким образом мы собираемся эти цели

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

Проекты объединяются в программы. Программа — ряд связанных друг с

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

Проекты и управление ими существовали всегда. В качестве

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

3
начале ХХ века. В этой дисциплине пока нет единых международных стандартов.
Наиболее известные центры компетенции:
■ PMI, Project Management Institute, PMBOK — американский
национальный стандарт ANSI/PMI 99-001-2004.
■ IPMA, International Project Management Association. (основана в 1965г.,
объединяет в настоящее время 55 национальных ассоциаций, включающих более
200 000 сертифицированных профессионалов. Существуют и другие
профессиональные сообщества, такие как Австралийский институт (Australian
Institute of Project Management — AIPM ), ассоциация в Японии (Project
Management Association of Japan — PMAJ), а также Международная организация
Green Project Management — GPM, которая занимается распространением
устойчивых методов управления проектами в части социального расслоения и
экологической деградации от последствий экономического роста в 145 странах
мира. Активно работают национальные ассоциации управления проектами в
Великобритании, Польше, Германии, Исландии, Прибалтийских странах и ряде
других. в России — это ассоциация СОВНЕТ, в Украине — ассоциация УКРНЕТ,
в Казахстане — Казахстанская ассоциация управления проектами.
Единственными странами, в которых нет подобной структуры, являются
Бельгия и, к сожалению, Республика Беларусь).

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

Критерии успешности проекта

Задача проекта — достижение конкретной бизнес-цели, при соблюдении
ограничений «железного треугольника».

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

Согласно текущей редакции стандарта PMBOK, проект считается

успешным, если удовлетворены все требования заказчика и участников проекта.
Поэтому у проекта разработки ПО сегодня не три, а четыре фактора успеха:
4
 1. Выполнен в соответствие со спецификациями.
2. Выполнен в срок.
3. Выполнен в пределах бюджета.
4. Каждый участник команды уходил с работы в 18:00 с чувством
успеха.
Этот четвертый фактор успеха должен стать воспроизводимым, если
предприятие хочет быть эффективным. Для успешного проекта характерно
постоянное ощущение его участниками чувства удовлетворения и гордости за
результаты своей работы, чувства оптимизма. Нет ничего более гибельного для
проекта, чем равнодушие или уныние его участников.

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

Структура организации–исполнителя проекта

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

Различают следующие структуры организаций:

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

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

проведения конкретных проектов. Руководитель такого временного
подразделения является руководителем соответствующего проекта и полностью
распоряжается выделенными для него ресурсами.

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

Продуктовая. Подразделения такой организации отвечают за разработку,

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

Ориентированная на клиента. Подразделения таких организаций

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

Территориальная. Подразделения формируются согласно географическому

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

Матричная. Это гибрид нескольких схем, обычно проектной или

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

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

Выделяют следующие виды организационной культуры:

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

Рыночная (открытая). Деятельность этой организации ориентирована на

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

Инновационная (произвольная). Работа организации этого типа

ориентирована на инновации, создание передовых, уникальных продуктов и
услуг. Ценностями в ней служат творческая атмосфера, технологическое
лидерство, внедрение новаторских подходов.
Работа в ней продвигается, если поддерживает творческие инициативы
вовлеченных в нее служащих, использует передовые достижения в некоторой
области, способствует созданию уникальных технологий, продуктов и услуг.
Нужно убедить каждого участника или "законодателей мод" в полезности
ведущейся деятельности, подтвердить использование новаторских подходов и
предоставить свободу творческих изменений.

Семейная (синхронная). Такая организация обладает хорошей внутренней

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

Заинтересованные в проекте лица

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

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

Спонсор проекта. Это лицо или группа лиц, предоставляющая ресурсы для
проекта или формирующая инвестиционно- привлекательную ситуацию вокруг
него. Очень важно еще до начала проекта определить его спонсора, поскольку
именно с ним нужно решать все вопросы, касающиеся обеспечения проекта
ресурсами.

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

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

Лидер проекта. Это наиболее авторитетный человек в команде проекта, к

чьему мнению прислушиваются, кто принимает большинство технических
решений по ходу проекта. Часто лидер и менеджер проекта — одно лицо.

Заказчик. Это лицо или организация, которые получают результаты проекта

в собственность того или иного вида.

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

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

Организация-исполнитель. Это организация, в которой проводится проект и

которая несет ответственность перед заказчиком за его выполнение. Такая
организация может быть создана для проведения одного конкретного проекта и
состоять только из его команды.

Команда проекта. Это служащие организации-исполнителя, выполняющие

работы по проекту. Менеджер проекта и лидер проекта входят в команду.
8
 Команда управления проектом. Это часть команды проекта,
непосредственно участвующая в деятельности по управлению проектом. Сюда
входят менеджер проекта и его лидер, может входить секретарь менеджера,
эксперты, помогающие в принятии решений и т.д.

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

Источники влияния. Это лица, группы лиц или организации, не связанные

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

При управлении проектом большое внимание должно уделяться

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

Функциональные роли в программном проекте

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

Роли и ответственности участников типового проекта разработки ПО можно

условно разделить на пять групп:
1. Анализ. Извлечение, документирование и сопровождение требований к
продукту.
2. Управление. Определение и управление производственными
процессами.
3. Производство. Проектирование и разработка ПО.
4. Тестирование. Тестирование ПО.
5. Обеспечение. Производство дополнительных продуктов и услуг.

Группа анализа включает в себя следующие роли:

 Бизнес-аналитик. Построение модели предметной области (онтологии).
 Бизнес-архитектор. Разрабатывает бизнес-концепцию системы.
Определяет общее видение продукта, его интерфейсы, поведение и ограничения.
 Системный аналитик. Отвечает за перевод требований к продукту в
функциональные требования к ПО.
 Специалист по требованиям. Документирование и сопровождение
требований к продукту.
 Менеджер продукта (функциональный заказчик). Представляет в проекте
интересы пользователей продукта.

Группа управления состоит из следующих ролей:

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

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

В производственную группу входят:

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

Группа тестирования в проекте состоит из следующих ролей:

 Проектировщик тестов. Разработка тестовых сценариев.
 Разработчик автоматизированных тестов.
 Тестировщик. Тестирование продукта. Анализ и документирование
результатов.

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

Они выполняют работы в рамках своей процессной деятельности. К группе
обеспечения можно отнести следующие проектные роли:
 Технический писатель.
 Переводчик.
 Дизайнер графического интерфейса.
 Разработчик учебных курсов, тренер.
 Участник рецензирования.
 Продажи и маркетинг.
 Системный администратор.
 Технолог.
 Специалист по инструментальным средствам.
 Другие.

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

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

Возможны следующие совмещения ролей:

 Руководитель проекта + системный аналитик (+ системный архитектор)
 Системный архитектор + разработчик
 Системный аналитик + проектировщик тестов (+ технический писатель)

11
  Системный аналитик + проектировщик интерфейса пользователя
 Ответственный за управление конфигурациями + ответственный за
сборку и поставку (+ разработчик)

Крайне нежелательно совмещать следующие роли:

 Разработчик + руководитель проекта
 Разработчик + системный аналитик.
 Разработчик + проектировщик интерфейсов пользователя.
 Разработчик + тестировщик

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

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

Программисты любят и умеют программировать. Пусть они этим и

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

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

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

Никто уже не хочет работать с программами с технологической парадигмой

навороченного пользовательского интерфейса — кустарным творением
программистов — когда для того, чтобы работать с системой, надо обязательно
знать, как она устроена. Поэтому, необходимо привлекать в проектную команду
бизнес-аналитиков, эргономистов, художников-дизайнеров, документалистов.
Разделение труда и специализация — залог перехода от кустарного производства
к более эффективному промышленному производству.
Из профессиональных программистов получаются отличные тестировщики.
Однако, совмещать одновременно роли программиста и тестировщика — плохая
практика. Хороший программист убежден, что он пишет программы правильно и
ему психологически тяжело допустить, что где-то в его коде может быть ошибка.
А ошибки есть всегда!

Организационная структура проекта обязательно должна включать в себя

эффективную систему отчетности, оценки хода выполнения проекта и систему
принятия решений. Можно рекомендовать еженедельные собрания по статусу

12
проекта, на которых анализируются риски, оцениваются результаты, достигнутые
на предыдущей неделе, и уточняются задачи на новый период.
Важно помнить, что организационная структура проекта — «живой»
организм. Она начинает складываться на стадии планирования и может меняться
в ходе проекта. Нестабильность организационной структуры (частые замены
исполнителей) — серьезная проблема в управлении сложными программными
проектами, поскольку существует время вхождения в контекст проекта, которое
может измеряться месяцами.

Жизненный цикл проекта. Фазы и продукты

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

На фазе инициации проекта необходимо понять, что и зачем мы будем

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

Как правило, редкий проект выполняется в соответствие с первоначальными

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

Распределение ресурсов по фазам проекта

Проект часто начинается с идеи, которая появляется у одного человека.

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

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

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

Устав проекта — документ, выпущенный инициатором или спонсором

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

Данный документ чаще называется Концепция проекта. (Концепция –

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

В компании, которая принимает решение о старте того или иного проекта

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

Приоритет любого проекта должен определяться на основе оценки трех его

характеристик:
 Финансовая ценность
 Стратегическая ценность
 Уровень рисков

15
 Шкала оценки финансовой ценности проекта может выглядеть следующим
образом:
 Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от
проекта не менее чем в 1.5 раз превышают расходы. Все допущения при
проведении этих оценок четко обоснованы.
 Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет.
Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы.
Большинство допущений при проведении этих оценок имеют под собой
определенные основания.
 Средняя. Проект позволяет улучшить эффективность производства в
Компании и потенциально может снизить расходы компании не менее чем на 30%.
Проект может иметь информационную ценность или помочь лучше
контролировать бизнес.
 Низкая. Проект немного снижает расходы компании не менее чем на 10%
и дает некоторые улучшения производительности производства.

Например. Финансовая ценность проектов разработки ПО, проектов

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

Шкала оценки стратегической ценности проекта может иметь следующий

вид:
 Высокая. Обеспечивает стратегическое преимущество, дает устойчивое
увеличение рынка или позволяет выйти на новый рынок. Решает значительные
проблемы, общие для большинства важных клиентов. Повторение конкурентами
затруднено или потребует от 1 до 2 лет.
 Выше среднего. Создает временные конкурентные преимущества.
Выполнение обязательств перед многими важными клиентами. Конкурентное
преимущество может быть удержано в течение 1 года.
 Средняя. Поддерживается доверие рынка к компании. Повышает мнение
клиентов о качестве предоставляемых услуг или способствует выполнению
обязательств перед несколькими клиентами. Конкуренты уже имеют или
способны повторить новые возможности в пределах года.

16
  Низкая. Стратегическое воздействие отсутствует или незначительно.
Влияние на клиентов несущественно. Конкуренты могут легко повторить
результаты проекта.

Третьим обязательным показателем приоритета проекта должна быть

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

Примерная шкала оценки уровня рисков проекта может иметь следующий

вид:
 Низкий. Цели проекта и требования хорошо поняты и документированы.
Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации
доступны в полном объеме. Разрабатываемые системы не потребуют новой
технологической платформы.
 Средний. Цели проекта определены более-менее четко. Хорошее
понимание требований к системе. Масштаб и рамки проекта заданы достаточно
хорошо. Ресурсы требуемой квалификации доступны в основном. Системы
создаются на новой, но стабильной технологической платформе.
 Выше среднего. Цели проекта недостаточно четки. Задачи системы или
бизнес-приложения поняты недостаточно полно. Понимание масштаба и рамок
проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены.
Системы создаются на новой технологической платформе, сомнения в рыночной
стабильности платформы.
 Высокий. Цели проекта нечетки. Основные функциональные
компоненты системы не определены. Масштаб и рамки проекта непонятны.
Ресурсы требуемой квалификации практически отсутствуют. Системы создаются
на новой технологической платформе, в отношении которой крайне мало ясности.
Технологии имеют неподтвержденную стабильность.

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

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

17