1
Sparx / Re: Оценка трудоемкости с использованием Use Case Metrics Enterprise Architect
« : 26 Июля 2010, 16:58:32 »
Да, про UserStory это я не подумав ... в принципе достаточно было про Use Case написать. В идеале это должно быть одно и то же, но на практике у нас не совсем так.
А разработка у нас ведется немного странным методом, что обусловлено тяжкой и разнообразной историей проекта. Я рассказывала эту грустную историю на ЛАФ: сначала был хаос (т.е. никакого проектирования, один разработчик, который написал 80 % функционала, после чего выяснилось что это немного не то что надо); потом был RUP - тяжелый такой, полновесный RUPище, за почти два года была проведена колоссальная работа по сбору требований, проектированию архитектуры, написана куча документации и... не написано ни строчки кода. Сейчас в проекте внедряется SCRUM. Собственно из скрама UserStory и всплыли.
Т.е. если полный цикл разработки рассматривать, то получается так:
есть ЗЗЛ (запросы заинтересованных лиц - высокоуровневые бизнес-требования), из которых получились Требования (Requirements) (функциональные и нефункциональные). Есть UseCase модель старой системы (которую переписываем, и функциональность которой, как я уже говорила, нужно повторить). Есть модель UseCase разрабатываемой системы (на которую страсированы все требования и usecase старой системы, это чтобы ничего не забыть при разработке). Каждый UseCase описан с помощью sub-диаграмм Activity, Class, stateMachine и т.д. По каждому UseCase пишется один или несколько TestCases. Это все ведется в EA.
Затем, на итерацию отбираются UseCases из которых составляется Sprint Backlog, в виде User Story. Иногда (для простых UseCases) 1 UseCases= 1 UserStory, иногда, если удается разбить UseCases на относительно независимые части это может быть несколько UserStory. Плюс в Backlog включаются еще некие технические задачи, которые не описаны в UseCase. Дальше все по скраму - оцениваем User Story в StoryPoints, разбиваем на задачи, которые тоже оцениваются, но уже в идеальных часах. Backlog итерации (помимо традиционной доски) ведется в TFS. Там же ведутся Bugs, Risks и другие Work Items проекта.
Т.е. все что требования, анализ и тестирование - в EA, все что разработка в TFS. По хорошему бы, конечно все в одно место перетащить, но TFS для аналитика пока слишком убог, пока там только тест-студию более-менее приличную сделали.
А разработка у нас ведется немного странным методом, что обусловлено тяжкой и разнообразной историей проекта. Я рассказывала эту грустную историю на ЛАФ: сначала был хаос (т.е. никакого проектирования, один разработчик, который написал 80 % функционала, после чего выяснилось что это немного не то что надо); потом был RUP - тяжелый такой, полновесный RUPище, за почти два года была проведена колоссальная работа по сбору требований, проектированию архитектуры, написана куча документации и... не написано ни строчки кода. Сейчас в проекте внедряется SCRUM. Собственно из скрама UserStory и всплыли.
Т.е. если полный цикл разработки рассматривать, то получается так:
есть ЗЗЛ (запросы заинтересованных лиц - высокоуровневые бизнес-требования), из которых получились Требования (Requirements) (функциональные и нефункциональные). Есть UseCase модель старой системы (которую переписываем, и функциональность которой, как я уже говорила, нужно повторить). Есть модель UseCase разрабатываемой системы (на которую страсированы все требования и usecase старой системы, это чтобы ничего не забыть при разработке). Каждый UseCase описан с помощью sub-диаграмм Activity, Class, stateMachine и т.д. По каждому UseCase пишется один или несколько TestCases. Это все ведется в EA.
Затем, на итерацию отбираются UseCases из которых составляется Sprint Backlog, в виде User Story. Иногда (для простых UseCases) 1 UseCases= 1 UserStory, иногда, если удается разбить UseCases на относительно независимые части это может быть несколько UserStory. Плюс в Backlog включаются еще некие технические задачи, которые не описаны в UseCase. Дальше все по скраму - оцениваем User Story в StoryPoints, разбиваем на задачи, которые тоже оцениваются, но уже в идеальных часах. Backlog итерации (помимо традиционной доски) ведется в TFS. Там же ведутся Bugs, Risks и другие Work Items проекта.
Т.е. все что требования, анализ и тестирование - в EA, все что разработка в TFS. По хорошему бы, конечно все в одно место перетащить, но TFS для аналитика пока слишком убог, пока там только тест-студию более-менее приличную сделали.