Организация работ по управлению требованиями
Управление требованиями и приемы этой работы, представленные выше, являются главными условиями успешного развития большинства сложных проектов, поскольку именно это обеспечивает возможность построения системы, реально удовлетворяющей потребности пользователей с учетом внешних обстоятельств разработки (надежность заказчика, рыночная конъюнктура и др.). Однако большинство рекомендаций, которые можно дать для организации этих работ, принадлежат конкретным методологиям. Наиболее регламентировано подходят к вопросу монументальные методологии, ставящие критерии отслеживания процесса развития проекта на первое место [18]. Противоположная позиция у методологии экстремального программирования, провозгласившей «путешествие налегке» (все, что не относится к решению задач проекта в их текущем видении, не требуется учитывать, а тем более специально разрабатывать), сотрудничество с заказчиком как с членом команды (он отвечает за актуальность решаемых при производстве релизов задач), а также ряд специальных методик, делающих классический анализ требований избыточным [3].
Позиция, которая провозглашается в данном курсе по отношению к требованиям, исходит из того, что в любом успешном реальном проекте процессы, определяющие разработку программного проекта, выполняются явно или неявно, документируются в той степени, в которой это необходимо для решения задач проекта. Применительно к управлению требованиями это означает, что всегда выполняются работы, которые обеспечивают корректное решение проблем, обозначенных в лекции 12. Все это относится к внутренней организации дел проекта. Что же касается взаимоотношений с инициаторами работ, поставляющими требования, то здесь ситуация иная: необходимо придерживаться общепринятых норм общения и правил, которые без дополнительных соглашений обеспечивают бесконфликтность контактов и нормальное развитие. Они сводятся к следующему регламенту действий, сопровождающих анализ распространения изменений требований. Требования, возникающие и изменяемые в течение этапов итерации, разделяются на принимаемые и отвергаемые:
• для каждого отвергаемого требования составляется мотивированное заключение о том, почему оно не принимается (невозможно удовлетворить, нецелесообразно принимать, поскольку желаемое достижимо иным путем, запланировано в качестве перспективы, может быть принято при изменении финансовых и календарных планов и др.). Это заключение согласовывается с автором требования и с заказчиком;
• для каждого из принимаемых требований (их элементарных составляющих) определяется, когда оно может быть удовлетворено и когда его целесообразно удовлетворять: в рамках текущей итерации
или в ходе последующего итеративного наращивания. Критериями распределения требований по итерациям служат:
—приоритетность требования;
—сложность рабочих продуктов и зависимостей рабочих продуктов от требования;
• простые требования, зависимости которых незначительны и которые решено учитывать в рамках текущей итерации, реализуются
непосредственно в момент утверждения;
• сложные требования откладываются до завершения конструкторских работ данной итерации, которое рассматривается как начало
работ по учету комплекса предъявленных требований;
• требования, откладываемые до последующих итераций, реализуются согласно общему плану проекта, который корректируется с
учетом решения о реализации этих требований;
• учитывается, что ранее принятое требование может оказаться отвергнутым вследствие принятия нового требования (новых требований), а потому для такого требования необходимо подготовить
заключение об отказе от реализации. Это решение согласовывается с автором требования и с заказчиком;
• изменения планов и объемов работ, возникающие и/или планируемые в связи с управлением изменениями требований, всегда согласуются с заказчиком.
Вариант 1
1. Когда применяется прием использования метафор?
□ при выполнении оценочных работ
□ при выполнении работ этапа анализа
□ при выборе архитектуры системы
□ при разработке функциональности сценариев
□ при разработке интерфейсов
2. Какой результат достигается при осознанном применении
метафор?
• все ожидания пользователя в предлагаемых средствах оправдываются
• не появляются стихийно формируемые у пользователя мета
форы, способные исказить существо программной системы
• удовлетворение пользовательских потребностей в комфортных
ощущениях при работе с программной системой
• дополнительные требования, связанные с реализацией мета
фор, которые предъявляются к архитектуре, интерфейсу и документации программной системы
• модель деятельности-прототипа в развиваемой программной
системе
3. Что такое модель уровня конструирования?
□ описание системы в виде, пригодном для использования в качестве задания на программирование подсистем
□ описание системы в виде, пригодном для автоматизированного построения архитектурного скелета программной системы
□ разбиение разработки программной системы на части, соответствующие реализации фрагментов ее функциональности
□ модельное представление архитектуры системы в той ее части, которая реализуется в текущей итерации
□ описание системы в виде диаграмм классов, состояний и деятельностей
Вариант 2
1. Как метафоричность способствует достижению функциональной полноты и замкнутости предлагаемых средств?
• метафора служит критерием определения функционально полного набора средств
• метафора помогает оценить актуальность предлагаемых средств
• метафора позволяет определить базовые средства для реализации функционально полного набора средств
• метафора поставляет набор элементов деятельности-прообраза
для реализации их автоматизируемых аналогов
• метафора помогает проверить, все ли аспекты деятельности-
прообраза нашли отражение в функциональности
2. Что такое первичная модель?
□ модель автоматизированной деятельности некоторой предмет
ной области, зафиксированная в первом релизе разрабатываемой системы
О совокупность всех требований в их исходном представлении, указывающая на определенный аспект реального мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей
• модель, отражающая первичные нужды пользователей разрабатываемой системы
• наиболее широкое представление предметной области автоматизируемой деятельности
3. История изменения требований используется для:
□ поддержки версионности, в частности когда приходится выпускать для разных пользователей различные версии, базирующиеся на некотором общем релизе, пройденном ранее
• отката проекта к ранее пройденному состоянию в связи с
ошибками перспективного планирования, из-за желания оценить текущую ситуацию с позиций прошлого, для переоценки приоритетов и по другим причинам
• отслеживания аналогичных ситуаций, чтобы текущее планирование опиралось на полученный ранее опыт
• выработки оснований для поощрения и наказания участников
проекта
• будущих учебных целей: изучение опыта развития данного проекта даст возможность повысить качество и сократить время анализа аналогичных ситуаций в последующих проектах
Вариант 3
1. Что означает точность метафоры?
□ фиксация в ней целей, ресурсов, средств и методов как элементов пользовательской деятельности, рассматриваемой в качестве прототипа
□ построение автоматизируемой деятельности так, чтобы пользователь был в состоянии воспринимать ее как деятельность-прототип
□ явное воплощение элементов деятельности-прототипа в виде
функций, структур данных и в поведении конструируемой
программной системы
□ отображение в интерфейсе таких элементов, которые делают
его узнаваемым для пользователя
□ требуется, чтобы в метафоре отражались все аспекты деятельности-прототипа
2. Что такое уточненная первичная модель?
□ представление предметной области автоматизируемой деятельности, суженное за счет учета требований к разрабатываемой программной системе
□ модель, отражающая первичные нужды пользователей разрабатываемой системы, которые уточнены в результате анализа требований
□ совокупность всех требований в их исходном представлении,
указывающая на определенный аспект реального мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей
□ совокупность всех требований в их унифицированном и типизированном представлении, в котором ликвидированы явные противоречия, указывающая на определенный аспект реально го мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей
модель автоматизированной деятельности некоторой предметной области, зафиксированная в первом релизе разрабатываемой системы
3 Для хранения истории следует предусмотреть специальную организацию хранения требований, проектных связей, рабочих продуктов, в первую очередь обеспечивающую:
□ обратимость изменения данных
□ протоколирование появления данных
П фиксацию времени каждой модификации данных
□ авторство изменения данных
□ хранение мотиваций изменения данных