Программное обеспечение.
Под программным обеспечением (ПО) понимается совокупность программ,
выполняемых вычислительной системой.
К программному обеспечению относится также вся область деятельности по
проектированию и разработке ПО:
– технология проектирования программ;
– методы тестирования программ;
– методы доказательства правильности программ;
– анализ качества работы программ;
– документирование программ;
– разработка и использование программных средств, облегчающих процесс
проектирования программного обеспечения, и многое другое.
Системное
Это часть системы, которая помогает следить за аппаратной стороной ПК и
управлять ею. Сюда входят программы, контролирующие работу оперативной
памяти, центрального процессора, видеокарты, устройств ввода и вывода
информации, сетевые подпрограммы.
К системному ПО относятся:
Прикладное
Наиболее обширная доля классификации. Сюда относятся графические и
текстовые редакторы, браузеры, базы данных и все, что люди используют в
привычной работе за компьютером.
Смысл этой разновидности в выполнении четко поставленной задачи:
рисовать, учитывать, набирать текст и т.д. Если утилита нужна для конкретного
выполнения действия, то она является прикладным ПО.
Инструментальное
Специфическое обеспечение любой компьютерной техники. Его можно было
бы отнести к прикладному, но из-за специфики применения его выделили в
отдельный вид. Основная функция – отладка, настройка, переписывание
программного кода.
Сюда входят компиляторы, отладчики, переводчики высокого уровня,
редакторы, интерпретаторы и другие средства. Они необходимы, потому что
техника не понимает человеческих слов. Чтобы ей «объяснить», что надо сделать,
требуется специальный «машинный язык».
Постоянно пользоваться этим кодом базовым пользователям довольно
сложно, поэтому были разработаны системы, которые позволяют переводить
обычную речь в двоичную, привычную для ПК.
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. разработку управленческих решений по составу и структуре организации,
методологии решения задач, направленных на повышение эффективности системы
управления.
Правовое обеспечение
Правовое обеспечение — совокупность правовых норм, определяющих со-
здание, юридический статус и функционирование информационных систем,
8
регламентирующих порядок получения, преобразования и использования
информации.
Главной целью правового обеспечения является укрепление законности.
В состав правового обеспечения входят законы, указы, постановления
государственных органов власти, приказы, инструкции и другие нормативные
документы министерств, ведомств, организаций, местных органов власти. В
правовом обеспечении можно выделить общую часть, регулирующую
функционирование любой информационной системы, и локальную часть,
регулирующую функционирование конкретной системы.
Правовое обеспечение этапов разработки информационной системы включает
нормативные акты, связанные с договорными отношениями разработчика и
заказчика и правовым регулированием отклонений от договора.
9
Лекция 2
Процессы разработки программного обеспечения
Шаги процесса
Процесс разработки состоит из множества подпроцессов.
1. Анализ требований включает в себя сбор требований к программному
обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также
документирование.
Анализ требований включает три типа деятельности:
Сбор требований — общение с клиентами и пользователями, чтобы определить,
каковы их требования; анализ предметной области.
Анализ требований — определение, являются ли собранные требования
неясными, неполными, неоднозначными или противоречащими; решение этих проблем;
выявление взаимосвязи требований.
Документирование требований — требования могут быть задокументированы в
различных формах, таких как простое описание, сценарии использования,
пользовательские истории, или спецификации процессов (Спецификация требований
программного обеспечения — структурированный набор требований
(функциональность, производительность, конструктивные ограничения и атрибуты) к
программному обеспечению и его внешним интерфейсам. Предназначен для того,
чтобы установить базу для соглашения между заказчиком и разработчиком (или
подрядчиками) о том, как должен функционировать программный продукт).
2. Проектирование ПО
Целью проектирования является определение внутренних свойств системы и
детализации её внешних (видимых) свойств на основе выданных заказчиком требований
к ПО (исходные условия задачи). Эти требования подвергаются анализу.
Проектирование ПО включает следующие основные виды деятельности:
выбор метода и стратегии решения;
выбор представления внутренних данных;
разработка основного алгоритма;
документирование ПО;
тестирование и подбор тестов;
выбор представления входных данных.
3. Кодирование (программирование) — в обычном понимании, это
непосредственно сам процесс создания компьютерных программ.
4. Тестирование и отладка — процесс исследования, испытания программного
продукта, имеющий своей целью проверку соответствия между реальным поведением
программы и её ожидаемым поведением на конечном наборе тестов, выбранных
определённым образом.
5. Документирование — это документы, сопровождающие программное
обеспечение (ПО). Эти документы описывают то, как работает программа и/или то, как
её использовать.
1
6. Внедрение — процесс настройки программного обеспечения под
определенные условия использования, а также обучения пользователей работе с
программным продуктом.
7. Сопровождение — процесс улучшения, оптимизации и устранения дефектов
программного обеспечения (ПО) после передачи в эксплуатацию. Сопровождение ПО
— это одна из фаз жизненного цикла программного обеспечения, следующая за фазой
передачи ПО в эксплуатацию. В ходе сопровождения в программу вносятся изменения,
с тем, чтобы исправить обнаруженные в процессе использования дефекты и
недоработки, а также для добавления новой функциональности, с целью повысить
удобство использования (юзабилити) и применимость ПО.
Основные процессы.
Основные процессы жизненного цикла – это процессы, которые реализуются под
управлением основных сторон, участвующих в ЖЦ ПС. Основными сторонами
являются заказчик, поставщик, разработчик, оператор и персонал сопровождения
программных продуктов.
Заказчик – это организация, которая приобретает систему, программный
продукт (ПП) или программную услугу.
Поставщик – это организация, которая поставляет систему, ПП или программную
услугу заказчику.
Разработчик – это организация, которая разрабатывает ПП.
Оператор – это организация, которая производит эксплуатационное
обслуживание системы, содержащей ПП, в заданных условиях.
Персонал сопровождения – это организация, которая предоставляет услуги по
сопровождению программного продукта.
Таким образом, основные процессы состоят из пяти процессов:
• заказ;
• поставка;
• разработка;
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).
Организационные процессы.
Организационные процессы жизненного цикла − это ряд мер, направленных
на повышение организации и качества разработки программного обеспечения. Обычно
их выделяют четыре вида:
Управление
Создание инфраструктуры
Усовершенствование
Обучение
Вспомогательные процессы
Документирование
Управление конфигурацией
Обеспечения качества
Верификация
Аттестация
Совместный анализ
Аудит
Решение проблем
7
влечёт за собой плачевные последствия в виде сорванных сроков и даже отказов
заказчика. Таким образом, возрастает роль руководителей и ответственных
разработчиков, с уровнем компетентности которых в любой компании часто бывают
проблемы.
Игнорирует конечного пользователя. Чем ниже продвигается процесс в водопаде,
тем меньше в нём роль заказчика, не говоря уже о клиентах, которых он представляет.
Внесение каких-либо изменений в функциональность ПО запускает всю цепочку этапов
заново, поэтому продукты, полученные по каскадной модели далеки от ориентации на
массового пользователя.
Позднее тестирование. На этапе тестирования чаще всего выявляются ошибки,
допущенные на каждом из этапов. Более гибкие методологии используют тестирование
в качестве фундаментальной операции, происходящей непрерывно. «Водопад» же
допускает низкую квалификацию сотрудников на каждом этапе и плохое качество
исполнения, ведь при запоздалом тестировании проблемы невозможно решить
фундаментально, только при помощи «заплаток».
Достоинства:
− снижение неопределённости в требованиях по мере проектирования,
позволяющее уменьшать число откатов;
− совмещение относительно строгой последовательности шагов и итеративного
подхода обеспечивает достаточно сбалансированный по рискам затрат план работ.
8
Недостатки:
− трудность прогнозирования сроков окончания проекта;
− возможность отката при интеграции отдельных компонентов, что может
приводить к откатам и связанным с ними затратам.
Спиральная модель
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков.
Была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Боэм
формулирует 10 наиболее распространенных (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание
деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение
системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту)
ресурсами.
9. Недостаточная производительность получаемой системы.
10. «Разрыв» в квалификации специалистов разных областей знаний.
Макетирование
Достаточно часто заказчик вначале проекта не может точно и однозначно
сформулировать подробные требования по вводу, обработке и выводу данных.
С другой стороны, разработчик может сомневаться в переносимости продукта на
другую программную или аппаратную платформу, а также в эффективности
реализуемых алгоритмов. В этих случаях целесообразно использовать макетирование.
Основная цель макетирования – снять неопределенности в требованиях заказчика.
Макетирование (прототипирование) – это процесс создания модели требуемого
программного продукта. Модель может принимать одну из трех форм:
1. бумажный макет, на котором изображен человеко-машинный диалог;
2. работающий макет, который выполняет некоторую часть требуемых функций;
3. существующая программа, характеристики которой должны быть улучшены.
Макетирование основано на многократном повторении операций, в которых
участвуют разработчик и заказчик.
11
Лекция 3
Это основное и общепринятое определение Agile, но, как это часто бывает в
мейнстримных направлениях, которым Agile стала на сегодня, единого определения не
существует и есть множество альтернативных толкований этого термина.
Принципы Agile.
Гибкая методология — набор идей и принципов, на которых основаны
конкретные практические решения. Можно считать это особой философией, которая
задает вектор, а не предписывает действия. Эти идеи и принципы были впервые
сформулированы в Agile-манифесте.
2
12 принципов Agile
1. Задача высшего приоритета — регулярно и как можно раньше удовлетворять
потребности заказчика, предоставляя ему программное обеспечение.
2. Учитывать, что требования могут измениться на любом этапе разработки.
Если изменения быстро вносятся в проект, заказчик может получить конкурентные
преимущества.
3. Выпускать версии готовой программы как можно чаще — с промежутком от
двух недель до двух месяцев.
4. Ежедневно вместе работать над проектом — разработчикам и заказчикам.
5. Поручить работу мотивированным профессионалам. Обеспечить поддержку и
условия, довериться им — и работа будет сделана.
6. Общаться напрямую — это самый эффективный способ взаимодействия
внутри команды и вне ее.
7. Считать главным показателем прогресса работающий продукт.
8. Поддерживать постоянный ритм работы — касается и разработчиков, и
заказчиков.
9. Уделять пристальное внимание техническому совершенству и качеству
проектирования — это повышает гибкость проекта.
10. Минимизировать лишнюю работу.
11. Стремиться к самоорганизующейся команде — в ней рождаются наиболее
эффективные и качественные решения.
12. Всем участникам команды — постоянно искать способы повышать
эффективность работы.
1. Обычный хлебозавод
Технолог получает от генерального директора задание на разработку нового вида
хлебной продукции. Что он делает дальше? Допустим, направляется к маркетологам
предприятия и поручает им провести соответствующие исследования. Но, скорее всего,
этот шаг продиктован не желанием узнать истинные предпочтения потребителей, а
стремлением угодить вкусам руководителя.
Получив результаты маркетинговых исследований, технолог создаст хлебную
новинку на свой вкус и представит ее директору. Тот продегустирует продукт и решит:
похвалить и поощрить технолога или забраковать разработку, отправив подчиненного
все переделывать. В итоге после одобрения руководством пекари получат
технологические карты, чтобы начать массовый выпуск новой продукции, и, наконец,
испеченный хлеб поступит в торговлю. Так выглядит традиционный вариант: персонал
всего лишь получает указания для работы, а оценивается результат одной личностью
(иногда бывает, что несколькими).
3
2. Agile-хлебозавод
У генерального директора рождается идея о выпуске нового сорта хлеба. А
дальше происходит что-то невероятное. Создавать продукт зовут и технолога, и группу
маркетинга, и отдел продаж, и логистов, и поваров с кондитерами, а еще, представьте,
обычных покупателей.
В этой сборной команде не будет никакой иерархии (разве что генеральный
директор сохранит руководящую роль), итогом же общих усилий станет не
персональная награда одного лучшего сотрудника, а то, что появится новый сорт хлеба
и он будет нарасхват у покупателей. Кстати, во время всего процесса каждое из
действующих лиц оценивает результат и выдает обратную связь для лучших
показателей.
Короче говоря, благодаря такому подходу компания может быстро
переориентироваться на какую-то цель и выдать отличный продукт, который способен
выдержать конкуренцию, а главное, по душе покупателям. Это хорошо для продаж,
ценно с точки зрения экономии времени и помогает избежать ошибок.
Применение Agile
В настоящее время проект-менеджмент с поддержкой Аджайл по большей части
распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система
применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на
вооружение множеством компаний и государственных структур.
4
Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский
пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo
(производство печенья), компания Aviasales (крупнейший поисковик авиабилетов),
компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк»
(Россия), Альфа-банк.
Если говорить о динамике распространения Agile в Беларуси, то пока чувствуется
некоторое шевеление в банковском секторе, чуть меньше проявляют интерес к Agile в
R&D-департаментах (от англ. Research & Developmet) (отдел НИОКР – отдел научно-
исследовательских и опытно-конструкторских разработок) производственных
компаний, появляется небольшое движение в сторону Agile у сервисных компаний.
Scrum
Набор принципов, ценностей, политик, ритуалов, артефактов, на которых
строится процесс разработки, позволяющий в жестко фиксированные и небольшие по
времени итерации, называемые спринтами (sprints), предоставлять конечному
пользователю работающий продукт с новыми бизнес-возможностями, для которых
определен наибольший приоритет.
Достоинства Scrum
Scrum ориентирован на клиента, адаптивен.
Scrum дает клиенту возможность делать изменения в требованиях в любой
момент времени, но не гарантирует то, что эти изменения будут выполнены.
(Возможность изменения требований привлекательна для многих заказчиков)
Scrum достаточно прост в изучении, позволяет экономить время за счет
исключения некритичных активностей.
Scrum позволяет получить потенциально рабочий продукт в конце каждой
итерации работ.
5
Scrum делает упор на самоорганизующуюся многофункциональную команду,
способную решить необходимые задачи с минимальной координацией.
Это особенно привлекательно для малых компаний, так как избавляет от
необходимости найма или обучения специализированного персонала дорогостоящих
руководителей.
Недостатки Scrum.
Ввиду простоты и минималистичности, Scrum задает небольшое количество
довольно жестких правил. Однако это вступает в конфликт с идеей "клиент всегда прав",
так как заказчикам не важны внутренние правила команды разработки, особенно если
они его ограничивают.
Так же общеизвестной проблемой Scrum являются большие издержки на
обсуждения, встречи и большие потери времени на стыках спринтов. Как минимум день
уходит на закрытие очередного спринта, а потом день – на открытие нового. В условиях,
когда спринт длится 2 недели, 2 дня составляют 20% рабочего времени. Итог – 30-40%
времени при применении Scrum тратится на поддержание самого процесса (ежедневные
встречи, планирование и детализирование работ, презентация полученных результатов
и пр.)
6
7
8
Лекция 4
Методологии разработки программного обеспечения (ч.2)
Роли Scrum
Команда
Команда – это группа профессиональных работников, объединенные одной
целью. Смысл командной работы состоит в производстве высоких результатов за счет
кооперирования между сотрудниками высокой квалификации и производства
совокупного результата, который должен превосходить сумму результатов членов
команды.
Топ-менеджмент большинства организаций полагает, что, отдавая предпочтение
отдельным специалистам, проще осуществлять контроль и управление коллективом в
целом. Когда есть необходимость в хороших исполнителях, руководство нацелено на
то, чтобы в фирме собрать самых опытных работников. Вопросы качества и хороших
результатов становятся решенными априори после того, как нужный работник найден.
Не так все просто.
Ресурс отдельного, хоть и профессионального исполнителя ограничен многими
факторами, которые определяют необходимый результат. Но когда мы начинаем
говорить о командной работе, то начинают работать совсем другие принципы.
Командный ресурс состоит из ресурсов исполнителей, к которому добавляется
синергетический эффект, приводящий общий механизм в движение.
Этапы командообразования
Чтобы группа людей превратилась в сплоченную и эффективную команду,
необходимо пройти несколько этапов.
Наиболее распространенной моделью, описывающей стадии
командообразования, является модель Такмана.
2
В своем развитии все команды обязательно проходят несколько этапов.
Формирование
Этот этап во многом является отправной точкой для создания команды и
постановки целей на разработку или развитие продукта. Как правило, на этом этапе
выполняются создание или обновление состава, постановка целей деятельности всего
состава команды в целом и отдельных ее членов, не очень понимающих те задачи,
выполнение которых поставлено перед ними для достижения общего результата.
Бурление
На этом этапе все члены команды отчетливо осознают свои и общие цели,
задающие вектор движения коллектива. В период бурления часто возможны конфликты
и противостояние между отдельными членами команды, формирование мелких
группировок, поэтому особенно возрастает роль Scrum-мастера (SM) как модератора (о
нем чуть позже). Этап бурления – самое время для определения формальных и
неформальных лидеров Scrum-команды.
Нормализация
На этапе нормализации происходит "притирание" членов команды друг к другу.
Закрепляются лидеры команды, и она начинает демонстрировать стабильные
результаты деятельности. Основная задача Scrum-мастера на этом этапе – помощь
команде для перехода на следующий этап.
Функционирование
Функционирование – это этап, на котором команда переходит к
самоуправляемости. На этом этапе команда способна оптимизировать свою
производительность, существующие неформальные связи между членами команды
3
закрепляются окончательно. Это период наибольшей эффективности и
производительности.
Расформирование
Цели, поставленные перед командой, достигнуты, мотивация большинства
участников в этот период убывает. Профессиональный Scrum-мастер должен четко
отслеживать рубеж между этапом функционирования и расформирования, и
предпринимает шаги, которые не позволят команде сильно понизить их
производительность. В качестве примера подобных шагов можно привести изменение
состава команды, смену целей, предоставление нового продукта, над развитием
которого должна трудиться команда, и т. д.
Разработчик
Scrum-команда должна состоять из мотивированных профессиональных
сотрудников. Члены команды отвечают за разработку программного продукта высокого
качества. Они должны обладать множеством различных навыков, необходимых для
создания эффективного программного обеспечения:
Бизнес и системный анализ.
Проектирование архитектуры программного продукта.
Программирование.
Тестирование.
Настройка баз данных.
Разработка эргономичных пользовательских интерфейсов.
Scrum-мастер
Scrum-мастер – движущая сила Scrum-процесса. Он призван помогать команде в
освоении гибкой методологии. Его роль является определяющей при внедрении Scrum.
Для того чтобы Scrum получился успешным, Scrum-мастер должен обладать
следующими качествами:
быть ответственным;
отдавать должное команде, а не личным достижениям;
всегда быть готовым к диалогу;
выкладываться по максимуму;
обладать умением влиять на других;
обладать развитым профессиональным кругозором;
разбираться в профессиональных и технических вопросах.
Scrum-мастер призван помогать команде в использовании Scrum. Его функции
сопоставимы с функциями тренера, который помогает спортсменам соблюдать
спортивный режим и поддерживать физическую форму. Scrum-мастер создает
мотивации и в то же время следит за тем, чтобы члены команды не увиливали от
выполнения "тяжелых физических упражнений". Однако его полномочия ограничены.
Он не может заставить сотрудника выполнять то или иное упражнение, которое тот не
желает выполнять. Вместе с тем он напоминает о целях и о том, как необходимо их
достигать. Scrum-мастер обладает властью в той мере, в какой этой властью наделила
его команда.
5
объясняет Скрам-команде необходимость кратких и понятных Элементов
Бэклога Продукта;
объясняет особенности планирования продукта в эмпирической среде;
помогает Владельцу Продукта упорядочить Бэклог Продукта, чтобы получить
максимальную ценность продукта;
способствует лучшему пониманию гибкости и её применения;
фасилитирует (облегчает выполнение заданий) события Скрама при
необходимости.
Владелец продукта
Роль владельца продукта является основной при использовании методологии
Scrum.
Владелец Продукта несет ответственность за достижение максимальной ценности
продукта как результата работы, которую выполняет Команда Разработки.
Владелец Продукта – единственный человек, который отвечает за управление
Бэклогом Продукта
Для того чтобы быть успешным, сотрудник, выполняющий эту роль, должен
сочетать в себе навыки таких должностей, как менеджер продукта, менеджер проекта,
бизнес-аналитик, и при этом быть природным лидером, способным мотивировать и
вдохновить окружающую его команду на свершения.
Бизнес-аналитик – сотрудник, который знает, как получить требования от
пользователей и как подготовить требования к команде, чтобы она исполняла их
максимально быстро.
Менеджер продукта – сотрудник, который знает, чего хотят бизнес и
пользователи.
Менеджер проекта – сотрудник, который знает, как планировать и
отслеживать исполнение проекта.
6
Лидер – сотрудник, который знает, как направить общие усилия в одну сторону,
на чем сфокусироваться и как мотивировать команду на достижение этой цели.
7
Лекция 5
Методологии разработки программного обеспечения (ч.3)
Атрибуты SCRUM
Story mapping
Story mapping (англ. "карта историй") − техника визуального и физического
представления последовательности действий, которые должны быть реализованы в
разрабатываемом командой программном продукте.
Т.е. карта историй − это источник информации, используемый для визуализации
требований к продукту в контексте использования его функциональности и их
приоритетов. Story mapping помогает выполнить декомпозицию задачи с ее
высокоуровневого представления до уровня конкретных задач
1
Под каркасом находятся подробные требования, которые описывают конкретные
функциональные части для выполнения задач. В Scrum, когда речь заходит о работе с
требованиями, применяют определенную технику работы с ними, которая называется
User Story (пользовательские истории).
User story может быть добавлена к бэклогу проекта на любом этапе спринта
любым членом команды. Владелец проекта решает, как координировать и
приоритезировать пожелания пользователя, и подбирает их вначале каждого цикла
спринта.
Структура
Карточка составляется по стандартной схеме:
Заголовок (должен описывать действие);
Заказчик (роль);
Примечание (функционал);
Цель (выгода).
2
История: Владелец карточки снимает наличку
Use Case
В практике подготовки требований, которые в дальнейшем составят каркас
разрабатываемого программного продукта, в Scrum принято использовать один из
стандартизированных подходов для их описания − Use Cases ("сценарии
использования").
Use Case − это сценарная пошаговая техника описания взаимодействия двух или
более участников, задействованных в автоматизации. С помощью Use Case может быть
описано и пользовательское требование, и требование к взаимодействию систем, и
описание взаимодействия людей и компаний в реальной жизни.
Таким образом, каждый квадратик в Story Mapping можно представить в виде Use
Case. Разработать оптимальную пользовательскую историю не так просто, нужен
определенный навык, который позволит создать качественное описание требований
пользователей к реализуемому программному продукту, но в награду за это получаются
следующие преимущества:
Краткость. Пользовательская история описывает небольшую часть бизнес-
ценности, которую возможно реализовать за период спринта.
"Незатратность" создания и сопровождения. За счет своей "компактности"
пользовательские требования достаточно просто создать и сопровождать их изменения
на всем протяжении жизненного цикла продукта.
Вовлечение ключевых пользователей в процесс создания продукта. За счет своей
доступности бизнес-требования смогут стать реальным "мостиком" между
пользователями и Scrum-командой. Это позволит более адекватно управлять
ожиданиями пользователей и вовлечь их на нужную степень погружения в процесс
разработки продукта.
Облегчают оценку заданий. Формат пользовательских историй способствует
более точной оценке необходимых системных разработок/доработок.
3
4
Основной поток событий
5
При использовании этой матрицы по ее "частям" распределяются задачи в
соответствии с их важностью и срочностью.
Важные и срочные задачи. Это те задачи, которые важны, и выполнить их
необходимо срочно. Без них все порушится, ничего работать не будет, и сделать их
завтра – будет уже поздно.
Важные, но не срочные задачи. Это те, которые срочными станут в скором
времени. Успешные команды и сотрудники в первую очередь обращают свое внимание
именно на этот тип задач, чтобы они постепенно не перешли в разряд "Важные и
срочные задачи".
В момент усталости многие разработчики начинают заниматься сторонними
делами, чтобы отдохнуть. Это неправильно. Правильно –запланировать качественный
отдых в соответствии с индивидуальными особенностями каждого разработчика. Это
задача из категории "Важно и не срочно".
Не важные, но срочные. Это тип задач, которые никак не приближают к
достижению необходимого результата, которые надо делать, но исключительно для
того, чтобы их делать.
Не важные и не срочные. Эти задачи не важны, они не срочны, но именно их
хочется делать. Это пожиратели времени, и от них необходимо избавляться.
Принцип Эйзенхауэра – очень эффективная техника расстановки приоритетов. Но
ее особенности больше направлены на расстановку приоритетов отдельного
сотрудника, а не команды в целом.
Методика «АБВ».
В соответствии с этой методикой задачи делятся на три категории: жизненно
важное, важное, приятное. Эта методика является логическим (более "глубинным")
продолжением принципа Эйзенхауэра.
Применение принципа Парето (принцип 80/20 – 20 % усилий дают 80 %
результата, а остальные 80 % усилий — лишь 20 % результата) конкретизируется,
если все задачи проанализировать в соответствии с их долей в итоговом результате и
затем распределить по категориям важности. АБВ основывается на следующих трех
закономерностях, подтвержденных опытом:
6
Самые критичные задачи (категория "А") составляют ~ 15-20% всех задач.
Значимость этих задач, вклада в достижение конечного результата составляет ~ 60-65%.
Менее важные задачи (категория "Б") составляют ~ 20 % от общего числа. Их
значимость – также 20% конечного результата.
Неважные и несущественные задачи (категория "В") составляют до 65% от
общего числа задач. Они имеют незначительную долю – 15% в достижение конечного
результата
7
MoSCoW позволяет сосредоточить фокус внимания как владельца продукта, так и
Scrum-команды на задачах конкретного спринта.
Все имеющиеся задачи в бэклоге продукта следует сгруппировать в четыре
приоритетные корзины по следующим правилам:
M (must) – задачи должно быть реализованы в первую очередь, без них
программный продукт не имеет смысла. От этих задач нельзя отказаться. В них
заключен залог успеха. Задачи, отмеченные как must, должны быть включены в текущий
спринт.
S (should) – следовало бы иметь, но можно отложить на более позднее время.
Задачи этого типа также критичны для успеха разрабатываемого продукта, но не
необходимы в ближайшее время. Такие задачи, как правило, имеют альтернативные
пути решения.
C (could) – можно было бы иметь, но если нет возможности их разработать сейчас,
то можно и отложить. Задачи этого типа менее критичны. Они обычно относятся к типу
"хотелось бы иметь".
W (would) – в этот раз стоит отказаться от этих задач, но в следующий раз можно
их сделать. Наименее критичные. Задачи данной категории не планируются к
разработке в ближайшие спринты, но при будущих поставках их статус может быть
пересмотрен.
Доска задач
Рассмотреть еще один очень важный артефакт каждой Scrum-команды, цель
которого – визуализировать состояния задач в Scrum. Речь идет о Scrum-доске.
8
Каждый рабочий день все члены команды собираются на 15-минутное daily, на
котором они обмениваются информацией по состоянию текущих дел ("Что сделано с
момента предыдущей встречи?", "Чем планирую заниматься сегодня?", "Какие есть
препятствия?").
Таким образом, участники daily каждый день собственными глазами видят, как
идет прогресс в работе над тем или иным типом задачи.
Бэклог продукта
После того как необходимые требования к продукту собраны, их необходимо
зафиксировать и "взять на учет" для дальнейшей реализации. Для этого в Scrum есть
артефакт, который называется бэклог продукта (Product Backlog, PB).
Бэклог продукта – это упорядоченный список задач, которые должны быть
реализованы в конечном продукте.
PB является единственным источником требований для любых изменений,
которые может потребоваться внести в ПО. Ответственность за бэклог продукта несет
владелец продукта, включая его содержимое, доступность, упорядочение и
приоритизацию.
9
PB никогда не является полным. В начале (сверху) – только первоначально
известные и наиболее понятные требования. Бэклог постоянно обновляется по мере
обновления самого продукта и окружающей его среды, поэтому PB "живет" вместе с
продуктом. PB является динамическим, постоянно изменяющимся для соответствия
требованиям продукта, его конкурентоспособности и пригодности. PB существует
ровно до тех пор, пока существует и сам продукт:
PB содержит все "фичи", функции, требования, усовершенствования и
информацию по исправлению дефектов, то есть те данные, которые и определяют
изменения, необходимые в следующих релизах продукта. Каждому элементу PB
присваивается:
– описание
– порядковый номер
– оценка объема работы
– ценность.
Элементы Бэклога Продукта часто содержат описания тестов, которые позволят
убедиться в завершённости Элемента, когда он будет «Готов».
Бэклог спринта
Бэклог спринта (Sprint Backlog SB) – это набор элементов Product Backlog,
выбранных для выполнения в текущем спринте.
SB – это прогноз и обязательства Scrum-команды относительно
функциональности, которая станет частью разрабатываемого инкремента за время
спринта.
Бэклог спринта:
– наполняется во время планирования работ на спринт;
– визуализируется на доске задач;
– определяет тот объем работы, которую Scrum-команда должна выполнить,
чтобы превратить требования и задачи в готовый для использования в бизнес-процессах
инкремент.
10
Бэклог спринта должен быть достаточно "глубоко" детализирован по сравнению
с задачами в Product Backlog, чтобы прогресс работы над ним можно было видеть
ежедневно, не уделяя дополнительное время сбору необходимых деталей.
Scrum-команда работает над бэклогом спринта на всем его протяжении, и он
постоянно изменяется вместе с прогрессом команды.
Изменения происходят потому, что в процессе работы возникают всё новые и
новые задачи, которые нужно выполнить для достижения конечного результата.
Если возникает необходимость в дополнительном объеме работы, то эти задачи
добавляются в бэклог продукта и планируются к выполнению в следующих спринтах.
После того как они выполнены, оценки оставшегося объема работ обновляются.
Если некоторые задачи считаются уже неактуальными, то их удаляют.
Только Scrum-команда может изменять свой бэклог во время спринта. По
решению команды и ее участников задачи могут добавляться или удаляться, но
необходимо четко обосновать, почему это необходимо.
Инкремент продукта
Цель команды Scrum в отдельно взятом спринте – предоставлять работающий
инкремент продукта.
Работающий "прирост" продукта (инкремент) – обязательный результат каждого
спринта Scrum.
Инкремент по своей сути – это продукт, который будет приносить бизнес-пользу
в момент своей разработки после того, как результаты определенного спринта
реализованы Scrum-командой и приняты заказчиком.
11
Критерии Готовности
Когда Элемент Бэклога Продукта или Инкремент описывается как «Готовый»,
каждый в команде должен понимать, что именно означает «Готовый». Хотя понимание,
при каких условиях работа является выполненной, может значительно отличаться от
команды к команде, оно должно быть едино для всех участников одной Скрам-команды.
Это необходимо для обеспечения прозрачности.
Решение о готовности Инкремента продукта принимается исходя из Критериев
Готовности, принятых Скрам-командой.
Если над выпуском одной системы или продукта работает несколько Скрам
Команд, то их Команды Разработки должны совместно выработать Критерии
Готовности.
Каждый Инкремент прибавляется ко всем предыдущим Инкрементам и
тщательно тестируется, чтобы убедиться, что все Инкременты работают вместе.
По мере того, как Скрам-команда будет становиться более зрелой, Критерии
Готовности, скорее всего, будут становиться строже, обеспечивая более высокое
качество разрабатываемого продукта. Применение новых критериев может привести к
тому, что в уже принятых «Готовых» Инкрементах обнаружится работа, которую
необходимо будет выполнить.
Любая система или продукт должны иметь Критерии Готовности, это
обязательный стандарт для любой выполняемой работы в рамках этой системы или
продукта.
12
Лекция 6
Методологии разработки программного обеспечения (ч.4)
Планирование спринта
Для Scrum подходит вид планирования, при котором работа, которую надо будет
выполнить в ближайшей перспективе, подробно планируется с глубоким раскрытием
структуры необходимых работ. Далеко отстоящая работа планируется с относительно
неглубоким раскрытием иерархии работ. По мере выполнения глубоко раскрытой и
понятной работы производится более подробное планирование последующих задач с
возможной корректировкой общих целей.
Но тут появляется проблема: не всегда есть возможность прогнозировать даже
ближайшее будущее, даже в процессах и командах с постоянным прогрессом. Поэтому
планирование выполняется «волнами» или этапами, где действия ближнего этапа
детально планируются, а действия в далеком будущем отложены. Необходимо
выполнять столько волн планирования, сколько итераций работы необходимо провести
для достижения конечного и удовлетворяющего потребностям результата.
Такой подход к планированию называется планированием методом «набегающей
волны».
Он наиболее полно соответствует принципам Scrum и поддерживает процесс
поэтапной разработки программного продукта.
1
Эта деятельность прекрасно сочетается с техникой планирования методом
набегающей волны и называется поэтапным уточнением ранее намеченных планов.
Актуализация данных
Имеющаяся информация о задачах актуализируется, отсутствующая
запрашивается или добавляется.
Не следует совмещать встречу для Backlog Grooming с планированием спринта.
Груминг в обязательном порядке должен проводится в формате отдельной встречи.
Именно груминг позволит проработать имеющиеся задачи к этапу планирования
спринта. На груминге обязательно должен присутствовать владелец продукта и scrum-
команда. По возможности стоит пригласить представителя клиента.
Подготовка
Для проведения покера планирования необходимо подготовить список
обсуждаемых функций и несколько колод пронумерованных карт. Список функций
(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. (Ноль означает, что функция или уже реализована, или настолько мала, что нет
смысла присваивать ей число.)
Процедура проведения
Каждому участнику обсуждения выдаётся по одной колоде карт. Все колоды
идентичны друг другу.
Scrum-мастер, не участвующий в обсуждении, ведёт собрание.
Владелец продукта представляет краткие обзоры каждого пункта из бэклог.
Достоинства метода
В планировании участвует вся команда.
У каждого члена команды есть возможность высказаться, не испытав влияния
более авторитетных коллег.
Все члены команды берут на себя ответственность за сроки.
Оценки, полученные PP, более точные в сравнении с оценками, полученными с
помощью альтернативных методов оценок.
Техника PP минимизирует эффект привязки путём опроса каждого из
участников команды таким образом, что никто не знает чужого решения до
одновременного оглашения выбора каждого из участников.
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.
2
Для проведения Планирования Спринта нужны: Бэклог Продукта, последний
Инкремент продукта, прогноз возможностей Команды Разработки в будущем Спринте,
статистика её прошлой производительности.
При этом только Команда Разработки определяет количество Элементов Бэклога
Продукта, которые могут быть выполнены в Спринте. Ей же принадлежит
исключительное право оценивать объём работ, который по силам завершить в текущем
Спринте. Во время Планирования Спринта Скрам-команда также формирует Цель
Спринта.
Ежедневный Скрам
Ежедневный Скрам – это встреча Команды Разработки, которая проводится
каждый день во время Спринта. Встреча не должна занимать более 15 минут, за которые
Команда разработки планирует свою работу на ближайшие 24 часа. Команда
оптимизирует взаимодействие между её членами и повышает свою производительность,
анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт
работу. Для упрощения Ежедневный Скрам проводится каждый день в одно и то же
время.
Команда Разработки использует это событие для отслеживания прогресса по
работе над Бэклогом Спринта, а также для того, чтобы понять, успевает ли она
завершить задачи Спринта в срок.
Команда сама определяет формат встречи, но акцент всегда остается на
достижении Цели Спринта. Какие-то команды проведут дискуссию, какие-то будут
использовать вопросы,
например:
• Что я сделал вчера, что помогло Команде Разработки приблизиться к Цели
Спринта?
• Что я сделаю сегодня, чтобы помочь Команде Разработки достичь Цели
Спринта?
• Вижу ли я какие-либо препятствия, которые могут помешать мне или Команде
Разработки достичь Цели Спринта?
Часто сразу после Ежедневного Спринта Команда Разработки в полном составе
или её отдельные участники встречаются для более детального обсуждения, или для
изменения, или перепланирования оставшейся в Спринте работы.
3
Скрам-мастер следит, чтобы встреча Команды Разработки состоялась, но за
проведение Ежедневного Скрама отвечает сама команда. Скрам-мастер обучает
Команду Разработки проводить Ежедневный Скрам за 15 минут или быстрее.
Ежедневный Скрам — это внутренняя встреча Команды Разработки. Если на ней
присутствует кто-то ещё, Скрам-мастер следит, чтобы они не мешали встрече.
Обзор Спринта
Обзор Спринта проводится в конце Спринта с целью инспекции Инкремента и, по
необходимости, адаптации Бэклога Продукта.
Скрам-команда и заинтересованные лица во время Обзора Спринта совместно
обсуждают, что было сделано за Спринт. Эти данные, как и любые изменения Бэклога
Продукта в течение Спринта, служат основанием для обсуждения следующих шагов к
оптимизации ценности Продукта.
Обзор Спринта — не статусная встреча, а неформальная. На ней проводится
демонстрация Инкремента Продукта для получения обратной связи и развития
сотрудничества. Для Спринтов длительностью один месяц продолжительность встречи
не превышает 4 часов.
4
Ретроспектива Спринта
Ретроспектива Спринта — это возможность для Скрам-команды провести
инспекцию, направленную на себя, и создать план улучшений командной работы в
следующем Спринте.
В качестве примера можно привести автомобиль и замену его масла. Грубым
интервалом замены масла считается порядка 15 000 км., то есть через такое число
километров необходимо слить старое масло и залить новое, иначе качество работы
двигателя может ухудшиться или, более того, это может привести к серьезной поломке
автомобиля и даже его выходу из строя. Scrum Team также нуждается в подобной
«замене масла», чтобы работа всегда была в наивысшей степени эффективной.
5
Пример Sprint Retrospective Meeting в разработке интернет-магазина
После завершения Sprint и проведения Sprint Reviews Meeting, команда Scrum
собралась для обсуждения эффективности её работы, которая была оценена каждым
самостоятельно.
Scrum Master решает задать вопрос каждому лично и узнать ответы на все три
вопроса.
Участник №1:
1. Я считаю, что команде следует начать использовать более развернутые
листы тестирования
2. ----
3. Я считаю, что команда должна продолжить использовать текущий вид
Product Backlog, он оптимально подходит.
Участник №2
1. -----
2. Мне кажется, команде надо прекратить использовать текущую IDE, её
«неповоротливость» замедляет работу.
3. Команде однозначно следует продолжить использовать текущую систему
контроля версий и облачных сохранений, с ней мы менее беспокоимся о потерях и более
концентрируемся на работе.
6
Стоит еще раз отметить, что формат проведения ретроспективы может быть
различным. Ретроспективы − это не единичное мероприятие. Они проводятся
регулярно, и по результатам каждого такого собрания выполняется основная цель −
создается план на ближайшую итерацию. Если отнестись к этой процедуре
профессионально, заранее проанализировать наиболее типичные проблемы,
возникающие в ходе ретроспективы, можно создать благоприятные условия развития
настоящей самоорганизующейся команды.
Velocity Scrum
Если представить себе движение автомобиля, то скорость в нём оценивается по
спидометру. Глядя на него всё предельно ясно. Однако в жизни в целом и в каком-то
конкретном деле нет спидометра, и как оценить скорость объективно – уже вопрос.
Если представить, что в автомобиле сломался спидометр, то скорость может быть
оценена постфактум, то есть когда человек будет ехать 60 минут и проедет, например,
100 км, затем за 60 минут – 120 км, то он будет видеть, с какой скоростью двигался –
около 110 км/ч. При этом, если во время следующих 60 минут он остановится и потратит
на заправку 12 минут, на обед 15 минут и проедет 55 км, то средняя скорость за весь
путь составит – 98 км/ч.
7
В таком графике, по сути, изображено Story Points, и на основе этих показателей
выстраивается среднее значение скорости. Однако график Velocity может быть и иной,
с простым отображением Story Points, на основе которых визуально видна тенденция.
Ведя свою команду к цели спринта, можно успешно достигнуть её, но при этом
упустить, что происходит на уровне продукта. А ведь порой из-за этого нарушается
целостность всей разработки.
Представьте, что вы едете на автомобиле в сторону цели, параллельно едет ещё
одна команда, но между вами находится преграда, и вы понятия не имеете, как движутся
соседи. Если представить, что обе команды везут некий груз и успех всей поездки
зависит от того, обе ли команды довезли его в сохранности, то их взаимодействие
просто необходимо.
Подобные встречи могут касаться вопросов взаимной интеграции или разговора о
проделанной работе и ближайших планах. Одним из важных плюсов таких встреч
является то, что со стороны можно увидеть те проблемы, которые не видно вблизи.
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.
11
Что представляет собой продукт в LeSS? Это полноценное (end-to-end),
клиенториентированное решение, которое будет использоваться реальными людьми.
Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или
библиотека.
LeSS включает в себя:
фундаментальные принципы, формирующие основу для других элементов
LeSS;
два процессных фреймворка;
руководства по запуску LeSS в компании;
реальные эксперименты в компаниях, которые привели к созданию LeSS.
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х годах японские
автомобили заполнили рынок США.
1
Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть
проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов,
как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического
проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на
разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов.
Как и Agile, Lean это скорее концепция, образ мышления. Это не методология,
поэтому в ней нет набора готовых практик. Конкретных правил тоже нет, но есть
приемы, которые помогают извлекать пользу. Но как разобраться, что значит Lean, если
нет методологии и правил? И как придерживаться философии, в которой не на что
опереться?
Придерживаться Lean ― значит всегда использовать системный подход, искать и
устранять потери, создавать поток. Поток ― это непрерывный процесс создания
ценности — не любого продукта, а именно того, который нужен потребителю.
3
Сильные стороны Lean
Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого
исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти
требования. Lean сочетает гибкость и структурированность.
4
1. Простота
В XP разработка начинается с самого простого решения, которое удовлетворит
текущую потребность в функциональности. Члены команды учитывают только то, что
должно быть сделано сейчас, и не закладывают в код функциональность, которая
понадобится завтра, через месяц или никогда.
2. Коммуникация
В XP коммуникация между разработчиками ведется не посредством
документации, а вживую. Команда активно общается между собой и с заказчиком.
3. Обратная связь
Обратная связь в XP реализуется сразу в трех направлениях:
фидбек от системы при постоянном тестировании модулей
фидбек от заказчика, т.к. он входит в команду и участвует в написании
приемочных тестов
фидбек от команды во время планирования касательно времени на разработку.
4. Смелость
Некоторые методики экстремального программирования настолько непривычны,
что требует смелости и постоянного контроля над собой.
5. Уважение
В экстремальном программировании уважение рассматривается с точки зрения
уважения к команде и самоуважения. Члены команды не должны заливать изменения,
которые поломают компиляцию, модульные тесты, или замедлят работу коллег.
Каждый стремится к высшему качеству кода и дизайна.
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
снижаются риски, связанные с разработкой, т.к. ответственность за проект
распределяется равномерно и уход/приход члена команды не разрушит процесс
затраты на разработку ниже, т.к. команда ориентирована на код, а не на
документацию и собрания
Kanban
Менеджмент Канбан в экономической практике означает такую организацию
предпринимательской деятельности − будь то производство, логистика или розничная
торговля − которую можно охарактеризовать как система «точно в срок». В самом
термине «Kanban», который переводится с японского как «видимая карточка», заложен
подход к оптимизации бизнеса за счет деления на операции и визуализации рабочего
процесса. И хотя философию Kanban впервые применили в фирме «Toyota» более
полувека назад, этот метод в современном понимании был разработан и предложен
экономистом Дэвидом Андерсоном.
Экономист Дэвид Андерсон, будучи весной 2005 года в Токио, во время прогулки
в Восточных садах Императорского дворца пришел к выводу, что многоразовые
разноцветные пластиковые билеты для туристов, называемые Kanban могут стать
инструментом экономической деятельности в условиях неопределенности. Совершив
прогулку и сдав Канбан, он, по сути, завершил «условную работу». Отметки о выдаче
карточек посетителям и получении их обратно контролёры делали на специальной доске
с колонками.
Андерсон пришёл к выводу, что посредством карточек и колонок можно,
например, контролировать запасы на складе или поставки товаров. За счет концепции
«точно в срок» удастся минимизировать материальные издержки и оптимизировать
продажи.
5 правил Канбан
1. Визуализация рабочего процесса.
2. Ограничение незавершенных производств (WIP — Work-In-Progress).
3. Управление потоком работ.
4. Понятность и прозрачность изменений.
5. Улучшение совместной работы (с использованием моделей и научного
метода).
Недостатки:
Система плохо работает с командами численностью более 5 человек
Он не предназначен для долгосрочного планирования.
9
Scrum (Скрам) и Kanban (Канбан) – это методы управления проектами. Они
являются представителями популярной методологии Agile-семейства. Эти методы
гибкие и итеративные, они могут использоваться для работы в любой отрасли, однако
лучше всего они подходят для IT-сферы. Оба метода близки, поэтому их инструменты
можно использовать в комбинации. Очень часто применяют гибридный подход. При
этом используют лучшее из Scrum и Kanban.
Несмотря на то, что данные методологии близки и имеют много общего, у них
достаточно много различий.
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 требуется выделять время на ежедневные митинги, на которых
планируются спринты и решаются организационные вопросы.
13
5. Доски
6. Показатели
15
Лекция 9
Разработка требований к программному обеспечению (ч.1)
1
недостаточно определенных требований и бессистемного изменения
процесса. Некорректные сведения от пользователей и недостатки
определения и управления требованиями клиентов — основные причины
провалов проектов.
Нигде более, как на стадии сбора требований так тесно не связаны
интересы всех заинтересованных в проекте лиц с успехом проекта.
Заинтересованные лица являются людьми или организациями
(юридические лица, такие как компании, комитеты по стандартизации), у
которых есть действительный интерес к системе. Они могут быть затронуты
этой системой прямо или косвенно.
К заинтересованным лицам также относятся:
− любой, кто пользуется системой (пользователи и обслуживающий
персонал)
− любой, кто извлекает выгоду из системы (функциональную,
политическую, финансовую и социальную)
− любой вовлечённый в покупку или обеспечение системы
− организации, которые регулируют аспекты системы (финансовые,
безопасность, и другие)
− люди или организации, настроенные против системы
(отрицательные заинтересованные лица),
− организации, ответственные за системы, которые
взаимодействуют с системой согласно проекту
− те организации, которые объединяются горизонтально с
организацией, для которой аналитик проектирует систему
Определение требований к ПО
Разные эксперты, говоря об одном и том же документе, могут называть
его пользовательскими требованиями, требованиями к ПО, бизнес-
требованиями, функциональными требованиями, системными
требованиями, требованиями к продукту или проекту, пользовательской
точкой зрения, функцией или ограничением. Имена, которые они применяют
к различным требованиям, также различаются. Заказчики зачастую считают,
что определенные ими требования — это высокоуровневая концепция
продукта, предназначенная для разработчиков. Те, в свою очередь, полагают,
что в отношении клиентов это детализированная разработка интерфейса
пользователя.
Мы будем считать, что Требования − это спецификация того, что
должно быть реализовано. В них описано поведение системы, свойства
системы или ее атрибуты. Они могут служить ограничениями в процессе
разработки системы.
Требования охватывают как видение пользователя, так и внешнее
2
поведение системы, а также представление разработчика о некоторых
внутренних характеристиках. Они включают как поведение системы в
определенных условиях, так и свойства, которые делают систему полезной и
даже доставляющей удовольствие конечным операторам.
Требования к ПО включают измерение времени. Они могут относиться
к настоящему времени — в этом случае они описывают текущие функции
системы. Или могут относиться к ближайшему (высокоприоритетные),
среднему (среднеприоритетные) или гипотетическому (низкоприоритетные)
будущему. Они могут даже относиться к прошлому времени, когда
описывают запросы, которые были ранее определены, а затем отброшены.
Классификация требований
3
Классификация требований по К. Вигерсу
Рисунок 1
5
пользователи смогли выполнить свои задачи (пользовательские требования)
в рамках бизнес-требований.
Функциональные требования описываются в форме традиционных
утверждений со словами «должен» или «должна»: «У пассажира должна
быть возможность распечатать посадочные талоны на все рейсы, на
которые он зарегистрировался» или «Если в профиле пассажира не указаны
предпочтения по выбору места, система резервирования должна сама
назначить ему место».
Бизнес-аналитик документирует функциональные требования в
спецификации требований к ПО (software requirements specification, SRS), где
описывается так полно, как необходимо, ожидаемое поведение системы
6
функциональных требований было реализовано для выполнения
пользователем его задач.
7
количественные показатели. Кроме того, затраты на объективное измерение
количественных нефункциональных требований могут оказаться крайне
высокими.
Свойства требований
− полнота,
− ясность,
− корректность,
− согласованность,
− верифицируемость,
− необходимость,
− полезность при эксплуатации,
− осуществимость,
− модифицируемость,
− трассируемость,
− упорядоченность по важности и стабильности,
− наличие количественной метрики.
Полнота.
Требование полноты можно рассматривать в двух аспектах: полнота
отдельного требования и полнота системы требований.
9
Полнота отдельного требования − свойство, означающее, что текст
требования не требует дополнительной детализации, то есть в нем
предусмотрены все необходимые нюансы, особенности и детали данного
требования.
Полнота системы требований − свойство, означающее, что
совокупность артефактов, описывающих требования, исчерпывающим
образом описывает все то, что требуется от разрабатываемой системы.
10
соображениями, либо опытом внедрения информационных систем на
аналогичных предприятиях, он должен проявить инициативу и собрать
совместное совещание сторон. Аргументы в пользу отсутствия
необходимости требования несомненно будут восприняты, особенно если
они будут мотивированы в бизнес-терминологии Заказчика и подтверждены
выкладками, прогнозирующими соотношение затрат на выполнение
требования и ожидаемой от него эффективности.
Более слабой, чем "необходимость" формулировкой обладает свойство
"полезность при эксплуатации". Разграничение между данными свойствами
можно провести следующим образом. Необходимыми следует считать
свойства, без выполнения которых невозможно, либо затруднено
выполнение автоматизированных бизнес-функций пользователей;
полезными при эксплуатации следует считать любые свойства, повышающие
эргономические качества продукта.
Осуществимость (выполнимость).
Выполнимость требования на практике определяется разумным
балансом между ценностью (степенью необходимости и полезности) и
потребными ресурсами. Так, если стоимость контракта на разработку
информационной системы составляет $10000, а затраты на выполнение
нового требования, возникшее в момент, когда проект выполнен наполовину,
оценивается в $4000, является ли оно невыполнимым? Скорее всего, да, если
Исполнитель докажет Заказчику новизну требования (требование не входило
в согласованные спецификации) и сложность его исполнения. Но, если
требование является критически важным, необходимым, но выпало из поля
зрения при подписании контракта Заказчик готов выделить дополнительно
финансирование, а Исполнитель − трудовые ресурсы − значит, требование
выполнимо. Таким образом, требование осуществимости в ряде случаев
также следует считать субъективным, а критерии его оценки лежат в области
договоренностей между Заказчиком и Исполнителем.
Трассируемость
Трассируемость требования определяется возможностью отследить
связь между ним и другими артефактами информационной системы
(документами, моделями, текстами программ и пр.). Отдельная трасса
представляет собой направленное бинарное отношение, заданное на
множестве артефактов ИС, где первый элемент отношения представляет
соответствующее требование, а второй − артефакт, зависимый от данного
требования.
11
На практике трассировки анализируются с помощью графовых, либо
табличных моделей.
13
Упорядоченность по важности и стабильности
Приоритет требования представляет собой количественную оценку
степени значимости (важности) требования. Приоритеты требований обычно
назначает представитель Заказчика. Разработчик, отталкиваясь от
приоритетности требований, управляет процессом реализации
информационной системы.
Стабильность требования характеризует прогнозную оценку
неизменности требований во времени.
Наличие количественной метрики
Количественные метрики играют важную роль в верификации и
аттестации информационных систем. В первую очередь это относится к
нефункциональным требованиям, которые, как правило, должны иметь под
собой количественную основу (запрос должен отрабатываться не более, чем
___ секунд; средняя наработка на отказ должна составлять не менее, чем ___
часов). Функциональные требования также могут расширяться
количественными мерами при помощи так называемых аспектов
применимости.
16
Обобщенная модель процесса формирования и анализа требований.
Специфицирование требований
Клиенты и конечные пользователи описывают свои требования на
естественном языке. После анализа этих требований происходит их
документирование. Этот документ называется Спецификацией требований к
программному обеспечению (Software Requirements Specification, SRS).
Эта спецификация работает как соглашение между заказчиком и
командой разработчиков о том, что должен делать программный продукт.
Правильная спецификация помогает предотвратить сбои программного
обеспечения. Это также помогает команде разработчиков получить четкое
представление о продукте, который они должны разработать.
Разница между Требованием и Спецификацией в разработке
программного обеспечения заключается в том, что Требования — это
потребности заказчика, которые должны быть решены программным
обеспечением, тогда как Спецификация — это технический документ с
проанализированными требованиями.
18
одной и той же системной функции.
3. Проверка на полноту. Спецификация требований должна содержать
требования, которые определяют все системные функции и ограничения,
налагаемые на систему.
4. Проверка на выполнимость. На основе знания существующих
технологий требования должны быть проверены на возможность их
реального выполнения. Здесь также проверяются возможности
финансирования и график разработки системы.
20
«среднего пользователя», чтобы на основе его потребностей проектировать
продукт. Для корпоративных продуктов это попросту невозможно: директор
будет пользоваться одной функциональностью, его секретарь другой, а
бухгалтер третьей. По этой причине перед началом сбора требований
должны быть определены основные профили пользователей.
22
Лекция 10
Разработка требований к программному обеспечению (ч.2)
Определение стимулов
На данном этапе указываются основные причины, которые стимулируют
принятие решения о создании этого продукта.
Как правило, причиной создания продукта может служить одна или несколько
проблем: потребность, производственная необходимость, потребность заказчика,
технический, юридические ограничения или нормы и т.д.
Определение целей продукта и критериев успеха
Необходимо описать основные преимущества, которые предоставит продукт для
бизнеса. Сделать это надо в измеряемом виде. Также нужно определить механизм для
измерения успеха продукта в конечном итоге.
Например, основные цели
Финансовые:
Освоить Х% рынка за Y месяцев.
Увеличить сектор рынка в стране X на Y% за Z месяцев.
Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев.
Получить Х% прибыли или дохода по инвестициям в течение Y месяцев.
1
Достигнуть положительного баланса по этому продукту в течение Y месяцев.
Сэкономить $Х в год, которые в настоящий момент расходуются на
обслуживание системы.
Уменьшить затраты на поддержку на Х% за Z месяцев.
Получить не более X звонков в службу обслуживания по каждой единице
товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после
выпуска товара.
Увеличить валовую прибыль для существующего бизнеса с Х до Y%.
Нефинансовые:
Достигнуть показателя удовлетворения покупателей, равного, по крайней мере,
X, в течение Y месяцев со времени выпуска товара.
Увеличить производительность обработки транзакций на Х% и снизить
уровень ошибок данных до величины не более Y%.
Достигнуть определенного времени для достижения доминирующего
положения на рынке.
Разработать надежную платформу для семьи связанных продуктов.
Разработать специальную базовую технологическую основу для организации.
Получить X положительных отзывов в отраслевых журналах к определенной
дате.
Добиться признания продукта лучшим по надежности в опубликованных
обзорах продуктов к определенной дате.
Соответствовать определенным федеральным и государственным
постановлениям.
Уменьшить время оборота до X часов на Y% звонков покупателей в службу
поддержки.
2
Часто встречающиеся нефункциональные требования
Создание сценариев
Наиболее эффективным способом получения ответа на эти вопросы является
определение сценариев работы пользователей с будущим продуктом.
Сценарий — это совокупность всех процессов, в которых будет участвовать
продукт, а также описание окружения, в котором его планируется использовать.
Сценарий не должен являться описанием работы отдельного пользователя для
достижения конкретной цели. Его ценность состоит в том, что он описывает способы
взаимодействия с продуктом всех его пользователей одновременно на протяжении
всего цикла эксплуатации продукта. Таким образом, сценарий гарантирует отсутствие
взаимоисключающих требований к продукту и дает возможность легко убедиться, что
никто и ничто не забыто. Для проверки сценария надо всего лишь проанализировать
его выполнение всеми заинтересованными лицами (проиграть его).
3
Для продуктов под заказ сценарии использования продукта формируются самим
заказчиком. Как правило — сколько заказчиков, столько и сценариев. Наиболее
эффективным методом является живой диалог с заказчиком, в котором аналитик
задает наводящие вопросы (пытается разговорить заказчика), а заказчик отвечает на
них.
Если личный контакт невозможен, как правило, помогают вопросники,
содержащие «нужные» вопросы, по которым заказчику легче будет написать
сценарий.
Для открытого рынка сначала определяются профили будущих клиентов
продукта, а затем для каждого из них создается подробный сценарий его
использования. Аналитик может описывать сценарии самостоятельно, используя
информацию из личного опыта или открытых источников. Другой вариант,
позволяющий достичь явного преимущества — найти клиентов или компании,
подходящие под ранее определенные профили и получить сценарии непосредственно
от них.
4
и не реализовать второе). Если требования столь сильно зависят друг от друга, что
должны быть реализованы только вместе, лучше их объединить.
Как только все требования структурированы, следует назначить им приоритет.
Обзор конкурентов
Для определения текущего положения на рынке крайне важно серьезно подойти
к обзору конкурентов.
Еще одна цель обзора конкурентов — рассмотрение идей, реализованных в
продукте.
Цель проста — использовать наиболее удачные решения, реализованные в
конкурирующих продуктах, и исключить неудачные. Так сказать, сделать работу над
ошибками других.
Структура обзора конкурентов обычно следующая:
1. Конкурентное положение на рынке.
2. Список конкурентов (Резюме по каждому конкуренту).
3. Список проблем, которые призваны решать продукты.
4. Список возможностей продуктов.
В процессе создания обзора вам потребуется пройти этапы, описанные ниже.
1. Определить список конкурентов на рынке и выделить лидеров. Вся
дальнейшая работа проводится с лидерами на рынке. Определить лидеров можно,
используя различные обзоры, результаты опросов или продаж. Следует учесть, что в
числе лидеров может оказаться не только продукт с отличным функционалом, но и
бесплатное приложение, предоставляющее необходимый минимум возможностей.
Если предметная область продуктов достаточно популярна, то в сети можно
найти уже готовый обзор, который будет содержать необходимую для вас
информацию.
2. Узнать цену и способ доставки конкурентов. Также нужно постараться
достать демонстрационную версию продукта. Если это не удалось, то надо хотя бы
найти маркетинговые материалы, содержащие список возможностей и руководство
пользователя.
3. Составить список проблем, которые решает каждый конкурент. Этот
раздел обзора конкурентов особенно интересен при проектировании продукта для
открытого рынка, так как благодаря ему аналитик сможет определить максимальное
количество проблем, для решения которых пользователи захотят купить будущий
продукт.
Составить список проблем можно, исследовав продукт самостоятельно, но более
эффективный способ — просмотреть документацию по продукту. Качественные
продукты содержат сценарии использования продукта в тех или иных ситуациях, а
маркетинговые материалы — выгоды, которые сулит продукт при его использовании.
Все проблемы, для решения которых созданы продукты, должны отвечать на
вопрос «зачем?».
Суммарную информацию о конкурентах желательно поместить в таблицу. В ней
нужно указать, кто имеет возможность решать указанную проблему (сегмент рынка
или профиль пользователей) и насколько важно иметь возможность ее решать
(обязательно (essential), полезно (useful), желательно (desirable)). В ячейке продукта
напротив каждой проблемы нужно указать предоставляет ли конкурент эту
возможность или нет (обычно помечаются как «+», «−» или «+/−»). Также полезно
дополнять записи кратким описанием проблемы и заметками о конкурентах.
5
По завершении исследования проблем, которые решают продукты конкурентов,
следует провести повторный анализ бизнес требований к своему продукту.
Полученная информация о конкурентах поможет вам сделать бизнес требования к
вашему продукту лучше.
Совет: Если вы занимаетесь проектированием новой версии продукта, то
имеет смысл добавить предыдущую его версию в качестве конкурента. Это
поможет вам увидеть текущее конкурентное положение продукта и различия между
старой и новой его версиями.
4. Составить список возможностей. Здесь нужно описать все важные
возможности, которые были реализованы в конкурентных продуктах для
удовлетворения проблем. На основе этого списка можно узнать, как хорошо продукт
решает заявленные проблемы, какие у него сильные и слабые стороны.
На этом этапе вам придется работать либо с самим продуктом, либо с его
документацией.
Результатом работы будет таблица со списком возможностей, которые
предоставляют все продукты. В столбце продукта напротив каждой возможности
должно быть указано предоставляет ли конкретный продукт эту возможность (обычно
помечаются как «+» или «−»). Также полезно дополнять записи кратким описанием
возможности и заметками о конкурентах.
Источники требований
Основным источником требований к информационной системе, безусловно,
являются соображения, высказанные представителями Заказчика. Данная информация
структурируется как минимум на 2 уровня:
– бизнес-требования
– требования пользователей.
Наряду с требованиями, высказанными Заказчиком, целесообразно собирать и
требования от других совладельцев системы: сотрудников аналитической группы
исполнителя, внешних экспертов и т.д.
Результирующий, часто достаточно сырой материал рассматривается, как
документ "Требования совладельцев". На требования совладельцев обычно не
накладывается никаких специальных ограничений.
Другим важным источником информации, помимо выявления требований,
являются артефакты, описывающие предметную область. Это могут быть документы с
описанием бизнес-процессов предприятия, должностные инструкции, распоряжения,
своды бизнес-правил, принятые на предприятии.
Таким образом, основными источниками, образующими "вход" процесса
выявления требований, являются требования, высказанные совладельцами, как
таковые или (и) артефакты, описывающие объект исследования.
Однако, это достаточно упрощенный взгляд: чтобы данные поступили "на вход",
аналитики требований должны проделать немалую работу, связанную с подбором
респондентов и информационных материалов, организацией интервью и т.д.
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)
Объекты проектирования.
Проектированию обычно подлежат:
Архитектура ПО;
Устройство компонентов ПО;
Пользовательские интерфейсы.
1
Разработка концепции Изучение объекта
АС
Проведение необходимых научно-исследовательских
работ
Разработка вариантов концепции АС и выбор варианта
концепции АС, удовлетворяющего требованиям
пользователя
Оформление отчета о выполненной работе
Техническое задание Разработка и утверждение технического задания на
создание АС
Эскизный проект Разработка предварительных проектных решений по
системе и ее частям
Разработка документации на АС и ее части
Технический проект Разработка проектных решений по системе и ее частям
Разработка документации на АС и ее части
Разработка и оформление документации на поставку
изделий для комплектования АС и (или) технических
требований (технических
заданий) на их разработку
Разработка заданий на проектирование в смежных
частях проекта объекта автоматизации
Рабочая документация Разработка рабочей документации на систему и ее части
Разработка или адаптация программ
Ввод в действие Подготовка объекта автоматизации к вводу АС в
действие
Подготовка персонала
Комплектация АС поставляемая изделиями
(программными и техническими средствами,
программно-техническими комплексами,
информационными изделиями)
Строительно-монтажные работы
Пусконаладочные работы
Проведение предварительных испытаний
Проведение опытной эксплуатации
Проведение приемочных испытаний
Сопровождение АС Выполнение работ в соответствии с гарантийными
обязательствами. Послегарантийное обслуживание
2
Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на
всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в
одну стадию «Техно-рабочий проект». В зависимости от специфики создаваемых АС и
условий их создания допускается выполнять отдельные этапы работ до завершения
предшествующих стадий, параллельное во времени выполнение этапов работ,
включение новых этапов работ.
На этапе "Обследование объекта и обоснование необходимости создания АС"
в общем случае проводят:
- сбор данных об объекте автоматизации и осуществляемых видах деятельности;
- оценку качества функционирования объекта и осуществляемых видов
деятельности, выявление проблем, решение которых возможно средствами
автоматизации;
- оценку (технико-экономической, социальной и т.п.) целесообразности создания
АС.
3
На этапе "Разработка предварительных проектных решений по системе и ее
частям" определяются: функции АС; функции подсистем, их цели и эффекты; состав
комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная
структура; функции системы управления базой данных; состав вычислительной
системы; функции и параметры основных программных средств.
4
На этапе "Подготовка персонала" проводят обучение персонала и проверку его
способности обеспечить функционирование АС.
5
- устранению выявленных недостатков и обеспечению стабильности
эксплуатационных характеристик АС;
- внесению необходимых изменений в документацию на АС.
Архитектурная/проектная документация
Проектная документация обычно описывает продукт в общих чертах. Не
описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос
«почему именно так». Например, в проектном документе программист может описать
обоснование того, почему структуры данных организованы именно таким образом.
Описываются причины, почему какой-либо класс сконструирован определённым
образом, выделяются паттерны, в некоторых случаях даже даются идеи как можно будет
выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или
пользовательскую документацию, но всё это действительно важно для проекта.
Техническая документация
При создании программы, одного лишь кода, как правило, недостаточно. Должен
быть предоставлен некоторый текст, описывающий различные аспекты того, что
именно делает код. Такая документация часто включается непосредственно в исходный
код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технический характер и в
основном используется для определения и описания API, структур данных и
алгоритмов.
Часто при составлении технической документации используются
автоматизированные средства — генераторы документации, такие как Doxygen, javadoc,
NDoc и другие. Они получают информацию из специальным образом оформленных
комментариев в исходном коде, и создают справочные руководства в каком-либо
формате, например, в виде текста или HTML.
Использование генераторов документации и документирующих комментариев
многими программистами признаётся удобным средством, по различным причинам. В
частности, при таком подходе документация является частью исходного кода, и одни и
те же инструменты могут использоваться для сборки программы и одновременной
сборки документации к ней. Это также упрощает поддержку документации в
актуальном состоянии.
6
Пользовательская документация
Отличие от технической документации, сфокусированной на коде и том, как он
работает, пользовательская документация описывает лишь то, как использовать
программу.
Обычно, пользовательская документация представляет собой руководство
пользователя, которое описывает каждую функцию программы, а также шаги, которые
нужно выполнить для использования этой функции. Хорошая пользовательская
документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае
возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение
и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если
имеется сквозной предметный указатель. Логическая связность и простота также имеют
большое значение.
Существует три подхода к организации пользовательской документации.
Вводное руководство, наиболее полезное для новых пользователей,
последовательно проводит по ряду шагов, служащих для выполнения каких-либо
типичных задач.
Тематический подход, при котором каждая глава руководства посвящена какой-
то отдельной теме, больше подходит для совершенствующихся пользователей.
В последнем, третьем подходе, команды или задачи организованы в виде
алфавитного справочника — часто это хорошо воспринимается продвинутыми
пользователями, хорошо знающими, что они ищут.
Жалобы пользователей обычно относятся к тому, что документация охватывает
только один из этих подходов, и поэтому хорошо подходит лишь для одного класса
пользователей. Во многих случаях разработчики программного продукта ограничивают
набор пользовательской документации лишь встроенной системой помощи,
содержащей справочную информацию о командах или пунктах меню. Работа по
обучению новых пользователей и поддержке совершенствующихся пользователей
перекладывается на частных издателей, часто оказывающих значительную помощь
разработчикам.
Маркетинговая документация
Для многих приложений необходимо располагать рядом с ними рекламные
материалы, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая
форма документации имеет целью:
− подогреть интерес к продукту у потенциальных пользователей
− информировать их о том, что именно делает продукт, с тем чтобы их ожидания
совпадали с тем, что они получат
− объяснить положение продукта по сравнению с конкурирующими решениями
Одна из хороших маркетинговых практик — предоставление слогана— простой
запоминающейся фразы, иллюстрирующей то, что мы хотим донести до пользователя,
а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы дают
более ясную картину о возможностях и способах использования программы, чем всё
остальное.
7
В соответствии с данными стандартами должны оформляться следующие
программные документы:
Спецификация должна содержать перечень и краткое описание назначения всех
файлов программного обеспечения, в том числе и файлов документации на него.
Спецификация является обязательной для программных систем, а также их
компонентов, имеющих самостоятельное применение.
Ведомость держателей подлинников (код вида документа – 05) должна
содержать список предприятий, на которых хранятся подлинники программных
документов.
Текст программы (код вида документа – 12) должен содержать текст программы
с необходимыми комментариями.
Описание программы (код вида документа – 13) должно содержать сведения о
логической структуре и функционировании программы.
Ведомость эксплуатационных документов (код вида документа – 20) должна
содержать перечень эксплуатационных документов на программу, к которым относятся
документы с кодами 30, 31, 32, 33, 34, 35, 46.
Формуляр (код вида документа – 30) должен содержать основные характеристики
программного обеспечения, комплектность и сведения об эксплуатации программы.
Описание применения (код вида документа – 31) должно содержать сведения о
назначении программного обеспечения, области применения, применяемых методах,
класс решаемых задач, ограничениях для применения, минимальной конфигурации
технических средств.
Руководство системного программиста (код вида документа – 32) должно
содержать сведения для проверки, обеспечения функционирования и настройки
программы на условия конкретного применения.
Кроме того, в него часто включают и описание необходимого обслуживания,
которое раньше приводилось в руководстве оператора (ГОСТ 19.505-79) и/или
руководстве по техническому обслуживанию (ГОСТ 19.508-79). В настоящее время
данную схему используют для составления руководства системному администратору.
Руководство системного программиста должно содержать следующие разделы:
• общие сведения о программном продукте,
• структура,
• настройка,
• проверка,
• дополнительные возможности,
• сообщения системному программисту.
Раздел Общие сведения о программе должен включать описание назначения и
функций программы, а также сведения о технических и программных средствах,
обеспечивающих выполнение данной программы (например, объем оперативной
памяти, требования к составу и параметрам внешних устройств, требования к
программному обеспечению и т. п.).
В разделе Структура программы должны быть приведены сведения о структуре
программы, ее составных частях, о связях между составными частями и о связях с
другими программами.
В разделе Настройка программы должно быть приведено описание действий по
настройке программы на условия практического применения.
8
В разделе Проверка программы должно быть приведено описание способов
проверки работоспособности программы, например, контрольные примеры.
В разделе Дополнительные возможности должно быть приведено описание
дополнительных возможностей программы и способов доступа к ним.
В разделе Сообщения системному программисту должны быть указаны тексты
сообщений, выдаваемых в ходе выполнения настройки и проверки программы, а также
в ходе ее выполнения, описание их содержания и действий, которые необходимо
предпринять по этим сообщениям.
9
В разделе Ожидаемые технико-экономические показатели указывают технико-
экономические показатели, обосновывающие преимущество выбранного варианта
технического решения.
В разделе Источники, использованные при разработке, указывают перечень
научно-технических публикаций, нормативно-технических документов и других
научно-технических материалов.
10
представляют планы на следующий период, обеспечивают контрольные механизмы и
обзор проекта.
Обеспечение качества
Требуется документация разработки и документация продукции для выполнения
задач, связанных с обязанностями по обеспечению качества программного обеспечения.
Инструкции и справки
Документация, требующаяся операторам, пользователям, руководителям и
другим заинтересованным лицам для того, чтобы понимать и использовать
программную продукцию.
Исторические справки
Документация, требуемая в качестве исторической справки по проекту. Данная
документация может помочь в переносе и переводе программного обеспечения в новое
окружение.
11
Понятие и основные процессы инициации проекта
Инициация проекта (Project Initiating) – стадия процесса управления проектом,
результатом которой является санкционирование начала проекта или очередной фазы
его жизненного цикла
Основными причинами появлениями (источниками идей) проектов являются:
• Неудовлетворенный спрос;
• Избыточные ресурсы;
• Инициатива предпринимателей;
• Реакция на политическое давление;
• Интересы кредиторов.
12
• Качество:
• Выработка стратегии управления качеством в проекте (определение
целей и задач, критериев успеха и неудач, ограничений и допущений)
• Определение общих требований и принципов обеспечения качества
(Стандарты и правила)
• Требования к системе управления качеством
• Риски:
• Определение целей управления рисками в проекте
• Идентификация факторов риска и неопределенности
• Определение возможных источников рисков
• Выбор стратегии управления рисками в проекте
• Анализ альтернатив
• Определение требований к системе управления рисками
• Персонал:
• Выработка стратегии управления персоналом (определение цели и
задач управления персоналом, требований к персоналу, ограничений)
• Определение потребности в трудовых ресурсах проекта
• Определение структуры и функций команды проекта
• Формирование жизненного цикла команды
• Анализ возможностей обеспечения проекта нужными
специалистами
• Определение требований к управлению персоналом
• Коммуникации:
• Определение участников проекта
• Определение базовой документации проекта
• Определение требований к коммуникациям
• Обоснование и выбор коммуникационных технологий для управления
проектом
• Оценка альтернатив
• Контракты:
• Проведение маркетинга рынка продуктов и услуг
• Разработка стратегии управления контрактами
• Составление спецификации продуктов и услуг
• Определение возможных источников приобретения ресурсов
• Анализ альтернатив
• Изменения:
• Выработка стратегии управления изменениями
• Анализ возможных изменений
• Определение принципов интеграции процессов управления
изменениями
2. Рассмотрение и утверждение концепции
3. Собственно инициирование:
• Принятие решения о начале проекта
• Определение и назначение управляющего проектом
• Принятие решения об обеспечении ресурсами выполнения первой фазы
проекта
13
Этап инициирования проекта характеризуется большой степенью
неопределенности исходных и результирующих данных, возможностью их изменения и
ограниченным временем для принятия решения.
14
Структурно-функциональная методология
В структурном анализе и проектировании используются различные модели,
описывающие:
Функциональную структуру системы;
Последовательность выполняемых действий;
Передачу информации между функциональными процессами;
Отношения между данными.
Наиболее распространенными реализациями этих моделей являются:
− Функциональная модель SADT (Structured Analysis and Design Technique);
− Модель IDEF3;
− DFD (Data Flow Diagrams) — диаграммы потоков данных.
− Диаграмма «сущность — связь» (ERD — Entity-Relationship Diagram).
16
- обратная связь по управлению (output-control feedback), когда выход
нижестоящей работы соединяется с входом по управлению вышестоящей работы;
17
В реальном процессе рабочему, производящему обработку, выдают заготовку и
технологические указания по обработке (или правила техники безопасности при работе
со станком). Ошибочно может показаться, что и заготовка, и документ с
технологическими указаниями являются входящими объектами, однако это не так. На
самом деле в этом процессе заготовка обрабатывается по правилам, отраженным в
технологических указаниях, которые должны соответственно изображаться
управляющей интерфейсной дугой.
Другое дело, когда технологические указания обрабатываются главным
технологом и в них вносятся изменения. В этом случае они отображаются уже входящей
интерфейсной дугой, а управляющим объектом являются, например, новые
промышленные стандарты, исходя из которых производятся данные изменения.
Декомпозиция (Decomposition)
Принцип декомпозиции применяется при разбиении сложного процесса на
составляющие его функции. При этом уровень детализации процесса определяется
непосредственно разработчиком модели.
18
Декомпозиция позволяет постепенно и структурированно представлять модель
системы в виде иерархической структуры отдельных диаграмм, что делает ее менее
перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого –
одного функционального блока с интерфейсными дугами, простирающимися за
пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком
называется контекстной диаграммой, и обозначается идентификатором “А-0”.
Глоссарий (Glossary).
Для каждого из элементов IDEF0: диаграмм, функциональных блоков,
интерфейсных дуг существующий стандарт подразумевает создание и поддержание
набора соответствующих определений, ключевых слов, повествовательных изложений
и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор
называется глоссарием и является описанием сущности данного элемента. Например,
для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может
содержать перечень полей соответствующего дуге документа, необходимый набор виз
и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая
диаграммы необходимой дополнительной информацией.
20
Метод моделирования IDEF3 предназначен для таких моделей процессов, в
которых важно понять последовательность выполнения действий и взаимозависимости
между ними.
21
Единицы работы — Unit of Work (UOW) (работы), являются центральными
компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя,
обозначающее процесс действия и номер (идентификатор).
Связи IDEF3 показывают взаимоотношения работ. Все связи в IDEF3 являются
однонаправленными и имеют следующие типы:
− временное предшествование,
− объектный поток,
− нечеткое отношение.
Изобра-
Название Назначение
жение
Графическое
Название Вид Правила инициации
обозначение
Разворачи- Каждое конечное действие
Соединение «и»
вающее обязательно инициируется
Сворачи- Каждое исходное действие
вающее обязательно должно завершиться
Соединение
Разворачи- Одно и только одно конечное дей-
«эксклюзивное
вающее ствие инициируется
"или"»
Сворачи- Одно и только одно исходное
вающее действие должно завершиться
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) представляют собой
иерархию функциональных процессов, связанных потоками данных.
Цель такого представления – продемонстрировать, как каждый процесс
преобразует свои входные данные в выходные, а также выявить отношения между
этими процессами.
Здесь источники информации (внешние сущности) порождают информационные
потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те,
в свою очередь, преобразуют информацию и порождают новые потоки, которые
переносят информацию к другим процессам или подсистемам, накопителям данных или
внешним сущностям – потребителям информации.
При создании диаграммы потоков данных используются четыре основных
понятия:
− потоки данных,
− процессы (работы) преобразования входных потоков данных в выходные,
− внешние сущности,
− накопители данных (хранилища).
26
− Каждая сущность может обладать любым количеством связей с другими
сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями,
значимая для рассматриваемой предметной области. Связь — это ассоциация между
сущностями, при которой каждый экземпляр одной сущности ассоциирован с
произвольным (в том числе нулевым) количеством экземпляров второй сущности, и
наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для
рассматриваемой предметной области и предназначенная для квалификации,
идентификации, классификации, количественной характеристики или выражения
состояния сущности. Атрибут представляет тип характеристик или свойств,
ассоциированных с множеством реальных или абстрактных объектов (людей, мест,
событий, состояний, идей, предметов и т.д.).
Экземпляр атрибута — это определенная характеристика отдельного элемента
множества. Экземпляр атрибута определяется типом характеристики и ее значением,
называемым значением атрибута.
На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными
сущностями. Таким образом, экземпляр сущности должен обладать единственным
определенным значением для ассоциированного атрибута.
27
Лекция 12
Методы анализа и проектирования программного обеспечения (ч.2)
Объектно-ориентированная методология
Объектный подход к разработке систем следует итеративному процессу с
наращиванием возможностей. Единая модель конкретизируется на этапах анализа,
проектирования и реализации – в результате успешных итераций добавляются новые
детали, при необходимости вводятся изменения и усовершенствования.
1
Модульность – это свойство системы, связанное с возможностью ее
декомпозиции на ряд внутренне сильно сцепленных, но слабо связанных между собой
подсистем (модулей).
Иерархия – это ранжированная или упорядоченная система абстракций,
расположение их по уровням.
2
графические символы, изображаемые вблизи визуальных элементов
диаграмм.
Сущности в UML
В UML определены четыре типа сущностей: структурные, поведенческие,
группирующие и аннотационные. Сущности являются основными объектно-
ориентированными элементами языка, с помощью которых создаются модели.
Структурные сущности - это имена существительные в моделях на языке UML.
Как правило, они представляют статические части модели, соответствующие
концептуальным или физическим элементам системы. Примерами структурных
сущностей являются "класс", "интерфейс", "кооперация", "прецедент", "компонент",
"узел", "актер".
Поведенческие сущности являются динамическими составляющими модели
UML. Это глаголы, которые описывают поведение модели во времени и в
пространстве. Существует два основных типа поведенческих сущностей:
взаимодействие - это поведение, суть которого заключается в обмене
сообщениями между объектами в рамках конкретного контекста для достижения
определенной цели;
автомат - алгоритм поведения, определяющий последовательность состояний,
через которые объект или взаимодействие проходят в ответ на различные события.
Группирующие сущности являются организующими частями модели UML. Это
блоки, на которые можно разложить модель. Такая первичная сущность имеется в
единственном экземпляре - это пакет.
Пакеты представляют собой универсальный механизм организации элементов в
группы. В пакет можно поместить структурные, поведенческие и другие
группирующие сущности. В отличие от компонентов, которые реально существуют во
время работы программы, пакеты носят чисто концептуальный характер, то есть
существуют только в процессе разработки.
Аннотационные сущности - это пояснительные части модели UML:
комментарии для дополнительного описания, разъяснения или замечания к любому
элементу модели. Имеется только один базовый тип аннотационных элементов -
3
примечание. Примечание используют, чтобы снабдить диаграммы комментариями или
ограничениями, выраженными в виде неформального или формального текста.
Отношения в UML
В языке UML определены следующие типы отношений: зависимость,
ассоциация, обобщение и реализация. Эти отношения являются основными
связующими конструкциями UML и также как сущности применяются для построения
моделей.
Зависимость (dependency) - это семантическое отношение между двумя
сущностями, при котором изменение одной из них, независимой, может повлиять на
семантику другой, зависимой.
Ассоциация (association) - структурное отношение, описывающее совокупность
смысловых или логических связей между объектами.
Обобщение (generalization) - это отношение, при котором объект
специализированного элемента (потомок) может быть подставлен вместо объекта
обобщенного элемента (предка). При этом, в соответствии с принципами объектно-
ориентированного программирования, потомок (child) наследует структуру и
поведение своего предка (parent).
Реализация (realization) является семантическим отношением между
классификаторами, при котором один классификатор определяет обязательство, а
другой гарантирует его выполнение. Отношение реализации встречаются в двух
случаях:
между интерфейсами и реализующими их классами или компонентами;
между прецедентами и реализующими их кооперациями.
5
Отношение агрегации имеет место между несколькими классами в том случае,
если один из классов представляет собой некоторую сущность, включающую в себя в
качестве составных частей другие сущности. Применяется для представления
системных взаимосвязей типа "часть-целое".
7
класса, отражающее совершенно иные его аспекты, но, тем не менее, соответствующее
спецификации. Таким образом, графическая нотация UML используются для
визуализации системы, а с помощью спецификаций описывают ее детали.
Практически каждый элемент UML имеет уникальное графическое изображение,
которое дает визуальное представление самых важных его характеристик. Нотация
сущности "класс" содержит его имя, атрибуты и операции. Спецификация класса
может содержать и другие детали, например, видимость атрибутов и операций,
комментарии или указание на то, что класс является абстрактным. Многие из этих
деталей можно визуализировать в виде графических или текстовых дополнений к
стандартному прямоугольнику, который изображает класс.
При моделировании объектно-ориентированных систем существует
определенное деление представляемых сущностей.
Во-первых, существует деление на классы и объекты. Класс − это абстракция, а
объект − конкретное воплощение этой абстракции. В связи с этим, практически все
конструкции языка характеризуются двойственностью "класс/объект". Так, имеются
прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы
и экземпляры узлов. В графическом представлении для объекта принято использовать
тот же символ, что и для класса, а название подчеркивать.
Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс
декларирует обязательства, а реализация представляет конкретное воплощение этих
обязательств и обеспечивает точное следование объявленной семантике. В связи с
этим, почти все конструкции UML характеризуются двойственностью
"интерфейс/реализация". Например, прецеденты реализуются кооперациями, а
операции - методами.
UML является открытым языком, то есть допускает контролируемые
расширения, чтобы отразить особенности моделей предметных областей.
8
Внутри рамки должно быть указано имя диаграммы и то подмножество системы,
которое иллюстрирует данная диаграмма. В левом верхнем углу рамки изображается
пятиугольник с именным тегом, который несёт информацию об имени и типе
диаграммы
Диаграммы UML
В большинстве ситуаций, для представления статических частей модели
используются структурные диаграммы, а для предоставления её динамической части
применяются поведенческие диаграмм.
Структурные диаграммы:
Диаграмма классов
Диаграмма компонентов
Диаграмма композитной/составной структуры
Диаграмма кооперации (UML2.0)
Диаграмма развёртывания
Диаграмма объектов
Диаграмма пакетов
Диаграмма профилей (UML2.2)
Диаграммы поведения:
Диаграмма деятельности
Диаграмма состояний
Диаграмма вариантов использования
9
Диаграммы взаимодействия:
Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
Диаграмма обзора взаимодействия (UML2.0)
Диаграмма последовательности
Диаграмма синхронизации (UML2.0)
Диаграмма классов.
Диаграмма классов является ключевым элементом в объектно-ориентированном
моделировании.
Это статическая структурная диаграмма, описывающая структуру системы,
демонстрирующая классы системы, их атрибуты, методы и зависимости между
классами.
Существуют разные точки зрения на построение диаграмм классов в
зависимости от целей их применения:
концептуальная точка зрения — диаграмма классов описывает модель
предметной области, в ней присутствуют только классы прикладных объектов;
точка зрения спецификации — диаграмма классов применяется при
проектировании информационных систем;
точка зрения реализации — диаграмма классов содержит классы, используемые
непосредственно в программном коде (при использовании объектно-ориентированных
языков программирования).
На диаграмме классы представлены в рамках, содержащих три компонента:
В верхней части написано имя класса. Имя класса выравнивается по центру и
пишется полужирным шрифтом. Имена классов начинаются с заглавной буквы. Если
класс абстрактный — то его имя пишется полужирным курсивом.
Посередине располагаются поля (атрибуты) класса. Они выровнены по левому
краю и начинаются с маленькой буквы.
Нижняя часть содержит методы класса. Они также выровнены по левому краю и
пишутся с маленькой буквы.
10
11
На диаграмме классов применяется один основной тип сущностей: классы
(включая многочисленные частные случаи классов: интерфейсы, примитивные типы,
классы-ассоциации и т.д.), между которыми устанавливаются следующие основные
типы отношений: зависимости, ассоциации, обобщения, реализации.
12
Диаграмма композитной/составной структуры (Composite structure diagram)
— статическая структурная диаграмма, демонстрирует внутреннюю структуру классов
и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Диаграммы композитной структуры могут использоваться совместно с
диаграммами классов.
13
Диаграмма развёртывания (Deployment diagram, диаграмма размещения) —
служит для моделирования работающих узлов (аппаратных средств, англ. node) и
артефактов, развёрнутых на них. В UML2 на узлах разворачиваются артефакты (англ.
artifact), в то время как в UML1 на узлах разворачивались компоненты. Между
артефактом и логическим элементом (компонентом), который он реализует,
устанавливается зависимость.
14
Диаграмма пакетов (Package diagram) — структурная диаграмма, основным
содержанием которой являются пакеты и отношения между ними. Диаграммы пакетов
служат, в первую очередь, для организации элементов в группы по какому-либо
признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма автомата
(состояний) (State Machine diagram,
диаграмма конечного автомата,
диаграмма состояний) — диаграмма, на
которой представлен конечный автомат
с простыми состояниями, переходами и
композитными состояниями.
15
Конечный автомат (англ. State machine) — спецификация последовательности
состояний, через которые проходит объект или взаимодействие в ответ на события
своей жизни, а также ответные действия объекта на эти события. Конечный автомат
прикреплён к исходному элементу (классу, кооперации или методу) и служит для
определения поведения его экземпляров.
16
студент хочет записаться на некий семинар, предлагаемый в рамках
некоторого учебного курса. С этой целью проводится проверка подготовленности
студента, для чего запрашивается список (история) семинаров курса, уже
пройденных студентом (перейти к следующему семинару можно, лишь проработав
материал предыдущих занятий). После получения истории семинаров объект класса
"Слушатель" получает статус подготовленности, на основе которой студенту
сообщается результат (статус) его попытки записи на семинар.
18
На рисунке изображается, как выглядит ситуация поступления в систему
звонка от клиента. Эта диаграмма может быть полезной в случае, если нужно
определить, как информация о звонке распространяется через компоненты ПО, какие
процессы при этом происходят в его различных частях и какие данные передаются.
Звонок от клиента приходит на офисную АТС, оттуда уходит на телефонный
аппарат свободного оператора и на сервер. От сервера через локальную сеть этот
звонок приходит на клиентское ПО того же оператора.
Из этой диаграммы становится понятно, что PBX (телефонная система
частного пользования, Офисная АТС) должен передавать серверу вместе с
информацией о звонке еще также информацию и об операторе, с которым он
прокоммутировал этого клиента. Ведь сервер должен послать информацию о новом
звонке на клиентское ПО именно этого оператора. Получая информацию о звонке,
клиентское ПО автоматически открывает оператору специальный диалог, в
который тот вводит информацию о звонке прямо во время разговора с клиентом.
Еще один важный момент, который следует из этой диаграммы: телефонный звонок
на аппарате оператора должен прозвенеть одновременно (или почти одновременно) с
появлением на его мониторе диалогового окна для внесения информации о звонке.
На диаграммах коммуникаций изображается взаимодействие ролей классов,
компонент, а не конкретные экземпляры. Роль – более общее понятие, чем объект
(экземпляр), и является гнездом, куда могут быть вставлены различные объекты. В
синтаксисе UML имена ролей обозначаются без подчеркивания, а имена экземпляров –
с подчеркиванием.
Диаграммы коммуникаций могут использоваться для пояснения кооперации,
композитной компоненты или другого композитного объекта. Поэтому в ней и
используются роли, а не объекты. Имя этого композитного объекта указывается в
заголовке диаграммы. Там же, в заголовке, используется тег comm для обозначения
диаграммы коммуникаций.
19
Диаграммы коммуникации и последовательности транзитивны, выражают
взаимодействие, но показывают его различными способами и с достаточной степенью
точности могут быть преобразованы одна в другую.
20
Диаграмма синхронизации (Timing diagram) — альтернативное представление
диаграммы последовательности, явным образом показывающее изменения состояния
на линии жизни с заданной шкалой времени. Может быть полезна в приложениях
реального времени.
– точка уничтожения
21
Диаграмма вариантов использования (Use case diagram, диаграмма
прецедентов) — диаграмма, на которой отражены отношения, существующие между
актёрами и вариантами использования.
Основная задача — представлять собой единое средство, дающее возможность
заказчику, конечному пользователю и разработчику совместно обсуждать
функциональность и поведение системы.
22
Как вариант возможно расположение надписи под эллипсом; это может
оказаться полезным в случае длинного имени прецедента.
На диаграмме прецеденты обычно располагаются в середине листа, а акторы —
слева. В случае, если прецедент активирует один актор, а результат выполнения
достается другому, актор-получатель располагается справа:
Сценарий прецедента
Поскольку прецедент представляет одну из функций программы, одного его
имени недостаточно для понимания его роли в проекте. Необходимо вкратце дать
определение сценария, согласно которому происходит его выполнение.
На раннем этапе проектирования сценарий очень кратко описывается в
словесной форме как последовательность действий (поток событий), осуществляемых
в процессе выполнения. На следующем этапе проектирования (построение диаграммы
23
устойчивости) эти описания сменит наглядная и непротиворечивая графическая
диаграмма.
Например, сценарий публикации статьи мог бы выглядеть примерно таким
образом:
− Заполнить сведения об авторе.
− Заполнить аннотацию.
− Скопировать текст статьи в соответствующее окно.
− Выполнить предварительный просмотр статьи.
− Подтвердить публикацию.
Несмотря на кажущуюся простоту, картина усложняется за счет того, что
сценарий помимо основного потока событий, который характеризует нормальное
поведение системы, зачастую включает один или несколько альтернативных потоков,
описывающих нетипичные случаи.
Например, в предыдущем примере во время предварительного просмотра
публикации автор может обнаружить, что статья выглядит не так, как он задумывал,
или содержит ошибки, которые следует исправить. В этом случае следует ожидать, что
он не будет подтверждать публикацию статьи, а либо перейдет к ее редактированию,
либо прекратит сеанс публикации вовсе, решив внести исправления автономно в свою
рабочую копию. Подобные возможности следует также не забыть включить в
прецедент, описав каждый альтернативный поток максимально кратко.
Включение
При включении один прецедент явно включает в себя поведение другого
прецедента в определенной точке потока событий.
Если одна и та же последовательность действий встречается в нескольких
прецедентах, имеет смысл не копировать ее каждый раз, а выделить ее в отдельный
прецедент, который включают в себя несколько базовых прецедентов.
Графически включение прецедента выглядит следующим образом:
24
На данной диаграмме отражен факт, что и для чтения темы, и для публикации
статьи нужно сначала пройти авторизацию на форуме, причем в обоих случаях
авторизация выполняется одинаково.
Расширение
Расширение выглядит аналогично включению, однако имеет иной смысл. Если
при включении дочернего прецедента в базовый его поток событий копируется в
поток событий базового прецедента, то при расширении поток событий дочернего
прецедента представляет альтернативный сценарий, который выполняется при
определенных условиях.
Обобщение
Если включение прецедента можно уподобить вызову подпрограммы, то
обобщение скорее напоминает наследование объектов: производные прецеденты могут
наследовать поведение базовых, при этом при необходимости уточняя либо
переопределяя их поведение.
25
Диаграммы прецедентов определяют зачем (или с какой целью) актеры
взаимодействуют с системой. Для того, чтобы ответить не только на вопрос «Зачем
происходит взаимодействие с системой? Но и как происходит взаимодействие?»
необходимо будет обратиться к диаграммам коммуникации и последовательности
(sequence и collaboration) и деятельности (activity).
26
Персона (персонаж) — это обобщенное, но реалистичное описание типичного
или целевого пользователя продукта, то есть архетип, а не реальный живой человек, но
персонажи должны описываться так, как если бы они были настоящими людьми.
Персонаж не должен документировать каждый аспект жизни воображаемого человека,
а должен фокусироваться на тех характеристиках, которые влияют на то, что
разрабатывается.
Персонажи нужны для того, чтобы приблизиться к реальному клиенту и не
забывать его при разработке продукта.
Создавать персонажей стоит «Как можно раньше». В идеале процесс создания
персоны должен быть частью фазы продуктового исследования, прежде чем начнется
фактический процесс проектирования и разработки. Поведение каждого
вымышленного пользователя должно быть основано на фактических агрегированных
данных, полученных на основании поведения реальных пользователей.
Создание персонажа лучше всего делать в команде: не потому, что это сложно, а
потому, что он получит больше поддержки для дальнейшего использования. Чтобы
инициировать процесс создания персоны, стоит начать с определения характеристик
пользователей, наблюдаемых в пользовательских исследованиях. Далее следует
сгруппировать эти характеристики в кластеры. Если несколько кластеров кажутся
слишком похожими, объединить их вместе или устранить любые атрибуты, которые
кажутся менее важными для бизнеса. После появления отдельных кластеров добавить
детали, чтобы сделать персонажа более реалистичным, правдоподобным и
запоминающимся.
Для этого необходимо указать следующую информацию о персонаже:
– Имя, возраст, пол и фотографию
– Ключевые слова, описывающие, что он делает в «реальной жизни»
– Уровень опыта в области использования вашего продукта или продуктов
конкурентов
– Контекст того, как они будут взаимодействовать с вашим продуктом
– Как часто они будут использовать его
– Цели и проблемы, для решения которых будут использовать ваш продукт
– Цитаты для подведения итогов
27
Ваша цель должна заключаться в создании правдоподобного и живого
персонажа. Стоит избегать добавления посторонних деталей, которые не имеют каких-
либо последствий для дизайна. Хотя имя и фотография могут показаться
неактуальными, их функция заключается в том, чтобы помочь запоминанию, что
является № 1 задачей персоны: чтобы все члены команды помнили пользователей, для
которых они создают продукт.
28
Лекция 13
Проектирование графического пользовательского интерфейса (ч.1)
1
Основные вопросы, решаемые UX дизайном
Успех продукта основывается на том, как пользователи его воспримут.
Используя продукт, люди обычно оценивают свой опыт взаимодействия следующим
образом:
Получил ли я пользу от этого продукта?
Легко ли его использовать?
Приятно ли его использовать?
Компоненты UX-дизайна
Существует пять основных компонентов UX:
Информационная архитектура (ИА)
Проектирование взаимодействия
Юзабилити
Прототипирование
Визуальный дизайн
2. Проектирование взаимодействия
Проектирование взаимодействия отвечает за определённые взаимодействия
пользователя и экрана монитора. Визуальный дизайн реагирует на действия
пользователя. Данные действия и цели пользователя рассматриваются во время
проектирования взаимодействия, чтобы бренд мог взаимодействовать с пользователем
посредством изображений, графики, шрифтов, определённых цветов, иконок и т.д.
Также проектирование взаимодействия использует прототипирования, для
определения специфичного поведения и функционирует с различными компонентами.
Например, во время дизайна мобильных приложений, для страницы входа будет
применена анимация сворачивания ("ease"), или она будет блекнуть (fade in), или
3
выезжать справа. Данные переходы должны быть изучены во время фазы создания
концепции взаимодействия, чтобы финальный продукт как можно ближе
соответствовал изначальной задумке дизайнера.
3. Юзабилити
Юзабилити заключается в использовании данных для определения валидности
решений дизайна. Роль UX дизайнера понять и воплотить потребности пользователей
и избавить их от любого разочарования во время использования продукта.
Эти данные могут быть получены различными способами − начиная от работы с
фокус-группой для исследования, изучения юзабилити в лаборатории, интервью один
на один, с посетителями сайта, отслеживанием поведения глаз, сортировка карточек,
A/B тестирование, телеметрии и так далее.
Юзабилити-тестирование призвано понять площадь охвата продукта, в то же
время определить поведение и потребности пользователя. На высшем уровне, хорошая
практика − проверить свои гипотезы на настоящих пользователях, проверить
изменения продукта, так чтобы он соответствовал потребностям аудитории.
4. Прототипирование
Прототип можно определить, как предварительную версию, из которой
разрабатываются другие формы. Дизайнеру прототипирование предоставляет дешёвый
и гибкий способ проверить, что выглядит хорошо и соответствует требованию, будь-то
мобильное приложение, физический продукт или веб-сайт. Также предоставляется
способ итерации на основе отзывов заинтересованных сторон и пользователей в
контексте исследований юзабилити.
Это дает представление о функциональности дизайна и любых его изменениях,
необходимых для того, чтобы сделать работу восхитительной и функциональной. Это
способ установить приоритеты проектирования, недорого протестировать варианты, а
затем выяснить логистические ограничения и конфликты относительно реализации. В
конечном итоге, прототипирование важно, так как это позволяет ближе взглянуть на
функционал продукта, прежде чем вкладывать время, ресурсы и деньги в разработку.
5. Визуальный дизайн
Визуальный дизайн отвечает за использование визуального аспекта продукта,
для улучшения интерфейса пользователя. Иногда, если дизайнер акцентирует
внимание на эстетической составляющей, это может идти в ущерб юзабилити.
Отличный визуальный дизайн может даже заставить пользователя не обращать
внимания на проблемы юзабилити. Визуальный дизайн сообщает нам, как продукт
работает с цветом, визуальной иерархией, типографикой и т.д.
4
Usable: Продукт должен быть простым и легким в использовании. Он
должен быть разработан так, чтобы быть знакомым и понятным.
Useful: Продукт должен удовлетворять потребности. Если он этого не
делает, что у пользователя нет причин его использовать.
Desirable: Визуальная эстетика продукта должна быть привлекательна.
Элементы дизайна могут вызывать позитивные эмоции и симпатию.
Findable: Если у пользователя возникли проблемы с продуктом, то они
должны быть в состоянии быстро найти решение.
Accessible: Дизайн продукта должен быть таким, чтобы даже физически
неполноценные люди могли иметь такой же опыт как и все остальные.
Credible: Компания и ее продукты должны вызывать доверие.
Когда дизайн продукта сочетает в себе эти 6 элементов, тогда он будет ценен для
пользователей, а максимизация ценности – основная цель UX.
Интерфейс
Интерфейс – совокупность технических, программных и методических
(протоколов, правил, соглашений) средств сопряжения в вычислительной системе
пользователей с устройствами и программами, а также устройств с другими
устройствами и программами.
Интерфейс – в широком смысле слова, это способ (стандарт) взаимодействия
между объектами. Интерфейс в техническом смысле слова задаёт параметры,
процедуры и характеристики взаимодействия объектов
Пользовательский интерфейс
Интерфейс пользователя (UI – англ. user interface) – разновидность интерфейсов,
в котором одна сторона представлена человеком (пользователем), другая –
машиной/устройством. Представляет собой совокупность средств и методов, при
5
помощи которых пользователь взаимодействует с различными, чаще всего сложными,
машинами, устройствами и аппаратурой.
Весьма часто термин применяется по отношению к компьютерным программам,
однако под ним может подразумеваться набор средств, методов и правил
взаимодействия любой системы, управляемой человеком.
Несколько широко распространённых примеров:
- меню на экране телевизора + пульт дистанционного управления;
- дисплей электронного аппарата (автомагнитолы, часов) + набор кнопок и
переключателей для настройки;
- приборная панель (автомобиля, самолёта) + рычаги управления.
Интерфейс двунаправленный (интерактивный) – когда устройство, получив
команды от пользователя и исполнив их, выдаёт информацию пользователю
некоторыми средствами – визуальными, звуковыми, тактильными и т.п. (приняв
которую, пользователь выдаёт устройству последующие команды предоставленными в
его распоряжение средствами: кнопки, переключатели, регуляторы, сенсоры, голосом,
и т. д.).
Поскольку интерфейс есть совокупность, то есть он состоит из элементов,
которые, сами по себе, также могут состоять из элементов (так, экран дисплея может
содержать в себе другие окна, которые, в свою очередь, могут содержать панели,
кнопки и прочие интерфейсные элементы).
Особое и отдельное внимание в интерфейсе пользователя традиционно
уделяется его эффективности и удобству пользования (юзабельности). Понятный,
удобный, дружественный – его основные характеристики.
Средства интерфейса:
- вывода информации из устройства к пользователю – весь доступный диапазон
воздействий на организм человека (зрительных, слуховых, тактильных, обонятельных
и т.д.) — экраны (дисплеи, проекторы) и лампочки, динамики, зуммеры и сирены и т.д.
- ввода информации/команд пользователем в устройство – множество
всевозможных устройств для контроля состояния человека – кнопки, переключатели,
потенциометры, датчики положения и движения, сервоприводы, жесты лицом и
руками, даже съём мозговой активности пользователя.
По наличию тех или иных средств ввода, интерфейсы разделяются на типы
жестовый, голосовой, брэйн (Нейрокомпьютерный интерфейс — система, созданная
для обмена информацией между мозгом и электронным устройством), и т.д.,
возможны смешанные варианты.
Методы интерфейса:
- набор правил, заложенных разработчиком устройства, согласно которым
совокупность действий пользователя должна привести к необходимой реакции
устройства и выполнения требуемой задачи – т.н. логический интерфейс. Правила эти
должны быть достаточно ясны для понимания, естественны и легки для запоминания
(всё это входит в понятие юзабилити);
Увеличение в устройстве (при равной функциональности) средств ввода-вывода
даёт упрощение построения методов управления и упрощение правил пользования, но
зато приводит к сложности восприятия информации пользователем – интерфейс
становится перегруженным. И наоборот – уменьшение средств отображения и
6
контроля приводит к усложнению правил управления – каждый элемент несёт на себе
слишком много функций. Потому проектировщики интерфейсов стараются принять
компромиссное решение между этими двумя крайностями в каждом отдельном случае.
Безопасность. Одним из основных направлений исследований в области
обеспечения безопасности пользовательских интерфейсов, и, в частности, визуальных
интерфейсов пользователя, является разработка моделей информационной
безопасности при условии комплексного учета информационных, функциональных,
психофизиологических и экологических аспектов безопасности.
Типы интерфейсов
Интерфейсы пользователя бывают двух типов:
1) процедурно-ориентированные:
– примитивные
– меню
– со свободной навигацией
2) объектно-ориентированные:
– прямого манипулирования.
Процедурно ориентированный интерфейс использует традиционную модель
взаимодействия с пользователем, основанную на понятиях "процедура" и "операция".
В рамках этой модели программное обеспечение предоставляет пользователю
возможность выполнения некоторых действий, для которых пользователь определяет
соответствие данных и следствием выполнения которых является получение
желаемого результата.
Процедурно-ориентированные интерфейсы:
1) обеспечивают пользователю функции, необходимые для выполнения задач;
2) акцент делается на задачи;
3) пиктограммы представляют приложения, окна или операции;
4) содержание папок и справочников отражается с помощью таблицы-списка.
7
навигацией реализуется с использованием событийного программирования, что
предполагает применение визуальных средств разработки (посредством сообщений).
8
контейнера или пиктограммы устройства обозначает сам объект, а потому не зависит
от содержимого.
Различие между типами объектов является условным, так как один и тот же
объект в разных ситуациях может вести себя то, как объект-данные, то, как объект-
устройство, то, как объект-контейнер (принтер – объект-устройство, может обладать
свойствами объекта-контейнера, может содержать объекты-данные в очереди на
печать).
Технология DragandDrop. («перетащил и бросил») − способ оперирования
элементами интерфейса в интерфейсах пользователя (как графическим, так и
текстовым, где элементы GUI реализованы при помощи псевдографики) при помощи
манипулятора «мышь» или сенсорного экрана.
Способ реализуется путём «захвата» (нажатием и удержанием главной (первой,
чаще левой) кнопки мыши) отображаемого на экране компьютера объекта,
программно доступного для подобной операции, и перемещении его в другое место
(для изменения расположения) либо «бросания» его на другой элемент (для вызова
соответствующего, предусмотренного программой, действия). По отношению к окнам
(также способным к перемещению подобным способом) данный термин обычно не
употребляется.
Существует два вида пунктов назначения: один принимает объект, а другой его
копию (Пользователь «бросает» документ в «корзину» – уничтожается сам документ, а
если на принтер, то передается копия документа).
Базовыми действиями и самыми простыми примерами drag-and-drop действий
являются: перемещение объекта, перемещение объекта из панели в панель.
Пакетная технология
Вначале накапливаются данные, и формируется пакет данных, а затем пакет
последовательно обрабатывается рядом программ. Недостатки этого режима − низкая
оперативность принятия решений и обособленность пользователя от системы.
9
− Переопределение клавиш клавиатуры в зависимости от контекста.
− Использование манипуляторов и серых клавиш клавиатуры для управления
курсором.
Собственно, WIMP
Этот подтип интерфейса характеризуется следующими особенностями:
− Вся работа с программами, файлами и документами происходит в окнах;
− Все программы, файлы, документы, устройства и другие объекты
представляются в виде значков;
− Все действия с объектами осуществляются с помощью меню;
− Широкое использование манипуляторов для указания на объекты.
Речевая технология
При этой технологии команды подаются голосом путем произнесения
специальных зарезервированных слов-команд.
Биометрическая технология
Здесь человек предстаёт как совокупность признаков поведения. Картинка
считывается с цифровой видеокамеры, а затем с помощью специальных программ
распознавания образов из этого изображения выделяются команды.
Семантический интерфейс
Об этой технологии известно крайне мало. Похоже, что она тесно связана с
искусственным интеллектом и сходна со всеми подтипами SILK и другими типами
тоже. Возможно, что в связи с важным военным значением этих разработок эти
направления были засекречены.
10
Метафора в пользовательском интерфейсе – такая организация интерфейса,
при которой обстановка на экране и способы взаимодействия с системой апеллируют к
ситуации, хорошо знакомой пользователю.
Метафора помогает объяснить новое, незнакомое явление через то, что
пользователь уже знает. Самая знаменитая метафора в сфере взаимодействия между
человеком и компьютером и дизайне пользовательского опыта — это «метафора
рабочего стола» Алана Кея. Она помогла перейти от ввода команд в командную строку
к управлению визуальными объектами, представленными в цифровой форме,
напрямую (Рисунок 1).
С помощью метафор можно вызывать эмоциональный отклик. Когда в Apple
велась работа над вторым поколением iMac, Стив Джобс и Джони Айв как-то раз
прогуливались в саду и пытались представить, как будет выглядеть новая модель
девайса. Стиву на глаза попался подсолнух, и он предложил сделать iMac второго
поколения похожим на подсолнух. На рисунке 2 своей гибкой ножкой, с помощью
которой можно менять положение экрана, девайс действительно напоминает
подсолнух.
11
Рисунок 2. Использование метафоры подсолнуха делает iMac более
«человечным».
Если предлагать людям самобытный продукт, не похожий на тот, что уже
существует, нужно описывать его хотя бы отчасти при помощи понятий, которые
аудитория хорошо понимает. Например, Pinterest, завоевавший 10 миллионов
пользователей за рекордное для социальной платформы время, построен на метафоре
доски для заметок. Пользователи «прикрепляют» к себе на доску фотографии, которые
нашли в Сети, и составляют из них тематические коллекции. Такая метафора
вдохновляет людей на творчество.
Достоинства метафор
- пользователю легче понимать и интерпретировать изображение на экране; ему
не нужно каждый раз заглядывать в руководство, чтобы узнать, как выполняется то
или иное действие (по крайней мере, некоторые действия должны естественно
следовать из метафоры)
- у пользователя возникает чувство психологического комфорта, характерного
для встречи с чем-то хорошо знакомым.
Недостатки метафор
- не для любой функциональности можно подобрать подходящую, технически
реализуемую и всем понятную метафору;
- почти всегда метафора будет сковывать функциональные возможности. Что
делать, если проектируемая система обладает большим количеством функций, чем
копируемый образец? Следование метафоре в таких условиях будет только вредить,
поскольку совпадающим функциям будет учиться легче, а несовпадающим – сложнее
(они будут слишком иначе устроены);
- не обязательно, что сам по себе копируемый образец работает идеально. Если
его копировать, окажется, что система не сможет быть эффективней своего
прародителя.
12
Правила применения метафор:
- опасно полностью копировать метафору, достаточно взять из неё самое
лучшее;
iBooks от Apple – отличный пример подобной ошибки. В iBooks был
использован дизайн, имитирующий книжный шкаф, вплоть до 3D полок и текстур под
дерево. Метафора книжного шкафа была призвана помочь пользователям перенести
то, что они знают о книжных шкафах в реальности (место для хранения и
упорядочивания материальных носителей информации), на реалии виртуальной среды.
Полки и оформление под дерево не имели никакого отношения к функционалу
приложения, они использовались, чтобы сделать метафору очевиднее. Позже
компания Apple отказалась от этого дизайна интерфейса.
В iBooks от Apple применялся знакомый и ясный для всех образ книжного шкафа, чтобы
дать пользователю понять, что он видит перед собой, и помочь установить эмоциональную
связь.
- следует остерегаться фотографической похожести среды в компьютере с
выбранным аналогом.
- эффективнее всего метафорически объяснять значение отдельных объектов;
- если метафора хоть как-то ограничивает систему, от неё необходимо
немедленно отказаться.
- следует избегать примитивных, буквальных метафор
Подобрать хорошую метафору для дизайна очень сложно. Всегда есть риск, что
вы сделаете неверный выбор и все пойдет кувырком. Как мы все знаем по опыту,
плохая метафора может сбить с толку. Один из таких примеров — Скрепыш от
Microsoft. Он получил известность как одно из самых неудачных решений для
интерфейса, когда-либо предложенных широкой публике, и оказался в числе самых
непопулярных функций за всю историю франшизы.
13
Скрепыш от Microsoft — надоедливая анимированная
скрепка, которая появлялась в углу экрана и
отвлекала пользователей от рабочего процесса.
Недостатки
− графический интерфейс использует больше потребление памяти по
сравнению с текстовым интерфейсом;
− сравнительная сложность организации удаленной работы;
− невозможна автоматизация работы при условии, если она не была заложена
разработчиком программы;
− к графическому интерфейсу трудно привыкнуть пользователям, которые
работали с интерфейсом командной строки.
15
Переключатель – значок в виде черного кружка в круглом окошке,
установленный слева от команды. Включение/отключение, как и у выключателя,
происходит щелчком мыши, но в отличие от выключателя, может быть включен
только у одной команды из
списка.
Окно приложения.
Приложениями принято называть
прикладные программы. Каждое
приложение имеет главное окно. В
ходе работы с приложением могут
открываться дополнительные
подчиненные окна.
Окно документа не может
существовать самостоятельно, оно
управляется каким-либо
приложением. Такие окна
называются дочерними. Они
размещаются только внутри
главного окна приложения и
исчезают при закрытии главного окна.
5) Пользовательский Web-интерфейс
Базовый WUI-стиль (англ. Web user interface, WUI) весьма схож с меню
иерархической структуры, которые пользователи знают по опыту работы в средах с
неграфическим интерфейсом за исключением более наглядного представления и
использования гиперссылок. Необходимая навигация выполняется в рамках одного
или нескольких приложений с использованием текстовых или визуальных
гиперссылок. Основные особенности приложения, использующего WUI-стиль:
- информация обычно отображается в единственном окне, называемом
браузером, хотя для представления данных в приложении могут использоваться
несколько окон браузеров;
- браузер обеспечивает меню для Web-приложения;
- выбор действий ограничен, так как меню, обеспечивающее обращение к
функциям, не является легкодоступным для приложения;
- Web-страница обладает небольшой степенью внутреннего контроля над
клиентской областью для открытия специализированных всплывающих меню;
- создание специализированных меню требует дополнительной работы по
программированию;
- клиентская область не содержит традиционных пиктограмм;
- многие приложения используют графику и анимацию в эстетических или
навигационных целях. Это таит в себе потенциальную угрозу возникновения внешнего
визуального шума и увеличения времен отклика при загрузке и раскрытии
графических файлов;
- браузер и приложения обеспечивают возможности отключения графики,
содержащейся в Web-страницах, так что на экране отображается только их текстовая
версия;
- поддержка указателя осуществляется в основном для выбора с помощью
одного щелчка мышью или выбора по навигационным ссылкам. Технология "drag and
drop" ("перетащить и поместить") не поддерживается за исключением случаев
специального программирования в определенных средах.
17
приложения к другой в пределах одного и того же Web-узла приложения выполняется
с использованием гиперссылок, схемы Web-узла, кнопок и навигационной панели.
Основное назначение Web-страницы заключается в обеспечении полезной
информацией, включая навигационную структуру в организацию Web-узла. Web-
страницы составлены из одной или нескольких конструкций, представляющих собой
сочетание бесчисленных мозаик цветных графических элементов. По сравнению с
GUI-ориентированными приложениями WUI-ориентированные приложения включают
несчетное количество элементов поведения, которые не вызываются пользователем,
например, анимационных.
Компоненты WUI-интерфейса. К наиболее распространенным компонентам
WUI-интерфейса относятся баннеры (заголовки), навигационные панели и визуальные
или текстовые гиперссылки, упорядоченные различными способами. Также
применяются разнообразные подходы к использованию графики, анимации и цвета.
18
Недостатком подобного типа интерфейса является ограниченность
изобразительных средств по причине ограниченности количества символов,
включённых в состав шрифта, предоставляемого аппаратурой.
Программы с текстовым интерфейсом могут имитировать оконный интерфейс,
чему особенно способствует применение псевдографических символов.
В текстовом интерфейсе реализованы все базовые элементы интерфейса,
используемые и в графическом интерфейсе – меню, кнопки, переключатели, флажки,
выпадающие списки, полосы прокрутки и так далее.
19
Лекция 14
Проектирование графического пользовательского интерфейса (ч.2)
Этапы разработки
Полный цикл разработки интерфейса включает следующие этапы:
− Исследование
− Пользовательские сценарии
− Структура интерфейса
− Прототипирование интерфейса
− Определение стилистики
− Дизайн концепция
− Оформление всех экранов
− Анимация интерфейса
− Подготовка материалов для разработчиков
Этап 1. Исследование
На этапе исследования проводится сбор информации о продукте, клиенте, его
конкурентах или близких аналогах, сбор статистики использования текущего
интерфейса, анализ устройств предполагаемой целевой аудитории.
Этот этап помогает понять для кого разрабатывается интерфейс, с какими
ограничениями следует его делать (размеры экранов, интерактивность), как не стоит
делать (например, быть непохожими на конкурентов).
1
2
Черновой прототип представляет собой схематичные изображения экранов,
связанные между собой. При черновом варианте на схемах изображены зоны и
описания этих зон. Например, список новостей или шапка сайта. Все без деталей.
Черновой прототип помогает более наглядно понять на сколько объемным будет
проект, как много информации будет на каждом экране, как много нужно кликать,
чтобы добраться до нужного места.
Следующим шагом идет финальный прототип, где уже есть все кнопки, тексты,
чекбоксы, формы и прочие элементы.
В прототипах планируется функционал, расположение элементов относительно
друг друга, но никак не оформление.
3
В результате этого этапа появляются видеоролики, показывающие анимацию
интерфейса. Они нужны не только клиенту, но и разработчикам, которые будут
ориентироваться на эти ролики.
5
Специалисты по удобству использования обычно формулируют некоторый
набор принципов и правил, позволяющих как оценивать удобство интерфейса, так и
предлагать решения, повышающие его удобство:
Правило доступности.
Система должна быть настолько понятной, чтобы пользователь, никогда раньше
не видевший ее, но хорошо разбирающийся в предметной области, мог без всякого
обучения начать ее использовать.
Это правило служит некоторым идеалом, к которому надо стремиться,
поскольку на практике достичь такой степени понятности почти никогда не удается.
Тем не менее, все, что можно сделать для достижения этого идеала, делать нужно.
Правило эффективности.
Система не должна препятствовать эффективной работе опытных пользователей,
работающих с ней долгое время.
Очевидным примером нарушения этого правила является нацеленность системы
только на новичков, например, выполнение почти всех операций с помощью мастеров
(wizards), которые хорошо подходят для неопытного пользователя, ограничивая его в
возможности сделать что-то не так, но неэффективны для эксперта, который и так
знает, что и где ему нужно сделать.
Правило непрерывного развития.
Система должна способствовать непрерывному росту знаний, умений и навыков
пользователя и приспосабливаться к его меняющемуся опыту.
Плохие результаты приносит предоставление только базовых возможностей или
оставление начинающего пользователя наедине со сложным интерфейсом, которым
уверенно пользуются эксперты. Нарушение непрерывности при переходе от одного
набора возможностей к другому также приносит неудобства, поскольку пользователь
вынужден разбираться с добавленными возможностями в новом контексте.
Большинство пользователей можно поместить в три группы: новичков, опытных
и средних, которые уже знают больше, чем новички, и не делают столько ошибок, но
еще не приобрели автоматизма при выполнении большинства операций и иногда
путаются в интерфейсе. Новичкам необходима помощь в освоении новой для них
системы и контроль их действий, опытным пользователям — высокая эффективность
выполнения часто требующихся действий и возможность гибкого управления
системой в таких ситуациях, которые встречаются реже, но способны вызвать
проблемы при их неадекватной поддержке. Про средних же пользователей часто
забывают, хотя подавляющее большинство пользователей ПО относится к этой
категории. Им нужны достаточно высокие эффективность и гибкость вместе с
возможностью быстро получать адекватную помощь по возникающим время от
времени разнообразным вопросам.
Правило поддержки.
Система должна способствовать более простому и быстрому решению задач
пользователя.
Это означает, прежде всего, что система должна действительно решать задачи
пользователя. Кроме того, она должна решать их лучше, проще и быстрее, чем
имевшиеся до ее появления инструменты и методы.
Правило соблюдения контекста.
Система должна быть согласована с контекстом, в котором ей предстоит
работать.
6
Это правило требует от системы быть работоспособной не "вообще", а именно в
том окружении, в котором ею будут пользоваться. В контекст могут входить
специфика и объемы входных и выходных данных, тип и цели организаций, в которых
система должна работать, уровень пользователей, зашумленность помещений и пр.
Представленные выше правила определяют общие требования, которым должен
удовлетворять удобный интерфейс. Кроме них, при разработке ПО необходимы
некоторые подсказки, позволяющие сделать его более удобным.
7
опытных пользователей, поэтому позже были разработаны более упрощенные способы
ввода данных. Все эти виды взаимодействия можно отнести к одному из пяти
основных стилей взаимодействия.
1. Непосредственное манипулирование.
Пользователь взаимодействует с объектами на экране. Например, для удаления
файла пользователь просто перетаскивает его в корзину.
2. Выбор из меню. Пользователь выбирает команду из списка пунктов меню.
Очень часто выбранная команда воздействует только на тот объект, который выделен
(выбран) на экране. При таком подходе для удаления файла пользователь сначала
выбирает файл, а затем команду на удаление.
3. Заполнение форм. Пользователь заполняет поля экранной формы. Некоторые
поля могут иметь свое меню (выпадающее меню или списки). В форме могут быть
командные кнопки, при щелчке мышью на которых инициируют некоторое действие.
Чтобы удалить файл с помощью интерфейса, основанного на форме, надо ввести в
поле формы имя файла и затем щелкнуть на кнопке удаления, присутствующей в
форме.
4. Командный язык. Пользователь вводит конкретную команду с параметрами,
чтобы указать системе, что она должна дальше делать. Чтобы удалить файл,
пользователь вводит команду удаления с именем файла в качестве параметра этой
команды.
5. Естественный язык. Пользователь вводит команду на естественном языке.
Чтобы удалить файл, пользователь может ввести команду "удалить файл с именем
XXX".
Юзабилити
Крупные компании ПО тратят уйму денег на юзабилити. Юзабилити — это
степень эффективности, продуктивности и удовлетворенности, с которыми продукт
может быть использован определенными пользователями в определенном контексте
использования для достижения определенных целей.
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)
1
Качество продукта − качество основного производимого продукта
(программного обеспечения или системы) и всех его составляющих (например,
компонентов, подсистем, архитектуры и т. д.).
Качество процесса
Насколько был реализован желаемый процесс (в том числе системы мер и
критерии качества) и насколько его придерживались во время производства продукта.
Кроме того, на качество процесса влияет и качество артефактов (таких, как планы
итераций, планы тестирования, реализации прецедентов, модель проектирования и
т.д.), создаваемых для поддержки основного продукта.
Модель Маккола
Эта модель классифицирует все требования к программному обеспечению по 11
показателям качества программного обеспечения. Эти 11 факторов сгруппированы в
три категории:
эксплуатация продукта,
пересмотр продукта
факторы перехода продукта.
правильность
Эти требования касаются правильности вывода программного обеспечения
системы:
− Выходная миссия
− Требуемая точность вывода, на которую могут отрицательно повлиять
неточные данные или неточные расчеты.
− Полнота выводимой информации, на которую могут повлиять неполные
данные.
− Актуальность информации, определяемой как время между событием и
ответом системы программного обеспечения.
− Доступность информации.
− Стандарты кодирования и документирования программного обеспечения
системы.
надежность
Требования к надежности связаны с отказом обслуживания. Они определяют
максимально допустимую частоту отказов программной системы и могут относиться
ко всей системе или к одной или нескольким ее отдельным функциям.
Эффективность (КПД)
Он касается аппаратных ресурсов, необходимых для выполнения различных
функций системы программного обеспечения. Он включает в себя возможности
обработки (в МГц), емкость хранения (в МБ или ГБ) и возможность передачи данных
(в МБПС или ГБПС).
Он также касается времени между подзарядкой портативных блоков системы,
таких как блоки информационной системы, расположенные в портативных
компьютерах, или метеорологические блоки, размещенные на открытом воздухе.
целостность
Этот фактор связан с безопасностью системы программного обеспечения, то есть
для предотвращения доступа посторонних лиц, а также для разграничения группы
людей, которым даются разрешения на чтение и запись.
Юзабилити
Требования юзабилити связаны с кадровыми ресурсами, необходимыми для
обучения нового сотрудника и эксплуатации системы программного обеспечения.
3
Согласно модели Маккола, три категории качества программного
обеспечения включены в категорию редакции продукта. Эти факторы заключаются
в следующем:
Ремонтопригодность
Этот фактор учитывает усилия, которые потребуются пользователям и
обслуживающему персоналу для определения причин сбоев программного
обеспечения, исправления сбоев и проверки успешности исправлений.
гибкость
Этот фактор связан с возможностями и усилиями, необходимыми для поддержки
адаптивного обслуживания программного обеспечения. Это включает в себя
адаптацию текущего программного обеспечения к дополнительным обстоятельствам и
клиентам без изменения программного обеспечения. Требования этого фактора также
поддерживают совершенные действия по обслуживанию, такие как изменения и
дополнения программного обеспечения, чтобы улучшить его обслуживание и
адаптировать его к изменениям в технической или коммерческой среде фирмы.
Тестируемость
Требования к тестируемости относятся как к тестированию программной
системы, так и к ее работе. Он включает предварительно определенные
промежуточные результаты, файлы журнала, а также автоматическую диагностику,
выполняемую программной системой перед запуском системы, чтобы выяснить, все ли
компоненты системы находятся в рабочем состоянии, и получить отчет об
обнаруженных неисправностях. Другой тип этих требований касается автоматических
диагностических проверок, применяемых специалистами по техническому
обслуживанию для выявления причин сбоев программного обеспечения.
Переносимость (портативность)
Требования переносимости имеют тенденцию к адаптации программной
системы к другим средам, состоящим из другого оборудования, разных операционных
систем и так далее. Программное обеспечение должно иметь возможность продолжать
использовать одно и то же базовое программное обеспечение в различных ситуациях.
Повторное использование
Этот фактор связан с использованием программных модулей, изначально
разработанных для одного проекта, в новом программном проекте, который
разрабатывается в настоящее время. Они могут также позволить будущим проектам
использовать данный модуль или группу модулей разработанного в настоящее время
программного обеспечения. Ожидается, что повторное использование программного
обеспечения позволит сэкономить ресурсы разработки, сократить период разработки и
обеспечить более качественные модули.
4
Совместимость
Требования к функциональной совместимости направлены на создание
интерфейсов с другими программными системами или с другими аппаратными
средствами оборудования. Например, встроенное программное обеспечение
производственного оборудования и испытательного оборудования взаимодействует с
программным обеспечением управления производством.
Проблемы разработки ПО
В современных условиях вопрос качества поставляемого на рынок
программного обеспечения становится все более актуальным — с ростом количества
компаний-разработчиков, а также независимых коллективов программистов, готовых
предоставить потребителям готовый продукт, заинтересованность в скорейшем выводе
в продажу коммерческого решения возрастает. Часто в погоне за прибылью ключевые
проблемы разработки ПО уходят на второй план — сроки одерживают верх в борьбе
за высокое качество программных решений.
Основные факторы, оказывающие негативное влияние на качественные
показатели выпускаемых на рынок программ:
Достаточно крупные коллективы разработчиков, планируя создание нового
программного обеспечения, как правило, совершают первую ошибку уже на этапе
формирования технического задания. Вопреки отработанной технологии разработки
качественного ПО, заказчики не редко ограничивают сроки реализации проекта,
вынуждая команду разработчиков исключать из перечня задач процесс отладки
написанного программистами кода. Вместо оптимизации каждого компонента
программного продукта, задача по «вылавливанию багов» возлагается на
тестировщиков, берущихся за работу на самом последнем этапе разработки ПО, когда
все модули программы уже собраны воедино.
Чуть менее значимой ошибкой, ведущей к появлению проблем при разработке
программного обеспечения, является игнорирование весьма нужной процедуры
анализа формируемых заказчиком и исполнителем требований к будущей программе.
Нечеткое понимание целей, преследуемых заказчиком, а также несогласованность
бизнес-деталей, подлежащих реализации в продукте, ведет к сдаче низкокачественной
программы, имеющей существенное количество недоработок. Особенно остро эта
проблема стоит в сфере разработки мобильных приложений, где ключевым фактором
для заказчиков становится как можно более ранний вывод решения на рынок, чтобы
успеть заработать деньги от продажи программы потребителям.
Пути решения
Чтобы избежать упомянутых проблем при разработке программного
обеспечения, и заказчики, и исполнители, будь то крупная компания или небольшой
коллектив программистов, должны придерживаться методики обеспечения качества
ПО, состоящей всего из нескольких пунктов.
1. Анализ требований
Еще на этапе формирования технического задания на разработку ПО требуется
согласовать ключевые вопросы, связанные с механикой работы и составом ключевых
компонентов программы. Также стороны должны прийти ко взаимному пониманию в
вопросе функциональности создаваемого программного продукта, что позволит
добиться принятия работы сразу после демонстрации рабочего образца программы.
5
2. Анализ и сквозной контроль кода
Контроль работоспособности программного кода, наличие ошибок и
корректность их обработки, должны осуществляться постоянно, в течение всего
процесса разработки ПО. Перекладывать необходимость поиска проблемных участков
кода на плечи тестировщиков, занимающихся проверкой выполнения основных
функций ПО уже после выполнения основных этапов разработки, категорически
нельзя.
3. Сессионное тестирование
Методика сессионного тестирования, предложенная одним из ведущих
специалистов в области программирования Джеймсом Бахом, позволяет осуществлять
качественную проверку работоспособности созданного решения. В отличие от
технологии поиска «точечных» недоработок кода, при сессионном тестировании
тестировщик получает свободу действий, пытаясь выявить необычные дефекты,
фактически моделируя поведение предполагаемого пользователя.
6
ПО и оценке полученных результатов, а также вызывать положительные эмоции
определенного или подразумеваемого пользователя.
Эффективность − это отношение уровня услуг, предоставляемых ПО
пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость − это характеристики ПО, которые позволяют
минимизировать усилия по внесению изменений для устранения в нем ошибок и по
его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность − это способность ПО быть перенесенным из одной среды
(окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надежность являются обязательными критериями качества
ПО, причем обеспечение надежности должно красной нитью проходить по всем
этапам и процессам разработки ПО. Остальные критерии используются в зависимости
от потребностей пользователей в соответствии с требованиями к ПО. Для
конкретизации качества ПО по каждому из критериев используется
стандартизованный набор достаточно простых свойств, однозначно интерпретируемых
разработчиками. Такие свойства называются примитивами качества ПО. Некоторые
из примитивов могут использоваться по нескольким критериям. Ниже приводится
зависимость критериев качества от примитивов качества ПО.
Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость,
защищенность.
Легкость применения: П-документированность, информативность (только
применительно к документации по применению), коммуникабельность, устойчивость,
защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам (по
памяти), эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных примитивов
качества. Однако их можно распределить по двум группам, выделив два подкритерия
качества: изучаемость и модифицируемость. (Изучаемость − это характеристики ПО,
которые позволяют минимизировать усилия по изучению и пониманию программ и
документации ПО. Модифицируемость − это характеристики ПО, которые позволяют
автоматически настраивать на условия применения ПО или упрощают внесение в него
вручную необходимых изменений и доработок).
Изучаемость: С-документированность, информативность (здесь
применительно к документации по сопровождению), понятность,
структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком
смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность,
модульность.
Ниже даются определения используемых примитивов качества ПО.
Завершенность (completeness) − свойство, характеризующее степень обладания
ПО всеми необходимыми частями и чертами, требующимися для выполнения своих
явных и неявных функций.
Точность (accuracy) − мера, характеризующая приемлемость величины
погрешности в выдаваемых программами ПО результатах с точки зрения
предполагаемого их использования.
7
Автономность (self-containedness) − свойство, характеризующее способность
ПО выполнять предписанные функции без помощи или поддержки других компонент
программного обеспечения.
Устойчивость (robustness) − свойство, характеризующее способность ПО
продолжать корректное функционирование, несмотря на неправильные (ошибочные)
входные данные.
Защищенность (defensiveness) − свойство, характеризующее способность ПО
противостоять преднамеренным или нечаянным деструктивным (разрушающим)
действиям пользователя.
П-документированность (u. documentation) − свойство, характеризующее
наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и
справочной документации, необходимой для применения ПО.
Информативность (accountability) − свойство, характеризующее наличие в
составе ПО информации, необходимой и достаточной для понимания назначения ПО,
принятых предположений, существующих ограничений, входных данных и
результатов работы отдельных компонент, а также текущего состояния программ в
процессе их функционирования.
Коммуникабельность (communicativeness) − свойство, характеризующее степень,
в которой ПО облегчает задание или описание входных данных, и способность
выдавать полезные сведения в достаточно простой форме и с простым для понимания
содержанием.
Временнáя эффективность (time efficiency) − мера, характеризующая
способность ПО выполнять возложенные на него функции в течение определенного
отрезка времени.
Эффективность по ресурсам (resource efficiency) − мера, характеризующая
способность ПО выполнять возложенные на него функции при определенных
ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency) − мера, характеризующая
экономичность использования устройств машины для решения поставленной задачи.
С-документированность (documentation) − свойство, которое характеризуют
написание документации, отражающей требования к ПО и результаты различных
этапов разработки данной ПО, включающие возможности, ограничения и другие
черты ПО, а также их обоснование.
Понятность (understandability) − свойство, характеризующее степень, в которой
ПО позволяет изучающему его лицу понять его назначение, сделанные допущения и
ограничения, входные данные и результаты работы его программ, тексты этих
программ и состояние их реализации.
Структурированность (structuredness) − свойство, характеризующее программы
ПО с точки зрения организации взаимосвязанных их частей в единое целое
определенным образом (например, в соответствии с принципами структурного
программирования).
Удобочитаемость (readability) − свойство, характеризующее легкость
восприятия текста программ ПО (отступы, фрагментация, форматированность).
Расширяемость (augmentability) − свойство, характеризующее способность ПО к
использованию большего объема памяти для хранения данных или расширению
функциональных возможностей отдельных компонент.
8
Модифицируемость (modifiability) − мера, характеризующая ПО с точки зрения
простоты внесения необходимых изменений и доработок на всех этапах и стадиях
жизненного цикла ПО.
Модульность (modularity) − свойство, характеризующее ПО с точки зрения
организации его программ из таких дискретных компонент, что изменение одной из
них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств (device independence) − свойство,
характеризующее способность ПО работать на разнообразном аппаратном
обеспечении (различных типах, марках, моделях ЭВМ).
Разработка программного средства завершается его аттестацией. Аттестация
программного средства − это авторитетное подтверждение его качества. Как правило,
для аттестации создается комиссия экспертов. Эта комиссия проводит приемо-
сдаточные испытания программного средства с целью получения необходимой
информации для оценки его качества. При этом оцениваются только установленные
критерии качества и примитивы качества.
9
время, необходимое для запуска системы. Именно эти показатели соотносятся с
эффективностью системы. Таким же образом можно регистрировать количество
системных ошибок и их типы, что напрямую связано с надежностью системы.
Статические показатели, как правило, имеют отдаленное отношение к
качественным характеристикам ПО. Было предложено достаточное количество таких
показателей, с которыми был проведен ряд экспериментов для выявления и оценки
возможных взаимосвязей между этими показателями и такими свойствами, как
сложность, понятность и удобство эксплуатации системы.
В таблице приведено несколько статических показателей, которые могут
использоваться при оценке качества. Среди них объем программного кода и
сложность управления являются наиболее надежными показателями для
прогнозирования сложности, понятности и удобства сопровождения программного
продукта.
Показатели Описание
Нагрузочный множитель Нагрузочный множитель по входу пропорционален
по входу и нагрузочный количеству функций, которые вызывают другую функцию
множитель по выходу (назовем ее X). Нагрузочный множитель по выходу
пропорционален количеству функций, которые
вызываются функцией X. Высокие значения для
множителя по входу означают, что функция X тесно
связана с остальными компонентами системы и изменения
в этой функции могут привести к существенным
изменениям во всей системе. Высокое значение
множителя по выходу означает высокую сложность самой
функции X, которая вытекает из сложности логической
схемы управления вызываемых ею компонентов
Объем программного кода Этот показатель определяет размер программы. В общем
случае, чем больше объем кода программного
компонента, тем более сложным и подверженным
ошибкам будет сам компонент
Цикломатическая Это мера сложности логической структуры программы. В
сложность свою очередь, сложность структуры программы связана с
таким показателем, как понятность программного кода.
Длина идентификаторов Этот показатель измеряется как среднее длин
идентификаторов в программе. Чем длиннее
идентификаторы, тем понятнее, что они означают, а
следовательно, более понятна и сама программа
Глубина вложения Здесь измеряется глубина вложений условных операторов
условных операторов в программе. Большая глубина вложения условных
операторов затрудняет чтение программы, что ставит ее в
разряд потенциально ошибочных программ
Индекс непонятности Измеряется как среднее длин слов и предложений в
документах. Чем выше показатель индекса непонятности,
тем труднее понять документ
11
Верифицировать можно и реальное поведение системы — сопоставляя его с
требованиями, проектными решениями, принятыми стандартами функционирования
систем такого рода.
Валидация обозначает проверку некоторого артефакта разработки на
соответствие конечным целям, для достижения которых это ПО предназначено, т.е.,
нуждам и потребностям его пользователей и заказчиков. При валидации ПО
проверяется, что оно действительно решает нужные пользователям задачи и
удовлетворяет их потребности (даже если эти задачи и потребности описаны плохо и
неполно).
Валидация обычно проводится представителями заказчика, пользователями,
экспертами в предметной области, т.е. людьми, обладающими достаточной
компетентностью, чтобы судить о достижении поставленных целей. Если же эти цели
формализовать, описать точно и полно, то проверка на соответствие полученному
документу будет верификацией.
Валидация необходима, потому что обычно согласованное, полное и точное
описание задач сложной системы практически невозможно, разрабатываемые
документы со спецификациями требований и пр. являются только приближениями к
такому описанию.
При валидации, могут использоваться те же техники, что и при выявления
требований, поскольку цели этих видов деятельности похожи — преобразовать
неясные и неформальные пожелания и представления о работе ПО в более точную
форму (при валидации — в оценку проверяемых характеристик качества).
Методы верификации существенно строже, они чаще могут быть
формализованы и автоматизированы.
12
или внешних систем производится их эмуляция). При этом собирается информация о
результатах работы в различных ситуациях, и эта информация далее подвергается
анализу на предмет соответствия требованиям или проектным решениям. Обычно к
таким методам относят
− тестирование, при котором работа ПО проверяется на заранее выбранном
наборе ситуаций;
− мониторинг, в рамках которого работа ПО протоколируется и оценивается
при его обычной или пробной эксплуатации;
− профилирование − специфический вид мониторинга временных
характеристики работы ПО и использования им отдельных ресурсов.
К динамическим методам анализа относят также и имитационное тестирование,
и имитационный мониторинг, при которых ПО выполняется в рамках какого-то
модельного окружения, построенного с использованием симуляторов и эмуляторов.
13
Стандартизация в области оценки качества программного обеспечения
Стандарты ISO 9000
Стандарты ISO 9000 приняты более чем 90 странами мира (в том числе и в РБ) и
применимы к любым предприятиям, независимо от их размера и сферы деятельности.
Стандарты серии ISO 9000 регламентируют осуществление двух основных видов
деятельности:
− Формирование на предприятии системы управления качеством;
− Разработка руководств по качеству, которые содержит детальное описание
процедур управления качеством на предприятии.
Система управления качеством нужна как самому предприятию, так и его
потребителям, и поставщикам:
− потребителям наличие системы управления качеством гарантирует высокий
уровень качества покупаемой продукции и предоставляемых услуг;
− поставщикам ее наличие гарантирует четкие и своевременные требования
производителя к поставляемым материалам, а также перспективы долгосрочного
сотрудничества;
− предприятию система управления качеством позволяет более эффективно
организовать управление функциональными процессами.
Структура ISO 9000
Серия стандартов ISO 9000 содержит требования и способы реализации системы
управления качеством и обеспечения качества и включает пять стандартов:
ISO 9000 – руководство по выбору и использованию имеющихся стандартов
ISO 9001 – спецификации по конструированию, производству, установке и
сервисному обслуживанию
ISO 9002 – спецификации по производству, установке и сервисному
обслуживанию
ISO 9003 – спецификации по инспектированию и проверке продукции
ISO 9004 – описание основных понятий и приложений, используемых в полной
системе управления качеством
14
Стандарт ISO 9000-3 включает в себя все положения общего стандарта ISO 9001,
а также необходимые дополнения к ним, относящиеся к разработке, поставке и
обслуживанию ПО.
ISO 9001 устанавливает требования к системе качества поставщика и позволяет
оценивать его возможности по проектированию и поставке продукции,
соответствующей этим требованиям. Требования стандарта направлены в первую
очередь на то, чтобы удовлетворить запросы пользователя, предупредив появление
каких-либо несоответствий продукции на всех стадиях ее жизненного цикла − от
проектирования до обслуживания.
15
Руководство определяет и документально оформляет ответственность,
полномочия и механизмы взаимодействия персонала, который выполняет и проверяет
работу, влияющую на качество.
Руководство назначает менеджера по качеству с определенными полномочиями
для обеспечения разработки, внедрения и поддержки в рабочем состоянии системы
качества и представления отчетов о ее функционировании, которые позволят
анализировать и совершенствовать систему качества.
Система качества
Компания-поставщик должна разработать, документально оформить и
поддерживать в рабочем состоянии систему качества как средство, обеспечивающее
соответствие продукции требованиям данного стандарта. Система качества
подразумевает наличие инструкции по качеству, включающей методики системы
качества компании и описание структуры документации, используемой в системе
качества. Масштаб и степень подробности методик системы качества должны зависеть
от сложности работы, используемых методов, необходимых навыков и подготовки
персонала.
Поставщик также определяет и документально оформляет действия по
реализации требований к качеству, т.е. выполняет планирование качества,
включающее формулировку требований к качеству, описание модели жизненного
цикла, задание критериев начала и конца каждого этапа проекта, определение типов
анализа, тестирования и других действий по проверке и утверждению программного
продукта, определение процедур управления конфигурацией. Планирование качества
позволяет "настроить" систему качества на определенный проект.
Анализ контракта
Система качества предусматривает определенные действия по анализу
контракта. Программный продукт может разрабатываться по контракту с заказчиком,
как коммерческий продукт для определенного сектора рынка, как система, встроенная
в аппаратное обеспечение, или как система поддержки бизнес-процессов поставщика.
Общие положения анализа контрактов, определенные в ISO 9000-3, применимы ко
всем этим ситуациям.
Поставщик должен проанализировать заявку на тендер, контракт или заказ до
подачи заявки или заключения контракта. Это позволит гарантировать адекватное
определение требований к проекту и возможность выполнить контракт.
При анализе контрактов на ПО могут учитываться различные моменты
взаимодействия с заказчиком, технические соображения, аспекты управления и
факторы обеспечения защиты и конфиденциальности. Например, могут
анализироваться оговоренные с заказчиком критерии принятия или отказа от готовой
системы, терминология, степень участия заказчика в совместной работе,
ответственность заказчика по предоставлению определенных данных или
оборудования, обязательства заказчика перед поставщиком по замене на новые версии
системы или обязательства поставщика поддерживать старые версии и т.д. Здесь же
могут рассматриваться стандарты и процедуры, которые будут использоваться при
разработке программной системы, операционная и аппаратная платформа, требования
к репликации и распределению системы, требования к установке, сопровождению и
поддержке системы и ряд других.
16
Управление проектированием
Это самый обширный раздел стандарта, поскольку он затрагивает базовую
составляющую общего процесса создания продукта, программного продукта в
частности, решающим образом влияющую на его качество.
Поставщик устанавливает и документирует методики управления и верификации
проекта с целью обеспечения выполнения установленных требований. Этот раздел
стандарта ISO 9000-3 дает руководящие указания по основным действиям в процессе
разработки, таким как анализ требований к проекту, проектирование архитектуры
системы, детальное проектирование и кодирование, а также планирование разработки.
Проект разработки программного продукта организуется в соответствии с
определенной моделью жизненного цикла. ISO 9000-3 не определяет, какой должна
быть модель жизненного цикла, это зависит от специфики решаемой задачи. Стандарт
дает лишь общее определение модели жизненного цикла как множества процессов.
Модель показывает, когда и как эти процессы подключаются к реализации проекта.
Разработка системы − это процесс преобразования исходных требований в
конечный программный продукт. Стандарт оговаривает, что этот процесс должен
проводиться в строго определенном порядке. Это позволит предотвратить появление
ошибок и снизит зависимость от процессов проверки и утверждения как единственных
методов определения проблемных ситуаций. Требование строгой дисциплины
процесса разработки подразумевает наличие и поддержку в рабочем состоянии
документированных процедур, которые послужат гарантией того, что программный
продукт создается в соответствии с заданными требованиями и планами разработки и
обеспечения качества.
Управление проектом должно учитывать такие аспекты, как используемый
метод проектирования и его соответствие конкретной задаче, опыт предыдущих
проектов, требования последующих процессов: тестирования, установки,
сопровождения и использования, наконец, соображения защиты и безопасности. В тех
случаях, когда сбои системы могут нанести ущерб людям, собственности или
окружающей среде, при проектировании должно быть сформулированы специальные
требования, гарантирующие устойчивость системы или ее ответные действия на
потенциальные аварийные ситуации.
Для процессов кодирования должны задаваться правила использования языков
программирования, принципы кодирования и правила составления адекватных
комментариев.
Инструментальные средства и методы, используемые в разработке
программного продукта, такие, например, как системы анализа и проектирования и
компиляторы, должны заранее утверждаться и контролироваться системой
конфигурационного управления. Область применения инструментария должна быть
задокументирована, а его использование периодически анализироваться, дабы выявить
необходимость усовершенствования инструментальных систем или замены на новые
продукты.
Проектирование и разработка должны тщательно планироваться. План
разработки программного продукта формулирует строго документированные действия
по анализу требований к системе, проектированию, кодированию, интеграции,
тестированию, установке и поддержке системы. План разработки должен быть
проанализирован и утвержден.
17
План разработки включает также связанные с основным процессом планы
обеспечения качества, управления рисками и конфигурацией, планы интеграции,
тестирования, установки, обучения сотрудников и др.
Должны быть определены и задокументированы принципы организационно-
технического взаимодействия между различными группами, участвующими в
разработке. Здесь четко определяются границы ответственности каждого участника
разработки и то, каким образом техническая информация будет передаваться между
участниками. Здесь же оговаривается ответственность заказчика проекта, если он
принимает участие в разработке: необходимость участвовать в проекте, обязательства
по своевременному предоставлению нужной информации. В случае обоюдной
договоренности между поставщиком и заказчиком может быть запланирован
совместный анализ ведения проекта, регулярно или на определенных его этапах. Этот
анализ затрагивает такие факторы, как ход разработки со стороны поставщика, участие
в разработке со стороны заказчика, соответствие системы требованиям заказчика,
результаты проверок, результаты тестирования.
Входные проектные требования к продукции. Требования формулирует
заказчик, а поставщик анализирует, насколько они адекватны. Неполные,
двусмысленные или противоречивые требования являются предметом урегулирования
с лицами, ответственными за их предъявление.
Выходные проектные данные также оформляются документально, причем таким
образом, чтобы их можно было проверить и подтвердить относительно входных
проектных требований. Выходные данные проекта программной системы могут
включать: спецификацию архитектуры проекта, детальную спецификацию проекта,
исходные коды, руководство пользователя.
Поставщик программного продукта должен планировать и проводить
официальный, документально оформленный анализ результатов проектирования.
Анализ проектирования затрагивает такие аспекты, как выполнимость проекта,
удовлетворение требованиям защиты и безопасности системы, выполнение правил
программирования и возможность тестирования.
На определенных стадиях проектирования проводится проверка соответствия
выходных данных входным требованиям. Такая верификация проекта может включать
анализ выходных данных, демонстрации, в том числе с помощью прототипов и
моделирования, или тестирование. Только проверенные выходные проектные данные
утверждаются для окончательного приема и последующего использования. Все
обнаруженные в процессе проверки проблемные ситуации должны адекватно
разрешаться.
Прежде чем система будет передана заказчику, поставщик должен утвердить
систему на соответствие заданному назначению. Заказчику может быть передан только
утвержденный программный продукт.
Все изменения и модификации проекта должны быть идентифицированы,
документально оформлены, проанализированы и утверждены до их реализации.
Поставщик устанавливает и поддерживает в рабочем состоянии процедуры
управления изменениями в проекте, которые могут возникнуть на любой стадии
жизненного цикла системы.
18
Управление документацией и данными
Поставщик должен разработать и поддерживать в рабочем состоянии
документированные процедуры управления всеми спецификациями и данными,
относящимися к требованиям стандарта ISO 9001, включая и документы внешнего
происхождения (стандарты и чертежи потребителя). Документы и данные могут
размещаться на любом бумажном или электронном носителе.
Для реализации контроля за документами и данными могут использоваться
процедуры управления конфигурацией. В область действия этого раздела стандарта
попадают контракты, специфицирующие требования к продукту; документы,
описывающие систему качества, содержащие различные планы поставщика и
взаимодействие поставщика с потребителем; документы и данные, описывающие
конкретный программный продукт.
Закупки
Поставщику вменяется в обязанность разработать и поддерживать в рабочем
состоянии документированные процедуры, гарантирующие соответствие закупленной
продукции установленным требованиям. При разработке, поставке, инсталляции и
сопровождении программных продуктов в качестве закупок может фигурировать:
коммерческое ПО; разработка по субконтракту; компьютерное и коммуникационное
аппаратное обеспечение; средства разработки; персонал, нанимаемый по контракту;
сервис поддержки и сопровождения; обучающие курсы и материалы.
19
Управление процессами
Поставщик должен определить и спланировать процессы разработки, установки
и обслуживания продукта. Процесс разработки программной системы организован как
множество процессов, преобразующих исходные требования в программный продукт
(см. раздел "Управление проектированием"). Раздел стандарта оговаривает требования
к репликации, доставке и инсталляции программных продуктов.
Контроль и испытания
Поставщик должен разработать и поддерживать в рабочем состоянии
документированные процедуры контроля и испытаний для проверки выполнения
установленных требований к продукции.
Контроль и испытания, проще говоря, тестирование программного продукта
может потребоваться на нескольких уровнях, от отдельных элементов ПО до
законченной системы. Существует несколько подходов к тестированию, которые
данным стандартом не обсуждаются. Выбор подхода зависит от поставщика. Объем
тестирования, степень контроля за средой испытаний, входные и выходные данные
тестов могут варьироваться в зависимости от выбранного подхода, сложности системы
и связанных с ней рисков.
Поставщик должен определить, задокументировать и периодически
анализировать план тестирования модулей, интеграционных процессов, системы в
целом и тестирования для окончательной приемки.
В процессе разработки поставщик должен контролировать и испытывать
продукцию в соответствии с программой качества. Все виды окончательного контроля
и тестирования также следует проводить в соответствии с этой программой, дабы
убедиться, что готовый продукт соответствует установленным требованиям. Для
производителя программных систем это означает, что прежде чем продукт будет
передан заказчику, поставщик должен официально подтвердить, что продукт работает
в соответствии с заданным назначением, в условиях, сходных с теми, в которых будет
применяться система. Любые различия между средой утверждения системы и
фактической средой ее использования, а также риск, связанный с этими различиями,
должны быть выявлены и зарегистрированы на возможно более ранних этапах
жизненного цикла.
Помимо тестирования для окончательного утверждения, тестирование может
провести заказчик при приемке уже утвержденного продукта. При этом он будет
определять, соответствует или нет продукт ранее согласованным критериям. Заказчик
может передать полномочия на проведение таких тестов поставщику или третьему
лицу. Поставщик и заказчик должны согласовать между собой методы решения
проблем, обнаруженных в ходе процедуры приемки.
20
изоляция аппаратного компонента, содержащего несоответствующий прикладной
элемент.
21
В том случае, если данные о качестве хранятся в электронном виде, при
определении времени сохранения и доступа к данным необходимо учитывать степень
возможной деградации электронных копий и доступность устройств и программных
компонентов для доступа к данным.
Подготовка кадров
Поставщик должен разработать и поддерживать в рабочем состоянии
документированные процедуры определения потребностей в подготовке кадров, а
также обеспечивать подготовку всего персонала, выполняющего работы, которые
влияют на качество. Персонал должен быть квалифицирован на основе
соответствующего образования, подготовки и опыта. Определение задач обучения
должно увязываться с теми инструментальными средствами, методами и
компьютерными ресурсами, которые будут использоваться в разработке программного
продукта и управлении им. Возможно, потребуется также специальное обучение в той
области, с которой связан разрабатываемый программный продукт.
Обслуживание
Что касается программного обеспечения, то обслуживание здесь понимается как
сопровождение системы (maintanance) и поддержка заказчиков (customer support).
Поддержка заказчиков обсуждается в стандарте ISO 9000-2.
Сопровождение системы, как правило, включает в себя обнаружение и анализ
несоответствий в программной системе, вызывающих сбои в ее работе; коррекцию
программных ошибок; модификацию интерфейсов, что необходимо в случае внесения
добавлений или изменений в аппаратуру; функциональное расширение или улучшение
производительности
Все действия по сопровождению должны проводиться и контролироваться в
соответствии с планом сопровождения, который заранее определяется и
согласовывается поставщиком и заказчиком.
22
стандарта. Исходя из принципиальных возможностей их измерения, все
характеристики могут быть объединены в три группы, к которым применимы разные
категории метрик:
− категорийным, или описательным (номинальным) метрикам наиболее
адекватны функциональные возможности программных средств;
− количественные метрики применимы для измерения надежности и
эффективности сложных комплексов программ;
− качественные метрики в наибольшей степени соответствуют практичности,
сопровождаемости и мобильности программных средств.
Функциональность (functionality)
Способность ПО в определенных условиях решать задачи, нужные
пользователям. Определяет, что именно делает ПО, какие задачи оно решает.
Функциональная пригодность (suitability). Способность решать нужный набор
задач.
Точность (accuracy). Способность выдавать нужные результаты.
Способность к взаимодействию (interoperability). Способность
взаимодействовать с нужным набором других систем.
Соответствие стандартам и правилам (compliance). Соответствие ПО
имеющимся индустриальным стандартам, нормативным и законодательным актам,
другим регулирующим нормам.
Защищенность (security). Способность предотвращать неавторизированный,
т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к
данным и программам.
23
Надежность (reliability).
Способность ПО поддерживать определенную работоспособность в заданных
условиях.
Зрелость, завершенность (maturity). Величина, обратная частоте отказов ПО.
Обычно измеряется средним временем работы без сбоев и величиной, обратной
вероятности возникновения отказа за данный период времени.
Устойчивость к отказам (fault tolerance). Способность поддерживать заданный
уровень работоспособности при отказах и нарушениях правил взаимодействия с
окружением.
Способность к восстановлению (recoverability). Способность восстанавливать
определенный уровень работоспособности и целостность данных после отказа,
необходимые для этого время и ресурсы.
Соответствие стандартам надежности (reliability compliance). Этот атрибут
добавлен в 2001 году.
24
Удобство сопровождения (maintainability).
Удобство проведения всех видов деятельности, связанных с сопровождение
программ.
Анализируемость (analyzability) или удобство проведения анализа. Удобство
проведения анализа ошибок, дефектов и недостатков, а также удобство анализа
необходимости изменений и их возможных последствий.
Удобство внесения изменений (changeability). Показатель, обратный
трудозатратам на выполнение необходимых изменений.
Стабильность (stability). Показатель, обратный риску возникновения
неожиданных эффектов при внесении необходимых изменений.
Удобство проверки (testability). Показатель, обратный трудозатратам на
проведение тестирования и других видов проверки того, что внесенные изменения
привели к нужным результатам.
Соответствие стандартам удобства сопровождения (maintainability
compliance). Этот атрибут добавлен в 2001 году.
Переносимость (portability).
Способность ПО сохранять работоспособность при переносе из одного
окружения в другое, включая организационные, аппаратные и программные аспекты
окружения.
Иногда эта характеристика называется в русскоязычной литературе
мобильностью.
Адаптируемость (adaptability). Способность ПО приспосабливаться различным
окружениям без проведения для этого действий, помимо заранее предусмотренных.
Удобство установки (installability). Способность ПО быть установленным или
развернутым в определенном окружении.
Способность к сосуществованию (coexistence). Способность ПО
сосуществовать с другими программами в общем окружении, деля с ними ресурсы.
Удобство замены (replaceability) другого ПО данным. Возможность
применения данного ПО вместо других программных систем для решения тех же задач
в определенном окружении.
Соответствие стандартам переносимости (portability compliance). Этот
атрибут добавлен в 2001 году.
25
Эффективность (effectiveness). Способность ПО предоставлять пользователям
возможность решать их задачи с необходимой точностью при использовании в
заданном контексте.
Продуктивность (productivity). Способность ПО предоставлять пользователям
определенные результаты в рамках ожидаемых затрат ресурсов.
Безопасность (safety). Способность ПО обеспечивать необходимо низкий
уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности
или окружающей среде.
Удовлетворение пользователей (satisfaction). Способность ПО приносить
удовлетворение пользователям при использовании в заданном контексте.
26
содержит также практическое руководство по использованию представленных
моделей качества.
ISO/IEC 2502n – группа измерения качества. Стандарты данной группы
включают эталонную модель измерений качества программного продукта,
математические определения мер качества и практическое руководство по их
применению. Даются примеры внутренних и внешних мер качества программных
продуктов и систем, а также мер качества в использовании. Определены и
представлены элементы мер качества, являющиеся основой этих мер.
ISO/IEC 2503n – группа требований к качеству. Стандарты данной группы
помогают определить требования к качеству, основываясь на моделях и мерах
качества. Эти требования к качеству могут использоваться в процессе выявления
требований к качеству разрабатываемого программного продукта или как входные
данные для процесса оценки.
27
Лекция 16
Управление качеством и надежностью программного обеспечения (ч.2)
1
импровизируются "на ходу". В этом случае велика вероятность превышения бюджета
или заваливания сроков сдачи проекта, и потому менеджеры вынуждены заниматься
только разрешением ближайших проблем.
С другой стороны, в зрелой организации имеются четко определенные процедуры
создания программных продуктов и управления проектами. Эти процедуры по мере
необходимости уточняются и совершенствуются в пилотных проектах или с помощью
анализа стоимость/прибыль. Оценки времени и стоимости выполнения работ
основываются на накопленном опыте и достаточно точны. Наконец, в компании
существуют стандарты на процессы разработки, тестирования и внедрения ПО, правила
оформления конечного программного кода, компонент, интерфейсов и т.д. Все это
составляет инфраструктуру и корпоративную культуру, поддерживающую процесс
разработки программного обеспечения.
Таковы базовые посылки стандарта CMM. Можно сказать, что стандарт в целом
состоит из критериев оценки зрелости организации и рецептов улучшения
существующих процессов. В этом наблюдается принципиальное различие с моделью,
принятой в ISO 9001, так как в ISO 9001 сформулированы только необходимые условия
для достижения некоторого минимального уровня организованности процесса, и не
дается никаких рекомендаций по дальнейшему совершенствованию процессов.
В модели CMM определено пять уровней зрелости организаций. В результате
аттестации компании присваивается определенный уровень, который в дальнейшем
может повышаться или (теоретически) понижаться.
3
1. Заинтересованность руководства в данной области (планируется ли
практическое внедрение данной ключевой области, существует ли понимание у
руководства необходимости данной области и т.д.).
2. Насколько широко данная область применяется в организации (например,
оценке в 4 балла соответствует фрагментарное применение).
3. Успешность использования данной области на практике (например, оценке в 0
баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов
выставляется при наличии систематического и измеримого положительного результата
практически во всей организации).
В принципе, можно сертифицировать только один процесс или подразделение
организации, например, подразделение разработки программного обеспечения
компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем
немного компаний, которые могут похвастаться наличием у них пятого уровня CMM
хотя бы в одном из подразделений – таких всего около 50. С другой стороны,
насчитывается несколько тысяч компаний, сертифицированных по 3 или 4 уровню.
Свыше 70% всех компаний-разработчиков находится на первом уровне CMM.
Интересен вопрос о соотношении уровней CMM со стандартом ISO 9001: на каком
уровне CMM должна находиться организация, чтобы получить сертификат
соответствия ISO 9001? На первый взгляд, для этого необходимо иметь как минимум 3
или 4 уровень CMM. Тем не менее, существуют примеры организаций 1-го уровня,
имеющих сертификат ISO 9001. Одной из причин для возникновения подобных
несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим свобода
его интерпретации аудитором.
Естественно, особенно важен подбор сотрудников для организаций первого
уровня, так как сотрудники для них являются единственной гарантией качества. Но и на
более высоких уровнях зрелости "человеческий фактор" сохраняет свою значимость.
Поэтому в 1995 году был опубликован стандарт People CMM, являющийся дополнением
к Software CMMI и имеющий, в целом, похожую структуру. Внедрение этого стандарта
параллельно с обычным CMM обеспечивает организацию целым набором процедур по
оценке и развитию всей системы найма, обучения и сохранения квалифицированных
сотрудников.
Кроме People CMM, возникло еще несколько моделей, дополняющих CMM,
например, в приобретении ПО или разработке крупных систем. В целях полной
интеграции этих моделей и снижения общих затрат по их внедрению, был предпринят
проект CMM Integration (ради его выполнения в 1998 году был даже отменен выпуск
CMM версии 2.0).
К сожалению, использование CMM затрудняют следующие проблемы:
• стандарт CMM является собственностью Software Engineering Institute и не
является общедоступным (в частности, дальнейшая разработка стандарта ведется самим
институтом, без заметного влияния остальной части программистского сообщества);
• оценка качества процессов организаций может проводиться только
специалистами, прошедшими специальное обучение и аккредитованными SEI;
• стандарт ориентирован на применение в относительно крупных компаниях;
4
SPICE – оценка и аттестация зрелости процессов создания и сопровождения
программных средств и информационных систем.
В 1991 году Международная организация по стандартизации инициировала
работу по созданию единого стандарта оценки программных процессов. Стандарт
получил имя SPICE (сокращение от Software Process Improvement and Capability
dEtermination, определение возможностей и улучшение процесса создания
программного обеспечения). Официально стандарт называется "ISO/IEC 15504:
Information Technology − Software Process Assessment.
Задачей SPICE является создание международного стандарта, в котором был бы
учтен весь накопленный опыт в области разработки ПО.
Итак, стандарт SPICE унаследовал многие черты более ранних стандартов, в том
числе и уже упоминавшихся ISO 9001 и CMM. Для этого пришлось прибегнуть к
повышению уровня детализации стандарта. Следствием такого основательного подхода
является большой объем стандарта: документация к нему содержит около 500 страниц!
Больше всего SPICE напоминает CMM. Точно так же, как и в CMM, основной
задачей организации является постоянное улучшение процесса разработки ПО. Кроме
того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE
определено 6 различных уровней), но эти уровни применяются не только к организации
в целом, но и к отдельно взятым процессам.
5
В таблице приведен список уровней способностей модели SPICE и характерные
для них процедуры управления. На данный момент не существует русского перевода
стандарта SPICE, поэтому использованные термины не являются общепринятыми
или официально зарегистрированными
Уровни Название
Уровень 0 Процесс не выполняется
Уровень 1 Выполняемый процесс
1.1 Измерение производительности процесса
Уровень 2 Управляемый процесс
2.1 Управление производительностью
2.2 Управление созданием продуктов
Уровень 3 Установленный процесс
3.1 Документирование процесса
3.2 Отслеживание ресурсов процесса
Уровень 4 Предсказуемый процесс
4.1 Измерение процесса
4.2 Управление процессом
Уровень 5 Оптимизирующий процесс
5.1 Изменение процесса
5.2 Постоянное совершенствование
Уровни способностей процесса в стандарте SPICE
6
Во время оценки и улучшения качества процессов выполняются следующие
задачи:
7
Преимущества SPICE по сравнению с ISO 9001.
8
Процессы SQM состоят из задач и техник, предназначенных для оценки того,
как начинают реализовываться планы по созданию программного обеспечения и
насколько хорошо промежуточные и конечные продукты соответствуют заданным
требованиям. Результаты выполнения этих задач представляются в виде отчетов для
менеджеров перед тем, как будут предприняты соответствующие корректирующие
действия. Управление SQM-процессом ведется исходя из уверенности, что данные
отчетов точны.
9
Проверка (верификация) и аттестация (валидация) программного
обеспечения – упорядоченный подход в оценке программных продуктов, применяемый
на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по
проверке и аттестации, направлены на обеспечение качества как неотъемлемой
характеристики программного обеспечения и удовлетворение пользовательских
требований.
Проверка и аттестация ПО напрямую адресуется вопросам качества
программного обеспечения и использует соответствующие техники тестирования для
обнаружения тех или иных дефектов, может применяться для промежуточных
продуктов, однако, в том объеме, который соответствует промежуточным шагам
соответствующих процессов жизненного цикла.
Верификация – попытка обеспечить правильную разработку продукта (продукт
построен правильным образом; обычно, для промежуточных, иногда, для конечного
продукта), в том значении, что получаемый в рамках соответствующей деятельности
продукт соответствует спецификациям, заданным в процессе предыдущей
деятельности.
Аттестация (валидация) – попытка обеспечить создание правильного продукта
(построен правильный продукт; обычно, в контексте конечного продукта), с точки
зрения достижения поставленной цели.
Оба процесса – верификация и аттестация – начинаются на ранних стадиях
разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых
возможностей продукта как в контексте непосредственно предшествующих результатов
(промежуточных продуктов), так и с точки зрения удовлетворения соответствующих
спецификаций. Целью планирования проверки и аттестации ПО является обеспечение
процессов верификации и аттестации необходимыми ресурсами, четкое назначение
ролей и обязанностей. Получаемый план документирует и детально описывает
различные ресурсы, роли и действия, а также используемые техники и инструменты.
План также касается аспектов управления, коммуникаций (взаимодействия),
политик и процедур в отношении действий по верификации и аттестации и их
взаимодействия. Кроме того, в нем могут быть отражены вопросы формирования
отчетности по дефектам и документирования требований.
Подготовка процесса
Задачи:
– периодические анализы хода работ в сроки, установленные проектным
планом, целевые анализы в сроки, определяемые заинтересованной стороной.
– между сторонами, участвующими в проведении анализа, должны быть
согласованы объем и состав ресурсов, необходимых для проведения анализа. Данные
10
ресурсы включают персонал, место проведения, условия проведения, необходимые
технические, программные и инструментальные средства.
– стороны должны согласовать следующие вопросы проведения каждого
анализа: план проведения анализа; состав анализируемых программных продуктов
(результатов работы) и проблем; объем и процедуры проведения анализа; исходные и
итоговые критерии при проведении анализа.
– проблемы, выявленные при проведении анализа, должны быть
документально оформлены и введены в процесс решения проблем
– результаты анализа должны быть документально оформлены и разосланы
заинтересованным сторонам.
– стороны должны согласовать итоговый результат анализа, любые
принимаемые обязательства и критерии завершения анализа.
Технические анализы
Должны быть проведены технические анализы для оценки создаваемых
программных продуктов или услуг с точки зрения их просмотра и представления
доказательств того, что:
a) они полностью реализованы на данный момент;
b) они соответствуют принятым стандартам и техническим требованиям;
c) изменения к ним выполнены должным образом и влияют только на те области,
которые определены процессом управления конфигурацией
d) они полностью придерживаются установленных графиков работ;
e) они готовы к последующим работам;
f) их разработка, эксплуатация или сопровождение проводятся в соответствии с
проектными планами, графиками, стандартами и руководствами.
11
Управленческие оценки (Management Reviews)
Назначение управленческих оценок состоит в отслеживании развития
проекта/продукта, определения статуса планов и расписаний, утверждения требования
и распределения ресурсов, или оценки эффективности управленческих подходов,
используемых для достижения поставленных целей.
Управленческие оценки поддерживают принятие решений о внесении изменений
и выполнении корректирующих действий, необходимых в процессе выполнения
программного проекта.
Управленческие оценки определяют адекватность планов, расписаний и
требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки
могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита,
отчетов о состоянии (развитии), отчетов проверки и аттестации, а также различных
типов планов – управления рисками проекта/проектного управления,
конфигурационного управления, безопасности использования программного
обеспечения, оценки рисков и т.п.