56
Требование
Важность
(1-3)
3. Система продуктивной эксплуатации SAP BI
3.1. Требования к подсистеме АС МиАЭ
Сервер приложений, совмещенный с сервером баз данных (1 шт.)
3
Число процессоров (ядер) – не менее 4.
3
Объем оперативной памяти сервера приложений – не менее 8 Гбайт.
3
Дисковая память для хранения данных – не менее 293 Гбайт
Желательно использование внешнего дискового массива.
3
3.2.Требования для всех подсистем КИСУ, в т.ч. и для подсистемы АС МиАЭ
Два сетевых адаптера с пропускной способностью не менее 1 Гбит/сек
3
Периферийное оборудование – DVD-ROM.
3
ИБП, обеспечивающий время работы 15 минут.
3
3. Система разработки
Требования к подсистеме АС МиАЭ
Число процессоров (ядер) – не менее 1.
1
Дисковая память для хранения данных – не менее 100 Гбайт
Желательно использование внешнего дискового массива.
3
4. Система продуктивной эксплуатации
Требования к подсистеме АС МиАЭ
Число процессоров (ядер) – не менее 1.
1
Дисковая память для хранения данных – не менее 100 Гбайт
Желательно использование внешнего дискового массива.
3
Обоснование итоговых требований к системе разработки SAP BI; к
системе проверки качества SAP BI; к системе продуктивной эксплуатации
SAP BI; к системе разработки хранилища данных; к продуктивной системе
приведены в Приложении 3.
57
II Проектная часть
2. Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта создания информационной системы
мониторинга и анализа энергоэффективности начинается в момент
принятия решения о его создании и заканчивается в момент выведения его
из эксплуатации.
Существуют международные стандарты, регламентирующие
жизненный цикл информационных систем, в частности — ISO/IEC 12207 и
ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».
Российский стандарт ГОСТ 34.601-90 на создание и развитие
автоматизированных систем (АС) — универсальный, обобщенный, но
весьма строгий по структуре жизненного цикла и проектной
документации. Этот стандарт считаются консервативным, поэтому в
проекте создания АС МиАЭ применен более современный стандарт
ISO/IEC 12207:1995 [1].
Международный стандарт ISO/IEC 12207:1995 «Information
Technology — Software Life Cycle Processes» является основным
нормативным документом, регламентирующим состав процессов
жизненного цикла программного обеспечения. Он описывает структуру
жизненного цикла проекта, содержащую процессы, действия и задачи,
которые должны быть выполнены во время разработки, настройки и
конфигурации автоматизированной системы.
Каждый реализуемый процесс разбит на наборы действий, каждое
действие — на набор задач. Каждый процесс, действие или задача
инициируется другим процессом по мере необходимости. Связи по
входным данным при этом сохраняются [19].
Применительно к АС МиАЭ схема жизненного цикла проекта
выглядит следующим образом (рис. 2.1).
58
Рис.2.1 Общая схема жизненного цикла АС МиАЭ
Итак, разработка автоматизированной системы состоит из
следующих этапов:
1. Анализ и подготовка проекта
Прежде, чем были начаты работы по созданию АС МиАЭ, была
собрана полная первичная информация о существующих методах
автоматизации процесса сбора, обработки и консолидации данных по
направлению энергоэффективности предприятия, изучены нормативные и
регламентирующие документы, в том числе внутренние приказы
предприятия, а также Постановления Правительства Российской
Федерации, проработаны регламентные формы отчетности. На основании
перечисленных документов и интервью с представителями заказчика были
составлены модели бизнес процессов в виде «Как есть» и составлено
общее понимание деталей и характеристик автоматизируемых процессов.
На данном этапе ставятся действительно важные задачи, решение
которых впоследствии позволит качественно и с минимальными рисками
реализовать конечные цели создания системы. Составляется
функциональное задание, в котором отразятся аспекты проекта [20]:
- Цели создания АС МиАЭ – основываясь на предварительном
задании, анализ ставящейся перед системой целей и прогноз их
достижимости.
- Анализ уже существующих систем мониторинга
энергоэффективности на рынке, их сильные и слабые стороны,
составление рекомендаций к общим принципам построения системы для
достижения наилучших результатов.
- Конечные пользователи системы – анализ и описание
функциональных обязанностей пользователей, в ходе чего будет получено
понимание путей оптимизации и разделения полномочий в системе.
Анализ и подготока
проекта
Разработка
технического
задания
Концептуальное
проектирование
Реализация
проекта
Обучение
пользователей и
ОП
59
- Методологическое обоснование создания системы
энергоэффективности – выдаются требования в соответствии с
нормативными и регламентными документами, которые должны
учитываться при создании системы.
- Пути и средства создания системы – исходя из существующего
системного и технического ландшафта компании, выбирается
программный продукт, который будет взят за основу при создании,
настройки и конфигурации системы.
2. Разработка технического задания
На основании функционального задания, описания процессов «как
есть» (as is), а так же проведенных интервью с представителями заказчика
разрабатывается техническое задание на создание системы мониторинга и
анализа энергоэффективности, в котором сочетаются программные,
интерфейсные и пользовательские требования.
Определяются критерии достижения целей создания
автоматизированной системы для общего представления о конечных
функциональных требованиях по работе системы.
Организационный объем проекта – определение всех
департаментов, филиалов и подразделений компании, которые будут
вовлечены в работу системы при переводе в опытно-промышленную
эксплуатацию.
Функциональный объем проекта – перечень автоматизируемых
бизнес-процессов создаваемой системы и общие типы используемых
данных и их характеристики.
Требования к составу и структуре АС МиАЭ – описание
расширения функциональных возможностей существующей КИСУ, в том
числе интеграционных механизмов, обеспечивающих взаимодействие АС
МиАЭ и существующих подсистем. Логическая архитектура создаваемой
системы, с разбивкой на подсистемы с описанием требований и
функциональных особенностей.
60
Требования к технической инфраструктуре – описание
характеристик технической инфраструктуры необходимой для
обеспечения бизнес-процессов вычислительными ресурсами,
включающими в себя сетевое оборудование, серверное оборудование,
оборудование систем хранения данных, а также системное программное
обеспечение. Требования по обеспечению необходимого и достаточного
уровня быстродействия и надежности функционирования системы, в том
числе и предотвращение и/или снижение возможного ущерба от простоя в
целях обеспечения стабильности основных бизнес-процессов,
поддерживаемых системой.
Требования к составу отчетных форм – перечисление и описание
выходных результатов работы системы и требования по их формированию.
Перечень результатов выполненных Работ, подлежащих приёмке
Заказчиком – полный список результатов работ в части созданной
функциональности, обучения пользователей системы и документации.
Техническое задание разрабатывается архитектором системы
совместно с представителями от предприятия заказчика.
3. Концептуальное проектирование
На данном этапе производится создание документа, определяющего
общие требования к реализации проекта. Документ содержит описание
целевых бизнес-процессов мониторинга, выполняемых в
автоматизированной системе мониторинга и анализа энергоэффективности
(АС МиАЭ), построенной на базе ПО SAP – КИСУ. Данный документ
разрабатывается с учетом результатов анализа текущего состояния бизнес-
процессов в части мониторинга и анализа энергоэффективности.
Концептуальный проект содержит детализированные с технической
и организационной точек зрения объемы выполнения проекта. В
концептуальном проектировании участвует архитектор системы.
61
4. Реализация проекта
На этапе разработки проектных решений, описываются и детально
прорабатываются конкретные справочники, таблицы, инфо-кубы,
механизмы агрегации и консолидации данных, входные и отчетные
формы, по каждому автоматизируемому бизнес-процессу. Создаются и
согласовываются макеты экранных форм, форм консолидированной и
печатной отчетности в соответствии требованиями технического задания и
регламентными документами. Описывается бизнес-процесс с
наименованиями транзакций, указанием ролей и полномочий конечных
пользователей системы, этапов согласования внесения изменений в
справочники и в формы ввода.
Проектные решения создаются консультантами SAP при участии
архитектора системы и согласовываются с представителями заказчика.
На этом этапе создается схема данных, создаются информационные
кубы, признаки и показатели, разрабатываются функциональные модули,
экранные формы и формы отчетности, механизмы интеграции с другими
системами детализированные и описанные в проектных решениях. Также в
рамках этапа система наполняется данными посредством загрузки
справочных данных из предоставленных заказчиком файлов и других
подсистем и их сверкой и согласованием с представителями организации.
Создаются пользователи и присваиваются необходимые полномочия для
возможности осуществления действий в системе.
В настройке и программировании систем на базе продуктов SAP
участвуют консультанты SAP и программисты.
5. Обучение пользователей и опытно-промышленная эксплуатация
Для начала работы системы проводится обучение конечных
пользователей системы с подписанием отчетов о прохождении обучения и
проводится интеграционное тестирование с выявлением недочетов и
ошибок в работе системы, по результатам этапа производится доработка и
перевод системы в опытно-промышленную эксплуатацию.
62
В рамках Проекта предусмотрены следующие виды испытаний:
- предварительные испытания АС МиАЭ;
- приемочные испытания АС МиАЭ Заказчиком;
- опытно-промышленная эксплуатация АС МиАЭ Заказчиком.
Предварительные испытания – это вид испытаний новой
функциональности КИСУ на базе ПО SAP BI 7.0, который проводится
силами компании – разработчика на оборудовании Заказчика.
В ходе предварительных испытаний проводятся следующие виды
тестирования:
- функциональное тестирование АС МиАЭ;
- тестирование дополнительных программных разработок для
функциональности АС МиАЭ с учетом спецификаций;
- тестирование интерфейсов со смежными подсистемами КИСУ;
- тестирование ролей и полномочий.
Данный вид испытаний считается завершенным после выполнения
всех видов тестирования и устранения критических замечаний.
Приемочные испытания – это вид испытаний новой
функциональности КИСУ на базе ПО SAP BI 7.0, который проводится
приемочной комиссией Заказчика на оборудовании тестовой системы.
Приемочная комиссия формируется Экспертной группой и
Центральной рабочей группой Проекта из состава сотрудников следующих
структурных подразделений и предприятий (организационный объем
приемочных испытаний):
Дирекция модернизации и энергоэффективности;
Департамент взаимодействия с клиентами и рынком;
Департамент производственного контроля;
МЭС Центра.
Данный вид испытаний считается завершенным после выполнения
всех видов тестирования и устранения критических замечаний,
включенных в журнал учета и устранения замечаний.
63
Критическими замечаниями являются ошибки в работе АС МиАЭ,
которые не позволяют выполнить бизнес-процесс, бизнес-функцию, либо
фактические результаты выполнения не совпадают с ожидаемыми,
существует ошибка в алгоритмах расчета и т.п.
Некритическими замечаниями являются незначимые для
выполнения бизнес-процесса ошибки в работе АС МиАЭ, например,
точность округления результатов, шрифт вывода информации на экран или
в выходную форму, оформление форм ввода и вывода данных,
расположение отдельных элементов экрана или пользовательского меню,
настройки локальных рабочих мест пользователей (принтера, сетевых
устройств и т.п.).
По завершении приемочных испытаний результаты их проведения
оформляются Протоколом приемочных испытаний о готовности системы к
опытно-промышленной эксплуатации.
Общая концепция порядка проведения испытаний приведена на
рис. 2.2.
64
Порядок проведения испытаний АС МиАЭ КИСУ ОАО «ФСК ЕЭС» на базе ПО SAP BI 7.0
ЗаказчикИсполнитель
SAP BI 7.0
Предварительные
испытания
Приемочные
испытания (ПИ)
Опытно-
промышленная
эксплуатация
(ОПЭ)
- Программа и методика испытаний
- Техническое задание
- Концептуальный проект
- Проектные решения
- Спецификации на разработку
- Протокол
предварительных
испытаний
- Реестр выявленных
замечаний
- Перенос настроек и разработок в
тестовую систему выполнен.
- Тестовые данные загружены
- Система готова к приемочным
испытаниям
- Программа и методика испытаний
- Техническое задание
- Сценарии тестирования
Существуют
замечания
критичные для ОПЭ?
- Протокол приемочных
испытаний
- Реестр выявленных
замечаний
Устранение
замечаний
Да
Система готова к ОПЭ.
Протокол ЦРГ о переводе
в ОПЭ - подписан
Нет
Протокол устранения
замечаний
ОРД о начале ОПЭ
Устранение замечаний в
рамках поддержки
пользователей на период ОПЭ
- Реестр выявленных
замечаний
- Протокол устранения
замечаний
Рис. 2.2 Общая концепция порядка проведения испытаний
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Риск проекта – это неопределенное событие или условие, которое в
случае возникновения имеет позитивное или негативное воздействие по
меньшей мере на одну из целей проекта, например сроки, стоимость,
содержание или качество.
Порядок проведения испытаний
65
Рассмотрим основные категории рисков, которые возникают на
этапах жизненного цикла проекта.
На этапе анализа и подготовки проекта основные риски возникают
в связи с определением приоритета проекта, которое определяет компания.
На первый план выходит возможность конфликта интересов
подразделения по информационным технологиям и руководством или
собственниками компании, которое может получить выражение в
выделении недостаточности ресурсов, что приведет к срыву сроков или
снижению качества системы.
Также на этапе предварительного анализа большую роль играет
качество обследования, его недостаточная глубина или ошибки в процессе
могут привести к неверной постановке требований или неверном
моделировании ситуации «как есть», что в итоге приведет к неверной
постановке задачи [18].
На этапе разработки технического задания наряду с
вышеописанными рисками возникают риски нехватки компетенций у
созданной структуры для управления проектом. Также возникают риски,
связанные с неверной оценкой сроков реализации и объемов проекта.
На этапе концептуального проектирования к проекту, как правило,
присоединяются подрядчики и контрагенты, что всегда сопряжено с
рисками, связанными с их функционированием: начиная от риска
невыполнения обязательств и повышения тарифов на работы, заканчивая
возможностью банкротства, что также может отразиться на качестве и
сроках реализации проекта [15].
На этапе реализации проекта возникают риски, связанные с
мотивацией команды (например, управленческие ошибки). Кроме того,
всегда существуют программные риски ошибки проектирования и
настройки, а также реализации системы, что может привести к потере
данных, остановке системы.