Вопрос 23. Управление требованиями к системе.
Как можно видеть, даже в ТЗ целая масса требований. Кроме того, в процессе работы возникает целая масса различных пожеланий, комментариев и т.п., что не находит в уже утвержденном ТЗ.
В результате возникает необходимость в специальном процессе -- управлением требований к системе. Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, а также копий и оригиналов различных документов, отчетов существующей системы? и масса других материалов. Затем их начинают упорядочивать и очищать от противоречий. Далее на их основе вырабатываются требования к компонентам системы. При этом аналитику, проводящему обслуживание, приходится иметь дело с большим количеством неструктурированных пожеланий, разбросанных по различным документам, чероновым материалам обследования. Возникает ситуация, когда аналитику просто некуда вписать обнаруженные им при проведении обследования требования. Если аналитик с какого-то момента с помощью case-средств создает формальные спецификации в виде детальных моделей, то в них тоже невозможно все отразить. Поступают следующим образом: в специально созданном хранилище документов ведут учет собираемых сведений, контролируют их разработке или же отказ.
Систематический подход к выявлению, организации и документированию требований к системе, с другой -- процесс, устанавливающий соглашение между заказчиками и разработчиками относительно изменений требований к системе и обеспечивающий его выполнение. Основные цели управления требованиями:
|
|
|
§ Достичь соглашение разработчика с заказчиком и пользователями о том, что система должна делать
§ улучшить понимание требований к системе со стороны разработчиков
§ очертить границы системы
§ определить основу для планирования
Сложность управления требованиями заключается не только в широком разбросе видов докуметов, в которых требования упоминаются, она также заключается в том, что требования зависят друг от друга, и отказ от выполнения какого-либо требования может повлечь за собой отказ от целого дерева требований, часть из которых к моменту отказа уже может быть выполнена. Принято разделять требования на три основные группы:
§ обязательные требования, которые формулируются, как необходимые требования
§ группа требований, которые являются существенными с точки зрения качества продукта, но не являются обязательными к исполнению ("следует сделать")
§ группа требований -- необязательные и несущественные требования и пожелания, которые не оказывают существенного влияния на качество продукта ("можно сделать")
|
|
|
Как правило, при ограниченных сроках разработки все требования удовлетворить не удается. Поэтому вначеле реализуются требования первой группы, затем, по возможности, наиболее важные или просто реализуемые требования из второй группы. И, только если основные работы завершены, а время еще осталось -- оставшиеся требования второй и третьей группы. Требования часто вступают в противоречия, что тоже должно находить отражение в документах. Если требования противоречат друг другу, необходимо искать между ними компромисс или баланс.
Пример: противоречие "производительность-стоимость" -- Поддержка PCI-Express 3.0, например, сейчас очень дорога, а отказ от версии 3.0, в свою очередь, смягчает требования к микросхеме.
Наиболее распространенные структурные и объектно-ориентированные методы создания программного обеспечения часто направлены на моделирование требований с помощью различных диаграмм. Однако, моделирование не тождественно управлению: это разные виды деятельности, осуществляемые в рамках одного проекта. Управление требованиями относятся к работам, техническая поддержка которых не требует больших финансовых затрат, но позволяет ощутимо повысить качество создаваемой системы.
|
|
|
Здесь, как раз-таки, кроется пример того, как с помощью вычислительной техники существенно изменить качество обработки инормации (проектирования деятельности проектной организации).
Естественно, вести такие процессы без средств вычислительной техники очень сложно. На практике такой процесс отсутствует в деятельности организации "как она есть", если он еще не автоматизирован. Когда этот процесс внедряется в модель "как должно быть", мы получаем новое качество.
Важным является учет динамической составляющей управления требованиями. Помимо зависимости, она учитывает изменение приоритетов или формулировок требований во времени. Большинство крупных проектов включают сотни или тысячи требований.
В частности, проект самолета Boing-777 включал, по некоторым данным, около 300 тыс. требований.
Требованиям характерны такие атрибуты как:
Собственно существуют уже разработанные средства по управлению требованиями.
Это в частности, например, Requisite Pro, DOORS.
Средства обладают различными возможностями в зависимости от требований разработчика. Стандартными считаются две возможности:
§ выделение требований непосредственно в документах различного формата с сохранением ссылки на исходный документ.
§ отслеживание зависимостей между требованиями.
Ссылка на источник появления требования обязательна, но сам документ-источник и конкрентый фрагмент текста, из которого выделены требования, можно не хранить.
Дата добавления: 2015-12-16; просмотров: 11; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!