Документация на программу ГОСТ
Техническая документация на программный продукт (программу) разрабатывается в соответствии с требованиями ГОСТ ЕСПД и её можно разделить на следующие категории:
Программная документация – документация, содержащая сведения, необходимые для разработки, изготовления, эксплуатации и сопровождения программы (программного изделия).
Эксплуатационная документация – документация, необходимая для обеспечения функционирования и эксплуатации программного изделия.
Различают следующую документацию на программный продукт
| Спецификация | Состав программы и документации на нее |
| Ведомость держателей подлинников | Перечень предприятий, на которых хранят подлинники программных документов |
| Текст программы | Запись программы с необходимыми комментариями |
| Описание программы | Сведения о логической структуре и функционировании программы |
| Программа и методика испытаний | Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля |
| Техническое задание | Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
| Пояснительная записка | Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
| Эксплуатационные документы | Сведения для обеспечения функционирования и эксплуатации программы |
Виды эксплуатационной документации и требования к ней
| Ведомость эксплуатационных документов | Перечень эксплуатационных документов на программный продукт |
| Формуляр | Основные характеристики программы, комплектность и сведения об эксплуатации программы |
| Описание применения | Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств |
| Руководство системного программиста | Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения |
| Руководство программиста | Сведения для эксплуатации программы |
| Руководство оператора | Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы |
| Описание языка | Описание синтаксиса и семантики язык |
| Руководство по техническому обслуживанию | Сведения для применения тестовых и диагностических программ при обслуживании технических средств |
Разработка программной документации
Наши специалисты готовы разработать любой документы по требованиям ГОСТ ЕСПД.
Оформите заявку и задавайте все интересующие вас вопросы по телефону +7(499)755-74-33 e-mail Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или через форму заказа.
С целью персонализации сервисов, повышения удобства пользования веб-сайтом и проведения статистических исследований мы используем файлы «cookie». «Cookie» представляют собой небольшие файлы, содержащие информацию о настройках браузера. Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie, если вы не хотите использовать файлы «cookie», измените настройки браузера.
Все права защищены © 2023. SWRIT — разработка технической документации
Техническая документация в разработке ПО: кто, зачем, когда и как описывает проект
Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.
Общаясь с большим количеством компаний, я все еще встречаю твердое убеждение в том, что написание технического задания для разработки ПО — пустая трата времени и денег. Мы в 65apps считаем иначе. Поэтому приведу несколько аргументов в пользу технической документации и расскажу, кто и как ее пишет.
Техническая документация позволяет оценить стоимость разработки и согласовать функциональность будущей системы. При возникновении споров о стоимости и сроках разработки той или иной фичи она может стать определенной гарантией для заказчика. С другой стороны, если возникнет потребность в развитии приложения, документация облегчит процесс доработки и даст четкое понимание, возможно ли встроить новую функциональность в существующую систему.
Другой пример — государственные организации или организации, чья деятельность ограничивается или подчиняется законам и надзорным органам. Они обязаны осуществлять разработку ПО по всем правилам и с соблюдением всех стандартов. В таких проектах техническая документация, подготовленная по ГОСТам, — необходимое условие.
И разумеется, грамотно составленная и актуальная документация необходима для того, чтобы каждый участник в процессе разработки мог обращаться к документам, если возникают вопросы по конкретной задаче или по всей системе в целом.
Техническое задание и технический проект — два разных документа. Техническое задание отвечает на вопрос «что нужно сделать?», его составляет аналитик в самом начале проекта. Технический проект разрабатывает технический писатель. Этот документ создается после ТЗ и отвечает на вопрос «как нужно делать?».
Кто пишет техническую документацию
Обычно разработкой ТЗ занимается аналитик. Именно он общается с заказчиком / заинтересованным лицом и выявляет у него требования. В сложных случаях к процессу можно привлечь менеджера проекта, разработчиков, тестировщиков и других специалистов. Чем сложнее проект — тем больше требований к документации. Серьезные заказчики из крупных корпораций и госсектора требуют составлять документацию в соответствии с ГОСТами, а это задача очень трудоемкая, требующая внимательности к деталям и постоянной вовлеченности в процесс. И это не только ТЗ, но и технический проект, полностью описывающий все используемые в разработке решения, подходы и методологии. На него также распространяются ГОСТы. Подготовкой такой документации должен заниматься специалист — технический писатель.
Для крупных проектов иметь в штате технического писателя просто необходимо. Разработка решений для крупных заказчиков может длиться год и более, это довольно долгий срок. За это время возникает достаточное количество изменений, провоцирующих обновление документации. Кроме того, любая долгосрочная разработка ПО предполагает развитие. В этом случае актуальная техническая документация позволит снизить риски, закладываемые в работу исполнителей.
Исключение может быть сделано для представителей госсектора. Таким организациям необязательно иметь в своем штате специалистов соответствующего профиля, так как при возникновении необходимости всегда можно обратиться к профессионалам, которые выполнят качественно свою работу.
Кто такой технический писатель
Строго сформулированного перечня должностных обязанностей технического писателя не существует: каждая компания формирует его сама, а иногда возлагает на такого специалиста и дополнительные задачи. Поэтому иногда бывает сложно даже определить род деятельности технического писателя. В нашей компании такой специалист составляет документацию, необходимую для дальнейшей разработки программного обеспечения.
Для этого он собирает информацию и материалы от участников проекта и документирует эти данные согласно требованиям заказчика, в том числе и в соответствии с ГОСТами. Речь идет о ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы». Также технический писатель следит за актуальностью технической информации, если это необходимо на длительных и сложных проектах.
Какая техническая документация нужна разработчику
Рассмотрим идеальный с точки зрения ГОСТа процесс разработки системы.
Все начинается с требований заказчика или заинтересованных лиц, которые необходимо выявить и обязательно зафиксировать в документе «Техническое задание».
Техническое задание — это документ, регламентирующий бизнес-цели, общее описание системы, объем работ, границы проекта, а также порядок разработки, оценки и приемки. Данный документ отвечает нам на вопрос «что нужно сделать?» и фактически является постановкой задачи.
Аналитик составляет ТЗ и согласует его со всеми заинтересованными сторонами. После того как собраны и утверждены все требования, можно приступать к созданию прототипов будущей системы и разработке программного обеспечения.
На этом этапе начинается разработка макетов, сценариев, архитектуры и др. Раз уж мы говорим об эталонном процессе разработки, то все это должно быть описано в техническом проекте, который также использует часть информации из ТЗ.
Технический проект — это совокупность документов, описывающих и обосновывающих все подходы, методы, архитектурные и технические решения, применяемые для создания системы. Например, в технический проект включают макеты интерфейсов, описание протоколов для интеграции со смежными системами и оборудованием, пользовательские сценарии, описание алгоритма и их формирование, структура серверов и баз данных, а также другие требования к системе и ее взаимодействию с другими внешними системами.
это далеко не все: существует много стандартов для написания технической документации, и для каждой страны они свои. В отечественных стандартах есть отдельно ГОСТ на создание автоматизированных работ и на программное изделие. Например, технический проект по ГОСТу 19 «Единая система программной документации» может включать в себя следующий перечень работ:
- уточнение структуры входных и выходных данных,
- разработка алгоритма решения задачи,
- определение формы представления входных и выходных данных,
- определение семантики и синтаксиса языка,
- разработка структуры программы,
- окончательное определение конфигурации технических средств,
- разработка плана мероприятий по разработке и внедрению программ,
- разработка пояснительной записки,
- согласование и утверждение технического проекта.
Теперь, когда есть четкое понимание архитектуры, функциональности и дизайна проекта, можно перейти к разработке системы и ее тестированию.
На этапе тестирования, помимо проверки работоспособности системы, проверяется также выполнение всех требований, зафиксированных в документах, что позволяет разрешить спорные ситуации с заказчиком.
Когда составлять техническую документацию
Выше я описала идеальный процесс создания программного обеспечения, но иногда некоторые документы технического проекта составляют уже после этапа разработки.
Есть проекты, в которых важно иметь полную документацию до начала работ. Это касается решений с высокими требованиями к безопасности, соблюдению законодательства и т. д. Например, мобильные приложения для банков. В этом случае важно сначала продумать все детали системы (информационная безопасность клиентов и самого банка, соответствие законам). На это уйдет больше времени, но позволит избежать финансовых и репутационных рисков.
Если разработка идет по методологии Agile, то нет смысла прописывать всю документацию до старта работ. Если заказчику важно работать по спринтам и контролировать ход разработки, документацию можно дописывать параллельно основному процессу.
В нашей компании возможны оба варианта — мы умеем адаптироваться под условия и пожелания заказчика.
На сегодняшний день технический писатель не самая распространенная специальность, но для серьезной компании-разработчика такой сотрудник не менее важен, чем, например, аналитик.
Техническая документация обязательно разрабатывается для госзаказчиков, она необходима и для долгосрочных проектов, на которых с бОльшей вероятностью могут меняться подрядчики. Имеет смысл создавать технический проект для ноу-хау технологий и проектов высокой сложности — документация понадобится отделу QA, чтобы отличить баги и фич.
- технический писатель
- техническое задание
- техническая документация
- Управление разработкой
- Подготовка технической документации
Разработка технической документации для программного обеспечения
Документация для программного обеспечения – это справочный текст и визуальная информация, описывающие и отображающие процесс разработки, производства, эксплуатации и сопровождения программного продукта, его потребительские свойства и технические характеристики.
Виды документации для программного обеспечения
В соответствии с таким определением, техническая документация по ПО состоит из четырёх основных типов:
• Проектная – включает описание основных положений, используемых при создании ПО и рабочей среды.
• Техническая – алгоритмы, код, интерфейсы, АРI.
• Пользовательская – руководства для пользователей программы.
• Маркетинговая – содержащая рекламную информацию о продукте.
Проектная документация, как правило, программный продукт описывает в общих чертах. Например, программист в проекте может обосновать, почему структуры данных именно таким (а не иным) образом организованы. Почему именно таким образом сконструирован тот или иной класс. В проекте выделяются паттерны. Часто даются указания, как выполнять модернизацию программы.
Техническая документация (все указанные виды которой можно заказать в компании «ТехРайтКонсалт»). не только указывает конкретные коды. Она, как правило, также описывает различные аспекты того, что этот код делает. Она имеет явно выраженный технический характер и используется в основном для описания и определения API, алгоритмов и структур данных. При её составлении возможно использование генераторов документации (Doxygen, NDoc, javadoc и др.), что даёт возможность постоянно поддерживать такую документацию в актуальном состоянии. В последнем случае техническая документация является частью исходного кода. Тогда одни и те же инструменты можно использовать как для сборки программы, так и для сборки в то же время документации к ней.
Хорошая пользовательская документация состоит из:
• вводного руководства, где рассматриваются общие вопросы выполнения типичных задач;
• тематического, где каждая глава посвящена разъяснению какого-либо раздела эксплуатации программы;
• алфавитного справочника, для опытных пользователей, хорошо знающих, что нужно искать.
Маркетинговая документация используется для рекламы как самого программного продукта и его составляющих, так и других программных продуктов компании. Она часто информирует покупателя о свойствах продукта, объясняет его преимущества перед конкурирующими решениями. Часто бывает так, что именно коробка продукта и другая маркетинговая информация дают самое чёткое и простое представление о способах использования и возможностях программы.
Стандарты для разработки ПО
Основой для создания любой документации на программные продукты служат стандарты.
Современных стандартов по разработке технической документации для программного обеспечения в Российской Федерации до сих пор нету ещё со времён СССР. Хотя стандарты и модернизируются. Последнее обновление ГОСТ 2.015-2013.
В таких условиях IT-компании вопрос разработки документации для программного обеспечения решают по-разному. Одни пытаются копировать и внедрять западные стандарты. Другие – использовать отечественные. Третьи – создают свои собственные.
Актуальные вопросы при разработке документации ПО
В любом случае актуальными при разработке технической документации для программного обеспечения будут такие основные вопросы:
• Какова нормативная база и как её следует применять?
• Какая именно документация нужна среди огромного количества документов?
Остановимся на этих вопросах подробнее.
В настоящее время действуют следующие стандарты документирования:
ГОСТ 19.201 ( Единая система программной документации (ЕСПД);
ГОСТ 2.015-2013 (Единая система конструкторской документации (ЕСКД);
ГОСТ 34.602 (Комплекс стандартов на автоматизированные системы (КСАС).
Указанные стандарты с 2006 года применять не обязательно. В соответствии с нормами Федерального закона № 184-ФЗ «О техническом регулировании» вместо стандартов применяются специально разработанные технические регламенты. Но ГОСТы по-прежнему нужно применять при разработке документации для государственных заказчиков, а также для крупных организаций (особенно с государственным участием). Последние, как правило, разрабатывают собственные стандарты на основе указанных ГОСТов.
Следует также помнить, что в соответствии с ФЗ «О техническом регулировании» национальные стандарты имеют всегда приоритет над международными. То есть, использовать международные стандарты можно лишь в случаях, если последние не противоречат национальным! Благо, свободы действий отечественные стандарты предоставляют намного больше зарубежных. Последние пересматриваются каждые 5-7 лет и характеризуются большей конкретизацией, но отображают весь актуальный опыт за указанный период времени. Отечественные же (не имея столь разработанной конкретики) характеризуются глубокой разработкой концептуальных моментов. Это позволяет создавать на их основе неплохие стандарты в соответствии с требованиями времени.
Техническое задание
Основным документом на создание программного продукта является технические задание, которое используется для разработки (проектирования) программы и её испытания.
В ТЗ устанавливается назначение программного продукта, что разрабатывается, его технические характеристики, качество и технико-экономические показатели, а также указания по выполнению стадий документации (конструкторской, программной, технологической и т.п.), её состав и другие специальные требования.
Техническое задание – это юридический документ, который в качестве приложения включается в договор на выполнение проектных работ по созданию программы и является основой такого договора.
ТЗ может быть выполнено как в качестве эскизного проекта (описываются структура системы и её функции без технологий реализации решения); так и в форме технического проекта (детальное описание выбранной технологии реализации проекта). ТЗ может составляться также в общих чертах (для инвесторов, к примеру) и с самой подробной детализацией (для программистов и в иных случаях).
Часто ТЗ является единственным документом для описания разрабатываемого программного продукта. В таких случаях особо важно, чтобы оно разрабатывалось и изготовлялось профессионалами.
Автор: Администрация
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
При подготовке материала использовались источники:
https://www.swrit.ru/dokumentaciya-na-programmy.html
https://habr.com/ru/articles/507414/
https://metallicheckiy-portal.ru/articles/texnologii/razrabotka_texnicheskoi_dokumentacii_dla_programmno