http://lib.custis.ru/index.php?title=%D0%9A%D0%B0%D0%BA_%D0%BC%D1%8B_%D1%83%D0%BD%D0%B8%D1%84%D0%B8%D1%86%D0%B8%D1%80%D1%83%D0%B5%D0%BC_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D1%83%D1%8E_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_CUSTIS&feed=atom&action=history
Как мы унифицируем аналитическую деятельность в CUSTIS - История изменений
2024-03-28T20:23:42Z
История изменений этой страницы в вики
MediaWiki 1.26.4
http://lib.custis.ru/index.php?title=%D0%9A%D0%B0%D0%BA_%D0%BC%D1%8B_%D1%83%D0%BD%D0%B8%D1%84%D0%B8%D1%86%D0%B8%D1%80%D1%83%D0%B5%D0%BC_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D1%83%D1%8E_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_CUSTIS&diff=43940&oldid=prev
VeronikaLoseva: /* Заключение */
2017-07-12T07:46:28Z
<p><span dir="auto"><span class="autocomment">Заключение</span></span></p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='ru'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Предыдущая</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Версия 07:46, 12 июля 2017</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l48" >Строка 48:</td>
<td colspan="2" class="diff-lineno">Строка 48:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* пунктирные прямоугольники&nbsp;— типы диаграмм;</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* пунктирные прямоугольники&nbsp;— типы диаграмм;</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* прямоугольники со&nbsp;сплошным контуром&nbsp;— папки в&nbsp;шаблоне проекта в&nbsp;Enterprise Architect, где&nbsp;содержатся диаграммы.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* прямоугольники со&nbsp;сплошным контуром&nbsp;— папки в&nbsp;шаблоне проекта в&nbsp;Enterprise Architect, где&nbsp;содержатся диаграммы.</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>[[<del class="diffchange diffchange-inline">File</del>:CUSTIS_Модель концептов описаний_3.png]]</div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>[[<ins class="diffchange diffchange-inline">Image</ins>:CUSTIS_Модель концептов описаний_3.png]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Подробно остановимся на&nbsp;основных концептах.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Подробно остановимся на&nbsp;основных концептах.</div></td></tr>
<tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l135" >Строка 135:</td>
<td colspan="2" class="diff-lineno">Строка 135:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Это&nbsp;продемонстрировано на&nbsp;диаграмме:</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Это&nbsp;продемонстрировано на&nbsp;диаграмме:</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>[[<del class="diffchange diffchange-inline">File</del>:CUSTIS KPI_big.PNG||800px]]</div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>[[<ins class="diffchange diffchange-inline">Image</ins>:CUSTIS KPI_big.PNG||800px]]</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Мы&nbsp;не&nbsp;ставили перед собой цель уменьшить трудозатраты на&nbsp;разработку артефактов&nbsp;— нам было важно, чтобы это&nbsp;время не&nbsp;увеличилось критично и&nbsp;методика прижилась в&nbsp;компании. Тем&nbsp;отраднее было видеть, что&nbsp;затраты ресурсов стали снижаться, а&nbsp;люди разделяли ценности наших изменений.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Мы&nbsp;не&nbsp;ставили перед собой цель уменьшить трудозатраты на&nbsp;разработку артефактов&nbsp;— нам было важно, чтобы это&nbsp;время не&nbsp;увеличилось критично и&nbsp;методика прижилась в&nbsp;компании. Тем&nbsp;отраднее было видеть, что&nbsp;затраты ресурсов стали снижаться, а&nbsp;люди разделяли ценности наших изменений.</div></td></tr>
</table>
VeronikaLoseva
http://lib.custis.ru/index.php?title=%D0%9A%D0%B0%D0%BA_%D0%BC%D1%8B_%D1%83%D0%BD%D0%B8%D1%84%D0%B8%D1%86%D0%B8%D1%80%D1%83%D0%B5%D0%BC_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D1%83%D1%8E_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_CUSTIS&diff=43932&oldid=prev
VeronikaLoseva: /* Полезная литература */
2017-07-11T14:27:51Z
<p><span dir="auto"><span class="autocomment">Полезная литература</span></span></p>
<p><b>Новая страница</b></p><div>''<blockquote>В&nbsp;нашем корпоративном блоге на&nbsp;портале [https://habrahabr.ru/top/ «Хабрахабр»] появился новый пост: [[:Категория:Ольга Цыганова (Статьи)|Ольга Цыганова]], наш ведущий системный аналитик, поделилась опытом унификации деятельности аналитиков в&nbsp;CUSTIS. Как&nbsp;изменить неповоротливую систему устаревших аналитических практик? Что&nbsp;позволяет снизить трудозатраты аналитиков и&nbsp;рационально использовать их&nbsp;артефакты? Об&nbsp;этом&nbsp;— в&nbsp;статье [https://habrahabr.ru/company/custis/blog/332018/ «Как&nbsp;мы&nbsp;унифицируем аналитическую деятельность в&nbsp;CUSTIS»] на&nbsp;сайте издания.</blockquote><br />
''<br />
Мы&nbsp;писали в&nbsp;блоге о&nbsp;технологиях в&nbsp;привычном айтишному миру понимании&nbsp;— о&nbsp;наших лучших практиках в&nbsp;разработке информационных систем. Сегодняшний пост посвящен технологиям другого толка&nbsp;— управленческим: мы&nbsp;поговорим об&nbsp;унификации аналитической деятельности в&nbsp;CUSTIS. Эта&nbsp;история о&nbsp;том, как&nbsp;изменить огромную и&nbsp;стабильную систему сложившихся с&nbsp;годами практик и&nbsp;направить ее&nbsp;навстречу проектам развития.<br />
<br />
Когда наша компания занималась в&nbsp;основном заказной разработкой и&nbsp;создавала уникальные продукты, над&nbsp;проектом для&nbsp;каждого клиента трудилась одна команда на&nbsp;всем жизненном цикле системы.<br />
<br />
Такой подход хорошо отвечал потребностям заказчиков, поскольку аналитик:<br />
<br />
* занимался только одним проектом и&nbsp;глубоко разбирался в&nbsp;деятельности конкретного заказчика;<br />
* был прекрасно сработан с&nbsp;архитекторами, разработчиками и&nbsp;тестировщиками в&nbsp;своей проектной команде;<br />
* применял для&nbsp;написания постановок привычные инструменты, например Wiki и&nbsp;Bugzilla.<br />
<br />
Эта&nbsp;модель стала неэффективной, когда мы&nbsp;начали переходить к&nbsp;созданию тиражируемых решений и&nbsp;работать одновременно над&nbsp;б'''о'''льшим количеством проектов. Нам&nbsp;потребовалось быстро ротировать аналитиков между проектами и&nbsp;повторно использовать их&nbsp;артефакты, а&nbsp;из-за&nbsp;того, что&nbsp;один описывал действия пользователя в&nbsp;системе Visio, а&nbsp;другой&nbsp;— в&nbsp;Archi, возникали дублирование описаний и&nbsp;неразбериха с&nbsp;нотациями.<br />
<br />
Мы&nbsp;поставили перед собой задачу выбрать и&nbsp;внедрить для&nbsp;всех проектных команд одну методику или&nbsp;набор методик, которые будут отвечать новым бизнес-задачам. В&nbsp;посте мы&nbsp;расскажем, как&nbsp;разрабатываем эту&nbsp;методическую основу.<br />
== Начинаем работу ==<br />
Мы&nbsp;начали с&nbsp;того, что&nbsp;выделили три трека, в&nbsp;рамках которых будем проводить унификацию:<br />
# '''Методический трек.''' Создаем методическую основу для&nbsp;проведения работ на&nbsp;разных проектах. По&nbsp;итогам испытаний и&nbsp;внедрения вносим в&nbsp;результаты этого трека корректировки.<br />
# '''Испытания.''' Проверяем разработанные методы на&nbsp;реальных проектах. Собрав качественные и&nbsp;количественные показатели, возвращаемся к&nbsp;методическому треку и&nbsp;дорабатываем методики.<br />
# '''Внедрение.''' Принимаем успешно апробированные наработки и&nbsp;делаем их&nbsp;обязательными для&nbsp;всех аналитиков. Это&nbsp;этап, когда методика становится официальной практикой для&nbsp;всей компании. <br />
Затем мы&nbsp;проанализировали аналитическую деятельность в&nbsp;разных проектных командах и&nbsp;определили, что&nbsp;необходимо унифицировать:<br />
* типы проектов в&nbsp;компании;<br />
* концепты аналитической деятельности (метауровень);<br />
* инструменты работы аналитика;<br />
* роли, которые участвуют в&nbsp;аналитической деятельности;<br />
* описание работы людей, выступающих в&nbsp;этих ролях: <br />
** входной артефакт;<br />
** выходной артефакт;<br />
** технология создания выходного артефакта;<br />
* шаблоны артефактов аналитической деятельности;<br />
* перечень обязательных и&nbsp;необязательных аналитических артефактов для&nbsp;различных типов проектов;<br />
* методику обучения аналитиков.<br />
В&nbsp;следующих разделах подробнее расскажем о&nbsp;результатах методического трека работ.<br />
== Определяем типы проектов ==<br />
Мы&nbsp;выделили четыре типа проектов в&nbsp;компании, на&nbsp;которых нам важно уметь перемещать аналитиков:<br />
<br />
# '''Доработка существующих систем'''&nbsp;— корректировки, выделяемые в&nbsp;отдельные проекты. Трудозатраты: от&nbsp;200 до&nbsp;1500 человеко-часов. Длительность: до&nbsp;полугода. К&nbsp;таким проектам относится, например, разработка нескольких визуальных форм с&nbsp;отчетами, алгоритмов их&nbsp;заполнения, нескольких таблиц базы данных, фильтрации, выгрузки данных из&nbsp;отчетов в&nbsp;xlsx, pdf.<br />
# '''Новый проект (автоматизация «с нуля»)'''&nbsp;— разработка автоматизированных систем, когда у&nbsp;клиента нет&nbsp;«предыдущего» решения либо нужно полностью заменить существующую систему. Трудозатраты: от&nbsp;1500 до&nbsp;10&nbsp;000 человеко-часов. Длительность: от&nbsp;полугода до&nbsp;года.<br />
# '''Анализ request for information (RFI), предпроект, ведение бизнес-тем'''&nbsp;— бизнес-анализ процессов заказчиков. Реализация таких проектов может привести к&nbsp;запуску проектов автоматизации с&nbsp;нуля либо доработок существующих систем.<br />
# '''Реинжиниринг существующих систем'''&nbsp;— полная переработка имеющейся системы. <br />
<br />
Далее мы&nbsp;приступили к&nbsp;выделению тех&nbsp;понятий, в&nbsp;которых аналитики будут описывать создаваемые системы.<br />
== Описываем концепты аналитической деятельности ==<br />
На&nbsp;UML-диаграмме (см.&nbsp;ниже) показаны концепты аналитической деятельности, которые мы&nbsp;выделили. Используя их, аналитики создают описание IT-системы и&nbsp;общаются.<br />
<br />
Схема состоит из&nbsp;следующих элементов:<br />
* голубые прямоугольники&nbsp;— концепты;<br />
* пунктирные прямоугольники&nbsp;— типы диаграмм;<br />
* прямоугольники со&nbsp;сплошным контуром&nbsp;— папки в&nbsp;шаблоне проекта в&nbsp;Enterprise Architect, где&nbsp;содержатся диаграммы.<br />
[[File:CUSTIS_Модель концептов описаний_3.png]]<br />
<br />
Подробно остановимся на&nbsp;основных концептах.<br />
<br />
* Процесс&nbsp;— бизнес-процесс заказчика. Он&nbsp;может включать как&nbsp;автоматизируемые, так&nbsp;и&nbsp;не&nbsp;автоматизируемые функции в&nbsp;рамках разрабатываемой системы.<br />
: Описывается в&nbsp;нотации BPMN. Объекты на&nbsp;такой диаграмме могут быть типа Business Process&nbsp;— для&nbsp;диаграммы верхнего уровня и&nbsp;Activity&nbsp;— для&nbsp;диаграммы, описывающей процесс до&nbsp;элементарных операций.<br />
: Описание должно быть шире, чем автоматизируемый процесс, чтобы при&nbsp;чтении диаграммы был&nbsp;понятен контекст.<br />
* Роль&nbsp;— роль пользователя в&nbsp;системе или&nbsp;организационная единица.<br />
: Роль, исполняющая процесс или&nbsp;операцию, визуализируется на&nbsp;BPMN-диаграмме с&nbsp;помощью Pool и&nbsp;Lane, а&nbsp;на&nbsp;диаграмме Use Case&nbsp;— с&nbsp;помощью Actor.<br />
* Операции&nbsp;— операции, выполняемые в&nbsp;рамках локального процесса (локальные операции), или&nbsp;используемые в&nbsp;других процессах (глобальные). <br />
: Создаются на&nbsp;BPMN-диаграммах элементом Activity. <br />
* Автоматизируемая операция&nbsp;— элементарная операция, неделимая в&nbsp;рамках разрабатываемой системы.<br />
: На&nbsp;BPMN-диаграммах обозначается элементом типа Activity. Для&nbsp;него нужно устанавливать тип выполнения операции Manual, Script, User. Manual означает, что&nbsp;операция выполняется пользователем в&nbsp;информационной системе, Script&nbsp;— операция выполняется внутри системы, User&nbsp;— пользователи выполняют действия вручную. При&nbsp;описании бизнес-процессов для&nbsp;функций первых двух типов необходимо создавать требования для&nbsp;их&nbsp;выполнения. <br />
* Информационный ландшафт&nbsp;— все&nbsp;системы и&nbsp;подсистемы, которые задействованы в&nbsp;рамках бизнес-процесса, и&nbsp;передаваемые между ними данные. <br />
: При&nbsp;описании используется диаграмма потоков данных.<br />
* Объект данных&nbsp;— класс объектов реального мира.<br />
: Создается на&nbsp;диаграммах классов в&nbsp;нотации UML.<br />
* Автоматизируемая задача&nbsp;— задача, сформулированная заказчиком либо аналитиком.<br />
: Отображается элементом Feature. Он&nbsp;присутствует на&nbsp;BPMN- и&nbsp;Use Case-диаграммах. На&nbsp;BPMN-диаграммах он&nbsp;связывается с&nbsp;операциями, на&nbsp;Use Case&nbsp;—с&nbsp;элементами типа Use Case. Таким образом получается связь между бизнес-моделью и&nbsp;автоматизируемыми задачами. <br />
* Функция&nbsp;— описание поведения системы, когда она&nbsp;взаимодействует с&nbsp;кем-то или&nbsp;чем-то. Описание может совпадать с&nbsp;тем, как&nbsp;сформулирована автоматизируемая задача, или&nbsp;обобщать несколько задач. <br />
: Отображается на&nbsp;Use Case-диаграммах элементами типа Use Case. Они&nbsp;состоят из&nbsp;шагов&nbsp;— атомарных неделимых действий. К&nbsp;функциям привязываются элементы типа Requirement.<br />
* Требование&nbsp;— условие, которое должно быть удовлетворено.<br />
: Отображается элементом Requirement. Может присутствовать на&nbsp;диаграммах трех типов: BPMN, Use Case, диаграммах требований.<br />
: На&nbsp;диаграмме требований можно создавать иерархию требований, задавать в&nbsp;объектах название и&nbsp;описание. Для&nbsp;приоритизации требований устанавливается модальность: может, должен, обязан.<br />
* Таблица&nbsp;— таблица базы данных.<br />
: На&nbsp;ER-диаграммах отображаются не&nbsp;только таблицы, но&nbsp;и&nbsp;связи между ними. Несколько таблиц могут быть связаны с&nbsp;несколькими классами реализации.<br />
* Класс&nbsp;— классы объектов реализации, которые создает разработчик при&nbsp;проектировании.<br />
: Классы реализации отображаются на&nbsp;диаграмме классов в&nbsp;нотации UML.<br />
* GUI&nbsp;— описание пользовательского интерфейса.<br />
: Создается на&nbsp;диаграмме типа Dialog Wireframe Diagram. Обязательные элементы диаграммы: Use Case и&nbsp;макет экранной формы, факультативные: компонент, класс, таблица.<br />
* Компонент&nbsp;— это&nbsp;часть системы, выполняющая какую-то функцию.<br />
: Компонентную диаграмму создают на&nbsp;этапе проектирования системы архитекторы или&nbsp;разработчики, чтобы отразить ее&nbsp;состав.<br />
Чтобы использовать на&nbsp;практике концепты, нужно выбрать единый для&nbsp;всех инструмент моделирования. О&nbsp;нем&nbsp;— в&nbsp;следующем разделе.<br />
<br />
== Выбираем аналитические инструменты ==<br />
<br />
О&nbsp;достоинствах и&nbsp;недостатках инструментов, обеспечивающих аналитическую деятельность, можно спорить бесконечно. Например, кому-то нравится развивать мелкую моторику на&nbsp;примере [https://www.metasonic.de/en/touch вот таких решений] для&nbsp;моделирования бизнес-процессов.<br />
<br />
Наша компания много лет использовала гибкие методики разработки DDD (Domain Driven Design) [7] и&nbsp;инструменты Wiki [6]. Мы&nbsp;опирались на&nbsp;этот опыт и&nbsp;искали новые рыночные методики и&nbsp;инструменты аналитической деятельности.<br />
<br />
Мы&nbsp;выписали возможные кейсы использования инструмента, опробовали их&nbsp;на&nbsp;нескольких проектах [9], пообщались с&nbsp;коллегами из&nbsp;других компаний и&nbsp;в&nbsp;итоге остановили выбор на&nbsp;[http://www.sparxsystems.com/products/ea/index.html Enterprise Architect].<br />
<br />
Для&nbsp;нас&nbsp;были критичными такие параметры, как:<br />
* поддержка нотации BPMN и&nbsp;UML, ArchiMate 3.0;<br />
* ведение версионности проектов и&nbsp;диаграмм;<br />
* функции экспорта и&nbsp;импорта моделей;<br />
* выгрузки документации на&nbsp;основе диаграмм без&nbsp;привлечения разработчиков для&nbsp;создания шаблонов выгрузок документов;<br />
* возможность коллективно работать с&nbsp;диаграммами;<br />
* низкая стоимость и&nbsp;гибкая лицензионная политика;<br />
* наличие действующего сообщества пользователей и&nbsp;разработчиков.<br />
<br />
То, что мы&nbsp;предпочли этот инструмент, совсем не&nbsp;значит, что&nbsp;он&nbsp;подойдет и&nbsp;вам. При&nbsp;выборе своего инструмента постарайтесь собрать все&nbsp;ограничения и&nbsp;требования к&nbsp;нему, рассмотреть как&nbsp;можно больше сценариев того, как&nbsp;его&nbsp;используют ваши коллеги, и&nbsp;определить, насколько хорошо аналитики, разработчики, тестировщики и&nbsp;инженеры знают стандарты и&nbsp;нотации. Тогда в&nbsp;краткосрочной перспективе вам&nbsp;не&nbsp;придется переходить на&nbsp;новый инструмент.<br />
<br />
Чтобы аналитик каждый раз не&nbsp;перечислял артефакты, которые нужно создать, мы&nbsp;разработали шаблон проекта в&nbsp;Enterprise Architect. Следующий раздел про&nbsp;него.<br />
<br />
== Разрабатываем шаблон проекта в Enterprise Architect ==<br />
<br />
Когда мы&nbsp;создавали шаблон проекта, мы&nbsp;руководствовались потребностями разработчиков, тестировщиков, инженеров и&nbsp;заказчиков, а&nbsp;также распространенными в&nbsp;IT-отрасли стандартами и&nbsp;нотациями.<br />
<br />
Существует несколько вариантов описаний требований. Узнать о&nbsp;них&nbsp;подробнее вы&nbsp;можете из&nbsp;материалов, указанных в&nbsp;списке литературы в&nbsp;конце статьи [1–4]. Мы&nbsp;постарались взять только варианты, необходимые для&nbsp;решения наших задач, и&nbsp;оставили те&nbsp;артефакты, которые используют в&nbsp;работе два и&nbsp;более человек в&nbsp;проекте с&nbsp;учетом жизненного цикла разработки системы.<br />
<br />
В&nbsp;шаблоне проекта мы&nbsp;зафиксировали структуру папок и&nbsp;диаграмм в&nbsp;них, а&nbsp;также технологию наполнения диаграмм для&nbsp;различных видов проектов. Еще&nbsp;мы&nbsp;приводили не&nbsp;только перечень нотаций, но&nbsp;и&nbsp;их&nbsp;необходимые модификации, например, для&nbsp;выгрузки документации по&nbsp;ГОСТ, маппинга объектов одного уровня описания с&nbsp;другим.<br />
<br />
Набор артефактов в&nbsp;шаблоне меняется в&nbsp;зависимости от&nbsp;типа проекта.<br />
<br />
Желающие могут пройти по&nbsp;ссылкам ниже и&nbsp;посмотреть, что&nbsp;это&nbsp;за&nbsp;артефакты. В&nbsp;описании папок и&nbsp;диаграмм есть пояснения.<br />
# [https://drive.google.com/open?id=0B7q8XbLVArz7a1AyWUprSWRSRzQ Доработка существующих систем].<br />
# [https://drive.google.com/open?id=0B7q8XbLVArz7UXBwX1VScll3bVU Новый проект (автоматизация «с нуля»)]. <br />
# [https://drive.google.com/open?id=0B7q8XbLVArz7MUIyOTZsYWV3N28 Анализ request for information (RFI), предпроект, ведение бизнес-тем]. <br />
# [https://drive.google.com/open?id=0B7q8XbLVArz7UDdJWHA4a3BUVlk Реинжиниринг существующих систем]. <br />
<br />
== Заключение ==<br />
<br />
Еще раз напомню, для чего все&nbsp;мы&nbsp;здесь сегодня собрались.<br />
<br />
Представленный методический трек&nbsp;— часть большой работы по&nbsp;унификации аналитической деятельности в&nbsp;компании CUSTIS. На&nbsp;момент написания статьи мы&nbsp;уже&nbsp;испытали методику на&nbsp;некоторых типах проектов.<br />
<br />
На&nbsp;проектах типа RFI мы&nbsp;увидели несомненную пользу данной методики: она&nbsp;позволила повторно использовать функциональную и&nbsp;компонентную декомпозицию работ, а&nbsp;также методику оценки трудозатрат.<br />
<br />
Впервые работая по&nbsp;предложенной схеме, мы&nbsp;создавали функции, компоненты системы и&nbsp;другие необходимые элементы и&nbsp;оценивали трудозатраты. При&nbsp;получении аналогичных RFI мы&nbsp;копировали уже&nbsp;созданные диаграммы и&nbsp;при&nbsp;необходимости делали небольшие корректировки, например изменяли состав функций и&nbsp;(или)&nbsp;компонент. Таким образом, нам удалось повторно использовать созданные артефакты и&nbsp;минимизировать время на&nbsp;оценку трудозатрат по&nbsp;аналогичным RFI.<br />
<br />
На&nbsp;проектах по&nbsp;доработке существующих и&nbsp;разработке новых систем время создания аналитических артефактов «по-новому» оказалось меньше времени их&nbsp;разработки «по-старому» на&nbsp;25–40%.<br />
<br />
Мы&nbsp;сравнивали время, затраченное на&nbsp;разработку артефакта в&nbsp;новой методике, и&nbsp;экспертную оценку временных затрат каждого из&nbsp;работающих в&nbsp;проекте аналитиков на&nbsp;разработку артефакта «по-старому». Аналитик, впервые работавший по&nbsp;новым правилам, тратил больше времени на&nbsp;освоение методики, лучших практик и&nbsp;примеров, консультировался с&nbsp;более опытными коллегами, но&nbsp;после двух-трех итераций время на&nbsp;разработку диаграмм существенно уменьшалось.<br />
<br />
Это&nbsp;продемонстрировано на&nbsp;диаграмме:<br />
<br />
[[File:CUSTIS KPI_big.PNG||800px]]<br />
<br />
Мы&nbsp;не&nbsp;ставили перед собой цель уменьшить трудозатраты на&nbsp;разработку артефактов&nbsp;— нам было важно, чтобы это&nbsp;время не&nbsp;увеличилось критично и&nbsp;методика прижилась в&nbsp;компании. Тем&nbsp;отраднее было видеть, что&nbsp;затраты ресурсов стали снижаться, а&nbsp;люди разделяли ценности наших изменений.<br />
<br />
Актуальной для&nbsp;нас&nbsp;остается задача обеспечить перемещение аналитиков внутри компании по&nbsp;подразделениям, которые работают с&nbsp;заказчиками из&nbsp;разных предметных областей. Мы&nbsp;поделимся успехами этой части, когда наберем достаточно наглядных примеров, на&nbsp;основе которых с&nbsp;уверенностью можно сказать, что&nbsp;трек внедрения начал приносить первые существенные результаты.<br />
<br />
В&nbsp;следующих статьях мы&nbsp;также расскажем о&nbsp;том, как&nbsp;проверяем методологию: на&nbsp;какие параметры смотрим, чтобы понять, подходит ли&nbsp;выбранный метод к&nbsp;нашей работе&nbsp;— и&nbsp;поделимся опытом внедрения работы «по-новому» в&nbsp;действующих проектах.<br />
<br />
== Полезная литература ==<br />
# К.&nbsp;Вигерс. [http://www.ozon.ru/context/detail/id/1594986/ Разработка требований к программному обеспечению]. 2004.<br />
# А.&nbsp;Левенчук. [http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking_2015.pdf Системноинженерное мышление]. 2015.<br />
# I.&nbsp;Jacobson, I.&nbsp;Spence, K.&nbsp;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]. <br />
# [https://www.opengroup.org/archimate/2.1/ArchiMate2_intro.pdf An Introduction to the ArchiMate 2 Modeling Language]. <br />
# [http://pubs.opengroup.org/architecture/archimate3-doc/toc.html ArchiMate 3.0 Specification]. <br />
# М.&nbsp;Цепков. [https://www.slideshare.net/custisppt/agile-6999013?qid=3a13c0fc-1d0d-467a-b1cf-e8aa21f37244&v=&b=&from_search=2 Модель системы — архитектура для Agile-разработки] (презентация с&nbsp;выступления на Agile Days, 4–5 марта 2011).<br />
# М.&nbsp;Цепков. [https://www.slideshare.net/custisppt/ddd-2011?qid=3a13c0fc-1d0d-467a-b1cf-e8aa21f37244&v=&b=&from_search=31 Domain Driven Design: модель вместо требования] (презентация с&nbsp;выступления на&nbsp;ЛАФ, 25–26 июня 2011).<br />
# М.&nbsp;Цепков. [https://www.slideshare.net/custisppt/ss-75701759 Как выбрать для проекта практики проектирования и работы с требованиями] (презентация с&nbsp;выступления на&nbsp;Analyst Days, 21–22 апреля 2017).<br />
# П.&nbsp;Музыка. [https://www.slideshare.net/custisppt/custis-enterprise-architect-t4 Практика применения Enterprise Architect и T4-шаблонов для разработки системы на Microsoft SQL Server] (презентация с&nbsp;выступления на&nbsp;Desktop UI &&nbsp;Business Applications, 11 апреля 2015). <br />
<br />
[[Категория:Ольга Цыганова (Статьи)]]<br />
[[Категория:Хабрахабр (Публикации)]]<br />
[[Категория:2017 год (Статьи)]]<br />
[[Категория:CustisWikiToLib]]</div>
VeronikaLoseva