BoatmansHome: РазработкаТЗнаПО ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Разработка полезного ТЗ на ПО по ГОСТ 19.201


Очень сложно рассказывать заказчику о том, как жизненные циклы систем бороздят просторы конуса неопределенности, когда ему вотпрямщас нужна автоматизация, или хотя бы, оценка, сколько это будет стоить.
Но всем обычно понятно, что команде разработки нужно выставить ТЗ. Причем ТЗ это должно быть на ПО.
Обычно в этот момент коллеги обращаются к туманному слову «требования», которое много чего значит, но мало объясняет, что делать.


Для тех, кто начинает проект с подобных вводных я и пишу эту статью, в которой мы обсудим:
1. Что такое Техническое Задание и чем оно отличается от требований
2. Как устроено техническое задание на программу по ГОСТ 19.201
3. Почему 19.201 устарел и насколько сильно
4. Что добавить в 19.201 чтобы работа пошла
5. Что еще нужно чтобы написать хорошее ТЗ для программистов


Оглавление

Техническое задание и все-все-все


Отличие ТЗ от требований в том, что кроме требований к результату оно содержит как требования к выполнению работ, так и требования к сдаче-приемке результата. В итоге ТЗ — это план проекта, проектное задание на пакет работ или, просто, «задача».
В переводных методологиях принято жестко отделять требования от плана. С этой точки зрения Requirements в большей части случаев необходимо переводить на русский, как «проект», если смотреть на структуру и содержание соответствующих документов.
Так, например, детальные функциональные требования на программный продукт по своей сути соответствуют части технического проекта на автоматизированную систему.

Тут есть важная оговорка: требования на программный продукт не эквивалентны проекту на включающую автоматизированную систему, но лишь ему соответствуют. Почему и как это так мы разберем ниже по тексту.

Это вносит серьезную путаницу, так как там, где в переводных методологиях идет разработка требований на самом деле надо «проектировать», а там, где у нас надо писать ТЗ в переводных методологиях надо планировать, опираясь на уже выполненные работы по созданию требований.


В этой статье в «разработку ТЗ» я буду понимать все работы по проектированию и, собственно, выпуск бумаги с надписью «техническое задание». Мне хотелось бы рассуждать о правильной организации жизненного цикла и фазах проекта, однако это сегодня бесполезно в большинстве случаев, по этому давайте засучим рукава и начнем загружать разработчиков входом для работы.

Структура ТЗ


ТЗ на ПО устроено очень просто, если смотреть издали.


Вот структура ПО из ГОСТ 19.201:

  1. Основание разработки
  2. Назначение разработки
  3. Требования к программе
  4. Требования к программной документации
  5. Технико-экономические показатели
  6. Стадии и этапы разработки
  7. Порядок контроля и приемки

Чтобы было легче разобраться всегда надо держать в голове полный цикл приобретения и использования любого продукта «деньги-продукт-эффект-деньги».
Ниже этот цикл отражен на картинке.


file:192011.png


Заказчик (на самом деле спонсор, но для нас сейчас это не важно) дает деньги на разработку под ожидаемый эффект, который достигается в ходе эксплуатации программы, для чего ее надо доставить к пользователям и установить в надсистему, собственно, обеспечивающую получение пользы. А для этого программу надо разработать, попутно согласовав с заказчиком ключевые технические (и не только) решения и не забыть так же разработать и передать документацию для пользователей и эксплуатационных специалистов (среди которых первые — это администраторы и служба технической поддержки). Все это, естественно, надо приемо-сдать.


Все то, о чем я написал выше и должно быть разжевано в ТЗ в деталях и красках с точки зрения ГОСТ 19.201.
На мой взгляд, тут нет неважных и ненужных вопросов. Такой подход передает команде разработки полный контекст и по максимуму исключает получение бесполезного ПО, которое пишется, не задумываясь о пользователях и ожидаемом эффекте, вызывает проблемы при эксплуатации с первого дня, не говоря уже о доставке и установке.

Для решения этих проблем придуманы agile, dev ops и множество других страшных слов, отвечающих на те же самые вопросы — это при том, что перечень вопросов, о которых нужно думать, разрабатывая ПО был стандартом как минимум в 1979 году.
Кстати, если сравнить структуру ТЗ по ГОСТ 19–201 и модные ныне User Story, можно будет увидеть совпадение по практически всем решениям, которые должны быть записаны в обоих артефактах.

Именно поэтому, на мой взгляд, ТЗ лучше, чем просто требования, чаще всего, повисающие в воздухе и оторванные от контекста как вышестоящей системы, так и будущего использования разрабатываемой программы.

Как осовременить ТЗ


Надо понимать, что изначально ГОСТ 19–201 создавался под тот стиль проектирования и взаимодействия, который был принят в СССР.
В том числе:


При этом состав вопросов, на которые надо ответить чтобы все получилось, с тех пор не менялся.


По этому:

Как передать контекст разработки без тонн бумаги


Можно доказать (но я здесь не буду), что полная передача контекста с помощью одной лишь бумаги невозможна.


Поэтому мы лишь выбираем степень документирования проектных решений и требований и количество информации, которое останется в головах у источников информации и участников проектной команды и будет в свое время перемещено из одних голов в другие.


Тут условно можно выделить три режима, между которыми есть масса промежуточных положений:
1. Тщательное документирование, подразумевающее незначительные уточнения, которые нет нужды планировать, как отдельные работы

2. Минимальное документирование, исключающее попадание основного объема проектных решений на бумагу, что требует специальной организации работ

3. Частичное документирование, предполагающее значительный объем коммуникации в ходе работы, и необходимость эту коммуникацию планировать и выделять на нее заметное количество человеко-времени


Не разбирая детально приемы и подходы к выстраиванию коммуникационной сети проекта хочу отметить один важный тезис для аналитиков и менеджеров проекта: требования или техническое задание не могут быть написаны качественно без понимания схемы и режима коммуникации проекта.


Куда в ТЗ надо положить это понимание сейчас разберем.


1. Если мы планируем, что будет изложена достаточно полная информация и останется лишь переспросить, то достаточно указать автора ТЗ с его контактными данными, а так же людей-источников информации по различным областям или вопросам. Эти формулировки можно напрямую включить в те разделы, к которым может понадобиться уточнение или вынести в приложение в таблицу.


2. Если мы явно планируем досъем информации с источников, выемку документов или другие «следственные действия», то


3. Если мы планируем передачу данных о решениях и требованиях по большей части устно, то ТЗ используем, как контрольный список, чтобы не забыть что-то важное

Роль надсистемы


Драма требований к программе в том, что они создаются в контексте требований и проектных решений вышестоящей системы: программно-технического комплекса или автоматизированной системы, включающей программно-технический комплекс и людей. Это тоже не я придумал: «программные средства всегда существуют в контексте системы, даже если система состоит из единственного процессора, выполняющего программы.» (ГОСТ Р ИСО/МЭК 12207–2010).


Поэтому любое руководство по написанию ТЗ к ПО должно начинаться со слов: «возьмите ТЗ на вышестоящую систему и ее технический проект...».
Но мы живем в реальности, где заказчик хочет сразу определиться со стоимостью будущей системы, а разработка хочет получить на оценку максимально подробное ТЗ.
При этом замыливается тот факт, что стоимость суммы аналитических работ (включая предпроектные), выполненных для загрузки команды входом, и последующей сдачи-приемки (но не включая внутреннее тестирование) находятся в среднем между 10 и 30% от суммарной сметы на программную часть системы. И это лишь тогда, когда приходит заказчик, хорошо понимающий, что он хочет. Так как стоимость бизнес-анализа зачастую непредсказуема по отношению к стоимости решения.


Драма в том, что между словами «нужна система Х» и детальным входом разработке лежат минимум два цикла проектирования, в ходе которых на основе требований к вышестоящей системе проектируется решение и выставляются требования на компоненты, одним из которых является наша программа:


В каждом переходе требования-решение мы переходим от единственного набора требований к выбору из множества вариантов решений. Это значит, что если компоненты системы проектируются в изоляции, они не имеют шансов успешно состыковаться при сборке.


В реальности все спасаются от этой беды по разному:


Если смотреть наиболее полно, то в самом «ужасном» случае мы имеем такие уровни проектрования


Все это время явно или подсознательно заказчик или спонсор смотрят на все, что мы делаем, как на финансовый актив, в который все время вкладываются ресурсы в ожидании, когда пойдет отдача. Точки между проектами — это, по хорошему, точки, где можно избавиться от убыточного актива, принять решение “STOP LOSS”, закрыв проект или изменив его цели.

Требования к программе более детально


Что хорошо в 19.201 с точки зрения современности и что туда надо бы добавить.


Оставить:

  1. Требования к функциональным характеристикам, причем как записано: указать входы и выходы функций, состав и структуры данных, не забыть решить что пишем про временные характеристики — оставим в контексте, сформулируем диапазоны длительности для выполнения ключевых сценариев или жестко задаем по каждой функции.
  2. Требования к надежности часто уходят в умолчания, но на секунду задуматься над ними необходимо.
  3. Условия эксплуатации: виды обслуживания и количество обслуживающего персонала надо обдумывать совместно с предыдущим пунктом чтобы не было неожиданностей. Надо хотя бы нарисовать в уме ось от «будет заперто на ключ и отправлено на Марс, за 50 лет не допустимо ни одного сбоя» до «ежеминутные сбои будем лечить холодной перезагрузкой, если не помогло выкатываем систему из вчерашнего бэкапа» и на ней разместить свою программу.
  4. Требования к составу и параметрам технических средств живее всех живых, так как, очевидно, временные характеристики и надежность достигаются не в вакууме.
  5. Требования к информационной и программной совместимости так же актуальны.
  6. Требования к маркировке и упаковке — надо потратить секунду на их обдумывание. Как будем различать билды и версии пакета установки мы сами, как пользователь будет отвечать поддержке на вопрос «назовите версию установленного клиента».
  7. Требования к транспортированию и хранению ничуть не потеряли свою актуальность. Об этом придумали целый dev ops, и вообще число способов и подходов к транпортировке и установке ПО к месту работы возросло на порядки с тех пор, и решение этих вопросов для небольших приложений может занимать существенную долю разработанных строк кода.

Потеряли актуальность.


Что нужно добавить:

  1. Нефункциональные требования сильно усложнились. Их просто надо добавить те, которые нужны. Для этого просто нужно обратиться к ГОСТ Р ИСО/МЭК 25021–2014, ИСО/МЭК 9126–93.
  2. К условиям эксплуатации можно добавить требования к окружению и обеспечению работы. Иногда недостаточно, чтобы в операционной системе были установлено то или иное ПО. Может быть нужно, чтобы
    • работали определенные сервисы и смежные системы, иногда еще и в определенном режиме, например, «необходимо подключение к сети Интернет» или «доступен контроллер домена Active Directory»;
    • был выдан доступ куда-либо, заведены учетные записи и т.п.
    • и вообще все объекты окружения так или иначе задействованные в работе не только присутствовали, но и находились в нужном нам состоянии.
  3. Из-за все более глубокой интеграции автоматизации в деятельность людей для успешной сдачи-приемки подавляющего большинства программ нужно знать не только состав функций, но и их взаимосвязи, то есть последовательность применения функций при работе пользователей. С этой задачей хорошо справляются описания системных вариантов использования.
  4. Кому неохота лазить по ГОСТам, вот список НФТ, наиболее, актуальных для современных приложений:
    • Надежность
    • Нагрузка
    • Информационная безопасность
    • Ограничения/требования на режимы, виды и стоимость эксплуатации
    • Удобство (точнее эргономические требования)
    • Масштабируемость
    • Перспективы и ограничения на виды, способы и стоимость развития;
    • Локализуемость
    • Юридические требования
    • Переносимость
    • Специальные требования времени разработки, тестирования, процесса выпуска, хранения и доставки, к маркировке и упаковке
    • Документирование
    • Требования к окружению
    • Требования к подготовке персонала
    • Требование к оборудованию
    • Требования к смежному ПО 
    • Кто знает больше — давайте поговорим об этом

Что еще

Еще несколько вопросов, которые надо держать в голове.


Первый
В эту статью не влез целый пласт вопросов по работе с требованиями: как их выявлять, проверять, формулировать. Эти вопросы должны быть решены для любого артефакта, не только для ТЗ, и сейчас мы их по большей части оставляем за кадром, за исключением одного: понимание для кого мы пишем ТЗ, а значит, кому оно должно быть понятно.
Для тех, кто не уверен, что владеет этими вопросами положу две абсолютно необходимых к прочтению книги. Этого для начала хватит, дальше разберемся:

И пару строк о процессе коммуникации: http://boatmanshome.ru/cgi-bin/page.pl?21dev_001_002.page, кому надо быстрее, пролистайте до обсуждения контекста: http://boatmanshome.ru/cgi-bin/page.pl?21dev_001_002.page#A6


Второй
Если ТЗ на программу подписывает представитель заказчика или пользователей, формулировки должны быть им понятны. Это часто вызывает неудовольствие разработчиков, которые хотели бы видеть более детальные, точные и технические формулировки.
И тут важно понять одну вещь: это вопрос не языковой. Здесь должен отработать архитектор (кто бы ни взял на себя его роль) и выдать проектные решения более низкого уровня разработчикам.


Вообще попытка натолкать в ТЗ архитектурных решений часто приводит к замедлению согласования, эффекту «поплывшего документа», когда в нем круг за кругом возникает больше вопросов, чем ответов, растет объем, копятся противоречия и становится не ясно, что куда положить, чтобы не повторяться в каждом разделе.
Решается это включением в план отдельной работы по принятию и согласованию между исполнителями технических решений и проектных заданий исполнителей, за что и отвечает роль архитектора.


В ТЗ целых два раздела посвящены вопросам: какие решения надо допринять, в какие документы/артефакты положить, какие еще работы будут выполнены для создания программы. Тем, кто не хочет много писать, можно хотя бы продумать эти вопросы.


Третий
Не стесняемся включать в ТЗ обязательства заказчика. В отличие от требований, которые начинаются с «система/программа должна» формулировки ТЗ шире: «заказчик гарантирует наличие ...», «заказчик обеспечивает/делает/согласует ...» и т.п.

ТЗ и предпроектные решения

Куда класть восстановленные проектные решения: описание бизнес-процессов и предметной области, бизнес-требования, концепцию и ТЗ вышестоящей системы:

ТЗ и AGILE

Если коротко, ТЗ по перечню отвечаемых вопросов эквивалентно бэклогу спринта со всеми приложениями и списком задач команды, полученными после сессии планирования.


Посмотрим на формат User Story:


Задачи, помещенные на доску по итогам сессии планирования — это раздел «Стадии и этапы разработки»
Фокус (цель) спринта кладем в назначение разработки.


По этому, если кто-то во время сессии планирования будет писать в облегченный шаблон ТЗ по ГОСТ 19.201 получится вполне сносный протокол сессии планирования и черновик ТЗ на спринт, который может подписать и проштамповать заказчик. Это я к вопросам Гос AGILE? — нет ни препятствий, ни противоречий к применению AGILE внутри ГОСТ-овского процесса.

Выводы


Итого, за что мы любим ТЗ:


Нет никаких причин, если не применять, то хотя бы не разбираться в ГОСТ серии 19.


 
Один файл.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]