(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 

Конференция "ERwin"

Обсуждение вопросов, связанных с компанией Computer Associates, ее продуктами ERwin Data Modeler, ERwin Web Portal, ARCserve и др.

 
 
Добавить сообщение »

Тема: Реинжиниринг: как действовать?

Автор:  Ura Дата: 18.09.2002 13:42
>>>2. Как справляться со стрелками при переходе от IDEF0 к DFD?
>>Стелки при преходах - от разных диаграм ЭТО ТЕСТ правильного понимания процесса сверху вниз
>>(Может Я неверно понял вопрос - то уточни)
>Конкретизирую. Что делать со стрелкой, которая наследуется диаграммой DFD при декомпозиции диаграммы IDEF0?
>Например: на IDEF0 платежное поручение (далее п/п) входит в функцию в состоянии С1, а выходит в состоянии С2.

При декомпозиции этой функции на диаграмме DFD появляются стрелки: входящая С1 и исходящая С2. Куды их?
Для простой операции - на DFD 1 квадратик помещен (название немного меняю относительно IDEF0 этого квадрата) и к нему леплю эти стрелки. (Неверно, но в целом сохраняется общий стиль IDEF0 - DFD - IDEF3)
При сложной декомпозиции - когда на DFD много квадратов ВСЕ сразу яснее входную стрелку на первый квадратик а выходную цепляем на последний....
Ответить на сообщение »
 
Автор:  EGL Дата: 18.09.2002 11:51
Ura

>>2. Как справляться со стрелками при переходе от IDEF0 к DFD?
>Стелки при преходах - от разных диаграм ЭТО ТЕСТ правильного понимания процесса сверху вниз
>(Может Я неверно понял вопрос - то уточни)

Конкретизирую. Что делать со стрелкой, которая наследуется диаграммой DFD при декомпозиции диаграммы IDEF0?

Например: на IDEF0 платежное поручение (далее п/п) входит в функцию в состоянии С1, а выходит в состоянии С2. При декомпозиции этой функции на диаграмме DFD появляются стрелки: входящая С1 и исходящая С2. Куды их?

Спасибо за помощь!!!
Ответить на сообщение »
 
Автор:  Ura Дата: 15.09.2002 22:52
>1. >> DFD лучше всего это 1 лист. (Потом поясню зачем).
>Если можно, уточните, почему. А главное, разве их может быть несколько?
Поясняю. Их может быть несколько, и обычно так делают. НО DFD - раскрывает выполнение одной функции по преобразования документов/информации И ЧТО ИНТЕРЕСНО ИЗ ОПЫТА мне и заказчику ОЧЕНЬ удобно смотреть выполнение на 1 странице.

>2. Как справляться со стрелками при переходе от IDEF0 к DFD?
;-)
Стелки при преходах - от разных диаграм ЭТО ТЕСТ правильного понимания процесса сверху вниз
На IDEF0 - Я обычно рисую на стрелках общие слова (Как говорит хозяин функции+ делаю пометки что значит его слова (говорит передаем документ - подразумевает документ+ устный разговор +пояснение). А пояснение - делю стрелку на несколько стрелок на DFD.
Может в этом и есть разница между IDEF0 к DFD. Очень многое следует делать исходя из читаемости диаграмы.
(Может Я неверно понял вопрос - то уточни)

>3, и самое главное. Компания - финансовая, обрабатываются клиентские документы. В связи с этим диаграммы IDEF0 и DFD практически не отличаются друг от друга. Диаграмму IDEF0 можно заменить на DFD и не заметить этого. На DFD, конечно, есть хранилище и внешние сущности, но их, по сути можно отобразить на IDEF0 в виде потока документов в соответствующих состояниях и ресурсов/механизмов. Например: в IDEF0 между функциями перемещаются поручения ("принято", "обработано", "исполнено"); "Модуль учета" - это механизм. То же самое, но в DFD: есть хранилище поручений, имеющих разные состояния, к которым обращаются функции; есть внешние сущности - "Модуль учета".
>Такое впечатление, что мы что-то упускаем. Т.к. напрашивается вывод: рисовать все в DFD. Или в IDEF0. Но в чем-то одном. А потом переходить к IDEF3.

IDEF0 и DFD в принциме заменяемы (для меня тоже).
IDEF0 - я сделал чтобы показать на них ответственных за функцию и все документы на основании которых она делается
DFD - просто показал ход преобразования документа/информации.
И здесь отобразил разным цветом стрелок различные потоки ( Устные разговоры, информационные, бумажные)

И ГЛАВНОЕ Я НЕ ПЕРЕСТУПИЛ ЧЕРЕЗ СТАНДАРТ. Т.е. каждый стандарт определили и лучше их придерживаться, хотя все равно придется где-то прибивать гвоздями за уши...

>Можно иначе объяснить нашу (?) проблему: во всех примерах, которые мы видели, ведется обработка неких объектов (неважно: деталь окрашивается, посылка отправляется). В процессе обработки объекта возникают еще некие документы и их движение.
>У нас же - НИЧЕГО, кроме одного документа (в одном БП), НЕТ. То ли в консерватории надо что-то править, то ли что... )))
У вас - документ должен как то преобразовываться, или порождать какие-то операции.
(Надо посмотреть, исходя из моего опыта копромис всегда находится)

>
>4, на закуску. Показываем своему заказчику модель IDEF0, контекст. Заказчик хочет видеть полномочия и все нормативные документы, какие только есть (встречались на нижних уровнях): инструкции ЦБ, должностные инструкции, технологические карты операций, регламент. Каша получается. :( С этим можно как-то бороться (устранение заказчика - не предлагать :))?
Подели заказчика на группы.
Идея такая - Выделяешь начальника - он отвечает за IDEF0 (ему не будет интерсно все ниже), И ГЛАВНОЕ СТОЙ НА ЭТОМ. Он посмотрев диаграмму - назначает кто ответственный за фукции. ЭТИ ЛЮДИ - будут работать с тобой по DFD и определять все интсрукции и ответственный. Затем возвращаешься на IDEF0 и допысываешь их. И так ниже.
Сделай так чтобы они расписывались за диаграмму - ЭТО ПОВЫСИТ ИХ ОТВЕТСТВЕННОСТЬ. Давай им на редактирование. ОНИ ТОЖЕ ДОЛЖНЫ РАБОТАТЬ. Без этого тебя загоняют.

>Обращаемся, конечно, ко всему МИРОВОМУ сообществу, но, похоже, что Вы, Ura, пока что единственный человек, который помогает в столь интересном и...запущенном случае )))

Случай не запущенный. Просто по нему нужно работать. Первую свою работу я переделывал 3 раза за 6 месяцев. Главное работать - все сложится.

Мир в душе - МИР ВЕЗДЕ.
Ответить на сообщение »
 
Автор:  EGL Дата: 13.09.2002 16:50
Ura, спасибо Вам!

Вы РЕАЛЬНО помогли продвинуться! Правда, не столь далеко еще, чтобы в душе наступил мир. )))))
По предложенному Вами есть такие вопросы:

1. >> DFD лучше всего это 1 лист. (Потом поясню зачем).
Если можно, уточните, почему. А главное, разве их может быть несколько?

2. Как справляться со стрелками при переходе от IDEF0 к DFD?

3, и самое главное. Компания - финансовая, обрабатываются клиентские документы. В связи с этим диаграммы IDEF0 и DFD практически не отличаются друг от друга. Диаграмму IDEF0 можно заменить на DFD и не заметить этого. На DFD, конечно, есть хранилище и внешние сущности, но их, по сути можно отобразить на IDEF0 в виде потока документов в соответствующих состояниях и ресурсов/механизмов. Например: в IDEF0 между функциями перемещаются поручения ("принято", "обработано", "исполнено"); "Модуль учета" - это механизм. То же самое, но в DFD: есть хранилище поручений, имеющих разные состояния, к которым обращаются функции; есть внешние сущности - "Модуль учета".
Такое впечатление, что мы что-то упускаем. Т.к. напрашивается вывод: рисовать все в DFD. Или в IDEF0. Но в чем-то одном. А потом переходить к IDEF3.

Можно иначе объяснить нашу (?) проблему: во всех примерах, которые мы видели, ведется обработка неких объектов (неважно: деталь окрашивается, посылка отправляется). В процессе обработки объекта возникают еще некие документы и их движение.
У нас же - НИЧЕГО, кроме одного документа (в одном БП), НЕТ. То ли в консерватории надо что-то править, то ли что... )))

4, на закуску. Показываем своему заказчику модель IDEF0, контекст. Заказчик хочет видеть полномочия и все нормативные документы, какие только есть (встречались на нижних уровнях): инструкции ЦБ, должностные инструкции, технологические карты операций, регламент. Каша получается. :( С этим можно как-то бороться (устранение заказчика - не предлагать :))?

Обращаемся, конечно, ко всему МИРОВОМУ сообществу, но, похоже, что Вы, Ura, пока что единственный человек, который помогает в столь интересном и...запущенном случае )))
Спасибо Вам!!

Женя
Ответить на сообщение »
 
Автор:  Ura Дата: 13.09.2002 11:50
>Каковы практические критерии, по которым можно определить:
>- отсутствие функций, "чужих" для диаргаммы ЭТОГО уровня.
>- пора переходить от IDEF0 к DFD.
Критерий перехода от IDEF0 к DFD такой. Есть начальник отдела - ему не интересно знать как делается функция его функции (самое интересное, что он этого может и незнать). Т.е. рисуешь IDEF0 на нем указываешь фукции отдела/ подразделения. Указываешь КТО ОТВЕТСТВЕНЫЫЙ за фукции + на основании каких документов они исполняються(инструкции + ГОСТЫ +...). Подписываешь начальником подразделенния. ФУНКЦИИ ОБЩИЕ.
Пример. Есть отделения связи оно делится на подразделения. Рисуем.
1 Уровень - Обсуживание населения (IDEF0)
2 Уровень - Принимаем весовые отправления, Выдаем пенсии и т.д. + указываем на основании таких то указов все это делаем + указываем ответственных мелких начальников, ответственных за эту функци. (IDEF0)

Дальше стоп. Нужно теперь решать переходить ли на DFD или нет.
Ставим вопрос - на следующем уровне мы хотим показать перемещение/преобразование объектов и информации.
Ставим второй вопрос - хотим ли мы отобразить на следующем уровне внешнии сущности. Мое пояснение из личного опыта. Т.е. функция должна с чегото начинаться т.е. ктото извне ее активизирует -в моем варианте примера приходит человек за пенсией - И НАЧАЛАСЬ функции выдачи пенсии (DFD) т.е. человек - хочет пенсию. Из другого опыта - в хранилище данных (папке на столе ) появилась бумага - И ОПЯТЬ началось выполнение функции.
Если ДА то это DFD. Это немного не прямое применение DFD но оказалось самое логичное.
>>2. Переходишь на DFD ниже - показываешь документооборот и информационные потоки
>>т.е. показваешь технологию выполения/функции операции ДАННЫЕ НЕ ИСЧЕЗАЮТ И НЕ ПОЯВЛЯЮТСЯ ЧУДЕСНЫМ ОБРАЗОМ ИХ КТО ТО ДЕЛАЕТ. + технологическая карта операций (описание бизнес-процесса).
>>(подписывается ответсвенными за данную функцию)

>Каковы практические критерии, по которым можно определить:
>- пора переходить от DFD к IDEF3.
Здесь критерий простой. Ты написал DFD лучше всего это 1 лист. (Потом поясню зачем). Здесь указан процес перемещения/преобразование объекта. НО 1 - там несколько фукций при преобразовании И ГЛАВНОЕ ЭТИ ФУКЦИИ ВЫПОЛНЯЕТ УЖЕ 1 ЧЕЛОВЕК. 2 - при исполнении данной фукции есть несколько СЦЕНАРИЕВ работы. (Т.е. если есть варианты то на DFD ты их объеденяешь не вдаешься в детализацию)
Пример мой ВЫДАЧА ПЕНСИИ - может быть по базе данных, а может быть по бумажке.
На IDEF3 я просто рисую порядок выполнения функции 1 ЧЕЛОВЕКОМ. Это лучше подойти к исполнителю и посмотреть порядок действия. Здесь могут выяснится некоторые странные действия людей (например он делает контрольный звонок начальнику, или что-то еще). Эти потоки лучше тоже записать. ЭТО ПОМОЖЕТ ОПТИМИЗИРОВАТЬ ПОТОМ ТЕХПРОЦЕСС.

>И вообще, какие можете дать практические советы при работе с диаграммами (самоограничения, контрольные вопросы и т.д.)?
Схема построения из всех моих проектов такая (просто личный опыт 3 проектов)
Два, три уровня IDEF0 потом один уровень DFD и затем сценарии IDEF3

>>1. Все что стоит со знаком + это докуметны добытые тобой и подклееные к твоему описанию. Они должны подтверждать правильность твоих стрелок и квадратиков ;-) ОБЯЗАТЕЛЬНО собери их и подклей.
>В моем случае они должны РОДИТЬСЯ.
Если ты зарабатываешь систему для организации которой нет. ТО может они и только и будут рождаться. НО ИЗ ОПЫТА любая леятельность подчинена каким то законам и правилам. И в пределах этих правил строят внутренние правила.
Если ты строишь систему - то можешь ее промоделировать в АРЕНЕ. Но это уже друга история.

Примечания.
Если будет проектироваться ИС т.е. набор БД + программ - сразу работай с разработчиками БД (+ к DFD) .
Начнешь переходить в IDEF3 - можешь запускать в работу строителей ИС.

Мир В ДУШЕ - КУСОЧЕК Мира В МИРЕ. ;-)
Удачи в работе.
Ответить на сообщение »
 
Автор:  EGL Дата: 12.09.2002 17:56
Спасибо, Ura!

>Я уже отвечал на похожий вопрос, но повторюсь.
>1. Создаешь общую модель функционирования (IDEF0)

Каковы практические критерии, по которым можно определить:
- отсутствие функций, "чужих" для диаргаммы ЭТОГО уровня.
- пора переходить от IDEF0 к DFD.

>т.е. расписываешь общие фукции системы + документы по выполнению общие + инструкции + кто ответственный + положения о структурных подразделениях;
>(Подписывается начальниками )
Как именно называются эти документы? Каково их назначение и применение? (Речь о Вашей практике, конечно, т.е. о примерах).

>2. Переходишь на DFD ниже - показываешь документооборот и информационные потоки
>т.е. показваешь технологию выполения/функции операции ДАННЫЕ НЕ ИСЧЕЗАЮТ И НЕ ПОЯВЛЯЮТСЯ ЧУДЕСНЫМ ОБРАЗОМ ИХ КТО ТО ДЕЛАЕТ. + технологическая карта операций (описание бизнес-процесса).
>(подписывается ответсвенными за данную функцию)

Каковы практические критерии, по которым можно определить:
- пора переходить от DFD к IDEF3.

>3. Спускаемся ниже IDEF3 - тут порядок выполения работы + правила исполнения технологической операции сотрудником;
>(подписывается исполнителем операции)

И вообще, какие можете дать практические советы при работе с диаграммами (самоограничения, контрольные вопросы и т.д.)?

>Примечание.
>1. Все что стоит со знаком + это докуметны добытые тобой и подклееные к твоему описанию. Они должны подтверждать правильность твоих стрелок и квадратиков ;-) ОБЯЗАТЕЛЬНО собери их и подклей.
В моем случае они должны РОДИТЬСЯ.

>ПИШИ и будет мир.
Уважаемый URA...Да если б это только от моих писанин зависело, то поверьте мне...)))))
Ответить на сообщение »
 
Автор:  Ura Дата: 12.09.2002 17:05
EGL пишет 11.09:

>Интуитивно понятно, что внятно описанные бизнес процессы, согласованные с заказчиком, позволят получить такие желаемые результаты, как:
>- нормативные документы для сотрудников, включая должностные инструкции, правила исполнения операций и т.д.
>- ТЗ разработчикам ИС.

>1. Существует проблема с выбором языка общения, включающего стандарт и инструмент. Предполагается работа с БПВИНом (IDEF0, IDEF3, DFD), однако практики нет. А достаточно ли одного БПВИНа для ВСЕГО процесса?
Для твоего уровня т.е. построения модели достаточно и BPWin. А вот разработчика ИС понадобится что-то еще :-)

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

Я уже отвечал на похожий вопрос, но повторюсь.
1. Создаешь общую модель функционирования (IDEF0)
т.е. расписываешь общие фукции системы + документы по выполнению общие + инструкции + кто ответственный + положения о структурных подразделениях;
(Подписывается начальниками )

2. Переходишь на DFD ниже - показываешь документооборот и информационные потоки
т.е. показваешь технологию выполения/функции операции ДАННЫЕ НЕ ИСЧЕЗАЮТ И НЕ ПОЯВЛЯЮТСЯ ЧУДЕСНЫМ ОБРАЗОМ ИХ КТО ТО ДЕЛАЕТ. + технологическая карта операций (описание бизнес-процесса).
(подписывается ответсвенными за данную функцию)

3. Спускаемся ниже IDEF3 - тут порядок выполения работы + правила исполнения технологической операции сотрудником;
(подписывается исполнителем операции)

Примечание.
1. Все что стоит со знаком + это докуметны добытые тобой и подклееные к твоему описанию. Они должны подтверждать правильность твоих стрелок и квадратиков ;-) ОБЯЗАТЕЛЬНО собери их и подклей.
2. ТЗ разработчикам ИС будешь строить на основе DFD. Помечай отбельно цветом БУМАЖНЫЕ ПОТОКИ ДАННЫХ и ЭЛЕКТРОННЫЕ ПОТОКИ. Разработчикам ИС - интересны только электронные. К каждой DFD прикладывай IDEF3 - они вместе показывают что и как делается и в каком порядке. И что где хранится. И тут они тебя будут терзать - ну чтобы переделать.

ПИШИ и будет мир.
Ответить на сообщение »
 
Автор:  EGL Дата: 11.09.2002 18:25
Господа! Помогайте, если можете.

Я работаю в финансовой компании. Руководство жалает стандартизировать исполняемые сотрудниками операции. В общем, полнейший реинжиниринг ))))

Интуитивно понятно, что внятно описанные бизнес процессы, согласованные с заказчиком, позволят получить такие желаемые результаты, как:
- нормативные документы для сотрудников, включая должностные инструкции, правила исполнения операций и т.д.
- ТЗ разработчикам ИС.

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

Спасибо!
Ответить на сообщение »
 

Добавить сообщение »

 Распечатать »
 Правила публикации »
   
 Рекомендовать »  
 

Магазин программного обеспечения   WWW.ITSHOP.RU
erwin Data Modeler Navigator Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
erwin Data Modeler Workgroup Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
erwin Data Modeler Standard Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
EMS SQL Management Studio for InterBase/Firebird (Business) + 1 Year Maintenance
EMS Data Comparer for Oracle (Business) + 1 Year Maintenance
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Один день системного администратора
Мастерская программиста
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Русификация рамки IDEF0 BPWin4 (41)
Возможно ли русифицировать рамку диаграмм в BPWin4?
 
Проектирование курсовой работы в BPWin (32)
Здравствуйте.Подскажите пожалуйста где можно найти примерное проектирование курсовой работы...
 
Русификация ERWin (29)
Здравствуйте! Используем версию ERwin 4.1 в сети,но при создании логической модели вместо...
 
применение CA Process Modeller (BPWin) и связь моделей BPWin и ErWin (1)
Не очень понятна связь прогр продуктов CA Process Modeller (BPWin) и CA Data Modeller...
 
Erwin 3.5.2 (6)
Где скачать или кто может поделиться прогой Erwin 3.5.2? И как открыть файл из 3.5.2 в Erwin...
 
 
 



    
rambler's top100 Rambler's Top100