Этапы Большого пути
Или как подходить к организации работ по созданию информационной системы

       Любое современное предприятие использует в своей повседневной практике вычислительную технику и разнообразное программное обеспечение. По мере изменения некоторых условий (появление новых требований к производству, учету, управлению и т.п.) возникает необходимость в новых программных продуктах или информационных системах.

Решается возникшая проблема, как правило, несколькими способами:

  1. Приобретение готовой системы;
  2. Приобретение системы с проведением работ по ее адаптации к требованиям предприятия;
  3. Разработка программного продукта собственными силами;
  4. Размещение заказа на производство программы.

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

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

       Общая схема производственного цикла может быть выражена следующими этапами:

  1. Предпроектное обследование;
  2. Формирование технического задания;
  3. Проектирование пользовательских приложений;
  4. Тестирование;
  5. Опытная эксплуатация;
  6. Внесение корректировок;
  7. Сдача работ.

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

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

Таблица 1. Предубеждения, свойственные заказчикам и исполнителям

Заказчик	Исполнитель
1. Имеет собственное мнение "Что надо".	1. Имеет опыт, необходимый для решения проблем в рамках поставленной задачи.
2. Имеет собственное мнение "Как надо", т.е. уверенность в "полном" понимании бизнес-процессов на предприятии.	2. Владеет информацией о технологиях, подходах и способах построения аппаратно-программных комплексов, программного обеспечения, ведения проектов.
3. Уверен в "уникальности" процессов по отношению к профильным предприятиям.	3. Имеет опыт использования механизмов проектирования и программирования информационных систем.
4. Уверен в способности определить точное значение продолжительности работ.	4. Имеет опыт проведения консалтинговых работ.
5. Не стремится к смене установленных правил, методик, подходов.	6. Часто не рассматривает второстепенную, но существенную для структуры системы информацию о предприятии заказчика.
6. Имеет предубеждения (отчасти обоснованные) к консалтинговым предложениям.	7. Проектирует структуру информационной системы, в большей степени, на основании собственных представлений.
7. Неохотно включается в процесс проектирования технического задания, связанного с разработкой всех алгоритмов и методов.	8. Игнорирует организацию "тестирующего конвейера" для разрабатываемой системы.
8. Проявляет активность в получении "результата", и пассивность в постоянной поддержке "взаимоотношений" на всех этапах работ.	9. Зачастую недооценивает необходимость интеграции стороннего программного обеспечения в проектируемую систему.
9. Имеет целый ряд дополнительных "сдерживающих" факторов.	10. Часто, допускается не правильный выбор "уровня решений" по отношению к "уровню решаемой задачи".
10. Использует штампы, словосочетания и т.п. принятые на предприятии, т.е. своеобразный язык для описания производственных процессов (Метаязык -1)	11. Использует штампы, словосочетания и т.п принятые в собственной профессиональной среде, т.е. своеобразный язык для описания структуры систем (Метаязык -2)

       Таким образом, до начала проведения работ неявно присутствует потенциальный "конфликт взаимодействия" между заказчиком и исполнителем. Для разрешения данного конфликта можно предложить несколько путей. Рассмотрим наиболее типичные из них.

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

Результат: Программное обеспечение отвечает "общим" требованиям. Неявно выраженные требования Заказчика так и не решены. Пользовательские приложения "не адаптированы" под реальные потребности. Программное обеспечение соответствует техническому заданию, а само ТЗ соответствует договору, но договор имеет обобщенные черты. Программное обеспечение не покрывает полностью потребности Заказчика. Возникают двухсторонние претензии.

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

  1. Конечный результат работы - получение работоспособной информационной системы.
  2. ИС должна решать поставленные задачи с предоставлением новых возможностей.
  3. Необходима реорганизация бизнес-процессов, участвующих в решении.
  4. Ответственность за конечный результат в равной степени распределяется между всеми участниками проекта, т.е. между сотрудниками Исполнителя, и сотрудниками Заказчика.

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

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

  1. Первый этап - техническое задание, методика работы и развития системы. Формирование "договора №01" на основе "базовых" требований Заказчика.
  2. Второй этап - программные модули, входящие в систему. Формирование "договора №02" на основе технического задания, подготовленного по итогам предыдущего этапа.
  3. Третий этап - предложения по развитию системы. Формирование "договора №03" на основе "новых базовых" требований и возможностей эксплуатируемой системы.

Данный подход направлен на достижение следующих целей:

  1. Снижение рисков на всех этапах проектирования информационной системы.
  2. Зависимость финансирования проекта напрямую от динамики его реализации.
  3. Получение нескольких "ключевых" (контрольных) точек для контроля над реализацией проекта и его финансирования.
  4. Организация "защищенности" участников проекта от событий, способных сделать проект "нецелесообразным".

Возможная схема проведения работ:

  1. Первая встреча. Цель - выявление общих требований к системе, подбор специалистов со стороны Заказчика, обладающих полномочиями и желанием участвовать в проекте.
  2. Организация совместной группы. В задачи группы должно входить: проведение предпроектного обследования, предшествующего появлению "договора №01", на базе материалов отражающих текущее состояние дел ("как есть"), с целью получения ТЗ ("как будет").
  3. Закрытие договора №01. Контрольная точка принятия решения о дальнейшей целесообразности и возможности построения информационной системы с заданными требованиями. Производится логическое тестирование технического задания с целью выявления "слабых" мест в системе; разработка документа, отражающего этапы программирования, требования к программным модулям, потребности в реорганизации бизнес-процессов и иные консалтинговые предложения. Окончание этапа - подтвержденное техническое задание, сетевой график работ по программированию, тестированию и вводу в эксплуатацию модулей системы.
  4. Программирование информационной системы. Проектирование программных модулей согласно графика, созданного на предшествующем этапе. Тестирование на уровне Заказчика, тестирование на уровне Исполнителя. "Пробная" эксплуатация модулей системы. Ввод в эксплуатацию. Подготовка документации для пользователей и технических описаний по введенным в эксплуатацию программным модулям. Закрытие выполненных работ.
  5. Закрытие договора №02. Формирование отчетов по модулям системы. Предоставление методик, рекомендаций по эксплуатации ИС. Предоставление ER-модели структуры БД, описание проектных отношений таблиц, их структуры и структуры логических отношений. Предоставление рекомендаций по развитию системы.

Итоговые результаты

1. Работа разделена на два логического этапа: этап проектирования модели системы и этап ее воплощения. При этом каждый этап является самостоятельным и его окончание обусловлено выпуском соответствующего "законченного продукта".   2. В совместную группу входят сотрудники Заказчика, имеющие полномочия и заинтересованность в конечном результате.   3. Техническое задание отражает как требования к системе, так и необходимые ресурсы.   4. Работы по программированию ведутся согласно сетевого плана-графика реализации, с отражением необходимых ресурсов на каждом этапе выполнения работ.   5. Поэтапный ввод в эксплуатацию частей системы предоставляет возможность начать использование программных модулей на самых ранних этапах. Это, в свою очередь, позволяет более равномерно осуществлять подготовку персонала, его адаптацию к новым требованиям и возможностям.   6. Структура системы предполагает функциональное развитие.   7. Выполненные работы документированы, присутствует общее описание структуры базы данных, каждый программный модуль имеет техническое описание и руководство пользователя.

© Москва 1999г. НПФ "И.В.А." В.Горшков