Вы находитесь на странице: 1из 360

Лекция 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) ПО − эт