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

Unified system for program documentation. Program description.

Дата введения 1980-01-01

Постановлением Государственного комитета CCCР по стандартам от 18 декабря 1978 г. N 3350 дата введения установлена 01.01.80

ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в сентябре 1981 г. (ИУС 11-81).

Составление информационной части (аннотации и содержания) является обязательным.

3. Описание программы должно содержать следующие разделы:

описание логической структуры;

используемые технические средства;

вызов и загрузка;

В зависимости от особенностей программы допускается вводить дополнительные разделы или объединять отдельные разделы.

4. В разделе «Общие сведения» должны быть указаны:

обозначение и наименование программы;

программное обеспечение, необходимое для функционирования программы;

языки программирования, на которых написана программа.

5. В разделе «Функциональное назначение» должны быть указаны классы решаемых задач и (или) назначение программы и сведения о функциональных ограничениях на применение.

Оформления Дизайн Документа / Первый Опыт | Разработка игр

6. В разделе «Описание логической структуры» должны быть указаны:

структура программы с описанием функций составных частей и связи между ними;

связи программы с другими программами.

Описание логической структуры программы выполняют с учетом текста программы на исходном языке.

3-6. (Измененная редакция, Изм. N 1).

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

8. В разделе «Вызов и загрузка» должны быть указаны:

способ вызова программы с соответствующего носителя данных;

входные точки в программу.

Допускается указывать адреса загрузки, сведения об использовании оперативной памяти, объем программы.

9. В разделе «Входные данные» должны быть указаны:

характер, организация и предварительная подготовка входных данных;

формат, описание и способ кодирования входных данных.

10. В разделе «Выходные данные» должны быть указаны:

характер и организация выходных данных;

формат, описание и способ кодирования выходных данных.

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

7-12. (Введены дополнительно, Изм. N 1).

Источник: engenegr.ru

Разработка технической документации для программного обеспечения

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

Читайте также:
Как выбрать программу на фануке

Создание документа/Уроки Adobe Illustrator 01

Виды документации для программного обеспечения

В соответствии с таким определением, техническая документация по ПО состоит из четырёх основных типов:

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

• Техническая – алгоритмы, код, интерфейсы, АРI.

• Пользовательская – руководства для пользователей программы.

• Маркетинговая – содержащая рекламную информацию о продукте.

Проектная документация, как правило, программный продукт описывает в общих чертах. Например, программист в проекте может обосновать, почему структуры данных именно таким (а не иным) образом организованы. Почему именно таким образом сконструирован тот или иной класс. В проекте выделяются паттерны. Часто даются указания, как выполнять модернизацию программы.

Техническая документация (все указанные виды которой можно заказать в компании «ТехРайтКонсалт»). не только указывает конкретные коды. Она, как правило, также описывает различные аспекты того, что этот код делает. Она имеет явно выраженный технический характер и используется в основном для описания и определения API, алгоритмов и структур данных.

При её составлении возможно использование генераторов документации (Doxygen, NDoc, javadoc и др.), что даёт возможность постоянно поддерживать такую документацию в актуальном состоянии. В последнем случае техническая документация является частью исходного кода. Тогда одни и те же инструменты можно использовать как для сборки программы, так и для сборки в то же время документации к ней.

Хорошая пользовательская документация состоит из:

• вводного руководства, где рассматриваются общие вопросы выполнения типичных задач;

• тематического, где каждая глава посвящена разъяснению какого-либо раздела эксплуатации программы;

• алфавитного справочника, для опытных пользователей, хорошо знающих, что нужно искать.

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

Читайте также:
Прекращена работа программы space engineers

Стандарты для разработки ПО

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

Современных стандартов по разработке технической документации для программного обеспечения в Российской Федерации до сих пор нету ещё со времён СССР. Хотя стандарты и модернизируются. Последнее обновление ГОСТ 2.015-2013.

В таких условиях IT-компании вопрос разработки документации для программного обеспечения решают по-разному. Одни пытаются копировать и внедрять западные стандарты. Другие – использовать отечественные. Третьи – создают свои собственные.

Актуальные вопросы при разработке документации ПО

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

• Какова нормативная база и как её следует применять?

• Какая именно документация нужна среди огромного количества документов?

Остановимся на этих вопросах подробнее.

В настоящее время действуют следующие стандарты документирования:

ГОСТ 19.201 ( Единая система программной документации (ЕСПД);

ГОСТ 2.015-2013 (Единая система конструкторской документации (ЕСКД);

ГОСТ 34.602 (Комплекс стандартов на автоматизированные системы (КСАС).

Указанные стандарты с 2006 года применять не обязательно. В соответствии с нормами Федерального закона № 184-ФЗ «О техническом регулировании» вместо стандартов применяются специально разработанные технические регламенты. Но ГОСТы по-прежнему нужно применять при разработке документации для государственных заказчиков, а также для крупных организаций (особенно с государственным участием). Последние, как правило, разрабатывают собственные стандарты на основе указанных ГОСТов.

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

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

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

Основным документом на создание программного продукта является технические задание, которое используется для разработки (проектирования) программы и её испытания.

Читайте также:
Как создать автозагрузку программ

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

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

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

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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Источник: metallicheckiy-portal.ru

Стандартизация в области документирования программных средств

Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование?

На эти и массу других вопросов когда-то отвечали государственные стандарты на программную документацию — комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как, казалось — неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных.

Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текст своих программ. Это не значит, что исчезла необходимость в их документировании. Более того, вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств (ПС), продолжают задавать постоянно. Спрашивают и о том, есть ли обязательные для применения стандарты (особенно остро стоит этот вопрос, когда разработка выполняется по заказу государственной организации или предприятия). Интересуются и тем, где можно купить имеющиеся стандарты.

Рейтинг
( Пока оценок нет )
Загрузка ...
EFT-Soft.ru