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

×


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

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


Сообщения - Сергей Наумов

Страницы: « 1 2 3
31
IDEF ARIS BPMN и пр. / Re: Книги по BPMN
« : 06 Ноября 2008, 13:30:56 »
Спасибо! Уже что-то!

32
IDEF ARIS BPMN и пр. / Книги по BPMN
« : 06 Ноября 2008, 11:29:17 »
Есть ли такое на русском языке?

33
Буду ждать.  ;D

34
Книга замечательная. Но купить ее уже нигде не удается. может ли кто выложить сканы 91 и 92 страниц либо версию где эти страницы не пропущены? 8)

35
А вообще описывать БП с помощью БВИ - это не самый лучший вариант.

БАС, а как же тогда?

Эдуард, спасибо за столь развернутый ответ!

Чувствую, что истина где-то рядом, но уловить не могу.
Можете мне хотя бы намекнуть, каким образом можно описать цель "Учесть товары, переданные контрагенту"

36
Плохо, раз ничего не поняли :-( ...

Ногами сильно не пинайте. Я только встал на путь анализа и проектирования. До этого заказы мы выполняли "по наитию".
То что ЮзКейс - это цель - я понял из книги Коберна (хотя книга далась тяжело). Но почему не возможна декомпозиция цели - я не понимаю. Допустим Цель - "Учет товаров переданных контрагенту". Что бы достичь данной цели пользователь должен 1."Передавать товары контрагенту" и т.д.
Чем не декомпозиция?

Пока писал ответ - пришла в голову мысль: "А можно ли назвать "Учет товаров переденных контрагенту" целью?

37
1. Как Вы понимаете существуют разные уровни рассмотрения вариантов использования и область контекста.
2. ВИ не декомпозируются - это будет неправильно, но можно декомпозировать цели
3. Естественно начинать сверху вниз от целей бизнеса к целям пользователей
4. Естественным инструментом декомпозии в UML является пакет
5. Подсистема разбивается еще на ряд подсистем, задач, модулей, компонентов
6. Для каждого такого деления выстраивается модель взаимодействия, которая включает описание ВИ, причем диаграмма тут имеет последнее значение
7. Вариант использование - это элементарный бизнес-процесс производимый одним человеком в одном месте за один сеанс деятелности и приводящий к ощутимому результату, изменению состояния системы
8. ВИ описывает потребную с точки зрения пользователй функциональность системы
9. Логика работы такой функциональности может описываться диаграммами деятельности в первую очередь, а такжде системными диаграммами последовательностей во вторую

Кстати документо оборот лучше описыать с помощью DFD имхо

ничего не понял(

Хочу разложить большую подсистему на меньшие составляющие. Как мне это сделать с использованием UML?

38
Добрый день,

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

Вот что у меня есть.
Краткая постановка задачи:

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

Как я себе вижу картину вариантов использования:
1. Учет товаров переданных контрагенту
1.1 Передача товаров контрагенту. Может выполняться любой из "Подчиненных ВИ"
1.1.1 Передача товаров без ордеров оформлением документа "Передача товаров контрагенту"
1.1.2 Передача по ордерной схеме оформлением документов "Передача товаров контрагенту", "Расходный ордер на товары", "Приходный ордер на товары"
1.2 Реализация товаров у контрагента
1.2.1 Оформление документа "Отчет о продаже"
1.3 Проведение инвентаризации товаров у контрагента
1.3.1 Если выявилась недосдача - списание товаров
1.3.2 Если выявились излишки - оприходование товаров на склад компании, затем - 1.1. (Передача товаров контрагенту)
1.4 Прием товаров от контрагента
1.4.1 Если выявилась недосдача - списание товаров
1.4.2 Если выявились излишки - оприходование товаров на склад компании

39
Официального мануала на русском нет. Но обычно на вопросы здесь можем ответить, также можно faq на сайте почитать + в качестве шпаргалки можно использовать нашу с Эдом презентацию с TrainingLabs - http://luxoft.ru/downloads/edu/surova_galiaskarov.rar , в файловом архиве uml2.ru есть перевод доки по особенностям размещения EA при коллективной работе.


Спасибо. С Вашей презентацией я ознакомился. Но вопросов пока больше чем ответов.

Если у кого есть возможность - выложите свою модель, сделаную в EA с краткой постановкой задачи. Думаю на примерах быстрее освоюсь с программой.

40
Как учат нас the best practices в основе видение или концепция. Это и бизнес-план, и артефакт, призванный как раз дать всем ясное представление о том, что нужно делать, каковы стратегические и тактические цели, кто заитересован в проекте и какие общие нужды имеет.

Такми образом можно набросать Видение и спецификацию дополнительных средств.

Видение может быть отрисовано через фичи, контекстные диаграммы, поясняющие BPMN или другие диаграммы, планы проекта.

По сути Вы и сами все написали



Нет предела совершенству. Интересно, как подобные задачи другие решали. Не я ж один такой одинЭснег, кто задумался над проблемой документирования собственной работы.

41
Господа, а нет ли мануала на русском для EA? А то с английским не очень...

42
Здравствуйте.
В чем заключается проблематичность? Заказчик несовсем понимает перспективы развития ИС у себя на предприятии, нет денег, использует поэтапное внедрение? Подходит к процесс информатизации не глобально? Но потом задним умом понимает это и принимает неосознано, а поезд ушел как говорится?
Или заказчик таков, что полагает, что разработчик сам должен все знать и нечего заказчика мучить?
Как раз наборот - руководитель проекта на стороне заказчика более чем грамотный специалист и глобальный план работ составляет сам - обсуждаем мы его устно и нам этого достаточно.
А что понимать под общим ТЗ? Если нет понимания чего в общем делаем, а есть, как я понимаю, поэтапное внедрение функциональных подсистем, просто на одной платформе и разработчки тоже один?
Также интересно узнать, что Вы вкладываете в понятие общая модель системы и невозможность ее создания?
Понимание есть. Но вся информация уже есть у нас в головах. Такая ситуация пока всех устраивает.

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

43
Добрый день уважаемые коллеги,

Исходная ситуация: мы - разработчики ПО на 1С:8.х.
Задача: повысить качество взаимопонимания с заказчиком, с программистами и качество продукта путем ввода понятной для всех документации.
Особенности: взаимодействие с заказчиками складывается таким образом, что внедрение идет последовательно и разработка единого видения ИС/отчета об обследовании проблемотично. Например: месяц пишем подсистему CRM, потом месяц подсистему "Управление инструментами" и т.д. Разработать общее ТЗ/документ требований и общую модель системы не возможно.

Вопрос: Раскажите, как такие работы оформляются у вас? Поделитесь опытом..

Пока выбрал для себя следующий подход:

1. Концепция (формируется на каждый этап работ): бизнес-требования, требования пользователей, use-case модель, информационная модель разрабатываемой подсистемы (в случае с 1С - вещь понятная даже для неподготовленного пользователя, взял диаграмму классов из UML)
2. ТЗ (по одному этапу может быть много ТЗ, содержащие различные доработки) - документ содержит описание экранных форм документов, доработок к существующим объектам конфигурации и т.д.
3. План итерации - план работ на неделю с целью определить что из первоначального ТЗ в данный момент реализуем.

Страницы: « 1 2 3