КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Организация работ по управлению требованиями
Управление требованиями и приемы этой работы, представленные выше, являются главными условиями успешного развития большинства сложных проектов, поскольку именно это обеспечивает возможность построения системы, реально удовлетворяющей потребности пользователей с учетом внешних обстоятельств разработки (надежность заказчика, рыночная конъюнктура и др.). Однако большинство рекомендаций, которые можно дать для организации этих работ, принадлежат конкретным методологиям. Наиболее регламентировано подходят к вопросу монументальные методологии, ставящие критерии отслеживания процесса развития проекта на первое место [18]. Противоположная позиция у методологии экстремального программирования, провозгласившей «путешествие налегке» (все, что не относится к решению задач проекта в их текущем видении, не требуется учитывать, а тем более специально разрабатывать), сотрудничество с заказчиком как с членом команды (он отвечает за актуальность решаемых при производстве релизов задач), а также ряд специальных методик, делающих классический анализ требований избыточным [3]. Позиция, которая провозглашается в данном курсе по отношению к требованиям, исходит из того, что в любом успешном реальном проекте процессы, определяющие разработку программного проекта, выполняются явно или неявно, документируются в той степени, в которой это необходимо для решения задач проекта. Применительно к управлению требованиями это означает, что всегда выполняются работы, которые обеспечивают корректное решение проблем, обозначенных в лекции 12. Все это относится к внутренней организации дел проекта. Что же касается взаимоотношений с инициаторами работ, поставляющими требования, то здесь ситуация иная: необходимо придерживаться общепринятых норм общения и правил, которые без дополнительных соглашений обеспечивают бесконфликтность контактов и нормальное развитие. Они сводятся к следующему регламенту действий, сопровождающих анализ распространения изменений требований. Требования, возникающие и изменяемые в течение этапов итерации, разделяются на принимаемые и отвергаемые:
• для каждого отвергаемого требования составляется мотивированное заключение о том, почему оно не принимается (невозможно удовлетворить, нецелесообразно принимать, поскольку желаемое достижимо иным путем, запланировано в качестве перспективы, может быть принято при изменении финансовых и календарных планов и др.). Это заключение согласовывается с автором требования и с заказчиком; • для каждого из принимаемых требований (их элементарных составляющих) определяется, когда оно может быть удовлетворено и когда его целесообразно удовлетворять: в рамках текущей итерации —приоритетность требования; —сложность рабочих продуктов и зависимостей рабочих продуктов от требования;
• простые требования, зависимости которых незначительны и которые решено учитывать в рамках текущей итерации, реализуются • сложные требования откладываются до завершения конструкторских работ данной итерации, которое рассматривается как начало • требования, откладываемые до последующих итераций, реализуются согласно общему плану проекта, который корректируется с • учитывается, что ранее принятое требование может оказаться отвергнутым вследствие принятия нового требования (новых требований), а потому для такого требования необходимо подготовить
• изменения планов и объемов работ, возникающие и/или планируемые в связи с управлением изменениями требований, всегда согласуются с заказчиком. Вариант 1 1. Когда применяется прием использования метафор? □ при выполнении оценочных работ □ при выполнении работ этапа анализа □ при выборе архитектуры системы □ при разработке функциональности сценариев □ при разработке интерфейсов 2. Какой результат достигается при осознанном применении • все ожидания пользователя в предлагаемых средствах оправдываются • не появляются стихийно формируемые у пользователя мета • удовлетворение пользовательских потребностей в комфортных • дополнительные требования, связанные с реализацией мета • модель деятельности-прототипа в развиваемой программной 3. Что такое модель уровня конструирования? □ описание системы в виде, пригодном для использования в качестве задания на программирование подсистем □ описание системы в виде, пригодном для автоматизированного построения архитектурного скелета программной системы □ разбиение разработки программной системы на части, соответствующие реализации фрагментов ее функциональности
□ модельное представление архитектуры системы в той ее части, которая реализуется в текущей итерации □ описание системы в виде диаграмм классов, состояний и деятельностей Вариант 2 1. Как метафоричность способствует достижению функциональной полноты и замкнутости предлагаемых средств? • метафора служит критерием определения функционально полного набора средств • метафора помогает оценить актуальность предлагаемых средств • метафора позволяет определить базовые средства для реализации функционально полного набора средств
• метафора поставляет набор элементов деятельности-прообраза • метафора помогает проверить, все ли аспекты деятельности- 2. Что такое первичная модель? □ модель автоматизированной деятельности некоторой предмет О совокупность всех требований в их исходном представлении, указывающая на определенный аспект реального мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей • модель, отражающая первичные нужды пользователей разрабатываемой системы • наиболее широкое представление предметной области автоматизируемой деятельности 3. История изменения требований используется для: □ поддержки версионности, в частности когда приходится выпускать для разных пользователей различные версии, базирующиеся на некотором общем релизе, пройденном ранее • отката проекта к ранее пройденному состоянию в связи с ошибками перспективного планирования, из-за желания оценить текущую ситуацию с позиций прошлого, для переоценки приоритетов и по другим причинам • отслеживания аналогичных ситуаций, чтобы текущее планирование опиралось на полученный ранее опыт • выработки оснований для поощрения и наказания участников • будущих учебных целей: изучение опыта развития данного проекта даст возможность повысить качество и сократить время анализа аналогичных ситуаций в последующих проектах Вариант 3 1. Что означает точность метафоры? □ фиксация в ней целей, ресурсов, средств и методов как элементов пользовательской деятельности, рассматриваемой в качестве прототипа □ построение автоматизируемой деятельности так, чтобы пользователь был в состоянии воспринимать ее как деятельность-прототип □ явное воплощение элементов деятельности-прототипа в виде
□ отображение в интерфейсе таких элементов, которые делают □ требуется, чтобы в метафоре отражались все аспекты деятельности-прототипа 2. Что такое уточненная первичная модель? □ представление предметной области автоматизируемой деятельности, суженное за счет учета требований к разрабатываемой программной системе □ модель, отражающая первичные нужды пользователей разрабатываемой системы, которые уточнены в результате анализа требований □ совокупность всех требований в их исходном представлении, □ совокупность всех требований в их унифицированном и типизированном представлении, в котором ликвидированы явные противоречия, указывающая на определенный аспект реально го мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей модель автоматизированной деятельности некоторой предметной области, зафиксированная в первом релизе разрабатываемой системы 3 Для хранения истории следует предусмотреть специальную организацию хранения требований, проектных связей, рабочих продуктов, в первую очередь обеспечивающую: □ обратимость изменения данных □ протоколирование появления данных П фиксацию времени каждой модификации данных □ авторство изменения данных □ хранение мотиваций изменения данных
Дата добавления: 2014-01-07; Просмотров: 463; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |