466

Теория моделирования и нотации / Re: Когда применять диаграмму классов, а когда - диаграмму Сущность-связь

« : 08 Июля 2008, 10:19:20 »

Построение модели предметной области не накладывает ограничений на используемые нотации. Вопрос больше в целях такого моделирования и подходах к построению конкретной системы. Лично я отдаю предпочтения использованию диаграмм классов UML для domain model. ERD я использую при проектировании баз данных и то сразу в нотации IE или IDEF1X основываясь на модели предметной области.

467

Примеры / Re: Вариант использования с двумя actors

« : 07 Июля 2008, 12:28:32 »

Необходимость подтверждения выбора приложения или ввода ПИН не зависит от платёжной системы, а определяется данными, считанными непосредственно с карты. Способ проверки определяет банк-эмитент. Мы же должны поддерживать в одном приложении все варианты, заявленные в нашем сертификате EMV.

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

468

Варианты Использования (Use Case) / Re: Так UseCase функция или нет?

« : 07 Июля 2008, 00:00:41 »

У Злолтухиной собственная интерпретация RUP и юзкейсов в частности. Кстати Коберна она не воспринимала в принципе (может сейчас что-то изменилось). По определению -- функция системы, это нечто, что должна делать СИСТЕМА. Но если в качестве системы рассматривается АС (по ГОСТ 34), то можно говорить о юзкейсе как о функции, но с определенной натяжкой, т.к. модель юзкейсов не обязательно будет эквивалентна модели функциональной декомпозиции системы. А если мы ведем речь о программном изделии (т.е. в терминах ГОСТ 19) -- то однозначно нет.
RUP допускает некую нечеткость в этом вопросе отождествляя юзкейсы с функциональными требованиями. И если иметь "на вооружении" только RUP и ГОСТ -- то вполне можно прийти к таким выводам (UC = функция).

469

Конференции Семинары и Тренинги / Re: [Отчет] о конференции Training Labs 2008. Мысли, комментарии, эмоции

« : 06 Июля 2008, 11:27:08 »

У меня не было времени поработать над ошибками :-). Т.к. писал в условиях цейтнота -- сначала в электричке, потом дописывал с утра дома.

470

Примеры / Re: Вариант использования с двумя actors

« : 06 Июля 2008, 11:18:19 »

Нужно определить что является условием перехода на другую ветвь сценария. Если это тип карты (а их может быть несколько), то в главный сценарий пишется утверждение (!) что клиент дает карту Visa (или другую, которая более "типичная" т.е. чаше всего бывает). А в альтернативном сценарии пишем другие утверждение, например "Клиент подал карту AmEx" и далее что происходит. Важно, что тут нужно будет в сценарии описать не разницу экранов, а разницу во воодимой информации например или дейсвиях кассира.

471

Конференции Семинары и Тренинги / Re: [Отчет] о конференции Training Labs 2008. Мысли, комментарии, эмоции

« : 05 Июля 2008, 12:25:20 »

У себя в блоге опубликовал свою версию впечатлений о мероприятии ... :-)

472

Конференции Семинары и Тренинги / Re: [Отчет] о семинаре «Как заставить регламенты работать и приносить пользу»

« : 03 Июля 2008, 12:51:34 »

Соглашусь с Денисом. Нет смысла использовать PD именно для целей бизнес-моделирования как такового. Телелоджик System Architect в целом позиционируется как инструмент для работы с Enterprise Architecture, частью которой являются бизнес-процессы. Но SA не имеет eEPC нотации в себе, зато имеет как собственные нотации для визуализации целей, оргструктуры и т.п., так и поддерживает стандартные -- тот же IDEF и BPMN. Aris - наоборот, более заточен под именно БП, и менее под EA.

473

Термины и Определения / Re: [Термин] Allocated requirements

« : 26 Июня 2008, 14:30:43 »

Allocated -- СООТНЕСЕННЫЕ <требования> ... если контекст о системных требованиях, то говорят о соотнесенных с конкретными элементами системы требованиями .... в другом контексте, например, как описал greesha -- может быть другое "соотнесение". В том же IEEE 830 говорится о соотнесении функций с конкретным софтом или его частью.

474

Обучение / Re: основные критерии успешного аналитика

« : 25 Июня 2008, 14:01:47 »

Замуж! Срочно замуж! .... (не обижайтесь пожалуйста - это шутка). А если серьезно -- то вполне достаточно, если вы освоите UML/BPMN/Aris/IDEF до уровня "мне нужно 40 минут чтобы переключиться на эту нотацию". Идеально, если при этом вы будете разбираться в какой-то предметной области -- например в финансах, кредитовании или контроллинге, ... . Плюс ко всему освоите дисциплину Разработка и управление требованиями, и будете уметь писать документацию требований по ГОСТ 34.602, IEEE 830, а так же иметь представление как работают с требованиями в RUP\Agile. Плюс к этому - будете уметь работать с каким-нибудь инструментарием RDM. То вы будете иметь ОЧЕНЬ солидный багаж знаний для аналитика. На перспективу 10 лет не скажу, но сейчас очень перспективно специализироваться в SAP -- по деньгам конечно же. Но для SAP прикладные знания UML мало пригодятся.

Чтобы быть архитектором, нужно иметь немного другой skillset ... впрочем как и для PM-а.

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

475

Примеры / Re: UML диаграммы. Оболочка для БД с включением некоторых математических функций

« : 23 Июня 2008, 12:03:51 »

Имхо авторское "Просмотр отчетности" близко к 'отглагольное существительное' ... хотя по мне, так лучше "Формирование отчетности" - а уж что в дальнейшем будет делать пользователь с отчетностью ... просмотрит или распечатает или сохранит в неком_фомате для импорта.

И импорт/экспорт у автора может быть вполне отдельная операция, не имеющая к  "Формирование отчетности" отношения.

Название "формирование отчетности" скорее именует процесс, а не цель пользователя. Целью скорее всего будет именно "Получить отчет". Я как пользователь имею скромное желание получить таки отчет,  а не получить процесс формирования отчетности. А то, что я хочу его распечатать или сохранить в файл -- ну никак не является целью пользователя, это по Коберну -- subfunction в лучшем случае. Но я бы не стал выделять в данном случае отдельные UC по сохранению отчета и тп., т.к. это усложняет модель и не приносит никаких преимуществ. Можно сделать проще при той же информативности - вставить шаг о том, что пользователь в может сохранить отчет в файл или напечатать его ... и все.

476

Примеры / Re: ниче не понимаю.

« : 23 Июня 2008, 11:47:57 »

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

477

ПО Аналитика / Selecting the Right Requirements Management Tool ... от Forrester Research

« : 18 Июня 2008, 13:05:36 »

Опубликовал у себя в блоге ссылку на это исследование. Кому интересно -- можно посмотреть.

478

Вакансии / Re: Вакансия IT Бизнес-аналитик (г.Москва)

« : 17 Июня 2008, 10:27:14 »

Ренессанс-Капитал?

479

Примеры / Re: UML диаграммы. Помогите, пожалуйста, построить.

« : 16 Июня 2008, 14:35:24 »

Большое спасибо всем за ответы. Исходя из ваших замечаний переработал свою ДВИ.

1. Именовать юзкейсы следует отглагольными существительными, отражающими цель пользователя -- например,
"Просмотреть отчетность"
2. Не уверен, что имеет смысл выделять отдельно ВИ "Печать" и "Экспортировать данные". Это по-всей видимости опциональные шаги в ВИ "Получить отчет".
3. Чтобы правильно выделять ВИ имеет смысл попробовать описать предусловия и постусловия в ВИ и его основной сценарий -- тогда часто становится очевидным, корректен ли ВИ. ВИ это описание функциональности с т.з. пользователя.
4. Исходя из представленного в первом посте процесса работы с программой не понятно что делает пользователь в ВИ  "Контроль измеряемых значений" и "Управление процессом измерения". Каким образом пользователь управляет процессом? И как может влиять на процесс? И вообще, каков будет outmost ВИ? Есть подозрение, что тут будет только один ВИ.

480

Примеры / Re: UML диаграммы. Помогите, пожалуйста, построить.

« : 15 Июня 2008, 23:00:02 »

Варианты использования сделаны некорректно.. Например, что это за вариант использования "Отображение измеренных значений в графическом виде"? ... Это цель пользователя? Или это функция системы?