функциональный и процессный подход

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

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

владелец требования, автор требования - мы можем увидеть откуда идет требования

( для трассировки),
версия продукта - чтобы глянуть итерацию
статус
ПОЛЬЗУЕМсЯ ADM TOGAF план последовательность действий
т.е. 4 этапа ADM’a для составления ИСР.
мы только проектируем решение (мигрейшн планнинг ФАЗА Ф последняя ДО ПЛАНА
МИГРАЦИИ. БУДЕМ ЕГО ЗАЩИЩАТЬ)

4 этапа :инициация планирование реализация завершение

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

внутренняя ставка - примерно 80 т.р. в месяц - 500 рублей час

внешняя ставка (для заказчиков) -
+ страховые взносы  (30%),
накладные расходы - те которые нельзя прямо отнести на с\с (например, аренда офиса,
з\п адм. персонала) - накладные расходы 100% по отношению к фонду оплаты труда
+ НДС (20%)
+ налог на прибыль (20%) в итоге из 80 тысяч = 265 т.р. - рассчитать

Группы вопросов

1.Обоснуйте целесообразность разработки в вашем проекте

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

изменений в рамках всей компании
2) Компонентная – также чтобы взглянуть на компанию в целом, но при этом уже с точки
зрения детализации на уровни управления (стратегия, тактика, операции) и
рассмотрение отдельных бизнес-единиц (компонентов), а также проследить изменение
уровня зрелостей этих компонент
3) Верхнеуровневая – отображение всех слоев архитектуры компании, их взаимосвзяи,
отобразить изменения во всех слоях. Но самое главное это связи, кто кого реализует и за
счет чего.
4) Дерево целей – в нашем случае это дерево ИТ-задач. Здесь мы показываем взаимосвязь
карты ит процессов и требования, выведенные в мотивационной модели, что все
процессы новые – относятся. Или можно сказать что здесь декомпозируются требования
мотивационной модели для их непосредственной реализации уже как процессов в ИТ-
отделе
5) ССП – цели компании определяем. Проект должен способствовать достижению этих
целей.
 6) Модель окружения – оценить внешнее окружение компании. С кем есть взаимосвязи,
как проект может на них повлиять, как мы можем их использовать для реализации
проекта.
7) Орг структура – понимание структуры компании, кто какие задачи выполняет, кто кому
подчиняется - для реинжиниринга это очень важно.
8) План учебного проекта – для контроля хода выполнения работы, планирования задач,
распределения обязанностей, для отчетности.
9) Реестр стейкхолдеров – определяем кто будет влиять и участвовать в проекте, что ему
нужно, какие артефакты, какое воздействие оказывать, на основе реестра
вырабатывается модель взаимодействия со стейкхолдерами
10) Диаграмма детализации сегмента бизнес-слоя – по всей видимости – карта процессов,
т.к. на ней отображены по сути все основные и вспомогательные бизнес-процессы – ну
как всегда оценить изменения в основном бизнес-процессе, какие процессы будут
затронуты. Текущее состояние – для концептуального понимания, как он проходит
вообще + распределение на основные и вспомогательные.
11) Слой ИС – чтобы детализировать функциональные возможности разрабатываемой
системы, нужна для разработчиков в основном и для требований.
12) Диаграмма перехода – отобразить нужно ли переходное состояние, какие изменения к
какому состоянию относятся, какие результаты реализации каждого проекта
13) План реалиации – план внедрения – определить задачи по переходу, примерные сроки,
затраты
14) Модели бизнес-процессов – детализация основного процесса для анализа ас ис, найти
какие-то узкие места и в модели ту би уже отобразить во первых изменения, во вторых
исправить эти узкие места. Но в основном конечно отобразить изменения, линейные
руководители по этим моделям будут согласовывать или отклонять изменения
15) Реестр требований – чтобы понимать кто ввел требования, кому они нужны, какой
приоритет данного требования, статус, управление требованиями – важный аспект
любого проекта.
16) Фрагмент мотивационной модели – чтобы обосновать целесообразность проекта,
продемонстрировать связь целей конкретных стейкхолдеров и выгоды проекта
17) Карта процессов – уже писал зачем
18) Модели ит процесса – ИБ – как таковой модели ит процесса нет, но есть метрики и
описание процесса ИБ. Описание процесса необходимо для понимания
функционирования одного из главных нововведений проекта, для того чтобы клиент
понимал, что его данные будут в безопасности у нас. Как определить качество услуги?
Посмотреть на процесс, а мы его как раз и описали.
19) Реестра ис – у нас нет такого. Но вообще было бы полезно знать какой у нас там зоопарк
творится в системах, чтобы понимать как мы можем использовать текущие
возможности данных систем, как будем интегрировать новую систему, какие
интерфейсы понадобятся, может быть по описанию систем понятно будет, что они будут
выведены из эксплуатации из-за внедрения новой системы, т.к. она их функции будет
заменять
20) Тех слой – чтобы показать детальнее структуру технологическую которая будет
реализована – для примерного понимания какое ПО надо будет закупить, какое железо.

2.Обоснуйте целесообразность проведения в вашем проекте. Дайте оценку результатов

проведенного анализа

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

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

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

1) Остервальдер и модель окружения – партнеры на остервальдере это по сути тоже

окружение
2) Реестр требований и слой ИС – например, в системе должен быть реализован алгоритм
LSA – требований и этот алгоритм пристствует на слое ИС
Или например визуализация данных – одна из функций системы, а в требованиях
написано что система должна визуализировать данные
или конвертация данных в текст
3) Компонентная модель и верхнеуровневая -
например ведение бух учета и там и там отображено, ит процессы такие как управление
иб,проблемами, доступностью и т.д. тоже там есть
все процессы основные также отображены в компонетной модели
4) Реестр требований и мотивационная модель
мотивационная модель отображает верхнеуровневые требования к проекту. В реестре
требований они детализируются, например: реализовать интерфейс взаимодействия
консультанта-психолога и системы – требование, и требование в реестре требований:
Система должна иметь веб-интерфейс для представления визуализированных
данных
5) Реестр стейкхолдеров и мотивационной модели – ну тут просто стейкхолдеров указать
которые и там и там есть
6) Дерева целей и мотивационной – без комментариев
7) Свот и мотивационной – слабости – оценки, возможности=драйверы
8) Реестр стейкхолдеров и все остальные – ну артефакты нужны в основном как раз для
стейкхолеров, чтобы им показать, согласовать, это же способ визуализации просто того
над чем работаем.
9) Зачем разрабатывались артефакты – ну каждый для своего нужен, но единая цель –
задокументировать и визуализировать какие-то вещи, которые были поняты, выяснены
в ходе выполнения заданий. Полезны могут быть в принципе всем стейкхолдерам,
каждому своя пачка это в реестре отображено
10) Потенциальному инвестору проекта – мотивационная, свот анализ,ссп – покачану, они
простые и на них видна связь и результат четкий и прозрачный

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

ЧТО МЫ ИСПОЛЬЗОВАЛИ:

1. Референтные модели
1) TOGAF ADM – для планирования проекта. Начальный этап. Этап анализа и
разработки архитектуры и этап реализации и перехода (до планирования перехода)
+ план\фактный анализ. Тогаф внутри пмбоковской ИСР
 2) ITIL – в карте процессов, для создания грамотных ит-процессов
3) COBIT – тож самое
2. Фреймворки:
a. Togaf – из него взяли адм
b. Hadoop – из него взяли организацию системы
c. PMBOK – тоже для планирования. В начале инициализация, потом планирование
и на нем мы получается сворачиваемся
3. Программные среды – bizagi, staruml, archi, project, excel
4. Нотации:
a. BPMN –
b. Archimate
c. UML
5. Стандарты
a. Не использовались

ЧТО МОЖНО БЫЛО ИСПОЛЬЗОВАТь:

1. EPC – для бизнес процессов

2. ARIS express – рисовать в epc
3. Visio – орг структуру и БП рисовать
4. MOF – майкрасофтовский itil
5. FEAF
6. IDEF 0

5.На понимание ситуаций, применения различных ИТ-решений

1) Собственная ит-инфраструктура – потому что мы работаем с данными пользовательскими

и в этом вопросе выгоднее показать что все храниться будет у нас вот туточки. Плюс нужен
постоянный контакт ит-специалистов с системой удаленно конечно можно это все делать,
но удобнее когда все рядом.
2) Частное облако – вычислительные ресурсы в компании, но подключаются к ним не
напрямую.
Публичное облако – вычислительные ресурсы предоставляются нескольким компаниям.
Например, Амазон
Облако сообщества – какой-то группе клиентов предоставляются мощности
Гибридное – частное облако в обычное время и публичное в пиковые нагрузки.
3) Детализируя слой ИС, мы можем отобразить на нем например, что для каждой
услуги(сервиса) у нас есть свое СЛА. СЛА можно разработать и вместо детализации слоя
ИС: слой ИС – это артефакт, который мы разрабатываем для кого-то в нашем случае это
могут быть разрабы, либо бизнес-аналитики, которые на основе детализированного слоя
разрабатывают UML диаграммы уже для разрабов. В случае, если разработки в проекте не
предстоит и юмл диаграммы в общем-то не нужны , значит слой ИС как таковой не
пригодится и можно написать просто СЛА для новой услуги. СЛА уже идет не бизнес-
аналитикам и не разрабам, а заказчику(руководству) услуги – его легче понять, прочитать,
вынести оттуда основные аспекты предоставляемой услуги.
для тех слоя тут в принципе тоже самое наверное. Т.е. дополнительно сла стоит
разработать чтобы показать верхам, которые в этих слоях ничего не понимают, а вместо
разрабатывать, когда эти слои вовсе не нуждаются в детализации
4) Saas – ит провайдер нам предоставляет нам готовый сервис, мы абстрагируемся от железа
и т.д.
Iaas – ит провайдер нам предоставляет инфраструктурный мощности, на них что хотим
разворачиваем
 paas – промежуточный вариант, когда предоставляется платформа, но при этом на ней мы
можем инсталлировать какие-то свои приложения. (железо со средой и осью)
5) Показатели надежности, доступности и непрерывности сервиса – это реестр требований +
процессы доступности ИТ у нас появляются например.furps+ - функционал юзабилити
надежность, производительность и поддерживаемость и плюс.

6.На необходимость анализа системы управления ИТ

1) Необходимость связи бизнес и ит-целей – ну очевидно же, что если ит будет не

соответствовать бизнес целям то зачем тогда нужен вообще айти, если он не
способствует достижению бизнесовых целей.
2) ИТ-показатели -
3) Карта ит-процессов -
4) Внутренние и внешние ИТ-сервисы
5) Аутсорсинг и инсорсинг – инсорсинг – решение задач за счет внутренних резервов, не
привлекая внешнего поставщика
6) Организационная и ролевая модель ит-службы
7) Функциональный и процессный подход, их достоинства и недостатки:
процессный подход – открываем карту процессов, видим реализацию процессного
подхода. Достоинства: направленность на определенный результат,
клиентоориентированность, гибкость, возможность управлять процессами. Недостатки:
размытая ответственность, люди не всегда узкоспециализированы (проф качества не
очень могут быть). У функционального наоборот соответственно

7.На общее понимание выполненного учебного проекта

Достоинства командной работы :

1) Распределение обязанностей – большое количество задач решается за меньшее

количество времени
2) Рассмотрение аспекта с разных точек зрения помогает всесторонне его оценить
3) Взаимовыручка – если кто-то что-то вдруг не успевает, есть возможность замениться
4) Наличие внутренних методов отбора\фильтра работы. Т.е. внутри команды есть какая-
то проверка условного артефакта и он лютым говном не выйдет в свет.

Недостатки командной работы:

1) Необходимость прихода к единой точке согласия, много дебатов

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