4621

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

« : 30 Ноября 2007, 14:16:03 »

ArtemyY, внесите в риски проекта - риск непонимания заказчиком важности ведения документации и поробуйте расписать кто и за что тут отвечает, посчитайте влияние на проект и систему в целом, оцените вклад.

4622

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

« : 30 Ноября 2007, 14:02:53 »

Sunshine, думаю не следует цитировать анектод полностью, тем более он находится совершенно рядом.

4623

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 30 Ноября 2007, 14:00:08 »

BIS, спасибо за замечание, исправил. Саше выговор!

4624

ПО Аналитика / Re: Совместная работа в Rational Rose 2003

« : 30 Ноября 2007, 09:33:53 »

Юрий, а по подробнее?

Я нашел такой механизм. В Rational Administrator формируется новый проект. В него включается модель Rose.
Однако запустить ее из под администратора мне не удается, а запуск розы из-под админа создает новую модель.

Совершенно не понятно как этот механизм работает

4625

UML SysML и пр. / Re: UML диаграммы почтового клиента.

« : 30 Ноября 2007, 09:30:10 »

bas, я думаю тут не надо так уж строго.
По идее - тут главное выделить системные события. Хотя ты прав, цели пользователя достаточно очевидны -

получить/просмотреть почту,
ответить (но не всегда, только ответить, можно ведь и просто написать новое письмо - например для установления контакта, послать запрос и т.п.), так что ответить может дополнять расширять - написать письмо
ну и управлять списком писем. это к тому, что удаление вовсе необязательно сопутствует ответу, хотя можно и так на это посмотреть

4626

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

« : 30 Ноября 2007, 09:24:18 »

Многие Аналитики считают что они - стратеги.

А кем себя считают все остальные?

4627

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

« : 29 Ноября 2007, 21:00:40 »

ArtemyY,
давайте порассуждаем.

есть сторона Заказчика и сторона Подрядчика - ваша сторона.
Между ними есть некий договор, устный или письменный. Если устный плохо.
Если договор лучше, но тоже может быть плохо.

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

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

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

Поскольку Вы говорите что документ писался самими Заказчиком и более того потерял актуальность, тогда Вы имели право принять этот документ только после его ревизии. Но если приняли - тут что можно поделать?

4628

UML SysML и пр. / Re: UML диаграммы почтового клиента.

« : 29 Ноября 2007, 20:44:16 »

egor, в принципе да. Хотя можно в данном случае оставить как есть, только убрать повторяющиеся ВИ.

Вообще очень странно, что Вас заставялют делать то, что для Вас темный лес. Может Вы все-таки огласите задание, как оно было Вам выдано? Т.е. список всех требований к проекту?

Вы должны сечас понять одно. ДВИ как таковые ничего не значат. Они показывают лишь общий контекст, в данном случае ЧТО хочет пользователь от системы почтового клиента. Потому про администрирование можно и забыть, а оставить только важные цели пользователя:

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

Ответить на письмо (это и написать письмо и отослать письмо и возможно переслать письмо)

Переслать в приницпе можно оставить

Удалить письма можно оставить

Я бы правдв еще добавли что-то типа создание почтовго аккаунта или управление почтовым аккаунтом. А то как то непонятно как пользователь пользуется системой

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

Вариантов много :-)

Просто посмотрите на свой любимый почтовый клиент. определите самые важные функции которые нужны для выполнения ваших задач-  наверное этого будет достаточно

4629

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

« : 29 Ноября 2007, 19:46:16 »

Shur, поздравляю с сотней!

Полностью согласен с Shur. Аргументы крайне не убедительны для Заказчика. Заказчик скажет, что это Ваши трудности и проблемы, как Вы там орагнизуете процесс. Мне нужна система!

Однако нужно найти аргументацию, которая ясно покажет Заказчику, что может случиться вслучае игнорирования и нежелания финансировать эту работы. Причем это нужно сделать так, чтобы показать, что пострадает в первую очередь сам Заказчик и лучше, если вам удасться показать, что Вы собственно отделаетесь только головной болью, а финансово это Вас не затронет. Т.е. все издержки за упрямство будут виной самого Заказчика. Вопрос как это сделать? Вероятно, это должно жестко регламентироваться документами

4630

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

« : 29 Ноября 2007, 19:35:27 »

Похоже 

4631

UML SysML и пр. / Re: UML диаграммы почтового клиента.

« : 29 Ноября 2007, 19:33:44 »

egor, помоему получилось все нормально. Поскольку вы описываете задачи пользователя, то вполне нормально изложили их.

Конечно, можно сказать, что скорее всего не все возможности вы указали. Но Вы выделили главные.

Я бы, конечно, сделал несколько иначе.

Попробуйте уловить мои рассуждения.

Итак, что мы имеем.

Пользователь
1. Написать новое письмо
2. Получить почту
3. Ответить на письмо
4. Переслать письмо
5. Переадресовать письмо
6. Удалить (вероятно письмо)

К каждому ВИ следует поставить вопрос: А зачем?
Внимательно отвечая, можно прийти к таким более общим задачам как:
В1. Написать письмо
В2. Ответить на письмо
В3. Переслать письмо
В4. Удалить письмо

В1 Подразумевает создание либо нового письма либо ответа
В2 Подразумевает набор действий, среди которых вызывается В1 и 2
B3 Подразумевает выполнение 2 (который может быть расширен еще Прочитать письмо). Ваши 4 и 5 как мы видим аналогичны

При этом B4 может входить в общий вариант Управлять письмами, куда могут быть включены и Получить письмо и Прочитать письмо и Переадресовать письмо и Переместить письмо и Пометить письмо

Естественно все это можно рассматривать совершенно отдельно либо как экземпляр сценария базового ВИ.

Поэтому лучше для начала описать все, что хотел бы иметь пользователь от Вашего почтового клиента. Ведь фактически это и будут функции системы или свойства системы. Сюда могут быть включены и вопросы администрирования почтового клиента: создание ящика, формирование и настройка последнего, вклчение и отключение всяких свойств. Но... Вы стремитесь в начале выделить самое главное (Вам это практически удалось), далее анализируете, что следует делать вначале, а что можно реализовать позже. То что Вы выделили главным (а это 10-20% Ваших ВИ), описываете подробно и детально. Именно описываете. Диаграмма ВИ - это простой контекст, содержание задач пользователя в самомо общем виде, без излишних деталей.

Когда часть ВИ будет детально описана (базовый поток, альтернативные потоки, расширения и исключения) будет понятно как структурировать ДВИ, если это вообще потребуется.

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

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

Совокупность всех диаграмок классов дасть общую модель классов системы на концептуальном уровне

Диаграммы состояний будете делать для классов, которые действительно меняют состояния: например Письмо (Получено, Прочитано, Удалено). Либо для состояния какого-то управляющего класса.

Можно конечно отсановиться на общем концептуальном уровне и определить модель классов предметной области, модель состояний для нужных классов, модель взаимодействий объектов

4632

IDEF ARIS BPMN и пр. / Re: Как настроить jwsdp для jboss/jbpm?

« : 29 Ноября 2007, 18:58:09 »

Николай, но с Intalio тоже не так все просто. Как с дизайнером, так и с  сервером.

Тормоза страшные, кроме того, совершенно нельзя изображать связи message flow между процессом и pool "черный ящик". Может это связано с тем, что при конкретной реализации, нужно все-таки раскрыть черноту, чтобы определить действия клиента, т.е. явно задать задачу?

4633

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 29 Ноября 2007, 12:38:07 »

Причина может быть вполне ясная: новость не является новостью вуза или активностей вуза, это просто реклама, причем не вузовской деятельности.

Кроме того, я все-таки разместил новость на сайтах expert.isuct.ru и dit.isuct.ru - конечно они менее посещаемы чем главный сайт вуза. Тем не менее.

К вопросу об сортировки - я уже давно все сделал - разве не видно?

Делается это просто    - сортировка по самым старым (т.е. что раньше опубликовал, то впереди и торчит) [не подумайте чего худого  ]

4634

ПО Аналитика / Совместная работа в Rational Rose 2003

« : 29 Ноября 2007, 12:05:12 »

Срочно нужна консультация по организации совместной работе в Rational Rose 2003.

По справке искать сложно и по каким словам не знаю.

Кто этим занимался, прошу проконсультировать

4635

Работа / Re: Наиболее продуктивные условия работы для аналитика

« : 29 Ноября 2007, 11:51:11 »

Эля, можно вообще не работать!