Лекции разработка ПО / Texprog13
.docЛекция 14 УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К СИСТЕМЕ
Одно из первых действий при проектировании ПО - сбор и упорядочение требований к нему. Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, копий и оригиналов различных документов, отчетов существующей системы и массы других материалов. Потом их начинают упорядочивать и очищать от противоречий. Затем на их основе вырабатываются требования к компонентам системы: базам данных, программным и техническим средствам. При этом аналитику, проводящему обследование, приходится иметь дело с большим количеством неструктурированных, часто противоречивых требований и пожеланий, разбросанных по всевозможным соглашениям о намерениях, приложениям к договорам, протоколам рабочих совещаний, черновым материалам обследований. Возникает ситуация, когда ему просто некуда вписать обнаруженные им при проведение обследования требования. Если аналитик с какого-то момента начнет с помощью CASE-средств создавать формальные спецификации в виде детальных моделей, то в них тоже невозможно будет отразить все подобные требования. Даже если элемент модели может сопровождаться текстовым и графическим комментарием, это не помогает. Ведь модели обычно создаются не для повторения всех противоречий собранных требований, а с другой стороны, один документ с требованиями может воплощаться во множестве элементов разных формальных моделей. Таким образом, без организованных усилий по регистрации и контролю выполнения этих требований велик риск их потерять. Решение проблемы достаточно очевидно: в специально созданном хранилище документов следует вести учет собираемых требований и контролировать их обработку, оценку и реализацию (или отказ от реализации).
Итак, требование - это условие или характеристика, которым должна удовлетворять система. Существуют функциональные и нефункциональные требования.
Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Тем самым функциональные требования определяют поведение системы в процессе обработки информации.
Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения. Можно выделить следующие типы нефункциональных требований и их краткую характеристику:
• требования к применению - определяют качество пользовательского интерфейса, документации и учебных курсов;
• требования к производительности — накладывают ограничения на функциональные требования, задавая необходимую эффективность использования ресурсов, пропускную способность и время реакции;
• требования к реализации — предписывают использовать определенные стандарты, языки программирования, операционную среду и др.;
• требования к надежности.— обусловливают допустимую частоту и воздействие сбоев, а также возможности восстановления;
• требования к интерфейсу - определяют внешние сущности, с которыми может взаимодействовать система, и регламент этого взаимодействия.
Управление требованиями (requirements management) представляет собой:
• систематический подход к выявлению, организации и документированию требований к системе;
• процесс, устанавливающий соглашение между заказчиками и разработчиками относительно изменения требований к системе и обеспечивающий его выполнение.
Управление требованиями преследует определенные цели:
• достичь соглашения с заказчиком и пользователями о том, что система должна делать;
• улучшить понимание требований к системе со стороны разработчиков;
• очертить границы системы;
• определить базис для планирования.
Важность управления требованиями объясняется еще одним обстоятельством: почти во всех проектах, выполняющихся в экстремальных условиях, приходится устанавливать приоритеты, разделяя все требования к системе на три категории: "необходимо выполнить", "следует выполнить" и "можно выполнить". При такой расстановке приоритетов в проекте очевидная стратегия будет заключаться в следующем:
в первую очередь сконцентрироваться на требованиях, которые необходимо выполнить;
затем, если останется время, сосредоточиться на требованиях, которые следует выполнить;
и, наконец, если произойдет чудо, заняться требованиями, которые можно выполнить.
Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в крайне неприятной кризисной ситуации.
Управление требованиями относится к работам, техническая поддержка которых не требует больших финансовых затрат, но они способны ощутимо повысить качество создаваемой системы.
Наиболее распространенные структурные и объектно-ориентированные методы создания ПО направлены на моделирование требований с помощью различного рода диаграмм. Но в данном случае речь идет именно об управлении требованиями. Эти два понятия — моделирование и управление - не являются противоречивыми или несовместимыми.
В реальных проектах пользовательские требования зачастую должным образом не документируются. В свое оправдание разработчики говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, обычно полагаются на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе. Это порождает главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования "необходимо выполнить", какие "следует выполнить" и какие "можно выполнить"? Структурные и объектно-ориентированные методы не дают ответа на этот вопрос, поскольку они служат в первую очередь для понимания и объяснения требований, а не для управления ими в динамике (можно, конечно, определять приоритеты, раскрашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого).
Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности, поскольку как сами требования, так и их приоритеты изменяются в течение проекта. Большинство крупных проектов включает сотни требований, а многие— даже тысячи (например, проект самолета Боинг-777, который называли мешком программ с крыльями, включал, по некоторым данным, около 300 тыс. требований); Кроме того, некоторые требования зависят от других требований, а некоторые, в свою очередь, порождают другие требования.
Все это предполагает необходимость в методах и средствах для описания зависимостей между требованиями и для управления большим количеством таких зависимостей. В решении данной проблемы могут частично помочь структурный анализ и объектно-ориентированный анализ, но, к сожалению, до сих пор эти методы традиционно игнорировали атрибуты требований, такие, как приоритет, стоимость, риск, план, владелец и разработчик, который занимается его реализацией, В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложениях, чтобы обеспечить хотя бы некоторую степень автоматизированной поддержки.
В настоящее время появились специализированные системы управления требованиями (Requirements Management Systems), обеспечивающие комплексную и сложную поддержку управления требованиями. Некоторыми из доступных на сегодняшний день средств, являются Requisite Pro (Rational Software) и DOORS (Quality Systems and Software Inc.).
Средства управления требованиями обладают различными возможностями в зависимости от подхода разработчика. Стандартными можно считать две из них:
• выделение требований непосредственно в документах различного формата с сохранением ссылки на исходный текст;
• отслеживание зависимостей между требованиями.
Ссылка на источник появления требования обязательна. Но хранение в системе самого документа-источника и запоминание конкретного фрагмента текста, из которого получено требование, является необязательным. Причины этого очевидны: большей части документов может не существовать в электронном виде; в общем числе требований доля полученных непосредственно из электронных документов обычно очень мала.
Отслеживание зависимостей между требованиями, напротив, принципиально важно и позволяет контролировать их развитие, преобразование в проектные решения и реализацию (либо отказ или отложенную реализацию) по мере создания системы. Под развитием понимается создание одних требований на основе других. Например, из повторяющихся неструктурированных пожеланий многих пользователей можно создать структурированные по видам формальные требования к системе. При этом происходит не только их упорядочение, но и качественное изменение. Например, требование, касающееся удобства работы, может заставить сформулировать требование использования конкретного стандарта интерфейса, а из требований к удобству сопровождения могут сложиться требования к используемым средствам разработки. Естественно, такая переработка требований - это принятие решений, и необходимо указывать источник возникновения требований. Важно и то, что это неформальные преобразования, они не могут быть переложены на CASE-средства.
Еще одна важная задача, которую позволяет решить хранение данных о взаимозависимости требований - это управление изменениями требований. Зная, какие требования строились на основе измененных, можно корректно отработать внесение изменений.
Каждое требование может быть описано любым удобным набором атрибутов. Обычно помимо источника возникновения указывается обязательность и приоритет, статус. Компоновать требования в разделы можно по любым удобным критериям.
Для внедрения технологии управления требованиями необходимы в первую очередь организационные мероприятия: разработка процедуры сбора, анализа и согласования требований; определение категорий требований; назначение ответственных за их регистрацию и обработку.
Техническая сторона больших проблем вызвать не должна. Если нет возможности приобрести специализированную систему управления требованиями, основные задачи аналитики и руководители проектов могут решить, используя обычные офисные пакеты или собственные несложные программы. Такой подход вполне оправдан, так как он не вызовет несовместимости с инструментарием, используемым на последующих этапах, поскольку, как уже отмечалось, все преобразования, касающиеся требований, основаны не на формальных, а на содержательных решениях.
По существу, для описания требований уже имеется одно знакомое всем средство. Оно называется "текстовый процессор". В самом деле, начальная версия такого документа обычно исходит от пользователей, например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента. На этой ранней стадии пользователи рассматривают текстовый процессор как свое средство, а записку службы маркетинга - как свой документ. В результате они проявляют гораздо большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом продолжают использоваться аналогичные средства и документы. Таким образом, наблюдается тенденция, ведущая к документоцентринному управлению требованиями, когда средства, используемые специалистами по информационным технологиям (например, RequisitePro или DOORS), тесно интегрируются с текстовыми процессорами и документами, в которых пользователи хорошо разбираются.
В заключение остановимся на некоторых возможностях и характеристиках системы RequisitePro.
Для каждого требования в системе поддерживается предопределенный набор атрибутов, позволяющий управлять проектом на основе задания иерархий требований, установки их приоритетов, упорядочения, назначения требований конкретным исполнителям. Набор атрибутов может быть расширен пользователем по своему усмотрению, что позволяет характеризовать требования в соответствии с его представлениями.
Развитые возможности прослеживания требований позволяют визуально определять схожие требования в рамках одного проекта или нескольких и применять готовые апробированные решения в новом проекте.
Возможность задания связей между требованиями позволяет проследить, какие требования следует подвергнуть анализу (и, возможно, изменению) при изменении некоторого конкретного требования или атрибута. Тем самым упрощается процесс внесения изменений.
Для каждого требования хранится его история, помогающая отследить, какие изменения были внесены в требование, кем, когда и почему.
Ввод требований осуществляется с помощью Microsoft Word, с которым интегрировано RequisitePro. Кроме того, возможен импорт существующих требований, документированных средствами Microsoft Word. Средство Import Wizard позволяет собирать требования из разных источников: текстовых файлов, электронных таблиц и баз данных. Сами требования могут храниться в текстовых документах и базах данных MS Access, MS SQL Server или Oracle.
Имеются возможности документирования требований за счет использования стандартных или создаваемых текстовых шаблонов. В частности, предусмотрены шаблоны для выпуска документации в соответствии со стандартами IEEE, ISO, SEI СММ и RUP.
Помимо CASE-средств Rational, RequisitePro интегрируется со средствами управления конфигурацией PVCS Version Manager и Microsoft Source Safe, а также со средством управления проектами Microsoft Project. Интеграция RequisitePro версии 4.5 с CASE-средством Rational Rose 2000 позволяет расширять диаграммы вариантов использования нефункциональными требованиями к системе.