526

Варианты Использования (Use Case) / Re: Корректен ли такой вариант использокания?

« : 24 Февраля 2008, 13:44:46 »

1. Варианты использования сами по себе, строго говоря, не являются функциональными требованиями ... это (по Вигерсу) пользовательские требования. Функциональное требование будет выглядеть в данном случае как некая возможность системы/модуля по сохранению/использованию настроек, и "подтребованием" -- возможность обновлять настройки через обновление файлов настроек.
2. Я бы не стал для данного случая писать UC, а обошелся бы именно функциональными требованиями. Но если уж есть желание выделить именно UC -- то я бы сделал один общий UС, который бы назвал (CRUD по Коберну) "Управлять настройками системы" и в нем бы выделил отдельный сценарий, который бы описывал просто возможность ИЗМЕНЕНИЯ настроек. А то, что этот файл может быть скачан (или перенесен на флэшке) -- указал бы в разделе UC "Вариации технологий и данных" одной фразой.

527

Примеры / Re: Моделирование системы внутреннего контроля

« : 24 Февраля 2008, 13:34:16 »

Событийный механизм можно использовать и в UML, не только в ARIS. В UML 2.0  есть штатные средства для описания событий и реакции на них. И если даже инструментарий не поддерживает такой возможности -- всегда можно использовать стереотипы.

528

Сообщество Аналитиков / Re: Похожие ассоциации, клубы, сообщества

« : 21 Февраля 2008, 22:40:58 »

Что-то сообщество архитекторов как-то не очень активно ... новости не шибко новые, на форуме активность небольшая ...

529

Примеры / Re: Моделирование системы внутреннего контроля

« : 21 Февраля 2008, 22:29:42 »

Попробуйте использовать событийный механизм ...

530

Работа / Re: Заказчики

« : 18 Февраля 2008, 23:21:29 »

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

531

Для всех / Re: Бизнес-аналитик и бизнес-архитектор, где граница между их задачами?

« : 18 Февраля 2008, 12:33:49 »

1. В RUP есть понятие и бизнес-архитектуры и роли бизнес-аналитика. Это к вопросу о методологиях.
2. Решениями в области ИТ должны заниматься РОЛИ Системный аналитик и Системный (программный) архитектор. На вход они должны принимать то, что натворили бизнес-архитектор и бизнес-аналитики.
3. Для начала определитесь что есть в вашем понимании модели As-is и To-Be именно с т.з. БИЗНЕСА, а потом и ИТ. Возможно в вашем понимании происходит смешивание -- под бизнес-процессом понимается по сути то, что твориться внутри системы, а не собственно бизнес-процесс. Собственно бизнес-процесс может исполнятся как с использованием информационной системы так и без нее. Например процесс обработки входящей корреспонденции (обычная почта) может выполнятся без использования информационной системы -- просто клерк смотрит кому конверт и кладет на соответствующую полочку. Люди приходят и забирают потом свои письма. Но это самый что ни на есть бизнес-процесс.
Когда вы четко отделите бизнес-процессы от их автоматизации, и просто будете показывать что вот он процесс, а вот эти его части автоматизированы и под этот процесс есть регламенты (должностные инструкции), тогда и отпадет неопределенность с ролями бизнес-аналитиков\архитекторов и системным аналитиком\архитектором. А путаница идет от производителей ERP, в частности от SAP, в котором вообще нет понятия "требования", а есть понятие описания БП и его имплементация в системе. И тогда под бизнес-процессом начинает пониматься то, что автоматизировано в ERP. Нормальная практика подмены понятий в маркетинговых целях :-). Вспомним Microsoft -- они добились ассоциации "SQL сервер" -- как класса систем, со своим продуктом "MS SQL Server".

532

Для всех / Re: Бизнес-аналитик и бизнес-архитектор, где граница между их задачами?

« : 17 Февраля 2008, 12:56:09 »

Обычно все, что начинается на  "бизнес-" относится в большей степени к области организации бизнес-процессов компании. Бизнес-архитектура -- это по сути устройство бизнеса -- из каких динамических и статических частей состоит бизнес, или попросту -- как формируется цепочка добавленной стоимости, какие есть вспомогательные бизнес процессы и чем/кем они выполняются, каковы бизнес-цели организации (долгосрочные, краткосрочные), миссия и т.п., как оценивается успешность деятельности организации и ее эффективность (система KPI). Задача бизнес-архитектора это все спроектировать и контролировать актуальность и целостность. Бизнес-аналитик, по-сути может заниматься детализацией бизнес-процессов, их моделированием, оптимизацией. Как правило он специализируется на чем-то конкретном (группе БП, или отдельных БП). Кстати, эти люди могут быть достаточно далеки от ИТ.

533

Работа / Re: Заказчики

« : 16 Февраля 2008, 02:00:41 »

А что, реально помогают эти блок-схемы/UML в понимании текста? Может просто текстом описать требования? А динамику описать в виде сценариев :-), и пусть обчитаются :-). Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?

534

Варианты Использования (Use Case) / Re: Уйти от ВИ и перейти к иерархии Пользовательских Требований

« : 09 Февраля 2008, 12:01:29 »

Пользовательские требования рассматривают систему с перспективы самого пользователя и тех бенефитов\целей которые он имеет по отношению к системе. Если возможных вариантов использования очень много и нельзя выделить конкретный ВИ,  думаю имеет смысл сосредоточится на функциональных требованиях.

535

Проектирование / Re: Архитектура информационной системы (ПО, DLL. хранимые процедуры и функции.

« : 03 Февраля 2008, 01:47:35 »

Один комментарий. TOGAF, DODAF и т.п. относятся к т.н. Enterprise Architecture. Архитектура конкретного ПО обычно называется Программной архитектурой.

536

xP Xd Agile ICONIX пр. / Re: Что есть ICONIX

« : 27 Января 2008, 23:06:21 »

Мало кто ей пользуется.

537

xP Xd Agile ICONIX пр. / Re: Кратко про Agile

« : 24 Января 2008, 14:24:36 »

В двух словах и очень грубо: Строго говоря Agile это не процесс.
....
-----
Асхат Уразбаев (http://urazbaev.ru)

Рад приветствовать на нашем форме :-) ...

538

Проектирование / Re: Layer vs. Tier

« : 22 Января 2008, 14:16:21 »

1. Посмотрите в блоге Сергея Орлика (http://www.sorlik.blogspot.com/) перевод SWEBOK, главу Проектирование. Там есть кое-что на эту тему
2. Все-так речь идет не о системной архитектуре, а о программной архитектуре. Т.к. системная архитектура это часть системной инженерии, а не программной.

539

Системный Анализ и Требования / Re: Управление требованиями

« : 10 Января 2008, 22:13:13 »

сорри за неточность:
Название: UC12 ДОЛЖЕН быть реализован(или НЕ реализован в данном проекте).
Покрываемая бизнес-потребность: BR007
Источник требования: должностная инструкция менеджеру А отдела Х.
и т.д.
Насколько я знаю, традиционные шаблоны такие атрибуты в ЮзКейс не включают.

Вообще для меня это несколько не привычно (это не означает что это правильно или не правильно :-)). Юзкейсы системного уровня по определению должны быть реализованы в той или иной итерации и дополнительное утверждение о необходимости реализации того или иного юзкейса в этом случае нет. А эти атрибуты не обязательно должны существовать в "традиционном" шаблоне. Это просто ваше решение -- так вам удобно и вы об этом все договорились. Лично я описываю все типы требований и их атрибуты (в т.ч. и для юзкейсов) в плане управления требованиями (если он создается для проекта). И веду их в инструментарии требований. А источник требования -- такой атрибут например описан кажись в RUP (если мне не изменяет склероз ... :-)). А вот покрытие бизнес-потребности обчно вводится не через атрибут, а через связи трассировки. Но вам удобнее так .. никто за это не осуждает :-).

540

Управление Проектом / Re: Про проектный офис :-)

« : 10 Января 2008, 10:40:51 »

В одной ГОС конторе я слышала очень интересное определение электронной подписи, после чего подумала, что с гос заказчиками НАДО БЫТЬ ПРОЩЕ! =)

Госзаказчики они бывают ОЧЕНЬ разные, поэтому нужно ли быть "проще" или "сложнее" -- зависит от ситуации :-).