1

Вакансии / Re: Аналитик на проект. Москва. Схемы бизнес-процессов, юзкейсы.

« : 07 Марта 2017, 13:16:03 »

Вопрос еще актуален!

2

Для всех / Re: Реализация и документы

« : 06 Марта 2017, 17:47:29 »

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

В чем статика?

Диаграмма юзкейсов отличается от activity или collaboration диаграмм тем, что показывают статическую картину (список целей пользователя). Внутри КОНКРТЕНОГО юзкейса показывается динамика.

3

Вакансии / Re: Аналитик на проект. Москва. Схемы бизнес-процессов, юзкейсы.

« : 03 Марта 2017, 18:34:21 »

Можно обсудить.

4

Вакансии / Аналитик на проект. Москва. Схемы бизнес-процессов, юзкейсы.

« : 06 Февраля 2017, 13:10:36 »

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

Оплата - обсуждается. Знание графической нотации моделирования БП не обязательно - есть кому если что нарисовать по текстовым описаниям схемы БП, на проекте есть технические писатели. Очень желательно знать юзкейсы по Коберну, если не знаете - научим )). Возможно совместительство. Можно сделать только конкретную задачу (обследовать один-два БП), т.е. достаточно гибко все. Заказчик в Москве - крупный ФГУП (Варшавское шоссе). Опыт работы крайне желателен, хорошие коммуникативные навыки, умение проводить интервьюирование заказчика.

Присылайте резюме на почту (со ссылкой на UML2.ru) bouloui (дальше знак собаки) mail точка ru.

Юрий Булуй.

5

Для всех / Re: Реализация и документы

« : 23 Декабря 2016, 23:49:55 »

Вы видимо в корне не понимаете сути юзкейсов. Вы пытаетесь юзкейсами описать процесс, т.е. по сути показать динамику. Хотя юзкейсы показывают статику. Особенно  интересно как Вы интерпретируете "пунктирную стрелку".

6

Проектирование / Re: Archimate: примеры использования

« : 31 Декабря 2013, 01:03:59 »

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

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

...

Никто не мешает, согласен. Но вот большинство почему-то предпочитает для этого другие средства.

Большинство предпочитает вообще с этим не связываться

7

Проектирование / Re: Archimate: примеры использования

« : 28 Декабря 2013, 01:53:33 »

Вот рисунок в аттаче, где там то что ты утверждаешь?

http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap03.html#tag_03_12 (см. п. 3.12)

Почему, на чем зиждется твой вывод?

См. определение ИС в ФЗ 27 июля 2006 года № 149-ФЗ. Там не отождествляются ИС и АС (по ГОСТ 34).

Концепция чего? Архитектуры приложения?

Да.

Этот тезис хорошо, если ИС = апликейшен. Но ясно, что это не так. И Что делать?

На основании чего такая ясность?

Кроме этого, не согласен, что UML может использоваться только для описания структуры приложений. Никто не мешает тебе описать используя UML и собственно архитектуру бизнеса или БП.

8

Проектирование / Re: Archimate: примеры использования

« : 27 Декабря 2013, 00:57:59 »

Юра, спасибо за твой проснувшийся интерес А какова к примеру альтернатива?
Согласно TOGAF есть уровень бизнес-архитектуры, уровень архитектуры ИС и уровень технологической архитекутры
1. Уровень БА - описывает всякие там БП и БФ и прочие БЦ
2. Технологическая архитектура - техническую и программную системную платформу: СКС, Сервера, Станции, Мобильные устройства, Сетевое оборудование, Способы организации всего этого хозяйства. Серверные ОС , Системные утилиты, Системные платформы, Клиентские ОС и прочее бла бла

А что тогда остается на уровне Архитектуры ИС - прикладные приложения, прикладное оборудование? пользователи исполнители. Что?

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

Эд, ты пропустил еще один домен (view) EA по TOGAF - Архитектуру информации и данных.
Говоря об архитектуре приложений в EA, это может быть например как минимум перечень приложений и их взаимосвязь. Можно говорить про разделение приложений по архитектурным стилям и выделение на диаграмме различных компонентов приложений. Но так в принципе можно дойти и до программной архитектуры каждого из приложений в отдельности, а этот уровень детализации не нужен в EA. У тебя как раз задача будет описания именно программной архитектуры. Поэтому думаю, что концепции стройнее, чем была предложена в RUP (в т.ч. с соответствующими стереотипами), придумать будет сложно - именно когда мы говорим про описание конкретного приложения.

Архимейт как графическая нотация может решать задачу иллюстрации и описания EA. Но нужно понимать, что описание EA имеет свои цели и задачи в рамках организации. А описание программной архитектуры конкретного приложения - это несколько иная задача. Решать ее проще на UML который как раз позволяют спокойно описать программную архитектуру с разных точек зрения.

9

Проектирование / Re: Archimate: примеры использования

« : 24 Декабря 2013, 00:04:25 »

Эд, у тебя курс как я понял называется "Архитектура информационных систем". Archimate позиционируется преимущественно как язык описания Enterprise Architecture. Оно понятно что если смотреть выше на IEE 1471, то архитектура она и в Африке архитектура. Но обычно информационная систем как правило масштабом поменьше будет, чем EA. Хотя довольно забавно попытаться описывать ИС c т.з. которые предлагает тот же TOGAF по отношению к EA.

10

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 08 Ноября 2013, 22:44:55 »

Для начала нужно понять что в ГОСТ подразумевается под требованиями пользователя к АС.... это скорее то что называется stakeholder requests в RUP.

11

Обучение / Re: Помогить с выбором темы диссертации в IT

« : 02 Октября 2013, 02:06:17 »

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

12

Вакансии / Re: Требуется помощник IT-консультанта (фриланс)

« : 26 Августа 2013, 22:19:43 »

Ага, и Леночку продавца там же разместить, а то аренда помещения в городе дорого обходится.

Леночка пусть себе сидит на розничной точке.

13

Вакансии / Re: Требуется помощник IT-консультанта (фриланс)

« : 25 Августа 2013, 00:05:57 »

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

14

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 24 Августа 2013, 23:48:28 »

"

Юра, правильно я понимаю, что ты постулируешь это определение ОА? А почему нельзя рассматривать ОА как автоматизируемый процесс или совокупность процессов в контексте организации или ее части? Разве так не будет логичнее?

Тогда, если организация - понятие скорее обобщенное, например, типовое промышленное предприятие, то и описание автоматизируемых процессов происходит в контексте обобщенного, типичного промпредприятия.
Если рассматривается конкретная организация- как чаще всего и бывает, то объект автоматизации конкретизируется особенностями этой конкретной организации?

В любом случае объектом автоматизации являются все или часть функций системы или части системы

Эд, я понимаю о чем ты. Для начала я не постулирую, я предлагаю некоторое своего рода, определение того, что можно считать ОА в конкретном сегменте. И ищу либо подтверждения этой точке зрения, либо явное опровержение. Из хода дискуссии я пока не увидел явных опровержений. Антитеза, как я понимаю - что ОА - суть деятельность (БП функция) ... ты добавил "в контексте организации". С моей точки зрения БП более эфимерная вещь, чем организация или ее часть. В конце концов, у организаций есть оргштатная структура, подразделения и т.п., а БП как такового может и не быть (как например БП документооборота как такового).
Кроме этого я почуял в твоем вопросе что-то "от типового ПО", которое кастомизируется под нужды заказчика и редко идет "из коробки" - откуда как раз и такой "БП-центричный взгляд" на АС. Мне кажется, что таки первичен заказчик с его конкретной конфигурацией такой системы, т.е. конкретная организация с ее особенностями и ограничениями, связанными с выполнением тех или иных функций, которые мы автоматизируем.

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

15

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 24 Августа 2013, 20:00:50 »

Хорошо.

Несмотря на то, что у меня была другая гипотеза насчет определения объекта автоматизации, я готов принять Ваше определение, чтобы продолжить обсуждение.
Юрий, приведите примеры из ГОСТ-а, которые подтверждают ваше определение, чтобы увеличить количество аргументов в его пользу.
Хорошо бы еще кроме ГОСТ-а 34.ххх ориентироваться и на ГОСТ 19.ххх. Так как в них терминология очень совпадает.

Хотелось бы еще услышать мнение других участников насчет этого определения ОА.

Насчет контекста выполнения определенных функций...
Тоже хорошо бы привести примеры из ГОСТ-а, где упоминается или подразумевается этот контекст.

Насчет подтверждения гипотезы в ГОСТ... хотел бы обратить внимание на один момент - если бы в ГОСТ было хоть как-то определено, что есть ОА и какие они могут быть - мы бы не дискутировали об этом. Кроме этого предлагаю исключить из рассмотрения ГОСТ 19, он не имеет отношения к АС, а описывает порядок создания программного изделия. Программное изделие конечно может являться частью АС, но я не очень понимаю как он может быть полезен для понимания того, что есть ОА.

Мы уже обсуждали выше, через определение АС, через отношение ОА и АС и т.п., какие еще аргументы предполагаются?

Давайте пойдем от обратного - что в ГОСТе опровергает гипотезу и определения ОА, которое написал я?