2015-04-30
1325
«УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ»
Одна из первых работ при проектировании ПО — сбор и упорядочение требований к нему. Требование [10] - это условие, которому должна удовлетворять система, или свойство, которым она должна обладать, чтобы удовлетворить потребность пользователя в решении некоторой задачи и удовлетворить требования контракта, стандарта или спецификации.
Спецификация требований к ПО является основным документом, который играет определяющую роль по отношению к другим элементам плана разработки ПО. Все требования, определенные в спецификации, делятся на функциональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Тем самым функциональные требования определяют поведение системы в процессе обработки информации. Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения. Можно выделить следующие типы нефункциональных требований:
· требования к применению определяют качество пользовательского интерфейса, документации и учебных курсов;
· требования к производительности накладывают ограничения на функциональные требования, задавая необходимую эффективность использования ресурсов, пропускную способность и время реакции;
· требования к реализации предписывают использовать определенные стандарты, языки программирования, операционную среду и др.;
· требования к надежности определяют допустимую частоту и воздействие сбоев, а также возможности восстановления;
· требования к интерфейсу определяют внешние сущности, с которыми может взаимодействовать система, и регламент этого взаимодействия.
Требование не должно быть проектным решением. Способ реализации требования будет определен на стадии проектирования системы. Если требование является проектным решением, то такое требование должно быть отмечено как ограничение.
К требованиям не относятся способы управления проектом, планы, методы верификации, управления конфигурацией, тестовые процедуры и т.д.
Работа с требованиями порождает целый ряд проблем:
· требования не очевидны, приходят из разных источников, их трудно сформулировать словами из-за внутренней неоднозначности языка;
· требования разнообразны по типам и детальности, могут достигать огромного количества, которое трудно контролировать;
· требования разнообразны по значимости (обязательность, риск, важность, стабильность);
· требования связаны между собой и с другими проектными данными, изменяются в жизненном цикле ПО.
Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, копий и оригиналов различных документов, отчетов существующей системы и массы других материалов. Потом их начинают упорядочивать и «очищать» от противоречий. Затем на их основе вырабатываются требования к компонентам системы - базам данных, программным и техническим средствам. При этом аналитику, проводящему обследование, приходится иметь дело с большим количеством неструктурированных, часто противоречивых требований и пожеланий, разбросанных по всевозможным соглашениям о намерениях, приложениям к договорам, протоколам рабочих совещаний, черновым материалам обследований. Без организованных усилий по регистрации и контролю за выполнением этих требований велик риск их «потерять». Кроме того, известно, что ошибки в требованиях — самые дорогостоящие и самые распространенные. Переделка ПО обычно занимает 40—50% бюджета проекта, при этом ошибки в требованиях отнимают наибольшую часть стоимости переделки ПО (>70%) и 30-40% общей стоимости бюджета проекта.
Наиболее распространенные методы проектирования ПО сосредоточены на моделировании требований с помощью различного рода диаграмм. Но в данном случае мы имеем в виду управление требованиями. Эти два понятия — моделирование и управление - не являются противоречивыми или несовместимыми.
В реальных проектах пользовательские требования зачастую должным образом не документируются; в свое оправдание разработчики говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, обычно полагаются на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе. Это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования необходимо выполнить, а какие можно отложить на более позднее время? Структурные и объектно-ориентированные методы не дают ответа на этот вопрос, поскольку они предназначены в первую очередь для понимания и объяснения требований, а не для управления ими в динамике.
Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности, поскольку сами требования и их приоритеты изменяются в течение проекта. Большинство крупных проектов включает сотни требований, а многие — даже тысячи (например, проект самолета Боинг-777, который называли мешком программ с крыльями, включал, по некоторым данным, около 300 000 требований). Кроме того, некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.
Все это подразумевает необходимость в методах и средствах для описания зависимостей между требованиями и управления большим количеством таких зависимостей. В решении данной проблемы могут частично помочь структурный анализ и объектно-ориентированный анализ, но эти методы традиционно игнорируют атрибуты требований, такие, как приоритет, стоимость, риск, план и разработчик, который занимается его реализацией. В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложениях, чтобы обеспечить хотя бы некоторую степень автоматизированной поддержки.
Управление требованиями (requirements management) представляет собой:
· систематический подход к выявлению, организации и документированию требований к системе;
· процесс, устанавливающий соглашение между заказчиками и разработчиками относительно изменения требований к системе, и обеспечивающий его выполнение.
Модель СММ характеризует деятельность по управлению требованиями следующим образом. Управление требованиями осуществляется для того, чтобы:
· достичь соглашения с заказчиком и пользователями о том, что система должна делать;
· улучшить понимание требований к системе со стороны разработчиков;
· определить границы системы;
· определить базис для планирования.
Понимание требований служит основой соглашения между заказчиком и командой разработчиков, которое является основным документом, определяющим все последующие действия. Формируется базовый уровень требований, на основе которого осуществляется управление разработкой ПО. Модель СММ предусматривает, чтобы все планы, графики и рабочие программные продукты разрабатывались и, если нужно, модифицировались в соответствии с требованиями, налагаемыми на ПО. Для осуществления данного процесса менеджеры проекта и заинтересованные лица (включая представителей заказчика и пользователей) должны документировать и пересматривать требования к ПО.
Например, в технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:
1) требования записаны в согласованном формате;
2) требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;
3) требования структурированы в соответствии со своими типами (функциональными и нефункциональными);
4) требования отслеживаются в соответствии с их типом;
5) требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.
Чтобы соответствовать первому уровню, достаточно взять стандартный тестовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие модели в жизненном цикле ПО.
Чтобы добиться осуществления целей управления требованиями и соответствия модели СММ в области управления требованиями, необходимо выделить определенные ресурсы. Нужно обучить участников разработки деятельности по управлению требованиями. Обучение должно предусматривать изложение методов и стандартов, а также способствовать формированию понимания командой разработчиков особенностей предметной области и существующих в ней проблем. Помимо обучения, организация процесса управления требованиями предусматривает:
· организацию соответствующей инфраструктуры (ответственные исполнители, инструментальные средства, средства взаимодействия (интранет/интернет, электронная почта));
· определение источников возникновения и механизмов выявления требований;
· определение процедуры обсуждения требований и правил принятия решений по ним;
· определение механизмов регистрации и обработки изменений требований и принятия решений по ним.
В процессе работы с требованиями выделяются следующие этапы:
· определение типов требований и групп участников проекта, работающих с ними;
· первичный сбор требований, их классификация и занесение в базу данных требований;
· использование базы данных требований для управления проектом.
Требования, вносимые в базу данных, обладают следующим стандартным набором атрибутов, который может быть расширен при необходимости:
· приоритет (высокий, средний, низкий);
· статус (предложено, одобрено, утверждено, реализовано, верифицировано);
· стоимость (высокая, средняя, низкая или числовое значение);
· сложность реализации (высокая, средняя, низкая);
· стабильность (высокая, средняя, низкая);
· исполнитель.
Еще одним важным аспектом управления требованиями является трассировка. Трассировка требований — это установка связей требований с другими требованиями или проектными решениями. Цель трассировки требований:
· убедиться, что все требования к системе выполнены в процессе реализации;
· убедиться, что ПО делает только то, что предполагалось;
· облегчить внесение изменений в ПО (управление изменениями).
С помощью трассировки требований можно анализировать воздействие изменения до того, как оно произведено, а также определять, на какие компоненты повлияет внесение изменения. Все принятые изменения полностью отслеживаются. Изменения считаются неотъемлемой составной частью действий по разработке ПО. Вместо «замороженных» спецификаций формируется стабильный базовый уровень требований, которые тщательно изучены, документированы и контролируются соответствующими системами, обеспечивающими управление изменениями.
В рамках процесса управления требованиями необходимо иметь возможность расстановки приоритетов требований и их изменения. Один из наиболее полезных способов расстановки приоритетов предлагает учитывать два измерения: важность и срочность, которые оцениваются по двоичной шкале. В результате получаются четыре комбинации для определения приоритетов:
· требования с высоким приоритетом - важные (пользователям нужны данные функции) и срочные (они необходимы в данной версии). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам;
· требования со средним приоритетом — важные (пользователям нужны данные функции), но не срочные (они могут подождать до следующей версии);
· требования с низким приоритетом - не важные (пользователи при необходимости могут обойтись без этих функций), и не срочные (они могут ждать сколько угодно);
· требования, кажущиеся срочными, но в действительности не являющиеся важными, вообще не заслуживают внимания и не приносят никакой ценности.
При такой расстановке приоритетов в проекте стратегия его выполнения будет заключаться в следующем: в первую очередь сосредоточиться на требованиях с высоким приоритетом, затем сосредоточиться на требованиях сосредним приоритетом, и в последнюю очередь, если останется время, заняться требованиями с низким приоритетом. Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в кризисной ситуации. Дополнительными факторами ранжирования требований по приоритетам являются:
· существенное влияние на архитектуру системы;
· рискованные, сложные для реализации или срочные функции;
· применение новой, неапробированной технологии;
· значимость в экономических процессах.
Управление требованиями относится к процессам, техническая поддержка которых не требует больших финансовых затрат, но они способны ощутимо повысить качество создаваемой системы.
1.6.
