Предпроектное обследование. 
Проектирование автоматизированных систем обработки информации и управления

Цели и задачи предпроектного обследования

Основная цель АСОИУ — качественная, количественная и временная оптимизация информационных потоков (процессов обработки информации) на объекте автоматизации.

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

Внедрение АСОИУ обеспечивает для организации, в частности, следующие возможности:

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

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

«Характер потоков информации зависит от объекта управления и функций управления: от источника возникновения и пунктов, куда поток направляется: от материальной формы потока, т. е. носителя информации, способа передачи и индикации; от объема (количества) информации; от частоты поступления и скорости передачи» [34, с. 281].

К задачам предпроектного обследования относятся следующие.

• 1. Исследование основных бизнес-процессов на объекте автоматизации, где предполагается внедрение системы организационно-управленческого типа, либо процессов обработки инженерной и (или) научной информации, если основное назначение системы заключается в автоматизации именно этих процедур. При этом выявляются:
  • • процессы, содержащие избыточное количество шагов между начальной и конечной точками;
  • • процессы, включающие дублирующие процедуры;
  • • процессы, выполняемые по морально устаревшим схемам, т. е. «по инерции», хотя производственной или управленческой необходимости в них уже нет;
  • • процессы, которые необходимо структурно регламентировать в графическом виде и (или) описать в форме документов;
  • • процессы, требующие унификации.
• 2. Выявление тех особенностей в деятельности объекта автоматизации, которые являются уникальными и поэтому обязательно должны поддерживаться в условиях АСОИУ.
• 3. Формирование совокупности задач, которые будут реализованы в АСОИУ (функциональность АСОИУ).
• 4. Определение бюджета и длительности проекта (зависит от объема функциональности).
• 5. Оценка работ по интеграции проектируемой АСОИУ с уже находящимися в эксплуатации на объекте автоматизации автоматизированными системами разных типов.
• 6. Оценка работ по обеспечению взаимодействия проектируемой системы с внешними по отношению к объекту автоматизации системами.
• 7. Выявление потребностей в количественном и качеством составе аналитической информации для всех уровней управления, а также информации, необходимой для принятия решений по результатам обработки разнообразной информации, которая относится к задачам соответствующей научно-исследовательской деятельности.
• 8. Выявление замечаний со стороны пользователей разного профессионально-квалификационного и управленческого уровней к качеству и количеству используемой в настоящее время информации для решения текущих задач.
• 9. Оценка возможных рисков, например:
  • • часто меняющиеся требования заказчика, что может обусловливаться неумением их корректно сформулировать и недостаточной компетентностью экспертов (исключение представляют гибкие технологии разработки ПО);
  • • недостаточный бюджет;
  • • жесткие временные рамки проекта;
  • • слишком большой объем реализуемой функциональности при заданных сроках проекта и его бюджете;
  • • использование недостаточно апробированных информационных технологий;
  • • недостаточные квалификация и опыт разработчиков.

Предпроектное обследование объекта автоматизации необходимо проводить в следующих случаях:

• • создание АСОИУ по «индивидуальному заказу»;
• • внедрение готовой системы (исследовать, насколько бизнеспроцессы на объекте автоматизации соответствуют тем, поддержание которых обеспечивается приобретаемым программным решением);
• • внедрение дополнительных модулей «родной» системы или «иногородней»;
• • функциональная и (или) технологическая модернизация существующей системы;
• • внедрение дополнительных автоматизированных систем к тем, которые уже функционируют на объекте автоматизации.

По результатам предпроектного обследования должны быть:

• • предварительно оценены необходимые для реализации проекта ресурсы и сроки его выполнения;
• • графически представлены и критически проанализированы существующие процессы или бизнес-процессы (с использованием, например, UML-диаграмм);
• • сформулированы функционально-технологические требования к АСОИУ, т. е. определена совокупность задач и их информационные взаимосвязи как внутри проектируемой системы, так и при ее взаимодействии с внешними системами.

С точки зрения оптимизации информационной поддержки бизнеспроцессов в условиях будущей АСОИУ могут быть выработаны рекомендации по их изменению, включая элементы реинжиниринга, например:

• • объединение нескольких «мелких» или смежных работ процесса в одну;
• • выполнение процессов в порядке, соответствующем бизнеслогике той деятельности, за которую отвечает подразделение (иногда процессы в силу разных причин бывают неоправданно «раздутыми» по количеству шагов);
• • предложение различных версий выполнения процесса, способствующих сокращению его длительности и трудоемкости, а также более четкой регламентации сути самого процесса;
• • изменение места выполнения процесса, руководствуясь его экономической и логической целесообразностью.

Цели и задачи предпроектного обследования являются основой для выполнения самого сложного и важного процесса «Формулирование требований к будущей системе».

«Несмотря на более чем пятидесятилетнее существование компьютерной отрасли, многие компании-разработчики программного обеспечения по-прежнему прикладывают значительные усилия для сбора, документирования и управления требованиями к ПО. Недостаточный объем информации, поступающей от пользователей, требования, сформулированные не полностью, их кардинальное изменение и неправильно понятые бизнес-цели — вот основные причины, из-за которых зачастую командам, работающим в области информационных технологий, не удается успешно завершить проект» [6, Введение].

Под разработкой требований авторы понимают такую последовательность действий:

• • выявление;
• • анализ;
• • документирование;
• • утверждение.

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