Время на чтение: 7 минут
Для кого: исполняющий роль Аналитика
Сложность: Junior

Предисловие

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

Артефакт - любой объект, имеющий отношение к решению, созданный в ходе работы по анализу.

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

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

Этап Анализа разработки ПО.

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

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

Дисциплина по инженерии требований подразделяется на:

• Разработка требований

• Управление требованиями

Нас интересует Разработка требований, которая также делится на четыре подраздела:

1. Выявление требований.

2. Анализ требований.

3. Документирование требований.

4. Проверка требований.

То, ради чего, я начал писать эту статью входит в подраздел Выявления требований.

Выявление требований осуществляется с помощью различных техник (коллективных и независимых).

Коллективные техники:

• Анкетирование

• Воркшоп

• Мозговой штурм

• Интервью

• Наблюдение

Независимые техники:

• Анализ ПО

• Анализ документов

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

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

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

Из системы нас интересуют ее абстракции, которые называются элементами (вам знакомые):

• Классы/Сущности/Таблицы

• Объекты/Свойства/Атрибуты/Состояния

• Процессы/Методы/Функции

• Условия/Исключения/События

• Слои/Сервисы

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

Анализ документов

Анализ документов применяется в следующих ситуациях:

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

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

• Автоматизация бизнес-процессов: При внедрении систем автоматизации анализ документов позволяет выявить необходимые изменения в бизнес-процессах.

• Внедрение готовых решений: При выборе готовых решений от других поставщиков, анализ документов позволяет понять функциональность и соответствие потребностям пользователей.

• Уточнение других техник выявления требований: Документы часто содержат важные входные данные, которые помогают уточнить информацию, полученную другими методами выявления требований.

Начало анализа

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

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

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

Находим элементы ПО в тексте

Классы/Сущности/Таблицы- существительное, используемое в начале предложения (чаще всего), либо следующее используемое существительное после основного.

Объекты/Свойства/Атрибуты/Состояния - существительные/прилагательные, явно зависящие от другого существительного (в смысловой зависимости).

Процессы/Методы/Функции - существительное + глагол, причастные/деепричастные обороты, глаголы, причастия, деепричастия, абстрактные существительные (например - операция)

Условия/Исключения/События - использование союза "Если"/"Когда", слова-указатели на условие (когда бы, при условии, если бы).

Выделяем элементы ПО цветом

Детально изучаем документ, при чтении выделяя текст по следующему принципу:

• Классы/Сущности/Таблицы- синий цвет

• Объекты/Свойства/Атрибуты/Состояния - оранжевый цвет

• Процессы/Методы/Функции - зеленый цвет

• Условия/Исключения/События - фиолетовый цвет

*В документе можно указать обозначения цветов для понимания читателями.

После анализа документа мы получаем артефакт - конспект.

Что делать с полученным артефактом

Информация из данного артефакта преобразуется в:

• Модель данных (например в нотации Crow`s foot) на основании выделенных Сущностей/Таблиц/Свойств/Атрибутов.

• Модель процесса (например в нотации BPMN, UML Sequence, UML Activity) на основании выделенных Сущностей/Процессов/Функций/Условий/Событий.

• Модель состояний (UML State Machine) на основании выделенных Свойств/Состояний/Условий.

• Модель классов/объектов (UML Class diagram, UML Object diagram), если вы используете объектно-ориентированный анализ, на основании выделенных Классов/Объектов/Методов.

• Вопросы к коллективной технике выявления требований - анкетирование/интервью/воркшоп/мозговой штурм.

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

Пример документа до анализа:

Пример документа после анализа:

Из представленного отрезка можно выделить:

Процессы/Методы/Функции:

• Торги,

• Установить продолжительность торгового дня для группы финансовых инструментов.

Классы/Сущности/Таблицы:

• Рабочий день,

• Торговый день,

• Предмет торгов,

• Продавец/Покупатель,

• Торговая сессия,

• Финансовый инструмент.

Объекты/Свойства/Атрибуты/Состояния:

• Торговый день группы финансовых инструментов,

• Торговый день по иностранным валютам,

• Основная торговая сессия,

• Дополнительная торговая сессия.

Условия/Исключения/События:

• Торги могут проводиться только в рабочий день и в течение торгового дня.

• У каждой группы финансовых инструментов отдельный торговый день.

• Если финансовый инструмент участвует в торгах с единственным покупателем или продавцом, торговый день для такого финансового инструмента может отличаться от установленного для всей группы финансовых инструментов, в которую входит представленный финансовый инструмент.

• Все иностранные валюты (за исключением Доллара США) торгуются в одну торговую сессию с продолжительностью в торговый день.

• Только для иностранной валюты Доллар США торговый день имеет отдельные торговые сессии.

Завершение

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

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

Анализ документов - это не просто процесс, это искусство. Это искусство понимания не только текста, но и того, как эта информация может быть воплощена в структурированные и понятные модели.

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

Спасибо за внимание, и желаю вам успехов в вашем аналитическом путешествии!

P.S. В статье много интересного, что можно раскрыть детальнее, чего бы тебе хотелось узнать?

Лукьянов Андрей

Ведущий системный аналитик (linkedin)