Разделы презентаций


Проектные работы по развитию ИТ архитектуры предприятия

Содержание

Тукмачева Ю.А. Национальный исследовательский ядерный университет МИФИ УДК 65 Международный научно-технический журнал «ТЕОРИЯ. ПРАКТИКА. ИННОВАЦИИ» ИЮНЬ 2017 http://www.tpinauka.ru/2017/06/Tukmacheva.pdfВ данной статье рассматривается IT-компания, которая претерпевает трудности в проектной деятельности, такие как закономерные

Слайды и текст этой презентации

Слайд 1Проектные работы по развитию ИТ архитектуры предприятия
Занятие 3
ПРИМЕНЕНИЕ МОДЕЛИ ЗАХМАНА

ДЛЯ РЕШЕНИЯ ПРОБЛЕМ, ВОЗНИКАЮЩИХ НА ЭТАПЕ РЕАЛИЗАЦИИ IT-ПРОЕКТА

Проектные работы по развитию ИТ архитектуры предприятияЗанятие 3ПРИМЕНЕНИЕ МОДЕЛИ ЗАХМАНА ДЛЯ РЕШЕНИЯ ПРОБЛЕМ, ВОЗНИКАЮЩИХ НА ЭТАПЕ РЕАЛИЗАЦИИ

Слайд 2Тукмачева Ю.А. Национальный исследовательский ядерный университет МИФИ
УДК 65 Международный

научно-технический журнал «ТЕОРИЯ. ПРАКТИКА. ИННОВАЦИИ» ИЮНЬ 2017
http://www.tpinauka.ru/2017/06/Tukmacheva.pdf

В данной статье

рассматривается IT-компания, которая претерпевает трудности в проектной деятельности, такие как закономерные задержки в части сдачи сроков по проекту. Решение выявленных проблем осуществляется с помощью построения архитектуры проектной деятельности компании, используя модель Захмана.
Тукмачева Ю.А. Национальный исследовательский ядерный университет МИФИ УДК 65 Международный научно-технический журнал «ТЕОРИЯ. ПРАКТИКА. ИННОВАЦИИ» ИЮНЬ 2017

Слайд 3Введение.
С каждым годом с ростом информационных технологий растет и

поток информации. Раз за разом этим потоком становится все труднее

управлять. Предприятия не успевают оценивать, как будут взаимодействовать между собой отдельные элементы предприятия, как будет проходить интеграция отдельных технологических решений. Из-за озвученных выше проблем по оценкам различных консалтинговых компаний, примерно 50% ИТ-проектов в различных отраслях заканчиваются не так, как запланировано [3]. Одним из путей решения является методика построения архитектуры предприятия. Архитектура предприятия — это современная, инновационная и высокоэффективная концепция стратегического управления, использование которой позволяет быстрее и более целенаправленно изменять предприятие для реагирования на вариации внешней среды [2
Введение. С каждым годом с ростом информационных технологий растет и поток информации. Раз за разом этим потоком

Слайд 4Архитектура – это описание некоторой сложной системы в определенный момент

времени. Также архитектура – это процесс, т.е. набор руководств, правил

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

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

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

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

Слайд 6Методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META

Group и другими;
· Модель Захмана;
· Методика TOGAF;
· Методика POSIX 1003.23,

которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.
· FEAF – Federal Enterprise Architecture Framework (для гос. организаций)
· DoDAF ­– для Министерства Обороны США
Методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;· Модель Захмана;· Методика TOGAF;·

Слайд 7Методики описывают, как определяются и документируются основные элементы архитектуры предприятия.

Они позволяют решить проблему плохого взаимопонимания между вовлеченными в этот

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

Слайд 9Целью данной статьи является применение архитектурного подхода в IT-компании, а

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

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

Слайд 10Компания на рынке существует относительно недавно – около двух лет.

За все время деятельности уже разработано не мало информационных систем,

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

Слайд 11Чтобы попытаться определить в чем заключается причина появления таких проблем,

автором было принято решение проанализировать деятельность копании в части осуществления

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

Слайд 12В связи с тем, что компания занимается разработкой разного рода

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

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

Слайд 13Модель Захмана
Захманом была предложена матрица размером шесть на шесть. Каждая

строка представляет собой видение системы с конкретной точки зрения. Все

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

Слайд 14По столбцам таблицы
Используемые данные (что?);
Процессы и функции

(как?); 
Места выполнения этих процессов (где?); 
Участники и

ключевые организации (кто?); 
Управляющие события (когда?);
Цели и мотивация (зачем?).
По столбцам таблицы Используемые данные (что?); Процессы и функции (как?);  Места выполнения этих процессов (где?); 

Слайд 15В качестве участников
В качестве участников предлагаются следующие: планировщик, представляющий

бизнес в целом;
менеджер, рассматривающий структуру организации в бизнес терминах;


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

Слайд 16Модель Захмана
п

Модель Захмана п

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

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

Слайд 19Из построенной матрицы можно заметить, что видение системы с точки

зрения разработчиков, не совсем относится к самой системе. Каждый разработчик

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

Слайд 20Эту же проблему можно увидеть на схеме Модель проектной деятельности

«As is»
о

Эту же проблему можно увидеть на схеме Модель проектной деятельности «As is» о

Слайд 21Из рисунка 3 видно, что задачи в отдел разработки поступают

со всех проектов, которые разрабатываются на предприятии. В такой ситуации

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

Слайд 22Следуя таким путем, как уже можно догадаться, трудно добиться успехов

в проекте. Это может привести к подрыванию доверия со стороны

Заказчика. Чтобы избежать такой ситуации, автором предлагается следующая модель проектной деятельности (модель «To be»), представленная на Рисунке 4.
Следуя таким путем, как уже можно догадаться, трудно добиться успехов в проекте. Это может привести к подрыванию

Слайд 23Модель проектной деятельности «To be»
э

Модель проектной деятельности «To be» э

Слайд 24Предлагается под каждый отдельный проект сформировать проектную группу. В состав

проектной группы будут входить: руководитель проекта, бизнес и системные аналитики,

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

Слайд 25Детальное представление проектной группы располагается на Рисунке 5. Оно схоже

с моделью «As is» (в части реализации проекта), но как

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

Слайд 26р
Состав проектной группы

рСостав проектной группы

Слайд 27Заключение.
В данной статье была рассмотрена модель Захмана, как средство построения

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

проекта и выявить первопричину задержек по сдаче проекта. По итогам анализа, автором была предложена модель «To be», которая должна помочь в решении данной проблемы. Безусловно, это является не единственной проблемой проекта. Для выявления более глубоких проблем, требуется детальный анализ, например, на сколько эффективно проходит процесс управления требованиями к системе и т.д.
Заключение.В данной статье была рассмотрена модель Захмана, как средство построения архитектуры IT-проекта. Данный способ позволил системно взглянуть

Слайд 30Матрица Захмана
Модель Захмана основана на дисциплине классической архитектуры и

обеспечивает общий словарь и набор перспектив, или структур (framework), для

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

Матрица Захмана Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или

Слайд 31Модель преследует две основные цели – с одной стороны, логически

разбить все описание Архитектуры на отдельные разделы для упрощения их

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

Слайд 32Строки представляют собой различные уровни абстракции (перспективы), а наборы столбцов

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

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

Слайд 34Перспективы (строки в таблице) могут, в частном случае, соответствовать различному

уровню управления предприятием, если речь идет об архитектуре предприятия или

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

Слайд 35Аналогично, в применении к деятельности предприятия верхняя строка "Контекст" соответствует

уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует

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

Слайд 36На каждом из этих уровней участники, вообще говоря, рассматривают одни

и те же категории вопросов, соответствующих столбцам в таблице, –

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

Слайд 37В содержание этих колонок входят:
 используемые данные (что?)
· процессы и

функции (как?)
· места выполнения этих процессов (где?)
· организации и персоналии–участники

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

Слайд 38Правила заполнения
· каждая клетка таблицы независима от других, вместе

они образуют функционально полное пространство для описания системы ("базис");
· порядок

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

Слайд 39Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На

этом уровне вводятся достаточно общие основные понятия, определяющие бизнес –

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

Слайд 40Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса

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

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

Слайд 41На четвертом уровне – технологической или физической модели – осуществляется

привязка данных и операций над ними к выбранным технологиям реализации.

Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к

Слайд 42Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования,

топологию сети, производителя и версию СУБД, средства разработки и собственно

готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства

Слайд 43Детализация системы
Первая колонка отвечает на вопрос "ЧТО?" и определяет используемые

в системе данные. На верхнем уровне достаточным будет простое перечисление

основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п.
Детализация системы Первая колонка отвечает на вопрос

Слайд 44Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания

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

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

Слайд 45Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую

организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех

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

Слайд 46Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне

планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими

функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли, требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Колонка таблицы, отвечающая на вопрос

Слайд 47Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов

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

календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Пятая колонка отвечает на вопрос

Слайд 48Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает

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

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

Слайд 49Основными характеристиками данной модели Захмана являются
 простота для понимания;
· целостность

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

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

Основными характеристиками данной модели Захмана являются  простота для понимания;· целостность в отношении предприятия, то есть каждая проблема

Слайд 50Плюсы:
· облегчает понимание и общение людей, имеющих разные роли в

процессах создания, развития и использования системы;
· ясно определяет фокус внимания

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

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

Слайд 51Еще примеры

Еще примеры

Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

Это сайт презентации, докладов, проектов в PowerPoint. Здесь удобно  хранить и делиться своими презентациями с другими пользователями.


Для правообладателей

Яндекс.Метрика