Основы разработки программного продукта. Пакеты документов

1. Основы разработки программного продукта. Пакеты документов. 1.1. Разработка технической документации. 1.1.1. Разработка Технических заданий и Графиков работ. Жизненный цикл любого продукта, в том числе и программного, состоит из нескольких этапов: • Идея; • Постановка задачи; • Проектирование и разработка; • Тестирование; • Сдача в эксплуатацию; • Эксплуатация; • Списание и утилизация. Каждый из этих этапов сопровождается разработкой соответствующей документации, отражающей формальную часть жизненного цикла продукта. В данном разделе основное внимание уделено разработке технической документации, сопровождающей второй из указанных выше этапов. К такой документации, прежде всего, относятся Технические задания и Графики работ. По своей сути Техническое задание является основным документом, которым руководствуется разработчик при выполнении работы. Техническое задание предназначено для всестороннего и углубленного описания требований, предъявляемых Заказчиком к разрабатываемому продукту, и обязательно включает в себя: • Развернутое название разработки и краткий шифр (псевдоним); • Обоснование проведения работ; • Назначение разработки; • Цели и задачи проведения работ; • Технический состав разработки; • Технические требования к разработке; • Требования к документации; • Стадии и этапы разработки (в виде таблицы); • Технико-экономическое обоснование разработки; • Особые условия и требования к разработке (например, требования по обеспечению сохранности государственной и служебной тайн); • Условия приемки работ; • Порядок внесения изменений и дополнений к Техническому заданию. По теории, составлять Техническое задание должен Заказчик, однако на практике очень часто возникает ситуация, когда заказчик не может верно сформулировать свои требования из-за отсутствия или неполноты технических знаний, необходимых для проведения разработки. Другими словами, Заказчик зачастую сам смутно представляет, что ему требуется. В таких случаях Техническое задание составляется либо совместно с Исполнителем работ, либо самим Исполнителем. После составления проекта Технического задания Исполнитель анализирует его, проводит предварительные расчеты с целью определения возможности его исполнения в установленные сроки. После того, как установлена потенциальная возможность выполнения Технического задания, производится его подписание и утверждение со стороны Исполнителя, а затем согласование со стороны Заказчика. В момент согласования Заказчик (его представитель) подтверждает подписью свое согласие с содержанием Технического задания. После подписания Техническое задание становиться главным документом, в соответствии с которым разрабатываются все графики работ. Соблюдение всех технических требований, перечисленных в Техническом задании, становится обязательным для Исполнителя. С другой стороны, после того, как Техническое задание вступило в силу, Исполнитель имеет право апеллировать к нему в случае возникновения разногласий с Заказчиком по поводу тех или иных характеристик разработки. Здесь действует правило: «не записано в ТЗ, следовательно, обязательному исполнению не подлежит». Как показывает практика, уже после подписания ТЗ Заказчик может передумать относительно одних технических требований и/или предъявить дополнительные. Исполнитель оставляет за собой право выполнять или не выполнять новые требования, не предусмотренные в ТЗ. Если Исполнитель готов выполнить новые требования, то совместно с Заказчиком эти требования оформляются в виде дополнения к ТЗ и, соответственно, подлежат отдельной оплате. Также возможно изменение сроков разработки в связи с введением новых требований. В каждом конкретном случае этот вопрос обсуждается с Заказчиком отдельно. Далее рассмотрим более подробно содержание пунктов Технического задания: 1. Название. В данном пункте указывается полное название разработки, а также краткий шифр (псевдоним), под которым разработка упоминается в дальнейшем тексте. Название работы рекомендуется начинать со слов «Разработка», если речь идет о создании какого-либо продукта (в т.ч. программного), или «Проведение», если речь идет о научных исследованиях и экспериментах. В первом случае проект относится к классу ОКР (опытно-конструкторская разработка), а во втором – к НИР (научно-исследовательская разработка). Если проект объединяет как научные исследования, так и создание конкретного изделия, то проект может быть отнесен к классу НИОКР (научно-исследовательская и опытно-конструкторская разработка). 2. Основание проведения работ. В данном пункте указываются предпосылки организации проекта. В качестве предпосылок могут выступать: • пункты ТЗ на общий проект, в рамках которого предполагается проводить данную разработку; • результаты и рекомендации протоколов испытаний по предшествующим работам, продолжением которых может являться данная разработка; • технические решения на разработку, согласно которым предполагается проводить проект; • другие документы, прямо или косвенно указывающие на необходимость проведения разработки. 3. Назначение разработки. В данном разделе указывается, для чего нужна разработка, которую предполагается проводить, какие функции (наиболее важные) она выполняет. 4. Цели и задачи проведения работ. В данном пункте перечисляются цели, для достижения которых предполагается вести разработку. В качестве целей могут выступать: • качественные и количественные характеристики, для достижения которых Заказчик санкционирует работы по проекту; • новые свойства и параметры, которые позволит обеспечить данная разработка; • улучшение существующих свойств и параметров, которые позволит обеспечить разработка; • новые возможности, которые обеспечит разработка и т.п. 5. Технический состав разработки. В данном пункте указываются составные части, из которых состоит конечный продукт разработки. Для программного продукта в качестве составных частей могут выступать: • программные модули; • библиотеки динамической компоновки; • файлы данных (в т.ч. баз данных); • другие составные части, разработка которых ведется в рамках данной разработки и которые предполагается передать Заказчику после завершения работ. 6. Технические требования к разработке. В данном пункте указываются технические требования, которым должна удовлетворять разработка. Обычно требования указываются в виде «Разработка должна обеспечивать…», «Разработка должна удовлетворять…», «Разработка должна выполнять…» и т.п. На данный пункт следует обращать особое внимание при составлении ТЗ, поскольку именно указанные здесь требования подлежат самой тщательной проверке при приемке работ заказчиком. Здесь следует указывать только те требования, выполнимость которых в установленные сроки не вызывает сомнений у Исполнителя. Дополнительные требования, а также те требования, в выполнимости которых имеются сомнения, лучше не указывать, либо указывать в смягченной форме (например, «Должна быть предусмотрена возможность…», «Должны быть проработаны вопросы…» и т.п.). В любом случае, желательно этот вопрос дополнительно обсудить с Заказчиком, высказав свои сомнения по поводу тех или иных требований. Однако, следует помнить, что последнее слово здесь остается за Заказчиком. 7. Требования к документации. В данном пункте указываются требования Заказчика к содержанию и оформлению сопроводительной программной и конструкторской документации. Обычно, если особых требований не предъявляется, в данном пункте приводится ссылка на Единую Систему Программной (Конструкторской) Документации (ЕСПД, ЕСКД). Например, «Состав программной (конструкторской) документации должен соответствовать требованиям ЕСПД (ЕСКД).» Далее обычно перечисляются документы, которые разрабатываются в рамках данной разработки. В ЕСПД (ЕСКД) перечислены документы, разработка которых является обязательной. Некоторые из них будут рассмотрены в разделе 1.1.2. 8. Стадии и этапы разработки. В данном пункте указывается последовательность проведения работ с указанием сроков и вида отчетности. Эти данные оформляются в виде таблицы следующего вида: № этапа Наименование работы Исполнитель Срок исполнения Отчетность 1. <Общее наимено-вание 1 этапа разработки>: ◦ Подпункт 1.1 ◦ Подпункт 1.2 ◦ Подпункт 1.3 … <кто исполняет> <срок, до которого выполняется подпункт> <вид документа, который является отчетным по данному подпункту> 2. <Общее наимено-вание 2 этапа разработки>: ◦ Подпункт 2.1 ◦ Подпункт 2.2 ◦ Подпункт 2.3 … <кто исполняет> <срок, до которого выполняется подпункт> <вид документа, который является отчетным по данному подпункту> … … … … … В качестве отчетных документов могут выступать: • технические акты о выполнении этапа разработки; • планы-графики работ; • программная и конструкторская документация; • протоколы испытаний; • само изделие (в случае программы – указывается вид носителя или универсальная формулировка – «на магнитном носителе»); 9. Технико-экономическое обоснование разработки. В данном разделе приводятся расчеты трудоемкости работ, ориентировочная стоимость закупаемого оборудования и программного обеспечения, необходимого для выполнения разработки, указывается общая стоимость проекта. Помимо этого приводятся обоснованные доводы в пользу необходимости выполнения тех или иных дополнительных работ и/или закупки оборудования и ПО. Также здесь могут приводиться обоснования необходимости привлечения к работам сторонних разработчиков (контрагентов), если они есть. Основная цель данного пункта – грамотно доказать Заказчику необходимость указанных затрат. 10. Особые условия и требования к разработке. В данном разделе указываются требования к организации работ по проведению разработки, требования к соблюдению государственной и служебной тайн и т.п. 11. Условия приемки работ. В данном разделе указывается порядок приемки выполненных работ, порядок тестирования и испытания разработки, порядок отчетности и т.п. 12. Порядок внесения изменений и дополнений. В данном пункте указывается порядок изменения различных пунктов Технического задания (как правило, технических требований и/или сроков разработки) в случае необходимости. График работ разрабатывается совместно с Техническим заданием и по содержанию практически повторяет пункт ТЗ «Стадии и этапы разработки» с добавлением пункта «Потребитель». Основная цель графика – дать возможность наглядно и быстро оценить объем работы, ее сроки, отчетность и т.п. Данный график должен находится у каждого из исполнителей работы, чтобы он мог сверяться по нему и планировать свою деятельность таким образом, чтобы выполнить свою часть в срок и с надлежащим качеством. Помимо ТЗ и графика работ также составляется документ, называющийся «Перечень работ». Этот документ в большинстве своем повторяет график работ, за исключением поля «Срок исполнения», и предназначен для отражения состава выполняемых работ и отчетных документов. Перечень работ является одним из документов, который используется при расчете окончательной стоимости работ, исходя из их количества и трудоемкости. 1.1.2. Оформление программной документации. Единая Система Программной Документации (ЕСПД). Программная документация предназначена для детального описания разрабатываемого программного продукта. Состав и содержание программной документации регламентируется набором ГОСТов, объединенных в Единую Систему Программной Документации (ЕСПД). Часть документов, предусматриваемых ЕСПД, являются обязательными к исполнению, а часть – рекомендуется, но не является обязательной. К обязательным документам на этапе технического проекта относятся: • Спецификация; • Формуляр; • Руководство оператора; • Описание программы; • Текст программы. К рекомендуемым, но не обязательным документам относятся: • Руководство системного программиста; • Руководство программиста; • Описание применения; • Пояснительная записка. Помимо программной, разрабатывается также следующая документация: • Программа и методика испытаний; • Протокол испытаний. Далее более подробно рассмотрим содержание обязательной программной документации. Спецификация представляет собой эксплуатационный документ, описывающий общее содержание программной документации, разработанной для данного проекта. Основное содержание Спецификации составляет таблица следующего вида: Обозначение Наименование Примечание Документация <кодовое обозначение документа 1> <наименование документа 1> <кодовое обозначение документа 2> <наименование документа 2> … … … Кодовое обозначение документа записывается в виде: A B . XXXXX–XX XX XX–XX Например, 7501665.00800-01 12 01 (Текст программы), 7501665.00800-01 12 01-ЛУ (Лист утверждения к Тексту программы). Некоторые коды вида программных документов: 12 – Текст программы; 13 – Описание программы; 30 – Формуляр; 33 – руководство программиста; 34 – Руководство оператора; 51 – Программа и методика испытаний; 90-99 – Техническое задание Формуляр представляет собой документ, предназначенный для отражения общих сведений о продукте, его производителе, комплектности, а также сведений о приемке и закреплении программного изделия. Общая структура данного документа имеет вид: 1. Общие указания. Данный раздел содержит общие требования, предъявляемые к оператору, выполнение которых необходимо для правильной эксплуатации программного изделия. 2. Общие сведения. Данный раздел содержит общие сведения о программном продукте, его назначении, производителе, инвентарном номере и т.д. 3. Комплектность. Данный раздел содержит сведения о составе программной документации, поставляемой вместе с продуктом. Состав документации оформляется в виде таблицы следующего содержания: Обозначение Наименование Количество, шт. Порядковый учетный номер Примечание Документация <код документа 1> <наименование документа 1> <количество экземпляров> <порядковый учетный номер> <код документа 2> <наименование документа 2> <количество экземпляров> <порядковый учетный номер> … … … … … 4. Свидетельство о приемке. В данном разделе приводится Лист приемки установленного формата, который заполняется при передаче продукта в эксплуатацию, подписывается обеими сторонами и закрепляется печатью. 5. Сведения о закреплении программного изделия при эксплуатации. Данный раздел содержит сведения отчетного характера, отражающие процесс эксплуатации программного изделия. Сведения оформляются в виде таблицы, поля которой резервируются для заполнения в процессе эксплуатации. Таблица имеет следующий вид: Должность ответствен-ного лица Фамилия ответствен-ного лица Номер и дата приказа Подпись ответствен-ного лица о назначении об освобождении … … … … … 6. Сведения об изменениях. Данный раздел предназначен для отражения всех последующих изменений документа (исправлениях в тексте, замене листов, удалении и добавлении листов и т.п.). Сведения об изменениях оформляются в виде таблицы следующего содержания: Основание (входящий номер сопроводи-тельного документа и дата) Дата прове-дения изме-нения Содержание изменения Поряд-ковый номер измене-ния Должность фамилия и подпись ответсвен-ного лица за проведение изменения Подпись лица ответсвен-ного за эксплуата-цию програм-много изделия … … … … … … 7. Особые отметки. Данный раздел состоит из 4-6 чистых страниц и предназначен для внесения дополнительных заметок в процессе эксплуатации программного изделия. Руководство оператора представляет собой документ, предназначенный для описания процесса эксплуатации программного продукта: методов ввода/вывода данных, описания интерфейса программного продукта, выдаваемых сообщений и требуемой реакции оператора на эти сообщения и т.п. Общая структура данного документа имеет вид: 1. Назначение программы. В данном разделе приводятся общие сведения о назначении программы. Обычно этот раздел состоит из двух частей: • Особенности применения; • Состав и назначение функциональных компонент. Однако состав данного раздела может быть изменен или дополнен по усмотрению разработчика. 2. Условия выполнения программы. В данном разделе приводятся требования к программным и аппаратным средствам, в среде которых гарантируется работоспособность программного изделия. 3. Выполнение программы. В данном разделе перечисляются действия оператора по запуску, управлению и завершению работы программного изделия; описываются методы ввода/вывода данных, контролю правильности исполнения программы и т.п. 4. Сообщения оператору. Данный раздел содержит сведения о предусмотренных в программе сообщениях оператору (информационных, диагностических, сообщениях об ошибках и т.д.), формируемых программой в процессе своей работы, их расшифровке (подробному описанию), а также действиях оператора после получения сообщения. Описание программы представляет собой документ, предназначенный для описания логической структуры программного изделия. Общая структура данного документа имеет следующий вид: 1. Общие сведения. Данный раздел содержит общие сведения о программном продукте, его назначении, производителе, инвентарном номере и т.д. 2. Функциональное назначение. Данный раздел содержит сведения о назначении программного изделия, выполняемых им функциях и решаемых им задачах. 3. Описание логической структуры. Данный раздел содержит описание логической структуры программного изделия, алгоритмов основных функциональных частей, форматов входных и выходных данных, информационных и управляющих потоков и т.п. 4. Используемые технические средства. Данный раздел содержит требования к аппаратному и программному обеспечению, в среде которых гарантируется работоспособность программного изделия. 5. Вызов и загрузка. В данном разделе перечислены действия оператора по запуску программного изделия. Текст программы представляет собой документ, содержащий комментированный листинг всех модулей программы с кратким пояснением назначения каждого модуля. Текст программы считается комментированным удовлетворительно, если комментариями снабжено не менее 70% операторов программы. При этом допускается не комментировать вспомогательные операторы, введенные из-за особенностей синтаксиса языка программирования.