Курсовая работа: Управление развитием ИС для предприятия ООО Прогресс

- автоматизация тестирования;

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

Стратегические цели ООО «Прогресс»:

- расширить спектр предоставляемых услуг;

- выйти на международную арену, расширив географию работ на страны ближнего зарубежья.

В общем виде все бизнес-процессы отображены на рисунке 2.

Так же рассмотрены отдельные уровни бизнес-процессов отдельно. Так, рисунок 3 Разработка ПО; рисунок 4 - Тестирование ПО; рисунок 5 - Отладка ПО, Рисунок 6- «Эксплуатация ПО».

Все модели реализовывались с помощью Business studio.

Рисунок 2 - Диаграмма декомпозиции IDEF0

Рисунок 3 - «Разработка ПО»

Рисунок 4 - «Тестирование ПО»

Рисунок 5 - «Отладка ПО»

Рисунок 6 - «Эксплуатация ПО»

1.2 Событийная цепочка процессов

Событийная цепочка процессов (EPC, event-driven process chain) - тип диаграмм, используемых для моделирования, анализа и реорганизации бизнес-процессов (функционального моделирования). В тоже время EPC-диаграммы могут использоваться для моделирования поведения отдельных частей системы при реализации функций и служить заменой традиционных блок-схем (поведенческого моделирования).

EPC-метод был разработан Августом-Вильгельмом Шеером (August-Wilhelm Scheer) в рамках работ над созданием методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем) в начале 1990-х годов.

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

Как и в случае с DFD, методология EPC «разрослась» интерпретациями, поддерживающими различные нотации (синтаксис и семантику элементов). К этому «приложили руку» как сам автор методологии, так и производители ПО, в котором реализована возможность моделирования бизнес-процессов посредством EPC (ARIS, Microsoft Visio, Business Studio, Bflow). По аналогии с блок-схемами, символы (элементы) графической нотации можно сгруппировать по назначению.

Для планирования реализации бизнес-процесса «Разработка программного продукта» необходимо построить EPC-диаграмму.

Каждый из этапов рассмотрен отдельно. На рисунке 7 представлен процесс разработки ПО.

Рисунок 7 - Диаграмма EPC для процесса «Разработка ПО»

1.3 Современные языки и среды моделирования архитектуры организации

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

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

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

Блок элементарных объектов организации, а именно:

- описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого организацией в настоящее время);

- средства, используемые для порождения таких представлений (т.е. данных по объектам) согласно определенным правилам (например, ERP, SCM, CRM, СУБД ).

Блок моделей архитектуры организации, а именно:

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

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

Блок языков и методологий моделирования, включая:

- обще модельные конструкции;

- процессы моделирования архитектуры организации;

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

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

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

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

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

- моделирование бизнес-процессов, моделирование бизнес-функций;

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

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

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

- универсальные интегрирующие среды (например, Zachman Framework, GERAM ),

- языки моделирования организаций (например, семейство IDEF, DFD-технология, ARIS, BPML),

- программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS, Casewise Corporate Modeler ),

- мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML ).

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

- поддерживают лишь отдельные компоненты среды моделирования,

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

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

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

Таблица 1 - Матрица Захмана

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

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

2. Разработка стратегии развития ИС для компании

2.1 Методы идентификации и приоритетов направления развития ИС

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

- проведение круглого стола с руководителями организации;

- анкетирование руководящего состава;

- интервьюирование руководителей.

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

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

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

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

На основе данной матрицы рассчитывается коэффициент «меры автоматизации». Для этого следует воспользоваться следующей формулой:

, (1)

где: - оценка согласия по i-му разделу; - количество строк в i-ом разделе; - уровень согласия в i-ом разделе, j-ой строке.

Рассчитаем меру автоматизации по формуле:

, (2)

где: - мера автоматизации; - вес i-го раздела; - количество разделов в матрице.

В полученной матрице всего 7 разделов. Рассчитывается коэффициент для каждого раздела по формуле 1. Были получены следующие показатели: S₁=0,7; S₂=0,6; S₃=0,5; S₄=0,6; S₅=0,6; S₆=0,6; S₇=0,3.

После того как были рассчитаны оценки согласия для каждого из раздело, можно приступить к нахождению меры автоматизации. В формулу 2 вместо - подставляем количество строк в каждом раздели, затем суммируем их, в результате получили 27. Соответственно первая часть выражения будет равна 1/27. Во второй части уравнения необходимо для начала найти произведение * , т.е. количество строк в разделе умножить на оценку согласия раздела, затем результаты сложить. Теперь можно подставить значения в формулу 2. Получаем, что = 0,56.