Оценка проекта Campaign Management при использовании предложенного варианта - Метод интеграции сторонних систем анализа и обработки данных в существующую ИС-архитектуру компании

Прогнозируемая оценка проекта после реализации единой шины данных как прослойки между всеми компонентами ИТ-ландшафта компании выполняется по методу оценки на основе Use-case points на примере проекта Campaign management.

Методология описана в приложении 1. На этапе оценки акторов видно различие от оценки без ESB. Простой актор использует систему по предопределенному API (REST, SOAP, dll), средний использует более сложный и гибкий API, комплексный в большинстве случаев означает взаимодействие с конечным пользователем (см. таблицу 5).

Таблица 5. Оценка акторов

Тип актора

Описание

Степень важности

Значение

Результат

Простой

Внутренняя система с определенным API

1

2

2

Средний

Внутренняя система, использующая интерфейс, основанный на протоколе (HTTP, TCT/IP) или на базе данных

2

4

8

Комплексный

Человеческий ресурс

3

2

6

Нескорретированный вес актора (UAW)

16

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

Таблица 6. Нескорректированная оценка вариантов использования

Тип прецедента

Описание

Степень важности

Значение

Результат

Простой

1-3 операции

5

9

45

Средний

4-7 операций

10

2

20

Комплексный

>7 операций

15

0

0

Нескорректированный вес прецедента (UUCW)

85

Нескорректированные очки прецедента (UUCP)=

= UAW + UUCW

101=16+85

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

Также в качестве транзакта можно использовать количество объектов в БД, изменяемых в рамках одного варианта использования. В этом случае ранжирование будет иметь такой вид: простой - 1 объект, средний - 2 объекта, комплексный - больше или равно 3 объекта.

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

Таблица 7. Оценка технических факторов

Номер фактора

Описание

Степень важности

Присвоенное значение (0-5)

Значение оценки

Т1

Распределенность системы

2

2

4

Т2

Малое время отклика или высокая пропускная способность

1

3

3

Т3

Степень эффективности от использования системы конечным пользователем

1

5

5

Т4

Комплексность внутреннего выполнения процессов системы

1

5

5

Т5

Возможность повторного использования кода

1

3

3

Т6

Низкая степень сложности при установке системы

0,5

2

1

Т7

Низкая степень сложности при использовании системы

0,5

3

1,5

Т8

Возможность экспорта системы на другую платформу

2

0

0

Т9

Возможность сопровождения системы

1

5

5

Т10

Возможность параллельной обработки системы

1

3

3

Т11

Требуемый уровень безопасности системы

1

4

4

Т12

Степень доступа к системе третьими лицами

1

5

5

Т13

Необходимость в обучении пользователей по использованию системы

1

4

4

Значение фактора технической сложности (TFactor)

43,5

Фактор технической сложности (TCF) =

=0,6 + (0,01*TFactor)

1,035=0,6 + (0,01*43,5)

На этапе оценки внешних факторов (см. таблицу 8) производится расчет коэффициента для оценки организационных рисков при разработке. В данном случае при внедрении единой интеграционной шины оценка внешних факторов наоборот показывает увеличение затрат, поскольку в команду разработки будут требоваться более квалифицированный персонал, особенно это касается архитектора, разрабатывающего технические решения совместно с руководителем группы. К примеру, в показатель "Сложности, связанные с языком программирования" запишется значение более высокое по сравнению с оценкой до внедрения ESB, что вызвано необходимостью владения не только pl/sql (основной язык разработки для решения задач проекта Campaign Management), но и JavaSrcript.

Таблица 8. Оценка внешних факторов

Номер фактора

Описание

Степень важности

Присвоенное значение (0-5)

Значение оценки

E1

Опыт персонала в установленном процессе разработки

1,5

2

3

E2

Степень разработанности системы

0,5

4

2

E3

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

1

3

3

E4

Способности ведущего аналитика

0,5

3

1,5

E5

Уровень мотивации рабочей группы к выпуску системы

1

3

3

E6

Стабильность требований Заказчика

2

2

4

E7

Наличие персонала, работающего на пол-ставки в рабочей группе

-0,5

0

0

E8

Сложности, связанные с используемым языком программирования

-1,5

5

-7,5

Значение дополнительных фактора (EFactor)

9

Внешний фактор (EF) = 1.4 + (- 0,03*EFactor)

1,13

=

1,4 + (- 0,03*9)

Установленные очки прецедента (UCP) = =UUCP*TCF*EF

118,12

=

101*1,035*1,13

Усилия в человеко-часах = UCP*PHM

2362,491

=

118,12*20

В результате подсчитываются итоги. Итог = 337,49 (человеко-часы каждого разработчика (7 человек)). После получения оценки необходимо правильно оценить количество часов на один поинт. Существуют классические рекомендации, равные 20-28 часов, однако в действительности оценка может отличаться, в зависимости от следующих факторов:

Ѕ степень абстракции при создании диаграмм вариантов использования;

Ѕ готовность оценивать тестирование, требования и менеджмент таким же образом.

Таким образом, получена разница в примерно в 91 час. Стоит отметить, что при более точном планировании можно выявить дополнительные факторы, которые окажу существенное влияние на человеко-часы при реализации после внедрения ESB.

Заключение

По завершении работы получены следующие результаты:

Ѕ приведено обоснование необходимости создания гибкого метода интеграции новых систем (чаще всего инструментов BI) в общую ИТ-архитектуру компании. Метод интеграции сторонних систем анализа и обработки данных в существующую ИС архитектуру компании позволяет:

Ѕ легко внедрять/настраивать системы бизнес-аналитики;

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

Ѕ не вносить существенных изменений в существующую архитектуру ИС компании при каждом новом внедрении сторонней системы;

Ѕ шаблонной интеграции с бизнес-процессами компании.

Ѕ в результате анализа особенностей инвестиционных ИТ-проектов "Витрина данных SPSS" и "Campaign Management" проведена оценка длительности и экономической эффективности проектов. Предположено, что при внедрении метода интеграции значительно сократятся трудозатраты исполнителей при подготовке витрины данных и интеграции инструментов в существующие бизнес-процессы компании;

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

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

Ѕ проанализированы экономические показатели инвестиционных проектов по внедрению систем аналитической обработки данных на примере IBM SPSS и IBM Campaign Management после изменения разработанного метода интеграции;

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

Ѕ адаптация к существующей архитектуре ИС компании;

Ѕ быстрота интеграции кс существующими системами;

Ѕ гибкая корректировка конфигурации;

Список терминов и сокращений

Термин/ сокращение

Содержание

API

Англ., Application programming interface - Интерфейс программирования приложений

BI

Англ., Business intelligence - Бизнес-аналитика

CRM

Англ., Customer Relationship Management - Система управления взаимоотношениями с клиентами

ERP

Англ., Enterprise Recourse Planning - Система планирования ресурсов предприятия

ETL

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

    1) извлечение данных из внешних источников (Extract); 2) трансформация и очистка (Transform); 3) загрузка в хранилище данных (Load)

MIS

Англ., Management Information Systems - Управленческая информационная система

OLAP

Англ., OnLine Analytical Processing - Аналитическая обработка в режиме реального времени

SPSS

Англ., Statistical Package for the Social Sciences - Статистический пакет для социальных наук

IBM SPSS Modeler

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

UCP

Англ., Use Case Points - Методика оценки проектов на основе вариантов использования оцениваемой системы

UML

Англ., Unified Modelling Language - Универсальный язык моделирования

WfMS (Workflow Management Systems), CRM (Customer Relationship Management), ERP (Enterprise Recourse Planning)

WfMS (Workflow Management Systems), CRM (Customer Relationship Management), ERP (Enterprise Recourse Planning),

XML

Англ., Extensible Markup Language - Расширяемый язык разметки информации, стандарт языка для обмена данными между различными приложениями

БД

База данных

ПО

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

СППР

Системы поддержки принятия решений

СУБД

Система управления базами данных

ТЗ

Техническое задание

ХД (Data Warehouse)

Хранилище данных

Похожие статьи




Оценка проекта Campaign Management при использовании предложенного варианта - Метод интеграции сторонних систем анализа и обработки данных в существующую ИС-архитектуру компании

Предыдущая | Следующая