Исторический подход при разработке информационных систем предполагает проведение тщательного обследования объекта автоматизации и разработку технического проекта. Однако, с развитием информационной отрасли и разработкой множества готовых решений для различных предметных областей, появилась и другая возможность успешной автоматизации, без разработки огромного количества документации
Ниже мы разберем два подхода в проектировании будущей информационной системе:
- Классический, с разработкой детального технического проекта;
- Компактный, предполагающий моделирование работы будущей информационной системы на прототипе. Прототипом будущей информационной системы в этом случае является готовое (типовое) программное решение. В него вводятся данные контрольного примера, выполняются разнообразные сценарии работы и получаются печатные формы и отчеты.
Классический подход с разработкой технического проекта
Целью данного подхода является создание комплекта документов, определяющих требования, функционал, структуру данных, интерфейсы, входные и выходные формы будущей информационной системы.
Основные этапы создания проектной документации следующие:
- Проведение обследования. Включает в себя:
- Анкетирование будущих пользователей системы
- Интервьюирование для уточнения анкет
- Описание бизнес-процессов «как есть»
- Описание структуры используемых данных «как есть»
- Сбор функциональных требований и используемых форм документов
- Разработка проекта. Включает в себя:
- Разработку функциональной модели (модели бизнес-процессов) «как будет»
- Разработку информационной модели (структуры базы данных) «как будет»
- Разработку архитектуры решения, то есть состава модулей и подсистем, описание их взаимодействия
- Разработку сложных алгоритмов преобразования данных
- Проектирование интеграционных механизмов (для систем, которые необходимо встроить в существующий ИТ-ландшафт)
- Разработку интерфейсов (экранных форм)
- Разработку печатных форм и отчетов
В таблице ниже приведен пример реального плана работ по подготовке одного из технических проектов, разработанных компанией «Кодерлайн Софт-портал»
Таблица 1. План работ по подготовке технического проекта на разработку программного обеспечения отдела сбыта теплосети.
|
№ |
Состав работ |
| 1 | Построение расширенной и углубленной функциональной модели контура управления сбытом в формате IDEF0 на основе ранее разработанной модели АСУП и дополнительных консультаций с персоналом теплосети |
| 2 | Оформление полного перечня и образцов внешних входящих документов |
| 3 | Построение модели данных контура управления сбытом в формате IDEF1 |
| 4 | Разработка интерфейсов справочников системы 1С |
| 5 | Разработка интерфейсов электронных первичных документов системы 1С |
| 6 | Разработка алгоритмов расчетов тепловой энергии на основе консультаций с персоналом теплосети и нормативной документации |
| 7 | Разработка плана синтетических и аналитических (субконто) счетов для учета расчетов с покупателями (тепла, ТМЦ, услуг) |
| 8 | Описание плана хозяйственных операций и проводок для учета расчетов с покупателями (тепла, ТМЦ, услуг) |
| 9 | Разработка печатных форм и форм отчетов системы 1С |
| 10 | Оформление текстовой части технического проекта |
Плюсами такого подхода являются:
- Полное определение требований к будущей информационной системе, включая требования к функционалу, данным и интерфейсу системы
- Однозначное понимание требований к будущей системе у заказчика и подрядчика, так как требования изложены письменно
- Возможность достаточно точно определить трудоемкость разработки системы
Однако, у этого подхода есть и серьезные недостатки:
- Большая трудоемкость, сроки и дороговизна разработки проекта. Стоимость разработки детальной документации проекта составляет от 20 до 40% цены будущей программы
- Излишняя работа по описанию функциональных областей, на которые уже имеются готовые программные решения
- Риск, что требования, изложенные на бумаге, даже согласованные заказчиком, будут существенно изменены после того, как заказчик увидит реальный прототип системы.
Подход с моделированием работы будущей информационной системы на прототипе
В случае, если у нас имеется готовое программное обеспечение, которое можно использовать как прототип будущей информационной системы, мы можем применить другой подход для проектирования.
Целью данного подхода является проверить возможность использования готового решения на ограниченном, но разнообразном объеме данных, и выявить функциональные разрывы (дефицит функциональности). Используемый набор данных называется при этом «контрольным примером».
Основные этапы моделирования следующие:
- Разработка сценариев моделирования (сценариев контрольных примеров)
- Сбор или разработка исходных данных для контрольных примеров
- Подготовка ожидаемых результатов для проверки контрольных примеров (вручную или с помощью исторических программных систем)
- Выполнение сценариев на контрольных примерах, демонстрация результатов пользователям заказчика
- Сбор замечаний и пожеланий в процессе демонстрации, оформление протокола демонстрации
- Анализ результатов, уточнение требований и подготовка списка функциональных разрывов (функциональных дефицитов)
- Подготовка локальных технических заданий (технических решений, технических проектов) для покрытия функциональных дефицитов.
В результате получаются:
- прототип будущей системы с введенными разнообразными данными
- протокол моделирования и список функциональных дефицитов будущей системы
- локальные технические задания (технические решения, технические проекты) на доработки прототипа.
Как мы видим из описания выше, второй подход не избавляет нас полностью от необходимости разработки технического проекта. Если в прототипе отсутствует требуемый функционал, его придется разработать. И если этот функционал достаточно сложный, для него придется также подготовить технический проект. Просто объем этого проекта будет существенно меньше, чем в случае, когда техпроект разрабатывается на всю систему.
В таблице ниже представлен пример плана работ по выполнению сценариев контрольных примеров и формированию списка функциональных дефицитов реального проекта. В этом примере описано только моделирование, сценарии для которого уже готовы, а технические задания на доработки будут выполнены позже.
Таблица 2. Выдержка из плана работ по выполнению сценариев моделирования (сценариев контрольных примеров) для автоматизации бухгалтерии предприятия
|
Группа работ |
Вид работ |
|
Настройка системы |
Создание информационной базы данных |
|
Ввод организаций |
|
|
Создание профилей и пользователей по участкам учета для целей моделирования |
|
|
Настройка плана счетов на основе типового плана счетов |
|
|
Загрузка типовых классификаторов (банки, адреса, валюты, ОКОФ и т. д.) |
|
|
Моделирование вариантов налогового учета на ключевой небольшой выборке операций за 1 месяц, принятие решения о варианте налогового учета |
|
|
Моделирование по сценарию |
Ввод данных по сценарию (справочников, документов, проведение документов, получение печатных форм и отчетов), Проверка и уточнение данных по сценарию после ввода с целью достижения стыковок с другими участками учета и достижения приемлемых результатов по оборотам и остаткам |
|
Проведение совещаний с Заказчиком, обсуждение различных вариантов реализации сценариев, принятие и оформление решений |
|
|
Проведение демонстрации по сценарию, регистрация замечаний по ходу демонстрации |
|
|
Подготовка протокола демонстрации с замечаниями и пожеланиями |
|
|
Уточнение описания контрольного примера по результатам демонстрации |
|
|
Подготовка итоговых (общих документов) по договору |
Дополнение данных по регламентированному учету для управленческого учета, потребность в которых возникла в процессе моделирования |
|
Определение списка функциональных дефицитов, классификация с точки зрения доработки |
|
|
Экспертная оценка трудоемкости устранения функциональных дефицитов |
|
|
Проведение совещаний по выработке решений по функциональным дефицитам (доработка или оставить как есть) и расстановка приоритетов (очереди реализации) |
|
|
Определение источников и способов получения данных для НСИ |
|
|
Определение источников и способов получения данных для остатков БУ и НУ |
|
|
Оценка интеграции данных на основе данных, предоставленных Заказчиком |
|
|
Актуализация и согласование рабочего Плана счетов |
|
|
Подготовка и согласование схемы настроек |
У этого подхода также есть свои плюсы и минусы.
Плюсами такого подхода являются:
- Более низкая трудоемкость, короткие сроки и умеренная стоимость разработки проекта
- Отсутствие работы по описанию функциональных областей, на которые уже имеются готовые программные решения
- Возможность для заказчика увидеть работающий прототип системы и быстро сформулировать замечания к нему. Так, чтобы к моменту внедрения системы они уже были устранены.
У этого подхода есть и минусы:
- Сложность подготовки результатов контрольных примеров для проверки. Их нужно рассчитывать вручную или вводить все данные в отдельную копию старых программ
- Отсутствие проверки работы системы на полном объеме данных и на всех возможных сценариях. Вследствие чего есть риск не выявить все функциональные дефициты.
Сравнение двух подходов в проектировании информационных систем
В таблице ниже приведено сравнение двух подходов
|
Критерий |
Технический проект |
Моделирование на контрольном примере |
|
Цель |
Полное документирование требований |
Выявление функциональных дефицитов прототипа |
|
Сроки |
Длительный (месяцы-годы) |
Короткий (недели-месяцы) |
|
Затраты |
Высокие |
Умеренные |
|
Результат |
Комплект документации |
Прототип с данными контрольного примера + документация |
|
Риски |
Существенное изменение требований |
Неполнота покрытия сценариев контрольных примеров |
Рекомендации по выбору подхода в реальной практике
Какой из подходов выбрать обычно определяет заказчик будущей системы. Зачастую выбор «делаем техпроект» обусловлен исторически сложившейся на предприятии практикой. Однако, если выбор производится не на основе каких-то устоявшихся стандартов, а по рациональным соображениям, можно рекомендовать следующий подход.
В случае, если
- для автоматизируемой предметной области существует готовое программное обеспечение
- это программное обеспечение покрывает более 70% требуемого функционала
лучше всего выбрать подход с моделированием на прототипе и разработкой локальных технических решений.
В случае же, если
- для предметной области нет готовой программы
- или готовая программа несовершенна и не покрывает основные потребности предприятия
лучше всего будет разработать полноценный технический проект.