Методика выбора автоматизированных информационных систем
Потребность в выборе АИС может быть вызвана либо необходимостью автоматизации или модернизации существующих информационных процессов, либо необходимостью коренной реорганизации в деятельности организации. Руководство практически всегда сталкивается с проблемой выбора АИС, когда предприятию необходим современный инструмент управления и в то же время четко сформулировать принципиальные требования к системе не представляется возможным.
Выбор системы в общем случае может быть организован как процесс последовательного просмотра большого количества предлагаемых вариантов с целью нахождения подходящего решения. Однако число разработанных и представленных на рынке систем столь велико, что выбор наилучшего решения простым перебором различных вариантов становится невозможным, поэтому чаще всего при выборе АИС заведомо неприемлемые системы отбрасываются из рассмотрения.
Для осуществления обоснованного выбора необходимо точно определить технические и экономические требования к АИС, которые обычно группируют в следующие разделы:
• функциональные возможности (соответствие АИС функциям, которые существуют или планируются в организации);
• стоимостные оценки (совокупная стоимость владения, т. е. сумма прямых и косвенных затрат владельца системы за период ее жизненного цикла);
• технические характеристики (архитектура системы, надежность, средства защиты и т. п.);
• перспективы развития и интеграции (масштабируемость, поддерживаемые интерфейсы с внешними системами).
Главный принцип выбора ИС для предприятия заключается в том, в какой степени та или иная система подходит для управления объектами в конкретных условиях. С этой точки зрения выделяют следующие основные критерии выбора ИС [8, 21, 33]:
• функциональные характеристики — соответствие возможностей системы задачам, которые выполняет объект автоматизации;
• удобство работы пользователей — простота эксплуатации системы и возможности поиска информации, наличие документации и справочной системы;
• совместимость — возможность использования с наиболее распространенными операционными системами и функциональным программным обеспечением;
• репутация фирмы-разработчика, стаж ее пребывания на рынке, число продаж, отзывы экспертов — этот критерий позволяет обеспечить стабильное сопровождение системы и своевременный переход к новым версиям;
• адаптируемость системы на российском рынке — наличие русифицированной версии систем иностранного производства или возможность их русификации, учет российского законодательства;
• простота внедрения — сроки и ресурсы, необходимые для приведения системы в рабочее состояние и обучения пользователей;
• возможность расширения и интеграции с другими системами — гибкость системы и готовность ее к совершенствованию функций, возможность настройки системы и подключения к внешним информационным источникам при меняющихся потребностях предприятия;
• опыт внедрения системы на других предприятиях и наличие демонстрационных версий — оценка по этому критерию позволит избежать возможных ошибок, вызванных несоответствием рекламных материалов фактическим возможностям системы.
Функциональная полнота является одним из важнейших критериев выбора системы, поскольку ограниченность набора возможностей приводит к существенным финансовым, трудовым и временным затратам на автоматизацию функций, не предоставляемых системой.
Выбор архитектуры информационной системы будет определяться ответами на следующие вопросы:
• Какие функции должны быть автоматизированы?
• Какие для этого потребуются промышленно изготовленные и оригинальные (заказываемые) типы программ?
• Какие необходимы информационные объекты, как они будут организованы и распределены? Прежде чем ответить на эти вопросы, необходимо рассмотреть ряд факторов, влияющих на этот выбор.
1. Насколько бизнес-процессы предприятия отличаются от традиционных?
Если отличия достаточно серьезны и привести бизнес-про- цессы на предприятии к стандартным невозможно или нецелесообразно, то покупать готовую ИС не имеет смысла.
2. Как часто потребуется вносить значительные изменения во внедряемую ИС?
Если бизнес-процессы в сфере деятельности предприятия постоянно изменяются и совершенствуются, то покупка и адаптация готовой ИС также неприемлема, так как в систему потре- буется непрерывно вносить изменения, интегрировать в нее новые компоненты и т. д., что может оказаться невозможным вовсе либо недостаточно эффективным.
3. Какие суммы готово вложить предприятие в автоматизацию?
Для ограниченных в финансовых ресурсах предприятий как покупка зарубежной ИС, так и специальный заказ на разработку ИС обычно неприемлемы. Выбор между покупкой существующего программного обеспечения или разработкой своими силами решается обычно на основании ответов на вышеперечисленные вопросы.
Таким образом, покупку и адаптацию готовой системы следует выбирать для предприятий со стабильными и традиционными бизнес-процессами, если на рынке программного обеспечения представлены соответствующие информационные системы. При этом для крупных и разветвленных структур рекомендуется выбирать мощную корпоративную информационную систему, однако нередко это приводит к необходимости реорганизации предприятия, что связано с дополнительными затратами времени и средств.
Для предприятий среднего и малого бизнеса вполне приемлемы локальные ИС, обеспечивающие автоматизацию отдельных функций на отдельных уровнях управления. Разработка ИС своими средствами и заказ разработки ИС организациями-раз- работчиками являются наиболее удобным способом для нетипичного ведения бизнес-процессов.
Таким образом, выбор автоматизированной информационной системы — это комплексная задача, сложность которой существенно возрастает с ростом масштабов предприятия. Поэтому для осуществления выбора АИС часто привлекаются квалифицированные специалисты, действующие на основании своего опыта и знаний, а также в соответствии с реальными потребностями предприятия.
Методология и технология проектирования АИС
Современные методологии и реализующие их технологии проектирования АИС поставляются в электронном виде вместе с CASE – средствами (рассмотрены далее) и включают библиотеки процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована методология. Электронные методологии и технологии составляют ядро комплекса согласованных инструментальных средств разработки АИС [6, 8, 16—181. Особенности современных методологических решений проектирования АИС невозможно реализовать без определенных технологий проектирования, соответствующих масштабу и специфике проекта.
^ Технология проектирования АИС — это совокупность методов и средств проектирования АИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта АИС) [8, 16—18]. В основе технологии проектирования лежит технологический процесс (ТП), который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий.
Согласно [20] ТП проектирования АИС представляет собой совокупность последовательно-параллельных, связанных и со- подчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектировании АИС, могут быть определены как неделимые технологические операции или как подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными, которые вырабатывают по установленным критериям оценки результатов проектирования.
Таким образом, технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода.
Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АИС.
Основные требования, предъявляемые к выбираемой технологии проектирования, следующие:
- созданный с помощью этой технологии проект должен отвечать требованиям заказчика;
- технология должна максимально отражать все этапы цикла жизни проекта;
- технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;
- технология должна способствовать росту производительности труда проектировщиков;
- технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;
- технология должна способствовать простому ведению проектной документации.
Технология проектирования АИС реализует определенную методологию проектирования. В свою очередь, методология проектирования предполагает наличие некоторой концепции, принципов проектирования и реализуется набором методов и средств.
Методы проектирования ^ АИС можноклассифицировать по степени использования средств автоматизации, типовых проект НЫХ решений, адаптивности к предполагаемым изменениям.
По степени автоматизации различают:
ручное проектирование, при котором проектирование компонентов АИСосуществляется без использования специальных инструментальных программных средств;
программирование производится на алгоритмических языках;
компьютерное проектирование, при котором генерация или конфигурация (настройка) проектных решений производится с использованием специальных инструментальных программных средств.
^ По степени использования типовых проектных решенийразличают:
оригинальное (индивидуальное) проектирование, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС;
типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программных модулей).
^ Оригинальное проектирование АИСпредполагает максимальный учет особенностей автоматизированного объекта.
Типовое проектирование выполняется на основе готовых решений и является обобщением опыта, полученного ранее при создании родственных проектов.
^ По степени адаптивности проектных решений различаются
следующие методы:
- реконструкция — адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);
- параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;
- реструктуризация модели — изменяется модель предметной области, что приводит к автоматическому переформированию проектных решений.
Сочетание различных признаков классификации методов проектирования обусловливает характер используемой технологии проектирования АИС. Выделяются два основных классатехнологии проектирования:
каноническая и индустриальная (табл. 1.5). индустриальная технология проектирования в свою очерёдь разбивается на два подкласса: автоматизированное (использование CASE – технологий) и типовое(параметрических - ориентированное или модельно-ориентированное) проектирование. Использование индустриальныхтехнологий проектирования не исключает использования в отдельных случаях канонической технологии.
Характеристики классов технологий проектирования
| Класс технологии проектирования | Степень автоматизации | Степень типизации | лапти |
| Каноническое проектирование | Ручное проектирования | Оригинальное проектирование | Реконструкции |
| Индустриальное автоматизированное проектирование | Компьютерное проектирование | То же | Реструктуризация модели |
| Индустриальное типовое проектирование | То же | Типовое сборочное проектирование | Параметризация и реструктуризация модели |
^ Каноническое проектированиеАПС ориентировано на использование главным образом каскадной модели жизненного цикла АИС.Стадии и этапы работы такого проектирования описаны
в ГОСТ 34.601 —90.
В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной АИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.
Стадии и этапы создания АИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ.
Сопровождение АИС:
- выполнение работ в соответствии с гарантийными обязательствами;
- послегарантийное обслуживание.
Рассмотрим специфику составляющих некоторых стадий подробнее.
Обследование— это изучение и анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации [20].
Материалы, полученные в результате обследования, используются для:
- обоснования разработки и поэтапного внедрения систем;
- составления технического задания на разработку систем;
- разработки технического и рабочего проектов систем.
На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ^ АИС и детальныйанализ деятельности организации.
Основная задача первого этапа обследования оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком АИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес - экспертами. Основная задача взаимодействия получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
По завершении стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (на аппаратное обеспечение, на закупаемое программное обеспечение и на разработку нового программного обеспечения).
Результатом этапа определения стратегии является документ (технико-экономическое обоснование - ТЭО — проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов — это график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
Примерное содержание ТЭО:
- ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
- совокупность условий, при которых предполагается эксплуатировать будущую систему, — архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
- сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
- описание выполняемых системой функций
- возможности развития и модернизации системы;
- интерфейсы и распределение функций между человеком и системой
- требования к ПО и системам управления базами данных (СУБд).
На этапе детального анализа деятельности организации изучаются деятельность, 0еспечивающая реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. Здесь следует наметить инструктивно методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач, а также возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
- функции — информация о событиях и процессах, которые происходят в автоматизируемой организации
- сущности — информация о классах объектов, имеющих значение для организации ио которых собираются данные.
При изучении каждой функциональной задачи управления
определяются:
- наименование задачи; сроки и периодичность ее решения;
- степень формализуемости задачи;
- источники информации, необходимые для решения задачи;
- показатели и их количественные характеристики;
- порядок корректировки информации;
- действующие алгоритмы расчета показателей и возможные методы контроля;
- действующие средства сбора, передачи и обработки информации
- действующие средства связи;
- принятая точность решения задачи;
- трудоемкость решения задачи;
- действующие формы представления исходных данных и результатов их обработки в виде документов;
потребители результатной информации по задаче.
Одной из наиболее трудоемких, хотя и хорошо формализуемых, задач этого этапа является описание документооборота организации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить:
- количество документов;
- место формирования показателей документов;
- взаимосвязь документов при их формировании;
- маршрут и длительность движения документа;
- место использования и хранения данного документа;
- внутренние и внешние информационные связи;
- объем документа в знаках.
По результатам обследования устанавливают перечень задач управления, подлежащих автоматизации, и очередность их разработки.
На этапе обследования следует классифицировать планируемые функции системы по степени важности.
Один из возможных форматов представления такой классификации — MuSCoW [22].
Эта аббревиатура расшифровывается так:
Must have — необходимые функции;
Should have — желательные функции;
Could have – возможные функции;
Won’t have — отсутствующие функции.
Функции первой категории обеспечивают критичньте для успешной работы системы возможности. Реализация функций второй м третьей категорий ограничивается временными и финансовыми рамками: разрабатывается необходимое, а также максимально возможное в порядке приоритета число функций второй и третьей категорий. Последняя категория функций особенно важна, поскольку нужно четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.
Модели деятельности организации создаются в двух видах:
- модель «как есть» («а8 i») отражает существующие в организации бизнес-процессы;
- модель «как должно быть» — отражает необходимые изменения бизнес-процессов с учетом внедрения АИС.
Уже на этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач: - получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБд и т. п.;
- разработки плана работ по обеспечению надежности АИС и ес тестирования.
Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Чем позже обнаружены ошибки в проектных решениях, тем дороже обходится их исправление; Худший вариант — их обнаружение на этапе внедрения. Таким образом, чем раньше группы тестирования начнут выявлять ошибки в АИС, тем ниже стоимость работы над системой. Время на тестирование системы и на исправление обнаруженных ошибок должно быть предусмотре1о не только на этапе разработки, но и на этапе проектирования.
Облегчить и увеличить эффективность тестирования признаны специальные системы отслеживания ошибок. Их использование позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования.
Результаты обследования представляют объективную основу для формирования технического задания на АИС [16— 181.
^ Техническое задание— это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
При разработке технического задания (ТЗ) необходимо решить следующие задачи:
- установить общую цель создания АI4С;
- установить общие требования к проектируемой системе;
- разработать и обосновать требования, предъявляемые кинформационно ту, математическому, программному,техническому и технологическому обеспечению;
- определить состав подсистем и функциональных задач;
- разработать и обосновать требования, предъявляемые к подсистемам
- определить этапы создания системы и сроки их выполнения;
- провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения;
- определить состав исполнителей.
Типовые требования к составу и содержанию технического задания приведены в таблице ниже:
^ ТаблицаСостав и содержание технического задания
(ГОСТ 34.602 – 89)
| Раздел | Содержание |
| Общие сведения | Полное наименование системы и ее условное обозначение. Шифр темы или шифр (номер) договора. Наименование предприятий разработчика и заказчика системы, их реквизиты. Перечень документов, на основании которых создается ИС. Плановые сроки начала и окончания работ. Сведения об источниках и порядке финансирования работ. Порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств |
| Назначение и цели создания (развития) системы | Вид автоматизируемой деятельности. Перечень объектов, на которых предполагается использование системы. Наименования и требуемые значения технических, технологических, производственно – экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС |
| Характеристика объектов автоматизации | Краткие сведения об объекте автоматизации. Сведения об условиях эксплуатации и характеристиках окружающей среды |
| Требования к системе | Требования к системе в целом:
|