Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Раздел "Методических указаний" довольно полезен (Эд, посмотри обязательно!).курс уже скачал. методические указания тоже. Только проблема со скачиванием usecase.doc
Такими темпами, чувствую, действительно пиво с проблемами пьём )Ден, я на ГАКе зависаю. Кажный день с 9 до 6 защиты. + Дипломники и бакалавры в ужасе (всели у них правильно оформлено, так ли расставлены запятые, всели понятно в докладе) Ухожу домой в 9 часов вечера. Нет времени даже подумать.
???Вот пока меня интересует правильно ли я начал. Стоит ли продолжать в том же духе или сразу что-то подкорректировать или даже начать заново совсем по другому.да может и правильно, если цель понятна, а может и не правильно. Нужны критерии. А пока проблема только в том, что система устарела морально. Но может система дополнительно не делает того ЧТО нужно (да у вас это есть). Но я и говорю у вас там столько проблем, может ну его - взять и начать с главного? Или отбросить то, что есть? И начать все постепенно с нуля.... Можно пойти наоборот - прописать все процессы как они делаются (раз), как они должны делаться (два) и отсюда предложить что менять, но поскольку по идее вы будете делать систему с нуля (другая платформа, другая БД, другой функционал) если смылс изучать как есть, может сразу делать модель того, как должно быть?
А что такое domain?
Думаю к такому я еще не готов. Просто не представляю пока как разбить все это на классы. Не до конца понятно как быть с печатью (пакетной) и связонностью этого с взаиморасчетами.Изменился и состав пользователей (реструктуризация фирмы). Кроме того как же быть со скрытой цельюесли вы умеете строить ER модели - разница небольшая, просто нужно забыть от приницпах организации связи через первичные и внешние ключи.
IDEF и CASE - разные вещи. :-)Кто бы сомневался, но, по-моему, я не где не ставлю знака равенства.
SADT и CASE - тоже. :-)
SADT - это всего лишь "идеологическая основа" для IDEF, насколько я понимаю.Почитайте, например, выдержку отсюда и отсюда.
1-я редакция IDEF0 - начало 80-х, а не 90-х.
Сейчас, конечно, все перешли на C++. Даже те, кто не смог освоить C++, оставили FORTRAN и пишут на ANSI C. Ну или на Java, на худой конец.А некоторые пишут на Delphi, php, Ruby, и т.п.
Маклаков - умный дядька.
бизнес-модель включает в себя следующие ключевые компоненты
* бизнес-функции, описывающие, ЧТО делает бизнес;
* бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
* организационную структуру, определяющую, ГДЕ исполняются бизнес-функции и бизнес-процессы;
* фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;Excel- таблицы не подойдут? Можно и диаграмму состояний
* роли, определяющие, КТО исполняет бизнес-процессы;
* правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.особые требования в сценариях, сторожевые условия, тегированные значения + таблицы, таблицы или текст...
Для описания БП необходимо включить в модель бизнес-процессов следующие атрибуты процессов:
* воздействия, инициирующие каждый шаг бизнес-процесса;
* исполнителей каждого шага;
* воздействия, регламентирующие данный шаг;
* результат, получаемый на выходе конкретного шага бизнес-процесса.постусловия, особые и доптребования в описании сценария.
Если пункт второй (исполнители) с грехом пополам еще можно нарисовать в UML, то что делать с остальными - непонятно.почему же с грехом пополам? и опять же зачем все рисовать? Модель это не только графические образы , но и вся сопутсвующая информация.
А вот в IDEF0 с ними ясно, что делать.Да в IDEF0 есть четкие позиции для входов: управление, механизм или чистые входы. Но тажа нотация Эриксона-Пенкера лекго интегрируется в UML диаграммы.
С учетом трудности понимания заказчиком UML'я при описании бизнес-процессов пока вижу один выход: связка BPMN (бизнес-модель) + UML (модели требований, анализа, архитектуры). Средства, которые поддерживают и то, и другое уже есть, например, Enterprise Architect. Но пока такая связка еще в стадии исследования, т.е. решение еще не проверено полностью:
нет. Попрежнему не открываются. Причем любые вложения. Сегодня создал тему, прикрепил Вордовский файл - попробовал открыть - не открываетсяПопробуй удалить кукис, выйти и вновь зайти на форум.
На Intuit.ru наконец-то появился курс "Анализ требований к автоматизированным информационным системам"Просто замечательно. Странно, что его поместили в ИТ-менеджмент, или не странно?
Теперь станет полегче )
"Может просто не повезло IDEF? Появился UML и другие передовые нотации, в этом может дело?"Да конечно я прекрасно это понимаю.
Нет. UML - не замена IDEF, и он не "более прогрессивен".
Просто у IDEF и UML - разные задачи. IDEF - это функциональный подход. В фокусе процесс, а не объект (за исключением разве что IDEF1x).
Понятно, что для проектирования системной архитектуры такой подход мало пригоден. Но для того, скажем, чтобы быстро оценить масштабы разрабатываемой системы (понять, что туда входит, а что остается за кадром), выделить ее основные функции, проследить связи между ними, определить, какие ресурсы при этом используются и какие ограничения ставятся, оптимизировать процессы прежде чем приступать к проектированию системы - IDEF незаменим (особенно в коллективной работе).Вполне возможно. Тем более, что структурным метододам и структурному типу мышления в программировании пока боьше лет, чем ООП, да и ООП не перекрывает всех возможностей или лучше сказать является наследником структурного метода.
Далее, не всегда функциональное моделирование имеет перед собой цель создать какую-то информационную систему. Возможно, мы всего лишь решили повысить эффективность работы какого-либо бизнес-подразделения, оптимизировав бизнес-процессы - например, исключив лишние операции, разбив один сложный и запутанный процесс на несколько простых, объединив используемые источники данных по принципу общих потребителей и общей информации, которая им необходима, и т.д. Во всех этих случаях нам может помочь IDEF.Абсолютно с Вами согласен.
Когда мы переходим к проектированию системы, в фокусе уже не процессы, а объекты и взаимодействия между ними. UML возник тогда, когда объектно-ориентированный подход к программированию стал нормой, и предназначен именно для того, чтобы строить архитектурные модели. Использовать его в каких-то других целях, наверное, можно, но лично мне представляется нецелесообразным.Однако мир состоит из объектов, а не функций и процессов. Функции и процессы есть стороны хаарактеристики функционирования объектов. Но все зависит от типа декомпозиции, и многие дороги ведут в Рим.
Я видела, разумеется, попытки использовать UML (точнее, Use Cases) для функционального описания системы, но...На нашем сайте есть методичка - http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=72.
В фокусе Use Case - не функция. В фокусе Use Case - цель, ради которой выполняется то-то и то-то. Попытки подменить одно другим, как правило, приводят к очень печальному результату.
