Организация работ по управлению требованиями

Управление требованиями и приемы этой работы, представленные выше, являются главными условиями успешного развития большинства сложных проектов, поскольку именно это обеспечивает возможность пост­роения системы, реально удовлетворяющей потребности пользователей с учетом внешних обстоятельств разработки (надежность заказчика, рыноч­ная конъюнктура и др.). Однако большинство рекомендаций, которые можно дать для организации этих работ, принадлежат конкретным методо­логиям. Наиболее регламентировано подходят к вопросу монументаль­ные методологии, ставящие критерии отслеживания процесса развития проекта на первое место [18]. Противоположная позиция у методологии экстремального программирования, провозгласившей «путешествие на­легке» (все, что не относится к решению задач проекта в их текущем виде­нии, не требуется учитывать, а тем более специально разрабатывать), со­трудничество с заказчиком как с членом команды (он отвечает за актуаль­ность решаемых при производстве релизов задач), а также ряд специальных методик, делающих классический анализ требований избыточным [3].

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

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

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

—приоритетность требования;

—сложность рабочих продуктов и зависимостей рабочих продук­тов от требования;

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

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

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

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

• изменения планов и объемов работ, возникающие и/или планиру­емые в связи с управлением изменениями требований, всегда сог­ласуются с заказчиком.

Вариант 1

1. Когда применяется прием использования метафор?

□ при выполнении оценочных работ

□ при выполнении работ этапа анализа

□ при выборе архитектуры системы

□ при разработке функциональности сценариев

□ при разработке интерфейсов

2. Какой результат достигается при осознанном применении
метафор?

• все ожидания пользователя в предлагаемых средствах оправ­дываются

• не появляются стихийно формируемые у пользователя мета­
форы, способные исказить существо программной системы

• удовлетворение пользовательских потребностей в комфортных
ощущениях при работе с программной системой

• дополнительные требования, связанные с реализацией мета­
фор, которые предъявляются к архитектуре, интерфейсу и до­кументации программной системы

• модель деятельности-прототипа в развиваемой программной
системе

3. Что такое модель уровня конструирования?

□ описание системы в виде, пригодном для использования в ка­честве задания на программирование подсистем

□ описание системы в виде, пригодном для автоматизированно­го построения архитектурного скелета программной системы

□ разбиение разработки программной системы на части, соот­ветствующие реализации фрагментов ее функциональности

□ модельное представление архитектуры системы в той ее части, которая реализуется в текущей итерации

□ описание системы в виде диаграмм классов, состояний и деятельностей

Вариант 2

1. Как метафоричность способствует достижению функцио­нальной полноты и замкнутости предлагаемых средств?

• метафора служит критерием определения функционально пол­ного набора средств

• метафора помогает оценить актуальность предлагаемых средств

• метафора позволяет определить базовые средства для реализа­ции функционально полного набора средств

• метафора поставляет набор элементов деятельности-прообраза
для реализации их автоматизируемых аналогов

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

2. Что такое первичная модель?

□ модель автоматизированной деятельности некоторой предмет­
ной области, зафиксированная в первом релизе разрабатывае­мой системы

О совокупность всех требований в их исходном представлении, указывающая на определенный аспект реального мира, в рам­ках которого будет разрабатываться система поддержки дея­тельности пользователей

• модель, отражающая первичные нужды пользователей разра­батываемой системы

• наиболее широкое представление предметной области автома­тизируемой деятельности

3. История изменения требований используется для:

□ поддержки версионности, в частности когда приходится выпу­скать для разных пользователей различные версии, базирую­щиеся на некотором общем релизе, пройденном ранее

• отката проекта к ранее пройденному состоянию в связи с

ошибками перспективного планирования, из-за желания оце­нить текущую ситуацию с позиций прошлого, для переоценки приоритетов и по другим причинам

• отслеживания аналогичных ситуаций, чтобы текущее плани­рование опиралось на полученный ранее опыт

• выработки оснований для поощрения и наказания участников
проекта

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

Вариант 3

1. Что означает точность метафоры?

□ фиксация в ней целей, ресурсов, средств и методов как элементов пользовательской деятельности, рассматриваемой в ка­честве прототипа

□ построение автоматизируемой деятельности так, чтобы поль­зователь был в состоянии воспринимать ее как деятельность-прототип

□ явное воплощение элементов деятельности-прототипа в виде
функций, структур данных и в поведении конструируемой
программной системы

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

□ требуется, чтобы в метафоре отражались все аспекты деятельности-прототипа

2. Что такое уточненная первичная модель?

□ представление предметной области автоматизируемой деятель­ности, суженное за счет учета требований к разрабатываемой программной системе

□ модель, отражающая первичные нужды пользователей разра­батываемой системы, которые уточнены в результате анализа требований

□ совокупность всех требований в их исходном представлении,
указывающая на определенный аспект реального мира, в рам­ках которого будет разрабатываться система поддержки дея­тельности пользователей

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

модель автоматизированной деятельности некоторой предмет­ной области, зафиксированная в первом релизе разрабатывае­мой системы

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

□ обратимость изменения данных

□ протоколирование появления данных

П фиксацию времени каждой модификации данных

□ авторство изменения данных

□ хранение мотиваций изменения данных