Определение требований c IBM Rational Requirements ComposerИсточник: developerworks
В определении и управлении требованиями существует много проблем, связанных с трудностью получения правильных и законченных требований до окончательного выпуска программного продукта. Во многих исследованиях отмечена корреляция проблем, возникающих с требованиями, с высоким процентом неудачных завершений ИТ-проектов. Более того, в некоторых работах указывается, что от 60 до 70 процентов ИТ-проектов завершаются неудачей из-за слишком плохого сбора, анализа и управления требованиями. Отсутствие четко определенных и актуальных требований является наиболее веской причиной этих неудач. При определении требований зачастую бывает трудно выявить окончательные требования до поставки программного продукта. Обычно этот процесс организован очень неформально. Даже после того как необходимая информация была собрана, зачастую она не обновляется и не отражает изменения, происходящие в процессе разработки. Для многих организаций совершенствование процесса определения требований способно повысить показатели возврата инвестиций (ROI) даже больше, чем совершенствование процесса управления требованиями. В этом документе мы рассмотрим проблемы и преимущества, связанные с определением требований, а также опишем подход, используемый в IBM Rational Requirements Composer для решения этих проблем и достижения преимуществ. Принципы определения требований Определение требований, также называемое разработкой требований, представляет собой набор деятельностей по идентификации потребностей, выраженных многими заинтересованными в проекте лицами. Эти потребности необходимо удовлетворить в результате выполнения проекта. Будучи итеративным процессом, определение требований позволяет представителям бизнеса принимать участие в выявлении и формулировке проблем. Определение требований позволяет концептуализировать возможные решения и их воздействие, что в результате дает набор требований, формирующих направление развития проекта. С другой стороны, управление требованиями является процессом коммуникации и управления функциональными границами проекта, сопровождаемым внесением неизбежных изменений, появляющихся при работе над проектом. Действия по работе с требованиями включают сбор, хранение, отслеживание, реализацию и обновление приоритетов требований. Для формирования надежного фундамента любого проекта критически важным является определение правильного набора требований. Учитывая, что имеется очень мало информации о лучших практических методах в этой области - и лишь несколько подходящих инструментальных средств - неудивительно, что представители бизнеса часто формулируют неправильные и незаконченные требования. Подобные упущения зачастую приводят к задержкам, растрате ресурсов и разочарованию лиц, заинтересованных в результатах выполнения проекта. Для использования преимуществ процесса определения требований - и при этом смягчения рисков, вызванных стремлением удовлетворить требования как имеющихся, так и новых заинтересованных лиц - необходимо решить, как именно будет организован сбор, анализ и оценка идей для сбора требований. Решение этих проблем оказывает влияние на все артефакты и деятельности, воздействуя на информацию, коммуникации, процессы и инструментальные средства. Но основная проблема заключается в организации сотрудничества: как заставить персонал работать вместе, как убедиться в наличии единого понимания проекта, и предоставить сотруднику информацию о том, что именно и когда именно он должен делать. Обеспечить такую координацию непросто, так как многие современные организации используют глобальную цепочку поставок ПО, охватывающую различные подразделения, компании, географические зоны и временные пояса. Масштабируемость практических навыков является еще одной проблемной областью процесса определения требований. Сотрудники часто выбирают неформальные методы выявления требований и безуспешно пытаются использовать их при работе над более крупными проектами. Но то, что работает в проектах с двумя или тремя участниками, не работает в проектах с 10 исполнителями, а что работает для 10 исполнителей, не работает для 100. Кроме того, проекты, в которых большинство сотрудников работают в удаленном режиме, сильно отличаются от проектов, выполняемых коллективом с компактным размещением сотрудников. Необходимая степень документирования и потребность в инструментальных средствах может варьироваться в зависимости от этих и других факторов. Многие организации используют документы Microsoft Word, слайды Microsoft PowerPoint или диаграммы Microsoft Visio для определения требований и обсуждения концепций проекта с заинтересованными лицами. Электронные таблицы, созданные в таких приложениях, как Microsoft Excel, используются для отслеживания требований и мест их возникновения. Подобный рудиментарный подход может срабатывать в небольших проектах, но задача становится невероятно сложной по мере перехода к крупным или множественным проектам. Интеграция информации является другим ограничением, вызванным использованием таких инструментов, как текстовые процессоры, презентации и электронные таблицы. Эти инструменты могут поддерживать встраивание и обновление определенной информации, но при этом плохо справляются со сбором реляционных данных, поэтому наглядность и контекст связей быстро утрачиваются. Это ведет к потере отслеживаемости промежуточных результатов, невозможности гарантировать полное покрытие решения, и затрудняет повторное использование полученных ранее результатов. Дополнительным осложняющим фактором является то, что эти специфические инструменты не поддерживают работу в диалоговом режиме. Организации, использующие эти ручные методы, могут создавать репозитории для артефактов или поощрять использование дискуссионных форумов или электронной почты для решения проблем, но при этом все равно создается разрозненная информация, которую еще необходимо собрать и каталогизировать для получения контекста. За счет тщательного и точного определения требований организации могут получить веские преимущества, такие как сокращение объемов переработки кода, ускорение выхода продукта на рынок, повышение качества и производительности, а также общее совершенствование процесса поставки программного обеспечения. Правильно определенные требования помогут организациям снизить затраты по проекту благодаря уменьшению необходимости в переделках, и таким образом сократить время выхода продукта на рынок. Исследования показывают, что переделки могут занимать от 30 до 40 процентов от общего объема работ по проекту разработки ПО. Максимум экономии обеспечивается за счет сокращения непроизводительных затрат труда, также экономию дает заблаговременное, на несколько месяцев раньше, завершение проекта, так как это означает больше времени на получение дополнительной прибыли, рост производительности и усиление конкурентных преимуществ. Кроме того, исследования утверждают, что задержка выпуска программного продукта всего на шесть месяцев может снизить потенциал общей прибыльности вплоть до трети от прибыли, полученной в рамках жизненного цикла продукта. Напротив, ускорение выпуска продукта всего лишь на один месяц дает потенциал повышения прибыльности более чем на 10 процентов. Достоверные и точные требования могут также помочь в повышении качества. Требования часто упоминаются как одна из основных причин возникновения проблем с программным обеспечением. Если требования добавляются или изменяются на поздних стадях процесса разработки, то решение возникающих проблем становится слишком дорогостоящим. Но если требования определяются с заблаговременным привлечением заинтересованных лиц, точность и полнота собранных требований может значительно повысить качество продукта. Успешное определение требований также способствует повышению производительности труда, формируя надежный фундамент для эффективной поставки ПО и расширяя возможности для дифференциации. Дифференциация дает вам возможность быть впереди ваших конкурентов. Организации находятся под постоянно нарастающим давлением необходимости делать больше с привлечением меньших ресурсов, поэтому им следует согласовывать растущие затраты на системную поддержку с затратами на ресурсы, которые позволят продолжить внесение инноваций в процесс разработки. Успешные организации на практике обнаруживают, что оказание помощи персоналу в более эффективной организации труда в рамках бюджетных ограничений способствует оптимизации инструментальных средств и методов, позволяя взаимоувязывать процессы для достижения текущих и будущих бизнес-целей. Существуют четыре области, в которых должны действовать организации для использования преимуществ хорошо определенных требований. Пакет IBM Rational Requirements Composer поможет выполнить эту работу. Группы разработчиков должны иметь возможность использовать наилучшие методы выражения требований - методы, которые позволят представителям бизнеса и ИТ-специалистам лучше понять друг друга и содействовать определению требований. Когда заинтересованные лица имеют возможность визуально выразить требования, а разработчики могут быстро осуществлять итерации в соответствии с этими требованиями, организация становится достаточно зрелой для реализации гибкой поставки программного обеспечения. Для решения проблем, связанных с географически распределенными коллективами и различными ролями, методы сотрудничества и коммуникации следует формализовать, что придаст уверенность в том, что требования однозначно поняты, правильно проанализированы и проверены участниками проекта. Кроме того, должен существовать единый репозиторий, позволяющий объединять, размечать и группировать информацию, что облегчает ее уточнение, отслеживаемость и возможность повторного использования. В завершение следует заметить, что для обеспечения воспроизводимости в решение определения требований должны быть встроены инструкции по осуществлению процесса. Техники визуализации для преодоления языковых барьеров ПакетIBM Rational Requirements Composer предоставляет несколько техник для выявления, определения и уточнения требований: диаграммы бизнес-процессов и прецедентов использования, раскадровка и макетирование пользовательского интерфейса, а также возможности редактирования текста для сбора структурированной и неструктурированной информации. Чрезвычайно популярная и весьма эффективная техника визуализации - моделирование бизнес-процессов - интенсивно используется в управлении бизнес-процессами (BPM) и в программах непрерывного совершенствования процессов. В таких диаграммах собирается информация, детализированная на уровне выполнения задач, что помогает бизнес-профессионалам увидеть источники возникновения проблем при проведении текущих бизнес-операций, а также оценить влияние изменений на выполнение бизнес-процессов. Диаграммы процессов позволяют пользователям визуально характеризовать проблемы, анализировать корневые причины их возникновения и предлагать возможные пути решения, таким образом повышая общую отдачу от бизнес-процессов. Для помощи бизнес-аналитикам в быстрой разработке диаграмм текущих и будущих процессов, Rational Requirements Composer предлагает редактор бизнес-процессов, который использует подмножество нотации моделирования бизнес-процессов (BPMN). Пакет Rational Requirements Composer также имеет редактор диаграмм прецедентов использования, который позволяет создавать модели прецедентов. Давая четкое визуальное представление для описания и проверки того, что должна делать система, диаграммы и спецификации прецедентов особенно ценны в дискуссиях с заинтересованными лицами, т.к. предоставляют высокоуровневое описание системы, и помогают лучше понять, что именно будет делать система, не концентрируясь при этом на особенностях реализации. Более того, диаграммы прецедентов использования позволяют разработчикам выявлять взаимосвязи между участниками, действующими лицами и видами деятельности, а также отсекать дополнительные или нефункциональные требования, такие как требования производительности или нормативных документов. В современном цифровом мире значительное внимание уделяется повышению удобства работы пользователя, достигаемому оптимизацией взаимодействия между пользователями и предпочитаемым ими пользовательским интерфейсом. Для помощи в определении потребностей пользователей Rational Requirements Composer предоставляет возможности макетирования и раскадровки. Макеты, иногда называемые каркасами, являются визуальными представлениями интерфейсов, или экранов, с которыми пользователь будет взаимодействовать при выполнении определенной задачи. Раскадровки представляют собой наборы макетов или каркасов, сгруппированные в определенной последовательности для создания сценариев, основанных на серии выполняемых задач. Представляя способ, которым пользователи работают с приложением и в Web-среде, макеты и раскадровки доказали свою ценность в определении и проверке пользовательских требований. Rational Requirements Composer также поддерживает работу с текстовым форматом, давая пользователям возможность формирования документов с текстом и встроенными диаграммами, изображениями, гиперссылками и т.д., что способствует сбору данных с требованиями проекта и созданию простых для понимания спецификаций и подписанных документов. Текстовые документы в Rational Requirements Composer могут также привязываться к терминам, определяемым в словарях программного обеспечения. При определении терминов можно указать соответствующие описания, сокращения и синонимы. Так как все рассматриваемые техники предназначены для организации совместной работы, можно легко и быстро переходить от использования одной техники к другой. Вы можете создавать взаимосвязи между артефактами, созданными с использованием этих техник, а также использовать возможности IBM Rational Requirements Composer для организации работы как небольших, так и крупных коллективов, расположенных рядом или разнесенных географически. Организация сотрудничества и обмена информацией Определение требований и управление ими - это работа, выполняемая коллективно. Возможность формирования коллективной среды, в которой известны роли, цели, операции и показатели успеха, повышает вероятность успешного завершения проекта. За счет поддержки диалога, независимо от местонахождения сотрудников, вы сможете гарантировать, что при определении требований будут учтены и поняты самые различные точки зрения. Очень полезно видеть, над чем именно работают другие сотрудники и иметь возможность комментировать их работу. Также очень удобно вести историю комментариев и рабочих артефактов. Вики и другие самостоятельно регулируемые инструменты управления контентом становятся очень популярными, позволяя сообществам создавать совместно используемые массивы информации. Дискуссионные темы и чаты могут сфокусировать внимание участников на определенных вопросах и группировать пользователей вокруг некоторых страниц. При подобном подходе также создается регистрационная запись "обсуждения", что полезно для последующего использования. Для заинтересованных лиц объем информации требований может показаться слишком большим. Управление уровнем вовлеченности с помощью контроля доступа позволяет определять и управлять ролями авторов, читателей, участников и рецензентов в тех областях, где заинтересованные лица могут взаимодействовать с проектом, что гарантирует полноту использования поступающей информации, без возникновения ситуаций переполнения, аврала или непреднамеренного изменения. Rational Requirements Composer использует премиущества открытой и расширяемой архитектуры, предоставляемой решением IBM Jazz™, - платформы нового поколения для совместной и высокопроизводительной поставки программного обеспечения. Переводя на новый уровень сам способ совместной работы сотрудников над разработкой и выпуском программного обеспечения, платформа Jazz предоставляет базовую технологию, позволяющую использовать IBM Rational Requirements Composer для определения коллективных рабочих пространств для проекта, формирования совместно используемых словарей терминологии, создания комментариев по рабочим элементам и артефактам с различными уровнями детализации, разработки дискуссионных тем с сотрудником или с группой, а также просмотра истории откликов. Прозрачность и открытое ведение диалогов позволяет коллективам фокусироваться на потребностях бизнеса, заблаговременно идентифицировать конфликты и быстрее проверять требования. Но с определением требований сотрудничество не кончается. По мере выявления и изменения требований, вы можете использовать надежный инструмент IBM Rational RequisitePro® для помощи вашему глобально распределенному коллективу разработки в создании базовых линий требований, а также в отслеживании и интеграции требований с целью улучшения дизайна, повышения качества кода и сценариев тестирования. Организация сложных взаимосвязей между компонентами процесса разработки Значительный объем информации требований значительно усложняет ее использование, управление ею и проведение поиска. Но если вам также необходимо использовать структурированные и неструктурированные данные, такие как текст со сложным форматированием, изображения, диаграммы прецедентов использования и дискуссионные темы, эта задача и вовсе выглядит неразрешимой. Однако возможность выбора более широкого ракурса восприятия, благодаря ссылкам на артефакты, ассоциированным метаданным, дискуссионным темам и комментариям на уровне артефактов предоставляет необходимый связывающий контекст, помогающий понять и склеить разрозненную информацию. Rational Requirements Composer может быстро организовывать и извлекать информацию. За счет использования встроенных возможностей разметки, фильтрации и поиска, вы можете с легкостью категоризировать, организовывать, выполнять поиск и находить артефакты требований, что значительно расширяет возможности по управлению требованиями. Для облегчения отслеживания данных по требованиям, в Rational Requirements Composer можно создавать ссылки от одного элемента или артефакта к другому. Подобная навигационная функциональность предоставляет расширенный контекст для требований и значительно упрощает передачу знаний между заинтересованными лицами. Кроме того, IBM Rational Requirements Composer обладает инструментальными панелями управления как для проекта, так и для пользователя, с помощью этих панелей можно увидеть недавние комментарии, требования, артефакты и ссылки от других членов коллектива разработчиков. Это помогает концентрировать усилия вашего распределенного коллектива разработки на выполнении общей задачи. Предоставление инструкций по процессу При выборе решения определения требований организации нуждаются в инструменте, который бы поддерживал используемые ими практики. При использовании Rational Requirements Composer для определения требований вы можете использовать встроенные в ПО практики для решения типичных проблем с требованиями. Вы также можете сделать эти практики конфигурируемыми с помощью IBM Rational Method Composer, чья библиотека процессов содержит уже готовые практики, а также инструменты для создания ваших собственных практик. Кроме того, вы можете расширить ваши возможности, воспользовавшись преимуществами технологий IBM для более простой адаптации новых техник и стилей нотаций, и IBM покажет вам способ объединения этих нотаций. Например, сотрудникам, привыкшим к работе с прецедентами использования, можно предложить работу с текстом. Но этот подход должен дополняться такими визуальными техниками, как раскадровки, диаграммы бизнес-процессов и прецедентов использования. Rational Requirements Composer предоставляет контекстно-зависимые инструкции по процессу, поэтому вы можете переходить от одного редактора к другому, работая с различными функциями этого ПО. Эти практики базируются на методологии IBM Rational Unified Process (RUP) и инфраструктуре Open Unified Process (OpenUP). При использовании Rational Method Composer, вам становятся доступны возможности авторинга и доступа к библиотеке процессов, что повышает удобство использования Rational Requirements Composer, включая инструкции по процессу от IBM и OpenUP, или же вы можете создать ваш собственный набор наилучших практик. Различные техники определения требований, возможности сотрудничества, организационные возможности и инструкции по процессу, имеющиеся в Rational Requirements Composer, предназначены для помощи в определении тех областей разработки, которые могут оказывать наиболее сильное влияние на точность определения требований. Уделяя этим областям особое внимание, вы можете согласовать бизнес-цели с ИТ-возможностями, снизить необходимость в переработке и ускорить время выхода на рынок, повысить производительность и степень повторного использования, а также гарантировать, что требования по проекту имеют достаточно высокий уровень качества для успеха проекта и эффективной поставки программного обеспечения. |