Среди множества препятствий, которые приходится преодолевать руководителям
проектов, системным аналитикам и начальникам отделов автоматизации, можно
выделить ряд характерных проблем, связанных с технологией ведения разработок.
Основные трудности, как правило, обуславливаются следующими печальными
необходимостями:
а) закончить проект в срок;
b) уложиться при этом в бюджет;
c) обойтись имеющимися силами и ресурсами.
И, конечно, не принимая во внимание законы Мэрфи, управленцы верхнего
уровня оказывают давление на руководителей информационных подразделений
или отдельных проектов, требуя от них выполнения всех перечисленных выше
условий.
Что мешает решать внешние проблемы? Правильно, проблемы внутренние.
Например, трудности, возникающие при вхождении в команду, которая занимается
некоторым проектом, нового человека. Особенно остро эта проблема встает
в том случае, если происходит замена некоторого участника проекта новым
сотрудником. Новичку бывает непросто понять и место проекта в инфраструктуре
компании, и смысл поставленных конкретно перед ним задач в контексте проекта.
Как сделать процесс присоединения к команде разработчиков нового специалиста
более гладким? Как избавить его от необходимости терроризировать коллег
многочисленными вопросами, вызывая у них, возможно, не вполне справедливое,
но вполне понятное раздражение?
Ответ кажется очевидным – необходимо тем или иным способом документировать
процесс ведения проекта и сделать эту документацию доступной всем заинтересованным
членам команды. Однако словесное описание было бы через чур пространным.
Ни у одного руководителя не хватит упорства для того, чтобы заставить одних
сотрудников написать достаточно подробный текст, а других сотрудников этот
текст прочитать. Необходима некоторая методология, некий язык, позволяющий
достаточно лаконично документировать проекты. Лаконичность обеспечивает
легкость восприятия, но это только одна сторона медали. Кроме того, методология
должна облегчать не только процесс чтения проектной документации, но и
процесс ее создания. В противном случае будет очень нелегко добиться того,
чтобы удовлетворительная проектная документация была создана участниками
проекта.
Какие существуют формальные языки? Например, для работы с базами данных
используется язык SQL, для написания драйверов – Ассемблер. Аналогично,
методологии проектирования содержат собственные, специальные языки (нотации)
. Одна из таких нотаций – IDEF0.
Методология IDEF0, разработанная в недрах НАТО и впоследствии ставшая
федеральным стандартом США, в настоящее время применяется сотнями тысяч
специалистов во всем мире. Большинство применений связано с построением
систем для бизнеса, производства, обороны, связи и организации проектирования.
Где можно ознакомится с этой методологией и реализующими ее инструментальными
средствами? В Учебно-консалтинговом центре компании Interface Ltd. был
разработан и читается курс "CASE-технологии и CASE-средства". Этот курс
в свою очередь состоит из двух основных частей: "Анализ и моделирование
бизнес-процессов в стандарте IDEF0" и "Моделирование и проектирование баз
данных с помощью ERwin". Курсы ориентированы на руководителей информационных
служб, системных аналитиков и разработчиков прикладных программ.
Изучив и научившись использовать методологии проектирования информационных
систем и документирования проектов, можно сделать качественный проект.
А что такое качественный проект? Это проект, который позволяет решать стоящие
перед заказчиком задачи, причем этот проект должен быть реализован в установленные
заказчиком сроки и не выходить за рамки выделенного на него бюджета. Современные
крупные организации (такие, как банки, промышленные предприятия, государственные
структуры) достигают поистине гигантских размеров, а процессы, происходящие
в них, бывают настолько сложны и запутаны, что даже сами руководящие работники
этих предприятий часто не вполне ориентируются в них. Разработчики, создающие
информационную систему для такой структуры, попадают в достаточно непростую
ситуацию. В этих условиях необходим специальный инструментарий для изучения
и моделирования процессов, происходящих на крупных предприятиях, а также
для последующего проектирования баз данных.
Interface Ltd. предлагает для решения подобных задач CASE-инструментарий
компании Logic Works, признанного лидера в области средств моделирования
данных и бизнес-процессов. Продукты BPwin, ERwin, ModelMart, TEST/Bytes,
а также анонсированный недавно OR*Compass являются интеллектуальными инструментами,
автоматизирующими весь цикл создания приложений - от изучения предметной
области до тестирования готового продукта. Пользуясь этими CASE-средствами,
разработчик может сначала ввести и систематизировать информацию о предметной
области (для этого применяется BPwin), потом, основываясь на выявленных
связях и структурных особенностях, автоматически сгенерировать файлы БД
(ERwin). ModelMart же является средой коллективного управления моделями,
созданными в BPwin и ERwin, и обеспечивает многопользовательский доступ
к ним.
Итак, решено: приобретаем CASE-средства и проходим необходимые учебные
курсы. Но как убедить упрямого коллегу поддержать эту инициативу, а упрямого
шефа профинансироваь ее? Рассмотрим несколько характерных контраргументов
и приведем возражения на них.
Контраргумент 1. "Я могу сам спроектировать свою задачу"
Ошибки, которые возникают из-за этого заблуждения, наиболее часто встречающаяся
и поддается коррекции хуже всех остальных. Если модель бизнес-процессов
спроектирована с ошибками, если детально не проанализированы все возможные
варианты, то структуру модели приходиться часто корректировать, вносить
изменения. Это приводит к затягиванию сроков реализации, перерасходу средств
и как следствие влечет за собой существенное снижение эффективности и процесса
разработки, и его результата.
Контраргумент 2: "Хорошо, я понимаю, что для того, чтобы спроектировать
задачу, мне нужна некоторая методология, но ведь на сомом деле мне нужна
только хорошая структура БД". И еще: (Контраргумент 3) "Я понимаю, что
для успешного выполнения проекта нужно уметь построить структуру БД и функциональную
модель, но я могу сделать это на листе бумаги, придумав свою методологию".
Стоит ли придумывать велосипед? Лучше, изучив принципы построения велосипедов
(методологию), создать мотоцикл, т.е. используя уже разработанные методологии,
создавать на их основе реально работающие проекты.