Для этого уровня мероприятия по совершенствованию рассчитаны не только на существующие процессы, но и на внедрение, использование новых технологий и оценку их эффективности. Основной задачей всей организации на этом уровне является постоянное совершенствование существующих процессов, которое в идеале направлено на предотвращение известных ошибок или дефектов и предупреждение возможных. Применяется механизм повторного использования компонентов от проекта к проекту (шаблоны отчетов, форматы требований, процедуры и стандартные операции, библиотеки модулей программных средств).
Ключевые области процесса разработки ПО этого уровня:
- Предотвращение дефектов (Defect Prevention).
- Управление изменением технологий (Technology Change Management).
- Управление изменением процесса (Process Change Management).
СММ определяет следующий минимальный набор требований: реализовать 18 ключевых областей процесса разработки ПО, содержащих 52 цели, 28 обязательств компании, 70 возможностей выполнения (гарантий компании) и 150 ключевых практик.
В результате аудита и аттестации компании присваивается определенный уровень, который при последующих аудитах в дальнейшем может повышаться или понижаться. Следует отметить, что каждый следующий уровень в обязательном порядке включает в себя все ключевые характеристики предыдущих. В связи с этим сертификация компании по одному из уровней предполагает безусловное выполнение всех требований более низких уровней.
К преимуществам модели SEI SW-CMM относится то, что она ориентирована на организации, занимающиеся разработкой программного обеспечения. В данной модели удалось более детально проработать требования, специфичные для процессов, связанных с разработкой ПО. По этой причине в SEI SW-CMM приведены не только требования к процессам организации, но и примеры реализации таких требований.
Основной же недостаток SW-CMM заключается в том, что модель не авторизована в качестве стандарта ни международными, ни национальными органами по стандартизации. Впрочем, CMM давно уже стала промышленным стандартом де-факто.
Структура уровней зрелости
Каждый из уровней, кроме первого, состоит из нескольких ключевых областей процесса (Key Process Area), содержащих цели (Goal), обязательства по выполнению (Commitment to Perform), осуществимость выполнения (Ability to Perform), выполняемые действия (Activity Performed), их измерение и анализ (Measurement and Analysis) и проверку внедрения (Verifying Implementation). Таким образом, СММ фактически является комплексом требований к ключевым параметрам эффективного стандартного процесса разработки ПО и способам его постоянного улучшения. Выполнение этих требований, в конечном счете, увеличивает вероятность достижения предприятием поставленных целей в области качества.
2.6 Итоги занятия
ü Ключевую роль в достижении эффективности разработки ПО играют процессы управления и корпоративная культура, поэтому прежде всего оптимизировать необходимо именно подходы к управлению.
ü Современные общепринятые подходы к управлению разработкой ПО описаны в международных и отечественных стандартах и широко освящены в литературе.
ü Заниматься организацией процесса должно руководство организации или проекта, однако знать и понимать данные подходы необходимо всем участникам рабочего процесса.
ü Существуют стандартизованные (де юре или де факто) промышленные методы, определяющие стратегию поэтапного развития организаций в области разработки ПО.
3. Разработка и управление требованиями
4 часа
Почти все прошлое занятие мы посвятили обзору основных процессов программной инженерии. В соответствии с планом нашего курса, начиная с сегодняшнего занятия и до предпоследнего, мы будем рассматривать отдельные (ключевые) процессы разработки ПО.
Одним из таких «ключевых» процессов является процесс разработки и управления требованиями. О нём и поговорим сегодня..
Одной только данной теме можно посвятить целый курс. Это было бы хорошим введением в специальность бизнес-аналитика (специалиста по разработке требований). Освоение профессии аналитика требует многолетнего опыта, особых знаний и навыков. Сегодня мы всего лишь узнаем некоторые особенности работы с программными требованиями. Этого не достаточно для организации процесса. Однако, если вас заинтересует данная область знаний, могу посоветовать отличную литературу по разработке требований к ПО.
3.1 Основы программных требований
3.1.1 Общие сведения
Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени - на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями (Орлик, 2004).
По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований (Бармин, 2011).
Разработка и управление требованиями – краеугольные камни успеха любого проекта.
Что же такое требования?
Требования – это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.
Обычно требования разделяются на требования к продукту , соответствущие свойствам продукта и требования к процессу, ограничения процесса, с помощью которого продукт будет создаваться.
3.1.2 Иерархия требований
На практике часто применяется подход, базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. Классический пример высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса (Карл Вигерс, 2014).
Рисунок 3.1 – Уровни требований по Вигерсу
На рисунке 3.1 овалы обозначают типы информации требований, а прямоугольники – документы, в которых хранится эта информация. Сплошные линии указывают, что в указанном документе хранится информация определенного типа. Пунктирная линия указывает, что информация одного типа является источником или влияет на информацию другого типа или на требование.
Бизнес-требования описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание – бизнес-цели организации или клиента, заказывающих систему.
Примеры бизнес-целей:
1. Разработать надежную платформу для семейства связанных продуктов.
2. Увеличить долю рынка в стране W c X % до Y% за Z месяцев.
3. Сократить трудозатраты на проведение научной конференции в 2 раза.
4. Привлечь участников конференции не только из Миасса, но и из других городов России.
Помимо бизнес-целей бизнес требования включают также концепцию и границы продукта (о них речь пойдет чуть дальше). Допустим, что авиакомпания хочет на 25% снизить затраты на сотрудников у стойки в аэропорту. В процессе достижения этой цели может возникнуть идея поставить терминал, который пассажиры будут использовать для самостоятельной регистрации в аэропорту.
Как правило, бизнес-требования высказывают те, кто финансируют проект, покупатели системы, управляющий реальными пользователями, отдел маркетинга или ответственный за концепцию продукта.
Карл Вигерс (Карл Вигерс, 2014) рекомендует записывать бизнес-требования в документе концепции и границ (рассмотрим ниже).
Пользовательские требования описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта. Область пользовательских требований также включает описание атрибутов или характеристик продукта, которые важны для удовлетворения пользователей. К отличным способам представления этого вида требований относятся варианты (сценарии) использования, пользовательские истории и таблицы события-отклик. Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой. Примером сценария использования является регистрация на рейс с использованием веб-сайта или терминала в аэропорту. Будучи сформулированным в виде пользовательской истории, то же пользовательское требование может звучать так: «Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет». Важно помнить, что в большинстве проектов есть несколько классов пользователей, а также других участников, потребности которых тоже надо выявить.
Функциональные требования определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований. Такое соотношение между тремя уровнями требований жизненно важно для успеха проекта. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна»: «У пассажира должна быть возможность распечатать посадочные талоны на все рейсы, на которые он зарегистрировался» или «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место».
Функциональные требования заносят в спецификации требований к ПО, где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и в связанных с проектом функциях. Этот артефакт называют по-разному: функциональная спецификация, документ требований, техническое задание и т.п. Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями.
Термин системные требования описывает требования к продукту, который содержит многие компоненты или подсистемы (в рамках системной инженерии). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди и процессы тоже часть системы, поэтому определенные системные функции могут распространяться и на людей.
Хороший пример системы – рабочее место кассира в супермаркете. В нем есть сканер штрих-кода, интегрированный с весами, а также ручной сканер штрих-кода. У кассира есть клавиатура, монитор и выдвижной ящик-касса. Есть также устройство чтения кредитных карточек и клавиатура для ввода ПИН-кода и чтения карт постоянного покупателя. На рабочем месте установлен один или несколько принтеров: для печати чека, квитанции кредитной карты и купонов на скидку. Все эти устройства взаимодействуют под управлением программного обеспечения. На основе требований к системе или продукту в целом бизнес-аналитик формулирует конкретную функциональность, которую должны поддерживать тот или иной компонент или подсистема, а также интерфейсы взаимодействия между ними.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы (рисунок 3.2).
Рисунок 3.2 – Источники бизнес-правил
Бизнес-правила не являются сами требованиями к ПО, потому что они находятся за пределами любой системы ПО. Однако они часто налагают ограничения, определяя, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда, как в случае с корпоративными политиками безопасности, бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональных требованиях. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
В дополнение к функциональным требованиям спецификация требований к ПО содержит нефункциональные.
Атрибуты качества еще называют параметрам качества, требованиями по уровню обслуживания и т.п. Они представляют собой описание различных измерений характеристик продукта, таких как производительность, доступность и переносимость, которые важны для пользователей или для разработчиков и тех, кто будет обслуживать систему.
Другие нефункциональные требования описывают внешние интерфейсы между системой и внешним миром. Речь идет о подключениях к другим программным системам, аппаратным устройствам и пользователям, а также коммуникационные интерфейсы.
Ограничения проектирования и реализации накладывают границы на возможности выбора разработчика при проектировании продукта.
Характеристика (feature) – это набор логически связанных функциональных требований, которые представляют ценность для пользователя и удовлетворяют бизнес-цели. Желательные характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки веб-браузера, средства проверки орфографии, запись макрокоманды, автоматическое обновление определений вирусов в антивирусной программе. Характеристики могут охватывать множество пользовательских требований, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач.
Обратите внимание, как много существует видов требований.
Чтобы вы лучше восприняли некоторые из различных видов требований, проанализируем проект по разработке системы регистрации участников научной конференции.
Одна из сформулированных бизнес-целей «Сократить трудозатраты на проведение конференции в 2 раза». В процессе анализа было выявлено 2 класса пользователей: «Участник конференции» и «Организатор конференции». Бизнес-правило «Участник будет допущен к выступлению, только если внесет регистрационный взнос» выявило пользовательские требования по оплате регистрационного взноса. Анализ показал, что автоматизация внесения платежей позволяет существенно уменьшить трудозатраты организаторов. Это легло в основу соответствующих вариантов использования. На основе них были сформированы функциональные требования: «Оплатить картой», «… по СМС», «оплатить наличными», «Подтвердить платеж», «Вернуть платеж» и т.д..
3.1.3 Определение концепции и границ проекта
Концепция и границы – два базовых элемента бизнес-требований.
Концепция продукта (product vision) сжато описывает конечный продукт, который достигнет заданных бизнес-целей. Этот продукт может полностью удовлетворять бизнес-требованиям или быть только частью решения. Концепция описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Она обеспечивает контекст для принятия решений на протяжении жизненного цикла продукта и выстраивает работу всех заинтересованных лиц в одном направлении.
Границы проекта (project scope) показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне.
Говоря о концепции, мы подразумеваем весь продукт. Он будет изменяться относительно медленно при определении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту или его итерации, в которых реализуются возможности продукта, как показано на рис. 3.3. Границы более динамичны, чем концепция, так как заинтересованные лица изменяют содержимое каждой версии в соответствии с ограничениями графика, бюджета, ресурсов и качества. Границы текущего выпуска должны быть четко определены, но границы будущих выпусков тем менее четко определены, чем более дальняя перспектива рассматривается.
Рисунок 3.3 – Концепция и границы продукта
3.1.4 Характеристики качественных требований:
3.1.4.1 Характеристики отдельных требований
Рассмотрим характеристики качества отдельных требований.
Полнота
Каждое требование должно содержать всю информацию, необходимую читателю, чтобы понять его. В случае функциональных требований это означает предоставление всей информации, необходимой разработчику, чтобы реализовать их (Карл Вигерс, 2014).
Корректность
Каждое требование должно точно описывать возможность, которая будет удовлетворять какую-то потребность заинтересованного лица и четко определять функциональность, которую надо построить. Для соблюдения корректности необходима связь с источниками требований, в качестве которых могут выступать пользователь, предоставивший начальное требование, высокоуровневое системное требование, вариант использования, бизнес-правило или другой документ. Низкоуровневое требование, которое конфликтует со своим родительским требованием нельзя считать корректными. Однако основная оценка здесь – за представителями пользователей (Карл Вигерс, 2014).
Осуществимость
Необходима возможность реализовать каждое требование при известных возможностях и ограничениях системы и рабочей среды, а также в рамках временных, бюджетных и ресурсных ограничений проекта. Разработчик, участвующий на этапе выявления требований может выполнить проверку на предмет того, что можно и что нельзя выполнить с технической точки зрения, а на что требуются только исключительные затраты и усилия. Если требование нужно удалить, потому что оно неосуществимо, нужно понимать его влияние на концепцию и границы проекта (Карл Вигерс, 2014).
Необходимость
Каждое требование должно отражать возможность, которая действительно предоставит заинтересованным лицам ожидаемую бизнес-пользу, выделит продукт на рынке или необходима для соблюдения внешних стандартов, политик или правил. Каждое требование должно поступать из источника, которое имеет полномочия на предоставление требований. Необходимо отследить каждое требование до бизнес-целей, которые четко определяют, почему оно необходимо. Если кто-то спросит, почему включено то или иное требование, у вас будет наготове обоснованный ответ (Карл Вигерс, 2014).
Определенные приоритеты
Назначьте приоритеты реализации каждому функциональному или пользовательскому требованию, варианту использования или функции, чтобы определить, насколько они важны для конкретного выпуска продукта. Если все требования одинаково важны, менеджеру проекта будет трудно справиться с нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки. Приоритизация требований должна выполняться коллективно, чтобы учесть интересы многих заинтересованных лиц (Карл Вигерс, 2014).
Недвусмысленность
Естественный язык несет в себе два типа двусмысленности. Первый тип можно определить самостоятельно, прикинув, нет ли более одного способа интерпретации данного требования. Другой тип двузначности поймать сложнее. Это происходит, когда разные люди читают одно требование, но интерпретируют его по-разному. Они находят требование содержательным, но оно имеет для них разное значение. Рецензирование — хороший способ обнаружить двусмысленности. Вам никогда не удастся полностью устранить двусмысленность из требований – такова природа человеческого языка. В большинстве случаев разумные люди делают правильные выводы даже из немного туманных требований. Но помощь со стороны коллег в виде рецензирования позволит избавиться от многих самых плохих проблем. (Карл Вигерс, 2014).
Проверяемость
Сможет ли тестировщик разработать тесты или применить другие приемы, чтобы установить, действительно ли в продукте реализовано каждое требование? Если требование не поддается проверке, вопрос корректности его реализации становится предметом оценки, а не объективного анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не поддаются проверке.
3.1.4.2 Характеристики наборов требований
Недостаточно получить прекрасные отдельные формулировки требований. Некоторые характеристики качества применимы только к набору требований (как к системе). Рассмотрим их поподробнее.
Полнота
Никакие требования или необходимые данные не должны быть пропущены. На практике никогда не документируются все и каждое требование к системе. Всегда есть предполагаемые и подразумеваемые требования, хотя они и более рисковые, чем явно сформулированные требования. Недостающие требования сложно обнаружить, потому что их просто нет!
Согласованность
Согласованные требования не конфликтуют с другими требованиями того же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Если не устранить несогласованность требований до начала процесса разработки, ее придется устранять разработчикам. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если будет обнаружен конфликт. Выявить несоответствия может быть сложным, если соответствующая информация хранится в разных местах, например в документе концепции и границ проекта и в средстве управления требованиями.
Способность к модификации
Требование всегда можно переписать, но нужно поддерживать историю изменений каждого требования, особенно после достижения базового соглашения о требованиях. Нужно также знать о связях и зависимостях между требованиями, чтобы можно было найти те, что должны меняться одновременно. Возможность модификации диктует, что каждое требование должно уникально именоваться и выражаться отдельно от других, чтобы на него можно было однозначно ссылаться из других требований (Карл Вигерс, 2014).
Требования должны быть поставлены под контроль конфигурационного управления, также как исходные тексты или тестовые варианты.
Для сохранения возможности модификации необходимо избегать излишней информации в требованиях. Повторяя требования в нескольких местах спецификации требований к ПО, где они уместны, вы облегчаете чтение документа, но затрудняете его поддержку. Одинаковые требования придется изменять одновременно, в противном случае возникнет несогласованность. Перекрестные ссылки на связанные между собой элементы в спецификации вам синхронизировать внесение изменений. Храня отдельные требования в средстве управления требованиями или в базе данных только один раз, вы решите проблему избыточности и упростите повторное использование требований, общих для нескольких проектов (Карл Вигерс, 2014).
| Вам никогда не удастся создать идеальную спецификацию, в которой бы у всех требований присутствовали все эти атрибуты. Однако если вы будете помнить об этих характеристиках при написании и проверке требований, вы создадите более качественную спецификацию требований, а значит, и программный продукт. |
Отслеживаемое требование можно отследить как назад, к первоисточнику, так и вперед, к производным требованиям, элементам дизайна и исходному коду, который его реализует, а также к тестам, которые позволяют проверить корректность реализации.
3.1.5 Важность взаимодействия с клиентом
Отдельно стоит отметить важность взаимодействия с представителями клиента (пользователем, заказчиком и т.д.).
Герхард, старший менеджер компании Contoso Pharmaceuticals, встретился с Синтией, начальником ИТ-отдела. «Нам нужно создать новую систему учета химических препаратов Chemical Tracking System, – начал Герхард. – Она должна обеспечить учет всех химических контейнеров на складе и в лабораториях. Если химикам понадобится новый реактив, который уже есть в компании, они смогут взять его в соответствующем отделе, не тратя деньги на заказ нового контейнера. Система сэкономит компании уйму денег. Кроме того, она позволит отделу охраны труда и техники безопасности тратить меньше сил на создание предоставляемых в контролирующие органы отчетов об использовании и утилизации химикатов. Ты сможешь создать систему к началу аудита, который у нас будет через пять месяцев?»
«Понимаю, почему этот проект важен, Герхард, – сказала Синтия. – Но прежде чем я набросаю график разработки проекта, нам потребуется собрать требования к системе».
Герхрад удивился: «Что вы имеете в виду? Я только что перечислил вам требования».
«На самом деле вы описали общие бизнес-цели проекта, – объяснила Синтия. – Бизнес-требования такого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько времени на это может потребоваться. Я хочу, чтобы мой аналитик поработал с несколькими пользователями и понял, что они ожидают от системы».
«Химики – занятые люди, – запротестовал он. – Вряд ли у них найдется время объяснять все подробности до того, как вы начнете писать программу. Не могут ли ваши люди сами определить, что создавать?»
Синтия попыталась объяснить: «Если мы сами будем пытаться угадать ожидания пользователей, ничего хорошего не выйдет. Мы – разработчики ПО, а не химики. Я по собственному опыту знаю, что, если не потратить время на изучение проблемы до начала программирования, результат не понравится никому».
«У нас нет времени на это, – настаивал Герхард. – Я описал вам мои требования. Теперь, пожалуйста, просто создайте систему. Сообщайте мне о ходе работы». (Карл Вигерс, 2014)
Такие диалоги регулярно возникают при разработке ПО. Клиенты, которым требуется новая информационная система, зачастую не понимают, насколько важно непосредственно опросить будущих пользователей и других заинтересованных лиц. Специалисты по маркетингу, разработавшие концепцию нового замечательного продукта, считают, что могут адекватно представлять интересы предполагаемых покупателей. Тем не менее, мнение непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Согласно некоторым современным методикам разработки ПО, например методики гибкого программирования (agile programming), представитель заказчика должен тесно взаимодействовать с командой разработчиков.
Без адекватного участия клиента в конце проекта неизбежно возникает разрыв ожиданий (expectation gap) – пробел между тем, что клиенту реально нужно, и тем, что предоставили разработчики, основываясь на том, что они знали в начале проекта (Карл Вигерс, 2014). Это показано на рисунке 3.3.
// Отметить важность взаимодействия с клиентом Разрыв ожиданий стр 28.
Рисунок 3.3 – Частое взаимодействие с клиентом сокращает разрыв ожиданий
Наилучший способ минимизации разрыва ожиданий – организация частых точек контакта с представителями клиента. Эти точки могут принимать форму интервью, собеседований, просмотра требований, просмотра дизайна пользовательского интерфейса, оценки прототипа и т.д. Каждая точка контакта предоставляет возможность закрыть разрыв ожиданий: создаваемое разработчиком ближе к тому, что требуется клиенту.
Естественно, что разрыв начинает снова увеличиваться сразу же после каждой точки контакта. Чем чаще такие точки, тем проще двигаться в правильном направлении. Как иллюстрируют маленькие серые треугольники на рис. 3.3, набор таких точек контакта позволяют в конце проекта получить намного меньший разрыв ожиданий и решение, которое намного лучше соответствует реальным потребностям клиента.
3.2 Роль бизнес-аналитика
Среди участников любого проекта по разработке ПО обязательно есть человек, явно или неявно выполняющий роль бизнес-аналитика. Стоит особенно отметить важность данной роли.
Бизнес-аналитик – это основное лицо, отвечающее за выявление, анализ, документирование и проверку требований к проекту. Это основной коммуникативный канал между группой клиентов и командой разработчиков (рис. 3.4), хотя, конечно, не единственный: есть и другие. Аналитик отвечает за сбор и распространение информации о продукте, а руководитель проекта – за обмен информацией о проекте.
Рисунок 3.4 – Роль бизнес-аналитика
Аналитик – это посредник в общении, проясняющий смутные представления пользователей и обращающий их в четкие спецификации, которыми руководствуется команда разработчиков продукта.
Далее рассмотрим стандартные обязанности аналитика и необходимые ему навыки.
3.2.1 Задачи аналитика
Работа аналитика начинается с определения бизнес-требований. Аналитик помогаете куратору, менеджеру продукта или менеджеру по маркетингу определить бизнес-требования к проекту. Можно разработать шаблон документа о концепции и границах и, расспросив людей, имеющих представление о концепции системы, получить у них необходимую информацию.
Спланировать подход к работе с требованиями. Аналитик должен разработать планы выявления, анализа, документирования, проверки и управления требованиям на всем протяжении проекта и тесно сотрудничать с менеджером проекта над согласованием этих планов с общим планом проекта для достижения поставленных целей.
Определить заинтересованных лиц и классы пользователей. Совместно с кураторами следует выбрать соответствующих представителей каждого класса (см. главу 6), заручиться их поддержкой и согласовать обязанности. Запишите, какого именно сотрудничества вы ожидаете от пользователей и согласуйте уровень участия каждого из них.
Выявить требования. Профессиональный аналитик помогает пользователям четко обрисовать функции системы, необходимые им для достижения бизнес-целей, используя приемы сбора информации.
Анализировать требования. Аналитик должен искать производные требования, логически проистекающие из запросов клиентов, а также невысказанные ожидания, которые, как считают клиенты, и так будут реализованы. Он использует модели требований, чтобы выявить пробелы в требованиях, конфликтующие требования и убедиться, что все требования укладываются в границы проекта.
Документировать требования. Аналитик отвечает за создание хорошо организованного и написанного документа требований, который описывает решение, удовлетворяющее потребности клиента.
Доводить требования до заинтересованных лиц. Аналитик должен эффективно довести требования до всех участников. Аналитик должен определить, полезно ли представлять требования не текстовыми средствами, например с помощью разнообразных графических нотаций, таблиц, математических уравнений, раскадровок и прототипов. Доведение требований не ограничивается распечаткой схем и развешиванием их на стенах – это постоянное взаимодействие с командой, чтобы быть уверенным в правильности понимания доводимой аналитиком информации (Карл Вигерс, 2014).
Управлять проверкой требований. Аналитик должен гарантировать, что формулировки требований отвечают всем характеристикам, перечисленным выше, и что система, созданная на основе этих требований, устроит пользователей. Аналитики – ключевые участники рецензирования документов с требованиями. Им также следует изучить архитектуру, код и варианты тестирования, спроектированные на основе спецификаций требований, и убедиться, что требования интерпретированы правильно.
Обеспечить расстановку приоритетов требований. Аналитик обеспечивает общение и взаимодействие различных классов заинтересованных лиц с разработчиками, чтобы расставить приоритеты требований в соответствии с бизнес-целями.
Управлять требованиями. Бизнес-аналитик вовлечен во все этапы разработки ПО, его задача — помочь создать, обсудить и осуществить план управления требованиями к проекту. Определив базовую версию требований для текущего выпуска продукта или итерации разработки, бизнес-аналитик переходит к отслеживанию состояния этих требований, проверкой того, как они реализуются в продукте и управлением изменениями базовых требований. Расспрашивая коллег, аналитик собирает информацию о связях требований, сопоставляет их с прочими элементами системы.
3.2.2 Навыки, необходимые аналитику
Умение слушать.
Умение опрашивать и задавать вопросы (большая часть информации о
требованиях извлекается в ходе бесед с людьми).
Способность соображать на ходу (можно создать идеальный список вопросов для интервью, но всегда приходится задавать дополнительные вопросы.)
Навыки анализа (эффективный бизнес-аналитик способен думать на нескольких уровнях абстракции и знать, когда переходить между ними).
Навыки системного мышления (ориентируясь на детали, аналитик обязан не упускать общей картины).
Навыки обучения (аналитики должны быстро усваивать новый материал, будь то новые способы работы с требованиями или особенности предметной области. И конечно же аналитик должен честно признавать, что он чего-то не знает).
Навыки создания комфортных условий общения (умение организовывать дружескую атмосферу на семинарах для уточнения требований – один из необходимых навыков аналитика).
Лидерские качества (сильный аналитик может подталкивать группу заинтересованных лиц в определенном направлении для достижения общей цели).
Умение наблюдать.
Навыки общения (как письменной, так и устной форме).
Дата: 2019-02-19, просмотров: 356.
