1

UML SysML и пр. / Re: По каким критериям стоит разбивать 1 большую use case диаграмму на несколько

« : 25 Сентября 2013, 12:23:22 »

extend и include использовать в реальной жизни вообще не рекомендуется: резко возрастает вероятность, что потребители диаграммы поймут её неправильно.
CRUD внизу притаился.

Да, наверное, Вы правы. Чаще Extend лишь путает пользователя. Но совсем без extend как-то у меня не полчилось, т.к:
1. все-таки некоторые из ВИ являются дополнительными к основным (т.е. расширяют их);
2. если все ВИ напрямую соединять с актером, то, имхо, диаграмма будет перегружена.
Но может у Вас будут альтернативные мнения.

Только непонятны связи между ролями, и человечков лучше расположить вокруг системы, а не внутри.CRUD внизу притаился.

Не совсем поняла комментарий, но слегка изменила диаграмму в целом. Так что может сейчас она будет выглядеть лучше и понятнее.
Диаграмму я прикрепила

[вложение удалено администратором] - слишком большой размер, изменил на уменьшенное

2

UML SysML и пр. / Re: По каким критериям стоит разбивать 1 большую use case диаграмму на несколько

« : 25 Сентября 2013, 12:02:12 »

Спасибо за комментарии!

Я тоже думала о том, что следует прежде всего исходить из того, кто пользователи диаграммы. В моем случае это разработчики, поэтому, вероятнее всего, удобнее будет разбить по функциональным модулям.

А что касается CRUD, то прежде всего спасибо за заметку, но на самом деле диаграмма неполная и еще дорабатывается. Так что Вы абсолютно правы, и все что касается CRUD мы добавим позже!

3

UML SysML и пр. / По каким критериям стоит разбивать 1 большую use case диаграмму на несколько

« : 24 Сентября 2013, 19:08:07 »

Добрый день, уважаемые коллеги!

Возник такой вопрос по диаграмме вариантов использования (или use case diagram): если ВИ получается очень много и показывать их на одной диаграмме неинформативно, то по какому принципу/критерию ее лучше разбить на несколько?

Мои варианты:
1. по актерам (т.е. на одной диаграмме показывать ВИ доступные только одному актеру, на второй - другому и т.д.);
2. по функциональным модулям (т.е. на одной диаграмме показыать ВИ, относящиеся к одному модулю; на второй - к другому и т.д.).

Преимущества вариантов:
- при разбивке по актерам можно понять и получить общее представление о том, какие задачи планирует выполнять тот или иной пользователь (актер) с помощью системы;
- при разбивке по модулям можно получить общее представление о конкретном модуле системы.
Таким образом, как мне кажется оба варианта имеют преимущества и выбор одного из двух лишь дело вкуса, но может у вас будут альтернатиыные мнения.

Образец неразбитой диаграммы можно посмотреть во вложении к моими сообщению

4

Идеи и мозговой штурм / Re: Тестовое задание на написание ТЗ

« : 23 Сентября 2013, 17:58:28 »

Да, действительного "злого умысла" у работодателей не было. В целом, задание на мой взгляд было очень интересным и полезным.

Основные цели были проверить:
1) умеет ли соискатель выделить требования согласно классической их градации (функциональные (бизнес, пользовательские и т.д.) и нефункцинальные (бизнес-правила, ограничения) требования);
2) знает ли основы моделирования (UML, например);
3) умеет ли соискатель "креативить" в рамках полученного задания, т.е. генерировать интересные идеи, вносить предложения в рамках того запроса, который был поставлен заказчиком.

Примерно так. На мой взгляд, вполне помогает оценить собственные силы. 

5

Идеи и мозговой штурм / Re: Тестовое задание на написание ТЗ

« : 31 Августа 2013, 22:09:57 »

В какой-то степени, я с вами согласна. Т.к. сама думала, что в этом есть риск. Если я выполняю работу (и стараюсь выполнить ее качественно), генерирую идеи и т.д. - это же интеллектуальный труд. Нет никаких гарантий, что часть ТЗ не будет использована нанимателем.
А насчет теста "на способность задавать правильные вопросы для уточнения требований" у меня есть сомнения, т.к.:
1. Девушка HR вряд ли будет выступать носителем требований (многих деталей она может и не знать, на мой взгляд).
2. Она мне ответила, что по требованиям она может ответить, но мне надо учесть, что почти все должно быть выполнено на мое усмотрение.
3. Фирма (наниматель) производит свой продукт. Думаю, что они ждут идей и креатива, и это для них важно.
Поэтому, насколько я понимаю, это все-таки тест на креативность и самостоятельность.

Я, конечно, как аналитик должна была переспросить правильность моего понимания задания, но по неопытности я этого не сделала, а срок выполнения ограничен. Но я рада, что не одна я думаю, что такого рода задания достаточно скользкие и лучше все-таки прямой диалог.

6

Идеи и мозговой штурм / Re: Тестовое задание на написание ТЗ

« : 29 Августа 2013, 23:56:04 »

Ведение блога больше похоже на задачу, чем на цель.

Цель — это то, что стоит в конце фразы
«Я, как зарегистрированный пользователь сайта, хочу вести блог, для того, чтобы … ».

Вот это «чтобы» позволит более уверенно проектировать функции блога, взаимодействие и отдельные требования.

Да уж...как такового "чтобы" в задании нет. Просто сказано, что необходима возможность пользователям вести тематические блоги для действующего сайта. Спасибо, видимо все-таки мне надо уточнять детали у HR.

7

Идеи и мозговой штурм / Re: Тестовое задание на написание ТЗ

« : 29 Августа 2013, 23:32:28 »

Я не сталкивался.

Рекомендую креатив начать с выработки вменяемых целей компонента и критериев его успеха.

Цели компонента прописаны в задании (там компонент-то всего лишь предполагает возможность ведения блога зарегестрированным пользователям). Насчет критериев задумаюсь, спасибо!

8

Идеи и мозговой штурм / Тестовое задание на написание ТЗ

« : 29 Августа 2013, 22:58:23 »

Добрый день, уважаемые форумчане.

Хотела бы посоветоваться с вами вот по какому вопросу.
Я работаю бизнес-аналитиком не так давно, но вот решила проверить свои навыки и походить по собеседованиям (чтобы, так сказать, оценить "чего стою"). Так вот на одном из собеседований мне предложили выполнить одно тестовое задание, а именно: написать ТЗ по добавлению нового компонента на действующий сайт фирмы-нанимателя.
В задании высказаны высокоуровневые пожелания заказчика к функциям компонента, а также требования к самому ТЗ. Контактирует со мной Reseacher с этой фирмы (т.е. так называемый HR). Она открыта для любых вопросов по требованиям к заданию и т.д., но, как она уточнила, практически все нужно будет сделать исключительно на мое усмотрение.
Насколько я могу судить из вышесказанного, мне требуется проявить креатив и развить высокоуровневые пожелания на свое усмотрение. Но я сомневаюсь, и возможно, все-таки мне следует все детали требований обсуждать с HR (что мне кажется несколько странным, т.к. HR - это не заказчик).

Поэтому, чтобы на первых порах, так сказать, не упасть в грязь лицом, хотела бы посоветоваться и уточнить: может кто-то уже встречался с подобного рода заданиями и мог бы поделиться опытом (например, может здесь очевидно необходимо уточнить детали задания либо наоборот, как правило, наниматели дают такого рода задания с целью проверить общий уровень аналитика по написанию ТЗ, а также его креативность и в силу того, что это тестовое задание, то стандартные процесс уточнения деталей упрощен).
Очень надеюсь, что вопрос мой не покажется глупым и найдет отклик