31

Системный Анализ и Требования / Re: структура документа для описания бизнес-правил и их реализации в системе

« : 05 Декабря 2012, 11:23:17 »

Да, мне про реестр тоже интересно:)

Обычный файл Excel, как вариант.

32

Системный Анализ и Требования / Re: Использование ВИ и функциональных требований вместе/раздельно или как?

« : 04 Декабря 2012, 11:46:46 »

В книге "Путь аналитика", насколько я помню, предлагается способ:

1. Высокоуровневые требования.
2. Варианты использования, поясняющие эти требования.

Именно по такому принципу я в последнее время и формирую спецификации.

33

Системный Анализ и Требования / Re: Спецификация технических требований к автоматизации бизнес-процесса

« : 22 Ноября 2012, 17:53:56 »

Добрый день, уважаемые коллеги!
Подскажите пожалуйста. с помощью какого стандарта или примера можно составить спецификацию технических требований к автоматизации БП.
На входе есть БП, для него нужно составить СТТ, так чтобы было понятно и удобно читать заказчику (заказчик не технический специалист) и разработчику. Причем упор здесь на заказчика. Варианты: ТЗ, спецификация требований IEEE не принимаются . Заранее спасибо за информацию.

Наверное Вам подойдут сценарии использования. Результат -- описание алгоритма, понятное и заказчику, и разработчику. Шаблоны есть и на uml2, и в интернете.

34

Конференции Семинары и Тренинги / Re: МСК, 24 ноября, суббота, Введение в профессию системного аналитика

« : 20 Ноября 2012, 16:32:49 »

С удовольствием бы почитал отзывы с "типичными днями аналитика"

35

Системный Анализ и Требования / Re: Проблема с документированием

« : 19 Ноября 2012, 14:22:20 »

В своем ответе, конечно же, я имел в виду отсутствие СУТ.

36

Системный Анализ и Требования / Re: Проблема с документированием

« : 16 Ноября 2012, 17:57:59 »

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

А вообще, я бы сначала настроил правильное именование документов.

Например,
ТЗ 00 -- Общее ТЗ на всю систему
ТЗ 01 -- ЧТЗ [Название модуля]
ТЗ 02 -- ЧТЗ [Название модуля]

Документы с требованиями на доработку:

ТЗ 011 -- [Название дорабатываемого функционала в базовом модуле 1]
ТЗ 021 -- [Название дорабатываемого функционала в базовом модуле 2]
...

37

Для всех / Re: обратная связь по документации с помощью опросника

« : 01 Октября 2012, 15:24:52 »

Анна, я думаю, что такую обратную связь наверное проще получить в неформальном разговоре с заказчиком документа. Сам обеспокоен решением подобной задачи.

38

Обучение / Re: Учебные кейсы

« : 21 Сентября 2012, 11:20:41 »

Да кстати вот тоже тема - что-то прикольное по мозговому штурму (стоит дать тему и команды должны что-то там напридумывать) + выделяются наблюдатели которые должны следить и фиксировать нарушение регламента?

Хотел написать, как только обсуждение открылось, но потом передумал, т.к. посчитал, что возможно информация будет не по теме. Но раз Эдуард упомянул мозговой штурм, приведу интересную ссылку: http://www.4ernov.ru/2012/03/brainwriting-108-30.html

Недавно Алексей Киселев подробно писал об этой технике в своем блоге.

Сам хочу как-нибудь применить этот метод на практике.

39

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 15:45:37 »

Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..


В общем случае получается что приходиться создавать столько виртуальных обобщенных экторов сколько есть сочетаний между конкретными экторами.
Это выглядит на диаграмме очень грустно и печально (

Моё мнение. Я бы в таком случае классифицировал диаграммы по типам пользователей. Для каждого пользователя создал бы отдельную ДВИ -- было бы проще.

Но вариант с общей ДВИ и бизнес-правилами, связанными с конкретной ролью, мне тоже нравится.

40

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 15:41:51 »

Тогда добавляйте БПр в сценарии ВИ и там это описывайте, даете ссылку в шаге раширения на это БПр.

Кстати, да. О том, как можно это делать, можно почитать тут (некоторое время назад я занимался переводом англоязычной статьи).

41

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 13 Сентября 2012, 15:26:00 »

Странно, я недели две назад смотрел - работала. М.б. у ФрендФ поменялась ссылка на фид?
Напиши Грише плиз.

Да, работал. По ходу, такая проблема со всеми аккаунтами на ФФ. Посмотрел свой аккаунт -- тоже недоступен.

Григорию напишу.

42

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 13 Сентября 2012, 12:14:09 »

Коллеги, лента с недавних пор перестала работать: http://www.uml2.ru/index.php?option=com_content&task=view&id=438&Itemid=92. Кто-нибудь знает, в чем причина? Данные брались из френдфида uml2.

43

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 12:12:17 »

Здравствуйте.

Насколько я помню (читал в одной из статей блога Александра Шамрай, потом сделал краткую выжимку: http://it-analysis.blogspot.com/2011/03/blog-post_24.html), операции с данными (СЧОУ -- создание, чтение, обновление, удаление -- сюда можно и отнести редактирование) не рекомендуется выносить в виде отдельных UC.

Я бы порекомендовал выделять в виде UC только действительно важные цели пользователя, которые принесут ему ощутимую пользу. Все остальное опишите в виде текстовых требований, привязанных к конкретному варианту использования.

44

IDEF ARIS BPMN и пр. / Re: BPMN - Материалы по BPMN

« : 11 Сентября 2012, 11:58:23 »

Александр, посмотри вложения. Может это именно то, что нужно.

45

Консалтинг и Внедрение / Re: Системы workflow automation

« : 06 Сентября 2012, 18:59:10 »

Эдуард, мне кажется Вы имеете в виду как раз системы управления бизнес-процессами (BPMS). Как заметил Александр, оценить плюсы и минусы выбранных BPMS гораздо интереснее, чем сравнивать  баг-трекеры.

Сразу пример BPMS: связка SharePoint + Nintex Workflow.