Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 90
Текст из файла (страница 90)
Помимо этого должны быть определены и док)згентированле критерии приемки, т.е. тесты и измерения, которые будут использоваться для проверки того, что про~ранимое обеспечение удовлетворяет предъявляеллглле к нему требованиям. л1тобы добиться осуществления этих целей и соответствия стандарту СММ в области управления требовапнялии необходимо выделить определенные ресурсы и средства на управление требованиями. Нужно обучить членов группы программирования и др>гих участников разработки деятельности но управлению требованиями.
Обучение должно предусматривать изложение методов и стандартов, а также способствовать формирова. нию понимания командой разработчиков особенностей прикладной области и существующих в ней проблем, 422 Прилоясения Требованиями нужно управлять, и они должны служить основой для планирования деятельности по разработке программного обеспечения и создания рабочих продуктов. Изменения требований должны изучаться и вноситься в планы разработки, а их воздействие необходимо оценивать и обсуждать с заинтересованными группами.
Чтобы получить отклик на результаты разработки, а также проверить их соответствие требованиям, стандарт СММ предлагает методические указания по оценке и анализу, а также по верификации реализации. Предлагается отслеживать следующее. ° Статус каждого существующего требования ° Деятельность по внесению изменений в требования, накопительный эффект изменений ° Общее количество открытых, предложенных, принятых и включенных в базовый уровень изменений Одним иэ наиболее прогрессивных аспектов лгодели СММ является понимание того, что утлравлеллие требованиями является не просто процессом создания документа, после чего можно двигаться дальше, как часто предписывалось "водопадными" методологиями 70-х годов.
В СММ требования являются живыми сущностями, находящимися в самом центре процесса разработки приложения. Неудивительно, что управление требованиями присутствует фактически на всех уровнях модели процесса разработки и во многих его ключевых областях. Когда организация переходит на третий уровень шкалы СММ, основное внимание уделяется управлению деятельностью по разработке программного обеспечения в соответствии с определенпымн и документированными стандартнылги принципами. Ключевыми областями процесса для уровня 3 являются фокусировка организационного процесса, его определение, программа обучения, всеобъемлющее управление разработкой программного обеспечения, инженерия программного обеспечения, координация действий различных групп и тщательно организованный промежуточный контроль.
Задача инженерии программного обеспечения в том, чтобы организация прщ водила все действия по программированию согласованно и в результате могла успешно создавать высококачественные программные продукты. Согласно основополагающим принципам инженерии програмлгного обеспечения, егребования х программному обеспечению розробатмваюглсл, поддерхсиваются, документируются и вериб>икируютсл посредспюом систеиапш мского анализа требований е соотвееитвии с заранее определенныи процессом разРо бопгки пРогРоминого обеспечения (эр1 1993). Процесс анализа необходим, чтобы убедиться в том, что требования имеют смысл, четко с<>юрмулированы, являются полными и недвусмысленньпеи.
согласованы друг с другом и тестнруемы. Предлагаются различные методы анализа, в том числе имитация, моделирование, создание сценариев, а глюке функциональная и объектно-ориентированная декомпозиция. Результатом данного процесса будет более глубокое понимание требований к приложению, что должно быть отражено в пересмотренной документации требований. Кроме того, требовзпня также анализирулотся гр>ппой, отвечающей эа тестирование и приемку системы, чтобы удостовериться в воэможности их тестирования. Полученный в результате документ требований к программному обеспечению изучается и принимается заинтересованными сторонами, что призвано обеспечить отражение в требованиях позиций всех этих сторон.
Среди них — заказчики, конечные пользователи, руководство проекта, разработчики и тестологи. Чтобы можно было управлять изме- Приложение Г. Принципы управления требованиями в стандартах... 423 нениямн требований, СММ требует помещать документ требований к программному обеспечению под контроль управления конфигурацией. Еще одним важным аспектом СММ является ш>>асафоека.
Следуя стандарту СММ, все важные рабочие программные продукты должны документироваться, должно быть обеспечено ведение документации и легкий доступ к ней. Требования к программному обеспечению, технический проект, программный код и тестовые примеры трассируются к источнику, из которого они были получены, и к продуктам последующих действий по разработке.
С помощью трассировки требований можно анализировать воздействие иэ. менения до того, как оно произведено, а также определять, па какие компоненты повлияет внесение изменения. Кроме того, трассировка предлагает механизм определения адекватности тестового покрытия. Все принятые изменения полностью отслеживаются. Ведется также документация трассировки всех имеющихся требований. Чтобы определить функциональные воэмож. ности и качество программных продуктов, а также статус определенной деятельности по разработке программного обеспечения.
предлагается отслеживать следующее. ° Статус каждого существующего требования на протяжении жизненного цикла ° Деятельность по изменению существующих требований ° Распределение существукмцих требований по категориям В СММ изменения считаюотся неотъемлемой составной частью действий по разработке программного обеспечения. Вместо замороженных спецификаций создается стабильный базовый уровень требований, которые тщательно изучены, документированы и контролируются соответствующими системами, обеспечивающими управление изменениями. В частности, ниже приводятся некоторые требования СММ.
° По мере совершенствования понимания программы предлагаются, анализируются и вносятся соответствуэощие изменения в программные рабочие продукты и действия по их разработке. При необходимости внесения изменений в требования, они принимаются и вносятся до того, как производятся изменения любых рабо. чих продуктов или действий.
° Воздействие изменения должно определяться до того, как оно производится. ° Изменения обсуждаются и доводятся до сведения групп, на работу которых по. влияют данные изменения. ° Все изменения полностью отслеживаются. В результате, стандарт СММ предлагает всеобъемлющее представление действий, необходимых для повышения качества программного обеспечения и увеличения про. изводительности. Управление требованиями является неотьемлемой составной частью этого процесса, в котором требования выступают живыми сущностями и нахо. дятся в центре действий по разработке.
Выявленные требования документируются и обрабатываются с той же тщательностью, что и состоящие из программного кода ра. бочие продукты. Этот процесс позволяет команде управлять проектом и его масштабом. Наконец, контролируемое внесение изменений в требования позволяет удержать проект под контролем и гарантировать надежное повторяемое производство высококачественных программных продуктов. Хотя все изложенное выше обеспечивает важную возможность "проверить правнль.
ность" концепции управления требованиями и содержит некие высокоуровневые советы 424 Приложения по включению ориентированных на требования процессов в жизненный цикл разработки, там не говорится, как осущесииыяшь управление требованиями. Подробно деятельность по выявлению, организации, документированию и обработке требований описы. вается в данной книге, и на нее, несомненно, повлияли принципы СММ. Принципы управления требованиями в стандарте 1ЯО 9000 На протяжении последнего десятилетия многие организации во всем мире использовали серии стандартов определения качества, известные как 13О 9000, для повышения эффективности и производительности работы, а также снижения затрат. 13О 9000 был принят Европейским сообществом (в Европе стандарт получил название ЕХ29000) и стал важным фактом в международной торговле; органиэации, желающие вести бизнес в Европе, как правило, должны планета сертификат 13О 9000, Для сертификации требуется оценка "на месте" уполномоченным 13О чиновником; прошедшие оценку компании извещаются о том, что опи будут периодически подвергаться повторной оценке, чтобы подтвердить свой сертификат.
Стандарт 13О 9000 состоит иэ пяти частей. 1. 13О 9000. Руководящие > казания по выбору н применению 2. 1ЬО 9001. 1'уководящие указания по обеспечению качества при проектировании, разработке, производстве, монтаже н обслуживании 3. 13О 9002. Руководящие указания по обеспечению качества для компаний, в основном занимающихся производством 4. 13О 9003. Р>ководящие указания по обеспечению качества для компаний, в основном запинающихся дистрибуцией 5. 15О 9004.
Общее руководство качеством и элементы системы качества Один нз документов стандарта, 13О 9000-3, содержит руководящие указания по применению стандартов 130 9001 при разработке, поставке и обслуживании программного обеспечения. Часть 5.3 этого документа предписывает следующее: чяюбы эанимаюьсл (>азРабтпктй яостакйиэк долзген плита полпый набор недвусмысленных функционольных требовлхий. Этот же документ указывает, что предоставляемая поставщику (которого мы по. всюду называлн "разработчиком" ) информация должна содержать все требования по производителыюсти, безопасности, надежности„защите и соблюдению секретности, ко.
торые в совокупности определяют, является ли разработанная система приемлемой. Как н СММ, стандарты 13О 9000 долго были предметом споров, особенно в некоторых организациях СП!Л, которые беспокоились о том, что стандарты моэуг превратиться в бюрократические требования чрезмерного доюлчентирования. Мы не ставим перед собой задачу защищать или критиковать 13О 9000; как и все подобные концепции на >>эовне "здравого смысла", данный стандарт можно использовать правильно и неправильно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
