Yyyyyy yyyy 1-8

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

Литература

• Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004.

• Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. — М.: Вильямс, 2002.

• Кобёрн А. Современные методы описания функциональных требований к системам. — М.: Лори, 2002.

• Пер Кролл, Филипп Крачтен. Rational Unified Process - это легко. Руководство по RUP для практиков

Анализ требований к ПО

Анализ требований к ПО – это процесс • сбора требований к программному обеспечению, • систематизации требований, • документирования требований, • анализа, выявления противоречий, неполноты

требований, • разрешения конфликтов в процессе разработки

программного обеспечения.

В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering).

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

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

• Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

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

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

Понятие «требование к ПО» • SWEBOK (Software Engineering Body of Knowledge) Программные требования (Software

Requirements) – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нем для решения конкретных практических задач.

• RUP (Rational Unified Process) Требование – это условие или возможность, которой должна соответствовать система

• IEEE (I triple E, Institute of Electrical and Electronics Engineers, Институт инженеров по электротехнике и электронике) Standard Glossary of Software Engineering Terminology (1990)1. условия или возможности, необходимые пользователю для решения проблем или достижения

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

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

3. документированное представление условий или возможностей для пунктов 1 и 2.

• Дорфман (Dorfman), Тэйер (Thayer) (Леффингуэлл. Принципы работы с требованиями ПО)1. Некое свойство программного обеспечения, необходимое пользователю для решения проблемы

при достижении поставленной цели.2. Некое свойство программного обеспечения, которым должна обладать система или ее компонент,

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

• Ian Sommerwille &Pete Sawyer Требования – это спецификация того, что должно быть получено. Требования описывают поведение системы или атрибуты и свойства системы. Требования могут являться и ограничениями на процесс разработки системы.

Классификация требованийSWEBOK - не описывает подходы к классификации

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

• Требования к продукту и процессу • Функциональные и нефункциональные требования • Независимые свойства • Требования с количественной оценкой • Системные требования и программные требования.

Классификация требованийФункциональные требования Нефункциональные требования

Бизнес-требования

Требования пользовател

ей

Системные требования

Функциональные требования

Бизнес-правила

Атрибуты качества

Внешний интерфейс

Ограничения

Документ об образе и границах проекта

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

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

К.ВИГЕРС

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

• Деталей дизайна или реализации

• Данных о планировании проекта

• Сведений о тестировании

Классификация требованийД. Леффингуэлл. Пирамида требований

Бизнес-цели

Требования пользователей

Функциональные требования

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

решения некоторых бизнес-задач;

• Пользователи, которые взаимодействуют напрямую или не напрямую с приложением (подкласс заказчиков);

• Аналитики требований, которые пишу требования и передают их разработчикам;

• Разработчики, которые создают, разворачивают и поддерживают продукт;

• Тестеры, которые определяют соответствие поведения ПО желаемому;

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

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

• Сотрудники правового отдела, которые следят, чтобы продукт не противоречил действующим законам и постановлениям;

• Производственники, которые должны построить продукт, содержащий дано ПО;

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

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

• любой, кто пользуется системой (пользователи и обслуживающий персонал)

• любой, кто извлекает выгоду из системы (функциональную, политическую, финансовую и социальную)

• любой вовлечённый в покупку или обеспечение системы• организации, которые регулируют аспекты системы

(финансовые, безопасность, и другие)• люди или организации, настроенные против системы

(отрицательные заинтересованные лица),• организации, ответственные за системы, которые

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

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

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

Продукт под заказХарактеристики процесса:

•заказчик определен с самого начала;

•заказчику известны начальные предпосылки (стимулы) для инициации проекта и проблемы, которые продукт должен решить

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

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

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

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

Продукт для открытого рынка

Характеристики процесса:

•сектор рынка с самого начала может быть не определен;

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

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

•сразу за определением исходных предпосылок (стимулов) идет обзор конкурентов;

•далее идет определение целевого сегмента рынка и потребностей его заказчиков;

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

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

Встроенные приложения

Характеристики процесса:

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

Определение стимулов

•потребность рынка;

•производственная необходимость;

•потребность заказчика;

•технический прогресс;

•юридические ограничения или нормы.

Определение целей продукта и

критериев успеха •финансовые:

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

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

Техники выявления требований

•Мозговой штурм

•Совещания

•Интервью

•Наблюдение

•Кабинетные исследования

•Анкетирование

Метод мозгового штурма

1. Четкая формулировка цели и/или задач и ограничений

2. Обеспечение максимальной свободы участникам

3. Тщательное формирование состава участников

4. Иерархическое ведение обсуждений

5. Огромная роль "ведущего" и демократический стиль руководства

Метод мозгового штурма. Основные этапы

1. Разминка

Зачем мы здесь собрались?

2. Генерирование идей

Любые идеи важны, даже самые безумные!

3. Обсуждение

Насколько эта идея поможет решить нашу задачу?

4. Подведение итогов

Метод мозгового штурма. Распределение ролей

1. Ведущий

управляет процессом;

поощряет предложение и обсуждение;

вовлекает всех участников;

поддерживает энергичность.

2. Помощник ведущего (может отсутствовать)

записывает предложения;

следит за временем;

3. Эксперт

разъясняет проблему;

отвечает на вопросы;

дает дополнительную информацию.

4. Участник

выдает предложения;

задает вопросы.

Метод мозгового штурма. Метод 635

6 человек

3 идеи

5 минут

Метод мозгового штурма. Метод модераций

3 карточки

Соотнесение карточки с кластером

Ранжирование кластеров

Совещание

1. Подготовка к совещанию

2. Проведение совещания

3. Итоги совещания

Совещание. Подготовка

• Определение целей совещания

• Потребность в совещании

• Формулировка четкой повестки дня и донесение ее до участников

• Определение «ключевых фигур» совещания

• Обеспечение участников совещания достаточной информацией

• Анализ возможных возражений

Совещание. Проведение

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

• Суммирование промежуточных результатов совещания

• Равноправие участников совещания

• Регламент выступлений и соответствие выступлений повестке дня

• Принятие решений по каждому пункту, в случае достижения консенсуса

Совещание. Итоги

• Определение результатов совещания (задания, ответственные за выполнение, сроки выполнения)

• Документирование результатов совещания

• Организация встречи с участниками, мнение которых не было учтено

• Рассылка уведомлений, посвященных дальнейшим действиям

Совещание. Методы проведения

1. Доклад

2. Обмен мнениями

3. Мозговой штурм

4. Обсуждение.

Формат совещания по решению проблем

Формат совещания по принятию решений

•Сбор данных

•Определение проблемы и идентификация причин

•Критерии для принятия решений

•Разработка альтернатив

•Оценка альтернатив

•Принятие решения, выбор альтернативы

•Планирование действий по реализации решения

ИнтервьюФормат:

• Беседа интервьюера с респондентом по предварительно составленному плану-гайду

• Аудио-запись беседы с последующей расшифровкой для детального анализа либо конспектирование ответов в заранее заготовленных шаблонах интервью

Структура вопросов интервью:

•Контекстно-свободные – помогают достичь понимания реальной проблемы, не оказывая влияния на ответы пользователя.

Примеры:Кто является пользователем системы?Кто является клиентом?Отличаются ли из потребности?Где еще можно найти решение данной проблемы?

•Контекстно-зависимые – смещены в область исследования решений, позволяют не только понять проблему, но и предложить подходящие решения.

Пример структуры интервью(1)

Часть 1. Определение профиля заказчика или пользователя

• Имя• Компания• Отрасль• Должность• (указанная информация, как правило, может быть внесена

заранее)• Каковы ваши основные обязанности?• Что вы в основном производите?• Для кого?• Как измеряется успех вашей деятельности?• Какие проблемы влияют на успешность вашей деятельности?• Какие тенденции, если такие существуют, делают вашу работу

проще или сложнее?

Пример структуры интервью(2)

Часть 2. Оценка проблемы• Для каких проблем (прикладного типа) вы

ощущаете нехватку хороших решений?• Назовите их. (Замечание: не забывайте

спрашивать «А еще?»)• Для каждой проблемы выясняйте

следующее:– Почему существует эта проблема?– Как она решается в настоящее время?– Как заказчик (пользователь) хотел бы ее решать?

Пример структуры интервью(3)

Часть 3. Понимание пользовательской среды• Кто такие пользователи?• Какое у них образование?• Каковы их навыки в компьютерной области?• Имеют ли опыт работы с данным типом приложений?• Какая платформа используется?• Каковы ваши планы относительно будущих платформ?• Используются ли дополнительные приложения, которые имеют

отношение к данному приложению? Если да, то пусть о них немного расскажут

• Каковы ожидания заказчика относительно практичности продукта?

• Сколько времени необходимо на обучение?• В каком виде должна быть представлена справочная

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

Пример структуры интервью(4)

Часть 4. Резюме (перечисляются основные пункты, чтобы проверить, всё ли правильно вы поняли)

• Итак, вы сказали мне(перечислите описанные заказчиком проблемы своими словами)

---

• Адекватно ли этот список представляет проблемы, которые имеются при существующем решении?

• Какие еще проблемы (если такие существуют) вы испытываете?

Пример структуры интервью(5)

Часть 5. Предположения аналитика относительно проблемы заказчика

(проверенные и непроверенные предположения)(те проблемы, которые не были упомянуты)• Какие проблемы, если они есть, связаны с (перечислите все

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

Для каждой из указанных проблем выясните следующее:• Является ли она реальной?• Каковы ее причины?• Как она решается в настоящее время?• Как бы заказчик (пользователь) хотел ее решать?• Насколько важно для заказчика (пользователя) решение этой

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

Пример структуры интервью(6)

Часть 6. Оценка предполагаемого вами решения (если это уместно)

(Охарактеризуйте основные возможности предлагаемого вами решения. А потом задайте пользователю следующие вопросы.)

• Что, если вы сможете…• Как вы расцениваете важность этого?

Пример структуры интервью(7)

Часть 7. Оценка возможности• Кто нуждается в приложении?• Сколько пользователей будут использовать

приложение?• Насколько значимо успешное решение?

Пример структуры интервью(8)

Часть 8. Оценка необходимого уровня надежности и производительности, а также потребности сопровождения

• Каковы ваши ожидания относительно надежности?• Какой, по-вашему, должна быть производительность?• Будете ли вы заниматься поддержкой продукта или этим

будут заниматься другие?• Испытываете ли вы потребности в поддержке?• Что вы думаете о доступе для сопровождения и

обслуживания?• Каковы требования относительно установки и конфигурации?• Существуют ли специальные требования по

лицензированию?• Как будет распределено программное обеспечение?• Есть ли требования на маркировку и упаковку?

Пример структуры интервью(9)

Часть 9. Другие требования• Уточнить наличие законодательных актов,

инструкций, стандартов и других стандартов, которых нужно придерживаться.

Часть 10. Окончание интервью• Какие еще вопросы стоило задать?• Как можно связаться для обсуждения требований?

Часть 11. Заключение аналитика• Фиксация потребностей и/или проблем с

наивысшими приоритетами.

Фокус-группа

• Групповое интервью в форме дискуссии по заранее составленному плану-гайду

• Численность 6-12 человек

• Участники - типичные представители целевой аудитории

• Продолжительность беседы – 1-3 часа

• Дискуссия записывается на видео с последующей расшифровкой для детального анализа

• В рамках одного исследования – 3-4 фокус-группы

Наблюдение

Типы наблюдений:

• Включенное - наблюдатель является непосредственным участником процесса (обыгрывание ролей пользователей)

• Невключенное - наблюдатель только регистрирует

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

Наблюдение - непосредственное целенаправленное

восприятие и регистрация явлений и процессов

Кабинетные исследования (Desk Research)

Источники информации:• Интернет-источники

• печатные СМИ

• базы данных

• законодательные акты

• правительственные публикации и материалы

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

• данные статистических органов

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

Анкетирование

Анкетирование – самозаполнение анкеты

Предпосылки:

• удаленность респондента и интервьюера

• анонимность получаемых данных

Формат:

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

• используются технические средства связи: почтовые рассылки, рассылки по e-mail, факсимильная связь

Техники диаграмм

• Ментальные карты

• Контекстная диаграмма (диаграмма потоков данных)

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

• Диаграммы состояний и действий

• Диаграмма бизнес-процессов

Ментальные карты(Mind map , интеллект-карты, диаграммы связей)

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

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

Ментальные карты. Рекомендации

1. Вместо линейной записи использовать радиальную.

2. Записывать не всё подряд, а только ключевые слова.

3. Ключевые слова помещаются на ветвях, расходящихся от центральной темы.

4. Связи (ветки) должны быть скорее ассоциативными, чем иерархическими.

5. Ассоциации могут подкрепляться символическими рисунками.

Ментальные карты, пример 1

Ментальные карты, пример 2

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

Порядок построения контекстной диаграммы :• определение системных ограничений и

интерфейсов с внешним миром

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

Используемые технологии:

• IDEF0

• DFD Data Flow Diagramming (диаграммы потоков данных)

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

Процесс – экскурсии молодых людей по достопримечательностям города Уфы.

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

Пример построения контекстных диаграмм(продолжение)

Построение модели

Цель моделирования: хорошо провести время с девушкой на экскурсии

Точка зрения: искателя приключений

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

Вопросы:•Где взять саму девушку?•Как ее убедить в неизбежности мероприятия? •Куда ее отвести?•Что с ней делать после мероприятия?  И т.д.

Пример построения контекстных диаграмм(продолжение)

Входы (inputs):•Девушки г. Уфы и окрестностей•Карта Уфы и окрестностей 

Управление (controls):•Что люди скажут?•Резервы свободного времени

Материальные возможности•Выходы (outputs):•Успешно проведенное мероприятие•Благодарная девушка

Механизмы (mechanisms):•Искатель приключений•Транспорт 

Пример построения контекстных диаграмм(продолжение)

(стандарт IDEF0)

Пример построения контекстных диаграмм(продолжение)

Дерево модели

Пример построения контекстных диаграмм(продолжение)

Выбор субъекта (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Выбор места и  времени экскурсии (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Процесс убеждения девушки (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Организация мероприятия (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Заключительные операции (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Смена модели!!!

Цель моделирования: хорошо провести время на экскурсии вместе со спутником

Точка зрения: девушки

Область применения: девушки, которые хотели бы хорошо провести время на экскурсии, но (как и искатели приключений) пока еще не знают, как этого добиться 

Вопросы:•Где найти подходящего спутника?•Как убедить его в неизбежности мероприятия?•Как обеспечить личную безопасность?•Куда сходить?•Что с ним делать после мероприятия?  

Пример построения контекстных диаграмм(продолжение)

(стандарт IDEF0)

Пример построения контекстных диаграмм(продолжение)

Основные этапы (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Дерево модели (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Подготовка (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Выбор спутника (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)

Проведение мероприятия (стандарт DFD)

Пример построения контекстных диаграмм(продолжение)Оценка претендента (стандарт DFD)

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

объектов, упорядоченные по времени их проявления

Диаграмма состоянийОриентированный граф для конечного автомата, в

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

Диаграмма бизнес-процессов(Business Process Model and Notation, нотация и модель бизнес-процессов)

Формальные техники• Диаграмма Ишекавы (Исикавы)

• SWOT (Strengths, Weaknesses, Opportunities, and Threats, сильные и слабые стороны, возможности и угрозы)

• MoSCoW (Must, Should, Could, Would)

• CATWOE (Customers, Actors, Transformation Process, World View, Owner, Environmental Constraints, клиенты, акторы, процесс трансформации, мировоззрение, владелец, ограничения среды)

• PESTLE (Political, Economic, Sociological, Technological, Legal , Environmental, политические, экономические, социологические, технологические, правовые, экологические факторы)

• MOST (Mission, Objectives, Strategies, Tactics, миссия, цели, стратегия, тактика)

Диаграмма Ишекавы(«рыбный скелет»)Причинно-следственная диаграмма или диаграмма Ишекавы является графическим изображением, которое в сжатой форме и логической последовательности распределяет причины

Цель диаграммы – выявить влияние причин на всех уровнях технологического процесса.

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

Диаграмма Ишекавы. 6М (5М)1. Man (Человек) − причины,

связанные с человеческим фактором

2. Machines (Машины, оборудование) − причины, связанные с оборудованием

3. Materials (Материалы) − причины, связанные с материалами

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

5. Measurements (Измерения) − причины, связанные с методами измерения

6. Менеджмент (management) – причины, связанные с организацией управления предприятием

Диаграмма ПаретоАвторы метода: В. Парето (Италия), 1897 г., М. Лоренц (США), 1979 г.

Цель метода: выявление проблем, подлежащих первоочередному решению

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

Особенности метода: принцип Парето (принцип 20/80) означает, что 20% усилий дают 80% результата, а остальные 80% усилий - лишь 20% результат

Достоинства метода: • Простота и наглядность делают возможным использование

диаграммы Парето специалистами, не имеющими особой подготовки• Сравнение диаграмм Парето, описывающих ситуацию до и после

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

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

Виды диаграмм Парето1. Диаграмма Парето по результатам деятельности.

Предназначена для выявления главной проблемы и отражает нежелательные результаты деятельности, связанные:• с качеством (дефекты, поломки, ошибки, отказы,

рекламации, ремонты, возвраты продукции)• с себестоимостью (объем потерь; затраты)• со сроками поставок (нехватка запасов, ошибки в

составлении счетов, срыв сроков поставок)• с безопасностью (несчастные случаи, трагические

ошибки, аварии)

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

Построение диаграммы Парето1. Решить, какие проблемы (причины проблем) надлежит

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

контрольный листок)3. Собрать данные, заполнив формы, и подсчитать итоги по каждому

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

Графы таблицы: • признак (фактор, причина и т.п.)• итог по каждому проверяемому признаку в

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

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

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

6. Подготовить оси для построения диаграммы• Горизонтальная ось - интервалы в соответствии с числом

контролируемых признаков. • Левая вертикальная ось - шкала с интервалами от 0 до общей

суммы числа выявленных факторов• Правая вертикальная ось - шкала с интервалами от 0 до 100,

отражающую процентную меру фактора. 7. Построить столбиковую диаграмму

• Высота столбца (откладывается по левой шкале) равна числу появлений соответствующего фактора

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

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

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

9. Нанести на диаграмму все обозначения и надписи

Построение диаграммы Парето (продолжение)

Анализ диаграммы Парето.Метод АВС-анализа

1. Группа А — наиболее важные, существенные проблемы, причины, дефекты. Относительный процент группы А в общем количестве дефектов (причин) обычно составляет от 60 до 80%. Устранение причин группы А имеет большой приоритет, а связанные с этим мероприятия — самую высокую эффективность

2. Группа В — причины, которые в сумме имеют не более 20%

3. Группа С — самые многочисленные, но при этом наименее значимые причины и проблемы

Пример диаграммы Парето

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

2. Группа факторов «прочие» не должна составлять большой процент

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

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

Диаграмма Парето. Рекомендации

Техника MoSCoW(Must, Should, Could, Would)

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

Should Have Требования «Should» столь же важны, как и требования «Must», но они могут не быть срочным или для их реализации их можно использовать обходной путь (workaround)

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

Won’t Have but Would Like in the Future

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

Техника MoSCoW.Наследование приоритетов

Must Should Could Would

Must Must Should Could Would

Should Should Could Would Would

Could Could Would Would Would

Would Would Would Would Would

Разработан в корпорации «Рэнд» в конце 1940-х гг. Первоначально использовался для прогнозирования будущих событий. Позднее метод использовался для принятия решений по спорным вопросам.

Суть метода:• Предварительный этап: участники дискуссии должны без

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

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

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

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

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

состоит больше из «мнений экспертов», чем из строго определенных эмпирических данных

Метод Делфи

Практическая реализация проведения оценки по методу Делфи (Барри Боэм, 1981 г.)

Является методом для повышения качества оценок, полученных несколькими экспертами

Ориентирована на получение следующих оценок: • Структурная или функциональная декомпозиция

работ • Трудозатраты • Размер проекта • Критические компьютерные ресурсы • Стоимость • Риски

Методика Wideband Delphi

Менеджер проекта – составляет список оцениваемых элементов

Модератор – управляет процессом оценки, обеспечивает правильное выполнение процедуры Wideband Delphi. Эта роль может выполняться менеджером проекта

Оценщики – изучают задачу и выполняют оценку

Методика Wideband Delphi.Основные участники процесса оценки

1. Подготовить список оцениваемых элементов

2. Провести совместную встречу команды оценки для проведения ревью списка оцениваемых элементов

3. Выполнить индивидуальные оценки

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

5. Провести встречу по обсуждению оценок

6. Завершить заполнение суммарной таблицы оценок

Применение Wideband Delphi

• Выполняется менеджером проекта

• Определяется, что надо оценить (трудозатраты, стоимость и т.д.)

• Нельзя смешивать различные виды оценок

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

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

Методика Wideband Delphi.Подготовка списка оцениваемых

элементов

Совместное совещание команды оценки организуется модератором

Это совещание должно занимать не более 30 минут

Шаги: • Рассказать про технику Wideband Delphi • Предоставить список оцениваемых элементов, а

также форм для проведения оценки • Провести ревью списка, скорректировать его при

необходимости • Если используется индивидуальная форма оценки,

то она также может быть скорректирована

Методика Wideband Delphi.Подготовка списка оцениваемых

элементов

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

посчитают нужными • Оценщики не должны общаться между собой • Индивидуальная оценка должна занимать не

более, чем 2 часа • Оценка выполняется по PERT(Program Evaluation

and Review Technique)

Методика Wideband Delphi.Выполнение индивидуальных оценок

Ожидаемая (PERT)=(О + 4*В + П) / 6

Оценка по трем точкам: О – оптимистическая (Best Case)В – наиболее вероятная (Most Probable)П – пессимистическая (Worst Case)

Пример. Некоторая работа исполнялась 10 раз. Статистика длительностей:

2 раза за 4 дня – оптимистическая 7 раз за 5 дней – наиболее вероятная 1 раз за 9 дней – пессимистическая Средняя (арифм.) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней

Методика Wideband Delphi.Оценка PERT

1. Всем участникам предоставляется суммарная таблица оценок

2. Каждый оценщик изучает суммарную таблицу оценок

3. Проводится несколько совместных обсуждений оценки

4. Каждый оценщик выполняет еще одну индивидуаль-ную оценку.

5. Результаты этих оценок опять обобщаются в суммар-ной таблице оценок

6. Проводится новое совместное обсуждение оценок 7. Если оценки сошлись и между ними небольшая

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

8. Если оценки не сошлись, то шаги 3-6 повторяются

Методика Wideband Delphi.Обсуждение оценок

1. Для проведения оценки необходимо 3-5 экспертов2. Полезно использовать экспертов с различным

опытом, проектными ролями, техниками оценки 3. Wideband Delphi это ресурсоемкая методика,

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

4. Когда применяется? • Новый бизнес-домен, технология, язык программирования • Грубая оценка на начальных стадиях проекта• Нетривиальный пользовательский интерфейс, высокая

алгоритмическая сложность, высокие требования к

производительности и т.д.

Методика Wideband Delphi.

Рекомендации по использованию

Покер планирования (англ. Planning Poker, а также англ. Scrum poker) - техника оценки, основанная на достижении договорённости

Используется для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения

Разновидность метода Wideband Delphi

Достоинство метода: минимизирует эффект привязки путём опроса каждого из участников команды таким образом, что никто не знает чужого решения до одновременного оглашения выбора каждого из участников

Покер планирования

Материалы:• список обсуждаемых функций• несколько колод пронумерованных карт

Разновидности колод:• карты, содержащие числа Фибоначчи, включая ноль: 0, 1,

2, 3, 5, 8, 13, 21, 34, 55, 89

• 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 и иногда знак вопроса («?»), означающий неуверенность, и чашку кофе, означающую требование перерыва

• обычные игровые карты, включающие туз, 2, 3, 5, 8 и короля. Король буквально означает: «Данный пункт слишком большой или его слишком сложно оценить». Выбрасывание короля завершает обсуждение пункта в текущем круге

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

Покер планирования. Подготовка

1. Каждому участнику обсуждения выдаётся по одной колоде карт. 2. Все колоды идентичны друг другу. 3. Ведущий, не участвующий в обсуждении, ведёт собрание4. Менеджер проекта представляет краткие обзоры каждого из пунктов5. Команда может задавать вопросы и вести обсуждение предложений

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

показывая таким образом, что выбор сделан8. Каждый участник называет свою карту и переворачивает её9. Участникам с высокими и низкими оценками даётся возможность

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

достигнут консенсус11.Голос участника, который, скорее всего, будет владеть разработкой,

имеет больший вес в «голосовании на основе консенсуса»12.Таймер используется для обеспечения структурированности

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

Покер планирования. Проведение

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

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

Данный эффект не исчезает, даже если:• в качестве якорей используются несоразмерно большие

или маленькие числа;• испытуемые знают об эффекте якоря

Эффект привязки

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

Команда обычно имеет в своём составе как сдержанных, так и импульсивных участников

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

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

была закончена как можно скорее

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

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

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

Эффект привязки в покере планирования

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

которых создается система3. Потребовать, чтобы аналитик преобразовал требования, предоставленные

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

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

5. На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков

6. Знать о вариантах и альтернативах требований и их реализации7. Описать характеристики, упрощающие работу с продуктом8. Изменить требования или разрешить использование имеющихся

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

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

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

Билль о правах клиента ПО при формировании требований

Клиент обязан1. Ознакомить аналитиков и разработчиков с особенностями бизнеса2. Потратить столько времени, сколько необходимо, на объяснение

требований3. Точно и конкретно описать требования к системе4. Принимать своевременные решения при формировании

требований 5. Уважать определенную разработчиком оценку стоимости и

возможность реализации ваших требований6. Определять приоритеты требований7. Просматривать документы с требованиями и оценивать прототипы8. Своевременно сообщать об изменениях требований9. Поддерживать принятый в организации-разработчике порядок

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

аналитики создают требования

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

Спецификация требований

1. Глоссарий (словарь) основных используемых терминов• Оформляется, как текст, состоящий из абзацев,

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

• Термин обычно выделяют полужирным кеглем • Иногда проблемную область целесообразно

сегментировать на ряд «подобластей» (subject areas), тогда каждой из них в глоссарии выделяется отдельный параграф

2. Реестр требований, оформленный надлежащим образом

Состав спецификации

• Размеры проекта

• Важность проекта и варианта использования

• Традиции, сложившиеся в коллективе «Заказчик-Разработчик»

• Критичность проекта в целом и критичности варианта использования в данном проекте

Факторы выбора формата спецификации

Определяется «ценой ошибки»

Проекты, ошибки в которых могут привести к… :

1)опасности для жизни людей

2)невосполнимым финансовым потерям

3)финансовым потерям в ограниченном объёме

4)снижению комфортности конечного пользователя

Показатель критичности

1.Не существует выверенного способа написания идеальных требований

2.Лучший учитель — это опыт, который нарабатывается со временем

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

Формулировка требований

1.Используйте полные предложения, с правильной грамматикой, правописанием и пунктуацией

2.Предложения и абзацы должны быть краткими и ясными

Рекомендации по формулировке требований

3. Используйте действительный залог

Рекомендации по формулировке требований

корректно некорректно

Система отобразит список товаров

На экране отобразится список товаров

4. Используйте термины и именно так, как они определены в словаре. Не используйте синонимы и близкие по значению слова.

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

читателя!!!

Рекомендации по формулировке требований

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

Рекомендации по формулировке требований

6.Требования следует излагать последовательно

Рекомендации по формулировке требований

<Субъект> [будет] <активный глагол> <наблюдаемый результат>

Замечания:• Укажите, какие условия или действия инициируют

соответствующее поведение субъекта• Можно использовать «должно» как синоним «будет» • Не используйте слова «следовало бы», «может»,

«можно было бы» и аналогичные, из которых не ясно, необходимо ли действие

7. Идентифицируйте пользователя

Рекомендации по формулировке требований

корректно некорректно

Покупатель будет... Пользователь будет...

8.Применяйте • списки, • рисунки, • графики• таблицы,

чтобы представить информацию визуально

Читателей утомляет большой объем сплошного текста!!!

Рекомендации по формулировке требований

9.Выделите наиболее значимые фрагменты информации.

Рекомендуемые приемы:• графики, • последовательности, в которых первый

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

Рекомендации по формулировке требований

10.Требования, изложенные неясным языком, не поддаются проверке

Избегайте • двусмысленных, • неоднозначных,• субъективных терминов

Рекомендации по формулировке требований

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

НО! Избегайте ненужных ограничений разработки!!!

Рекомендации по формулировке требований

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

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

Рекомендации по формулировке требований

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

Рекомендации по формулировке требований

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

• слова «и», «или» и «также» • слова «пока не» и «кроме»

Пример:«Кредитная карточка покупателя будет считаться действительной для платежей до тех пор, пока не истечет ее срок действия».

Решение: Разделите требование на два (для двух условий) когда срок действия кредитной карты истек и когда она действительна

Рекомендации по формулировке требований

Ловушка

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

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

всяких неясностей и проблем.

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

доработка

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

1) Приемлемый, адекватный

Определите, что понимается под приемлемостью и как система это может оценить

2) Практически выполнимо

Не заставляйте разработчиков определять, что под этим понимается. Поставьте пометку «TBD»(to be detected…) и определите дату, к которой эту проблему следует разрешить

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

3) По меньшей мере, как минимум, не более чем, не должно превышать

Укажите минимальное и максимальное допустимые значения

4) Между Определите, указаны ли конечные точки

Рекомендации по формулировке требований

Неоднозначные

термины

Способы их улучшения

5) Зависит от Определите природу зависимости. Обеспечивает ли другая система ввод данных в вашу систему, надо ли установить другое ПО до запуска вашей системы и зависит ли ваша система от другой при выполнении определенных расчетов или служб?

6) Эффектив-ный

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

Рекомендации по формулировке требований

Неоднозначные

термины

Способы их улучшения

7) Быстрый, моменталь-ный

Укажите минимальную приемлемую скорость, при которой система выполняет определенное действие

8) Гибкий Опишите способы изменения системы в ответ на изменения условий или бизнес-потребностей

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

9) Улучшенный, лучший, более быстрый, превосходный

Определите количественно, насколько лучше или быстрее стали показатели в определенной функциональной области

10) Включает; включает в себя, но не ограничен этим; и т.д.; и т.п.; такой как

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

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

11) Максимизируйте, минимизируйте, оптимизируйте

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

12) Обычно, в идеальном

варианте

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

13) Необязательно Укажите, кто делает выбор: система, пользователь или разработчик

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

14)Разумный, при необходимости, при соответствующих условиях

Объясните, как это выполнить

15)Устойчивый к сбоям

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

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

16)Цельный, прозрачный, элегантный

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

17)Несколько Укажите сколько или задайте минимальную и максимальную границы диапазона

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

18)Не следует Старайтесь формулировать требования в позитивной форме, описывая, что именно система будет делать

19)Реальный Поясните этот термин

20)Достаточный Укажите, какая степень чего-либо свидетельствует о достаточности

Рекомендации по формулировке требований

Неоднозначные термины

Способы их улучшения

21)Поддерживает, позволяет

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

22)Дружественный, простой, легкий

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

Mary had a little lamb

Пример неоднозначности«У Мэри был

маленький барашек»

Sarah Hale

Ключевые слова:• had (have)• lamb

«У Мэри был маленький барашек»

Have1а) иметь во владении в качестве собственности4а) приобретать в качестве собственности4в) ПРИНИМАТЬ состоять в браке5а) отметка или отличительная особенность (иметь

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

ущемлять10б) ОБМАНУТЬ, ОДУРАЧИТЬ12)ПРОИЗВЕСТИ НА СВЕТ, РОДИТЬ (иметь ребенка)13)съесть14) ДАВАТЬ ВЗЯТКУ, ПОДКУПАТЬ

«У Мэри былмаленький барашек»

Webster's Seventh New Collegiate Dictionary

Lamb1а) молодая овца в возрасте до одного года или без

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

антилоп)2а) человек слабый и симпатичный, как маленький

барашек2б) ДОРОГОЙ, ЛЮБИМЫЙ2в) человек, легко идущий на обман (нечистый на руку),

особенно в сфере торговли3а) «седло барашка» - кулинарное блюдо

«У Мэри былмаленький барашек»

Webster's Seventh New Collegiate Dictionary

«У Мэри былмаленький барашек» Интерпретации (1)

have lamb Интерпретация

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

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

«У Мэри былмаленький барашек»

Интерпретации (2)have lamb Интерпретация

5а 1а Мэри - владелец маленькой овечки в возрасте до одного года или без постоянных зубов

10а 1а Мэри держала в руках (не давала порезвиться) маленького ягненка в возрасте до одного года или без постоянных зубов

«У Мэри былмаленький барашек»

Интерпретации (3)have lamb Интерпретация

12 1б Мэри родила маленькую антилопу

12 2а Мэри является (или была) матерью некоего маленького симпатичного существа

«У Мэри былмаленький барашек»

Интерпретации (4)have lamb Интерпретация

13 3а Мэри съела небольшую порцию седла ягненка

14 2в Мэри подкупила мелкого торговца ценными бумагами, который нечист на руку

• Эвристика запоминания – восстановление по памяти исходного требования

• Метод ключевых слов – выделить ключевые слова, выписать их определения (из авторитетных источников!) и составить комбинации

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

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

Методы уходаот неоднозначности

«У Мэри был маленький барашек»

Метод ударения

У Мэри был маленький барашек

У Мэри был маленький барашек

У Мэри был маленький барашек

У Мэри был маленький барашек

У Мэри был маленький барашек (Mary had a little lamb)

• Полные• Правильные• Выполнимые• Необходимые• Имеющие приоритет• Точно выраженные• Поддающиеся проверке

Характеристики требований

Ловушка

Старайтесь избегать паралича аналитического процесса

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

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

при приемлемом уровне риска

Один из способов оценить требование – проверить, устраивают ли пользователя

нелепые, но имеющие право на существование интерпретации этого

требования

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