Найти в Дзене
Пишем диплом по ИТ

Ошибки в IDEF0

IDEF0 вы создаете не для для того, чтобы отстал вредный препод, а чтобы использовать ее дальше в работе. Для того, чтобы строить на основе диаграммы процессов весь дальнейший проект. Если в IDEF0 будут ошибки, то использовать ее будет невозможно. На ее основе потом просто ничего не построится. Какими бывают типичные ошибки? Давайте посмотрим на диаграмму (рис.1) Ошибка 1. Прямоугольник А1 "Получить задачу(выдача/заправка). Дружочки, выдать новые картриджи по подразделениям и заправить картриджи, которые уже давно выданы - это две совершенно разные задачи. И не нужно их объединять в одной диаграмме. Это все равно, что в одном рецепте пытаться рассказать, как сварить борщ и испечь торт "Наполеон".
Поэтому исправляется такая ошибка введением диаграммы более высокого уровня, на которой показаны основные подсистемы нашей системы. Можно их назвать главными процессами, если хотите (рис.2). А потом уже отдельно развлекайтесь с декомпозицией каждого процесса. Ошибка 2. Обожаю до слёз управ

IDEF0 вы создаете не для для того, чтобы отстал вредный препод, а чтобы использовать ее дальше в работе. Для того, чтобы строить на основе диаграммы процессов весь дальнейший проект. Если в IDEF0 будут ошибки, то использовать ее будет невозможно. На ее основе потом просто ничего не построится.

Какими бывают типичные ошибки? Давайте посмотрим на диаграмму (рис.1)

Рис.1 Диаграмма с кучей типичных ошибок
Рис.1 Диаграмма с кучей типичных ошибок

Ошибка 1. Прямоугольник А1 "Получить задачу(выдача/заправка).

Дружочки, выдать новые картриджи по подразделениям и заправить картриджи, которые уже давно выданы - это две совершенно разные задачи. И не нужно их объединять в одной диаграмме. Это все равно, что в одном рецепте пытаться рассказать, как сварить борщ и испечь торт "Наполеон".
Поэтому исправляется такая ошибка введением диаграммы более высокого уровня, на которой показаны основные подсистемы нашей системы. Можно их назвать главными процессами, если хотите (рис.2).

А потом уже отдельно развлекайтесь с декомпозицией каждого процесса.

Рис.2 Вводим диаграмму с основными подсистемами
Рис.2 Вводим диаграмму с основными подсистемами

Ошибка 2. Обожаю до слёз управляющие стрелки типа "Указания руководителя" (рис.1), "Руководящие документы", "Начальство"....

Люди, не пишите туда общие, ничего не значащие фразы, которые никому ничем не помогают и не дают дополнительной конкретики.

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

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

Утвержденные формы документов, технологические карты производства продукции, законы, которым должна соответствовать система, - все это важная информация, которую мы должны учитывать при разработке. Именно эту информацию следует размещать среди стрелок управления. А кто там начальник и какие распоряжения он дает - это бессмыслица, которая никак не влияет на нашу систему. Тогда зачем об этом вообще упоминать?


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

Ошибка 3. Служебная записка входит в прямоугольный блок и выходит из него (рис.1). А зачем она туда входила? В каком виде она из него вышла? В таком же как и вошла или нет? Если она вышла в том же виде, что и вошла, то непонятно зачем она туда входила.

Если она там претерпела какие-то изменения, то это должно быть отражено на выходящей стрелке. Например, она вышла со статусом "Принято". Это нормально. В блоке с ней произошла смена статуса. Но тогда так и нужно писать на выходе "Служебная записка в статусе "Принято".

Ошибка 4. Выдать и занести - это два разных действия (рис.1). И для них нужно два разных блока.

Ошибка 5. Стрелка "Отправить картридж на заправку" (рис.3)

Рис.3 Стрелка не может быть глаголом
Рис.3 Стрелка не может быть глаголом

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

Как исправить эту ерунду? Примерно вот так (рис.4)

Рис.4. Исправленный рис.3.
Рис.4. Исправленный рис.3.

Ошибка 6. Посмотрим на рис.5. Тут ошибка менее очевидная. Глаголы и существительные, вроде, на месте.

Рис.5 Что мы делаем с учениками?
Рис.5 Что мы делаем с учениками?

Есть простое правило: прямоугольник перерабатывает вход в выход. Если на входе капуста и картошка, а на выходе борщ, то это нормально. А во что мы перерабатываем учеников на рис.5? Если мы ничего не делаем с ними физически, то и не нужно их подавать на вход. Это прям негуманно как-то.
Вам на входе нужны здесь не ученики, а список учеников в виде документа. Или данные учеников в виде их личных дел.
А вот на следующих двух рисунках не грех и живого человека подать на вход:

Рис.6. Здесь все правильно. Мы же работаем с учениками непосредственно
Рис.6. Здесь все правильно. Мы же работаем с учениками непосредственно

Рис.6. Ученики вошли в блок в статусе "Оболтус обыкновенный", в прямоугольном блоке с ними работали непосредственно (а не с их данными!) и они вышли из блока в статусе "ученики , знающие китайский". Это нормально.


Или вот здесь нормально:

Рис.7 Пациента на вдохе - это нормально
Рис.7 Пациента на вдохе - это нормально

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

В общем, включаем голову, господа и будет вам счастье.