Пишем диплом по ИТ

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

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

Как не надо делать. Перед защитой дипломов прям масть пошла! Посыпались IDEF0 со всеми типичными ошибками. Ну давайте еще поразвлекаемся разборами. Ошибка 1. Управляющие стрелки из разряда "обо всем хорошем и против всего плохого". Но ничего конкретного. "Должностные инструкции" и "Нормативные акты". Газопровод "Северный поток", который эти стрелки создают на диаграмме занимает пол-листа. Смысла и информации в них - ноль. Управляющие стрелки должны нести информацию, которая является источником конкретных требований к нашей системе...

Как у вас там сеют брюкву? С кожурою али без? (Л. Филатов. ©) Мы уже обсуждали, что есть два типа ИТ-проектов. В одних случаях причиной проекта становится проблема, которая уже случилась. В другом случае проблемы нет, но есть интерес у некоторой целевой аудитории. Подробнее об этом здесь. То есть целевая аудитория не умрет без вашего приложения, но если вы его разработаете и грамотно предложите, то оно разлетится на горячие пирожки и принесет вам счастье и прибыль. Например, вы подумали, что есть...

Когда вы начинаете изучать какую-то предметную область как аналитик, вы сталкиваетесь с кучей специальных терминов. Это названия процессов, документов, различных объектов и их состояний. Если посмотреть на рисунок, то здесь мы видим: заявления, рейтинговые списки, списки рекомендованных, приказ о зачислении и еще ряд документов. Значение одних и тех же терминов кому-то может показаться очевидным, а кому-то весьма туманным. А еще нередко вам могут попасться два термина, которые звучат почти одинаково! Например,...

О хорошем поговорили, теперь о плохом. Язык из пяти слов с одной стороны легко выучить, с другой стороны пяти слов может быть недостаточно. Какие недостатки имеются у IDEF0: 1. Отсутствие ветвлений. Это, пожалуй, самый большой недостаток. Здесь нельзя показать, что в зависимости от условия развитие событий может пойти по одному из сценариев. Но ветвления требуются далеко не во всех задачах. 2. Инструменты и исполнители никак не отличаются. И то и другое - это механизмы. А хотелось бы отличать. Потому что исполнители - это будущие роли пользователей в системе...

Еще раз напоминаю, что обязательными в IDEF0 являются входы и выходы. Механизмы и Управление - это опциональная информация, которая иногда вообще не нужна. А иногда она очень нужна. Все зависит от того оказывает ли эта информация влияние на то, как мы будем разрабатывать систему. Много горячих голов полегло в неравной битве с IDEF0, пытаясь понять разницу между входами и механизмами, потому что разница эта не очевидна. Механизм - это о том КТО? выполняет действие или С ПОМОЩЬЮ ЧЕГО? выполняется действие...

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

По англоязычной версии стандарта IDEF0 в прямоугольнике нужно писать герундий - специальная часть речи, которая называет действие. В русском языке герундию примерно соответствует отглагольное существительное. Здесь, думаю, людям сдавшим ЕГЭ по русскому, все ясно и понятно. А вот у нас в Донецке я еще несколько лет назад встречала русскоговорящих людей, которые не знают названия частей речи на русском языке! Отглагольное существительное штука коварная. Записывание, чтение, проверка, продажа - вроде слова означают действие, но выглядят, как обычное существительное...

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

Когда Денис Владимирович Пушилин не так давно сказал, что у него есть план сделать в Донецкой Народной Республике поближе к морю вторую Кремниевую долину с гениальными ИТ-стартапами, я подумала, что он вдохновился этой книгой :) Том ДеМарко - известный ИТ-специалист, который придумал нотацию для диаграмм потоков данных, да и вообще ввел понятие структурного анализа для сбора требований к программам. Как-то он взял да и написал художественное произведение "Дедлайн. Роман об управлении проектами"...

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