Методологии разработки систем электронного управления

Методологии разработки систем электронного
управления
1.
Методологии разработки информационных систем
Методологии, а точнее методологии развития систем на протяжении жизненного цикла,
предоставляют рамки и процедуры, согласно которых можно исполнять огромное количество
заданий, связанных с развитием электронного управления. Большинство методологий касаются
всего цикла деятельности по развитию: от инициации проекта и до его проверки после введения в
действие. Методология для развития системы является формальным и структурированным
подходом, содержащим и описывающим поочередно все этапы, задания и суждения, необходимые
для успеха проекта. Рамки и ряд процедур обеспечивают тщательное планирование, контроль и
утверждение каждой фазы разработки, соответствие каждой фазы ряду стандартов, адекватной
документирование каждой фазы, а также должное обеспечения сотрудниками каждого этапа
разработки.
С точки зрения управления и контроля, методологии информационных систем
•
Используют в качестве ссылок опыт экспертов и других разработчиков систем, таким
образом, предоставляя менеджерам, недавно участвующим в процессе, список шагов,
которые нужно предпринять, и вопросов, на которые нужно найти ответы для того,
чтобы способствовать развитию информационных систем.
•
Предоставляют исторические записи процесса разработки путем использования
формальной методологии и требуемой документации, которую можно использовать
для дальнейшего планирования и оценки информационных систем.
•
Позволяют пользователям-менеджерам иметь больше контроля над прогрессом
проекта и, таким образом, повышают используемость конечного результата.
•
Дают возможность перевода дизайна из одного приложения в другое и перевод
персонала из одного проекта в другой.
Поэтому, важно чтобы разработка систем электронного управления проводилась согласно
ряду формальных процедур или методологий.
Перед разработкой системы электронного управления, нужно провести и глубинную проверку
рабочих процессов, связанных с этой системой, включая взаимодействие между
правительственными агентствами. Информационные системы разрабатываются
для
компьютеризации и реструктуризации связанных рабочих процессов для увеличения
эффективности, оперативности и продуктивности работы правительства. Очевидно, что без
рационализированных рабочих процессов или потока рабочих операций не может быть
рационализированного потока информации внутри одного правительственного агентства или
между несколькими из них. Это послужило причиной того, что Реорганизация Рабочих
Методологии развития систем электронного управления
Процессов (BPR) и реструктуризация стали очень популярными с 1980-х годов в индустриальных
странах.
Существует три разных типа разработки информационных систем, каждый из которых
приводит к конкретному типу систем:
•
Информационные системы, которые имеют программное обеспечение, созданное по
заказу, т.е. программное обеспечение для системных приложений изготавливается
под заказ для удовлетворения специфических потребностей пользователей
информационными системами, которые должны быть разработаны.
•
Информационные системы, которые используют коробочное программное
обеспечение, т.е. программное обеспечение, разработанное третьей стороной, либо
продавцами, либо консультантами, и которое используется в качестве основного
программного обеспечения. Конечно, некоторое количество работы под заказ должно
быть осуществлено.
•
Информационные системы, реорганизованные из существующих ранее, т.е.
существующие коды и данные, реорганизованные и переведенные в новую
передовую технологическую среду и платформу программного обеспечения целью
модернизации и улучшения набора функций существующих информационных
систем. Или же приведение «систем старого образца» в соответствие с современной
системой путем использования связующих продуктов.
С развитием технологии программного обеспечения информационные системы все чаще и
чаще разрабатываются с помощью коробочного программного обеспечения. Независимо от того,
какой тип информационной системы из указанных выше разрабатывается, нужно применить
подходящую методологию создания информационной системы для того, чтобы обеспечить успех
разработки системы.
Существует четыре отдельных метода разработки систем, а именно:
1. Метод, ориентированный на данные используется, когда данные/информация,
необходимые для выполнения функции учреждения, формируют базу изменения
системы. Метод, ориентированный на данные подходит для обработки больших
негомогенных объемов информации и интенсивно динамических процедур.
2. Функциональный метод, используется, когда элементы структуры организации
(функции) и их совместная коммуникация формируют базу. Функциональный метод
подходит для обработки сложных процедур со многими поверхностями или точками
контакта и правилами обработки. Также, этот метод хорошо подходит для задач,
получивших хорошее определение.
3. Эволюционный метод, который включает в себя последовательную разработку. Части
системы высшей приоритетности вводятся перед введением частей низшей
приоритетности, но таким образом, чтобы все части системы формировали часть
запланированного общего. Эволюционный метод подходит для пофазового запуска
систем, или в случаях, когда некоторые части системы имеют большую важность,
чем другие. Также этот метод хорошо подходит для сложных систем.
4. Метод разработки прототипа, используется, когда нужна функционирующая модель
будущей системы. Метод разработки прототипа подходит для очень
неструктурированных задач, например, динамической среды, экспериментальных
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 2 из 15
Методологии развития систем электронного управления
ситуаций, диалоговых систем, а также для подготовки организаций внедрению систем
электронного управления. Разработка прототипа – это метод, в котором разработка
тестовых версий (прототипов) системы производиться на очень раннем этапе. Этот
метод также называется экспериментальной разработкой системы, разработкой
системы с прототипами, или разработка интерактивных систем.
Выбор метода развития системы базируется на оценке общих результатов в этих 4 главных
сферах и принимает следующее во внимание: природу заданий, причастную организацию,
доступную технологию и работники, к которым относятся пользователи и технического персонала
2.
Создание системы электронного управления
Эффективная и оперативная разработка систем электронного управления базируется на
многих факторах, включая понимание требований пользователей и способность определить
самые эффективные средства для их удовлетворения. Первое требует детальных знаний и
профессиональных умений в пользовательском деле. Это существенно и требует наличия и
участия менеджеров и пользователей с экспертными знаниями своего дела. Последнее,
определяя средства, с помощью которых можно удовлетворить требования пользователей,
требует участия аналитиков систем электронного управления, имеющих экспертные знания в
сфере современной технологии. Таким образом, разработка системы электронного управления
требует дизайнерского сотрудничества: пользователи предоставляют дизайн рабочих
процессов, а аналитики систем электронного управления предоставляют технический дизайн.
Это несложно описать, но на практике очень нелегко выполнить. Разработка системы
электронного управления, также как и анализ рабочих процессов, в лучшем случае неточная наука,
и такая, что сильно зависит от ясного, точного и четкого обмена информацией и идеями между
пользователями, аналитиками и разработчиками. Для достижения успеха в разработке системы
электронного управления нужно следовать методологиям разработки систем электронного
управления, которые подытоживают и объединяют опыт предыдущих системных разработок,
независимости от их успеха.
Для эффективного исполнения любой задачи или нескольких задач, команда должна иметь
план или расписанную процедуру работы. Без этого все действия совершаются случайно и с
малым уровнем координации, или вообще без нее. Результаты таковы, что разные
промежуточные продукты редко когда сочетаются в одно связное целое, но хуже того, готовый
продукт редко соответствует изначальным его спецификациям. В некоторых случаях, по причине
отсутствия рабочего плана, отсутствуют изначальные спецификации. Детальные рабочие планы
для разработки систем электронного управления называются методологиями. Фактически,
методология – это система принципов, практик, и процедур, которые применяются для и получают
информацию из конкретной области знаний. Как было упомянуто во вступительном абзаце,
методологии предоставляют рамки и процедуры, согласно которых можно исполнять огромное
количество заданий по разработке. Большинство методологий касаются всего цикла деятельности
по развитию: от инициации проекта и до его проверки после введения в действие.
Разработка систем электронного управления ведет увеличению продуктивности и к качеству
системных разработок. Некоторые из значительных вопросов, связанных с развитием
информационных систем, решаются методами разработки систем электронного управления
описанным ниже образом.
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 3 из 15
Методологии развития систем электронного управления
2.1 Управление данными и информационными ресурсами
Разработка систем электронного управления придает большое значение управлению данными
и информационными ресурсами и является мощным средством для установления функций по
управлению данными и информационными ресурсами в организации. Управление данными – это
функция, которая определяет стандарты, распоряжение и контроль информации в организации.
Управление информационными ресурсами имеет сходную цель с управлением данными, но
также включает в себя планирование, организация, и контроль данных и моделей и дизайнов
процессов, определяя конфигурации технического, программного обеспечения и сетевых
средств, а также обучение людей, что является необходимым для поддержки систем
электронного управления организации.
2.2 Продуктивность и качество системы
Увеличение продуктивности наряду с плохим качеством не принесет желанных результатов
электронного управления; продуктивность и качество нужно повышать одновременно. Разработка
систем электронного управления делает акцент на качестве и обеспечивает его путем
фиксирования требований рабочего процесса перед созданием каких-либо решений. Точность в
технологиях и фазах этой методологии обеспечивает поддержание должного уровня качества на
протяжении всего процесса до завершения внедрения. Хотя установление и поддержка функций
управления информационными ресурсами стоит организации значительных ресурсов, увеличение
продуктивности системных разработок с использованием разработок систем электронного
управления более чем покрывает эти инвестиции.
2.3 Управление изменениями и эволюция
Разработка систем электронного управления предоставляет механизм, с помощью которого
можно управлять изменениями в организации. Добавление, удаление или пересмотр рабочего
правила требует оценки модели данных и процессов в широкой перспективе. Это может
привести к модификациям многих систем. Изменения в технологии или системных требованиях
требуют модификации системных разработок, а также уже внедренным системам. Разделяя
аспекты управления изменениями, не зависящие от технологии, и процессы, зависящие от
технологии, поддержание системы является эволюционным процессом, позволяющим
организации контролировать ее собственную судьбу.
2.4 Переход к альтернативной архитектуре
После развития для функциональной области моделей данных и процессов, не зависящих от
технологии, они предоставляют основу для разработки и внедрения системы. В некоторых
случаях, целевая среда для внедрения конкретной функциональной области может быть
указана. Во многих ситуациях, все же, модели данных и процессов становятся базой для оценки
альтернативных технологий. Это позволяет организации выбрать оптимальные конфигурации
технического и программного обеспечения и сетей на основании доступных бюджетных средств для
того, чтобы удовлетворить собственные нужды. Возможно, потребуется больше, чем одна целевая
среда для удовлетворения рабочих потребностей, описываемых моделями данных и процессов.
Вместо того, чтобы просто связывать все эти окружения, их можно полностью интегрировать, таким
образом, используя ключевые преимущества каждой среды.
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 4 из 15
Методологии развития систем электронного управления
2.5 Реорганизация и обратный инжиниринг
Реорганизация делает акцент на рационализации рабочих процессов организации для
полноценного использования современной информационной технологии и применяет подход
«сверху вниз» к построению моделей данных и процессов. Он дает результаты высокого
качества за короткое время, также обеспечивая понимание пользователей. Для организаций, в
которых поточные системы не эффективно документированы, возможно, понадобится подход
«снизу вверх», обратный инжиниринг. Разработка систем электронного управления использует
нормализацию рабочих процессов и принципы обратного инжиниринга для изъятия дизайнов баз
данных из структуры данных и программного кода, и создает модели данных и процессов,
независимые от технологии, которые способны адаптироваться к разным платформам,
зависящим от технологии. Этот процесс обратного инжиниринга целесообразный для
организаций, не находящихся в процессе изменений в работе в силу регуляторных или других
препятствий.
3.
Разработка структурированных систем электронного
управления
Разработка систем электронного управления дает организации возможность
максимизировать преимущества, получаемые от возникающих технологий. Полученные
преимущества охватывают спектр от нового понимания стратегического видения работы
организации до детального планирования и оптимального использования новых технологий. Но
возможно достичь как кратковременной, так и долговременной выгоды. После утверждения
прибыль от инвестиций во внедрение разработок систем электронного управления обеспечивает
не только продуктивность и качество, но и долгосрочный успех организации.
И по этой причине, данный модуль делает короткое введение в
методологию
структурированной разработки и развития систем электронного управления, которая является
одной из самых важных технологий разработки систем электронного управления и очень
полезна, в частности для больших и сложных разработок систем электронного управления. С
уменьшением масштабов проекта, появляется возможность комбинирования некоторых фаз
разработки.
Припуская, что проект по электронному управлению проходит нормально и слаженно, от него
можно ожидать следующих общих фаз:
•
Инициация проекта.
•
Анализ требований, включая анализ работы, оценка существующих системных
компонентов, идентификация проблем и анализ возможности применения
альтернативных подходов; логическая разработка, включая реорганизацию потока
рабочих процессов и разработку архитектуры системы.
•
Физическая разработка, включая спецификации технического и программного
обеспечения и средства коммуникаций, дизайн и схема проводки сети, а также
безопасность системы.
•
Внедрение, Включая установление баз данных, механизма ввода данных и
разработку программного обеспечения для приложений.
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 5 из 15
Методологии развития систем электронного управления
•
Функционирование, включая слитие системы с нормальным рабочим окружением,
обновление данных и обслуживание системы.
•
Оценка эффективности после запуска.
Существует много разных способов определения фаз жизненного цикла процесса
разработки информационной системы. Но все их можно упростить до трех главных стадий:
анализ, разработка и внедрение. Все эти три стадии окружены (им предшествуют и за ними
следуют другие) инициацией проекта и его проверкой. Вдобавок, все эти действия включают
административные задачи планирования, создания графика работы и контроля.
3.1 Предварительный анализ
Инициация проекта осуществляется с помощью предварительного анализа. Этот анализ
ложиться в основу первой и, возможно, самой важной стадии разработки и развития проекта. Во
многих случаях, она сама стает полным проектом, поскольку информация, наработанная на этом
этапе, может указывать на то, что любая дальнейшая работа не является нужной, реальной или
желанной. Во всяком случае, результаты фазы предварительного анализа определяют то, есть
ли проблема, требующая решения, есть ли действенное решение этой проблемы, и
целесообразна ли разработка решения для этой проблемы с позиций экономии средств и с
позиций правительственного агентства в целом.
Главной целью предварительного анализа является решить нужно или не стоит
инициировать проект для разработки системы электронного управления, требуемой
пользователями. Даже на этом раннем этапе результаты исследования определят
достаточность ожидаемой выгоды для оправдания перехода к следующим стадиям проекта.
Детальный анализ касается следующего:
•
Поточных проблем, которые нужно устранить из пользовательской среды и
пользование поточными и будущими возможностями.
•
Определения миссии системы и формулировка рабочих потребностей пользователей в
понятной системе задач рабочего процесса.
•
Установление ограничителей для области изучения проекта.
•
Идентификация возможных преград и рисков проекта.
•
Изначальный поиск потенциальных решений по внедрению системы.
•
Анализ рентабельности.
При определении текущих проблем, обычно много внимания уделяется тому, как
информационная технология может быть использована для повышения эффективности,
оперативности, продуктивности и качества работы правительственных агентств. Но этого далеко
не достаточно. Нужно придавать особое значение проверки поточных рабочих процессов
организации для того, чтобы проверить их совместимость с целью, для которой их было применено.
Новая система электронного управления должна быть интегрирована с существующей рабочей
средой только при условии, что такая интеграция оправдана ощутимой оперативностью
существующих рабочих процессов. В противном случае, нужно принять решение относительно
реорганизации рабочего процесса.
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 6 из 15
Методологии развития систем электронного управления
Проблемы и/или возможности, определенные или описанные пользователями, должны быть
расставлены по порядку их важности. Такая классификация необходима для проведения линий
отличия между вопросами, являющимися действительно важными, и теми, которые, хотя и полезно
решить, не весомы для текущего проекта. Среди способов, которыми их можно категорировать,
есть такой:
1. Существенные. Без удовлетворения таких требований пользователи не могут
должным образом работать в деловой среде.
2. Приспосабливаемые. Этот требования, которые при необходимости можно частично
модифицировать для создания альтернативных рабочих режимов.
3. Желательные. Таковыми являются требования, о которых пользователь имеет
желание заявить, но они могут не войти в список требований системы, если
удовлетворение их влечет за собой значительные расходы.
Задачи проекта должны быть направленными на проблемы и/или возможности,
определенные во время анализа существующей ситуации. Задачи проекта должны быть
сформулированы в кратком, сжатом и понятном формате.
По существу, на этой стадии нужно провести формальное исследование возможности запуска
проекта. С помощью такого исследования проектной команде и руководству организации
пользователей нужно согласовать масштаб проекта. В отчет об исследовании включаются
аргументы, оправдывающие проект, четко очерченные границы разработки и развития, а также
рабочий план, показывающий каким образом нужно завершить разработку.
3.2 Анализ требований
Анализ требований имеет цель обнаружить то, чего желают и в чем действительно
нуждаются пользователи; определить продукты, нацеленные на удовлетворение весь ряд
желаний и установить, кто должен опалить главную часть процесса. Очевидно, анализ
требований критически важен для успешной разработки системы электронного управления,
поскольку, если разработчики системы не знают, что нужно пользователям (предприятиям или
гражданам) ил и не имеют адекватного обмена информацией с пользователями функции и
работа системы не могут быть корректно определены. Любая система электронного управления,
несоответствующая потребностям конечных пользователей, будет существовать недолго.
Определение требований начинается с тщательного анализа существующего потока рабочих
процессов и организационных структур, относящихся к предлагаемой системе. Путем сбора данных
и опроса пользователей системы, которую предстоит создать, анализ нацелен на поиск ответов
на вопросы, выведенные в последующих разделах.
3.3 Действия в рамках этапа анализа
Самым важным способом проведения анализа требований является опрос пользователей, в
частности людей, причастных к рабочему процессу, и конечных пользователей системы. Для
разных уровней системы электронного управления нужно выбирать разные уровни
пользователей для опроса. Во время опроса пользователей, ключевыми задачами являются
полностью изучить работу пользователя, понять терминологию пользователя и поставить только
нужные вопросы. Логической последовательность опроса является
•
Во-первых, узнайте информацию о потоках рабочих процессов и информации в
организации. Начните с результатов: Какая информация нужна для того, чтобы
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 7 из 15
Методологии развития систем электронного управления
совершать работу? Как должны двигаться данные между агентствами и отдельными
лицами? Определите частоту, временные рамки и точность.
•
Во-вторых, определите действия, требуемые в контексте результатов: Какая
информация нужна для достижения каждого из результатов? Какая информация есть
в наличии, когда, где? Какую новую информацию нужно будет собрать?
Цель анализа требований в том, чтобы зафиксировать существующие пользовательские
функции, процессы, действия и данные. На этапе анализа осуществляются такие действия:
анализ поточных функций; создание модели поточных функций; анализ поточных процессов и
деятельности; создание модели поточных процессов; анализ использования и источника
поточных данных; анализ поточных данных; создание модели поточных данных. После анализа
можно порекомендовать применение подходящего подхода для удовлетворения требований
пользователей, который обычно выбирается из следующего ряда: разработка системы по
индивидуальному заказу, внедрение пакета, поставленного продавцом с его модификацией или
без, а также реорганизация существующей компьютерной системы. Суть разработки любой
новой системы должна быть определена после полного осознания старой системы. Даже в
случае абсолютно новой системы нужно уделить особое значение возможности использования
существующих ресурсов.
Утверждение анализа требований является достаточно весомым аргументом для
санкционирования отдельного процесса. Для удостоверения того, что все стороны согласны с
тем, что условия, представленные в документации точно описывают рабочую среду, и что
составленные документы содержат полные, точные, однозначные и контролепригодные,
необходимо утвердить полную документацию по анализу.
Анализ требований должен быть завершен Документом Требований (ДТ), который содержит
проблемы и требования пользователей и необходимые общие решения. Его язык должен
ориентироваться на работу пользователей и не содержать компьютерного жаргона. ДТ иногда
используется в качестве Требования Предложения (ТП), когда пользователь предлагает
исполнение проекта внешним подрядчикам. Но ДТ, написанный пользователями, обычно не
подходит для оценки разработки, поскольку пользователь может не иметь полной информации о
том, что может проделывать система, основанная на компьютере, и поэтому ДТ часто расплывчат.
Пользователь даже может и не воспринимать свои потребности корректно, если они не
соответствуют современным компьютерным и коммуникационным технологиям. Другие проблемы
связаны с трудностями коммуникации. От человека без технического опыта нельзя ожидать того,
что он выучит компьютерный язык и жаргон с той целью, чтобы сформулировать свои требования
перед компьютерным аналитиком. Поэтому, обнаружение и решение проблем такого характера
ложится на плечи команды разработчиков проекта. Опыт многих системных аналитиков
показывает, что команде проекта стоит уделить больше времени пользователям для того, чтобы
помочь им составить нормальный документ требований.
3.4 Участие пользователей
На этом этапе обязательным есть активное участие пользователей, включая предприятия,
граждан и работников правительства, а также любых других лиц, чья помощь может оказаться
необходимой в силу их причастности к разрабатываемой системе. Вне всякого сомнения, это
очень важный фактор успеха. Например, рабочие потребности и задачи проекта не могут быть
разработаны грамотно, если пользователи не готовы предоставить уверенную помощь при их
определении на стадии инициации. Это единственный способ, чтобы удостовериться в том, что
требуемая система будет точно соответствовать рабочим целям ведомств организации и всей
организации в целом. Из этого следует, что пользователи должны принимать активное участие и
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 8 из 15
Методологии развития систем электронного управления
высказывать свои потребности. По существу, это утверждение касается всех ожидаемых
результатов проекта, созданных в процессе предварительного анализа и анализа требований.
Акцент на вовлечении пользователей должен рассматриваться в качестве проводника успеха
проекта. Система, которая будет разработана, будет настолько эффективна в поддержке
функциональных областей пользователей, насколько эффективно сами пользователи участвуют
в процессе создания системных требований, особенно на критически важных стадиях процесса
анализа. С помощью технологий разработки, ориентированных на пользователей, таких, как
создание прототипов, все больше и больше правительственных систем будут разрабатываться с
успехом при командной работе пользователей и компьютерных аналитиков, тесно
сотрудничающих на протяжении всего проекта.
Самыми успешными проектами чаще всего являются те, которые отданы под формальную
ответственность пользователей. Хотя систему могут создавать профессионалы в области
компьютеров и коммуникаций, главная ответственность за проект лежит на осведомленных и
способных представителях пользователей, которые официально несут ответственность за новую
систему.
3.5 Обучение пользователей
Важно ознакомить пользователей, которые будут прямо участвовать в проекте, с
технологиями определения требований, которые будут применены к данной ситуации. Это
поможет преодолеть разрыв в коммуникации, который может существовать между
пользователями и разработчиками системы. Нужно составить курсы обучения, для того чтобы
способствовать преодолению неведения касательно разработки системы электронного
управления. В общем, такие курсы описывают процесс развития системы в простых терминах,
которые можно легко понять с точки зрения пользователя. В ходе таких семинаров также
объясняется специализированный (и часто внутренний) набор концепций и словарь,
используемый разработчика информационных систем, также подается краткое описание разных
графических инструментов и технологий, применяемых при решении задач рабочего процесса и
моделирования данных. Учитывая инвестиции, предоставленные для развития большой
системы электронного управления, не говоря уже о том факте, что такая система просуществует
около 10-15 лет, курсы для пользователей длительностью от одного до пяти дней стоят очень
мало в сравнении с высококачественной системой, по-настоящему нацеленной на
удовлетворение требований пользователей.
3.6 Разработка системы
Целью разработки системы является определение внутренней архитектуры системы
электронного управления. Для большого, сложно приложения, проблемы разработки связаны с
характеристиками функционирования, удобства работы и обслуживания стоят на первом плане.
Следовательно, модели физических данных и процессов нужно создавать таким образом, чтобы
они были максимально гибкими, учитывая физические препятствия, которые могут стоять перед
технологией, выбранной для применения в системе. Любые отклонения от изначальных
требований в моделях функционального процесса и данных, являющиеся необходимыми для
соответствия специфическим операционным критериям системы, нужно фиксировать должным
образом и тщательно обсуждать с пользователями. Стратегии для проверки системы,
конвертации данных, обучения конечных пользователей и установки системы также должны
быть грамотно спроектированы.
На основании анализа требований пользователей можно определить функции системы,
которую нужно разработать. Определяя такие функции, разработчики системы должны
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 9 из 15
Методологии развития систем электронного управления
зафиксировать все подходящие функции и понять явные, скрытые и дополнительные функции.
Явные функции – это те, которые осуществляются максимально видимым, или явным, для
пользователей образом. Скрытые функции должны быть максимально незаметными для
пользователей. Дополнительные функции – это функции, которые пользователи желают иметь,
если это ничего не будет им стоять, либо прямым путем, либо путем отказа от некоторых других
функций. Классификация списка функций на скрытые и открытые может помочь обнаружить
возможности, которые в противном случае можно упустить. Это потому, что такая классификация
подчеркивает функции, важные для системы, которые в другом случае можно было бы
проигнорировать.
Определение функций должно быть произведено совместно с пользователями путем создания
изначального списка потенциальных функций, и отнесения каждой функции к классу открытых,
скрытых или дополнительных. Метод мозгового штурма может помочь раскрыть неупомянутые
скрытые функции, которые расширят общий список функций. В процессе классификации этих
функций, нужно искать функции, формулировка которых подразумевает некоторые ограничения
для решений, и трансформировать такую формулировку, чтобы утверждения стали проблемными,
а не утверждениями решений, и, наконец, создать список дополнительных функций.
Есть несколько вопросов, также являющихся важными, которые нужно ввести в процесс
разработки системы. Они идентифицируют ограничения и риски, определяют предпочтения,
ограничивают ожидания от разрабатываемой системы.
Идентификация рисков и ограничений, существующих при разработке системы, является
важной проблемой. Ограничения рабочего процесса и ограничения технического характера, а также
риски, связанные с условиями, которые считаются таковыми, которые находятся вне сферы
прямого влияния или контроля команды проекта. Но в то же время они могут иметь прямой влияние
на масштаб проекта, его сроки и альтернативные решения о внедрении. Ограничения или риски,
способные повлиять на проект, включают в себя следующие: стабильность организации в контексте
ее стратегического курса, функций и структур; правительственные постановления; бюджетные
ограничения; политические соображения; ситуация с графиком; юридическая ситуация;
экологические соображения; операционные ограничения; наличие данных; ситуация с
техническим/программным обеспечением/ сетевым окружением; ситуация с персоналом;
технические ограничения; риски, связанные с использованием непроверенной новой технологии.
Для того, чтобы окончательное решение касательно дизайна системы было приемлемым, нужно
обеспечить устранение каждого ограничения или риска. Таким образом, ограничение или риск
нужно определить, таким образом, который даст участникам возможность принять объективное
решение касательно того, решена проблема с этим ограничением или риском в конечном итоге или
нет.
Определение предпочтений – еще одно задание фазы анализа системы. Предпочтение – это
желаемое, но необязательное условие, поставленное перед предметом. Любое решение
окончательной разработки, которое решает проблему каждого ограничения, является
приемлемым решением, но некоторые приемлемые решения могут иметь больше преимущества
перед другими. Предпочтения дают возможность разработчикам сравнить приемлемые решения
и выбрать лучшие из них. Лучше определять предпочтения таким образом, чтобы их можно было
измерять, поскольку их используют разработчики в качестве мерила для удовлетворения своих
клиентов. Итак, предпочтения не могут быть полезными, если каждое их них не определено
таким образом, который поможет разработчикам определить, в какой мере предпочтение было
удовлетворено.
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 10 из 15
Методологии развития систем электронного управления
Ограничение ожиданий от разрабатываемой системы также является важным. Если
разработчик думает о процессе разработки как об оправдании всех ожиданий и устранении
всякой неудовлетворенности, он/она никогда не достигнет успеха. Важно понимать, определять,
выражать и контролировать ожидания каждого, кто задействован в процессе. Для того, чтобы
поднять и зафиксировать ожидания и ограничения, сначала представители пользователей
должны составить список специфических ожиданий. Разработчики системы должны работать со
списком для понимания и генерализации каждого ожидания. Потом они должны провести
переговоры по ограничению ожиданий в рамках допустимого уровня, оставляя открытыми
возможности для будущих модификаций системы, но, устраняя все то, чего нельзя ожидать в
разумных рамках. При установлении границ, нужно зафиксировать документально источник
ограничения, поскольку сегодняшнее ограничение может перерасти в завтрашнюю возможность.
Логический дизайн системы идентифицирует логические связи между существенными
элементами вне и внутри системы, т.е. потоки рабочих процессов, которые система будет
поддерживать, и поток информации, который будет обрабатываться системой. Потоки рабочих
процессов представляют рабочую модель организации, а потоки информации описывают
модель данных/информационную модель организации. Рабочие модели и модели
данных/информационные модели организации являются независимыми от технологии и
нацелены на архитектуру системы на логическом уровне. Логический дизайн системы также
идентифицирует функции, исполняемые новой или улучшенной системой, и уточняет действия
новой или улучшенной системы в поддержку потока рабочих процессов организации.
Логический дизайн должен представлять собой документ нетехнического характера,
доступный как профессионалам системы, так и ее пользователям. Когда пользовательменеджер уверен в том, что новая система удовлетворит потребности организации, и
утверждает логический ее дизайн, можно приступать к физическому дизайну системы.
Физический дизайн определяет архитектуру системы на физическом уровне, который
является зависимым от технологии и создает модель системы. Физический дизайн системы
электронного управления включает в себя спецификации относительно того, как нужно внедрять
логический дизайн. Это охватывает такие вещи, как спецификации всех ручных и
компьютеризированных процедур; архитектуру системы и топологию сети; выбор компьютерных
технических средств и программного обеспечения; разработку требуемых файлов физического
представления данных; спецификацию всех необходимых программ и/или процедур;
физическую безопасность системы. Этот процесс имеет в большой степени технический
характер и требует участия пользователей, особенно при детализации процедур ручной
обработки данных.
Оконченный физический дизайн системы нужно зафиксировать документально на двух
уровнях. Нужно написать обзор дизайна, включая в него описания системы и подсистемных
приложений, взаимосвязи между подсистемами, архитектуры системы, процедуры операций или
фиксации данных и процедуру аудита. Он также должен содержать описание своих баз данных,
пример всех входящих/исходящих документов или форматов, а также степень безопасности
системы. Он также должен подавать детали о связи и интерфейсе данной системы с другими
системами электронного управления в среде организации. Такой обзор дизайна должен быть
утвержден руководством правительственного агентства перед установлением детальных
технических спецификаций.
Вдобавок к обзору дизайна и второму уровню документации, также нужно предоставить
детальные спецификации для словаря данных, файлов данных, баз данных,
входящих/исходящих документов, экранных образов, программ и процедур, системы кабелей и
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 11 из 15
Методологии развития систем электронного управления
программ обучения пользователей
3.7 Внедрение системы
Главной целью фазы внедрения является подача пользователям полностью и адекватно
работающей системы. На основании спецификаций системного дизайна, полученных на
предыдущих этапах разработки, программное обеспечение кодируется, проверяется, и
постепенно интегрируется в завершенную систему. Ручные и административные действия в
системе завершаются и проходят проверку в сочетании с автоматизированной частью системы.
Руководства по документации для пользователей и системы также доделываются, а персонал
проходит соответствующее обучение. Данные старых файлов помещаются в новые структуры
файлов/баз данных системы. Для пользователей устанавливается соответствующее
техническое, программное и сетевое оборудование и средств, и система и поддерживающие
материалы переводятся в рабочую среду. При необходимости систему настраивают на
протяжении одного месяца после ее запуска в рабочем режиме.
Пользователи должны участвовать в проверке программного обеспечения приложений,
программ, процедур и баз данных для того, чтобы лучше поныть систему. Можно использовать ряд
технологий для обеспечения должного качества. Особое внимание нужно уделить документации.
Обучающие программы для пользователей разных уровней и материалы, касающиеся новой
системы, нужно включить в качестве части процесса внедрения. К ним относятся подготовка
подсказок и проведение семинаров для передачи общей информации о системе, планы занятий
и материалы для обеспечения детального обучения концепциям системы и ее процедурам,
обучающие программы без отрыва от производства для тех, кому предстоит каждодневная
работа с новой системой.
Нужно провести приемку перед тем, как вводить новую систему в действие. Все обещанные
функции и итоговые продукты должны быть продемонстрированы во время приемки. Система
полноценна в качества завершенного проекта, если:
•
Новая система установлена и работает без перебоев.
•
Преобразование или переключение из старой системы полностью завершено.
Переключение по возможности нужно делать поэтапно.
•
Конечные пользователи обучены и нормально работают с новой системой.
•
Обзор результатов после окончания проекта проведен и зафиксированы все
преимущества проекта в будущем.
•
Определены обязанности и методы постоянного обслуживания.
Всегда существует потребность изменить систему для того, чтобы сделать ее лучше,
добавить новые характеристики или исправить проблемы, которые еще остались после приемки
системы или окончания срока гарантии. В большинстве случаев, работа пользователя изменяется
со временем, а с ней изменяются и потребности пользователей. Такие изменения или улучшения
делают необходимость обслуживания системы неотложной.
Преобразование должно представлять собой хорошо спланированный процесс, в котором
пользователи должны быть участниками. Нужно создать файлы и документы, напечатать формы
и учредить новые процедуры.
Необходимо разработать предварительную версию разных типов системных руководств для
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 12 из 15
Методологии развития систем электронного управления
использования, произведения операций и обслуживания системы. На раннем этапе фазы
внедрения такие руководства можно разработать в качестве черновых вариантов. Но у них
должно быть достаточно информации для поддержки пользователей и, время от времени,
работников по управлению системой во время цикла приемки пользователями и рабочей
приемки.
Руководство пользователя системы всегда должно быть составляемо на языке, которой
нетрудно понять с точки зрения пользователя. Следует избегать технического жаргона.
Пользователи не обязаны знать, как работает система внутри, но знать, как связываться с ее
автоматизированной частью должным и оперативным образом.
Руководство по эксплуатации системы описывает высокоуровневые функции и средства,
применяемые в программном обеспечении приложений, сосредотачиваясь в первую очередь на
технических параметрах. Оно содержит общие описания программ и описывает важные
технические характеристики системы (т.е., ее внутренней и внешней архитектуры). Такое
руководство первоначально нацелено на поддержку работы команды по обслуживанию. Но оно
не обязательно дает детальное описание спецификаций программы. Детальная информация,
связанная с программой, может быть вынесена в отдельное пособие.
Руководство по операциям системы предоставляет описание детальной документации,
требуемой сотрудниками центра данных/информации для произведения операций в рамках
работы системы. Обычно, тип информации, которую нужно описать для каждого
производственного процесса в специфическом рабочем цикле (каждодневном, еженедельном,
месячном, годовом), включает в себя подготовку к работе, исполнение работы и
распространение продуктов работы.
Во время фазы внедрения, нужно подготовить пакет по обучению работе в системе.
Учебные материалы можно создать в виде предварительного проекта и на ранней стадии этой
фазы. Предварительный проект должен иметь достаточно информации для поддержки начального
обучения участников команды пользователей, которые буду проводить пользовательскую приемку.
Детальную стратегию обучения нужно рассматривать в свете всей информации, которая была
создана касательно новой системы. Также, проектный пакет по обучению работе в системе нужно
проработать для проверки его точности и соответствия поставленным к обучению задачам.
Окончательный проект материалов формального облучения должен совершить адекватную
подготовку и обучение пользователей, работников системы и обслуживающего персонала
относительно того, как использовать, производить операции поддерживать систему самым
эффективным способом, до запуска системы в рабочем режиме. Материалы обучения могут
содержать распечатки, слайды, прожекторные материалы и т.п. Эти материалы должны быть
разработаны методом «сверху вниз», описывая систему от самых общих черт до максимально
конкретных. В некоторых случаях, нужно будет создать некоторые специфические компоненты
пакета по обучению для удовлетворения специфических нужд целевой аудитории.
После того, как система запущена в работу, нужно провести оценку результатов внедрения
по его окончанию. Это нужно для того, чтобы определить, насколько точно система
соответствует задачам, поставленным при разработке. Общая работа и уровень оперативности
всей системы нужно рассматривать с точки зрения времени реагирования программ онлайнрежима, времени исполнения пакетных программ, времени исполнения сервисных программ
программного обеспечения, средств безопасности, установленного компьютерного оборудования,
инструкций по работе с компьютером и контроле рабочего процесса, пользовательской/системной
документации в общем и эффективности коммуникационной сети системы, а также любых других
параметров, привязанных к изначальным задачам. Оценку можно проводить команде проекта или
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 13 из 15
Методологии развития систем электронного управления
аудиторам внутренней системы.
Оптимизация системы после внедрения может проводиться на основании результатов оценки.
Нужно обнаружить специфические области, в которых изначальные системные требования не были
полностью удовлетворены. Команда по внедрению проекта также должна определить причины
проблем и применить соответствующие меры по исправлению. Также в задачу по оптимизации
нужно включить полный перечень системных документов и оптимизацию производственной
системы.
Методология системы электронного управления, представленная в этом занятии, базируется
на принципах и практике жизненного цикла процесса разработки и развития системы. Существуют
разные типы систем электронного управления. Но три главных стратегии остаются неизменными
для каждой из них, а именно: анализ, разработка и внедрение. Некоторые из фаз и действий в
рамках каждой из стадий будут отличаться в зависимости от того, какого типа система электронного
управления внедряется.
4.
Управление проектом
Планирование, организация, набор персонала и контроль являются четырьмя ключевыми
видами деятельности, обеспечивающими успех программы/проекта.
Успешные проекты должны иметь ясное начало – письменный план, определяющий суть
результатов работы и самого пути к их достижению. Нужно документально зафиксировать критерии
приемки, которые можно измерять, и использовать их в качестве ссылки при предъявлении
доказательств того, что изначальные обещания выполнены.
Во время разработки, необходимо проведение близкого мониторинга для обеспечения
продвижения проекта согласно плану. Члены команды по внедрению проекта должны
располагать адекватным опытом для достижения заявленного результата. Необходимо
предоставлять нужные документы нужным людям, даже в трудностях, потому что руководящие
лице должны осознавать, что документация – это один из самых важных аспектов проекта.
Частые обзоры проекта нужны для того, чтобы определить продвижение согласно графику. Если
произошла проблема, ее необходимо сразу заметить и по возможности решить; в противном
случае, планы и графики нужно переделать и при необходимости переформатировать ожидания.
Наконец, удовлетворенность пользователей должна быть главной заботой команды по
внедрению проекта. Продукт, который команда создает, должен соответствовать обещанному.
Расходы проекта нужно контролировать, чтобы они были в « разумных пределах» заявленных
плановых расходов. Не должно быть никакого несогласия по поводу приемки. Точный и
детальный метод, используемый для демонстрации требуемых функций продукта,
пользователям нужно утвердить заблаговременно.
Эффективная организационная структура команды по внедрению малого или среднего проекта
системы электронного управления состоит из менеджера проекта, лидера проекта, системных
аналитиков и создателей программного обеспечения.
Каждый в команде имеет конкретные рабочие обязанности. Системные аналитики отвечают
за анализ системы и ее логический дизайн. Физический дизайн и внедрение системы
осуществляется совместно системными аналитиками и программистами. Программисты
разрабатывают программное обеспечение приложений и создают дизайн баз данных. Лидер
проекта совершает постоянный надзор, управляя техническими действиями и решая любые
проблемы системы. Главной обязанностью лидера проекта является обеспечение качества
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 14 из 15
Методологии развития систем электронного управления
продукта. Менеджер проекта, перед которым отчитывается лидер проекта, поставлен
обеспечить управление и отвечать за коммуникацию между командой по внедрению проекта и
внешним миром. Обязанности менеджера по проекту включают в себя общее управление
ресурсами проекта и успешное исполнение задач, производство продуктов и успешную
деятельность.
Для большего проекта, системных аналитиков и программистов можно разделить на
несколько команд. С помощью такого подхода отдельные команды проекта могут работать над
своей частью проекта, как над подсистемой, или отдельным проектом. Полномочия командных
лидеров нужно четко определить и все командные лидеры должны отчитываться перед лидером
проекта, который контролирует их действия.
Менеджеры проекта являются главными лицами, которые должны обеспечить успех проекта
по внедрению системы электронного управления. Они несут ответственность за успешную
разработку, внедрение, интеграцию, работу и обслуживание систем. Самым сложным в
разработке системы электронного управления является обеспечение того, чтобы менеджер
проекта и тот, кто интегрирует систему, полностью понимали, чего хотят пользователи, и не
говорили на языке, который отличается от языка пользователей. В общем, пользователям нужно
больше, чем профессиональные знания тех, кто интегрирует систему. Менеджеры проекта должны
иметь четкое понимание сути работы пользователей систем электронного управления. Чисто
техническое решение может принести пользователям только минимальную пользу. Менеджер
проекта должен иметь следующие черты:
1. Обладать всесторонними знаниями вертикальной организации конкретной области
экономики и желательно иметь опыт руководителя в сродной области.
2. Иметь способность работать с линейными руководителями на предприятии для
определения требований и внедрения систем электронного управления.
3. Иметь глубокое понимание соответственных технических концепций и способность
оперировать между требованиями рабочего процесса и требованиями технической
разработки систем.
4. Иметь хорошие навыки общения, отлично работать с командами и уметь
эффективно вести переговоры.
5. Уметь ориентироваться на детали и устанавливать временные рамки для
завершения конкретного проекта, вести учет важных этапов и быть для
пользователей единой контрольной точкой, тем кто интегрирует систему.
Электронное управление – Что нужно знать лидеру в сфере управления
Страница 15 из 15