учебники, программирование, основы, введение в,

 

Проблемы оперирования требованиями

Требования к программному изделию — основа любого программного проекта. Они формируют как проектное задание, так и само развитие проекта. Качество создаваемого программного обеспечения во многом определяется тем, насколько оно удовлетворяет требованиям. Однако требования меняются, и эту изменчивость нужно уметь отражать в развивающейся системе. Новые требования могут противоречить ранее принятым, и потому нужно иметь критерии отбора требований для реализации. Наконец, формулировка требований чаще всего поступает к разработчикам в таком виде, который не подлежит непосредственному воплощению, а потому обычно говорят об извлечении требований из пожеланий пользователей, заказчиков, других инициаторов работ.
Традиционные методологии рассматривают определение и анализ требований как работу, которая предшествует собственно разработке и имеет целью выявление всей информации для последующего конструирования. Как следует из предыдущего обсуждения, здесь говорится о методологической стратегии определения этапов выполнения проекта для преодоления сложности разработки программного обеспечения (см. лекцию 5). И сбор требований рассматривается в качестве обособленного предварительного этапа. Утверждается, что успешность дальнейшей работы над проектом напрямую зависит от того, насколько полно и тщательно выполнен аналитический этап, что внесение корректив в зафиксированные требования приводит к необходимости повторения проектирования и всех других последующих этапов. Иными словами, изменение требований в процессе разработки рассматривается как ошибка аналитического этапа. Однако эта парадигма в большинстве случаев явно противоречит практике, что нашло отражение в известном афоризме: любая полезная программа нуждается в модификации, а бесполезная — в документации.
Более соответствуют реальному положению методологии программирования, основывающиеся на стратегии сужения задачи путем итеративного наращивания предоставляемых средств системы, в частности, на базе объектно-ориентированного проектирования. Как уже было сказано, в таких методологиях предполагается, что все этапы разработки системы рассредоточиваются по итерациям, каждая из которых завершается предъявлением продукции, реализующей не все, а только выделенные для нее требования. Соответственно, на следующих итерациях этапы анализа, конструирования и т.д. продолжаются, а не повторяют пройденное в стиле исправления ошибок. Понятно, что проблемы, связанные с определением и анализом требований, не исчезают и в этом случае, но благодаря специальной организации труда преодолевать трудности можно с меньшими затратами.
Из сказанного выше следует, что организация работы с требованиями относится к числу первоочередных задач менеджмента программных проектов. Ее решение не ограничивается предварительным периодом подготовки к проекту, а распространяется на все время жизни проекта. Как интегрирующее звено коллектива исполнителей проекта, менеджер обязан построить процесс так, чтобы в результате создаваемые продукты в полной мере отражали изменчивое движение требований к программному изделию.
Проблемы определения и анализа требований
В наиболее общем виде понятие требований сводится к следующим двум аспектам, фиксируемым для выполнения конструкторских работ:

  • средства программного изделия, в которых нуждается пользователь для решения своих проблем или достижения определенных целей;
  • характеристики программного изделия, которым должна обладать система в целом или ее компонент, чтобы удовлетворять соглашениям, спецификациям, стандартам или другой формально установленной документации.

Даже это не очень точное определение понятия требования указывает, что в реальности очень трудно исходя из аморфных и противоречивых пожеланий выявить, что конкретно и в каком виде должно быть воплощено в программном изделии. Требования первичны по отношению к программной разработке, определяют все ее развитие, являются начальным звеном в слагаемых качества конструируемых программ. А потому задача управления требованиями должна рассматриваться как одна из главных задач проекта, претендующего на реальную полезность для пользователя.
Основные проблемы управления требованиями, с которыми приходится сталкиваться при их анализе, сводятся к следующему.

  • Требования имеют много источников.

Даже если программная система разрабатывается по заказу, существует широкий круг людей, так или иначе заинтересованных в развитии проекта, — инициаторы работ (см. лекцию 1). Это, разумеется, и будущие пользователи, и заказчик, и другие лица, которые осознают как необходимость автоматизации деятельности с помощью данной системы, так и рамки, за которые выходить не стоит. Указанные и другие персоналии, в частности сами разработчики и их руководители, имеют свои, как правило, противоречивые представления о задачах проекта. Это тем более так, когда разработка претендует на удовлетворение рыночной потребности. От инициаторов работ зависит, какие работы целесообразны для реализации в проекте.

  • Требования не всегда очевидны.

Смысл утверждения в том, что инициаторы работ далеко не всегда знают, какими средствами должна обеспечиваться поддержка автоматизируемой деятельности, в каких интерфейсных формах эта поддержка должна быть выражена. Очень часто не получается четко выделить и саму автоматизируемую деятельность.

  • Требования не всегда легко выразить словами.

Интуитивное представление о том, какие средства должны предоставляться, чаще всего не формулируются явно. Приводится множество противоречивых примеров, соображений, но не описание нужных средств. В этой связи одна из главных задач анализа — представить требования в виде согласованных между заказчиком и разработчиками (одинаково понимаемых) утверждений, схем, диаграмм, моделей и т.п.

  • Существует множество различных типов требований и различных уровней их детализации.

Совокупность требований весьма многопланова и соотносится с различными аспектами проекта. Следовательно, одной из задач анализа является типизация имеющихся сведений о требованиях и распределение их по этапам и итерациям разработки.

  • Требования почти всегда взаимосвязаны и взаимозависимы, часто противоречивы.

Связанность требований обусловлена в первую очередь тем, что они относятся к автоматизации определенных видов системы деятельностей одной предметной области и наследуют ее системные связи. Кроме того, из-за автоматизации появляются и дополнительные связи. Однако пожелания к разработке даются разными людьми и в системах понятий, которые лишь косвенно соотносятся с предметной областью и поведением пользователя, решающего задачи из этой области. Не следует ожидать, что связи между требованиями будут ясно прослеживаться, что заранее будет сформулирована система объектов, которые воплощаются в программном изделии. Все, на что можно рассчитывать, получая сведения о требованиях, — это неформальное представление о том, кто будет работать с системой и зачем ему это нужно. Как следствие, в задачу анализа входит выявление взаимосвязей и взаимозависимостей, устранение противоречий, например, путем выработки рациональных компромиссов.
Следует отметить, что компромисс вовсе не означает достижение удовлетворительных результатов. Простейший, быть может, несколько утрированный, но показательный пример. Путь одно требование к интерфейсу системы утверждает, что управление должно осуществляться только с помощью мыши, а другое указывает на недопустимость иного управления, нежели посредством горячих клавиш. Неразумный компромисс в таком случае — реализация одних воздействий с помощью мыши, а других — через горячие клавиши. В результате неудовлетворенными оказываются оба инициатора работ. Правильнее было бы построить две версии системы, одна из которых удовлетворяет первому требованию, а другая — второму. Конечно, в этом случае придется специально позаботиться о согласованном ведении версий, но уже на уровне реализационных механизмов, которые пользователям не видны.
Как показывает пример, в идеале нужно стремиться не к устранению противоречий, а тому, чтобы превращать их в идеи решений. К сожалению, по разным причинам это удается далеко не всегда.

  • Требования всегда уникальны.

При формулировке требований как регламента разработки всегда нужно учитывать свойства или значения свойств, по которым они различаются: не существует двух равно значимых требований. Это не так, если рассматривать исходный материал для требований. Тем не менее не следует сразу отбрасывать некоторое новое требование только потому, что оно кажется похожим на ранее рассмотренные. Необходимо проанализировать, какие дополнительные стороны оно характеризует, и получить аргументированный ответ на вопрос, действительно ли данное требование является новым. По существу, утверждение об уникальности требований определяет то, как они должны быть представлены в проекте в результате анализа (требование к требованиям).

  • Набор требований чаще всего является компромиссом.

Это компромисс между пожеланиями инициаторов работ, направленный на максимально возможное расширение сферы применения системы. Существует много заинтересованных лиц, чьи усредненные требования должны быть удовлетворены в рамках выполняемых ими функций в прикладной области. Противоречия между требованиями, возникающие в связи с этим, ставят перед разработчиками проблемы, обычным способом преодоления которых является компромисс. В большинстве случаев компромисс можно считать лишь удовлетворительным, но никак не хорошим решением. Для технической сферы, в которой разработаны специальные методики творческого мышления , противоречивость требований всегда рассматривается как проблема, а компромисс — наихудшим выходом. Поиск решения проблем — основная цель изобретательства. Но в программировании такому подходу к задачам мешают по крайней мере три фактора:

    • отсутствие методик преобразования задач, подобных тем, которые применяются в практике изобретательства, но ориентированы на программирование как деятельность;
    • ориентация на жесткие и точные решения задач, которые якобы удовлетворяют всех, а не на действительные решения проблем, как это делается по указанным методикам;
    • преобладание специалистов с комбинационным мышлением, а не тех, кто умеет анализировать задачу на уровне метода .

Есть и субъективный, чисто экономический фактор: стоимость работы специалиста, способного к аналитическому продуцированию методов, слишком высока, чтобы их можно было привлекать всегда для выработки решений в противоречивых случаях.
Вывод из приведенного обсуждения и представленного выше примера можно сделать следующий: менеджер проекта и другие заинтересованные лица должны четко себе представлять, что компромиссы требований указывают на проблему и что если мы решаемся на них, то, скорее всего, сужаем сферу применимости разработки до тех пределов, при которых эти требования почти безразличны.

  • Требования изменяются.

Фиксируемые в заказе на разработку требования к системе, претендующей на широкую сферу применения и долгую жизнь, не являются незыблемыми. Они изменяются как из-за учета новых факторов и пожеланий, так и в связи с выявлением особенностей проекта в ходе его разработки. Следовательно, необходимо строить аналитическую работу так, чтобы иметь возможность оперативно изменять получаемые результаты и учитывать в них изменения и дополнения исходной информации.

  • Требования зависят от времени.

Это положение указывает на то, что пробное и экспериментальное знакомство с первыми получаемыми результатами (программными и документными), вероятно, повлечет за собой корректировку требований. Как следствие, нужно иметь в виду, что при выпуске очередной версии рабочих продуктов или при переходе от релиза к релизу вполне реальна ситуация проведения анализа требований вновь, а потому анализ и следующие за ним этапы должны быть организованы так, чтобы было как можно меньше переделок программ и документов.

  • Требования очень трудно оценивать.

Это многоаспектное положение указывает на то, что на вопросы значимости требования, с одной стороны, а с другой — цены его реализации зачастую не удается найти удовлетворительных ответов.
Относительно просто оцениваются время и ресурсы, необходимые для разработки программного кода, отвечающего требованию. Значительный разброс оценок может оказаться и для этих параметров. Он связан, например, с различиями квалификации сотрудников. Но это ни в какое сравнение не идет с проблемами оценки постановки задачи на программирование и встраивания кода в систему. Подобные проблемы объективно обусловлены тем, что уровень системы значительно сложнее уровня составляющих ее компонентов, а достоверность, обозримость и точность информации системного характера, как правило, недостаточны для оценочного оперирования (по крайней мере, для программирования это так).
Не лучшим образом обстоит дело и с оцениванием потребительской значимости требования. Это также связано с необходимостью действовать на системном уровне, но уже на уровне системы деятельностей потенциальных пользователей и других инициаторов работ. Простых утверждений о том, что изучение прикладной области позволит выявить актуальность и что заказчик лучше других знает реальные потребности пользователей, явно недостаточно, а исследования внешних систем деятельностей, вовлекающих в себя программный продукт, слишком дорого стоят, и не без оснований считается, что чаще всего они не окупают себя.
В результате в сфере оценки требований царят стихийность и произвол.
Список проблем, связанных с требованиями, можно продолжить, но уже и этого достаточно, чтобы понять, что необходимы специальные приемы и методы оперирования потоками требований, сопровождающих развитие проекта. Применительно к настоящей работе следует выделить то, как эти обстоятельства отражаются на моделях жизненного цикла развивающихся проектов и на менеджерской деятельности. Существенно, что учет появляющихся требований приводит к необходимости продолжения аналитических работ за пределами этапа анализа. Это можно делать по-разному, но всегда приходится выполнять так называемую трассировку требований, обсуждению которой посвящен следующий раздел.

Трассировка требований
Независимо от уровня первоначальной проработки требований к проекту не стоит думать, что требования всегда будут оставаться неизменными. Необходимо быть готовым к тому, что в любой момент могут появиться новые требования, одни старые требования изменятся, другие — отпадут. Но основная сложность управления процессом изменения требований заключается не в этом, а в том, что изменения одних требований влияют на другие, и такие влияния нужно отслеживать. Влияние изменений требований естественным образом распространяется на все рабочие продукты проекта, в том числе на программные рабочие продукты.
Любое предложение по развитию конструируемой системы может быть классифицировано как требование одного из трех видов:

  • дополняющее, которое отражает ранее не рассматривавшийся аспект системы;
  • модифицирующее, которое изменяет одно или несколько уже существующих требований;
  • отменяющее, принятие которого исключает одно или несколько ранее принятых требований.

Вид требования отражает различия анализа нового требования в контексте существующих соглашений. Целью такого анализа является поддержка целостности системы требований: нахождение противоречий между требованиями, разрешение противоречий, а при невозможности этого — достижение приемлемых компромиссов. Следует отметить, что требования могут оказаться противоречащими не только друг другу, но и уже принятым проектным решениям. В работах с меняющимися требованиями значительное место занимает отслеживание связей проекта, благодаря которому определяется деятельность, необходимая как для реализации требований, так и для распространения изменений, связанных с требованиями к проекту.
Таким образом, вопрос о том, принять или отклонить требование, является очень ответственным, зачастую влекущим за собой цепь связанных решений на всех уровнях проектирования. Чтобы сделать ответ на него обоснованным, необходимо выполнение как минимум двух условий:

  • требования должны быть заданы в виде, допускающем однозначное представление в моделях уровня анализа и конструирования, и способ такого представления должен быть унифицирован для всего проекта;
  • в проекте должны инструментально поддерживаться связи между требованиями и между требованиями и другими компонентами рабочих продуктов, и эта поддержка должна быть обеспечена.

Представление требований и пожеланий, исходящее от инициаторов работ, ни в коей мере не способствует соблюдению указанных условий. Следовательно, они должны быть трансформированы, т.е. преобразованы к виду, приспособленному для анализа. Прохождение исходного требования через последовательность трансформаций от одного представления к другому, сопровождающееся соответствующим анализом, называется трассировкой требования. Основное назначение трассировки в том, чтобы в любой момент развития проекта сохранялась целостность и непротиворечивость конструируемой системы, реализующей принятые требования.
Трассировка — основа анализа, проводимого в рамках управления изменениями требований. В первую очередь трассировке подвергаются требования, предъявленные первоначально, т.е. до того, как проект начал развиваться. Но было бы неправильно ограничиваться только ими, поскольку связи новых требований с уже сложившейся системой требований, как явные, так и обнаруживаемые в ходе анализа, также требуют соответствующего анализа и других работ, необходимых для реализации. Это, а также то, что для отбора и анализа требований, поступающих в ходе работ над проектом, появляется дополнительный критерий реализационной совместимости с принятыми требованиями, отличает трассировку новых и первоначальных требований.
В результате трансформаций строятся представления требований, вид которых приспособлен для выяснения целесообразности реализации требований. Если на некотором уровне трансформаций установлено, что данное требование отвергается, то его дальнейшие преобразования не производятся. Выделяются следующие представления требований:

  1. Исходное представление — текстовое описание пожеланий к системе, заданное в свободной форме. Это описание, в частности, может фактически содержать несколько требований, отражающих разные аспекты проекта, — элементарные составляющие требования.
  2. Унифицированные представления — исходное представление требования разбивается на элементарные составляющие, которые описываются в базовом виде, приспособленном для дальнейшего использования на всех проектных уровнях. В частности, здесь могут применяться формализованные описания элементарных составляющих требования. Во всяком случае, на уровне унифицированного представления достигается однозначность понимания требований.
  3. Типизированное представление — каждое из элементарных составляющих требования приписывается к некоторому типу. В результате формируется набор атрибутов элементарных требований и их значений. Эта информация допускает почти формальное сопоставление элементарных требований с различными требованиями, уже представленными в проекте. Сопоставление проводится на разных уровнях иерархии типов требований к системе.
  4. Модельные представления уровня анализа — образы элементарных требований как элементы аналитических моделей системы. Если следовать RUP (похоже, что сегодня это становится общепринятым), то нужно говорить о моделях ситуаций использования и динамики взаимодействий, которые применяются для оценки требований.

Подчеркнем, что в п. 4 говорится именно об элементах моделей, поскольку сами модели, как правило, отражают, пусть даже фрагментарно, сразу несколько требований. Это же относится и к последующим представлениям требований. Для трассировки важно знать, какие модели и в каких частях затрагивает то или иное требование, что позволяет отслеживать связи, возникающие при трансформации требований. Не менее существенно иметь возможность оперативно получать соответствующую информацию о текстах программ и о документации.
Если требование принимается на уровне анализа, то трассировка продолжается на следующих уровнях и можно говорить о продолжении последовательности трансформаций в реализации требования в компонентах программного изделия:

  1. Модельные представления уровня конструирования — образы элементарных требований в диаграммах классов, состояний и других компонентах архитектуры системы. На этом уровне требования принимаются или отклоняются в зависимости от их соответствия уже разработанной части проекта.
  2. Программные представления — программные рабочие продукты и их фрагменты, которые рассматриваются в качестве образов требований, представленных очередной версией системы.
  3. Документные представления — фрагменты документов, сопровождающих программный код и предназначенных для поддержки деятельности пользователей.

Схема на иллюстрирует приведенную последовательность трансформаций. Первые три представления требований изображены в виде совокупностей стрелок, которые при переходе от одного представления к другому становятся все более упорядоченными.
Иерархия типов требований представлена на рисунке следующим образом. Верхний уровень — это абстрактный тип, свойства которого присущи требованиям всех типов (они сводятся к стандартизованному набору операций объединения, пересечения атрибутов, сравнения значений атрибутов и др.). Можно сказать, что Табстр задает регламент, которого следует придерживаться при оперировании требованиями. Следующий уровень содержит четыре обязательных типа: Тэкон, Тфунк, Тинт и Тэфф, которые объединяют требования экономического характера (пределы стоимости, рентабельность и пр.), функциональные требования, требования к интерфейсу и эффективности (производительности). Многоточием обозначены типы, которые, добавляются из-за специфики проекта. Тa(a1,...,ana), Тb(b1,...,bnb), Тc(c1,...,cnc), ..., Тz(z1,...,znz) — это конкретные типы, которым приписываются элементарные составляющие требований (в скобках указаны их атрибуты).
Модельные представления уровней анализа и конструирования изображены в виде условных схем различных видов. Программные и документные представления — это текстовые файлы, пиктограммы которых показаны на рисунке.
На схеме представлен блок, обозначающий глоссарий проекта. Это очень важный инструмент согласования понятий, используемых в программной разработке. Глоссарий может пополняться на любой стадии трассировки требований, когда появляются новые понятия, смысловую трактовку которых нужно зафиксировать. Тем самым глоссарий отражает текущее понимание проекта в целом. Важно подчеркнуть, что когда разработчики не занимаются ведением глоссария, система понятий проекта все равно складывается, но стихийность этого процесса приводит к дополнительным издержкам коммуникаций сотрудников.
Приведенная схема демонстрирует, что в той или иной форме вынуждены делать разработчики для преодоления трудностей управления требованиями. Она может рассматриваться в качестве проекции жизненного цикла на задачи анализа требований. Каждое требование, поступающее для анализа, проходит вполне традиционные этапы жизненного цикла, правда, в несколько специфичном виде: учитываются только те работы, которые имеют отношение к моделированию требований. Но эта абсолютизация трассировки не является недостатком. Напротив, явное выделение задач управления требованиями уже само по себе способствует более успешному их решению.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика