Многие из нас работают в компаниях с устоявшимися процессами разработки прикладного программного обеспечения, и неотъемлемой частью этих процессов является широкий спектр документов.
Однако есть компании, у которых нет традиций и процессов написания технической документации, а вся информация находится в головах людей и в корпоративной электронной почте.
Если вы приходите из компании первого типа в компанию второго типа, то очень быстро обнаруживаете, что рабочая документация нужна как воздух.
Почему? Давайте рассмотрим основные виды рабочей документации при разработке программного обеспечения и попробуем представить жизнь без них.
1. Технические характеристики.
Технические характеристики – это связь между бизнесом и разработкой.
Это документ, в котором бизнес и программисты приходят к единому мнению, что и как следует реализовать.
Если в компании не принято писать техническое задание, то никто и никогда не сможет понять, что уже реализовано, а что еще не реализовано.
Это неизбежно приведет к многократному дублированию функционала, поскольку с течением времени меняются люди, меняются административные подразделения, функции переходят из одного отдела в другой и так далее.
Кроме того, дополнить уже реализованный функционал новыми возможностями станет чертовски сложно, ведь чтобы понять (особенно для нового сотрудника), что и как было реализовано, придется общаться с десятками сотрудников и поднимать месяцы корпоративной переписки.
.
2. HLA (архитектура высокого уровня).
В этом документе на архитектурном уровне описано, как мы будем реализовывать то, что описано в технических спецификациях.
В нем описано, где нужно будет внести изменения, описана суть изменений, и именно в этом документе описана такая очень важная часть, как интерфейсы между модулями/подсистемами.
Если я не ошибаюсь, ДеМарко и Листер очень правильно заметили, что самые «плохие» (то есть трудно находимые и устраняемые) ошибки возникают во время взаимодействия между системами, в интерфейсах.
Поскольку HLA согласовывается командами разработчиков, по сути, это единственное место, где команды разработчиков договариваются о том, как их продукты будут взаимодействовать друг с другом.
Если вы не напишете эти документы, вы никогда не узнаете, кто неправильно реализовал интерфейс, что неизбежно приведет к архитектурным ошибкам, которые могут стоить очень дорого в будущем.
Качество кода значительно упадет, появится множество трудно обнаруживаемых ошибок.
Кроме того, в будущем, чтобы понять, как работает взаимодействие двух модулей, новому человеку снова придется общаться с десятками людей и проходить месяцы переписки.
3. LLD (низкоуровневое разложение).
Это документ, который создается внутри команды разработчиков.
Здесь подробно описаны все методы и API, необходимые для реализации.
По сути, после написания этого документа остаётся только закодировать описанное.
Без этого документа у программистов не будет четкого понимания, что нужно делать, что в дальнейшем приведет к увеличению количества ошибок (то есть к снижению качества кода).
4. PMI (программа и методика испытаний).
Это, пожалуй, главный документ в области тестирования, поэтапно описывающий, что необходимо сделать, чтобы бизнес мог четко решить, что реализованный функционал работает корректно и в соответствии с техническим заданием.
Без такого документа вы не сможете проверить функционал на наличие ошибок (несоответствие спецификации тоже является ошибкой), что в конечном итоге значительно увеличит риск появления кучи ошибок на производственной платформе, вплоть до полная неработоспособность функционала.
Кроме того, без этого документа приемка функционала бизнесом превращается в неформализованный процесс со всеми вытекающими последствиями, такими как необоснованные претензии к разработке со стороны бизнеса.
5. Руководство пользователя.
Что нужно сделать пользователю, чтобы выполнить определенный бизнес-процесс с использованием вашего программного обеспечения.
Много скриншотов, мало слов.
Без этого документа пользователи будут регулярно звонить в поддержку и (в особо запущенных случаях) разработку по каждому чиху.
Стоит ли говорить, что без этого документа новому сотруднику будет крайне сложно разобраться в прикладном программном обеспечении предприятия, которое, как правило, не имеет простого и интуитивно понятного интерфейса? 6. Руководство системного администратора.
Крайне необходимый документ, описывающий, какие ресурсы необходимы прикладному ПО, как настроить это ПО и как назначить в нем привилегии и права.
Документом пользуются как системные администраторы, так и техническая поддержка (это не везде один и тот же отдел).
Без этого документа ваше программное обеспечение рискует остаться без ресурсов (ядер процессора, дискового пространства) в самый ответственный момент. Также будет немало проблем со своевременностью распределения прав: если информация находится в сознании двух человек, один болен, другой в отпуске, то сотруднику придется ждать неделю, чтобы получить необходимую информацию.
привилегии.
Неделя – это очень большой срок для бизнеса.
Для бизнеса даже час — это слишком долго.
Понятно, что в данной статье не охвачены все документы, сопровождающие процесс разработки от возникновения потребности в чем-то до внедрения этого чего-то в производство.
Я вообще не затронул область управления проектами, а в этой области документация — это основа основ.
Я не рассмотрел всю документацию по разработке и тестированию.
Но, надеюсь, я вас убедил (неужели есть люди, которых нужно в этом убеждать?), что техническая документация — крайне нужная и полезная вещь, которой ни в коем случае нельзя пренебрегать при разработке программного обеспечения.
Пишите документы! В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Есть ли в вашей компании процессы составления и актуализации (актуализации) технической документации? 10,92% Да, документация полная и регулярно обновляется 56 18,71% Нет, сотрудники уже знают, в чем смысл создания бюрократии 96 50,88% Документация ведется время от времени и не обновляется постоянно 261 19,49% У нас почти нет документации , но мы полны решимости сделать это, чтобы завоевать 100 голосов 513 пользователей.
143 пользователя воздержались.
Теги: #документация #процесс разработки #разработка сайтов #тестирование ИТ-систем #программирование
-
Три Самые Ненавистные Вещи В Компьютерах
19 Oct, 24 -
Плагин Для Выделения Последней Строки
19 Oct, 24 -
Тема Диссертации
19 Oct, 24
