
- •Процесс оценки проекта на основе размерно-(функционально-)ориентированных метрик
- •Cocomo 81: принципы оценки, иерархия , типы по
- •Cocomo 2: модель композиции приложения
- •7.Cocomo 2: модель раннего этапа проектирования
- •8.Cocomo 2: модель этапа постархитектуры
- •9. Оценки на основе диаграммы вариантов использования
- •10. Case-средства: понятие, история появления и развития
- •11. Case-средства: понятие, структура и состав
- •12. Case-средства: понятие, классификация
- •Этап развитие унифицированного процесса: цели, действия, артефакты, веха
- •Этап конструирование унифицированного процесса: цели, действия, артефакты, веха
- •Этап переход унифицированного процесса: цели, действия, артефакты, веха
- •Процесс «Управление проектом»: цели и содержание, роли и артефакты
- •Процесс «Бизнес-моделирование»: цели и содержание, роли и артефакты
- •Процесс «Управление требованиями»: цели и содержание, роли и артефакты
- •22.Процесс «Анализ и проектирование»: цели и содержание, роли и артефакты
- •23.Процесс «Реализация»: цели и содержание, роли и артефакты
- •24. Процесс «Тестирование»: цели и содержание, роли и артефакты
- •25.Процесс «Развертывание»: цели и содержание, роли и артефакты
- •26. Проблемы классического похода к разработке по и причины появления гибких методологий.
- •27. Манифест и принципы гибких методологий
- •28. Преимущества и область применения гибких методологий
- •29. Экстремальное программирование: понятие, базис xp
- •33. Scrum процесс: понятие, артефакты scrum
- •34. Scrum процесс: этапы командообразования в scrum
- •35. Scrum процесс: уровни команд в scrum
- •39.Разработка, управляемая тестированием (Test Driven Development)
- •40.Разработка, управляемая поведением (Behavior Driven Development)
33. Scrum процесс: понятие, артефакты scrum
Скрам это процессный подход, используемый для комплексного управления процессом разработки продукта с начала 90-х, это подход, в рамках которого возможно применение разнообразных процессов и техник. Скрам показывает относительную эффективность способа управления продуктом и практиками разработки, и благодаря Скрамуможно их улучшить.Скрам состоит из Скрам Команд (ScrumTeams), внутри которых распределены соответствующие роли (roles), а также мероприятий (events), артефактов (artifacts) и правил (rules). Правила Скрама связывают мероприятия, роли и артефакты, регулируя отношения и взаимодействие между ними.Скрам основывается на теории управления эмпирическими процессами. Согласно эмпиризму, знание приходит с опытом и принятием решений на основании того, что является известным. Скрам использует итеративный, инкрементный подход для оптимизации прогнозируемости и управления рисками. В основе управления эмпирическими процессами лежат три главных принципа: прозрачность (transparency), проверка (inspection) и адаптация (adaptation). Прозрачность. Значительные аспекты процесса должны быть видимыми ответственным за результат. Прозрачность требует, чтобы эти аспекты определялись общими стандартами, позволяя всем наблюдателям разделять единое понимание видимого. Проверка. Использующие Скрам должны часто проверять его артефакты и прогресс продвижения к цели для своевременного обнаружения нежелательных отклонений. Однако проверка не должна быть настолько частой, чтобы мешать работе. Адаптация. Если по результатам проверки инспектор заключает, что один или более аспектов процесса отклоняется от допустимых норм и что производимый продукт будет неприемлем, инспектор должен внести изменения либо в процесс, либо в рабочие материалы. Изменения должны вноситься как можно раньше для уменьшения риска последующего отклонения от нормы. Скрам предписывает четыре формальные возможности для проверки и адаптации: планирование Спринта (SprintPlanningMeeting), ежедневный Скрам (DailyScrum), обзор Спринта (SprintReviewMeeting), ретроспектива Спринта (SprintRetrospective).
Артефакты Скрама предоставляются в качестве работы или ценности того, насколько они полезны в обеспечении прозрачности и возможностей для инспекции и адаптации. Определенные Скрамом Артефакты специально спроектированы таким образом, чтобы обеспечить максимальную ясность ключевой информации, необходимой для того, чтобы Скрам Команда достигла успеха в поставке “готового” Инкремента.Журнал Продукта – это упорядоченный список всего, что может быть нужным в продукте, он является единственным источником требований для любых изменений, которые может потребоваться внести в продукт. Ответственность за ЖП несет Владелец Продукта, включая его содержание, доступность и упорядочение. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования. ЖП является постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. ЖП существует ровно столько, сколько существует и сам продукт. ЖП содержит все свойства, функции, требования, усовершенствования и информацию по исправлению дефектов, те данные, которые и определяют изменения, которые нужно сделать в следующих выпуска продукта. Элементам ЖП должно присваиваться короткое описание, порядковый номер и оценка объемов работы. В ЖП требования часто упорядочены по ценности, риску, приоритетности и необходимости. Элементы ЖП с высоким уровнем приоритетности должны быть более понятными и содержать больше деталей, чем менее приоритетные. Требования Журнала Продукта, которые можно выполнить и “завершить” в течение одного Спринта считаются “готовыми” и “выполняемыми” для того, чтобы их внесли в план во время следующего Планирования Спринта.
Журнал Спринта – это набор элементов из Журнала Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта. Журнал Спринта – это прогноз Команды Разработчиков о функциональности, которая будет частью следующего Инкремента, а также работы, которую необходимо для этого выполнить.