Комментарии 14
Тема обширна. Возможно, различия в восприятии терминологии, но важные тех. решения должны быть выявлены и обязательно зафиксированы на самом старте проекта, отражены в структуре требований (особенно, если у вас будут логические модели данных в виде ERD-диаграмм или диаграммы классов, например) и проектировании минимально-достаточного «дерева» требований. Или еще аргумент хотя бы с позиции потребностей бизнес-анализа: без арх. решений вы НФТ (производительность, отказоустойчивость, например) ну никак не напишите исчерпывающе.
UX/UI не так категорично, конечно, но я бы тоже отнесла в обязательные.
«Другие типы документов» в посте — это не «необязательные», а обязательные на определенных проектах. Необходимый минимум — это те, которые я могу написать под все проекты, которые видела.
А вот UX/UI нет в бековских системах (а где есть фронт — макеты будут 99%), в простых системах архитектуру вполне заменяет концептуальная модель, как мне кажется.
Концептуальная модель (точнее то, что вы ею называете; для меня понятие концептуальной модели все же ближе к понятию модели данных (логической модели) или концептуальной модели данных в терминах UML, а у вас модель БП верхнего уровня в нотации IDEF0; сущности описывают ERD и UML Class Diagram) и технологический стек — это немного о разном, как мне кажется. Тех. моменты решения, которые стоит учесть на этапе анализа, есть всегда, независимо от того, «простая система или сложная».
>> А вот UX/UI нет в бековских системах (а где есть фронт — макеты будут 99%), в простых системах архитектуру вполне заменяет концептуальная модель, как мне кажется.
Макеты да, а UX ;)
Но, это все придирки, повторюсь:) Статья очень структурна и полезна.
Тех. моменты решения, которые стоит учесть на этапе анализа, есть всегда, независимо от того, «простая система или сложная».
Cогласна c Вами, спасибо за полезный комментарий.
Хочется придумать побольше примеров таких тех. моментов для одного сервиса: субд важна, количество БД, реляционка или нет, тип интеграций (шины, очереди, FTP, REST, SOAP), если стек не выбираем — тоже могут быть нюансы, конечно, бекапы, логирование.
У Вас есть какие-то еще примеры?
БП — да, а БП, подлежащий автоматизации, всегда мапится на функции системы.
И я бы все же разделяла понятия как в терминах у Вигерса (логическую модель данных он часто заменяет синонимом концептуальной) и общепринятых стандартов, например, UML (Class Diagram в UML или ERD у аналитиков так и называется концептуальной моделью предметной области в терминах сущностей (классов), их атрибутов и связей). Я понимаю что у вас концептуальная модель системы как бы, а не данных, но такого термина я не встречаю в обиходе.
>> У Вас есть какие-то еще примеры?
Тут я все же больше имела ввиду важные моменты на фазе инициации разработки: технологический стек реализации и иные нюансы, которые должны быть на входе у архитекторов при проектировании или создании тех. дизайна системы с учетом инфраструктур, кроссплатформенности, сред развертывания, интеграций, миграции данных, перспектив масштабирования и т.д.
То, что перечислили вы это уже более глубокие моменты последующего функционального анализа (технического, системного) и действительно не всегда могут быть в пакете итоговых артефактов для условно простых систем.
Чтобы новый человек мог понять что же вообще должен делать сервис и если он делает это не так, то можно было бы сослаться на это ТЗ и обозначить что тут что-то не сходится. Тем более если есть идея — улучшить сервис, то без ТЗ не понятно совпадают ли цели улучшения с целями сервиса. ТЗ должно обновляться в случае доработок и не должно протеворечить самому себе.
По ТЗ пишем тесты, после них начинаем разработку.
Во-первых, ТЗ — это не всегда только требования, туда могут входить еще план-график проекта, протоколы встреч, финансовые обязательства и пр.
Во-вторых, требования — это очень обширное понятие. Большая часть перечисленного в статье может входить в спецификацию требований — это и сценарии использования, и требования к данным, и ограничения, архвижн, интерфейсы, функциональные (оно же логика работы системы) и пр.
Но часто в agile-проектах не пишут общего ТЗ и спецификации, а требования размазывают по задачам в трекере, письмам и другим неструктурированным артефактам. Поэтому я и расписала по пунктам.
P.S.: кстати, на некоторых проектах, если собрать все в единый документ — он становится совершенно нечитабельным, так как много разветвленных и вложенных требований.
Добавлю немного про требования и Agile...
На старте проекта действительно редко кто позволяет себе тщательно документировать требования к системе (согласно одной из заповедей Agile-манифеста). И до поры до времени почти всю информацию можно получить из набора выполненных user stories (конечно, при условии, что они сами были качественно проработаны).
Но переломным моментом, на мой взгляд, является релиз, в который попала пользовательская история с изменениями в уже реализованной функциональности. Ведь с каждой новой подобной историей распутать клубок изменений в требованиях будет становиться всё сложнее, а значит трудозатратнее!
В целом согласна, спасибо! Но даже и на старте не каждую систему можно описать через user stories и только них. Часто бывает, что системы не взлетают или очень долго и сложно стартуют, потому что требования не были проработаны должным образом: не записали и не учли все сущности, маппинги, альтернативные сценарии. Системный подход к документированию как раз помогает такие пробелы вовремя увидеть.
Прям утреннее откровение для меня!
Заставил новый проект заниматся документацией, а я чувствую, что не совсем хорошо описываю процессы.
И тут Ваша статья. Огромное спасибо!
"Рекомендую использовать https://glvrd.ru" - а эта рекомендация прямо сделала мой день. И нескольких аналитиков на разных проектах, они прям в восторге.
спасибо за информация! есть примеры такого программного обеспечения и результаты сравнения? желательно чтобы документация разрабатывалась по ISO 9000, ITIL и документация сверялась с живыми информационными системами, чтобы документация была актуальная и показывала несоответствия
Документация в порядке