Получи максимум от анализа документов

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

Предисловие

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

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

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

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

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

841a71c4121fe2effda91810012112b8.png

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

Инженерия требований (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. В статье много интересного, что можно раскрыть детальнее, чего бы тебе хотелось узнать?

5822462b940d1f849398c920f8a9f517.jpgЛукьянов Андрей

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

© Habrahabr.ru