331

Варианты Использования (Use Case) / Внешная Система как инициатор ВИ

« : 16 Декабря 2008, 15:57:37 »

Очередное обсуждение ВИ пошло отсюда:
http://www.uml2.ru/forum/index.php?topic=1078.msg11331#msg11331

А вообще главная аргументация в том, что ВИ - это ЦЕЛЬ Пользователя по отношению к Системе. ВИ отражают ПОЛЬЗОВАТЕЛЬСКИЕ требования, а при взаимодействии м\у ИС - какие ПТ?
Но в нынешней эконом. ситуации лучше не спорить с "компетентные товарищи (на работе)"

Саша, исходя из определения ВИ - это цель актора, а актор может быть пользователем, девайсом или внешней системой.
Дело здесь скорее всего в том, что обычно ПОЛЬЗОВАТЕЛЬ является инициатором ВИ (caller), а внешняя система вспомогательным актором (callee). В таком случае никаких противоречий нет и все вроде бы укладывается в "цели пользователя". А как быть со случаем, когда внешняя система является инициатором (caller)? У этой системы есть "своя цель" и про нее мы тоже не должны забывать. Или данный случай уже не относится к ВИ и является требованиями к интеграции?

332

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

« : 16 Декабря 2008, 15:27:01 »

Павел, правильно ли я понимаю, что внешняя система NT выступает в роли черного ящика, и Вы имеет в наличии только форматы передаваемых сообщений (описание интерфейса)?
В данном случае внешняя система может выступать как инициатор определенных действия, которые вы описали в виде сценария.
Моем мнение (коллеги могут не согласится :
1. Опишите форматы всех входящих и исходящих сообщений, которыми обмениваются системы.
2. Опишите алгоритмы обработки входящих сообщений и алгоритмы формирования исходящих сообщений.
    Алгоритмы можно описать с помощью сценария (что вы и сделали) или с помощью диаграммы деятельности (если не знаете компоненты) или диаграммы последовательности/коммуникации (если известны компоненты - как показал выше Александр.). Называть это вариантом использования не совсем правильно, а вот алгоритмом или функцией наверное можно.
3. Рекомендую также подготовить список данных, которые "живут" в системе - Сущности и их параметры
4. Можно еще контекстную диаграмму нарисовать, на которой показать 2 системы (как черные ящики) и показать на связях все передаваемые между ними сообщения.

Таким образом у вас будет общая картина взаимодействия двух систем, алгоритмы обработки (функции) и участвующие данные.

333

О Сайте и Форуме / Re: Снова о логотипе

« : 15 Декабря 2008, 18:58:23 »

Еще одна идея

334

Сообщество Аналитиков / Re: Сообщество аналитиков - Санкт Петербург

« : 15 Декабря 2008, 09:37:03 »

Коллеги, я тоже из Питера и с удовольствием бы пообщался.. Планируются ли встречи в ближайшее время?

Андрей, приветствуем
В начале февраля планируем провести семинар по теме "Планирование процесса разработки и управления требованиями". Более подробно о сроках и плане семинара сообщу позже.

335

Книги, статьи и ресурсы / Re: UML 2 и Унифицированный процесс: практический ООА и ООП, 2-е издание

« : 12 Декабря 2008, 18:13:01 »

Эд, судя по твоему посту очень похоже на то, как описывает ВИ сам Джэкобсон и иже с ним.
Хотя бы тот пример, что вариант использования может начинаться с нескольких точек старта и иметь разные выходы в зависимости от старта. А "если", "для" я тоже считаю что удобно использовать, например для описания той же цикличности...

336

Термины и Определения / Re: Business Continuity

« : 11 Декабря 2008, 01:54:49 »

Денис, это что-то типа продвинутого риск-менеджера?

337

Термины и Определения / Re: Business Continuity

« : 11 Декабря 2008, 01:49:42 »

Спасибо. Почитаю, поизучаю... .

338

Термины и Определения / Business Continuity

« : 10 Декабря 2008, 21:30:41 »

Друзья, может кто-нибудь вкратце пояснить что это такое и как оно может быть связано с IT? Предполагаю, что через ITIL и ITSM.

https://www.drii.org/docs/ppintro.pdf

339

О Сайте и Форуме / Re: Снова о логотипе

« : 09 Декабря 2008, 12:47:02 »

В дополнении к вышесказанному можно попробовать своровать логотип Global Rational Community
http://www.rational-ug.org/ (слева сверху). Вместо планеты сделать процесс и поиграть цветами.

Лого человечков со стрелками в руках конечно неплохо, но его сложнее рисовать. Может кто-нибудь попробует сделать?

340

ПО Аналитика / Re: IBM Rational Requirements Composer

« : 09 Декабря 2008, 11:29:26 »

вот и хотелось бы услышать реальные примеры либо перехода к СУТ либо отказа от нее, чтобы самим не наступать на те же грабли 

Саша правильно написал, сначала вы должны определиться, что именно вам нужно от СУТ, а потом уже выбирать подходящую. Если у Вас нет процесса разработки и управления требованиями, то о СУТ пока лучше не думать. Попробуйте организовать процесс на бумаге (документы, регламенты, почта ...). Когда будет работать процесс вы увидите проблемы, которые сложно решать без специализированного средства, например управление изменениями требований, отслеживание их состояний (реализованы, предложены..), управление рисками, связанными с требованиями и тп. Далее, вы можете подыскать подходящую по цене и возможностям.

341

ПО Аналитика / Re: IBM Rational Requirements Composer

« : 08 Декабря 2008, 18:51:26 »

Виталий,
А я что-то сказал противоречившее?

Вроде бы нет. Если я ответил как-то не в тему. То можно удалить комментарий

342

ПО Аналитика / Re: IBM Rational Requirements Composer

« : 08 Декабря 2008, 18:37:40 »

Когда процесс уже внедрен... появляется много подводных камней, которые трудно оплыть без СУТ...

343

ПО Аналитика / Re: IBM Rational Requirements Composer

« : 08 Декабря 2008, 18:24:12 »

Некоторые компетентные товарищи говорят, что DOORS много лучше

DOORS не юзал к сожалению. Да и что там, все равно IBM их купило, вот сейчас сделают что нибудь более толковое, объединив и реквизит и дурс

344

Тестирование / Re: Test Case & Test Analyst

« : 08 Декабря 2008, 17:02:08 »

....Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?

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

345

ПО Аналитика / Re: IBM Rational Requirements Composer

« : 08 Декабря 2008, 11:27:03 »

К сожалению с продуктами Rational я на данный момент не работаю, так как поменял работу. Но мне всегда были интересны продукты от IBM и я их продолжаю изучать . По управлению требованиями я не встречал продукта лучше RequisitePro, это ИМХО Теперь IBM сделали что-то новенькое и ReqPro обновили, так что думаю вещь получилась классная, но дорогая

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