Жизнь проекта поддерживает много людей. И состояние (качество жизни) проекта напрямую зависит от того, насколько хорошо организована коммуникация между этими людьми.
В полном жизненном цикле любого проекта есть много составляющих, но меня, на текущий момент, интересуют 2 из них - техническая реализация проекта и его поддержка.
Вопрос этот уже многими решался, и какой набор приложений может обеспечить высокое качество и удобство взаимодействия ясен. Это:
- Help Desk
- Bug Traking
- Source Repository
- Wiki
- CRM
Реализаций этих приложений огромное множество. Но появляется сложная проблема выбора:
- Каждое приложение должно быть наиболее удобно в своем классе.
- Должна быть обеспечена интеграция приложений друг с другом.
Для решения нужно точно понять, кто и как в команде будет использовать эти приложения.
Без диаграмм вариантов использования тут не обойтись :-) (для проектирования использовался бесплатный oss продукт StarUML)
Первое приближение. Определяем набор ролей в команде и взаимодействие между приложениями.
Кликните по картинке для увеличения Итак.
Интеграция приложений:
Help Desk использует CRM для получения данных об обращающемся пользователе и продукте, который использует пользователь. (CRM ID - идентификатор записи в CRM)
Так же Help Desk использует Bug Tracking для отслеживания реализаций задач. (BT ID - идентификатор задачи в Bug Tracking)
Bug Tracking, в свою очередь, использует Help Desk для отслеживания источника задач. (HD ID - идентификатор Ticket-а в Help Desk. Извиняюсь, не могу подобрать хороший русский аналог к Ticket)
Еще Bug Tracking использует Source Repository для определения, в какой версии файла исходника хранится изменение, внесенное для решения конкретной задачи. (SR ID - ссылка на версию файла исходника в Source Repository)
Роли:
Выделены основные роли. Здесь, по-моему, комментарии к диаграмме излишни. А более детальное поведение каждой из ролей будет расписано в следующих частях.
technorati tags: Life Cycle, Development Team
RSS Feed / Subscribe
6 comments:
Цитата: "Без диаграмм вариантов использования тут не обойтись :-)".
В таком контексте лучше использовать cllaboration диаграммы, а не use case. UC тут использованы некорректно.
Уважаемый Anonymous, в чем же, по во вашему, некорректность применения UseCase диаграммы в данной ситуации?
UseCase диаграмма – это самый верхний уровень, который показывает отношения между участиниками системы (помогает увидеть какие роли есть, зачем и в каких вариантах они используют систему). Главное она показывает для чего актеры и прецеденты используют друг друга. UseCase – это диаграмма абстракций, иногда совсем не обязательно что за каким-то прицендентом будет стоять реальная сущность. Причем обычно используется несколько диаграмм с разным уровнем детализации. И данная диаграмма это самый дальний взгляд.
Collaboration диаграмма – это уже очень глубокий уровень, уровень реализации. Она должна показывать взаимодействие и подчеркивать структурную организацию объектов. Она показывает как актеры используют реальную функциональность, а также, как объекты системы используют друг друга.
Этот пост и весь последующий цикл писался для того, чтобы определить
1. какие роли (=актеры) есть
2. какие функции они выполняют (причем не в терминах системы, а в терминах взаимодействия команды)
3. какие приложения нужны для улучшения взаимодействия между ролями в команде и упрощения жизни каждой отдельной роли.
Т.ч., основной вопрос диаграммы для чего – а это UseCase диаграмма.
Уважаемая Елена, некорректность заключается в следующем:
- Мы знаем, что UseCase это: 1) "sequence of actions that "scope" do ..." 2) "...that yield a value or visible result for actor". Таким образом имеем непонимание ЧТО есть например wiki как UseCase и какое value он дает.-
- Правила именования UseCases (я думаю вы знаете из) никто не отменял, но тем не менее они не используются на этой диаграмме!
- по своей сути wiki это ОБЪЕКТ с которым взаимодействует тот же User! Получается, что UseCase = Объект, что противоречит определению и природе UseCases!
- Кроме этого, Эктор есть "внешняя по онтношению к scope" сущность. Что на этой диаграмме выступает в роли scope?
Что касается collaboration. Вы пытаетесь оперировать предствалениями RUP, говоря об использовании collaboration (тем не менее игнорируете предствления RUP об использовании UseCаses). Тем не менее, если wiki и прочие системы на этой диаграмме являются по сути объектами, то имеем хороший шанс описать это именно в терминах взаимодействия тех же актеров с этими объектами (системами), даже указав то самое value, которое они получают от этих систем! Чего нельзя показать на UC диаграмме.
Далее, разберем ваши высказывания:
1) "UseCase диаграмма – это ... который показывает отношения между участиниками системы (помогает увидеть какие роли есть, зачем и в каких вариантах они используют систему). Главное она показывает для чего актеры и прецеденты используют друг друга."
Комментарий. Так все-таки "используют систему" (я понял, что вы имели ввиду scope в общем виде), или "актеры и прецеденты используют друг друга"???
2) "UseCase – это диаграмма абстракций, иногда совсем не обязательно что за каким-то прицендентом будет стоять реальная сущность".
Комментарий - за usecase вообще не стоит как таковая сущность. Это же цель эктора. Как цель (например "Получить деньги" из приславутого банкомата) может быть сущностью? Или вы о банкомате, как сущности (и деньгах)? Да и если по вашим словам сущность не стоит, то почему прецедентами являются СУЩНОСТИ (wiki и иже с ним)?
3)"2. какие функции они (роли) выполняют (причем не в терминах системы, а в терминах взаимодействия команды)
".
Комментарий - Великолепно звучит для роли (эктора) User роль "Wiki" ... ? User выполняет роль Wiki - это явно требует пояснения ибо не укладывается :-(.
Сорри, торопился сделал много ошибок:
*преславутого
*"Комментарий - Великолепно звучит для роли (эктора) User роль "Wiki" ... ? User выполняет роль Wiki - это явно требует пояснения ибо не укладывается :-(. "
Следует читать:
"Комментарий - Великолепно звучит для роли (эктора) User ФУНКЦИЯ "Wiki" ... ? User выполняет ФУНКЦИЮ Wiki - это явно требует пояснения ибо не укладывается :-(. "
Уважаемый Anonymous, повторно обращаю Ваше внимание на то, что первая диаграмма - это "взгляд издалека", примерно обозначающий роли и модули, которые будут разбираться в дальнейшем. Collaboration диаграмма тут абсолютно не к месту, поскольку детально показать информацию, передающуюся в процессе взаимодействия между присутствующими на диаграмме объектами невозможно.
Я с удовольствием продолжу наше занимательное обсуждение тонкостей использования различных диаграмм, но, во-первых, не с Anonymous-ом, а человеком, имеющим имя, во-вторых, желательно, в привате, т.к. уместность/неуместность использования UseCase диаграммы не относится к сути данного поста. Мой email в моем профиле.
P.S.: Если честно, мне очень интересно посмотреть как с Вашей точки зрения должна выглядеть collaboration диаграмма, иллюстрирующую идею поста.
Цитата "Уважаемый Anonymous, повторно обращаю Ваше внимание на то, что первая диаграмма - это "взгляд издалека", примерно обозначающий роли и модули, которые будут разбираться в дальнейшем."
Не важно насколько "издалека" этот взгляд. Важно что UC это UC, и они имеют а) правила именования!!! б) несут определенный смысл -- а именно ЦЕЛЬ, на худой конец ДЕЙСТВИЕ, вы же вкладываете в них другой смысл -- статический, подразумевая под ними ОБЪЕКТЫ, что есть некооректно.
Вы упорно игнорируете эти факты, и акцентируетесь на "взгляде издалека" и "как будет выглядеть collaboration", вместо обсуждения того корректно ли использование UC в таком виде.
Готов нарисовать collaboration, в обмен на написание сецнария для UC "wiki" :-), ОК?
Post a Comment