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

 

Лекция 2

 

Тема лекции: «Фазы ЖЦ ИС  и специфика каждой из них»

1. Фазы и стадии жизненного цикла ИС.
2. Развертывание и внедрение ИС.
3. Эксплуатация и поддержка ИС. Модернизация и утилизация ИС.

1. ФАЗЫ И СТАДИИ ЖИЗНЕННОГО ЦИКЛА ИС.

 

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

 

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

 

Первая фаза  «1. ПЛАНИРОВАНИЕ ПРОЕКТА» включает в себя следующие стадии:

1.1. Экспресс-обследование.

1.2. Технико-экономическое обоснование.

1.3. Оценка целесообразности проекта (TELOS).

1.4. Выбор программного решения.  

Вторая фаза «2. АНАЛИЗ И ПОСТАНОВКА ЗАДАЧИ» включает в себя следующие стадии:   

 

2.1. Информационное обследование предприятия.

2.2. Описание бизнес-процессов.

2.3. Сбор требований.

2.4. Подготовка технического задания.

 

При этом стадия «2.2. Описание бизнес-процессов» включает в себя следующие основные этапы: выбор основных нотаций / методологий моделирования и  выбор программных продуктов моделирования деятельности организации.

 

Третья фаза «3. ПРОЕКТИРОВАНИЕ» включает в себя следующие стадии:

 

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

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

 

Четвертая фаза «4. РАЗРАБОТКА» включает в себя следующие стадии:  

 

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

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

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

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

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

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

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

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

Пятая фаза «5. РАЗВЕРТЫВАНИЕ И ВНЕДРЕНИЕ» включает в себя следующие стадии:

5.1. Закупка и настройка требуемой ИТ-инфраструктуры.

5.2. Ввод начальных остатков.

5.3. Обучение пользователей.

5.4. Развертывание системы на рабочих местах.

5.5. Основные виды тестирования.

5.6. Опытно-промышленная эксплуатация.

5.7. Приемо-сдаточные испытания.

 

Шестая фаза «6. ЭКСПЛУАТАЦИЯ».

 

Седьмая фаза «7. ПОДДЕРЖКА (Сопровождение эксплуатации)» включает в себя следующие стадии:

7.1. Авторский надзор.

7.2. Техническая поддержка.

7.3. Постгарантийное сопровождение.

На фазе «8. МОДЕРНИЗАЦИЯ» рассматриваются:  

8.1. Стратегии управления legacy-системами.

8.2. Виртуализация как стратегия модернизации решений.

8.3. Особенности проектов по модернизации.

Девятая фаза «9. УТИЛИЗАЦИЯ» включает в себя:

9.1. Технические аспекты.

9.2. Организационные аспекты.

9.3. Коммерческие аспекты.

9.4. Юридические вопросы.

 

2. РАЗВЕРТЫВАНИЕ И ВНЕДРЕНИЕ ИС.

 

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

 

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

 

Это следующие операции.

 

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

 

‒ Настройка рабочего сервера.

 

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

 

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

 

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

 

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

 

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

 

Среди основных работ фазы развертывания и внедрения следующие:

 

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

 

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

 

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

 

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

 

‒ Осуществить интеграцию модуля с другими модулями или внешними системами, внедренными ранее.

 

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

 

-наименование модуля системы, проходящего опытно-промышленную эксплуатацию;

 

- наименование компании-исполнителя;

 

- сроки проведения опытно-промышленной эксплуатации;

 

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

 

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

 

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

 

К моменту ОПЭ (опытно-промышленной эксплуатации) уже должны быть проведены следующие работы:

 

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

 

‒ Подготовлены, дополнены и введены недостающие справочники по каждому модулю системы, проведена выверка введенных в систему недостающих справочников.

 

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

 

2.1. Закупка и настройка требуемой ИТ-инфраструктуры.

 

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

 

Поэтому к техническому обеспечению ИТ-систем компании должны предъявляться жесткие требования по следующим характеристикам.

 

 

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

 

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

 

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

 

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

 

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

 

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

 

ПРИМЕР.

 

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

 

Масштабируемость этих инсталляций обеспечивается следующим образом:

 

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

 

‒ Инсталляция базы данных масштабируется по вертикали путем адаптации необходимых аппаратных ресурсов (увеличения мощности процессора, расширение памяти и так далее).

 

К ИТ-инфраструктуре в таком случае можно отнести следующие компоненты:

вычислительную инфраструктуру, сетевую инфраструктуру и инженерную инфраструктуру.

 

ВЫЧИСЛИТЕЛЬНАЯ ИНФРАСТРУКТУРА включает в себя следующие категории:  

 

1)   Базовые инфраструктурные сервисы.

 

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

 

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

 

2)   Серверное и пользовательское оборудование и системы хранения данных (СХД).

 

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

 

3)   Серверные площадки и центры обработки данных (ЦОД).

 

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

 

4)   Системное ПО.

 

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

 

Сетевая инфраструктура включает в себя следующие категории:

 

1)   Инфраструктура локальных вычислительных сетей (ЛВС).

 

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

 

2)   Корпоративные сети передачи данных (КСПД).

 

3)   Телефония, ВКС, подключение к сети Интернет.

 

ИНЖЕНЕРНАЯ ИНФРАСТРУКТУРА включает в себя следующие компоненты: устройства бесперебойного питания, электропитания, охлаждения, кабельную инфраструктуру.

 

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

 

Среди непосредственных активностей этапа построения ИТ-инфраструктуры для ИС отметим следующие:

 

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

 

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

 

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

 

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

 

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

 

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

 

2.2. Ввод начальных остатков.

 

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

 

2.3. Обучение пользователей.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Шаг 2. Обучение рядовых пользователей.

 

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

 

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

 

Шаг 3. Повышение квалификации / переобучение.

 

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

 

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

 

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

 

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

 

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

 

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

 

2.4. Развертывание системы на рабочих местах.

 

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

 

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

 

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

 

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

 

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

 

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

 

‒ Выделение основных блоков функциональности, их запусков, взаимозависимостей.

 

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

 

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

 

‒ Информация по исполнителям работ (зонам ответственности).

 

При переходе в «продуктив»  должны быть осуществлены такие активности, как:

 

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

 

‒ Описание мероприятий по переходу в продуктивную систему.

 

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

 

‒ Описание порядка действий в случае возникновения ошибок / сбоев / нарушения работы системы.

 

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

 

‒ установка / подключение технических средств;

 

‒ установка / конфигурация ПО;

 

‒ развертывание баз данных, служебных программ;

 

‒ доработка интерфейса / процессов / кастомизация профилей пользователей / настройка отчетов;

 

‒ установка прав доступа;

 

‒ пуско-наладочные работы и окончательная отладка конфигурации.

 

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

 

2.5. Основные виды тестирования.

 

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

 

НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ необходимо для предсказания поведения системы в реальных и экстремальных условиях, выявления ошибок, отслеживать производительность и доступность при изменении различных параметров работы с системой. Среди его других задач:

 

‒ Оценка производительности и работоспособности приложения на этапах:

 

- Разработки.

 

- Опытно-промышленной эксплуатации.

 

- Сопровождения и эксплуатации (выпуск новых релизов, патчей).

 

‒ Оптимизация приложений.

 

‒ Подбор оптимальной программно-аппаратной платформы и конфигурации сервера.

 

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

 

‒ ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ (load testing).

 

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

 

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

 

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

 

- Определение максимально достижимой производительности системы.

 

Следующий вид тестирования

 

‒ СТРЕССОВОЕ ТЕСТИРОВАНИЕ (stress testing).

 

Этот вид тестирования проводится для определения стабильности системы при интенсивности работы, превышающей плановые / стандартные значения.

 

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

 

Среди основных активностей стресс-тестирования следующие:

 

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

 

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

 

Следующий вид тестирования

 

‒ ТЕСТИРОВАНИЕ НАДЕЖНОСТИ (reliability testing).

При тестировании надежности ИС происходит:

 

- Определение длительности бесперебойной и безошибочной работы системы.

 

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

 

Следующий вид тестирования

 

‒ КОНФИГУРАЦИОННОЕ ТЕСТИРОВАНИЕ (configuration testing).

 

Конфигурационное тестирование включает:

 

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

 

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

 

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

 

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

 

С точки зрения последовательности действий для проведения данного вида тестирования:

 

1. Создается матрица покрытия с описанием всех возможных конфигураций системы.

 

2. Приоритезация конфигураций.

 

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

 

‒ ОБЪЕМНОЕ ТЕСТИРОВАНИЕ (volume testing).

 

- Тестирование программного обеспечения системы на предмет стабильности обработки определенного объема данных.

 

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

 

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

 

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

 

2.6. Опытно-промышленная эксплуатация.

 

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

 

При этом важные задачи ОПЭ следующие:

 

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

 

‒ проведение множественных расчетов по фактической производственной информации с применением соответствующих программно-аппаратных средств, предусмотренных техническим проектом (проектным решением);

 

‒ достижение наиболее полного охвата бизнес-процессов автоматизируемых подразделений предприятия.

 

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

 

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

 

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

 

3)   Интеграцию внедряемого модуля с уже существующими модулями и / или внешними системами, которые были внедрены ранее.

 

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

 

ПРИМЕР.

 

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

 

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

 

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

 

ПРИМЕР.

 

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

 

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

 

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

 

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

 

ПРИМЕР.

 

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

 

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

 

2.7. Приемо-сдаточные испытания.

 

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

 

Цели ИНТЕГРАЦИОННОГО ТЕСТИРОВАНИЯ следующие:

 

‒ проверка корректности функционирования бизнес-процессов и функций;

 

‒ уточнение настроек бизнес-процессов в системе;

 

‒ уточнение и доработка настроек пользовательского интерфейса;

 

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

 

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

 

‒ проверка работоспособности интерфейсов с внешними системами;

 

‒ проверка корректности проектной и эксплуатационной документации;

 

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

 

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

 

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

 

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

 

‒ Протокол об окончании ОПЭ и готовности к промышленной эксплуатации совместно с Актом приемки-передачи работ.

 

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

 

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

 

3. ЭКСПЛУАТАЦИЯ И ПОДДЕРЖКА ИС. МОДЕРНИЗАЦИЯ И УТИЛИЗАЦИЯ ИС.

 

3.1.               Эксплуатация.

 

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

 

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

 

‒ Устранение замечаний, не затрагивающее изменение ТЗ.

 

‒ Обновления (по сути – новые версии системы), выпускаемые при накоплении критического объема доработок.

 

‒ Увеличение производительности системы.

 

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

 

3.2.               Поддержка (сопровождение эксплуатации).

 

Данная фаза включает в себя следующие стадии: АВТОРСКИЙ НАДЗОР, ТЕХНИЧЕСКУЮ ПОДДЕРЖКУ, ПОСТГАРАНТИЙНОЕ СОПРОВОЖДЕНИЕ.

 

АВТОРСКИЙ НАДЗОР.

 

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

 

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

 

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

 

Однако далее на базе классификации эксплуатационных характеристик программного обеспечения они могут дополняться и другими параметрами:

 

‒ АНАЛИЗИРУЕМОСТЬ: оценка не предусмотренных изначально усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы.

 

‒ ИЗМЕНЯЕМОСТЬ: оценка усилий, необходимых для проведения заданных модификаций.

 

‒ СТАБИЛЬНОСТЬ: оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования.

 

‒ ТЕСТИРУЕМОСТЬ: оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.

 

ТЕХНИЧЕСКАЯ ПОДДЕРЖКА.

 

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

 

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

 

‒ Консультирование по «горячей линии» (телефон, e-mail, skype) по определенному в договоре графику.

 

‒ Консультирование по вопросам программно-аппаратной платформы системы.

 

‒ Создание новых учетных записей пользователей системы.

 

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

 

‒ Диагностика и устранение неисправностей (с учетом гарантии на сами программные решения).

 

‒ Уведомление о выпуске обновлений и их загрузка через Интернет.

 

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

 

‒ Миграция данных и настройка интеграции с новыми системами предприятия заказчика.

 

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

 

ПОСТГАРАНТИЙНОЕ СОПРОВОЖДЕНИЕ.

 

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

 

Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как «модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и / или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении».

 

Функционирование программного продукта,  таким образом,  поддерживается на протяжении всего периода его эксплуатации.

 

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

 

‒ Сопровождать модуль системы в ходе промышленной эксплуатации на участках.

 

‒ Формировать перечень замечаний ключевых пользователей.

 

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

 

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

 

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

 

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

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

 

Для рассмотрения работ по сопровождению системы будем использовать руководство SWEBOK в области знаний «Поддержка ПО» (Software maintenance) как содержащее достаточно полный набор материалов на эту тему.

 

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

 

‒ Передача (Transition).

 

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

 

‒ ПРИНЯТИЕ / ОТКЛОНЕНИЕ ЗАПРОСОВ НА МОДИФИКАЦИЮ (Modification Request Acceptance / Rejection).

 

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

 

‒ Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk).

 

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

 

‒ Анализ влияния (Impact Analysis).

 

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

 

‒ Поддержка программного обеспечения (Software Support).

 

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

 

‒ Контракты и обязательства.

 

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

 

ОБНОВЛЕНИЕ И РЕЛИЗЫ.

 

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

 

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

 

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

 

1. Формирование заявок для специалистов, работающих в рамках сопровождения.

 

2. Планирование работ (выявление проблем / требований, объема и содержания задач).

 

3. Оказание услуг (согласование / уточнение требований, реализация работ, консультации, обучение, доработки)

 

4. Сдача / приемка работ.

 

Говоря о плановых обновлениях версий программного обеспечения вендорами, приведем пример компании 1С.

 

ПРИМЕР.

 

В 2012 году 1С выпустила новую конфигурацию «Бухгалтерия предприятия» (редакция 3.0) и в пресс-релизе были отмечены следующие внесенные изменения:

 

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

 

2. Развитие функциональности учета заработной платы. Начисление заработной платы, НДФЛ и страховых взносов стало проводиться одним документом автоматически при начислении заработной платы. Разделы «Зарплата» и «Кадры» объединены в один раздел, за счет чего все кадровые документы стали доступны на карточке сотрудника.

 

3. Развитие прав доступа. Добавлена функция доступа к информационной базе в режиме просмотра без прав на внесение изменений.

 

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

 

5. Повышение удобства работы при выполнении длительных операций. Возможность выполнения операций в фоновом режиме.

 

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

 

УВЕЛИЧЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ

 

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

 

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

 

‒ ВРЕМЯ ОТКЛИКА (время, необходимое серверу для получения ответа на произведенный запрос).

 

‒ ПРОПУСКНАЯ СПОСОБНОСТЬ (число запросов, которые могут быть обработаны за единицу времени).

 

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

 

‒ ИСПОЛЬЗОВАНИЕ РЕСУРСОВ (потребление приложением серверных / сетевых ресурсов (ЦП, память, дисковое пространство)).

 

‒ РАБОЧАЯ ЗАГРУЗКА (общее количество пользователей (либо только активных пользователей), объем данных и транзакций).

 

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

 

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

 

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

 

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

 

Отметим некоторые задачи инженерии производительности:

 

1)   Повышение окупаемости бизнеса через обеспечение своевременной обработки необходимых объемов транзакций.

 

2)   Своевременное выявление потенциальных проблем масштабирования / производительности и их устранение.

 

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

 

4)   Предотвращение задержек, вызванных проблемами с производительностью, при развертывании систем.

 

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

 

‒ Сетевое обеспечение (в том числе пропускная способность).

 

‒ Аппаратное обеспечение (характеристики серверов, рабочих станций).

 

‒ Зависимости ресурсов (число доступных соединений баз данных, веб-сервисов).

 

‒ Совместно используемые ресурсы (в т.ч. принципы распределения ресурсов между разными элементами системы).

 

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

 

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

 

ПРИМЕР.

 

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

 

«Для сценария использования A отклик системы на корректный запрос пользователя не должен превышать:

 

‒ 5 секунд для нагрузки в 250 активно использующих систему пользователей (200 онлайн пользователей в 95 % случаев);

 

‒ 10 секунд для пиковой нагрузки в 500 активных пользователей (400 онлайн пользователей в 90 % случаев)».

 

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

 

3.3.               Модернизация.

 

На фазе модернизации ИС рассматриваются следующие аспекты: СТРАТЕГИИ УПРАВЛЕНИЯ LEGACY-СИСТЕМАМИ, ВИРТУАЛИЗАЦИЯ КАК СТРАТЕГИЯ МОДЕРНИЗАЦИИ РЕШЕНИЙ, ОСОБЕННОСТИ ПРОЕКТОВ ПО МОДЕРНИЗАЦИИ.

 

СТРАТЕГИИ УПРАВЛЕНИЯ LEGACY-СИСТЕМАМИ.

 

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

 

Legacy systems (унаследованные системы) – системы, более не соответствующие текущим потребностям бизнеса, но по-прежнему эксплуатирующиеся компаниями.

 

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

 

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

 

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

 

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

 

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

 

‒ Изменения в системе документооборота, формате / структуре формируемых документов.

 

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

 

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

 

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

 

‒ Характеристики организации и внешней среды (выпуск новых изделий, появление новых технологических ограничений).

 

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

 

‒ Уход из компании и недостаток на рынке специалистов со знаниями, необходимыми для поддержки конкретной legacy-системы.

 

‒ Слишком высокая стоимость поддержки системы / совокупная стоимость владения.

 

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

 

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

 

‒ Осуществляемые процессы слияний и поглощений M&A (так, в случае объединения информационных систем с другой компанией требуется полный пересмотр существующего ландшафта систем и частичная / полная модернизация).

 

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

 

Чаще всего выделяются следующие варианты проведения модернизации:

 

‒ Миграция (migration).

 

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

 

ПРИМЕР.

 

Среди основных категорий миграции:

 

‒ Миграция платформ.

 

Миграция с IBM Mainframe COBOL/CICS/DB2/VSAM на Intel-платформу Windows Micro Focus COBOL (с БД Oracle).

 

‒ Миграция языков программирования.

 

Конвертация кода на C#.

 

‒ Миграция пользовательского интерфейса.

 

Переход от ПК-версии к веб-интерфейсу.

 

‒ Миграция аппаратного обеспечения.

 

Переход с DEC VAX-обеспечения на Intel PC сервера и рабочие станции (что в свою очередь, требует перевода ПО с VAX OpenVMS на MS Windows.

 

‒ Миграция баз данных.

 

Переход с IDMS на Oracle.

 

‒ Реинжиниринг (re-engineering).

 

Чаще всего применяется при адаптации сервисно-ориентированной архитектуры SOA, при построении прежних приложений на основе новых технологий / платформ, с прежней или же расширенной функциональностью.

 

‒ Рефакторинг кода.

 

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

 

ПРИМЕР.

 

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

 

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

 

‒ Смена хостинга (re-hosting).

 

Чаще всего проводится в качестве промежуточного шага при предстоящей замене аппаратного обеспечения (например, на UNIX/Wintel платформах).

 

‒ Внедрение «коробочного» решения (package implementation).

 

Замена устаревшего ПО целиком или частично на целые семейства решений (SAP, Oracle Apps).

 

ВИРТУАЛИЗАЦИЯ КАК СТРАТЕГИЯ МОДЕРНИЗАЦИИ РЕШЕНИЙ.

 

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

 

Сама концепция виртуализации появилась еще в 1970-х годах, когда IBM виртуализировала интерфейсы своего оборудования. VMS запускается непосредственно на основном оборудовании, позволяющем создавать множество виртуальных машин (VM), каждая из которых может обладать своей собственной операционной системой. Другим вариантом виртуализации в то время была симуляция процессора (выполнение псевдо-кода на виртуальной машине вместо реального оборудования).

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

 

‒ Происходит оптимизация расходов на ИТ.

 

‒ Увеличивается степень контроля над ИТ-инфраструктурой.

 

‒ Сокращаются плановые / внеплановые простои.

 

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

 

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

 

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

 

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

 

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

 

ОСОБЕННОСТИ ПРОЕКТОВ ПО МОДЕРНИЗАЦИИ.

 

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

 

Прежде, чем начать модернизацию, следует рассмотреть следующие аспекты:

 

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

 

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

 

‒ Целесообразность перехода на другую платформу. Для компаний, активно участвующих в процессах слияний и поглощений (M&A), эффективной альтернативой модернизации может стать консолидация и перевод legacy-систем на единую корпоративную платформу (в идеале – с хорошей масштабируемостью). Подобные активности могут значительно повысить затраты в краткосрочном периоде, но долгосрочные выгоды оказываются очень существенными.

 

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

 

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

 

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

 

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

 

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

 

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

 

3.4.               Утилизация.

 

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

 

ТЕХНИЧЕСКИЕ АСПЕКТЫ.

 

‒ Аппаратное обеспечение.

 

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

 

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

 

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

 

‒ Данные.

 

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

 

‒ Документация.

 

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

 

‒ Замещающие системы.

 

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

 

‒ Зависимые / интегрированные системы.

 

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

 

ОРГАНИЗАЦИОННЫЕ АСПЕКТЫ.

 

‒ Сотрудники ИТ-департамента компании.

 

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

 

‒ Подрядчики / специалисты, нанятые по контракту.

 

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

 

‒ Конечные пользователи.

 

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

 

КОММЕРЧЕСКИЕ АСПЕКТЫ.

 

‒ Контрактные вопросы.

 

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

 

ЮРИДИЧЕСКИЕ ВОПРОСЫ.

 

‒ Лицензирование.

 

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

 

‒ Отчетность.

 

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

 

ПРИМЕР.

 

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

 

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

 

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

 

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

 

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

 

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

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

    

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

 

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