Получи максимум от анализа документов
Время на чтение: 7 минут
Для кого: исполняющий роль Аналитика
Сложность: Junior
Предисловие
Начинаю серию статей, посвященных задачам аналитика на различных этапах создания программного обеспечения (ПО). В ходе наших бесед, мы рассмотрим, какие конкретные артефакты возникают после завершения каждого этапа, а также как правильно составлять эти артефакты.
Артефакт — любой объект, имеющий отношение к решению, созданный в ходе работы по анализу.
В данной статье я поделюсь своей личной техникой анализа документации, которая позволяет мне быстро создавать структурированные конспекты. Полученную из них информацию можно легко преобразовать в модели процессов, данных, классов или объектов. Кроме того, на основе конспекта можно подготовить предметные вопросы для интервью или анкетирования.
Чтобы полностью погрузиться в тему, давайте вернемся к этапам создания ПО и установим нашу точку координат — Анализ.
Этап Анализа разработки ПО.
На этом важном этапе разработки ПО, аналитик выступает в роли активного участника процесса, фокусируясь на инженерии требований.
Инженерия требований (Requirements Engineering) — это общеинженерная техническая дисциплина, которая отвечает за процессы разработки, документирования и поддержания требований. Эта дисциплина входит как в системную инженерию так и в программную инженерию.
Дисциплина по инженерии требований подразделяется на:
Нас интересует Разработка требований, которая также делится на четыре подраздела:
Выявление требований.
Анализ требований.
Документирование требований.
Проверка требований.
То, ради чего, я начал писать эту статью входит в подраздел Выявления требований.
Выявление требований осуществляется с помощью различных техник (коллективных и независимых).
Коллективные техники:
Независимые техники:
Да, вот таков этот этап анализа, который определяет будущее ПО, чем детальнее будет проработаны требования, тем качественнее получится ПО.
И последняя вводная информация, которую я обязан упомянуть, чтобы было понимание — для чего я выделяю текст документов синим/фиолетовым/оранжевым.
Система (System) — это совокупность программного, аппаратного обеспечения и других компонентов, взаимодействующих между собой для достижения одной или нескольких целей.
Из системы нас интересуют ее абстракции, которые называются элементами (вам знакомые):
Классы/Сущности/Таблицы
Объекты/Свойства/Атрибуты/Состояния
Процессы/Методы/Функции
Условия/Исключения/События
Слои/Сервисы
Такой подход не только упрощает восприятие информации, но и облегчает последующие этапы анализа, позволяя лучше понять структуру и взаимосвязи между различными элементами системы.
Анализ документов
Анализ документов применяется в следующих ситуациях:
Замена текущей системы: При обновлении системы анализ документации может раскрыть ценную информацию, необходимую для успешной миграции.
Изучение стандартов и требований: При рассмотрении корпоративных и отраслевых стандартов, а также требований законодательства, анализ документов становится ключевым этапом.
Автоматизация бизнес-процессов: При внедрении систем автоматизации анализ документов позволяет выявить необходимые изменения в бизнес-процессах.
Внедрение готовых решений: При выборе готовых решений от других поставщиков, анализ документов позволяет понять функциональность и соответствие потребностям пользователей.
Уточнение других техник выявления требований: Документы часто содержат важные входные данные, которые помогают уточнить информацию, полученную другими методами выявления требований.
Начало анализа
Убедиться что источник информации является релевантным, достоверным, подлинным, заслуживающим доверия.
Если в предложении используется перечисление в строчку, разбиваем строку на нумерованный/маркированный список.
Проставлять номер каждому абзацу, чтобы было проще ссылаться на информацию из документа при общении с заинтересованными лицами.
Находим элементы ПО в тексте
Классы/Сущности/Таблицы— существительное, используемое в начале предложения (чаще всего), либо следующее используемое существительное после основного.
Объекты/Свойства/Атрибуты/Состояния — существительные/прилагательные, явно зависящие от другого существительного (в смысловой зависимости).
Процессы/Методы/Функции — существительное + глагол, причастные/деепричастные обороты, глаголы, причастия, деепричастия, абстрактные существительные (например — операция)
Условия/Исключения/События — использование союза «Если»/«Когда», слова-указатели на условие (когда бы, при условии, если бы).
Выделяем элементы ПО цветом
Детально изучаем документ, при чтении выделяя текст по следующему принципу:
Классы/Сущности/Таблицы- синий цвет
Объекты/Свойства/Атрибуты/Состояния — оранжевый цвет
Процессы/Методы/Функции — зеленый цвет
Условия/Исключения/События — фиолетовый цвет
*В документе можно указать обозначения цветов для понимания читателями.
После анализа документа мы получаем артефакт — конспект.
Что делать с полученным артефактом
Информация из данного артефакта преобразуется в:
Модель данных (например в нотации Crow`s foot) на основании выделенных Сущностей/Таблиц/Свойств/Атрибутов.
Модель процесса (например в нотации BPMN, UML Sequence, UML Activity) на основании выделенных Сущностей/Процессов/Функций/Условий/Событий.
Модель состояний (UML State Machine) на основании выделенных Свойств/Состояний/Условий.
Модель классов/объектов (UML Class diagram, UML Object diagram), если вы используете объектно-ориентированный анализ, на основании выделенных Классов/Объектов/Методов.
Вопросы к коллективной технике выявления требований — анкетирование/интервью/воркшоп/мозговой штурм.
Также конспект может потребоваться при обсуждении/валидации требований, поможет быстрее погрузиться в предметную область «новичкам» команды или разговаривать на одном языке со своими стейкхолдерами.
Пример документа до анализа:
Пример документа после анализа:
Из представленного отрезка можно выделить:
Процессы/Методы/Функции:
Классы/Сущности/Таблицы:
Рабочий день,
Торговый день,
Предмет торгов,
Продавец/Покупатель,
Торговая сессия,
Финансовый инструмент.
Объекты/Свойства/Атрибуты/Состояния:
Торговый день группы финансовых инструментов,
Торговый день по иностранным валютам,
Основная торговая сессия,
Дополнительная торговая сессия.
Условия/Исключения/События:
Торги могут проводиться только в рабочий день и в течение торгового дня.
У каждой группы финансовых инструментов отдельный торговый день.
Если финансовый инструмент участвует в торгах с единственным покупателем или продавцом, торговый день для такого финансового инструмента может отличаться от установленного для всей группы финансовых инструментов, в которую входит представленный финансовый инструмент.
Все иностранные валюты (за исключением Доллара США) торгуются в одну торговую сессию с продолжительностью в торговый день.
Только для иностранной валюты Доллар США торговый день имеет отдельные торговые сессии.
Завершение
Документы играют роль не только источника информации, но и стратегического ресурса для эффективной разработки. Анализ документов при замене системы, изучении стандартов, автоматизации бизнес-процессов и внедрении готовых решений предоставляет ключевые детали, необходимые для успешного завершения проекта.
Техника выделения элементов ПО цветом, представленная в данной статье, дает возможность не только легко воспринимать информацию, но и создавать ценные артефакты, такие как конспекты. Эти конспекты становятся фундаментом для дальнейших этапов разработки, включая создание моделей данных, процессов, состояний, классов и объектов.
Анализ документов — это не просто процесс, это искусство. Это искусство понимания не только текста, но и того, как эта информация может быть воплощена в структурированные и понятные модели.
Не забывайте, что ключ к успешному анализу заключается не только в использовании технических инструментов, но и в глубоком понимании предметной области. Будьте открытыми к новым вызовам, постигайте мир анализа с увлечением, и ваш вклад в создание качественного программного обеспечения станет неоценимым.
Спасибо за внимание, и желаю вам успехов в вашем аналитическом путешествии!
P.S. В статье много интересного, что можно раскрыть детальнее, чего бы тебе хотелось узнать?
Ведущий системный аналитик (linkedin)