Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Юрий Булуй

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
781
интересует:
1) как взаимодействуют сотрудники посредством ИС

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

2) насколько ИС не соответствует БП
Денис уже ответил. Скажу только что есть такая штука gap analysis. Проблема не только перед вами такая стоит :-). Универсального метода решения не существует. Решение -- анализ "вручную".


3) как взаимодействуют функциональные блоки ИС
проблема в том, что руководители не получают нужную информацию, т.к. кто-то что-то сделал неправильно, либо "глючит" ИС

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

782
Ситуация:
Есть информационная система(ИС) и текущий бизнес-процесс(БП)
В моем понимании, есть точки входа бизнес-процесса в информ. систему и точки выхода
Требуется:
1) отобразить ИС и БП в графическом виде на уровне основных процессов без деталировки;
2) отобразить точки пересечения ИС и БП
3) симулировать если на входе ИС не будет информации, то на каких выходах она пропадет.
Какую нотац-ию(ии) и программное средство использовать?
ps.: интересует исключительно практическое применение, которое можно реализовать в сжатые сроки

Самое практичное и быстрое -- карандаш и бумага. Если вы не знакомы ни с одной нотацией, то времени на ее освоение и обретение навыков ее примения у вас уйдет достаточно. Увы, это требует услий. "Быстро только кошки родяться" (с).

А если ваша система всего лишь автоматизирует существующие БП, то входы/выходы системы очевидно соответствуют входам/выходам бизнес-процессов. IDEF0 в данном случае позволит описать входы/выходы процессов и тех кто взамиодействует.

783
Про бумаги.
По этому я и написал, что это провокация :) Вопросник, конечно надо было приложить.
А на самом деле, если заказчик смотрит модель внимательно, он сам пугается и говорит "А где же ценные бумаги?!" и тогда ты спрашиваешь, а какие они и он много рассказывает о них :)

О-о-о! Вам повезло с заказчиками. Обычно они не то что UML диаграммы не в состоянии прочитать, а требования изложенные в ТЗ не воспринимают. Приходится прототипами системы их пичкать :-).

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

Честно говоря, про изменение условий я не уловил где это предлагалось ...

Про связь 1:1. Я читаю так (выделения мои добавления подчеркнуты):
В рамках (ОДНОГО) договора одна сторона продает(выступает как продавец), а другая приобретает (выступает как покупатель) (ОДНИ) некие ценные бумаги
Здесь больше нигде не раскрывается понятие ЦЕННЫЕ БУМАГИ и оно откалывается отдельной сущностью и встает в очередь на раскрытие структуры этой сущности и ее связей с окружением. Почти наверняка в дальнейшем она умрет, но сейчас (на основании представленного текста) это элемент, подлежащий верификации и внесению в вопросники для дальнейшего разговора.

Конечно можно и так интерпретировать, ничто не запрещает рассматривать в модели анализа, точнее в ее наброске, ценные бумаги как нечто цельное с отношением 1:1. Но в таком случае, имеет смысл сопровждать модель  "вопросником" или хотя бы комментариями. Иначе, IMHO, сложно ее интерпретировать.

785
ПО Аналитика / Проблемы установки CaliberRM
« : 30 Января 2007, 21:41:24 »
Что я делаю не так?

Форум не тот конечно, но ... можно попробовать использовать localhost и Admin/admin ...
Можно мне на e-mail написать, может помогу. У меня есть опыт работы с CaliberRM :-), так что обращайтесь.

786
1. В исходном тексте который привел Эдуард, сказано достаточно четко, что договор на покупку "ценных бумаг",
Цитировать
"...а другая приобретает (выступает как покупатель) некие ценные бумаги..."
. Т.е. даже если выполнять формальный анализ текста, то все равно продажа не одной а нескольких ценных бумаг в рамках договора будет фигурировать. Откуда 1:1 связь м/у Договором и бумагами?
2. О важности контекста. Вопрос -- будут ли отличаться модели, если принять во внимание, что договор и иже с ним существует в контексте бухучета конкретной организации (Продавца или Покупателя), или существует в рамках неких процессов отслеживания движения ценных бумаг неким федеральным органом, который должен учитывать движение ценных бумаг, или договор сушествует и рассматривается в рамках некой системы "учета договоров", где важно отследить обязательства по договору -- т.е. вовремя ПРОСТО ВЫПОЛНИТЬ эти обязательства и передать именно ТЕ ценные бумаги, которые в конкретном договоре?
Да, точки зрения PD могут быть разные. Но смысл моделирования не ради моделирования как такового и выполнения задач (в терминах Boatman) -- задач в реальной жизни не так много. Поэтому и важен КОНТЕКСТ, который должен быть описан -- тогда это хороший case, в т.ч. для Эдуарда, который студентам должен задавать задачи (или проблемы?). В конце концов вы же сами формулировали вопросы тут http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=112.msg1030#msg1030 -- "Как спроектировать систему?", "Как воспитать/выучить А/П?", "Как мне не упустить важное в работе?" и т.п. ... вот они ответы в т.ч. на эти вопросы ...

787
А я так понял, что Эдуард выступил перед нами в роли аналитика, уже познакомившегося с описанием некой ПрОбл и представившего её некоторое продуманное и формализованное описание, а не пользователя. "Пользователь" или эксперт имхо другими словами бы всё излагал :)

Я в курсе того что Эдуард ознакомился с "первоисточником" :-). И эта цитата не к этому имеет отношение. Она говорит о моей практике, что я никогда не рисую диаграммы "со слов". Да и давайте посмотрим таки на оригинальный постинг от Boatman, на который и была приведена эта цитата:

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

Ровным счетом на него и был ответ, а не на предположение что Эдуард есть пользователь, не так ли?

Да, это всё правильно, но изначально не было постановки как "давайте попытаемся проиграть итеративный процесс построения модели ПрОбл", поэтому я, например, воспринял текст как всё, что у нас есть в распоряжении.

Я же опубликовал выше, что действительно все что есть в распоряжении это текст некоторого договора. Эдуард вполне передал суть, отбросив лишнее. Естественно в договоре нет ни слова об аналитической сущности "Сделка", естественно что показать условия договора -- этого ТОЖЕ НЕТ В ТЕКСТЕ ДОГОВОРА.  Я в своей диаграмме внес ПРЕДПОЛОЖЕНИЯ, их ЗАФИКСИРОВАЛ. Другой вопрос, если бы я не написал эти assumptions and dependences. И внеся предположения я поднял вопрос КОНТЕКСТА использования.
Да, все представленные решения так или иначе имели контекст, другой вопрос что одни "выжимали из текста все что можно", и следовали буква к букве, считая недопустимым "фантазировать", другие превносили контекст явно (или неявно??).
Я же прдедложил его таки описать (этот самый контекст использования) текстом. Но почему-то это предложение осталось незамеченным. Вместо этого все стали рефлексировать :-). Может все-таки имеет смысл описать контекст?

788
Исходный текст приведен в первом посте топика. Иначе мы с Вами просто сравниваем свои знания о купле-продаже ценных бумаг, что ИМХО бессмысленно и не может являться ЗАДАЧЕЙ.
С другой стороны, почему нет... В приведенной мной диаграмме показаны следующие факты.

1. Существуют "Юридические лица"
2. Сущевствуют "договора купли-продажи ценных бумаг"
3. Одно Юридическое лицо может выступать "покупателем" или "продавцом" в "договоре купли продажи ценных бумаг" и наоборот "договор купли продажи ценных бумаг" имеет одного покупателя - "Юридическое лицо" и одного продавца - "юридическое лицо".

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

Cм. мой топик выше, и предложения по контексту (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=111.msg1058#msg1058)

789
2Boatman. Вы текстом можете описать, что вы хотели этой (второй) диаграммой сказать? Тогда можно будет и откликнуться.

Есть еще одно предложение. Сформулировать тот самый контекст. С т.з. исходных данных -- все что имеется -- это текст договора купли-продажи ценных бумаг. Пусть это будут Векселя. В договоре сказано о том что 2 юрлица, (одного из которых В ДОГОВОРЕ (!!!)называют Покупатель а другого Прдавец) свершают куплю/продажу N Векселей, разного номинала, разных векселедержателей, с разным сроком погашения, естественно за разные деньги (цена покупки векселя). Так же в договоре есть обязанности сторон -- кто когда деньги перечисляет, когда векселя отдает, и штрафные санкции за просрочку (% от суммарной стоимости векселей за день просрочки) и т.п.

Достаточно ли этого для понимания КОНТЕКСТА? На мой взгляд нет. Какого рода информации не хватает? Если есть желение, your welcome, высказывайте свои мысли, можно будет обсудить.


790
Усложнять -- просто, упрощать сложно (с) Народная мудрость (?). На самом деле это я спровоцировал такой "эксперимент" :-). Кстати, Boatman ссылается на некий комментарий Дениса, насчет задачи на логику. Я к сожалению не видел этого комментария.
На самом деле, я никгода не рисую диаграммы "за пользователем", т.е. слово в слово. И тем более потом эти диаграммы валидировать у пользователя сложно. Реально имеет как раз смысл выделить самое важное из "первички" и отвалидироваться со своим мнением у заказчика.
Второй момент -- это важность КОНТЕКСТА в котором делается domain model. Именно контекст направляет моделирование. Если что-то не понятно, то имеет смысл внести предположения и потом их проверить, но их нужно зафиксировать. Например, если смотреть с позиции некой организации, которая просто свои сделки регистрирует -- это одно, а если смотреть с позиций документооборота, можно придумать несколько другие аспекты. И модели могут при этом отличаться.
А вообще, интересно было бы увидеть как решить вопрос без использования двух сущностей Продавец и Покупатель ;-).

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

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

792
Как написать ТЗ?

Вопрос в том, что действительно нужно ... мы хотим научиться писать ТЗ или разрабатывать и управлять требованиями к ПО? И кстати, ТЗ по ГОСТ 34.602? В случае ТЗ есть один сайт, где фрагментарно описано о том как писать ТЗ по ГОСТ. В случае работы с требованиями -- есть open enrollment курсы, есть консалтинг -- как от фирм, так и от частных консультантов (что обычно эффективнее и дешевле ;-)). Есть литература в конце концов. Что в этом случае будет продвигаться нами, и в каком виде?
[/quote]

Я сделал "то-то и то-то", что делать дальше?

It depends ....

Как спроектировать систему?

Вопрос риторический и конечно же it depends ...

Какой инструмент использовать для задачи N?

Скорее всего тот, который в вашей компании куплен :-). (http://www.pskovo-pechersky-monastery.ru/russian/qp/penance/!qp/2691 -- можно и так решать проблему ...)  А вот насчет обсуждения достоинств и недостатков инструментария, поговорить можно. Но эффективный результатом может быть например статья. А объективный анализ инструментария ОЧЕНЬ сложно сделать.

Как организовать процесс разработки при таких-то исходных данных?

Точно все данные удасться перечислить? ... вообще-то это вопрос консалтинга.

IMHO очень широк охват, боюсь что очень сложно будет охватить и процессы и методы ... Большинство из этих вопросов можно на круглый стол выносить :-) в рамках встреч :-).

793
Вот нечто подобное ...

794
1. Если нет контента, какая бы не была раскрутка ... поток посетителей быстро иссякнет
2. Если будет интересный контент ... хуже от "технической" раскрутки не будет

795
Например меня интересует сейчас очень конкретная вещь, возможно не сильно связанная с именно с UML и системным анализом. Но зато не абстрактная :-). А именно -- практика "разграничения компетенций" в треугольнике ITIL  -- Project Management -- Configuration Management в конкретных командах по разработке ПО, причем раз речь про ITIL зашла, то становится понятным что это в основном касается внутренних ИТ подразделений компаний (in-house разрботка).

Вторая область интересов -- это управление требованиями, в частности конкретные практики, которые сложились в конкрентных командах. Форматы документов, используемая классификация требований и почему и т.п. Управление требованиями в условиях когда реально идет в основном поддержка готового продукта, а не создание нового.

Далее. Архитектура :-) ... хотел бы пообщаться с Денисом, на сколько я знаю, он именно архитектор в компании на которую он работает -- интересна его практика,  и конечно практика других участников встречи. ЧТО есть архитектура (и кстати какая системная или программная?), какие артефакты создаются, какое value есть от них.

Я перечислил свои "шкурные интересы", т.е. то что я хотел бы получить. Другой вопрос, что я МОГУ дать в замен, вот тут бы хотел бы услышать пожелания. Понятно, что курс по RDM например я не прочту за кружкой пива :-), но обсудить конкретные практики и т.п. ... высказывайтесь.

P.S. К сожалению не могу гарантировать на 100% что буду, все-таки это выходной, и с родственниками нужно повстречаться и детей выгулять :-) и все такое ... но свой "интирэс" я обозначил :-).

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »