IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.

2. Отечественные ГОСТ:

• ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

• ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы

• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Разработка и внедрение АИС предприятия, как правило, бывает обусловлена рядом факторов, например, таких, как: •   Необходимостью получения достоверной информации о процессах, происходящих на предприятии; •   Отсутствием или слабой организацией управленческого учета; •   Большой трудоемкостью ручного формирования ряда отчетов; •   Отсутствием автоматизации на отдельных участках; •   Наличием большого количества ошибок в существующей на предприятии АИС и т.д. за что Заказчик готов платить деньги? Если в процессе начальных контактов участники переговорного процесса находят взаимопонимание по указанным проблемам, можно переходить к следующему этапу - предпроектному исследованию предприятия Заказчика.Причин, по которым руководство предприятия приходит к мысли о создании новой АИС предприятия, может быть много. Перед началом работ необходимо понимать, какой эффект хочет получить руководство предприятия от внедрения новой АИС, другими словами, Переход от существующей модели предприятия к новой, в общем случае, сводится к ряду работ, которые можно представить в виде следующей последовательности действий: 1.  Разработка модели организации «как есть». 2.  Анализ и оптимизация модели организации «как есть». 3.  Разработка модели организации «как надо». 4.  Разработки плана перехода из состояния «как есть» в состояние «как надо». 5.  Внедрение изменений и построение организации «как надо». Рассмотрим подробнее первый этап «Разработка модели организации «как есть». Выполнение этого этапа работ требует выполнения следующих шагов: •   Описание бизнес-направлений, которые реализует предприятие Заказчика. •   Описание работ, функций и бизнес-процессов, которые выполняются на предприятии для того, чтобы реализовывать эти бизнес-направления. Описание составляется по каждому бизнес-направлению. •   Описание организационной структуры предприятия. •   Распределение ответственности структурных звеньев за работы, функции и бизнес-процессы.   В результате выполнения указанных четырех шагов можно построить модель организации «как есть». Моделирование бизнес-процессов выполняется нашими специалистами в виде диаграммы в нотации EPC.

После построения бизнес-процессов осуществляется их анализ и оптимизация (исключение дублирующих ветвей, выделение основных, вспомогательных, ограничивающих, контролирующих и т.д. бизнес-процессов, исключение дублирования функций различными подразделениями и т.д.). Указанные шаги являются предметом предпроектного исследование, которое выполняется по отдельному Договору или может являться первым этапом по Договору на разработку и внедрение АИС. При этом оговаривается: предметная область предпроектного обследования, время выполнения и стоимость предпроектных работ. В той же нотации, что и модель «как есть», строится модель организации «как надо». Анализ двух моделей «как есть» и «как надо» позволяет разработать план перехода из одного состояния в другое, который включает, в том числе, выбор программного обеспечения для реализации АИС. Этот план, по сути, является предметом Договора на разработку и внедрение АИС. Отдельно рассматриваются вопросы технического оснащения организации Заказчика (использование/модернизация компьютерного парка Заказчика) в свете внедрения АИС и приобретения программных продуктов, которые необходимы для реализации АИС. Таким образом, проект по реализации и внедрению АИС в организации Заказчика сводится, в общем случае, к следующим мероприятиям (этапам): •   Предпроектное исследование (комплексное обследование хозяйственной деятельности организации), включающее: •   Изучение хозяйственной деятельности предприятия Заказчика. •   Анализ текущего состояния системы учёта Заказчика. •   Построение модели организации Заказчика «как есть» и формирование детального перечня функций автоматизированной системы. •   Организационное и техническое проектирование: •   Построение модели организации «как надо». •   Поставка и установка базового программного продукта. •   Разработка и утверждение Технического задания на автоматизацию в соответствии с разработанной моделью «как надо». •   Разработка Технического проекта на модификацию базового программного продукта. •   Разработка регламентов работы пользователей в автоматизированной системе. •   Модификация типовой конфигурации базового программного продукта в соответствии с Техническим проектом •   Подготовка АИС к эксплуатации. Обучение пользователей системы •   Формирование и утверждение перечня типов АРМ. •   Разработка инструкций по эксплуатации АРМ. •   Составление списка пользователей системы, привязка пользователей к АРМ. •   Проведение начального обучения всех пользователей автоматизированной системы. •   Проведение полного обучения всех пользователей автоматизированной системы в соответствии с их функциями в процессе эксплуатации АРМ системы. •   Тестирование пользователей АИС по результатам обучения. •   Параметрическая настройка рабочей конфигурации АИС. •   Организация и проведение переноса данных и первоначального заполнения АИС. •   Опытно-промышленная эксплуатация АИС:     •   Опытно-промышленная эксплуатация конфигурации в режиме реального времени и с использованием разработанного комплекта регламентных документов и инструкций.      •   Доработка по результатам опытной эксплуатации конфигурации и комплекта организационной и технической документации. • Передача АИС в промышленную эксплуатацию. Если необходимо, выполняются дополнительные этапы, например: • Модернизация технического парка Заказчика (поставка оборудования, прокладка коммуникаций, установка и настройка системного программного обеспечения и т.д.). • Перенос полностью или частично информации из прежней учетной системы в АИС (конвертация данных). • Промышленная эксплуатация АИС при поддержке специалистов Исполнителя и т.д.

На этапе организационно-технического проектирования формируется Перечень доработок внедряемого программного продукта (продуктов) для обеспечения необходимой функциональности АИС. Если объем доработок слишком велик и их стоимость смущает Заказчика, стороны проводят переговоры с целью выделения критичных доработок, реализация которых должна быть обязательно осуществлена до запуска АИС в эксплуатацию. Ряд доработок можно отнести на более позднее время и реализовать в процессе эксплуатации АИС, при условии, что необходимые для запуска АИС требования будут выполнены к моменту запуска АИС в опытно-промышленную эксплуатацию. Проект нашей Компанией ведётся с применением проектных технологий, в частности, стандарта PMI. Перед началом проекта определяются цели и задачи проекта, определяются границы проекта (предположения, ограничения, исключения), определяются риски по проекту и прорабатываются вопросы управления рисками. Все работы по проекту выполняются по плану-графику. Для каждого этапа проекта определяются необходимые ресурсы (количество и квалификация специалистов, необходимое время выполнения работ по этапу). Некоторые этапы могут выполняться параллельно. По каждому этапу определяется и описывается планируемый результат выполнения работ.

Краткая информация о технологии управления проектами Управление проектами - отдельная профессиональная область

За последние 50 лет «Управление проектами» сформировалась как отдельная профессиональная область, позволяющая осуществлять проекты разных типов и масштабов при помощи специально разработанных и подтвержденных опытом методов и средств. «Управление проектами» является наиболее эффективным механизмом реализации стратегических решений. «Управление проектами» - одна из важнейших областей конкурентоспособности организации.

Результаты применения технологии управления проектами;

•   Соблюдение требований международных стандартов в рамках основных областей управления проектами; •   Минимизация финансовых и организационных рисков проекта; •   Управление сроками выполнения работ, контроль резервов и расписания; •   Документированные процедуры взаимодействия отделов и служб в рамках реализации проекта; •   Система отчетности проекта (виды отчетов: еженедельный, ежемесячный, по этапам, по вехам, в целом по проекту); •   Различные сценарии плана проекта для минимизации конфликтов ресурсов в проектах; •   Согласованные интересы всех заинтересованных участников проекта; •   Повышение квалификации членов команды проекта.

Стандарты ведения проектов, применяемые компанией «кт:Алкоголь»

Компания «КТ:Алкоголь» применяет в своей деятельности стандарт Американского института управления проектами (PMI). Выбор американского стандарта обусловлен его относительной простотой и практической применимостью в российских условиях. Стандарт рассматривает управление проектом как деятельность, направленную на выполнение тройного ограничения проекта, а именно: • Получение в результате проекта продукта заданного качества; • Непревышение плановых затрат по проекту (соблюдение бюджета проекта, распределения бюджета по этапам); • Непревышение сроков проекта (соблюдение  плана-графика проекта). Этапность проекта и отдельные задачи проекта (формирование команды проекта, разработка Устава проекта и пр.) планируются с учётом требований стандарта управления проектами. Согласно требованиям стандарта компания «КТ:Алкоголь» выполняет постановку задач, разработку и внедрение АИС, активно вовлекая персонал Заказчика в эти процессы. Такой подход обеспечивает: •   «Принятие» регламентов и непрерывное функционирование АИС – сотрудники Заказчика, являясь «соавторами» регламентов, предусмотрят в них все особенности конкретной организации; благодаря этому регламенты внедряемой АИС дополнят, не противореча, уже сложившуюся систему управления конкретным предприятием; •   Возможность самостоятельной поддержки и развития АИС силами сотрудников Заказчика – в процессе постановки задач и внедрения Заказчик приобретает необходимые для этого программные продукты, а сотрудники Заказчика проходят обучение работе с программными продуктами и закрепляют полученные навыки в ходе постановки задач и внедрения АИС.

Информационная система — это взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели. Современное понимание информационной системы предполагает использование в качестве основного технического средства переработки информации компьютера. Кроме того, техническое воплощение информационной системы само по себе ничего не будет значить, если не учтена роль человека, для которого предназначена производимая информация и без которого невозможно ее получение и представление. Необходимо понимать разницу между компьютерами и информационными системами. Компьютеры, оснащенные специализированными программными средствами, являются технической базой и инструментом для информационных систем. Информационная система немыслима без персонала, взаимодействующего с компьютерами и телекоммуникациями. В нормативно-правовом смысле информационная система определяется как «организационно упорядоченная совокупность документов (массив документов) и информационных технологий, в том числе и с использованием средств вычислительной техники и связи, реализующих информационные процессы» [Закон РФ «Об информации, информатизации и защите информации» от 20.02.1995, № 24-ФЗ].

Классификация по архитектуре

По степени распределённости отличают:

• настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

• распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

• файл-серверные ИС (ИС с архитектурой «файл-сервер»);

• клиент-серверные ИС (ИС с архитектурой «клиент-сервер»).

В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные.

В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД (back-end), и рабочие станции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую.

В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности — современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено — веб-сервер с соответствующим серверным ПО.

[Править]Классификация по степени автоматизации

По степени автоматизации ИС делятся на:

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

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

«Ручные ИС» («без компьютера») существовать не могут, поскольку существующие определения предписывают обязательное наличие в составе ИС аппаратно-программных средств. Вследствие этого понятия «автоматизированная информационная система», «компьютерная информационная система» и просто «информационная система» являются синонимами^[4].

[Править]Классификация по характеру обработки данных

По характеру обработки данных ИС делятся на:

• информационно-справочные, или информационно-поисковые ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном виде;

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

[Править]Классификация по сфере применения

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

• Экономическая информационная система — информационная система, предназначенная для выполнения функций управления на предприятии.

• Медицинская информационная система — информационная система, предназначенная для использования в лечебном или лечебно-профилактическом учреждении.

• Географическая информационная система — информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных (пространственных данных).

[Править]Классификация по охвату задач (масштабности)

• Персональная ИС предназначена для решения некоторого круга задач одного человека.

• Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения.

• Корпоративная ИС в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности, безызбыточности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия.

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

Каждый их этих вопросов — тема для отдельного обсуждения. Мы остановимся на проблемах управления рисками, прежде всего их идентификации в проектах внедрения информационных систем управления предприятием класса ERP, CRM, SCM и пр.

Общеизвестным является тот факт, что многие проекты в области ИТ оказываются неудачными из за несоответствия целям, бюджету или срокам — в мире этот показатель в среднем превышает 50%, а в государственном секторе даже 70%. Такие проблемы во многом связаны с некачественным управлением рисками.

Однако следует отметить, что при принятии решений о внедрении необходимо корректно и полно анализировать и риски бизнеса для своего рода «нулевого» варианта, когда оценивается ситуация: «а что будет, если не внедрять систему?».

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

• выявление и идентификация предполагаемых рисков;

• анализ и оценка рисков;

• выбор методов управления риском;

• применение выбранных методов управления риском;

• реагирование на наступление рискового события;

• разработка и реализация мер по снижению рисков;

• контроль, анализ и оценка действий по снижению рисков;

• выработка корректирующих решений.

Управление рисками, естественно, охватывает весь цикл проекта — от подготовки до завершения, но наиболее важной (особенно в контрактах с фиксированными сроками и стоимостью) будет правильная и «честная» оценка будущих рисков на стадии подготовки проекта. Практика показывает, что игнорирование или несерьезное отношение к оценке рисков до начала работ может привести к серьезным последствиям в ходе выполнения проекта. Заметим, что довольно часто работа по идентификации рисков, их определению в договоре возлагается на руководителя проекта со стороны компании — консультанта по внедрению системы, в то время как заказчик не уделяет этим аспектам достаточного внимания, полагая, что его ответственность ограничена финансовыми обязательствами по контракту. Однако эта работа должна проводиться совместно и итеративно. В связи с этим полезно, если проекту внедрения ERP системы предшествует этап бизнес диагностики или разработки ИТ стратегии, так как уже заранее часть наиболее важных рисков может быть определена и учтена.

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

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

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

Например, российские страховщики готовились к использованию системы «Европейский протокол» при урегулировании убытков по ОСАГО, что требует определенных изменений в информационных системах страховых компаний, однако законодатели решили отсрочить введение этой системы на территории России на 2009 г. Это вариант пересечения странового и отраслевого рисков. Другой пример отраслевого риска связан с реформированием в российской энергетике — два года назад еще не было понятно, каким будет этот процесс и что потребуется предпринять в сфере ИТ-обеспечения бизнеса.  Аналогично можно предварительно оценить и внутренние (проектные) риски: управленческие, организационные, технологические;  риски, связанные с контрагентами (в том числе компаниями — партнерами по внедрению), с корпоративной культурой компании и др. Примеры таких рисков и возможные направления действий по снижению их значимости приведены в табл. 1.  После первичной идентификации рисков необходимо оценить их относительную важность. Здесь достаточно удобна оценка таких параметров риска, как вероятность его возникновения (от пренебрежимо малой до значительной) и последствия для проекта (от незначительных, т. е. не приводящих к значимым изменениям в сроках, результатах и бюджете проекта, до катастрофических, когда реализация проекта вынужденно прекращается). Каждый из этих параметров оценивается на основании экспертного мнения, например по пятибалльной шкале, а значимость риска прямо пропорциональна величине вероятности и последствиям.

Полученная оценка может быть использована для двух целей. Вопервых, приоритезация позволяет правильно распределить усилия на планирование и последующее выполнение мероприятий, направленных на минимизацию последствий рисков. Во вторых, при расчете эффекта от проекта целесообразно для получения объективной картины использовать поправки на риск. Так, при расчете ROI методом дисконтированных денежных потоков рекомендуется[T. Pisello, IT Value Chain Management — Maximizing the ROI from IT Investments, Alinean, LLC 2003] использовать определенные увеличения процента дисконтирования при оценке будущих доходов от проекта в зависимости от величины риска.

Например, при подготовке проекта внедрения некоторой ERP системы были экспертным путем определены следующие риски (см. диаграммы).  C учетом рекомендаций (табл. 2) поправка коэффициента дисконтирования составит 30%, так что ожидаемые эффекты в горизонте проекта существенно уменьшатся.

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

Здесь опыт консультанта используется для выбора наиболее подходящих решений. Например, часть проектных рисков можно снизить, следуя соответствующим стандартам и методикам выполнения проектов внедрения информационных систем. Так, риски, связанные с несоответствием или недостаточностью функций ИТ-системы требованиям предприятия, можно уменьшить, применяя лучшие практики стандартов проектирования ИС (от ГОСТ 34 до специализированных методологий вендоров) и выполняя процедуры утверждения функциональных требований владельцами процессов. Риск выбора продукта, не соответствующего требованиям, снижается при соблюдении формализованной методологии выбора технологической платформы системы. Риски, связанные с превышением бюджета и сроков выполнения проекта, уменьшаются применением процедур контроля бюджета и сроков, соблюдением проверенных методик управления проектами. А риск неэффективного использования системы после внедрения можно снизить за счет обучения пользователей, регламентации работы с системой, ведения актуальной справочной информации для пользователей, а также организации эффективной поддержки и сопровождения системы (с оговоренными параметрами качества, зафиксированными в SLA).

Ну и, разумеется, важнейшим условием становится постоянный мониторинг рисков (и вызванных ими проблем) на основании регулярных отчетов о состоянии проекта.

Исторически под термином «риск информационных технологий», или «ИТ риск», подразумевалась вероятность возникновения негативных событий из-за реализации специфичных угроз информационной безопасности – вирусов, хакерских атак, хищений информации, умышленного уничтожения оборудования. Однако в последнее время трактовка данного термина значительно расширилась и учитывает не только риски информационной безопасности, но и риски недостижения целей применения информационных технологий для повышения эффективности основной деятельности.

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

• выбора неоптимального решения по автоматизации;

• ошибок при проектировании;

• нарушения расчетных сроков и бюджета проекта;

• несоответствия между инфраструктурой и решениями по автоматизации;

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

• неэффективное взаимодействие между бизнесом и IT при определении оптимального уровня поддержки;

• неиспользование всего потенциала технологий;

• невозможность обеспечить наиболее приемлемый уровень сопровождения и развития систем;

• неоптимальные процедуры технического обслуживания и решения нештатных ситуаций;

• ошибки в расчетах нагрузки на элементы инфраструктуры и обслуживающий персонал.

Чтобы избежать подобных угроз, на предприятии необходимо создать комплексную систему, интегрирующую риск-менеджмент, внутренний контроль и внутренний аудит как на уровне основной деятельности, так и на уровне поддерживающих ее информационных технологий, то есть информационную систему. Степень зрелости данной структуры определяется ее способностью обеспечить на должном уровне результативное, рациональное и безопасное использование информационных технологий для целей основной деятельности. Чем выше уровень зрелости, тем меньше уровень ИТ-рисков и тем больше эффективность использования информационных технологий. При формирования информационной системы следует опираться на уже существующие и общепризнанные критерии (стандарты). За более чем 30-летнюю историю развития науки об IT-управлении ведущими международными институтами (ISACA, OGC, ISO) выработан набор детализированных требований в виде сборников лучших практик (например, ITIL) и открытых стандартов (CobiT, ISO 20000 и др.)

Какая-либо однозначная и общепринятая классификация АИС отсутствует, однако в науке и индустрии по крайней мере выделяют следующие типы систем по назначению:

• АСУ — Автоматизированные системы управления

• АСУП — Автоматизированные системы управления предприятия

• АСКУЭ— Автоматизированная система контроля и учёта энергоресурсов

• АСУ ТП — Автоматизированные системы управления технологическими процессами

• ГИС — Геоинформационные системы

• ИУС — Информационно-управляющие системы

• ИИС — Интеллектуальные информационные системы

• ИПС — Информационно-поисковые системы

• ИСС — Информационно-справочные системы;

• ЛИС — Лабораторная информационная система

• РИС — Распределенная информационная система

• САПР — Системы автоматизированного проектирования

• СИИ — Системы искусственного интеллекта

• СКД, СКУД — Система контроля (и управления) доступом

• СПД — Системы передачи данных

Видение продукта и границы проекта

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

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

В первом случае речь идёт о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть «ничем не ограниченным».

Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет – значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, «подняться над ситуацией», планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п.

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

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

Всегда ли нужно создавать документ «Концепция»? Следует ли разделять видение и границы?

Зачастую Заказчик осознаёт необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант её решения, с которым приходит к Исполнителю («мне нужен сайт», «требуется CRM-система» и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова² автоматизировать процессы «как есть» – всё равно, что асфальтировать дорожки, по которым ходят коровы.

В нотации RUP присутствует важная метафора: «Увидеть проблему за проблемой». Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе.

Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Всё вышесказанное ничуть не исключает возможность работы без концепции: либо речь идёт о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея «концепцию в голове» и время для консультирования Разработчика.

Некоторые аргументы за разделение видения и границ были приведены выше. Провести чёткую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос «разделять или не разделять» определяется выбранной методологией.

Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.

Концепция в гост рф

В соответствии с ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [Error: Reference source not found], после этапа формирования (выявления) требований к системе выполняется этап разработки концепции системы.

Основные работы этапа:

• Изучение объекта;

• Проведение научно-исследовательских работ (НИР);

• Разработка вариантов концепции АС;

• Оформление отчёта о выполненной работе.

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

Работы над концепцией начинаются с обследования объекта автоматизации. Выполняются НИР, направленные на исследование принципиальной реализуемости требований и возможных вариантов реализации.

ГОСТ, в отличие от большинства современных методологий, в общем случае закладывает многоальтернативность вариантов концепции системы и планов их реализации. Каждый из проработанных вариантов оценивается с позиций требуемых ресурсов и функциональности. Для вариантов должны быть представлены оценки преимуществ и недостатков. Полезность проработки нескольких вариантов концепции заключается в том, что Заказчику трудно сформулировать самостоятельно видение системы, в то время, как выбор из набора вариантов, представленных Разработчиком – вполне посильная задача.

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

Видение в rup

Шаги, которые необходимо пройти для формирования документа «Видение»:

• Формулировка проблем.

• Идентификация совладельцев

• Определение границ системы

• Идентификация ограничений

• Формулировка постановки задач

• Определение возможностей системы

• Оценка результатов

Для описания проблем предлагается шаблон, показанный в табл. 7-1.

Табл. 7-1.

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

Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта – представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.

Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы [Error: Reference source not found] (см. материалы 09-Моделирование требований). RUP в поиске границ предлагает отталкиваться от акторов и вариантов использования.

Среди источников ограничений обычно выделяют:

• Политические,

• Экономические,

• Среды,

• Технические,

• Выполнения,

• Системные.

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

Шаблон документа «Vision» RUP содержит следующие основные разделы:

1. Введение

2. Позиционирование

3. Описания совладельцев и пользователей

4. Краткий обзор изделия

5. Возможности продукта

6. Ограничения

7. Показатели качества

8. Старшинство и приоритеты

9. Другие требования к изделию

10. Требования к документации

11. Приложение.

Во введении описываются цель документа, его контекст (связь и взаимовлияние с различными проектами), определения, акронимы и сокращения, ссылки на другие документы, краткое содержание.

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

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

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

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

В раздел «Ограничения» следует выносить существующие технические, технологические и др. обстоятельства, которые необходимо учитывать на данной стадии.

Раздел «Показатели качества» содержит описание наиболее существенных нефункциональных требований к системе (эффективности, надёжности, отказоустойчивости и др.).

Раздел «Старшинство и приоритеты» ранжирует сформулированные ранее требования и возможности системы по степени важности, очерёдности реализации и т.п.

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

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

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

Видение / рамки в msf

Согласно белой книге MSF [Error: Reference source not found], на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.

Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и специфицирование его рамок – не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение³. Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта. Для получения дальнейшей информации об управлении рисками, см. “Белую книгу” дисциплины управления рисками MSF.

Также во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования.

Ведущим ролевым кластером на фазе выработки концепции является “Управление продуктом”.

Шаблон MSF содержит следующие разделы:

• Бизнес-преимущества,

  • Описание преимуществ

  • Формулировка видения

  • Анализ выгод

• Концепция решения

  • Цели, задачи, предположения и ограничения

  • Анализ применимости

  • Требования

• Рамки

  • Список характеристик/функций

  • Вне рамок

  • Стратегия подготовки релизов

  • Критерии применимости

  • Эксплуатационные критерии

• Стратегии проектирования решения

  • Стратегия проектирования архитектуры

  • Стратегия технического проектирования

Управляющие ис

Системы поддержки принятия решений (Decision Support System)

Системы поддержки принятия решений (DSS) - это компьютерные системы, почти всегда интерактивные, разработанные, чтобы помочь менеджеру (или руководителю) в принятии решений. DSS включают и данные, и модели, чтобы помочь принимающему решения решить проблемы, особенно те, которые плохо формализованы. Данные часто извлекаются из системы диалоговой обработки запросов или базы данных. Модель может быть простой типа "доходы и убытки", чтобы вычислить прибыль при некоторых предположениях, или комплексной типа оптимизационной модели для расчета загрузки для каждой машины в цехе. DSS и многие из систем, обсуждаемых в следующих разделах, не всегда оправдываются традиционным подходом стоимость — прибыль; для этих систем многие из выгод неосязаемы, типа более глубокого принятия решения и лучшего понимания данных.

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

Чрезвычайно популярный тип DSS - в виде генератора финансового отчета. С помощью электронной таблицы типа Lotos 1-2-3 или Microsoft Excel создаются модели, чтобы прогнозировать различные элементы организации или финансового состояния. В качестве данных используются предыдущие финансовые отчеты организации. Начальная модель включает различные предположения относительно будущих трендов в категориях расхода и дохода. После рассмотрения результатов базовой модели менеджер проводит ряд исследований типа "что, если", изменяя одно или большее количество предположений, чтобы определить их влияние на исходное состояние. Например, менеджер мог бы зондировать влияние на рентабельность, если бы продажа нового изделия росла на 10% ежегодно. Или менеджер мог бы исследовать влияние большего, чем ожидаемое, увеличения цены сырья, например 7% вместо 4% ежегодно. Этот тип генератора финансового отчета - простые, но мощные DSS для руководства принятием финансовых решений.

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

Другой пример DSS - интерактивная система для планирования объема и производства в большой бумажной компании. Эта система использует детальные предыдущие данные, прогнозирующие и планирующие модели, чтобы проиграть на компьютере общие показатели компании при различных плановых предположениях. Большинство нефтяных компаний развивают DSS, чтобы поддержать принятие решения капиталовложений. Эта система включает различные финансовые условия и модели для создания будущих планов, которые могут быть представлены в табличной или графической форме.

Все приведенные примеры DSS названы специфическими DSS. Они - фактические приложения, которые помогают в процессе принятия решения. Напротив, генератор системы поддержки принятия решений - это система, которая обеспечивает набор возможностей быстро и легко строить специфические DSS. Генератор DSS - пакет программ, разработанный для выполнения на частично компьютерной основе. В нашем примере финансового отчета Microsoft Excel или Lotus 1-2-3 могут рассматриваться как генераторы DSS, в то время как модели для проектирования финансовых отчетов для частного отделения компании на базе Excel или Lotus 1-2-3 - это специфические DSS.

Исполнительные информационные системы (Executive Support System)

Исполнительные информационные системы (Executive Support System - ESS) появились в 80-х годах. Ключевая концепция исполнительной информационной системы состоит в том, что такая система поставляет интерактивную совокупность текущей информации относительно конъюнктур рынка, формирует легкий доступ для старших руководителей и других менеджеров без помощи посредников. ESS использует современную графику, связь и методы хранения данных, обеспечивая исполнителям легкий интерактивный доступ к текущей информации относительно состояния организации.

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

Например, Comshare's Commander Decision является клиент-сервером и программой на базе intranet (локальная сеть, взаимодействующая с Internet), способствует быстрому широкому применению ориентированных на покупателей приложений типа поддержки принятия решения, таких, как анализ выполнения, исполнительные информационные системы и управление сообщениями. Commander Decision допускает, чтобы деловые пользователи получали информацию в любом виде, включая карты, диаграммы, вставки, запросы, вычисления и даже персональные напоминания об условиях предусмотренных встреч Этот универсальный инструмент может использоваться, чтобы строить традиционные ESS-приложения для исполнителей, как описано выше, или систем поддержки принятия решений для менеджеров на различных уровнях бизнеса. Commander Decision предоставляет для продажи большое количество легких в использовании и просто интерпретируемых изображений для предоставления ключевой информации менеджерам Кроме того, он обеспечивает выборочный контроль, интеллектуальную углубленную способность распознавать необходимую детальную информацию, демонстрацию десяти лучших или худших показателей, внимание к важным предметам новостей и экранное определение тенденций, отношений и новые версии данных.

Возможно, самая ранняя ESS, описанная в печати, - управление информацией и поддержка принятия решения (MIDS) системы в Lockheed-Georgia Company. Спонсором для MIDS были президент Lockheed-Georgia и специальный штаб, сообщавший вице-президенту финансовое развитие системы. Для развития MIDS был использован эволюционный подход с ограниченным числом показов, разработанных первоначально для ограниченного числа руководителей. Например, дисплей мог показывать предполагаемым клиентам типы самолетов или графически описывать прогноз и фактическую продажу в течение прошлого года.

Начальная версия MIDS в 1979 г. имела только 31 дисплей. К 1985 г. было поставлено 710 дисплеев, система использовалась 30 старшими исполнителями и 40 работающими менеджерами. Успех MIDS зависел от многих особенностей, но, возможно, наиболее важным было то, что система выдавала ту информацию (основанную на количественных и качественных данных), в которой нуждались старшие руководители и их компании, чтобы достичь успеха.

Фирма "Welch Allyn" - ведущий поставщик медицинских диагностических инструментов на международном рынке (термометров, офтальмоскопов, приборов кровяного давления и аудиометров). В связи с интенсивным продвижением на международный рынок фирма решила, что требуется "всемирная исполнительная система поддержки принятия решений, которая обеспечит быстрый доступ к значимой информации". Используя программные изделия Comshare, Welch Allyn построила систему финансовой отчетности, которая обращается с ежемесячным накоплением и обменом валюты. Это также обеспечивает возможности полного анализа для менеджеров, аналитиков и исполнителей. Система анализа взаимных продаж допускает менеджеров к передаче информации о всемирных продажах по линиям, областям и клиентам. "Наш процесс обработки настолько быстр, что мы можем теперь осуществлять продажу во всем мире и объединить данные таким образом, как мы никогда не мечтали", - говорит вице-президент и казначей этой фирмы Kevin Cahill.

Переработка данных (Data Mining)

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

"Добыча данных" (Data Mining) использует ряд технологий (типа деревьев решений и нейронных сетей), чтобы искать или "добывать" маленькие "самородки" информации из крупных объемов данных, запасенных в базе данных организации. Добыча данных, которая иногда рассматривается как вспомогательный аппарат систем поддержки принятия решений, является особенно полезной, когда организация имеет большие объемы данных в базе. Понятие "добыча данных" не ново, хотя название стало популярным только в конце 1990 г. По крайней мере, в течение двух десятилетий много больших организаций использовали внутренних или внешних аналитиков, часто называемых специалистами управления, пробуя распознавать тренды или создавать модели в больших массивах данных, используя методы статистики, математики и искусственного интеллекта. С развитием крупномасштабных баз данных и мощных недорогих процессоров возобновился интерес к тому, что названо в последние годы "добычей данных".

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

Какие методы решения или подходы используются при "добыче данных"? Фирма "KnowledgeSeeker" использует только одну технологию - дерево решений. Это структура в виде дерева, полученная из данных, чтобы представить наборы решений, приводящих к различным результатам. Когда создан новый набор решений в виде информации относительно частного покупателя, дерево решений предсказывает результат. Нейронные сети, область искусственного интеллекта, которые будут обсуждаться позже в этой главе, включены в пакеты программ Marksman, Intelligent Miner и Darwin (последние два также используют дерево решений). Другие популярные технологии включают правила предположений, извлечение из правил "если, то", основанные на статистическом значении; сортировку записей, основанных на наиболее близких им в базе данных;

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

Популярная пресса рассказывает о примерах успешной добычи данных. "Firster Bank", холдинговая компания с оборотом 20 млрд долл, основанная в Милуоки (США), использовала добычу данных для прямой отправки по почте набора заказов, чтобы увеличить быстродействие. Firster применила пакет обработки данных Marksman, сгруппировав карточки заказов клиентов на основе банка данных, который они уже использовали (типа карт расходов, акций домашних займов, сберегательных счетов и

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

Bank of America, основанный в Сан-Франциско, был завален запросами клиентов. Банк был заинтересован в новых способах текущего контроля за счетами клиентов при наборе новых клиентов. Сначала банковские маркетологи хотели выяснить, кто из клиентов имел тенденцию использовать конкретные изделия и какое сочетание услуг лучше соответствует потребностям различных групп клиентов. Через обширный процесс добычи данных, использующий различные программные изделия. Bank of America сгруппировал клиентов в небольшие группы, которые имели близкие интересы и потребности. "Некоторые клиенты неправильно использовали платежи, так что мы приступаем к их преобразованию", - говорит вице-президент по маркетингу Bank of America. - "Мы вошли в контакт с ними по почте или по телефону и нашли, что реакция была обычно очень благоприятная. Иногда это означало несколько долларов в месяц дополнительно, но зато мы чувствовали, что клиенты будут испытывать большее доверие к банку, который смотрел за их деньгами".

Добыча данных требует разработанной и хорошо построенной базы (склада) данных с сохраняемыми в ней данными. Прежде чем любая организация подумает относительно добычи данных, нужно сначала убедиться, что необходимые данные имеются и что они являются полными и точными. Например, отделение заказов по почте фармацевтического гиганта Merck-Medco, основанного в Нью Джерси, потратило 4 года на работу над громоздкой базой данных пациентов и обращений прежде, чем сделать банки данных готовыми к добыче данных. В Merek-Medco главными задачами реинжиннринга стали очистка данных и объединение их в значимую структуру.

Искусственный интеллект (Artificial Intelligence)

Идея искусственного интеллекта (AI), т.е. изучение того, как компьютеры могут "думать", имеет приблизительно 30-летний возраст, но только недавно появились достаточно мощные компьютеры, чтобы делать коммерчески привлекательными AI-приложения. AI-исследования развились в пять отдельных, но связанных областей: естественные языки, робототехника, системы ощущения (системы зрения и слуха), экспертные системы и нейронные сети.

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

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

Экспертные системы (Expert Systems)

Как применяет логику эксперта компьютерная система? Чтобы спроектировать экспертную систему, специалист, называемый инженером знания (специально подготовленный системный аналитик), очень тесно работает с одним или большим количеством экспертов в изучаемой области Инженеры знания пробуют узнавать все относительно способа, которым эксперт принимает решения. Если строится экспертная система для планирования оборудования, то инженер знания работает с опытными планировщиками оборудования, чтобы видеть, как они работают. Знание, полученное инженером знания, затем загружается в компьютерную систему, в специализированном формате, в блоке, названном базой знаний (Рис. 2.2.2.) Эта база знаний содержит правила и заключения, которые используются в принятии решений, - параметры, или факты, необходимые для решения.

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

Тенденция развития автоматизированных информационных систем

1. Автоматизированные информационные системы и сети – перспективные направления развития автоматизированных систем: значения и общая структура. Три модели организации информационных систем четвертого поколения.

2. Структура информационного узла концентрации. Преимущества информационных систем более сложной организации.

1. Автоматизированные информационные системы и сети – перспективные направления развития автоматизированных систем: значения и общая структура. Три модели организации информационных систем четвертого поколения.

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

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

Четвертое поколение ИС находится в стадии зарождения.

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

Информационные системы четвертого поколения имеют следующие основные особенности:

• полное использование потенциала настольных компьютеров и среды распределенной обработки;

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

• экономия ресурсов системы за счет централизации хранения и обработки данных на верхних уровнях иерархии информационных систем;

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

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

Предполагается, что развитие ИС четвертого поколения будет идти по пути одной из трех моделей: большой, средней или малой.

Малая модель Средняя модель Большая модель

Индивидуальная база данных

Подразделения предприятия

Современные тенденции в развитии АИС и технологий их создания

Индустрия производства АИС претерпела за 2 последних десятилетия качественные изменения. Это связано с такими тенденциями компьютерного мира и мировой экономики, как:

• развитием и появлением новой элементной базы,

• наступлением эпохи персональных компьютеров,

• появлением и развитием интегрированных сред разработки,

• появлением глобальных сетей передачи данных,

• глобализацией бизнеса,

• ростом конкуренции,

• переходом к экономике, ориентированной на потребителя,

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

АИС прошли путь от однопользовательских систем к системам масштаба рабочей группы, малого предприятия, холдинга, транснациональной корпорации.

Среди современных тенденций в развитии технологий создания АИС следует отметить:

• быстрые методы прототипирования,

• ориентацию на варианты использования,

• переход от разработке к настройке.

Покупное или заказное ПО – критерии выбора

В мире IT существует определённая конкуренция между заказными и покупными системами. Основной аргумент сторонников заказных систем – «каждый серьёзный бизнес уникален и требует собственной разработки; универсализм – синоним бедности». Аргументы их противников – «количество типовых решений конечно и невелико. Одни и те же организационные решения работают в различных отраслях промышленности».

Существует значительное количество аргументов в пользу покупных систем, например:

1. ERP-система X разрабатывается вендором Y уже Z лет. За это время он освоил рынки крупнейших стран Запада, позади тысячи внедрений, что говорит о высоком качестве системы.

2. КИС базируется на референтной (эталонной) модели бизнеса. Данная модель апробирована на предприятиях десятков государств и отраслей промышленности и помимо собственно системы вы (покупатель) получите подробные инструкции о том, как правильно вести бизнес и побеждать в конкурентной борьбе.

На порождение этих аргументов работают отделы маркетинга таких гигантов этого сегмента IT-индустрии, как SAP, Oracle, SAGE, Microsoft, SSA Global и др. И эти аргументы действительно и серьёзны и убедительны. Тем не менее, несмотря на мощный прессинг лидеров производства КИС, по данным обзоров, соотношение заказных и покупных систем автоматизации предприятий в мире оценивается, примерно, как 50:50.

По сути, выбор осуществляется даже не из 2, а из 3 вариантов:

1. закупить решение у вендора;

2. заказать эксклюзивное решение у фирмы-производителя прикладного программного обеспечения.

3. изготовить решение самостоятельно.

Основные критерии выбора:

• цена;

• степень уникальности бизнеса компании;

• уровень сервисного обслуживания.

Ценовые вопросы сводятся к анализу затрат на:

• закупку (или разработку),

• мероприятия по внедрению решения,

• владение (включая необходимые доработки).

Степень уникальности бизнеса компании характеризуется степенью отражения особенностей бизнеса компании в решениях, представленных на рынке.

Уровень сервисного обслуживания характеризуется наличием поддержки покупного программного обеспечения по месту размещения предприятия компании, политикой вендора (разработчика) в области поддержки, наличием горячей линии и т.п.

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

Стратегии выбора решения

Перед специалистом IT-отдела, либо независимым консультантом, которому поручен выбор решения в области автоматизации предприятия, стоит нелёгкая задача. Ведь на рынке представлены сотни решений в области автоматизации и чтобы хотя бы бегло ознакомиться с каждым из них может потребоваться несколько человеко-лет.

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

Чтобы сделать выбор обоснованным, используются стратегии выбора решения. Основные из них:

• анализ требований,

• анализ несоответствия,

• подход на основе «лучших практик».

Анализ требований

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

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

• рамки проекта;

• широта анализа требований;

• глубина проработки требований;

• требуемые ресурсы.

Рамки проекта. Какие бизнес-процессы, подразделения, отделы предприятия необходимо автоматизировать? Практика внедрения ERP-систем показывает, что даже на самых передовых в информационном смысле предприятиях степень охвата бизнеса информационными технологиями редко превышает порог в 90%. Возможно, крупномасштабный проект автоматизации следует разбить на несколько этапов, начав, допустим, с планки в 30%. Другая стратегия – «всё и сразу» предполагает попытку сразу выйти на максимально возможный охват функций.

Широта анализа требований. Сколько требований вы в состоянии сформулировать в течение разумного промежутка времени? Сколько времени уйдёт у вендоров на анализ документа требований, который вы подготовите? Д. О’Лири в [Error: Reference source not found] следующий порядок: документ описания требований для предприятия с годовым оборотом в $40 млн., содержит около 1000 позиций (требований).

Глубина проработки требований. Какую выбрать степень детализации требований? Уровень документа «Концепция» вряд ли окажется достаточным для серьёзного рассмотрения. Необходимо отражать как функциональные, та и нефункциональные требования. Можно остановиться на кратких формулировках функций (лаконично, трудно проверяемо). Можно перейти на язык сценариев (появляется возможность доскональной проверки, но это потребует значительных ресурсов). Хорош вариант с комбинацией этих способов описания: критичный функционал описать в форме сценариев, остальное – в виде функций.

Требуемые ресурсы. Ключевой ресурс предприятия – человеческий ресурс. Найдут ли топ-менеджеры предприятия время на скрупулёзную оценку требований к системе? Насколько хорошо смогут сформировать требования руководители линейных подразделений? Насколько удастся задействовать ресурс поставщиков решений? Стоит ли привлекать внешних консультантов?

Какова цена обследования? Как быстро удастся сформировать требования? Какое время следует выделить на получение ответов от вендоров, на анализ этих ответов перед окончательным выбором?

Анализ несоответствия

Анализ несоответствия при выборе КИС базируется на классических методах бизнес-анализа, предпологающих построения моделей «как есть», «как надо» и переходной модели, показывающей путь реформирования предприятия [Error: Reference source not found].

Нюанс заключается в том, что в данном случае анализ «как есть» применяется не к бизнес-системе в чистом виде, а к её комбинации с имеющейся автоматизированной системой. Он призван высветить слабые стороны и имеющегося решения и связанные с ним проблемы бизнеса.

Анализ «как надо» может производиться по одному из следующих сценариев: «реинжиниринга чистого листа» и «реинжиниринга, запускаемого технологией» [Error: Reference source not found].

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

Во втором случае речь идёт о реинжиниринге под конкретное ERP-решение. В этом случае основой для пересмотра действующих бизнес-процессов и уровня их автоматизации являются «лучшие практики», заложенные в соответствующей ERP-системе.

Как и в стратегии анализа требований, стратегия анализа несоответствия оставляет множество подводных камней и вопросов. Допустим, мы составили модель «надо» и рассматриваем спецификации конкурирующих ERP-системы. Как сопоставить эти два документа? Как измерить степень соответствия – по количеству функций? Где гарантии того, что функции, называющиеся одинаково в рассматриваемых документах, действительно одинаково работают?

Альтернативой рассмотренным выше стратегиям, позволяющей снизить степень неопределённости принятия решений, в определённой мере является подход на основе лучших практик [Error: Reference source not found].

Подход на основе лучших практик

Подход основан на отказе от моделей «как есть». Предлагается не зацикливаться на существующих на предприятии бизнес-процессах, а запустить процесс реинжиниринга, основываясь на «лучших практиках» внедряемого ERP-решения. Основные доводы за применение данного подхода [Error: Reference source not found].

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

2) Копировать существующие процессы не имеет смысла. Организация должна осуществлять автоматизацию, основываясь на «реинжиниринговом потенциале» ERP-системы.

3) Априорный анализ лучших практик не должен использоваться. Анализ лучших практик должен осуществляться в контексте конкретной части ПО выбранной ERP-системы.

4) Следует не «загибать решение под существующий бизнес», а, напротив, реорганизовать бизнес на основе лучших практик так, чтобы изменения в ERP-системы были минимальны. Это позволит снизить цену внедрения и цену владения ERP-системами.

Процесс выбора решения

Выбор решения для построения на предприятии корпоративной АИС – очень ответственный процесс, связанный с вопросами защиты инвестиций и выживания на рынке. Значительное количество проектов по внедрению ERP-систем заканчивается провалом, особенно это касается российской практики. Более того, на Западе существуют прецеденты, когда предприятия, поставившие «на карту ERP» своё благосостояние и связавшие с ними планы развития, попросту обанкротились, не справившись с задачей «реинжиниринга под ERP».

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

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

Ниже рассмотрен практический процесс, принятый компанией Chesapeake Display & Packaging при выборе ERP-решения – процесс быстрого выбора для быстрого внедрения⁴ на базе обзора, представленного в [Error: Reference source not found].

Процесс организован достаточно просто. Он предусматривает выполнение следующих этапов:

• cформировать команду «выборщиков»;

• организовать демонстрацию КИС поставщиками;

• осуществить предварительный отбор;

• осуществить выбор.

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

Организовать демонстрацию КИС поставщиками. Выбор ограниченного количества производителей высококачественных КИС. Предложение выбранным производителям подготовить демонстрацию для команды «выборщиков». Ограничение доступа представителей производителей к членам команды до момента демонстрации. Срок подготовки – 3 недели. Продолжительность демонстрации – 2 дня. Свобода выбора для вендора оборудования и СУБД.

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

• показать, что КИС сможет работать с вашим бизнесом;

• показать, что вы сможете внедрить его в течение требуемого времени;

• показать своё понимание отрасли.

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

Осуществить выбор. Выбор осуществляется на основе голосования, большинством голосов. Голосование производится на основе двух факторов:

• наиболее подходящие функциональные возможности;

• лучший персонал по внедрению.

Каждая из опций ПО оценивается в трёхбалльной шкале (3 – наивысший балл). Оценки осуществляются членами команды по группам компетенции.

IEEE 802.11 — набор стандартов связи, для коммуникации в беспроводной локальной сетевой зоне частотных диапазонов 2,4; 3,6 и 5 ГГц.

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

Методология ба

• Методологические

  • Lean production

  • Теория ограничений

  • SADT

  • ARIS

• Определяют набор аксиом, на которых базируется стратегия компании

• Определяют набор методик и инструментов, применяемых компанией

• Составляют целостную систему, изменение которой затруднено и рискованно

• Lean Production

  • Концентрация на выявлении и быстром устранении различных видов потерь. Ключевые идеи и понятия – «поток единичных изделий», «вытягивание», «точно вовремя», «встраивание качества в процесс»

• Теория ограничений

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

Тз к аис

ТЗ на АС яв-ся основным документом, определяющим требования и порядок создания (развития или модернизации) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы. ГОСТ 34.602-89 описывает какие разделы входят в техническое задание:

1) общие сведения (полное наименование системы; предприятия разработчика и заказчика и их реквизиты; сроки начала и окончания работы по созданию системы; источники финансирования работ и т.д.);

2) назначение и цели создания (развития) системы (вид автоматизируемой деятельности и перечень объектов автоматизации; требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС);

3) характеристика объектов автоматизации;

4) требования к системе (требования к системе в целом; к функциям, выполняемым системой; к видам обеспечения);

5) состав и содержание работ по созданию системы (перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций – исполнителей работ);

6) порядок контроля и приемки системы (виды и методы испытаний системы и ее составных частей; общие требования к приемке работ по стадиям, статус приемочной комиссии (государственная, ведомственная);

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие (перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие);

 требования к документированию (согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89);

9) источники разработки (должны иметься перечислены документы и информационные материалы на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы).

Общие методы и технологии проектирования аис

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

Методы проектирования ИС подразумевают использование определённых программных и аппаратных средств, составляющих инструментальные средства программирования ИС.

Метод проектирования включает совокупность трёх составляющих:

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

2) критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

Рис. 1. Представление технологической операции проектирования.

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

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

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

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

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

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

Реальное применение любой технологии проектирования, разработки и сопровождения ИС невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К ним относят стандарты:

• проектирования;

• оформления проектной документации;

• пользовательского интерфейса.

Проектирование вообще и ИС в частности обычно осуществляется поэтапно. В общем случае основные этапы проектирования, заключаются в проведении некоторой последовательности исследований (рис. 2).

Рис. 2. Этапы (последовательность) исследований.

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

Наиболее часто при проектировании ИС используют технологии и методы системного проектирования.

Системное (предварительное, концептуальное) проектирование включает в себя следующие стадии:

1) определение общих целей проектирования с формированием локальных (отдельных) целей разработки;

2) формирование концепции системы (объекта исследования) и подготовки данных для создания модели объекта;

3) разработки описания системы в виде структур объекта проектирования и построения функциональных подсистем объекта;

4) формализация задач проектирования, в том числе формирование области поиска решений, систем предпочтений и ограничений, требований к объекту и т.п.

Результатом системного (концептуального) проектирования является разработка ТЗ и, при необходимости, технико-экономического обоснования.

Рассмотрим более подробно аспекты, связанные с концептуальным проектированием.

КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ

Концептуальное проектирование порой называют техническим. Его основными этапами являются:

1) предварительное проектирование,

2) эскизное (рабочее или техно-рабочее) проектирование,

3) изготовление, испытания и доводка опытного образца системы (рис. 3).

Рис. 3. Этапы концептуального проектирования.

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

В ходе выполнения последующих стадий проектирования предполагается более глубокая и детализированная проработка решений, выработанных на данной стадии. При этом не исключается появление необходимости их существенного изменения. Хотя действующие нормативные документы предусматривают возможность, внесение изменений в проект или программу (концепцию), как правило, это связано с потерями финансовых, материальных и трудовых ресурсов как со стороны “Заказчика”, так и “Разработчика”. Указанные потери могут оказаться весьма значительными, если необходимо вносить весомые изменения в первоначальные проектные решения и чем позже эта потребность возникает. Отсюда следует особая значимость данной стадии проектирования для успешного создания АИС, а также ответственность Разработчиков и Заказчика при выполнении работ и согласовании итогового документа.

На стадии разработки, интеграции и тестирования должна быть создана тестовая БД и тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования проводится оптимизация БД и приложений. Приложения интегрируются в систему, проводится их тестирование в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему.

В результате такого проектирования должна быть получена логическая структура системы (подсистемы, модуля и др.), схемы вводы, вывода, представления, преобразования данных и т.п.

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

Стадия внедрения включает в себя действия по установке и внедрению баз данных и приложений. Основной результат стадии – готовая к эксплуатации и перенесенная на программно-аппаратную платформу Заказчика версия системы, документация сопровождения и акт приёмочных испытаний по результатам опытной эксплуатации.

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

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

Результатом концептуальной стадии проектирования АИС является итоговый документ – “Концептуальный проект”, “Аванпроект”, “Пилотный проект” или “Концепция и программа создания…”. В дальнейшем будут преимущественно использоваться термины “Концептуальный проект” и “Концепция” или “программа создания…”.

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

При проектировании, в т.ч. при решении проблем автоматизации процессов, обычно изначально принимается один из двух вариантов: создание системы решающей сиюминутные задачи или включающей и перспективные задачи (“на вырост”), учитывающие будущие потребности.

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

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

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

Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объёму и ряду других показателей: крупные, средние и малые (мелкие) проекты.

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

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

Малые проекты характеризуются использованием готовых решений и, в ряде случаев, адаптацией их под конкретные условия использования.

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

Модульное программирование – метод разработки программ, предполагающий разбиение программы на независимые модули. Считается, что модуль должен обладать оптимальными размерами (как правило, целиком помещаться на экране дисплея) и что разделение большой программы на модули облегчает её разработку, отладку и сопровождение.

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

Объект – абстрактное множество предметов, все предметы которого имеют одни и те же характеристики.

На выбор средств проектирования могут существенно повлиять следующие особенности методов проектирования:

• ориентация на создание уникального или типового проекта;

• итерационный характер процесса проектирования;

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

• жёсткая дисциплина проектирования и разработки при их коллективном характере;

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

ER-модели  Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В 1976 году Чен (Chen) предложил для проектирования ИС (баз данных) использовать ER-модели (Entity Relationship model – модель «сущность-связь»), представляющие концептуальные модели данных. Они получили широкое распространение в современных CASE-системах, поддерживающих автоматизированное проектирование ИС и обычно используются на этапе информационно-логического моделирования.

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

Таблица понятий: сущность, связь и атрибут.

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать много сотрудников. На рисунке приведен пример ER-диаграммы.

На основе ER-моделей последовательно формируют реляционные БД.

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

Iso 9000

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

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

Подчеркивая, что ISO 9000 - "превосходная идея", Gartner Group рекомендует рассматривать сертификацию на ISO 9001 только, как исходную точку на пути к качеству {1}.

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

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

• Сначала разработать и внедрить СМК по модели  ISO 9001:2000. (Ведь большинство компаний, которые сейчас находятся на 4-ом и 5-ом уровнях SW-CMM, сначала прошли через приведение своих процессов в соответствие по модели ISO. Как показывает практика, это оптимальный вариант в плане управления развитием СМК и снижения рисков).

• И только затем начать разрабатывать и внедрять ключевые процессы модели SW-CMM и далее, при необходимости, модели CMMI.

Для того, чтобы понять, насколько это действительно правильно, проведем сравнение этих моделей.

1. Обзор претендентов.

Проведем краткий обзор наиболее популярных стандартов, которые могут быть использованы ИТ-компанией для оптимизации своих бизнес-процессов.

ISO 9001. Наиболее популярным, и особенно,  в Европе, является ISO 9001 {2}

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

Упрощенно "качество", согласно серии стандартов ISO 9000, это ситуация, при которой потребители получают от производителя продукцию соответствующую их прямым требованиям и подспудным ожиданиям. Поэтому управление качеством, в соответствии с ISO 9000, предполагает применение т.н. "процессного подхода", когда моделируется и внедряется наиболее оптимальная цепь "преобразований-процессов", гарантирующая, что потребности потребителей воспринимаются производителем и воплощаются в любой продукт без искажений.

Многие организации -разработчики  ПО успешно используют именно эту широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и уже содержит в себе такие понятия, как процессный подход, анализ и измерения,  совершенствование процессов, заимствованные из модели СММ и ранее отсутствовавшие в предыдущих версиях ISO 9000. Правда, следует заметить, что стандарты этой серии универсальны - они не ориентированы на какую либо конкретную отрасль, не учитывает специфики IT-сферы и, в этом смысле, конечно по степени конкретизации, заметно уступают СММ. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение "истинных" возможностей той или иной организации и, соответственно, - путей их дальнейшего развития.

CMM (Capability Maturity Model ) разработана Software Engineering Institute при университете Карнеги-Меллона (США) и описывает модель зрелости процессов разработки программного обеспечения на предприятиях {3}. В рамках этой модели  для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектам, в то время как технические аспекты разработки освещены меньше.

В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices. Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas ( KPA ) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении и приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество  Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.

(Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:

- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software - SW-CMM) - модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard - EIA/IS 731) - модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model - IPD-CMM)

На основе этих моделей и был построен CMMI. Он вобрал в себя лучшее из этих моделей, устранив неоднозначность трактования некоторых понятий ввиду наличия множества моделей - поэтому и число ключевых практик значительно выросло).

Практические рекомендации

Желание получить сертификат соответствия в самые короткие сроки вынуждает консалтинговые компании и специалистов, занимающихся управлением качества, использовать гибкость и рамочность требований всех перечисленных высокоуровневых моделей в своих "корыстных" целях.  В результате такого форсирования событий у организации, например, получившей сертификат по ISO 9000:2000, определен только минимально-необходимый набор процессов для соответствия ISO 9001, а не все процессы, которые требуются компании для эффективного функционирования- см. Рис. 2. Кроме того  - уровень детализации процессов может быть не достаточен для четкого понимания того, что творится внутри процессов и кто, за какие задачи внутри процесса отвечает.  В лучшем случае через новые процедуры прошли лишь несколько тестовых проектов и через какое-то время становятся ясным необходимость их корректировки и дополнения. Часто, сразу после сертификации СМК о  процессах забывают до следующего наблюдательного аудита, забывая при этом и о затраченных финансовых ресурсах и энтузиазме сотрудников.  И действительно, когда выступаешь в роли независимого аудитора, очень сложно доказать, что принятый уровень детализации процесса явно не достаточен для эффективного функционирования СМК компании. Но и доказать обратное за время, которое выделяется на аудит по ISO 9000, крайне сложно (этим очень успешно можно воспользоваться при оппонировании аудитору). Практика показывает, что быстро построить эффективные процессы  даже 3-го уровня зрелости (также, по-хорошему, как и процессы на основе ISO 9000) невозможно.  Для того, чтобы этого добиться, недостаточно просто описать процессы с учетом требований выбранной модели. Самая главная сложность заключается в том, что необходимоперепроектировать культуру производства внутри организации.

1 Kurt Bittner, Ian Spence. Use Case Modeling, 2002.

1. 2 Калянов Г. Н. Консалтинг при автоматизации предприятий: Научно-практическое издание. Серия «Информатизация России на пороге XXI века». — М.: СИН-ТЕГ, 1997.

3

4 G.Chemis (1999), Shooting the Rapids of a Rapid Implementation //Shape Your World, Focus ’99 (Denver, CO:J.D.Edwards)