ВСТУПЛЕНИЕ Добрый день, уважаемое сообщество.
Позвольте мне представиться.
Я бизнес-аналитик, десять лет работаю в сфере заказной разработки программного обеспечения, в последнее время совмещаю роли аналитика и менеджера проектов.
Одним из болезненных вопросов в разработке программного обеспечения всегда был и остается процесс документирования этой самой разработки.
Вы когда-нибудь попадали на проект, который находится в разработке уже пару лет, но при этом просто не можете в нем разобраться, ведь в документах содержится только одно техническое задание, да и то, написанное на самое начало и не отражает и половины функционала системы? У меня есть.
И это, честно говоря, очень печальное и удручающее зрелище.
Поэтому на всех своих проектах я стараюсь изначально выстроить процесс так, чтобы не было неопознанного или неописанного функционала, все члены команды вовремя получали актуальную информацию и вообще во всем был мир.
Итак, сначала отвечу на главный вопрос: для чего все это? Есть несколько причин.
1. Документация обеспечивает «общее пространство» проекта.
Любой участник в любой момент может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о странном баге в мусоре, который сделал Вася».
месяц назад." 3. Документация позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и согласованность.
«Ноты на коленях» — это прямой и очень быстрый путь к тому, что границы проекта разойдутся, как резвые тараканы, и задуманный в начале функционал не будет установлен с учетом «хотел» заказчика, возникающих в процессе.
Для себя я разработал набор основных правил, которые позволяют мне эффективно документировать, планировать и контролировать разработку в комфортной для всех участников среде.
1. Документация не должна быть избыточной или объемной.
Мы пишем документы не для приятного процесса нажатия клавиш, а для того, чтобы использовать их в своей работе.
Избыточный текст раздражает и труден для понимания.
2. Вся схема проектной документации должна быть взаимосвязана и логична.
Если в схеме есть документ, не связанный ссылкой ни с каким другим документом, то его можно смело исключить из схемы.
3. Все оценки трудозатрат должны производиться только на основе описанных атомарных задач.
Трудно оценить развитие «функциональности подсистемы ввода данных»; Гораздо проще оценить задачи «разработка формы ввода марсианских данных» и «разработка фильтра списка марсиан».
Чем меньше оцениваемый элемент, тем точнее будет агрегированная оценка.
4. Всегда необходимо создавать списки уведомлений для заинтересованных участников.
Разработчик, узнавший о необходимости улучшения за три дня до релиза - это зло и самая гнусная подлость, аналитик, который тайно изменил требования и не оповестил всех заинтересованных участников о необходимости улучшения - последняя свинья, а РП кто допустил такую ситуацию - это чума, холера и неприятный человек, не выполняющий своих обязанностей.
Предлагаю уважаемому сообществу схему документации, которая мне кажется удобной, логичной и правильной.
И да, это работает. Итак, какие виды документов используются в схеме.
1. Технические характеристики.
2. Частное техническое задание (по желанию).
3. Вариант использования.
4. Тестовый пример.
5. Отчет об ошибке.
6. Руководство пользователя.
7. Руководство администратора (по желанию).
На рисунке ниже представлена схема связи этих документов.
Как это работает?
ТК
Первоначально в ходе экспертизы формируется Большое Техническое задание.Оно включает: • словарь терминов предметной области; • описание предметной области; • описание ролевой системы; • описание функциональных требований; • описание нефункциональных требований.
Описание требований в этом документе закреплено на «верхнем уровне», то есть мы не описываем конкретные действия, а только необходимые функции.
Требования оптимально разбиты на смысловые группы по подсистемам.
Для примера опишем подсистему «Администрирование» с функциями «Создание карты пользователя», «Удаление карты пользователя», «Редактирование карты пользователя».
Это требования верхнего уровня; ниже в технических характеристиках опускаться нет смысла.
ЧТЗ
Если система большая, то для каждой подсистемы целесообразно составить конкретное техническое задание.ЧТЗ должно содержать: • ссылка на пункт ТЗ; • максимально подробная информация по каждой функции; • список вариантов использования функции.
Таким образом реализуется непрерывность документов, что позволяет, во-первых, унифицировать их форму, во-вторых, частично реализовать повторное использование, то есть сократить время, затрачиваемое на «написание».
Например, мы формируем ЧТЗ для той же подсистемы «Администрирование».
Там будет описание функции: «Создать карту.
Необходимо реализовать следующий функционал: вызов карты по кнопке «Создать», интерфейс карты, содержащий следующий набор полей, сохранение карты по кнопке «Сохранить», отмена сохранения по кнопке «Отмена».
Вариант использования
Вариант использования — это суть варианта использования; здесь описаны все действия, которые может выполнить пользователь, и реакция системы на эти действия.Каждый вариант использования должен быть связан с элементом ЧТЗ.
Самым оптимальным, на мой взгляд, является формат описания, включающий: • Расположение экрана.
Вы также можете делать сложные, «кликабельные» макеты, но, по опыту, достаточно «электрической схемы», сделанной с помощью Visio или аналогичного инструмента.
Если в форме предполагается использование модальных окон, то их тоже необходимо отрисовать, а для них продублировать описанные ниже таблицы.
• Экранная диаграмма действий, графически описывающая алгоритм работы функции.
• Таблица с описаниями полей.
Строка таблицы должна содержать следующие данные: имя поля, тип поля, ограничения на ввод данных (логические проверки и т.п.
), роли пользователей, которые могут читать/редактировать поле.
Если поле вычисляемое, то необходимо указать формулу для расчета значения.
• Таблица с описанием действий экранных кнопок.
Строка таблицы должна содержать информацию о названии кнопки, описании действия при нажатии и путях перехода, если нажатие кнопки предполагает переход на другой экран, роли пользователей, которым доступно действие.
Краткое общее описание функционала также возможно, но, как правило, оно просто не обязательно.
Прецедент
Test Case, что вполне очевидно, должен содержать описание тестовых сценариев.В идеале каждый такой документ привязан к соответствующему Use Case, но бывает, что несколько Use Cases логично объединить в один Test Case. Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей за собой ответ системы, а во втором — описание правильной реакции системы.
Например, нет необходимости описывать процесс ввода текста в текстовое поле, но проверка корректности данных при сохранении (нажатие на кнопку «Сохранить») обязательна.
Отчет об ошибке
Поиграюсь еще немного: Bug Report появляется в процессе тестирования системы как реакция тестировщика на ошибку.Каждый документ обязательно должен ссылаться на соответствующий Тестовый пример.
Документ должен содержать: • скриншот возникшей ошибки; • описание предыдущих действий.
Лучше всего разработать шаблон такого описания, удобный для всех — это существенно экономит время разработчиков при воспроизведении ошибки; • текстовое описание самой ошибки.
Руководство пользователя/Руководство администратора
Самые скучные документы для написания, но тем не менее жизненно важные документы.Фактически, их генерацию можно даже автоматизировать, если все тестовые сценарии и сценарии использования были написаны с должной тщательностью и правильно отформатированы.
Я не буду на них подробно останавливаться, но если тема вдруг вас заинтересует, расскажу, как можно автоматизировать их составление.
Заключение
Надеюсь, статья окажется для вас полезной и интересной.Многие другие вопросы документации при разработке ПО я, естественно, не затронул в тексте (например, использование стандартов, шаблонов, автоматизация процессов и т. д.), но если тема будет интересна, продолжу писать с удовольствие.
Теги: #документация #бизнес-анализ #Управление проектами #Анализ и проектирование систем
-
Мобильные Карты Теперь И На Русском Языке
19 Oct, 24 -
Будильник От Banana Pi
19 Oct, 24 -
Кармагограф На Хабре Барахлит Что Ли?
19 Oct, 24 -
История В Картах
19 Oct, 24
