В этой статье я хочу рассказать об ошибках, которые часто допускают начинающие специалисты в области системного анализа, и поделиться основами создания документации для разработчика.
В IT-компаниях разработка самое дорогое звено в создании продукта. Системный аналитик должен упрощать работу разработчикам и экономить их время.
Ошибки
Большой объем
Объемный документ отнимет массу времени на изучение, итогом которого будет потеря разработчиком конкретики и понимания задачи.
Неполнота описания
Попытки сократить объем описания документации или задачи, часто приводит к неполноте ее описания. Аналитик должен уметь находить баланс и четко конкретизировать свои требования.
Пример неполного описания: "Для получения данных Системе А требуется периодически отправлять запрос в Систему B".
- Каких данных? С какой периодичностью? С помощью какого метода?
Нет визуализации
Если вы описываете реализацию какого-либо сложного функционала, то старайтесь разбавлять текст различными схемами или диаграммами. Это поможет сконцентрировать внимание разработчика на значительно важных деталях.
Применение UML-диаграмм
Каждый системный аналитик должен знать хотя бы одну из нотаций моделирования и проектирования информационных систем. В статье речь пойдет о нотации UML, так как она предоставляет все необходимые артефакты для документирования и визуализации программных продуктов.
Диаграммы нотации UML делятся на два типа:
- структурные диаграммы, которые предназначены для описания структуры системы и ее частей на разных уровнях абстракции;
- поведенческие диаграммы, которые предназначены для описания взаимодействия объектов системы, ее компонентов с изменением во времени.
Всего UML предоставляет около 12 диаграмм, но для создания технической документации достаточно использовать только три из них.
Почему только три? Зрительно человек способен воспринимать около 25% информации, поэтому очень важно не перегружать документацию и делать ее наиболее доступной.
Разработчик не должен знать все нюансы нотаций и построения диаграмм, его задача создавать продукт, поэтому визуализация должна помогать доносить информацию, а не усложнять ее передачу.
Class diagram (диаграмма классов)
Тип
Структурная диаграмма
Применение
В теории диаграмма классов предназначена для контекстного, описания интерфейсов и реализации, то есть демонстрирует отношения классов между собой.
В работе она используется для визуализации концептуальной, логической и физической структуры системы, другими словами она описывает связи между таблицами базы данных.
Sequence diagram (диаграмма последовательности)
Тип
Поведенческая диаграмма
Применение
Диаграмма отображает взаимодействие объектов, упорядоченных по времени их проявления. Идеально подходит для системной интеграции, хорошо отображает синхронное и асинхронное взаимодействие.
Component diagram (диаграмма компонентов)
Тип
Структурная диаграмма
Применение
Диаграмма предназначена для визуализации представления структурных компонентов системы и связи между ними. Применяется для создания архитектурных схем.