VeronikaLoseva: /* Заключение */

2017-07-12T07:46:28Z

‎Заключение

VeronikaLoseva: /* Полезная литература */

2017-07-11T14:27:51Z

‎Полезная литература

Новая страница

''<blockquote>В нашем корпоративном блоге на портале [https://habrahabr.ru/top/ «Хабрахабр»] появился новый пост: [[:Категория:Ольга Цыганова (Статьи)|Ольга Цыганова]], наш ведущий системный аналитик, поделилась опытом унификации деятельности аналитиков в CUSTIS. Как изменить неповоротливую систему устаревших аналитических практик? Что позволяет снизить трудозатраты аналитиков и рационально использовать их артефакты? Об этом — в статье [https://habrahabr.ru/company/custis/blog/332018/ «Как мы унифицируем аналитическую деятельность в CUSTIS»] на сайте издания.</blockquote>
''
Мы писали в блоге о технологиях в привычном айтишному миру понимании — о наших лучших практиках в разработке информационных систем. Сегодняшний пост посвящен технологиям другого толка — управленческим: мы поговорим об унификации аналитической деятельности в CUSTIS. Эта история о том, как изменить огромную и стабильную систему сложившихся с годами практик и направить ее навстречу проектам развития.

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

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

* занимался только одним проектом и глубоко разбирался в деятельности конкретного заказчика;
* был прекрасно сработан с архитекторами, разработчиками и тестировщиками в своей проектной команде;
* применял для написания постановок привычные инструменты, например Wiki и Bugzilla.

Эта модель стала неэффективной, когда мы начали переходить к созданию тиражируемых решений и работать одновременно над б'''о'''льшим количеством проектов. Нам потребовалось быстро ротировать аналитиков между проектами и повторно использовать их артефакты, а из-за того, что один описывал действия пользователя в системе Visio, а другой — в Archi, возникали дублирование описаний и неразбериха с нотациями.

Мы поставили перед собой задачу выбрать и внедрить для всех проектных команд одну методику или набор методик, которые будут отвечать новым бизнес-задачам. В посте мы расскажем, как разрабатываем эту методическую основу.
== Начинаем работу ==
Мы начали с того, что выделили три трека, в рамках которых будем проводить унификацию:
# '''Методический трек.''' Создаем методическую основу для проведения работ на разных проектах. По итогам испытаний и внедрения вносим в результаты этого трека корректировки.
# '''Испытания.''' Проверяем разработанные методы на реальных проектах. Собрав качественные и количественные показатели, возвращаемся к методическому треку и дорабатываем методики.
# '''Внедрение.''' Принимаем успешно апробированные наработки и делаем их обязательными для всех аналитиков. Это этап, когда методика становится официальной практикой для всей компании.
Затем мы проанализировали аналитическую деятельность в разных проектных командах и определили, что необходимо унифицировать:
* типы проектов в компании;
* концепты аналитической деятельности (метауровень);
* инструменты работы аналитика;
* роли, которые участвуют в аналитической деятельности;
* описание работы людей, выступающих в этих ролях:
** входной артефакт;
** выходной артефакт;
** технология создания выходного артефакта;
* шаблоны артефактов аналитической деятельности;
* перечень обязательных и необязательных аналитических артефактов для различных типов проектов;
* методику обучения аналитиков.
В следующих разделах подробнее расскажем о результатах методического трека работ.
== Определяем типы проектов ==
Мы выделили четыре типа проектов в компании, на которых нам важно уметь перемещать аналитиков:

# '''Доработка существующих систем''' — корректировки, выделяемые в отдельные проекты. Трудозатраты: от 200 до 1500 человеко-часов. Длительность: до полугода. К таким проектам относится, например, разработка нескольких визуальных форм с отчетами, алгоритмов их заполнения, нескольких таблиц базы данных, фильтрации, выгрузки данных из отчетов в xlsx, pdf.
# '''Новый проект (автоматизация «с нуля»)''' — разработка автоматизированных систем, когда у клиента нет «предыдущего» решения либо нужно полностью заменить существующую систему. Трудозатраты: от 1500 до 10 000 человеко-часов. Длительность: от полугода до года.
# '''Анализ request for information (RFI), предпроект, ведение бизнес-тем''' — бизнес-анализ процессов заказчиков. Реализация таких проектов может привести к запуску проектов автоматизации с нуля либо доработок существующих систем.
# '''Реинжиниринг существующих систем''' — полная переработка имеющейся системы.

Далее мы приступили к выделению тех понятий, в которых аналитики будут описывать создаваемые системы.
== Описываем концепты аналитической деятельности ==
На UML-диаграмме (см. ниже) показаны концепты аналитической деятельности, которые мы выделили. Используя их, аналитики создают описание IT-системы и общаются.

Схема состоит из следующих элементов:
* голубые прямоугольники — концепты;
* пунктирные прямоугольники — типы диаграмм;
* прямоугольники со сплошным контуром — папки в шаблоне проекта в Enterprise Architect, где содержатся диаграммы.
[[File:CUSTIS_Модель концептов описаний_3.png]]

Подробно остановимся на основных концептах.

* Процесс — бизнес-процесс заказчика. Он может включать как автоматизируемые, так и не автоматизируемые функции в рамках разрабатываемой системы.
: Описывается в нотации BPMN. Объекты на такой диаграмме могут быть типа Business Process — для диаграммы верхнего уровня и Activity — для диаграммы, описывающей процесс до элементарных операций.
: Описание должно быть шире, чем автоматизируемый процесс, чтобы при чтении диаграммы был понятен контекст.
* Роль — роль пользователя в системе или организационная единица.
: Роль, исполняющая процесс или операцию, визуализируется на BPMN-диаграмме с помощью Pool и Lane, а на диаграмме Use Case — с помощью Actor.
* Операции — операции, выполняемые в рамках локального процесса (локальные операции), или используемые в других процессах (глобальные).
: Создаются на BPMN-диаграммах элементом Activity.
* Автоматизируемая операция — элементарная операция, неделимая в рамках разрабатываемой системы.
: На BPMN-диаграммах обозначается элементом типа Activity. Для него нужно устанавливать тип выполнения операции Manual, Script, User. Manual означает, что операция выполняется пользователем в информационной системе, Script — операция выполняется внутри системы, User — пользователи выполняют действия вручную. При описании бизнес-процессов для функций первых двух типов необходимо создавать требования для их выполнения.
* Информационный ландшафт — все системы и подсистемы, которые задействованы в рамках бизнес-процесса, и передаваемые между ними данные.
: При описании используется диаграмма потоков данных.
* Объект данных — класс объектов реального мира.
: Создается на диаграммах классов в нотации UML.
* Автоматизируемая задача — задача, сформулированная заказчиком либо аналитиком.
: Отображается элементом Feature. Он присутствует на BPMN- и Use Case-диаграммах. На BPMN-диаграммах он связывается с операциями, на Use Case —с элементами типа Use Case. Таким образом получается связь между бизнес-моделью и автоматизируемыми задачами.
* Функция — описание поведения системы, когда она взаимодействует с кем-то или чем-то. Описание может совпадать с тем, как сформулирована автоматизируемая задача, или обобщать несколько задач.
: Отображается на Use Case-диаграммах элементами типа Use Case. Они состоят из шагов — атомарных неделимых действий. К функциям привязываются элементы типа Requirement.
* Требование — условие, которое должно быть удовлетворено.
: Отображается элементом Requirement. Может присутствовать на диаграммах трех типов: BPMN, Use Case, диаграммах требований.
: На диаграмме требований можно создавать иерархию требований, задавать в объектах название и описание. Для приоритизации требований устанавливается модальность: может, должен, обязан.
* Таблица — таблица базы данных.
: На ER-диаграммах отображаются не только таблицы, но и связи между ними. Несколько таблиц могут быть связаны с несколькими классами реализации.
* Класс — классы объектов реализации, которые создает разработчик при проектировании.
: Классы реализации отображаются на диаграмме классов в нотации UML.
* GUI — описание пользовательского интерфейса.
: Создается на диаграмме типа Dialog Wireframe Diagram. Обязательные элементы диаграммы: Use Case и макет экранной формы, факультативные: компонент, класс, таблица.
* Компонент — это часть системы, выполняющая какую-то функцию.
: Компонентную диаграмму создают на этапе проектирования системы архитекторы или разработчики, чтобы отразить ее состав.
Чтобы использовать на практике концепты, нужно выбрать единый для всех инструмент моделирования. О нем — в следующем разделе.

== Выбираем аналитические инструменты ==

О достоинствах и недостатках инструментов, обеспечивающих аналитическую деятельность, можно спорить бесконечно. Например, кому-то нравится развивать мелкую моторику на примере [https://www.metasonic.de/en/touch вот таких решений] для моделирования бизнес-процессов.

Наша компания много лет использовала гибкие методики разработки DDD (Domain Driven Design) [7] и инструменты Wiki [6]. Мы опирались на этот опыт и искали новые рыночные методики и инструменты аналитической деятельности.

Мы выписали возможные кейсы использования инструмента, опробовали их на нескольких проектах [9], пообщались с коллегами из других компаний и в итоге остановили выбор на [http://www.sparxsystems.com/products/ea/index.html Enterprise Architect].

Для нас были критичными такие параметры, как:
* поддержка нотации BPMN и UML, ArchiMate 3.0;
* ведение версионности проектов и диаграмм;
* функции экспорта и импорта моделей;
* выгрузки документации на основе диаграмм без привлечения разработчиков для создания шаблонов выгрузок документов;
* возможность коллективно работать с диаграммами;
* низкая стоимость и гибкая лицензионная политика;
* наличие действующего сообщества пользователей и разработчиков.

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

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

== Разрабатываем шаблон проекта в Enterprise Architect ==

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

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

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

Набор артефактов в шаблоне меняется в зависимости от типа проекта.

Желающие могут пройти по ссылкам ниже и посмотреть, что это за артефакты. В описании папок и диаграмм есть пояснения.
# [https://drive.google.com/open?id=0B7q8XbLVArz7a1AyWUprSWRSRzQ Доработка существующих систем].
# [https://drive.google.com/open?id=0B7q8XbLVArz7UXBwX1VScll3bVU Новый проект (автоматизация «с нуля»)].
# [https://drive.google.com/open?id=0B7q8XbLVArz7MUIyOTZsYWV3N28 Анализ request for information (RFI), предпроект, ведение бизнес-тем].
# [https://drive.google.com/open?id=0B7q8XbLVArz7UDdJWHA4a3BUVlk Реинжиниринг существующих систем].

== Заключение ==

Еще раз напомню, для чего все мы здесь сегодня собрались.

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

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

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

На проектах по доработке существующих и разработке новых систем время создания аналитических артефактов «по-новому» оказалось меньше времени их разработки «по-старому» на 25–40%.

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

Это продемонстрировано на диаграмме:

[[File:CUSTIS KPI_big.PNG||800px]]

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

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

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

== Полезная литература ==
# К. Вигерс. [http://www.ozon.ru/context/detail/id/1594986/ Разработка требований к программному обеспечению]. 2004.
# А. Левенчук. [http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking_2015.pdf Системноинженерное мышление]. 2015.
# I. Jacobson, I. Spence, K. Bittner. [https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2_0_jan11.pdf Use-Case 2.0: The Guide to Succeeding with Use Cases].
# [https://www.opengroup.org/archimate/2.1/ArchiMate2_intro.pdf An Introduction to the ArchiMate 2 Modeling Language].
# [http://pubs.opengroup.org/architecture/archimate3-doc/toc.html ArchiMate 3.0 Specification].
# М. Цепков. [https://www.slideshare.net/custisppt/agile-6999013?qid=3a13c0fc-1d0d-467a-b1cf-e8aa21f37244&v=&b=&from_search=2 Модель системы — архитектура для Agile-разработки] (презентация с выступления на Agile Days, 4–5 марта 2011).
# М. Цепков. [https://www.slideshare.net/custisppt/ddd-2011?qid=3a13c0fc-1d0d-467a-b1cf-e8aa21f37244&v=&b=&from_search=31 Domain Driven Design: модель вместо требования] (презентация с выступления на ЛАФ, 25–26 июня 2011).
# М. Цепков. [https://www.slideshare.net/custisppt/ss-75701759 Как выбрать для проекта практики проектирования и работы с требованиями] (презентация с выступления на Analyst Days, 21–22 апреля 2017).
# П. Музыка. [https://www.slideshare.net/custisppt/custis-enterprise-architect-t4 Практика применения Enterprise Architect и T4-шаблонов для разработки системы на Microsoft SQL Server] (презентация с выступления на Desktop UI & Business Applications, 11 апреля 2015).

[[Категория:Ольга Цыганова (Статьи)]]
[[Категория:Хабрахабр (Публикации)]]
[[Категория:2017 год (Статьи)]]
[[Категория:CustisWikiToLib]]

@@ Строка 48: / Строка 48: @@
 * пунктирные прямоугольники&nbsp;— типы диаграмм;
 * прямоугольники со&nbsp;сплошным контуром&nbsp;— папки в&nbsp;шаблоне проекта в&nbsp;Enterprise Architect, где&nbsp;содержатся диаграммы.
-[[File:CUSTIS_Модель концептов описаний_3.png]]
+[[Image:CUSTIS_Модель концептов описаний_3.png]]
 Подробно остановимся на&nbsp;основных концептах.
@@ Строка 135: / Строка 135: @@
 Это&nbsp;продемонстрировано на&nbsp;диаграмме:
-[[File:CUSTIS KPI_big.PNG||800px]]
+[[Image:CUSTIS KPI_big.PNG||800px]]
 Мы&nbsp;не&nbsp;ставили перед собой цель уменьшить трудозатраты на&nbsp;разработку артефактов&nbsp;— нам было важно, чтобы это&nbsp;время не&nbsp;увеличилось критично и&nbsp;методика прижилась в&nbsp;компании. Тем&nbsp;отраднее было видеть, что&nbsp;затраты ресурсов стали снижаться, а&nbsp;люди разделяли ценности наших изменений.

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

VeronikaLoseva: /* Заключение */

VeronikaLoseva: /* Полезная литература */