О правильном составлении ТЗ. Часть 3

В этом номере я с радостью готова представить вам 3-ю часть моего письменного рассказа о премудростях составления ТЗ. В первых двух статьях я рассказала вам о ТЗ в общих чертах, привела примерное содержание и постаралась показать, что необходимо писать в первых 4 главах. Сегодня я постараюсь освятить еще несколько глав. Приятного чтения…

Дарья Устюгова
by Sparky ustyugova90@mail.ru

Введение

Для начала отмечу, что в этом номере я расскажу о следующих главах:

5. Требования к программной документации
6. Технико-экономические показатели
7. Стадии и этапы разработки
     7.1 Стадии разработки
     7.2 Этапы разработки
     7.3 Содержание работ по этапам

Я специально не буду касаться вопросов проведения контроля и приемки работ, а также порядка корректировки ТЗ. Это вопросы довольно сложные и их обсуждение стоит вынести в отдельную статью. Сегодня мы также рассмотрим довольно серьезные и сложные вопросы. Чем же они сложны? Все банально, именно в этих главах ТЗ определяются сроки выполнения работ, содержание этих работ. И еще один немаловажный вопрос, вопрос финансовый. Но начнем мы с более банальных вещей.

Требования к программной документации

Это один из самых простых пунктов ТЗ, хотя это недолжно уменьшать его значимости. Тут стоит еще раз отметить, что ТЗ документ официальный. В данном пункте мы описываем, какая документации будет идти вместе с нашей программой. Возможно, некоторые возмутятся, а зачем вообще какая-то документация, у нас же в программе есть help? Задам встречный вопрос, а чем программный продукт отличается от программы? Одним из отличий является как раз таки наличие документации, причем качественной документации, написанной и оформленной также по ГОСТам. Да, да и тут ГОСТЫ. Для того чтобы сориентировать вас перечислю названия: «Руководство оператора», «Руководство системного программиста» и т.д. На самом деле подобных руководств много. Да байка про программы приходящие в больших коробках с кучей руководств – это правда. Это идеал, к которому необходимо стремиться. Именно поэтому в крупных компаниях есть должности технических писателей.

Технико-экономические показатели

Вот мы и добрались до финансовых вопросов. Сразу же хочу признаться, действительно крупных проектов у меня еще не было, поэтому этот пункт я опишу очень сжато, чтобы не ввести вас в заблуждение. В данном пункте, если разработка по своей идее не уникальна, стоит произвести сравнение стоимости с другими аналогами, показать что заказчик сможет выиграть за счет использования нашей программы. Если разработка уникально и финансист из вас не очень можно отписать следующей фразой: ориентировочная экономическая эффективность не рассчитываются. Аналогия не проводится ввиду уникальности предъявляемых требований к разработке.

Но в идеале необходимо расписать, какие преимущества именно с точки зрения ресурсов наш заказчик получит, а также необходимо разъяснить, за что заказчик будет платить нам деньги.

Стадии разработки

В данном пункте необходимо указать, через какие стадии разработки пройдет наша программа. Тут существует огромное количество всевозможных вариантов. Это объясняется тем, что существует не один способ создания ПО. Например, существуют каскадная и итерационная модели. Все будет зависеть в первую очередь от специфики проекта, во вторую очередь от разработчика. Но, если вы разработчик не очень опытный, а быть может это ваш первый проект или вы пишите систему (скажем для наших госорганов), то для вас есть ГОСТ. Называется этот ГОСТ: «ГОСТ 19.102-77 ЕСПД Стадии разработки». В этом документе и расписаны все стадии, кроме того, каждая стадия поясняется. Поэтому советую использовать поначалу именно этот ГОСТ. Но если ваш проект не очень большой и вы не любите изучать ГОСТы, предлагаю вам упрощенный вариант этого пункта ТЗ:

1. Разработка технического задания
2. Рабочее проектирование
3. Внедрение

Этапы разработки

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

Содержание работ по этапам

В данном пункте необходимо еще более детализировать стадии разработки. В ГОСТе это тоже есть. Зачем же нам это нужно? В прошлой статье я говорила о том, что одной из самых важных вещей в ТЗ является указание сроков выполнения работ. Какая же связь между этими 2 пунктами?

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

Именно этот прием стоит использовать и в разработки ПО, также благодаря этому мы в любой момент сможет отчитаться перед заказчиком о том, как у нас идут дела. И он будет хоть, сколько-то уверен в благоприятном исходе. И мы сможем себя контролировать, и если что подкорректировать свои действия.

Вместо заключения

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

• ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению http://www.nist.ru/hr/doc/gost/19201-78.htm
• ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом. http://www.nist.ru/hr/doc/gost/19106-78.htm
• Н. Дубова. В круге разработки http://citforum.ru/SE/project/circle
• Единая система программной документации (ЕСПД) http://www.philosoft.ru/espd.zhtml
• Rational Unified Process. Технологический процесс разработки ПО http://www.rup-rus.ru
• Введение в управление проектами http://www.prjman.ru/theory/32

Статья из десятого выпуска журнала «ПРОграммист».