Лекция
№7
Проектирование
и разработка ИС
Оглавление
1.
Проектирование
Проектирование
включает в себя два основных аспекта: техническое
и рабочее проектирование. В первом случае проводится описание технических
деталей (к примеру, модели данных и интерфейса), а также моделирование
ситуаций, в которых система будет использоваться – для дальнейшей разработки
сценариев использования системы и ее тестирования на их основе. При рабочем же
проектировании могут составляться блок-схемы и алгоритмы для программных
модулей. В целом же техническое
проектирование ИТ-системы предполагает детальную
подготовку к этапу настройки / развертывания модулей системы, для чего
необходимо решить несколько задач:
‒ Сформировать список модулей и функций
системы, необходимых для поддержки определенных на этапе анализе
автоматизируемых бизнес-процессов.
‒ Сформировать список справочников
систем (будущей и если применимо, текущей) для дальнейшего переноса и
обновления данных.
‒ Определить примерный сценарий работы
системы по категориям пользователей для формирования необходимого набора
диалогов и процедур проектируемой системы (включая реакции на все возможные и
даже очень маловероятные действия со стороны пользователя).
‒ Определить
элементы интерфейса пользователей (в случае гибкого или разрабатываемого «с
нуля» решения) для достижения удобства работы с системой.
‒ Сформировать
список отчетов / панелей мониторинга (включая их формы и обязательные для
реализации элементы). Эти отчеты в дальнейшем будут использоваться как для
учетных целей, так и для целей мониторинга системы ее администратором (в части
формирования и сбора статистики по нагрузке на ее отдельные модули, свободных
ресурсах, активности пользователей и т.п.).
‒ Определить
перечень настроек функциональных компонентов системы в соответствии со
выделенными на предыдущем этапе требованиями.
‒ Определить
необходимость, возможности и пути интеграции с существующими и планируемыми к
реализации системами на предприятии заказчика, чтобы своевременно предусмотреть
технические средства для интеграции.
На этапе детального
проектирования важно крайне четко определить все функциональные возможности
системы и определить ее место в общей программной архитектуре предприятии
ПРИМЕР Если
предполагается, что система взаимодействия с клиентами CRM будет получать
данные из личных кабинетов клиентов на портале компании, необходимо предусмотреть
подобную интеграцию. Если в компании уже внедрена и работает ERP-система, CRM
должна получать и предоставлять ей данные.
С организационной
перспективы к этому моменту важна подготовка иерархической структуры работ /
базового календарного плана / дорожной карты, которые бы позволили управлять
проектом на протяжении всей его реализации.
ПРИМЕР Календарный ресурсный план.
Техническое
проектирование
Цель
данного этапа – подготовка к этапу настройки модулей системы в целом. Данный
этап предусматривает разработку организационной и функциональной структуры
модуля системы, определение уровня автоматизации информационного процесса
предприятия, определение структуры информационного и технического обеспечения и
требований к их элементам, постановку и алгоритмизацию задач обработки данных,
разработку системы ведения нормативно-справочной базы.
Результаты работ
оформляются в виде технического проекта (проектного решения на автоматизацию
модуля системы) и представляют собой задание на программирование. Техническое
проектирование, создание, настройка, доработка и внедрение модуля системы
осуществляются только на основании соответствующих утвержденных технических
заданий (проектных решений).
Технический
проект (проектное решение по автоматизации модуля) – документ, содержащий
описание функциональных компонентов системы, необходимых для реализации
бизнес-процессов, описанных на этапе подготовки проектного решения, а также
необходимых доработок системы и (при необходимости) процедур интеграции с
модулями (или внешними системами), внедренными ранее.
Перечень документов, создаваемых на стадии «Технический
проект», определяется документом ГОСТ 34.201-89. Основной задачей является
разработка архитектуры системы и технических решений по ее реализации. Перечень
документов, служащих базой технического проекта, определяется условиями
договора / технического задания, но чаще всего в него включаются следующие
документы:
1.
Пояснительная записка.
‒
Общие положения.
ПРИМЕР Стадии и сроки, цели и задачи, используемые при разработке
системы объекты ИС.
‒ Описание процесса деятельности.
‒ Основные технические решения. ПРИМЕР Структура системы, основные функции,
режимы функционирования, требования к персоналу.
‒
Мероприятия по подготовке объекта автоматизации к вводу системы в действие. ПРИМЕР Подготовка информации к импорту,
создание рабочих мест.
2. Входные и выходные данные системы. ПРИМЕР Импортируемые и вводимые вручную
пользователями данные (названия и источники документов), формируемые системой
документы.
3.
Схема функциональной структуры.
‒ Описание функций подсистем.
ПРИМЕР Описание функций по отдельным
модулям (например, модуль расчета заработной платы, модуль учета труда).
‒ Информационные связи между элементами
и с внешней средой.
ПРИМЕР Условия обмена информацией с внешними системами.
4. Описание автоматизируемых функций.
‒
Исходные данные.
‒ Цели АС и автоматизируемые функции.
‒
Характеристика функциональной структуры. ПРИМЕР Список подсистем, описание процесса
реализации функций, требования (к надежности, защите информации от
несанкционированного доступа, сохранности информации).
‒
Типовые решения.
5.
Постановка задач и алгоритмы решения
‒
Характеристики комплекса задач.
‒
Используемая информация.
‒
Результаты решения.
ПРИМЕР Информация для выдачи выходных сообщений и данные исключительно
для использования внутри системы.
‒ Алгоритм решения.
6.
Программное обеспечение.
‒
Структура ПО.
‒ Функции частей ПО.
‒ Методы и средства разработки ПО. ПРИМЕР Инструментальные
средства проектирования модели предметной области, структур баз данных,
разработки. ПРИМЕР Применяемые
методологии разработки, проектирования системы / интерфейсов.
‒
Операционная система. ПРИМЕР
Совместимые / предпочтительные операционные системы для клиентской части ПО и
серверов (баз данных).
‒ Средства, расширяющие возможности ОС.
7.
Информационное обеспечение.
‒ Состав информационного обеспечения.
·
Внутримашинная
информационная база
– набор электронных таблиц и других объектов
баз данных для обработки и хранения данных.
·
Внемашинная
информационная база
–
информация, поступающая в бумажном виде. ПРИМЕР Нормативно-справочная информация,
годовые бюджеты.
‒ Организация информационного
обеспечения.
·
Принципы организации информационного
обеспечения. ПРИМЕР База данных должна
представлять собой взаимосвязанные реляционные таблицы.
·
Обоснование выбора носителей
данных. ПРИМЕР Расчет числа запросов,
которые необходимо обрабатывать, на основе статистики предыдущих периодов по
числу пользователей, объему информации, частоте обращения к ней.
·
Принципы и методы контроля в
маршрутах обработки данных. ПРИМЕР
Контроль форматов данных, контроль заполнения обязательных полей.
·
Описание решений, обеспечивающих
информационную совместимость АС с другими системами.
‒
Организация сбора / передачи информации
·
Основные источники информации. ПРИМЕР Информация из внешних систем, бумажные
носители информации, передаваемые по электронной почте файлы.
·
Общие требования к организации сбора,
передачи, контроля и корректировки информации.
ПРИМЕР Импорт данных в формате XML.
‒ Построение системы классификации и
кодирования.
·
Классификации объектов, принятые для
применения в АС. ПРИМЕР Общероссийский
классификатор валют (ОК 014-94), Коды представления названий стран (ИСО
3166-93), внутриорганизационный справочник сотрудников.
·
Классификации объектов, принятые для
применения в АС. ПРИМЕР Типы документов
обозначаются целыми положительными числами от 1 в возрастающей
последовательности.
‒ Организация внутримашинной
информационной базы.
·
Принципы построения.
·
Структура. ПРИМЕР Физическая структура базы данных
системы (с полями, типами данных).
‒ Организация внемашинной
информационной базы (информации в бумажном виде от внешних организаций).
8.
Комплекс технических средств
системы.
Структура комплекса технических
средств.
ПРИМЕР В состав подобного комплекса могут
включаться: серверы баз данных, приложений, веб-сервер,
персональные компьютеры. Принципы построения кластеров.
·
‒ Вычислительный комплекс.
·
‒ Абонентские пункты.
·
‒ Аппаратура передачи данных.
9. Ведомость документов.
В результате подготовки технического проекта
должен быть определен перечень компонентов модуля системы, необходимых
доработок, процедур интеграции с существующей системой (при ее наличии и
необходимости), необходимый для реализации бизнес-модели
предприятия To-Be. Также однозначно утверждается
перечень работ по настройке и доработке модуля системы и перечень / формы
отчетов и первичных документов, получаемых из модуля системы. Помимо отчетов,
должны быть определены процедуры для справочников системы (при ее наличии),
которые необходимо использовать для импорта, и тех справочников, для которых
необходимо разработать механизмы двустороннего обновления информации. Важно
отметить, что после детального определения и согласования всех вышеописанных
параметров необходимо к моменту начала следующего этапа выбрать и подготовить
также среду разработки и тестирования для проведения развертывания
системы.
Рабочее
проектирование / прототипирование при заказной разработке
В
целях снижения риска создания не соответствующей требованиям и техническому
проекту системы перед разработкой возможно создать ее прототип (макет) для
проверки предлагаемых архитектурных / функциональных / интерфейсных решений на
практике с будущими пользователями.
Прототип
– «черновая» реализация интерфейса и базовой функциональности системы для
анализа принципов ее работы и тестирования совместно с будущими пользователями
в целях дальнейшей доработки и совершенствования.
Обратная
связь в рамках прототипирования, организованная на
первых этапах жизненного цикла, очень важна для устранения замечаний по итогам проектирования
и внесении доработок в интересах пользователей и заказчиков системы.
В первую очередь создается макет, а уже потом
проводятся тестирование / обсуждение и внесение корректировок в спецификации и
прототип.
Рассмотрим основные виды / типы прототипов.
В качестве первой
классификации можно выделить «горизонтальное»
и «вертикальное» прототипирование. Первый случай («горизонтальное» прототипирование)
предполагает моделирование исключительно пользовательского интерфейса и форм
без фокусирования на логике обработки информации. Имитируются результаты
действий / запросов при нажатии на элементы управления и осуществляются
переходы между формами системы для формирования представления, каким образом
система реагирует на те или иные действия пользователя (и какие не
предусмотренные в текущей реализации функции / действия потенциальный
пользователь может совершить). Таким образом, возможно проверить и
устранить противоречия между сформированными на этапе анализа требованиями и их
реализацией в техническом проекте. А в рамках «вертикального» прототипа, в отличие от предыдущего варианта, фокус
переходит на саму структуру системы, используемые среды / языки
программирования для проверки корректности и работоспособности сформированного
архитектурного решения. Второй (и более известной) классификацией является «быстрое» и «эволюционное» прототипирование.
В первом случае (как и следует из названия) по технологии RAD, более подробно
рассматриваемой в главе методологий разработки, создается макет определенных
компонентов системы для более предметного и эффективного диалога между
разработчиками кода / интерфейсов / пользователями. Важно, что подобный прототип не призван в дальнейшем
дорабатываться и становиться частью системы, соответственно, достигается
значительная экономия времени и ресурсов, так как нет необходимости
фокусироваться на технических деталях быстродействия или энергоэффективности
системы. Напротив, эволюционное прототипирование, по сути являясь итерационной разработкой,
подразумевает создание в несколько итераций кода и тестирование полноценной
рабочей системы, с реализованными алгоритмами и целевым уровнем
производительности.
2. Разработка
Ко времени старта
реализации системы,
как уже было сказано, должна быть
выбрана и подготовлена среда разработки, а также выбрана методология, в
соответствии с которой будет осуществляться управление разработкой. От нее
зависит очень многое: принцип взаимодействия команды разработки / внедрения
(между собой и с основными стейкхолдерами проекта),
следование одной из моделей жизненного цикла ИС (каскадной, итерационной и пр), длительность самого процесса разработки и тестирования
и прочие важные аспекты процесса реализации системы.
1.
Закупка ПО
когда
организуется закупка стандартного («тиражируемого») решения и его последующая
настройка под бизнеспроцессы компании. Случаи
заказной разработки системы «с нуля» не рассматриваются. Каждая организация
выбирает собственные, оптимальные именно с учетом ее специфики критерии выбора
между рядом платформ/решений, среди наиболее распространенных из которых:
‒ Функциональность
системы.
‒
Надежность / стабильность работы решения (устойчивость к различным режимам
работы и степени активности пользователей).
‒ Наличие
встроенных средств администрирования / управления.
‒ Стоимость (внедрения, лицензий,
поддержки).
‒
Удобство организации услуг по поддержке и сопровождению системы.
‒ Наличие отраслевого решения.
‒
Наличие успешного опыта реализации проектов на базе данной платформы
(надежность системы).
‒ Опыт и компетенции организаций-подрядчиков.
‒ Учет отраслевой / корпоративной
специфики / соответствие корпоративным стандартам.
Список критериев
очень индивидуален в зависимости от специфики проекта и как правило,
формируются из разработанных на этапе проектирования требований к системе.
Следующим же шагом будет организация непосредственно процедуры закупки
(например, путем открытого запроса предложений), выбор поставщика и заключение договора на поставку ПО.
Типовая
структура подобного договора приведена ниже.
1. Предмет договора.
Например, поставка, установка ПО, монтаж оборудования, обучение персонала
заказчика.
2. Стоимость договора и
порядок оплаты. Сумма оплаты, сроки и размер платежей, форма оплаты (наличный /
безналичный платеж).
3. Права и обязанности
сторон. Порядок поставки / установки / ввода в эксплуатацию ПО, предоставления
информации со стороны поставщика. Порядок назначения ответственных лиц,
предоставления информации со стороны покупателя.
4. Ответственность сторон. Условия выплаты
неустойки / расторжения контракта в случае невыполнения или ненадлежащего
выполнения обязательств (в т.ч. несвоевременная поставка или оплата). Порядок
разрешения споров, в т.ч. в случае действия обстоятельств непреодолимой силы.
5. Гарантийное
сопровождение / авторский надзор.
6. Условия
конфиденциальности.
2.
Настройка конфигураций
К моменту инсталляции
системы на стенде предприятия, заказчиком должна быть обеспечена устойчивость работы
ЛВС стенда, проведена закупка программно-технического обеспечения в виде
основного внедряемого программного продукта (самой системы) и ключей
электронной защиты, а также завершены все работы предшествующих фаз жизненного
цикла. Для
инсталляции / тестирования системы программно-техническое обеспечение, в том
числе клиентские лицензии предоставляет заказчик (из числа закупленных ранее
либо через осуществление их закупки на этом этапе). В процессе инсталляции
модули системы устанавливаются на стендовый сервер с проведением основных
необходимых настроек под подлежащие автоматизации бизнес-процессы предприятия
заказчика. В зависимости от типа и
особенностей системы в ней могут быть реализованы разные механизмы дополнения /
изменения объектов в системе. Создание
кода программы Единого языка
программирования, использующегося для всех приложений, просто на бывает. Сейчас для многих стандартных
пользовательских приложений используется комбинация SQL и C# для серверной
программной части и
Код программы может являться
самодостаточным способом настройки системы либо же
дополняться т.н. «конфигуратором» или «конструктором» системы. Разница между ними в возможностях
внесения изменений (бизнес-логика и правила работы приложения, как правило,
требуют большего и более сложного объема работы, нежели просто добавление
нового поля). Для более простых же функций используются, как правило,
стандартные конфигураторы системы, не требующие знания языка программирования. Таким образом, может быть выстроена
следующая иерархия возрастания сложности и функциональных возможностей внесения
изменений:
Интерфейс пользователя
Конфигуратор
Код программы
Разумеется, крайне важно, чтобы конфигурация
была тщательным образом документирована, особенно в части «надстроек» над
стандартными функциональными возможностями, описываемыми в том числе в
поставляемой вендором документации. Также необходимо
обеспечить такую доработку кода, которая бы не содержала в себе элементы т.н.
«закрытого кода», недоступного для изменения. В противном случае если в ходе
разработки была создана определенная схема расчета или логика процесса, то в
случае необходимости внесения изменений ИТ-специалистам
придется с нуля создавать требуемый код / функциональность. Именно поэтому
специалисты должны быть обучены не только технике конфигурирования продукта, но
и самим особенностям конкретной конфигурации.
Настройка параметров системы в режиме «конфигуратора» Примером системы, работающей в подобном
режиме конструктора, является Salesforce.com. В ней разработчик имеет
возможность определять множество параметров, таких как: формат данных
создаваемых полей, их взаимосвязи, формат отображения, источники данных (ручной
ввод, вычисление по формуле или получение информации из других источников).
Пример экрана создания подобных полей приведен ниже. В том или ином виде конфигураторы присутствуют практически во всех
системах, но объем их возможностей (и требования к квалификации работающих с
ними специалистов) значительно различаются.
1. Настройка полей и создание библиотек
системы.
Наиболее простой из типов конфигурируемой информации. По сути таким образом
предоставляется возможность расширить информацию об объектах системы и
расширить возможности их взаимодействия. Дополнительные прописываемые поля,
типы данных и прочие элементы позволяют кастомизировать
каждый объект, а также описать возможные для него действия. ПРИМЕР Возможность дополнить карточку
сотрудника в системе набором новых полей с выбором типа каждого поля и
установки для них ограничений. Так, если в стандартной конфигурации существуют
только три поля: Идентификатор сотрудника, Фамилия и Имя, то можно добавить
любые дополнительные поля: Дата рождения, Должность, Дата принятия в штат. Для
системы в дальнейшем не будет различий, были ли созданы поля автоматически или
вручную, и они все в полной мере могут быть использованы в функциях поиска,
фильтрации, создания отчетов.
2. Настройка логики бизнес-процессов. Вторым видом наиболее часто
используемых объектов конфигурации являются сами процессы. Например, в системе
могут прописываться пути движения документов, когда после утверждения документа
первым согласующим он автоматически направляется второму согласующему с
отправкой уведомления о статусе «владельцу» документа в системе. ПРИМЕР Приведем пример настройки логики
бизнес-процесса выплаты бонусов сотрудникам филиала компании на основе
результатов продаж. Бонусы планируются к выплате на периодической основе. На
примере конфигурации в системе SAP в таком случае объектами настройки будут:
‒
Создание вида выручки к счету.
‒ Определение схемы перерасчета, схемы
учета результатов для заказа.
‒
Определение вида заказа для отражения бонуса.
‒ Ведение профиля расчета, присвоение
профиля расчета виду заказа.
3. Интерфейс пользователя, расположение
элементов на вкладках.
В конфигураторах большинства систем предоставляется также возможность изменять
расположение объектов, скрывать некоторые из них, создавать персонализированные
фильтры / настройка для групп пользователей. Данный шаг подробнее
рассматривается в следующем разделе пособия – «Создание ролей пользователей».
По результатам конфигурирования системы подрядчиком подготавливаются описание оптимальных
настроек сервера баз данных и рекомендации по развертыванию рабочих мест,
которое и проводится следующим шагом. Это также позволяет выявить и устранить
ошибки и неточности в программном продукте, затем подготовив описание тестового
сценария (контрольного примера действий пользователя) для проверки корректности
и актуальности осуществленных настроек. Результатом инсталляции и настройки
модули системы являются развернутые и готовые к переносу в них справочники и
данные, формы ввода данных адаптированы, подготовлен акт сдачи-приемки
работ.
.3.
Создание ролей пользователей
Права
доступа (и ролей пользователей) являются именно тем инструментом, который
определяет:
‒ Какой именно функциональностью системы
будет пользоваться тот или иной сотрудник (группа сотрудников).
‒
Какие данные будут ему доступны.
‒ Какие он будет иметь права на чтение,
редактирование информации, ее экспорт (!) и удаление.
Отдельно
отметим экспорт информации как
предоставляемую системой функциональность, тесно взаимосвязанную с
информационной безопасностью – а значит, возможность выгрузки конфиденциальных
данных должна быть предоставлена только ограниченному кругу лиц. С
технической точки зрения подобный доступ позволяет одному пользователю иметь
несколько ролей по отношению к разным объектам системы. Роли пользователей
значительно зависят от профиля компании и специфики системы, однако в целом они различаются по правам
доступа к каждой из категорий данных. В списках доступа чаще всего задаются
следующие возможности (по возрастанию объема прав):
R
(read) – Чтение
Возможность
видеть элементы страницы и просматривать прикрепленные файлы
W
(write) – Запись
Возможность
изменять / редактировать значения полей страницы, добавлять файлы (возможность
чтения, разумеется, сохраняется)
D
(delete) – Удаление
Возможность
удалять страницу вместе с прикрепленными файлами (доступ на чтение / запись при
этом сохраняется)
A
(admin) – Администрирование
Возможность
добавлять / удалять дополнительные поля, менять формат представления,
предоставлять и отзывать доступ к элементам (при
сохранении возможности чтения, записи и удаления).
Получается логическая
связка следующего вида: Учетная запись
пользователя – Роль пользователя – Права доступа (комбинация прав и элементов, к которым осуществляется доступ)
УЧЕТНАЯЗАПИСЬ
СОТРУДНИКА2 УЧЕТНАЯЗАПИСЬ
СОТРУДНИКА4 УЧЕТНАЯЗАПИСЬ
СОТРУДНИКА3 УЧЕТНАЯЗАПИСЬ
СОТРУД УЧЕТНАЯЗАПИСЬ
СОТРУДНИКА1
ПРИМЕР
RW
R R RW
ПАКЕТ
ДОКУМЕНТОВ1
,
Как
видно из данного примера, несколько сотрудников (например, работающие на равных
позициях одного подразделения) могут обладать одной ролью в системе (например, аккаунт-менеджера). В таком случае все права доступа будут
прописываться не для каждого отдельного пользователя, а для ролей (что гораздо
эффективнее с точки зрения трудозатрат, в особенности при внесении изменений).
Далее на примере приведены пакеты документов, к которым определен доступ,
однако тот же самый принцип действует и для полей (групп полей) и страниц в
системе. Так, в системе CRM аккаунт-менеджеру будет
доступна возможность просмотра, редактирования и удаления мобильных телефонов
его клиентов, но может быть отказано в доступе на внесение изменений в
финансовые детали осуществления платежей. И напротив, сотрудники бухгалтерии с
ролью «специалист по расчетам» смогут редактировать любые финансовые данные, но
не будут видеть мобильные телефоны и историю сообщений руководства
компании-клиента, которые доступны аккаунт-менеджеру.
4. Миграция данных
Данные на протяжении
своего жизненного цикла претерпевают огромное число действий над ними:
создание, обработка / редактирование, резервирование, копирование, перемещение
в новую виртуальную среду, новую систему. Миграция данных является очень важной
составляющей процесса внедрения системы – по сути, на этом этапе создается
механизм, позволяющий автоматически переносить основные справочники и другие
данные в модули системы. В первую очередь, важнейшим шагом является
непосредственно перенос (первичная загрузка) и настройка основных справочников.
По сути, это все те данные, которые являются едиными для различных модулей и
систем предприятия и используются ими совместно и одновременно: справочники
поставщиков, клиентов, складов, материалов, продукции (номенклатуры) и другие.
Именно благодаря наличию подобных
основных данных не происходит дублирования записей, а в при внедрении систем не
приходится заниматься ручным поиском, сбором и вводом этой информации. В целях
тестирования основные справочники новой системы заполняются тестовыми данными,
достаточными для тестирования модуля и принципов поступления и передачи из него
информации, и затем переносятся в систему. Если по результатам выверки тестовых
данных не наблюдается ошибок, то можно говорить об успешной миграции
справочников и на первый план выходит уже другой вопрос, а именно: поддержание
всех этих данных в актуальном состоянии. Другой категорией данных для передачи
является информация из функционирующих на предприятии программных рещений / legacy-систем, на смену которым внедряется новый
программный продукт. При корректной подготовке на стадии проектирования
передача данных в новую систему организовывается автоматизированно,
через специальные коннекторы / шины данных. В
противном случае миграция данных становится «ночным кошмаром», когда они должны
быть в ручном режиме выгружены из существующих систем, приведены к единому
формату, определено соответствие полей и данные загружены в новую систему. Но
ведь данные в существующих системах могут обновляться ежесекундно. Насколько
допустим этот простой во время миграции и как избежать всех ассоциированных с
распределенным онлайнвводом? Не говоря уже о проблеме
ресурсоемкости и неимоверной трудоемкости данного процесса, связанного с
огромным риском потери информации. В таких случаях миграция организуется в онлайн-режиме. Такой способ предполагает перенос данных при
непрерывной работе всех серверов и приложений. Это особенно важно для
критических для бизнеса приложений с высокими требованиями к доступности: Oracle, Exchange, биллинговых систем, систем электронной коммерции. Новые
данные внедряются в уже существующий поток информации, объединяются с ними на
логическом уровне через отдельный адрес диска, который после успешной миграции
удаляется или архивируется. К наиболее распространенным рискам миграции данных
и причинам их возникновения можно отнести: ‒ Недостаточные компетенции / опыт команды проекта в миграции данных
(в том числе, в части формирования документации об уже осуществленных
проектах).
‒
Отсутствие единого ответственного за данные, что сказывается на невозможности
определить более корректные и актуальные данные.
‒ Низкое качество переносимых данных
(дублирование, некорректные форматы данных).
‒ Нестабильность целевой системы для
переноса данных.
В
случае, если разработка еще не завершена и миграция данных выполнена
преждевременно, могут возникнуть ошибки / потеря информации.
‒
Несвоевременность организации синхронизации данных. Актуализация данных должны
производиться в новой системе сразу после миграции.
‒ Низкая степень документированности
процесса миграция.
Данный
риск относится не только к невозможности использовать полученный опыт для
выполнения дальнейших проектов. В большей степени связан этот риск связан с
невозможностью в случае возникновения необходимости продемонстрировать
аудиторам/ компетентным контролирующим органам отчеты по датам и масштабам
перемещения данных. А значит, потенциально может возникнуть огромное количество
проблем, связанных с доказательством достоверности предоставленной отчетности.
Особенно это актуально, если данные для отчетности выгружались в период
параллельной работы старой и новой систем, при наличии различий в объемах
данных, хранившихся в них в конкретный момент. Таким образом, миграция данных – длительная, кропотливая, требующая
большого внимания работа, связанная с высоким риском потери данных. В девяти из
десяти случаев основной сложностью, с которыми сталкиваются команды проекта при
миграции является возникновение дублирования данных. Среди основных причин
появления подобных данных-«двойников»:
1.
Различия в написании объектов: ПРИМЕР ‒ Организационно-правовые формы
/ формы собственности («ЗАО» Вымпел, оао «Вымпел»,
ВЫМПЕЛ). Это приводит к путанице: идет ли речь о разных предприятиях либо об
одной и той же компании? ‒ Использование латиницы и сокращений: Ivanov Ivan, Иванов И.
2.
Несовпадение информации из-за устаревания данных. ПРИМЕР В одной системе в качестве адреса ООО
«Вымпел» указывается г.Воронеж, а в другой – г. Москва. Разница может быть
обусловлена переездом компании либо же разной трактовкой понятия «адрес»
сотрудниками, вводившими информацию в систему: в первом случае – юридический
адрес компании, во втором – фактический.
3. Несовпадение
форматов данных ПРИМЕР ‒
Неиспользование выпадающих списков для полей с ограниченным числом значений: г.
Балашиха в одной системе и «Московская область» в
другой. ‒ Использование текстовых полей для написания цифр (например, в
случае миграции Excel-таблиц): 84951234567 добав
1111. ‒ Стиль написания цифр: +7 (495) 123-45-67, 84951234567. Во всех этих случаях необходима тщательная
выверка всех данных, проводящаяся частично в автоматизированном режиме
(например, для замены «+7» в телефонных номерах на «8», удалении лишних
пробелов / символов), частично в ручном режиме пользователями.
5. Разработка
контрольного примера
Контрольный пример
предназначен для проверки корректности работы алгоритма, правильности
заполнения и реакции форм на ввод определенных форматов данных, корректности
обработки исключений. В конечном итоге (в идеальном случае) результаты
реализации контрольного примера должны целиком совпадать с ожидаемым
результатом. В противном случае все полученные расхождения (в случае их
наличия) должны быть объяснимы (например, большей точностью вычислений новой
системы).
Контрольный пример составляется по каждому функциональному модулю и
используется для выявления и устранения недостатков / замечаний силами сначала
проектной команды, а затем – с привлечением ключевых пользователей. Затем этот
же пример может использоваться в процессе обучения рядовых пользователей. Подготовка контрольного примера должна
проводиться очень тщательно, по разработанному плану тестирования (регламент и
сценарий тестирования, о котором уже говорилось при описании инсталляции
системы, а также с обязательным наличием начальных данных для примера).
Контрольный пример должен следовать определенной логике, покрывать ситуации
типичного использования приложения и наиболее важные для пользователя аспекты
работы с системой, проверять распределение функций по модулям, быть удобным и
понятным для тестирования. Должна проверяться также реализация изначально
собранных требований пользователей. Среди других характеристик тестового сценария:
‒
Проверка наиболее «слабых» мест системы для повышения вероятности обнаружения
ошибок.
‒
Выполнение необходимого минимума действий для проверки (неизбыточность).
‒
Явно выявляет ошибки / недоработки.
‒ Понятность и логичность описания
примера для пользователей.
Тестовые
сценарии также могут относиться к конкретной проверяемой области: конфигурации
системы, юзабилити / удобство использования,
безопасности, взаимодействия / интеграции компонентов. Однако может создаваться
и общий пример, с единым описанием и дальнейшей детализацией в зависимости от
специфики проверяемой области / задач тестирования. Ко времени старта тестовой
эксплуатации таким образом должны быть подготовлены такие элементы модели тестирования, как:
‒ Набор исходных данных / условий
тестирования / планируемых результатов.
‒
Методика испытаний: технический документ, описывающий настройку системы для
проведения теста и принцип оценки итоговых результатов.
‒ Контрольный пример / сценарий
тестирования.
‒ Тестовый скрипт
(опционально: в случае использования автоматизированных инструментов
тестирования). Формальным основанием для старта тестовой эксплуатации могут
служить:
‒
Протокол совещания группы внедрения о передаче модуля системы в тестовую
эксплуатацию.
‒
Регламент тестирования контрольного примера.
‒
Перечень замечаний ключевых пользователей, собранных при предварительном
тестировании контрольного примера (по каждому модулю системы), с описанием
решений по их устранению, отраженный в Протоколе совещания группы
внедрения.
.6. Тестовая
эксплуатация
Между первоначальной настройкой системы на
стенде по сформированным и утвержденным требованиям и ее полномасштабным вводом
в эксплуатацию требуется один из самых сложных с точки зрения согласования
интересов всех сторон этап тестовой эксплуатации. Как правило, прием системы в
эксплуатацию и обучение пользователей проводятся исключительно после
подтверждения своего согласия с «итоговой версией». Разумеется, для проведения
опытной эксплуатации составляется отдельный регламент / методика – и затем, все
замечания, получаемые в ходе работы с системой среди выбранной группы ключевых
пользователей, заносятся в отдельный журнал запросов на изменение с
расстановкой приоритетов исполнения. Среди
наиболее больших блоков / классов
проводимых тестов можно выделить следующие:
‒
Компонентное / модульное тестирование (component / unit testing). Его основная цель
состоит в идентификации ошибок реализации модулей в ходе проверки
работоспособности (например, при различных поступающих на вход данных).
Проверяются отдельные объекты, функции, классы, модули.
‒ Интеграционное тестирование. Данный
тип тестирования проводится для всей системы в целом. Его основная задача –
проверка корректности передачи информации и взаимодействия между всеми модулями
/ компонентами системы и слоями архитектуры (в частности, прикладным
программным обеспечением, инфраструктурными сервисами / операционной системой).
Особенно данный тип тестирования актуален для клиент-серверных / распределенных
систем.
‒
Системное тестирование (в т.ч. функциональное тестирование). Определение
степени соответствия созданной ИС исходным требованиям (функциональным и
нефункциональным). Проводится проверка корректности настройки внешних
интерфейсов системы. Оцениваются различные характеристики надежности,
производительности, отказоустойчивости системы, в дальнейшем также проверяемые
в ходе нагрузочного тестирования.
В качестве дополнительных проверок могут
создаваться тестовые окружения для ИС при эмуляции работы отдельных компонентов
систем / внешнего окружения / активностей пользователей. В частности, при
эмуляции возможно смоделировать работу того или иного компонента системы
(модуля, сервиса), которые еще не были созданы, для более раннего проведения
тестирования. Тестирование в зависимости
от специфики системы / предметной области может проводиться в ручном /
автоматизированном или полуавтоматизированном режиме.
‒ В
ручном режиме специалисты по тестированию самостоятельно проходят весь
контрольный пример / сценарий тестирования. Этот способ применяется для крайне
динамической разработки в условиях постоянных изменений. По результатам
составляется протокол тестирования, в который заносятся все замечания,
комментарии и предложения.
‒
Автоматизированное тестирование
значительно упрощает и ускоряет процесс тестирования, предоставляет возможность
провести большее число проверок, в том числе до и после внесения доработок в
тестовую среду.
‒
Полуавтоматизированное тестирование выполняется по заданному
сценарию под постоянным контролем тестировщика.
Таким образом создаются
преимущества автоматизированного тестирования, но с возможностью в случае
необходимости изменить сценарий его выполнения и организовать дополнительные
проверки /
проверки при новых условиях. Тестирование,
как наиболее важный элемент обеспечения / контроля качества может и должно быть
организовано по специальной методике / в соответствии со стандартами. Среди
наиболее часто применяющихся стандартов:
‒ ГОСТ 12119 ИТ. Пакеты программ.
Требования к качеству и тестирование
.
‒ ГОСТ 12207 ИТ. Процессы жизненного цикла программных средств.
‒
ГОСТ 14764 ИТ. Сопровождение программных средств.
‒
ГОСТ 15288 ИТ. Системная инженерия. Процессы жизненного цикла систем.
‒ ГОСТ 15504 ИТ. Оценка процессов.
‒
ГОСТ 28195 ИТ. Оценка качества программных средств. Общие положения.
‒
ГОСТ 9126 ИТ. Оценка программной продукции. Характеристики качества и
руководства по их применению.
‒ ГОСТ серии 19 Единая система
программной документации (ЕСПД).
‒ ГОСТ серии 34 Разработка
автоматизированной системы управления.
‒
IEEE 829 Стандарт документирования тестирования программного обеспечения и
систем.
Отдельно можно отметить унифицированный
процесс RUP, который по своей сути исходит из идеи постоянного регулярного
тестирования на каждой итерации. Срок
тестовой эксплуатации, как правило, не превышает одного месяца и не меняется
при отсутствии или несвоевременном предоставлении замечаний.
Среди выполняемых для
организации тестовой эксплуатации мероприятий (все они проводятся по каждому
функциональному модулю в отдельности):
‒
Подготовка перечня замечаний ключевых пользователей, собранных в процессе
окончательного тестирования контрольного примера (по каждому модулю системы), с
описанием решений по их устранению, отраженный в Протоколе совещания Группы
внедрения.
‒
Предварительное тестирование командой внедрения контрольного примера (по
отдельным модулям!) с занесением замечаний в журнал тестирования и последующим
их устранением (в случае необходимости с дополнительными настройками /
доработками).
‒
Финальное тестирование с привлечением ключевых пользователей (здесь помимо
функциональности крайне важно также проверить степень удобства и интуитивности
интерфейса системы для пользователей).
‒
Разработка общего руководства по работе с системой и инструкций пользователей
по модулям системы (включая назначение и условия работы с модулем, описание
операций по подготовке и самой работе).
‒
Обучение пользователей базовым принципам работы с системой на контрольном
примере (в отдельности для каждого модуля системы). В процессе обучения
пользователь знакомится с интерфейсом системы, получает информацию по основным
принципам работы и основным возможностям системы. В случае наличия
разработанных методических руководств пользователю дополнительно
предоставляется необходимая документация. Подробнее обучение пользователей
рассматривается в соответствующем разделе пособия.
.7. Доработка по
результатам тестирования
Основная цель данной
активности – устранить замечания, возникшие в результате тестирования на
контрольном примере и, при необходимости, осуществить дополнительные настройки
и доработки модулей системы. Как уже было сказано, на данном этапе также важно
разделять критичные для успешной работы с системой и дополнительные, nice-to-have требования пользователей-экспертов, которые
можно будет включить в следующие итерации работы и версии системы. Что касается
порядка
организации данных типов проверки, то для первых сборок проводится
поверхностное smoke-тестирование, направленное на критическую функциональность.
В данном случае организуется короткий цикл тестов для подтверждения того, что
после сборки кода (вне зависимости, нового или исправленного) приложение будет
успешно выполнять свои основные функции. Код проверяется на предмет наличия быстронаходимых критических дефектов, которые необходимо
срочно исправить, отправив на доработку. В случае их отсутствия и успешного
прохождения тестирования и приложение передается для проведения полного цикла
тестирования. Так как при smoke-тестировании в максимально короткие сроки
покрывается максимально широкий объем функциональных возможностей, то
существует и другой вид тестов, дополняющих первый (функции проверяются скорее
«вглубь», максимально тщательно тестируя каждый аспект).
Это обусловлено тем,
что при проведении любого рода изменений необходимо обеспечивать их
корректность и отсутствие негативного влияния на работоспособность и
эффективность приложения. С этой целью проводится регрессионное тестирование (regression testing), один из наиболее известных видов
которого получил название sanityтестирования. Это тестирование определенных участков
кода, проводимое по результатам внесенных изменений. Его основная задача –
удостовериться в том, что внесенные изменения не затронули работоспособность
системы и не послужили причиной новых ошибок. К примеру, проверяется,
действительно ли исправленные ранее ошибки исправлены, не приводят ли сделанные
изменения к нейтрализации исправлений старых ошибок (регрессия багов, bug regression)
и есть ли новые ошибки
. В результате должны быть:
‒
Проведены тестирование, выявление и устранение замечаний по контрольным
примерам на каждый модуль системы (замечания обработаны и, либо сделаны
соответствующие изменения в модуле, либо они отклонены с указанием причин).
‒
Проведены дополнительные настройки и доработки модуля системы (в срок до 4
недель с момента передачи модуля системы в тестовую эксплуатацию и получения
перечня окончательных доработок и настроек модуля системы).
‒
Составлен протокол выполненных работ по устранению задокументированных
замечаний ключевых пользователей Заказчика по результатам тестирования
контрольного примера по каждому модулю системы.
‒ Ключевые пользователи обучены базовым
основам работы с модулем системы на данных контрольного примера и готовы к его
практической эксплуатации на своих рабочих местах, а также развертыванию на
основном рабочем сервере и проведению опытно-промышленной эксплуатации (ОПЭ).
‒
Сформирован протокол выполненных работ по обучению ключевых пользователей
Заказчика базовым основам работы с модулем системы на данных контрольного
примера.
‒
Подготовлен перечень окончательных доработок и настроек каждого модуля системы.
.8. Прием результатов
испытаний
Результаты тестовых
испытаний заносятся в единый отчет для рассмотрения заказчиком. При этом
организуется приемочное тестирование (acceptance testing), представляющее собой комплексную проверку
компонентов системы на предмет их работы с плановыми параметрами производительности
/ быстродействия и выполнением всех функциональных требований, в том числе на
различных конфигурациях. Прием результатов испытаний проводится при выполнении
следующих условий:
‒ Специалисты группы внедрения со
стороны заказчика владеют функциональностью модуля системы и готовы к его
развертыванию на рабочем сервере и опытно-промышленной эксплуатации.
‒
Все замечания, возникшие в ходе первоначального тестирования контрольных
примеров, задокументированы и устранены.
‒
Ключевые пользователи готовы к работе с модулем на своих рабочих местах.
‒ Все замечания ключевых пользователей,
собранные во время окончательного тестирования контрольного примера, обработаны
и, либо сделаны соответствующие изменения в модуле, либо замечания отклонены с
указанием причин отклонения.
‒ Заказчиком утверждены итоговые
документы.