Начало

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

Потом появился UML (версия 0.8), и я убедился, что программное обеспечение не только нужно, но и возможно и полезно документировать!

И, наконец, приобщение к RUP[1] "сделало" из меня нормального специалиста, каковым я, из природного нахальства, себя считаю.

Тому больше двадцати лет.

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

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

Толчком послужило активное чтение форума Сообщества системных аналитиков (http://www.uml2.ru). Не могу сказать, что все дискуссии на форуме продуктивны. Иногда жестокие битвы возникают на пустом месте. Но, в то же время, иногда поднимаются проблемы весьма актуальные, наталкивающие на размышления о роли аналитика в проекте разработки ПО, об уровне детализации и о степени формализма моделей, о документировании требований и т.д.

Такие проблемы не имеют однозначного решения. Всегда вспоминаются первые строки романа А.Н.Толстого "Анна Каренина"[2]. Действительно, я многократно убеждался, что почти все компании (группы разработчиков) имеют одинаковые проблемы[3]. Но способы решения этих проблем в каждой организации свои. Не буду здесь перечислять факторы, влияющие на выборы решений. Тем более, для различных проблем они разные!

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

Триал-версии инструментов, которые я использую (IBM Rational Software Architect (RSA) для моделирования, интегрированные с ним RequisitePro для управления требованиями и SoDA для создания шаблонов и генерации отчетов) можно "списать" и получить временные ключи на сайте IBM. А дальше уж сами решайте, надо это Вам или вашей организации, или нет!

Значит ли это, что если Вы используете другие инструменты, то Вы не сможете (при желании) воспроизвести приводимые примеры. Полагаю, что нет. Во-первых, модели RSA будут дублироваться в виде публикаций в формате html, содержащих всю информацию исходных моделей. Во-вторых, UML и в Африке UML. Отличия в реализации могут помешать интегрироваться с RequisitePro, но, м.б. позволят интегрироваться с инструментом, поддерживающим аналогичные функции. Конечно, не будут работать шаблоны SoDA. Но если Вы используете нормальный генератор отчетов, Вы сможете "нарисовать" свой шаблон. Т.е., если вам понравятся сами идеи, наверное, их можно реализовывать и другими инструментами.

Я ничего не говорю о количестве выпусков, частоте их появления. Все будет зависеть от активности читателей. То же относится и к тематике. Будут пожелания, возражения и т.д. – будут ответные статьи.

Спасибо за Ваше терпение.

Л. Новиков

Что влияет на эффективность аналитика[4]

Мой опыт свидетельствует, что эффективность аналитика (в проекте или в небольшой компании) зависит от двух ключевых факторов:

1.      Адекватность определения роли аналитика в текущей ситуации (входит в компетенцию руководства проекта или компании)

2.      Степень соответствия навыков назначенного аналитика этой роли

Другие факторы являются дополнительными, а возникающие проблемы – следствия двух перечисленных[5].

Определение роли аналитика

"В большом" роль аналитика[6] в разработке ПО сегодня сомнений не вызывает: это роль, которая отвечает за определение требований к ПО на основе запросов заинтересованных лиц. На рисунке внизу показаны ответственности системного аналитика в соответствии с RUP:

В жизни все намного сложнее!

В короткой, но емкой статье "Роль аналитика в разработке[7]" автор обратил внимание на то, что разные специалисты по-разному интерпретируют определение роли "Системный аналитик" и, часто, считая свою интерпретацию единственно верной, даже не предполагают, что возможны другие.

Автор статьи устанавливает две крайние позиции для роли аналитика. Условно назову их "Аналитик – спецификатор требований" и "Аналитик – представитель разработчика"[8].

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

Идеальный аналитик, с моей точки зрения

Предусловия

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

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

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

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

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

Обязанности

• Сбор требований к ПО

Аналитик должен проанализировать проблемы и потребности заказчика, сформулировать способы разрешения проблем, требования и ограничения к ПО.

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

Требования должны быть согласованы с заказчиком и разработчиками.

• Консультирование разработчиков относительно требований к ПО

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

При необходимости изменения формулировок требований аналитик согласует изменения с заказчиком и разработчиками.

• Проверка выполненных работ на соответствие требованиям

Аналитик принимает от разработчиков выполненную систему или ее части и проверяет на соответствие требованиям.

Аналитик может потребовать от разработчиков внесения изменений в систему в случае несоответствия требованиям.

• Представление заказчику разработанной системы

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

• Обучение заказчиков работе с системой (при необходимости)

Навыки

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

Пунктуальность. Грамотность. Вдумчивость. Умение возражать. Способность открыто заявить о своих ошибках. Предложение альтернативных вариантов решений. И т.д.
Нужно показать заказчику, что Вам интересны его проблемы, и Вы хотите их решить.

• Аналитик должен быть экспертом в идентификации и понимании проблем.

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

• Системный аналитик должен уметь документировать результаты своих исследований.

Номенклатура и форма документов должна соответствовать потребностям, как заказчика, так и разработчиков. Возможно даже создание документации, рассчитанной на определенный читательский адрес: для заказчика и для разработчиков[9].

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

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

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

Как экономить ресурсы?

Продуктами работы системного аналитика являются документы требований. (Диаграммы UML – это документы в графической форме.)

Многие уважаемые гуру во множестве книжек предостерегают нас от увлечения рисованием диаграмм, их "вылизыванием".

"Диаграммы предназначены для обсуждения решений, – пишут они. – Поддержка диаграмм в актуальном состоянии – это бесполезная трата ресурсов".

Как быть бедному системному аналитику?

Традиционно вопрос решается следующим образом:

1.      По результатам встреч с заказчиком системный аналитик рисует и обсуждает с заказчиком и разработчиками диаграммы прецедентов (UC) и деятельности (Activity)

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

3.      (Не обязательно) Разработанные документы требований импортируются в инструмент управления требованиями (например, RequisitePro).

4.      Далее управление требованиями выполняется с использованием документов или инструмента управления требованиями.

5.      Модель требований, уже не актуальная после первого изменения требования, тихо умирает.

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

"Модель первична, документ – вторичен"

Идея не новая, вытекает из концепции MDA.

Действительно, генерация отчета – это преобразование модели в текст по специально установленным правилам.

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

Итак, для реализации идеи "Модель первична, документ – вторичен" требуется:

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

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

Метаструктура модели

Под термином "метаструктура модели" я имею ввиду описание правил структурирования модели и соответствующие "строительные блоки".

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

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

Я не пользуюсь стандартными шаблонами RUP, а создаю пустые модели. Затем я импортирую из отдельного хранилища строительные блоки, построенные в соответствии с указаниями по моделированию, и использую эти блоки при моделировании. Моя модель имеет "правильную" структуру и совместима с шаблонами отчетов.

Пример шаблона в виде html-публикации модели (архив RAR) Вы можете скачать в разделе "Каталог файлов" этого сайта. Не забудьте зарегистрироваться!