Как написать Спецификацию на ПО. Всё, что изложено ниже – это только моё мнение, Вы можете иметь своё.))) Глава 1. Спецификация на ПО (примеры и замечания по…) «Чистая» спецификация Спецификация на программный продукт должна минимум в первую очередь содержать: - «Текст программы» - (исходный текст); - «Описание программы» - (среда компиляции и тому подобное; то есть, как текст программы превратить («сделать сборку») в исполняемую программу – «Продукт»). А все остальное в принципе может и отсутствовать (как говориться: дело автора). Рассмотрим на примерах (код вида документа приведён в соответствии с ГОСТ 19.101-77). Было разработано программное обеспечение ПО1. 1 ЖУТЬ.ххххх-хх ПО1 спецификация Документация общая ЖУТЬ.ххххх-хх 12 ПО1. Текст программы. ЖУТЬ.ххххх-хх 13 ПО1. Описание программы. Спецификация имеет точно такой же регистрационный номер как у «Текст программы» и «Описание программы», только без кода вида документа. Пока на этом остановимся. Разберёмся с «Текстом программы». Понятно, что сейчас ПО – это целый набор программных «объектов». Поэтому «Текст программы» - это совокупность всех исходных текстовых файлов (конечно можно всё свести в один текстовый файл, но зачем?). Обычно их записывают в одну папку, а папку называют присвоенным регистрационным номером (так удобнее хранить в архиве). Можно конечно и каждый модуль расписать, например: 2 ЖУТЬ.ххххх-хх ПО1 спецификация Документация общая ЖУТЬ.ххххх-хх 12 Модуль 1. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 1. Описание программы. ЖУТЬ.ххххх-хх 12 Модуль 2. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 2. Описание программы. ЖУТЬ.ххххх-хх 12 Модуль 3. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 3. Описание программы. ЖУТЬ.ххххх-хх 12 Модуль 4. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 4. Описание программы. ЖУТЬ.ххххх-хх 12 Модуль 5. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 5. Описание программы. … ЖУТЬ.ххххх-хх 13 ПО1. Описание программы. Спецификация имеет точно такой же регистрационный номер как у «Описание программы», только без кода вида документа. Обратите внимание исчез документ «ЖУТЬ.ххххх-хх 12 ПО1. Текст программы», потому что вместо него указаны тексты Модулей. В «ЖУТЬ.ххххх-хх 13 ПО1. Описание программы» определяется как из этих модулей «скомпоновать» требуемое ПО (программное изделие). Как лучше сделать как в 1 или как во 2 варианте. Каждый решает сам, но общая рекомендация такая: если модуль (программный блок) не будет использоваться в дальнейшем, то его не выносят из «ПО1. Текст программы», а если будет – то выносят как в варианте 2. Получим: ЖУТЬ.ххххх-хх ПО1 спецификация Документация общая ЖУТЬ.ххххх-хх 12 Модуль 1. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 1. Описание программы. ЖУТЬ.ххххх-хх 12 Модуль 2. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 2. Описание программы. ЖУТЬ.ххххх-хх 12 Модуль 3. Текст программы. ЖУТЬ.ххххх-хх 13 Модуль 3. Описание программы. … ЖУТЬ.ххххх-хх 12 ПО1. Текст программы. ЖУТЬ.ххххх-хх 13 ПО1. Описание программы. Спецификация имеет точно такой же регистрационный номер как у «Текст программы» и «Описание программы», только без кода вида документа. Можно на модули выпустить отдельные спецификации, что даже лучше. Тогда их спецификация будет выглядеть, как вариант 1 (никаких эксплутационных документов не требуется, только может быть ещё документ, описывающий привязку (установку) модуля в программы типа «Руководство программиста»). Получим: 3 ЖУТЬ.ххххх-хх ПО1 спецификация Документация общая ЖУТЬ.ххххх-хх 12 ПО1. Текст программы. ЖУТЬ.ххххх-хх 13 ПО1. Описание программы. Комплексы ЖУТЬ.ххххх-хх Модуль 1. ЖУТЬ.ххххх-хх Модуль 2. Спецификация имеет точно такой же регистрационный номер как у «Текст программы» и «Описание программы», только без кода вида документа. Обращаю внимание, что модули записаны как уже готовые «изделия» (номер изделия и его спецификации - это одно и тоже). Поэтому они записаны в разделе «Комплексы». Пока нет Спецификации, нет и изделия, поэтому нельзя в спецификацию на данное изделие записать само изделие! Идём далее. Было разработано программное обеспечение ПО2, которое состоит из двух ранее разработанных модулей №1 и №3: 4 ЖУТЬ.ххххх-хх ПО2 спецификация Документация общая ЖУТЬ.ххххх-хх 13 ПО2. Описание программы. Комплексы ЖУТЬ.ххххх-хх Модуль 1. ЖУТЬ.ххххх-хх 13 Модуль 3. Спецификация имеет точно такой же регистрационный номер как у «Описание программы», только без кода вида документа. Тут есть отличие: Модуль №1 задан спецификацией, Модуль № 3 текстом. В ГОСТ 19.202-78 сказано: «Для компонентов, не имеющих спецификации, основным программным документом является “Текст программы”». То есть такая запись может иметь место. Небольшое отступление. В ГОСТе 19.202-78 приведено: 4 Спецификация в общем случае должна содержать разделы: документация; комплексы; компоненты. Кода появился этот ГОСТ, программное обеспечение состояло из одной программы; потом из программы и «библиотек-модулей», которые загружались по мере необходимости; потом из целого набора программ, которые взаимодействовали друг с другом. Ранее и предполагалось заносить туда программные модули из «стандартных» библиотек. Сейчас модуль – сам может являться набором программ, поэтому к компонентам его можно не относить. А вот графические файлы, лог-файлы и прочие файлы, можно и нужно записывать в компоненты. Я просто предлагаю (конечно можно и не согласиться с этим) в раздел «Документация» вносить то, что разработано для данного ПО, то есть на этом уровне ПО выглядит как какие-то «исходные тексты», и только спецификация делает ПО – программным изделием. В раздел «Комплексы» требуемые модули для этого ПО, которые были разработаны ранее и имеют свой собственный индификационый номер. В раздел «компоненты» прочие служебные файлы. Если есть файлы, которые Вы не смогли включить ни один из выше перечисленных разделов, то создайте раздел «Прочие» (или «Дополнительное»), ГОСТ не запрещает создание новых разделов или подразделов, и включите это туда. В чём отличие такой записи модулей в примере 4? Отличие будет проявляться в документе «ЖУТЬ.ххххх-хх 13 ПО2. Описание программы». Для Модуля 1 – предполагается, что вся необходимая информация есть в спецификации на него, и в «ЖУТЬ.ххххх-хх 13 ПО2. Описание программы» можно указать только самое необходимое о модуле №1, а для Модуля 3 придётся вносить полное описание самого модуля и его «стыковку» с остальными (в данном случае с модулем 1). Какой метод лучше выбирать Вам. Можно поступить ещё проще вообще не выпускать спецификацию, а присвоить индификационые номера текстам программ, и в дальнейшем если, есть необходимость использовать только эти номера. Вы – автор своей документации и решать это Вам. Прочитав всё это, у Вас возникает вопрос: «А где различные руководства, инструкции, хелпы? Куда их записывать?». Ответ найдёте в следующем разделе. Спецификация «на вынос» Продукты производятся для «внутреннего» и для «внешнего» потребления. Что касается программных продуктов, то внутренне потребление – это, когда разработанное ПО будет использовать в нутрии организации как «самостоятельная программа» или для создания другого ПО. «Внешнее» - потребление, это когда ПО будет передано заказчику или реализовано потребителю. Здесь на свет появляется – эксплутационная документация (это и есть различные руководства, инструкции, хелпы и не только). Ниже будут представлены примеры Спецификаций для «внешнего» потребления. Для ПО, предназначенного для создания другого ПО, вполне достаточно выпустить спецификацию, как указано выше, ведь его эксплуатация как-то не подразумевается. Хотя если есть в этом необходимость можно выпустить и полный пакет документов (это может быть и «правильнее», но зачем, если это не требуется?). Было разработано ПО, которое передаётся заказчику или потребителю. 5 ЖУТЬ.ххххх-хх ПО1 спецификация Документация общая ЖУТЬ.ххххх-хх 12 ПО1. Текст программы. ЖУТЬ.ххххх-хх 13 ПО1. Описание программы. ЖУТЬ.ххххх-хх 20 ПО1. Ведомость эксплутационных документов. Остальные разделы (комплексы комплекты), если они есть, то их содержание как в примерах выше. Появился новый документ: «ЖУТЬ.ххххх-хх 20 ПО1. Ведомость эксплутационных документов». Этот документ и связывает разработанное Вами ПО с «внешним миром». В нем записаны документы, которые определяют: - какая копия Вашего ПО записана на конкретном носителе и упакованного в конкретную упаковку. - как надо эксплуатировать Ваше ПО и что для этого необходимо. Оказывается это не так сложно создать документ «Спецификация» для программного изделия. Ведомость эксплутационных документов и формуляр для программного изделия будут рассмотрены в «Главе 2. Ведомость эксплутационных документов и формуляр». Общие замечания по главе 1. 1. В тексте не говорилось, но подразумевалось, что в организации есть «Книга учёта программного обеспечения». В ней ведётся учёт разработанного ПО, то есть как минимум должны быть запись. содержащия: индификационный номер; тип документа, которому этот номер присвоен (текст программы или спецификация). Надо понимать, что номер (в основной части без кода типа документа) текста и спецификации могут совпадать, а могут и не совпадать, если в последнем случае использовались ранее разработанное ПО, для создания нового ПО, если совпадают, то записывают спецификацию; фамилию, того кто сделала это присвоение; дату, когда это было сделано присвоение, то есть эта дата может являться датой разработки. 2. Если говорить про книги учёта то надо указать и вторую из обязательных книг это - «Книга учёта копий программного обеспечения». В ней ведётся учёт количества выпущенного ПО, это аналог заводского номера. В книге должны быть записи, которые как минимум содержат: обозначение (примерно такой: ЖУТЬ.ххххх-хх); полное наименование ПО; номер текущей копии. Можно иметь книги учёта копий для каждого типа ПО, если номенклатура большая, а можно вести одну. В последнем случае номера копий для каждого вида ПО присваиваются свои. 3. Конечно, при желании можно всё внести в спецификацию на ПО: всю документацию, носителе и т.д. и т.п. С одной стороны вроде это хорошо и быстро и не надо создавать дополнительные какие-то документы. Да это тоже имеет место быть, как говориться: сделал и забыл. Есть понятие жизненного цикла документации: пока есть изделие (выпускается, эксплуатируется) – существует и документация на него. Со временем изделие может измениться – документация тоже меняется. В этом и заключается проблема спецификации. Её стараются составлять так, чтобы она не менялась для всего цикла существования изделия. Изменения спецификации автоматически приводят к появлению нового изделия или появлению модификации старого. В любом случая формально это новые изделия, а формальность значит в нашем мире много! В некоторых случаях это много значит. Пример, чтобы не «париться» Вы в спецификацию на ПО внесли всё: все документы (рабочие и эксплутационные), носители, упаковку, наклейки и т.п. и т.д. Вы получили на своё ПО лицензию, разные сертификаты на разрешения применения и т.д. Через некоторое время Вы решили, что экономически выгоднее вместо трёх CD (или CD были сняты с производства) выпускать ПО на одном DVD-диске. Это называется: приплыли. Вы не можете это сделать потому, что мгновенно теряете все лицензии и сертификаты на ПО так, как лицензирование и сертифицирование проводилось для ПО, для производства которого использовалось всё то, что указано в спецификации. (Спецификация – «рецепт приготовления» изделия). Формально все, что записано в спецификации обязательно для производства данного ПО. Любое измене в спецификации однозначно трактуется как получение нового изделия (новый «рецепт»). Случай другой, не внося никаких изменений в спецификацию, Вы решили поставлять ПО в новой более рекламно-выгодной упаковке. И вот в один не очень прекрасный день на предприятии (организации) произошёл сбой компьютера, на котором работала Ваша программа. Этот сбой повлёк большие экономические потери, загрязнение окружающей среды, человеческие жертвы (выбрать нужное). Почему произошёл сбой, никто не знает. Начинают разбираться, подымают всё документацию на оборудование и ПО, независимо где эта документация находится - у эксплуатирующей организации или разработчика. Вот тут и всплывёт, что Вы поставили ПО, которое не соответствует спецификации, то есть не лицензионное и не сертифицированное. Мало того, Вас могут обвинить в умышленном причинении вреда, Вы ведь знали, что ПО в другой упаковке на момент поставки. Поэтому очень ответственно надо подходить к тому, что записывать в спецификацию, если это необходимо для производства (и эксплуатации) изделия – то пишем, если нет – то нет. Ведь спецификация может «выстрелить» и через год, и через 10 лет, и через 50. Потом можете говорить, что угодно: и что Вы там уже как лет 5 не работаете; что Вас попросили её составить, - не важно, это не поможет, потому что вы автор этой спецификации.
