Скачать 1.18 Mb.
|
2.2 Управление требованиями Требования задают возможности, которые должна предоставлять система, так что соответствие или несоответствие некоторому множеству требований часто определяет успех или неудачу проекта. Поэтому имеет смысл узнать, что собой представляют требования, записать их, упорядочить и отслеживать их изменения. Определение управления требованиями выглядит следующим образом [3]. Управление требованиями — это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. Учитывая, что системе будут предъявлены сотни, если не тысячи требований, то очень важно организовать их. Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений. Кроме того, очень важными факторами являются размер проекта и его сложность. Управление требованиями наиболее важно в больших проектах, в которых участвует множество людей и число требований к проекту велико. Допустим, таких требований 1000. Тогда придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсов для выполнения всех этих требований. Последовательность работы с требованиями. Анализ проблемы У пользователя есть технические или бизнес-задачи, для решения которых им нужны программисты. Задача последних состоит в том, чтобы понять проблемы пользователей в их собственной проблемной плоскости и на их языке и построить системы, удовлетворяющие их требованиям. Для понимания проблемы пользователей существует ряд профессиональных приемов, о которых пойдет речь ниже [3|. Программисты должны понять потребности пользователей и других заинтересованных лиц, на чью жизнь повлияет создание программы. Следующим шагом осуществляется переход в область решения — непосредственно к программированию. Однако для начала будет полезно сформулировать знания о предметной области. На данном этапе составляется список функций, которые должна реализовывать система. Для того чтобы провести анализ, полезно определить, что же собственно представляет собой проблема. По определению Гаусса и Вайнберга [И], проблема — это разница между желаемым и воспринимаемым. Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы. Как всегда, начинать следует с определения цели. Цель анализа состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки. Для этого необходимо осуществить следующие пять этапов.
Этап 1. Достижение соглашения об определении проблемы. Первый шаг состоит в достижении соглашения об определении проблемы, которую необходимо решить. Один из простейших способов заключается в том, чтобы просто записать проблему и выяснить, все ли согласны с такой постановкой. В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клиентов/пользователей. Это обеспечивает дополнительную содержательную основу для понимания реальной проблемы. Рассматривая эти преимущества с точки зрения клиента, программисты также достигают лучшего понимания их взгляда на проблему в целом. Часто бывает полезно записать проблему в стандартной форме (таблица 2.1). Создание подобной таблицы является простым, но действенным средством, чтобы удостовериться в том, что все участники проекта работают вместе над осуществлением общей цели. Таблица 2.1- Структурирование проблемы
Этап 2. Выявление основных причин — вопросов, стоящих за проблемой. На данном этапе важно понять корневые причины, лежащие в основе проблемы, и ее проявления. Например, электронный магазин решил бороться с проблемой недостаточной прибыльности. Для этого был проведен анализ причин плохих продаж. Получено, что следующие причины ведут к слишком большим остаткам продукции на складе:
Однако нужно ли устранять все эти причины? Зачастую нет. Некоторые корневые причины просто не стоят того, чтобы их устранять. Нужно определить влияние каждой корневой причины и устранять только тс, которые наиболее серьезно влияют на саму проблему. В примере, допустим, наибольшее влияние оказывает корневая причина «Неправильные заказы на покупку». Этап 3. Выявление заинтересованных лиц и пользователей. В этом процессе могут помочь ответы на следующие вопросы:
Этап 4. Определение границ системы.
Рисунок 2.2 – Границы системы Очень важно правильно определить факторы. Для этого следует ответить на приводимые ниже вопросы.
Этап 5. Выявление ограничений, налагаемых на решение. Ограничения уменьшают степень свободы, которой располагают разработчики при реализации решения. Каждое ограничение может существенно сузить возможность создания предполагаемого решения. Следовательно, в процессе планирования необходимо тщательно изучить все ограничения (таблица 2.2). Таблица 2.2 - Возможные источники ограничений системы Преграды на пути выявления требований Синдром «да. но... Одну из самых неприятных проблем, с которыми сталкиваются разработчики, можно назвать синдромом «да, но...» [3]. Это первичная наблюдаемая реакция пользователя на каждый разработанный фрагмент программного обеспечения, которая могла бы быть выражена следующими словами:
Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что программисты подразумевают, когда описывают ее. И вот теперь она перед ними — впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали! Как это ни грустно, но нужно принять факт существования синдрома «да, но...» в качестве объективной реальности и сделать некоторые выводы, которые помогут членам команды смягчить влияние этого синдрома в будущих проектах:
Синдром «пользователь и разработчик» является следствием расхождения взглядов пользователей и разработчиков. Пользователи и разработчики, как правило, принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Предлагаются рекомендации по смягчению данной ситуации (таблица 2.3). Таблица 2.3 - Рекомендации решения проблемы Функции Использование функций — удобный способ описания возможностей без лишних подробностей. Такой подход имеет недостаток. Если команда при обсуждении не поймет, какая потребность стоит за функцией, это может привести к неприятным последствиям. Тем не менее это высокий уровень абстракции, удобный для описания возможностей системы. Рекомендуемое количество функций, которое дает полное представление о разрабатываемой системе, — 25—99, однако желательно, чтобы их число не превышало 50. После того как все функции перечислены, можно приступить к принятию решения вида «отложить до следующей версии», «реализовать немедленно», «полностью отвергнуть» или «исследовать дополнительно». Это процесс корректировки маештаба лучше проводить на уровне функций, а не на уровне требований, иначе можно увязнуть в деталях. Чтобы лучше работать с этой информацией, введем понятие атрибутов функций — элементов данных, которые обеспечат дополнительную информацию о каждой функции (табл. 2.4). Таблица 2.4 - Атрибуты функций Методы выявления требований:
Интервьюирование и анкетирование. Интервью помогает понять проблему, не оказывая влияния на ответы пользователя. Ниже приведены примеры контекстно-свободных вопросов:
После этого интервьюер перечисляет основные пункты, чтобы проверить, все ли было правильно понято: «Итак, вы сказали мне...» (перечисляются описанные заказчиком проблемы своими словами). «Какие еще проблемы вы испытываете?» Правила подготовки интервью:
Совещания. Хорошо проведенное совещание по вопросам требований имеет множество преимуществ:
Все материалы к совещанию должны быть предоставлены участникам заранее. Мозговой штурм. Все основные участники собираются в одной комнате, им раздаются материалы для заметок — не менее 25 листов формата от 7 х 12 до 12 х 17. Правила проведения мозгового штурма:
Идеи каждый записывает на листок; позже они оглашаются. Критиковать их нельзя, дискутировать тоже не стоит, чтобы никого не обидеть. Идею надо попробовать развить или скомбинировать с какой-либо другой; если ничего не получится, то се просто изымут из рассмотрения. Идеи обязательно записывают на бумагу по следующим причинам:
Раскадровка. Цель раскадровки в раннем выявлении реакции типа «да, но... Существует три типа раскадровок.
Применение прецедентов. Рисуются схемы с факторами; в овале пишется вид выполняемого ими действия (рисунок 2.3). Рисунок 2.3 - Схема применения прецедентов Обыгрывание ролей. Этот способ позволяет разработчику прочувствовать проблемы пользователя. Разработчик на время становится на место клиента, причем можно заранее написать сценарий для программистов, по которому они попытаются выполнить действия пользователей. Также очень эффективным способом является составление сценариев на основе CRC-карточек. Карточки описывают объект, его повеление и взаимодействие с другими объектами системы. Участники делят карточки между собой и используют их для ролевой игры, выполняя действия согласно предписаниям. Эффективный способ для выявления проблем проектирования системы. Прототипы требований. Прототип требований к ПО — это частичная реализация системы, созданная для того, чтобы помочь разработчикам, пользователям и клиентам точнее определить требования к системе. Этот метод также помогает решить проблему «да, но...» [3]. Таким образом, на базе знаний по составлению требований к ПО и при их корректном постоянном применении разработчик лучше поймет проблемы клиента, как следствие, создаст качественный программный продукт, отвечающий потребностям пользователей, и снизит риск краха проекта из-за функционального несоответствия приложения. |
Наконец, последняя выделяемая нами архитектура предназначена для построения глобальных распределенных информационных приложений с... | ПМ. 05 Выполнение работ по одной или нескольким профессиям рабочих, должностям служащих | ||
Перечень документов подтверждающих условие присвоения звания – ветеран труда, утверждено постановлением правительства №11 – пп от... | Конспект лекций по курсу «Делопроизводство» составлен на основе базовой программы «Делопроизводство и документационное обеспечение... | ||
Химия. Конспект лекций для студентов I курса медицинского факультета специальности «Стоматология». Часть Общая химия. М.: Изд-во... | Налоги и налогообложение: Конспект лекций / Составитель Н. А. Леончик. – Кемерово, 2006. – 80 с | ||
Пм 01. «Ведение расчетных операций», рассмотренной пцк от 31 августа 2016 г протокол №1 | Автоматизированные системы бухгалтерского и управленческого учета. Часть 1: Конспект лекций / Владим гос ун-т; Сост.: Д. Н. Васильев... | ||
Пм 01. «Ведение расчетных операций», рассмотренной пцк от 31 августа 2016 г протокол №1 | Вопросы к экзамену по мдк 02. 01. «Технология и организация сопровождения туристов» для студентов 2 курса специальности «Туризм» |
Поиск Главная страница   Заполнение бланков   Бланки   Договоры   Документы    |