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

×


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

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


Сообщения - kolodinivan

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

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

2
Да - они обрабатываются бухгалтерией-  как минимум, подшиваются в специальную папочку, заносятся в журнал и разносятся по счетам бухучёта. Как организовано взаимодействие библиотеки и бухгалтерии это интересный вопрос. Эти документы точно ничем не управляют в библиотеке.

Про деньги, кстати, тоже интересный вопрос. Если библиотека платит налом, то да у нас будет стрелка деньги (но тогда возможно имеет смысл сделать для библиотеки ресурс "Деньги"). В реальной жизни, скорее всего деньги идут безналом со счёта школы. Т.е. из библиотеки в бухгалтерию школы идёт некая служебная записка на оплату книг + обычно счёт от поставщика. Т.е. стрелок с деньгами тогда не будет. Будут стрелки с документами.
Как Вы думаете будет ли управлять принятие книг договор? Вы говорили про товаросопроводительные документы, как мне кажется они ни задевают процессы работы библиотеки и идут в бухгалтерию сразу, хотя по накладной например библиотекарь должен проверить  наличие книг, но то же наличие в принципе есть и в договоре. Сейчас на каждую поставку отдельно договор составляется, узнавал у библиотекарей))

3
Да - они обрабатываются бухгалтерией-  как минимум, подшиваются в специальную папочку, заносятся в журнал и разносятся по счетам бухучёта. Как организовано взаимодействие библиотеки и бухгалтерии это интересный вопрос. Эти документы точно ничем не управляют в библиотеке.

Про деньги, кстати, тоже интересный вопрос. Если библиотека платит налом, то да у нас будет стрелка деньги (но тогда возможно имеет смысл сделать для библиотеки ресурс "Деньги"). В реальной жизни, скорее всего деньги идут безналом со счёта школы. Т.е. из библиотеки в бухгалтерию школы идёт некая служебная записка на оплату книг + обычно счёт от поставщика. Т.е. стрелок с деньгами тогда не будет. Будут стрелки с документами.
Да скорей всего вы правы, уберу лучше деньги сделаю документ в бухгалтерию какой нибудь

4
Заказы поставщику и деньги поставщику это выход, книги от поставщика и товаросопроводительные документы это вход.
я так и думал :D. а товаросопроводительные документы разве не на управления, если это вход во что они должны преобразовываться?

5
Могу посоветовать книгу http://dit.isuct.ru/ivt/books/CASE/case8/sadt_index.htm (там есть часть 5 - уроки)
Также можно посмотреть сам стандарт http://dit.isuct.ru/ivt/books/CASE/case10/idef0/index.htm

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

IDEF0 реализует системный подход, подход сверху-вниз. Если перевести на уровень написания программы, то Вы начинаете с того, что пишите собственно контуры программы, что-то типа:

program factorial;
uses crt;
begin
end.

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

Потом вы ее декомпозируете на составные более детальные функции и процедуры:

program factorial;
uses crt;
procedure datainput;
begin
end;
procedure dataoutput;
begin
end;
procedure factbycycle;
begin
end;
begin

datainput;
factbycycle;
dataoutput;

end.

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

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

При этом  входы - то, что потребляется или преобразуется для получения выхода.
Управления - то, что регламентирует, ограничивает, управляет, определяет ход преобразования входа в выход. И Нужно искать такое управление, которое будет полезным для дальнейшего, а не просто Законодательство РФ, но конкретно Статья 3, пункт 4, абзац 5 :)
Механизмы - ресурсы, то что помогает преобразовать вход в выход, возможные пользователи, участники процесса, инструменты, и т.п.
Посмотрите пожалуйста, диаграмма с точки зрения библиотекаря, на выходе от работы библиотекаря он получает рейтинг по книгам который устанавливается в книжном формуляре и выданная книга который читатель будет читать)). на входе возможно не правильно, дуги заказ и деньги поставщику думал то же на выход, так как заказ будет обрабатываться на стороне и деньги поставщиком то же будут обрабатываться на стороне)) это уже не наше дело, главное что от него книги пришли, а по работе с читателями библиотекарь только информацию и получает ну и возвращенную книгу конечно. Нормативные документы можно в принципе разбить по подробней. ну и ресурс один библиотекарь, потом я думаю появиться и другие в декомпозиции. 

6
Совершенно неправильный подход использования IDEF0.
Ошибка начинается с первой диаграммы, А-0. И не надо спешить делать декомпозицию, надо начать с контекстной диаграммы, а не спешить.

IDEF0 - это про моделирование процессов, функций системы, а следовательно нужно думать в категориях процессов, функций (по-английски, activity т.е. деятельность).

Начинать нужно с определения точки зрения:
например, точка зрения системного аналитика со слов директора библиотеки....

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

Далее это может быть модель как есть, модель как должно быть.

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

Затем определяем выходы, с позиции выбранной точки зрения, тут важно понять  какие другие внешние процессы получают эти выходы для выполнения своих задач
Хорошо что я сюда зашел, спасибо за ответ, буду переосмысливать

7
и последняя декомпозиция

8
я вот с этого примера пытался переделать без использования СУБД

9
Декомпозиция 1го уровня мне очень не нравится.
Поиск в картотеке как процесс верхнего уровня? Картотека - это только инструмент. Это примерно, как описывая завод сделать процессы верхнего уровня "Работа с компьютером" и "Остальные процессы". Т.е. непосредственному использованию инструмента - не место на верхнем уровне.

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

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

По поводу того какие процессы писать на верхнем уровне - я бы рекомендовал сосредоточиться на обслуживании читателей. Если вы не библиотекарь, то про остальное вы знаете очень мало. Т.е. должно быть что-то типа "Регистрация читателей", "Приём книг от читателей", "Выдача книг читателям" можете глубже покопать, например "Претензионная работа" (борьба со злостным невозвращателями книг.


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

10
Учащиеся школы - это не вход. Вход это то что преобразуется системой в выход в ходе её работы. Учащиеся не преобразовываются :) Как они были учащимися так они и остались. Учащийся - за границей системы, хотя и взаимодействует с ней. 

Думаю, на вход должен идти "запрос на регистрацию", на выход что-то вроде "читательский билет"\"результат регистрации". Как вариант, я бы не стал тащить регистрационные взаимодействия на контекстную диаграмму вообще. Их можно оформить при помощи туннелирования на более глубоких уровнях декомпозиции.

И да, как уже отмечал Log  с т.н viewpoint лучше определиться сразу. Иначе размер вашей модели может устремится к бесконечности.

Хорошо, учащиеся школы поменяю, а в общем что можете сказать по процессам. У меня была мысль разбить на бизнес процессы это Поступление, Выдача, Прием, Списание, но это тогда будет отражать другую сторону работы библиотеки, работы как по отделам например. Хотя все эти бизнес процессы грубо говоря использует тот же поиск в картотеке для той или иной ситуации. 

11
А моделирование определенно чьей точкой зрения?
я не понял что вы имели в виду, с какой точки зрения можно смоделировать вообще?

12
Вот еще декомпозиция по порядку. Не понятно по поиску, правильно ли?

13
Пишу диплом на тему автоматизация школьной библиотеки, описываю IDF0 модель AS IS  и не уверен в правильности функциональной модели. Описать нужно библиотеку без использования электронных каталогов и средства поиска. Обычные картотеки как в старых добрых библиотеках. Просмотрев примеры с использованием электронных каталогов и понял что в них описывается не сами бизнес процессы (Поступление книг и их регистрация в картотеке, Выдача прием книг, списание книг и т.д.) а общие процессы(или как то по другому) которые используются в различный бизнес процессов. Например как "поиск карточки в картотеки" для того чтобы "выяснить зарегистрирована книга или нет" или "найти книгу по запросу читателя" и т.д. Поэтому подводя черту хотел бы спросить как правильнее строить модель от чего отталкиваться и правильно ли я начал. Может быть стоит разделить на бизнес процессы?

Страницы: 1