Управление жизненным циклом информационных систем

 

Лекция 3

 

Тема лекции: «Спецификация функциональных требований к ИС»

1. Планирование проекта. Анализ и постановка задачи.
2. Проектирование ИС. 
3. Разработка ИС.

1. ПЛАНИРОВАНИЕ ПРОЕКТА. АНАЛИЗ И ПОСТАНОВКА ЗАДАЧИ.

 

1.1. Проведение предпроектного обследования организации.

 

Планирование проекта  включает следующие стадии: ЭКСПРЕСС-ОБСЛЕДОВАНИЕ; ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ; ОЦЕНКА ЦЕЛЕСООБРАЗНОСТИ ПРОЕКТА (TELOS); ВЫБОР ПРОГРАММНОГО РЕШЕНИЯ.  

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

 

Важно верно определить:

 

1)   Организационный объем проекта (затрагиваемые реализацией проекта подразделения).

 

2)   Наличие зависимостей от других проектов.

 

ПРИМЕР.

 

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

 

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

 

Принято различать две категории обследования:

 

1. ЭКСПРЕСС-ОБСЛЕДОВАНИЕ.

 

Результаты проведения экспресс-обследования следующие.

 

a)   краткое описание текущей бизнес-модели предприятия;

b)   коммерческое предложение со сформулированными проблемами, а также ориентировочными сроками и бюджетом работ по дальнейшему информационному обследованию и непосредственно внедрению системы.

 

2.  ИНФОРМАЦИОННОЕ ОБСЛЕДОВАНИЕ.

 

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

 

a)   полное описание текущей бизнес-модели предприятия заказчика;

b)   утвержденный план работ по разработке и внедрению (включая состав группы внедрения с обеих сторон).

 

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

1.2. Анализ и постановка задачи.

 

Анализ и постановка задачи  включает в себя следующие стадии:  ИНФОРМАЦИОННОЕ ОБСЛЕДОВАНИЕ ПРЕДПРИЯТИЯ;  ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ;  СБОР ТРЕБОВАНИЙ;  ПОДГОТОВКА ТЕХНИЧЕСКОГО ЗАДАНИЯ (ТЗ).

 

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

 

Существует определенный набор ключевых мероприятий, обязательное проведение которых может повысить вероятность успеха проекта. Уже на стадии постановки задачи должны быть определены цели этапов проекта и самого проекта, включая критерии их выполнения. При этом данные цели должны быть сформулированы предельно четко и ясно, по возможности, удовлетворяя критериям SMART: КОНКРЕТНОСТЬ, ИЗМЕРИМОСТЬ, ДОСТИЖИМОСТЬ, АКТУАЛЬНОСТЬ, УСТАНОВКА КОНКРЕТНОГО СРОКА.

 

ПРИМЕР.

 

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

 

 

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

 

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

 

Модуль – часть системы, выделенная по определенному признаку, отвечающему конкретным целям и задачам управления. В рамках этих задач он может рассматриваться как самостоятельная система.

 

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

 

Этап 1. АНАЛИЗ ТРЕБОВАНИЙ И ИНФОРМАЦИОННЫХ ПОТРЕБНОСТЕЙ.

 

Этап 2. ОПРЕДЕЛЕНИЕ ИНФОРМАЦИОННЫХ ОБЪЕКТОВ И СВЯЗЕЙ МЕЖДУ НИМИ.

 

Этап 3. КОНСТРУИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ.

Этап анализа требований и информационных потребностей включает следующие задачи:

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Объектно-ориентированный подход основан на объектной  декомпозиции с описанием поведения системы в терминах  взаимодействия объектов.

 

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

 

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

 

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

 

Объектно-ориентированная технология проектирования ИС включает в себя следующие компоненты:

 

• технологию конструирования концептуальной  объектно-ориентированной модели предметной области;

 

• инструментальные средства спецификации проектных  решений;

 

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

 

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

 

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

 

Концептуальная объектно-ориентированная модель предметной области является основой проекта и реализации системы и  обеспечивает:

 

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

 

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

 

• компактность описания;

 

• удобство сопровождения готовой системы.

 

Отличительными чертами объектно-ориентированной методологии являются:

 

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

 

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

 

Отличительными чертами объектно-ориентированной технологии являются:

 

• совместное рассмотрение информационных, материальных и финансовых потоков;

 

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

 

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

 

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

 

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

 

1.3.               Формирование модели предметной области.

 

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

 

Предметная область — реальный мир, который должен быть  отражен в информационной базе.

 

Факты — результат наблюдения за состоянием предметной  области.

 

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

 

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

 

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

 

Основными направлениями формализации информации о предметной области являются:

 

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

 

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

 

• семиотика, изучающая знаковые системы с точки зрения синтактики, семантики и прагматики.

 

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

 

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

 

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

 

Способы абстрагирования:

 

• абстракция через параметризацию;

 

• абстракция через спецификацию.

 

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

 

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

 

Модель данных — модель, используемая при абстрагировании.

 

Концептуальная модель — абстрагированное описание предметной области.

 

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

 

Заключительным этапом анализа предметной области является проектирование определенной информационной структуры в виде концептуальной модели.

 

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

 

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

 

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

 

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

 

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

 

• упрощение эксплуатации ИС вследствие специализации  работников предметной области.

 

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

 

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

 

Функциональные подсистемы ИС могут строиться по различным принципам:

 

• предметному;

 

• функциональному;

 

• проблемному;

 

• смешанному (предметно-функциональному).

 

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

 

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

 

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

 

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

Функциональный принцип:

 

• стратегическое развитие;

 

• технико-экономическое планирование;

 

• бухгалтерский учет и анализ хозяйственной деятельности.

 

Предметный принцип (подсистемы управления ресурсами):

 

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

 

• основное и вспомогательное производство;

 

• качество продукции;

 

• логистика;

 

• маркетинг;

 

• кадры.

 

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

 

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

 

2.    ПРОЕКТИРОВАНИЕ ИС.

 

Основными свойствами процесса проектирования являются  дивергенция, трансформация, конвергенция.

 

ДИВЕРГЕНЦИЯ — расширение границ проектной ситуации с целью обеспечения более обширного пространства поиска решения.

 

ТРАНСФОРМАЦИЯ — стадия создания принципов и концепций (исследование структуры проблемы).

 

КОНВЕРГЕНЦИЯ охватывает традиционное проектирование  (программирование, отладка, проработка деталей).

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

 

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

 

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

 

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

 

Основными особенностями исходных данных для  проектирования ИС являются следующие:

 

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

 

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

 

• распределенный и асинхронный режим обработки данных;

 

• многообразие используемых информационных объектов и их свойств;

 

• нечеткость требований, их субъективный характер;

 

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

 

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

 

ФУНКЦИОНАЛЬНЫЕ СПЕЦИФИКАЦИИ — это часть исходных данных для проектирования информационно-управляющей системы, определяющая, что должна сделать система и как она должна быть взаимосвязана с окружением. Разработка ФС тесно  связана с обоснованием включения тех или иных действий в  функциональные требования, но не заменяет его. Для  математически определенного действия достаточно включить его  наименование с указанием типов исходных данных. Однако при  проектировании ИС именно выявление сущности выполняемого  действия составляет один из важнейших элементов  проектирования.

 

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

 

Поэтому важна оценка риска проекта, при этом рассматривают характеристики трех составляющих:

 

• заказчика;

 

• исполнителя;

 

• проекта.

Характеристики заказчика, влияющие на оценку риска проекта:

 

• стабильность организационной структуры;

 

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

 

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

 

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

 

• уровень подготовки кадров в области автоматизированной технологии обработки данных.

 

Характеристики исполнителя, влияющие на оценку риска  проекта:

 

• опыт разработки прикладного программного обеспечения (ПО);

 

• опыт работы с системным ПО;

 

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

 

• предполагаемая смена технической и программной среды;

 

• наличие в группе специалистов в данной предметной области.

 

Общие показатели проекта, влияющие на оценку его риска:

 

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

 

• наличие территориально разнесенных подразделений;

 

• объем обрабатываемых данных;

 

• наличие прототипов;

 

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

 

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

 

• требования к надежности;

 

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

 

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

 

Проектирование информационных систем будем рассматривать в следующих трех аспектах:

 

• стадии разработки;

 

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

 

• уровни детализации.

 

Проектирование включает в себя два основных аспекта: техническое и рабочее  проектирование.

 

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

 

При рабочем же проектировании могут составляться блок-схемы и алгоритмы для программных модулей.

 

2.3.               Техническое проектирование.

 

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

 

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

 

‒ Сформировать список модулей и функций системы, необходимых для поддержки определенных на этапе анализе автоматизируемых бизнес-процессов.

 

‒ Сформировать список справочников систем (будущей и, если применимо, текущей) для дальнейшего переноса и обновления данных.

 

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

 

‒ Определить элементы интерфейса пользователей (в случае гибкого или разрабатываемого «с нуля» решения) для достижения удобства работы с системой.

 

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

 

‒ Определить перечень настроек функциональных компонентов системы в соответствии со выделенными на предыдущем этапе требованиями.

 

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

 

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

 

ПРИМЕР.

 

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

 

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

 

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

 

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

 

Перечень документов, создаваемых на стадии «Технический проект», определяется документом ГОСТ 34.201-89. Основной задачей является разработка архитектуры системы и технических решений по ее реализации.

 

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

 

1. Пояснительная записка.

 

‒ Общие положения.

 

ПРИМЕР.

 

Стадии и сроки, цели и задачи, используемые при разработке системы объекты ИС.

 

‒ Описание процесса деятельности.

 

‒ Основные технические решения.

 

ПРИМЕР.

 

Структура системы, основные функции, режимы функционирования, требования к персоналу.

 

‒ Мероприятия по подготовке объекта автоматизации к вводу системы в действие.

 

ПРИМЕР.

 

Подготовка информации к импорту, создание рабочих мест.

 

2. Входные и выходные данные системы.

 

ПРИМЕР.

 

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

 

3. Схема функциональной структуры.

 

‒ Описание функций подсистем.

 

ПРИМЕР.

 

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

 

‒ Информационные связи между элементами и с внешней средой.

 

ПРИМЕР.

 

Условия обмена информацией с внешними системами.

 

4. Описание автоматизируемых функций.

 

‒ Исходные данные.

 

‒ Цели АС и автоматизируемые функции.

 

‒ Характеристика функциональной структуры.

 

ПРИМЕР.

 

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

 

‒ Типовые решения.

5. Постановка задач и алгоритмы решения.

 

‒ Характеристики комплекса задач.

 

‒ Используемая информация.

 

‒ Результаты решения.

 

ПРИМЕР.

 

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

 

‒ Алгоритм решения.

 

6. Программное обеспечение.

 

‒ Структура ПО.

 

‒ Функции частей ПО.

 

‒ Методы и средства разработки ПО.

 

ПРИМЕР.

 

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

 

ПРИМЕР.

 

Применяемые методологии разработки, проектирования системы / интерфейсов.

 

‒ Операционная система.

 

ПРИМЕР.

 

Совместимые / предпочтительные операционные системы для клиентской части ПО и серверов (баз данных).

 

‒ Средства, расширяющие возможности ОС.

 

7. Информационное обеспечение.

 

‒ Состав информационного обеспечения.

 

- Внутримашинная информационная база – набор электронных таблиц и других объектов баз данных для обработки и хранения данных.

 

- Внемашинная информационная база – информация, поступающая в бумажном виде.

 

ПРИМЕР.

 

Нормативно-справочная информация, годовые бюджеты.

 

‒ Организация информационного обеспечения.

 

- Принципы организации информационного обеспечения.

 

ПРИМЕР.

 

База данных должна представлять собой взаимосвязанные реляционные таблицы.

 

- Обоснование выбора носителей данных.

 

ПРИМЕР.

 

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

 

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

 

ПРИМЕР.

 

Контроль форматов данных, контроль заполнения обязательных полей.

 

- Описание решений, обеспечивающих информационную совместимость АС с другими системами.

 

‒ Организация сбора / передачи информации.

 

- Основные источники информации.

 

ПРИМЕР.

 

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

 

- Общие требования к организации сбора, передачи, контроля и корректировки информации.

 

ПРИМЕР.

 

Импорт данных в формате XML.

 

‒ Построение системы классификации и кодирования.

 

- Классификации объектов, принятые для применения в АС.

 

ПРИМЕР.

 

Общероссийский классификатор валют (ОК 014-94), Коды представления названий стран (ИСО 3166-93), внутриорганизационный справочник сотрудников.

 

- Классификации объектов, принятые для применения в АС.

 

ПРИМЕР.

 

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

 

‒ Организация внутримашинной информационной базы.

 

- Принципы построения.

 

- Структура.

 

ПРИМЕР.

 

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

 

‒ Организация внемашинной информационной базы (информации в бумажном виде от внешних организаций).

 

8. Комплекс технических средств системы.

 

-  Структура комплекса технических средств.

 

ПРИМЕР.

 

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

 

‒ Вычислительный комплекс.

 

‒ Абонентские пункты.

 

‒ Аппаратура передачи данных.

9. Ведомость документов.

 

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

 

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

 

2.4.               Рабочее проектирование / прототипирование  при заказной разработке.

 

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

 

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

 

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

 

Рассмотрим основные виды / типы прототипов.

 

В качестве первой классификации можно выделить «горизонтальное» и «вертикальное» прототипирование.

 

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

 

А в рамках «вертикального» прототипа, в отличие от предыдущего варианта, фокус переходит на саму структуру системы, используемые среды / языки программирования для проверки корректности и работоспособности сформированного архитектурного решения.

 

Второй (и более известной) классификацией является «быстрое» и «эволюционное» прототипирование.

 

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

 

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

2.5.                Модели представления для проектирования ИС.

 

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

 

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

 

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

 

Предлагается ввести пять основных моделей представления для проектирования информационных систем:

 

• функциональная модель;

 

• модель данных;

 

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

 

• структура программных модулей;

 

• логика.

 

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

 

• действие;

 

• данное;

 

• систему;

 

• объект;

 

• атрибут.

 

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

 

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

 

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

 

Модель пользовательского интерфейса ориентирована на  описание взаимодействий пользователей с проектируемой системой, состава форм представления и команд управления заданиями.

 

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

 

Логика ориентирована на описание потока управления  (последовательности выполнения) операторов программной системы и действий пользователей.

 

Важным элементом проектирования ИС является ядро моделей представления функциональных спецификаций, опирающееся на следующие компоненты: КОНФИГУРАЦИЮ И СТРУКТУРУ.

 

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

 

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

 

Структура (лат. structura) — прочная, относительно устойчивая связь (отношение) и взаимодействие элементов, сторон, частей предмета, явления, процесса как целого.

 

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

 

вид_элемента — определяет устойчивый для конкретной  предметной области набор свойств, объединяющий конкретные  проектируемые компоненты в группы;

 

вид_отношения — определяет устойчивые для конкретной предметной области группы связей между проектируемыми  компонентами;

 

отношение — определяется видами элементов, вступающими во взаимосвязь и видом отношения, задающим семантику связей.

 

Ядро позволяет описывать требуемые виды отношений, виды элементов и отношения.

 

3. РАЗРАБОТКА ИС.

 

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

 

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

 

3.1. Закупка ПО.

 

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

 

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

 

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

 

1)   Функциональность системы.

 

2)   Надежность / стабильность работы решения (устойчивость к различным режимам работы и степени активности пользователей).

 

3)   Наличие встроенных средств администрирования / управления.

 

4)   Стоимость (внедрения, лицензий, поддержки).

 

5)   Удобство организации услуг по поддержке и сопровождению системы.

 

6)   Наличие отраслевого решения.

 

7)   Наличие успешного опыта реализации проектов на базе данной платформы (надежность системы).

 

8)   Опыт и компетенции организаций-подрядчиков.

 

9)   Учет отраслевой / корпоративной специфики / соответствие корпоративным стандартам.

 

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

 

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

 

Типовая структура подобного договора приведена ниже.

 

1. Предмет договора.

 

Например, поставка, установка ПО, монтаж оборудования, обучение персонала заказчика.

 

2. Стоимость договора и порядок оплаты.

 

Сумма оплаты, сроки и размер платежей, форма оплаты (наличный / безналичный платеж).

 

3. Права и обязанности сторон.

 

Порядок поставки / установки / ввода в эксплуатацию ПО, предоставления информации со стороны поставщика. Порядок назначения ответственных лиц, предоставления информации со стороны покупателя.

 

4. Ответственность сторон.

 

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

 

5. Гарантийное сопровождение / авторский надзор.

 

6. Условия конфиденциальности.

 

3.2. Настройка конфигураций.

 

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

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

 

Процесс настройки конфигураций системы предполагает создание кода программы.

 

Единого языка программирования, использующегося для всех приложений, просто не бывает. Сейчас для многих стандартных пользовательских приложений используется комбинация SQL и C# для серверной программной части и HTML/CSS/JavaScript для создания интерфейса пользователей.

 

ПРИМЕР.

 

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

 

Примеры использования языков программирования в  ERP-системах:

 

‒  SAP – ABAP.

 

‒  Oracle – PL/SQL, Java.

 

‒  Microsoft Dynamics AX – среда разработки MorphX с языком программирования X+.

 

‒ Microsoft Dynamics NAV – графическая среда разработки C/SIDE с языком программирования C/AL.

 

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

 

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

 

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

 

Интерфейс пользователя → Конфигуратор → Код программы

 

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

 

НАСТРОЙКА ПАРАМЕТРОВ СИСТЕМЫ В РЕЖИМЕ «КОНФИГУРАТОРА»

 

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

 

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

 

1. Настройка полей и создание библиотек системы.

 

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

 

ПРИМЕР.

 

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

 

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

 

2. Настройка логики бизнес-процессов.

 

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

 

ПРИМЕР.

 

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

 

На примере конфигурации в системе SAP в таком случае объектами настройки будут:

 

‒ Создание вида выручки к счету.

 

‒ Определение схемы перерасчета, схемы учета результатов для заказа.

 

‒ Определение вида заказа для отражения бонуса.

 

‒ Ведение профиля расчета, присвоение профиля расчета виду заказа.

 

3. Интерфейс пользователя, расположение элементов на вкладках.

 

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

 

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

 

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

3.3. Создание ролей пользователей.

 

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

 

‒ Какой именно функциональностью системы будет пользоваться тот или иной сотрудник (группа сотрудников).

 

‒ Какие данные будут ему доступны.

 

‒ Какие он будет иметь права на чтение, редактирование информации, ее экспорт (!) и удаление.

 

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

 

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

 

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

ПРИМЕР.

 

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

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

 

3.4. Миграция данных.

 

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

 

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

 

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

 

В таких случаях миграция организуется в онлайн-режиме. Такой способ предполагает перенос данных при непрерывной работе всех серверов и приложений. Это особенно важно для критических для бизнеса приложений с высокими требованиями к доступности: Oracle, Exchange, биллинговых систем, систем электронной коммерции. Новые данные внедряются в уже существующий поток информации, объединяются с ними на логическом уровне через отдельный адрес диска, который после успешной миграции удаляется или архивируется.

 

К наиболее распространенным рискам миграции данных и причинам их возникновения можно отнести:

 

1)   Недостаточные компетенции / опыт команды проекта в миграции данных (в том числе, в части формирования документации об уже осуществленных проектах).

 

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

 

3)   Низкое качество переносимых данных (дублирование, некорректные форматы данных).

 

4)   Нестабильность целевой системы для переноса данных.

 

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

 

5)   Несвоевременность организации синхронизации данных. Актуализация данных должны производиться в новой системе сразу после миграции.

 

6)   Низкая степень документированности процесса миграция. Данный риск относится не только к невозможности использовать полученный опыт для выполнения дальнейших проектов. В большей степени, этот риск связан с невозможностью в случае возникновения необходимости продемонстрировать аудиторам/ компетентным контролирующим органам отчеты по датам и масштабам перемещения данных. А значит, потенциально может возникнуть огромное количество проблем, связанных с доказательством достоверности предоставленной отчетности. Особенно это актуально, если данные для отчетности выгружались в период параллельной работы старой и новой систем, при наличии различий в объемах данных, хранившихся в них в конкретный момент.

 

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

 

Среди основных причин появления подобных данных-«двойников» отметим следующие.

 

1. Различия в написании объектов:

 

ПРИМЕР.

 

‒ Организационно-правовые формы / формы собственности («ЗАО» Вымпел, ОАО «Вымпел», ВЫМПЕЛ). Это приводит к путанице: идет ли речь о разных предприятиях либо об одной и той же компании?

 

‒ Использование латиницы и сокращений: Ivanov Ivan, Иванов И.

 

2. Несовпадение информации из-за устаревания данных.

 

ПРИМЕР.

 

В одной системе в качестве адреса ООО «Вымпел» указывается г. Воронеж, а в другой – г. Москва. Разница может быть обусловлена переездом компании либо же разной трактовкой понятия «адрес» сотрудниками, вводившими информацию в систему: в первом случае – юридический адрес компании, во втором – фактический.

 

3. Несовпадение форматов данных.

 

ПРИМЕР.

 

Неиспользование выпадающих списков для полей с ограниченным числом значений: г. Балашиха в одной системе и «Московская область» в другой.

 

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

 

Стиль написания цифр: +7 (495) 123-45-67, 84951234567.

 

Во всех этих случаях необходима тщательная выверка всех данных, проводящаяся частично в автоматизированном режиме (например, для замены «+7» в телефонных номерах на «8», удалении лишних пробелов / символов), частично в ручном режиме пользователями.

 

3.5. Разработка контрольного примера.

 

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

 

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

 

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

 

‒ Проверка наиболее «слабых» мест системы для повышения вероятности обнаружения ошибок.

 

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

 

‒ Явно выявляет ошибки / недоработки.

 

‒ Понятность и логичность описания примера для пользователей.

 

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

 

Ко времени старта тестовой эксплуатации таким образом должны быть подготовлены такие элементы модели тестирования, как:

 

‒ Набор исходных данных / условий тестирования / планируемых результатов.

 

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

 

‒ Контрольный пример / сценарий тестирования.

 

‒ Тестовый скрипт (опционально: в случае использования автоматизированных инструментов тестирования).

 

Формальным основанием для старта тестовой эксплуатации могут служить:

 

‒ Протокол совещания группы внедрения о передаче модуля системы в тестовую эксплуатацию.

 

‒ Регламент тестирования контрольного примера.

 

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

 

3.6. Тестовая эксплуатация.

 

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

 

Среди наиболее больших блоков / классов проводимых тестов можно выделить следующие:

 

‒ КОМПОНЕНТНОЕ / МОДУЛЬНОЕ ТЕСТИРОВАНИЕ (component / unit testing).

 

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

 

‒ ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ. Данный тип тестирования проводится для всей системы в целом. Его основная задача – проверка корректности передачи информации и взаимодействия между всеми модулями / компонентами системы и слоями архитектуры (в частности, прикладным программным обеспечением, инфраструктурными сервисами / операционной системой). Особенно данный тип тестирования актуален для клиент-серверных / распределенных систем.

 

‒ СИСТЕМНОЕ ТЕСТИРОВАНИЕ (в т.ч. функциональное тестирование).

 

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

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

 

ТЕСТИРОВАНИЕ В ЗАВИСИМОСТИ ОТ СПЕЦИФИКИ СИСТЕМЫ / ПРЕДМЕТНОЙ ОБЛАСТИ МОЖЕТ ПРОВОДИТЬСЯ В РУЧНОМ / АВТОМАТИЗИРОВАННОМ ИЛИ ПОЛУАВТОМАТИЗИРОВАННОМ РЕЖИМЕ.

 

‒ В ручном режиме специалисты по тестированию самостоятельно проходят весь контрольный пример / сценарий тестирования. Этот способ применяется для крайне динамической разработки в условиях постоянных изменений. По результатам составляется протокол тестирования, в который заносятся все замечания, комментарии и предложения.

 

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

 

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

 

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

 

‒ ГОСТ 12119 ИТ. Пакеты программ. Требования к качеству и тестирование.

 

‒ ГОСТ 12207 ИТ. Процессы жизненного цикла программных средств.

 

‒ ГОСТ 14764 ИТ. Сопровождение программных средств.

 

‒ ГОСТ 15288 ИТ. Системная инженерия. Процессы жизненного цикла систем.

 

‒ ГОСТ 15504 ИТ. Оценка процессов.

 

‒ ГОСТ 28195 ИТ. Оценка качества программных средств. Общие положения.

 

‒ ГОСТ 9126 ИТ. Оценка программной продукции. Характеристики качества и руководства по их применению.

 

‒ ГОСТ серии 19 Единая система программной документации (ЕСПД).

 

‒ ГОСТ серии 34 Разработка автоматизированной системы управления.

 

‒ IEEE 829 Стандарт документирования тестирования программного обеспечения и систем.

 

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

 

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

 

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

 

‒ Предварительное тестирование командой внедрения контрольного примера (по отдельным модулям!) с занесением замечаний в журнал тестирования и последующим их устранением (в случае необходимости с дополнительными настройками / доработками).

 

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

 

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

 

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

 

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

 

3.7. Доработка по результатам тестирования.

 

Основная цель данной активности – устранить замечания, возникшие в результате тестирования на контрольном примере и, при необходимости, осуществить дополнительные настройки и доработки модулей системы. Как уже было сказано, на данном этапе также важно разделять критичные для успешной работы с системой и дополнительные, nice-to-have требования пользователей-экспертов, которые можно будет включить в следующие итерации работы и версии системы.

 

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

 

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

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

 

С этой целью проводится регрессионное тестирование (regression testing), один из наиболее известных видов которого получил название sanity-тестирования. Это тестирование определенных участков кода, проводимое по результатам внесенных изменений. Его основная задача – удостовериться в том, что внесенные изменения не затронули работоспособность системы и не послужили причиной новых ошибок. К примеру, проверяется, действительно ли исправленные ранее ошибки исправлены, не приводят ли сделанные изменения к нейтрализации исправлений старых ошибок (регрессия багов, bug regression) и есть ли новые ошибки.

 

В результате должны быть:

 

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

 

‒ Проведены дополнительные настройки и доработки модуля системы (в срок до 4 недель с момента передачи модуля системы в тестовую эксплуатацию и получения перечня окончательных доработок и настроек модуля системы).

 

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

 

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

 

‒ Сформирован протокол выполненных работ по обучению ключевых пользователей Заказчика базовым основам работы с модулем системы на данных контрольного примера.

 

‒ Подготовлен перечень окончательных доработок и настроек каждого модуля системы.

 

3.8. Прием результатов испытаний.

 

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

 

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

 

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

 

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

 

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

 

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

 

‒ Заказчиком утверждены итоговые документы.

 

СПИСОК РЕКОМЕНДОВАННОЙ ЛИТЕРАТУРЫ.

 

[1] Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Курс лекций. Учебное пособие для студентов вузов, обучающихся по специальностям в области информационных технологий.  – М.: Интернет ун-т Информ. Технологий, 2005. – 304 с., ил.

 

[2] Зараменских Е.П. Управление жизненным циклом информационных систем: Монография – Новосибирск: Издательство ЦРНС, 2014. – 270 с.

[3] Информационные системы в экономике: Учебник. /Под ред. Г.А. Титоренко. – 2-е изд., перераб.  и доп. – М.: ЮНИТИ-ДАНА, 2008. – 463 с.

    

[4] Информационные системы и технологии в экономике и  управлении: Учебник / Под ред. проф. В.В. Трофимова. — М.: Высшее  образование, 2006.-480 с.

 

[5] Советов Б.Я., Цехановский В.В.  Информационные технологии: Учебник для вузов –  3-е изд., стер. – М.: Высш. шк., 2006. – 263 с: ил.