Добрый день, уважаемое хабросообщество!
Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!
В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.
Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.
КИС поставляются как в коробочном варианте, который предлагает стандартные решения для автоматизации задач, так и позволяют создать необходимый набор функций самостоятельно в режиме конструктора. Кроме того, многие разработчики корпоративных систем предлагают услуги по адаптации коробочных решений к нуждам конкретного предприятия — услуги кастомизации.
Корпоративные системы являются продуктом интеллектуального труда, что позволяет им без больших материальных затрат легко тиражироваться и передаваться по каналам связи, в отличие от продуктов материального производства. Информационные продукты имеют гораздо большую возможность адаптации под нужные конкретного производства, в связи с чем встает задача получения исходной информации для разработки или адаптации информационной системы.
Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.
Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта.
По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.
Перед тем, как управлять требованиями разберемся, что такое требование и что такое управление требованиями и зачем это нужно.
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.
Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:
В соответствии со стандартом разработки требований ISO/IEC 29148, требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества)
Так же глоссарий ITILv3 определяет такое понятие, как набор требований — документ, содержащий все требования к продукту, а также к новой или измененной ИТ-услуге.
Требование должно обладать следующими характеристиками:
В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы:
В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Приведу краткие переводы основных функциональных возможностей приведенных систем, взятые с сайтов производителей.
Программное обеспечение Rational представляет лучшие практические методы определения требований и управления ими, которые обеспечивают экономию времени и средств, помогая в решении следующих задач:
Rational RequisitePro помогает проектным группам управлять требованиями, создавать качественные сценарии использования, расширять возможности отслеживания, повышать эффективность совместной работы, уменьшать потребность в доработках и повышать качество.
IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).
Первоначально DOORS разрабатывался только как средство управления требованиями в процессе разработки программного обеспечения. Однако идеи, заложенные в DOORS, оказались успешными и в настоящий момент система используется даже в кампаниях, которые не имеют отношения к разработке программного обеспечения, но вынуждены контролировать большой объем взаимосвязанной информации, например, при разработке инженерных систем.
Из Telelogic DOORS можно получить следующую информацию:
Borland Caliber RM – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц.
Borland Caliber RM обладает следующими функциональными возможностями:
За кадром остались также достаточно известные системы управления требованиями, такие как:
Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносит, а отмечает, как дублирующее. В связи с тем, что поиск схожих требований вручную является сложной и трудозатратной задачей, которая требует постоянного участия аналитика, то в процессе управления требованиями именно ее стоит автоматизировать в первую очередь.
Чтобы реализовать возможность поиска и повторного использования требований необходима методика идентификации требований, представленных текстом на естественном языке. Тогда, представив требование не только как текст, но и совокупность некоторых концептов или лингвистических переменных станет возможным не только выполнять поиск сходных требований, но и использовать повторно созданные в процессе реализации требования артефакты. Под артефактами в данном случае не стоит понимать только исходный код, который реализует требование, но и жизненный цикл, которое оно прошло, т.е. код не всегда можно использовать повторно из-за специфики задач, но можно получить консультацию у его разработчиков. При разработке нескольких продуктов для одной предметной области это становится актуальной задачей. Например, при адаптации системы электронного документооборота на нескольких предприятиях часто возникает ситуация, что на разных предприятиях разные документы проходят одни и те же маршруты в процессе жизненного цикла и функциональность, которая реализует эти маршрутры может быть использована повторно, пусть и без полного копирования.
Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А — {A, B, C, D, E}
Б — {F, B, C, D, E}
Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.
Рассчитав расстояние Хэмминга между этими двумя требованиями мы получим единицу, так как они различны только в одной позиции и, следовательно, при реализации требования Б стоит обратить внимание на требование А и его реализацию. Естественно, решение о повторном использовании принимает уже разработчик или другое лицо, принимающее решение, но уже хорошо, когда есть варианты, где можно подсмотреть реализацию.
Всем спасибо за внимание, жду комментариев.
Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!
Введение
В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.
Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.
КИС поставляются как в коробочном варианте, который предлагает стандартные решения для автоматизации задач, так и позволяют создать необходимый набор функций самостоятельно в режиме конструктора. Кроме того, многие разработчики корпоративных систем предлагают услуги по адаптации коробочных решений к нуждам конкретного предприятия — услуги кастомизации.
Корпоративные системы являются продуктом интеллектуального труда, что позволяет им без больших материальных затрат легко тиражироваться и передаваться по каналам связи, в отличие от продуктов материального производства. Информационные продукты имеют гораздо большую возможность адаптации под нужные конкретного производства, в связи с чем встает задача получения исходной информации для разработки или адаптации информационной системы.
Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.
Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта.
По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.
Управление требованиями
Перед тем, как управлять требованиями разберемся, что такое требование и что такое управление требованиями и зачем это нужно.
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.
Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:
- Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
- Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
- Документированное представление условий или возможностей для пунктов 1 и 2.
В соответствии со стандартом разработки требований ISO/IEC 29148, требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества)
Так же глоссарий ITILv3 определяет такое понятие, как набор требований — документ, содержащий все требования к продукту, а также к новой или измененной ИТ-услуге.
Требование должно обладать следующими характеристиками:
- Единичность — требование описывает одну и только одну вещь.
- Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
- Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
- Атомарность — требование нельзя разделить на более мелкие.
- Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
- Актуальность — требование не стало устаревшим с течением времени.
- Выполнимость — требование может быть реализовано в рамках проекта.
- Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
- Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
- Проверяемость — реализованность требования может быть проверена.
В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы:
- Функциональные (Functional) — реализуют саму бизнес-функцию.
- Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
- Эргономические (Usability) — к удобству работы конечных пользователей.
- Архитектурные (Architectural) — требования к архитектуре системы.
- Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
- Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.
Распространенное программное обеспечение для управления требованиями
В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Приведу краткие переводы основных функциональных возможностей приведенных систем, взятые с сайтов производителей.
IBM Rational Requisite Pro
Программное обеспечение Rational представляет лучшие практические методы определения требований и управления ими, которые обеспечивают экономию времени и средств, помогая в решении следующих задач:
- Сокращение объема доработок и ускорение выхода на рынок благодаря совместной работе с заинтересованными лицами.
- Повышение производительности труда за счет контроля над изменениями в требованиях и управлении ими.
- Минимизация расходов и рисков за счет оценки влияния происходящих изменений.
- Демонстрация соответствия требований благодаря полному отслеживанию требований.
Rational RequisitePro помогает проектным группам управлять требованиями, создавать качественные сценарии использования, расширять возможности отслеживания, повышать эффективность совместной работы, уменьшать потребность в доработках и повышать качество.
- Снижает сложность благодаря подробным представлениям с возможностью трассировки, в которых показаны отношения между родительскими и дочерними элементами.
- Снижает связанные с проектом риски, показывая требования, которые могут быть затронуты изменениями требований более низкого или более высокого уровня.
- Обеспечивает совместную работу географически распределенных рабочих групп благодаря применению полнофункционального, масштабируемого Web-интерфейса и цепочек обсуждения.
- Обеспечивает сбор и анализ сведений о требованиях с возможностью точной настройки атрибутов и фильтрации.
- Повышает производительность труда, позволяя отслеживать изменения путем сравнения версий проекта с начальными характеристиками, описанными с помощью XML.
- Обеспечивает соответствие результатов проекта поставленным задачам и бизнес-целям благодаря интеграции со средствами IBM Rational для разработки и выпуска ПО.
IBM Rational/Telelogic DOORS
IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).
Первоначально DOORS разрабатывался только как средство управления требованиями в процессе разработки программного обеспечения. Однако идеи, заложенные в DOORS, оказались успешными и в настоящий момент система используется даже в кампаниях, которые не имеют отношения к разработке программного обеспечения, но вынуждены контролировать большой объем взаимосвязанной информации, например, при разработке инженерных систем.
Из Telelogic DOORS можно получить следующую информацию:
- Статус выполнения работ по каждому требованию отдельно, а также по группе требований.
- Статус работы над всем проектом.
- Ответственное лицо для каждого требования или группы требований.
- Историю изменений требования.
- Ресурсы, которые потребуются для реализации требования еще до его внедрения в проект.
- Связь между требованиями заказчика, пунктами технического задания, программами верификации, тестирования и задачами управления проектом.
- Класс, модель или чертеж, в котором конкретное требование реализовано.
Borland Caliber RM
Borland Caliber RM – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц.
Borland Caliber RM обладает следующими функциональными возможностями:
- Централизованное хранилище требований для всех проектов, разрабатываемых IT-компанией.
- Адаптируемость — Caliber RM можно сконфигурировать для использования в любом проекте, что повышает эффективность процесса управления требованиями.
- Трассируемость требований — открытая архитектура Caliber RM позволяет связать требования с другими артефактами на всех стадиях жизненного цикла программного продукта.
- Поддержка большого числа клиентов — Caliber RM прекрасно интегрируется с такими системами разработки, как Microsoft Visual Studio, Eclipse на платформе Windows.
- Интеграция с другими продуктами Borland для поддержки полного жизненного цикла программного продукта.
Другое ПО
За кадром остались также достаточно известные системы управления требованиями, такие как:
- Sybase PowerDesigner
- OpenSource Requirements Management Tool
- RequirementsWin и другие
Новый подход к управления требованиями
Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносит, а отмечает, как дублирующее. В связи с тем, что поиск схожих требований вручную является сложной и трудозатратной задачей, которая требует постоянного участия аналитика, то в процессе управления требованиями именно ее стоит автоматизировать в первую очередь.
Чтобы реализовать возможность поиска и повторного использования требований необходима методика идентификации требований, представленных текстом на естественном языке. Тогда, представив требование не только как текст, но и совокупность некоторых концептов или лингвистических переменных станет возможным не только выполнять поиск сходных требований, но и использовать повторно созданные в процессе реализации требования артефакты. Под артефактами в данном случае не стоит понимать только исходный код, который реализует требование, но и жизненный цикл, которое оно прошло, т.е. код не всегда можно использовать повторно из-за специфики задач, но можно получить консультацию у его разработчиков. При разработке нескольких продуктов для одной предметной области это становится актуальной задачей. Например, при адаптации системы электронного документооборота на нескольких предприятиях часто возникает ситуация, что на разных предприятиях разные документы проходят одни и те же маршруты в процессе жизненного цикла и функциональность, которая реализует эти маршрутры может быть использована повторно, пусть и без полного копирования.
Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А — {A, B, C, D, E}
Б — {F, B, C, D, E}
Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.
Рассчитав расстояние Хэмминга между этими двумя требованиями мы получим единицу, так как они различны только в одной позиции и, следовательно, при реализации требования Б стоит обратить внимание на требование А и его реализацию. Естественно, решение о повторном использовании принимает уже разработчик или другое лицо, принимающее решение, но уже хорошо, когда есть варианты, где можно подсмотреть реализацию.
Всем спасибо за внимание, жду комментариев.
