Документация программы что это

Документирование программ

Процесс разработки программного обеспечения сопровождается созданием большого количества документов. Эти документы сопровождают процессы:

• • управления разработкой программного обеспечения;
• • передачи информации между разработчиками программного обеспечения;
• • передачи пользователям информации, необходимой для экс- п л уатац им про грам м н о го обес печен ия.

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

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

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

Разработка проектной документации — в чем заключается процесс? Как это работает?

Ко второй группе относятся документы, включаемые в состав программного обеспечения. Эти документы в свою очередь делятся на две группы:

• • документация по сопровождению;
• • пользовательская документация.

В состав документации по сопровождению включаются документы, описывающие структуру и состав ПО: архитектуру программной системы, спецификации и тексты программных модулей, средства тестирования, а также руководство по сопровождению программной системы с указанием аппаратно- и программно-зависимых ее частей.

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

Источник: studme.org

Лекция 11. Документирование программных средств

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

При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы [11.1]:

• Документы управления разработкой ПС.
• Документы, входящие в состав ПС.

• Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС.
• Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.
• Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС.
• Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.
• Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

• Пользовательская документация ПС (П-документация).
• Документация по сопровождению ПС (С-документация).

11.2. Пользовательская документация программных средств.

• Общее функциональное описание ПС. Дает краткую характеристику функциональных возможностей ПС. Предназначено для пользователей, которые должны решить, насколько необходимо им данное ПС.
• Руководство по инсталяции ПС. Предназначено для администраторов ПС. Оно должно детально предписывать, как устанавливать системы в конкретной среде, в частности, должно содержать описание компьютерно-считываемого носителя, на котором поставляется ПС, файлы, представляющие ПС, и требования к минимальной конфигурации аппаратуры.
• Инструкция по применению ПС. Предназначена для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для ее изучения.
• Справочник по применению ПС. Предназначен для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска отдельных деталей.
• Руководство по управлению ПС. Предназначено для администраторов ПС. Оно должно описывать сообщения, генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти сообщения. Кроме того, если ПС использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру.

Источник: studfile.net

Почему техническая документация — это интересно

Документация на программу ГОСТ

Техническая документация на программный продукт (программу) разрабатывается в соответствии с требованиями ГОСТ ЕСПД и её можно разделить на следующие категории:

Программная документация – документация, содержащая сведения, необходимые для разработки, изготовления, эксплуатации и сопровождения программы (программного изделия).
Эксплуатационная документация – документация, необходимая для обеспечения функционирования и эксплуатации программного изделия.

Различают следующую документацию на программный продукт

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

Виды эксплуатационной документации и требования к ней

Ведомость эксплуатационных документов	Перечень эксплуатационных документов на программный продукт
Формуляр	Основные характеристики программы, комплектность и сведения об эксплуатации программы
Описание применения	Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Руководство системного программиста	Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Руководство программиста	Сведения для эксплуатации программы
Руководство оператора	Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание языка	Описание синтаксиса и семантики язык
Руководство по техническому обслуживанию	Сведения для применения тестовых и диагностических программ при обслуживании технических средств

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

Наши специалисты готовы разработать любой документы по требованиям ГОСТ ЕСПД.

Оформите заявку и задавайте все интересующие вас вопросы по телефону +7(499)755-74-33 e-mail Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или через форму заказа.

С целью персонализации сервисов, повышения удобства пользования веб-сайтом и проведения статистических исследований мы используем файлы «cookie». «Cookie» представляют собой небольшие файлы, содержащие информацию о настройках браузера. Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie, если вы не хотите использовать файлы «cookie», измените настройки браузера.

Источник: www.swrit.ru

Программная документация и ее разновидности

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

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

С точки зрения ЕСПД программы разделают на следующие виды (ГОСТ 19.101): Компонент – программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса Комплекс – программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса Также в ГОСТ 19.101 упоминается и такое важное понятие как «программное изделие», в п. 1.3 данного стандарта указано следующее: «документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия». А в соответствии с ГОСТ 19.004 программное изделие – это «Программа на носителе данных, являющаяся продуктом промышленного производства».

Отдельно необходимо сказать несколько слов о разработке технических условий на программу (а если точнее на программное изделие, этот термин мы поясняли немного выше). В том же ГОСТ 19-101 достаточно немного про них написано, а именно «2.7.

На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы. Технические условия разрабатывают на стадии «Рабочий проект». Т.е. получается, что если в техническом задании нет требований по разработке ТУ на программу, то вроде бы можно и не разрабатывать.

Однако довольно часто этот документ все же разрабатывают т.к. он достаточно полезен при изготовлении, контроле, приемке, а также и при сертификации программных изделий, особенно актуальна разработка технических условий на программу при работах в интересах государственного Заказчика (МО РФ и др.). Необходимо упомянуть и следующую особенность – в системе ЕСПД не существует стандарта, предъявляющего требования к разделам и содержанию ТУ на программное изделие. Обычно при разработке ТУ руководствуются требованиями «конструкторского» ГОСТ 2.114, применяя его основные требования, оформление же делают в соответствии с ГОСТ 19-106 (т.е. без рамки как в КД). Также необходимо упомянуть о том, что в зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102), предназначенные для разработки, сопровождения и эксплуатации программы.

Наши преимущества

Большой накопленный опыт

Профессиональное и быстрое оформление технической документации по стандартам.

Проекты любой сложности

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

Ответственный подход к работе

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

Полный цикл разработки документации

Изделие возможно изготовить на любом современном производстве.

Наши клиенты

Если у вас возникли вопросы обратитесь к нашим экспертам и получите грамотную консультацию.

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

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

Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.

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

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

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

Техническое задание и технический проект — два разных документа. Техническое задание отвечает на вопрос «что нужно сделать?», его составляет аналитик в самом начале проекта. Технический проект разрабатывает технический писатель. Этот документ создается после ТЗ и отвечает на вопрос «как нужно делать?».

Кто пишет техническую документацию

Обычно разработкой ТЗ занимается аналитик. Именно он общается с заказчиком / заинтересованным лицом и выявляет у него требования. В сложных случаях к процессу можно привлечь менеджера проекта, разработчиков, тестировщиков и других специалистов. Чем сложнее проект — тем больше требований к документации.

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

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

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

Кто такой технический писатель

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

Для этого он собирает информацию и материалы от участников проекта и документирует эти данные согласно требованиям заказчика, в том числе и в соответствии с ГОСТами. Речь идет о ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы». Также технический писатель следит за актуальностью технической информации, если это необходимо на длительных и сложных проектах.

Какая техническая документация нужна разработчику

Рассмотрим идеальный с точки зрения ГОСТа процесс разработки системы.
Все начинается с требований заказчика или заинтересованных лиц, которые необходимо выявить и обязательно зафиксировать в документе «Техническое задание».

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

Аналитик составляет ТЗ и согласует его со всеми заинтересованными сторонами. После того как собраны и утверждены все требования, можно приступать к созданию прототипов будущей системы и разработке программного обеспечения.

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

Технический проект — это совокупность документов, описывающих и обосновывающих все подходы, методы, архитектурные и технические решения, применяемые для создания системы. Например, в технический проект включают макеты интерфейсов, описание протоколов для интеграции со смежными системами и оборудованием, пользовательские сценарии, описание алгоритма и их формирование, структура серверов и баз данных, а также другие требования к системе и ее взаимодействию с другими внешними системами.
это далеко не все: существует много стандартов для написания технической документации, и для каждой страны они свои. В отечественных стандартах есть отдельно ГОСТ на создание автоматизированных работ и на программное изделие. Например, технический проект по ГОСТу 19 «Единая система программной документации» может включать в себя следующий перечень работ:

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

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

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

Когда составлять техническую документацию

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

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

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

На сегодняшний день технический писатель не самая распространенная специальность, но для серьезной компании-разработчика такой сотрудник не менее важен, чем, например, аналитик.
Техническая документация обязательно разрабатывается для госзаказчиков, она необходима и для долгосрочных проектов, на которых с бОльшей вероятностью могут меняться подрядчики. Имеет смысл создавать технический проект для ноу-хау технологий и проектов высокой сложности — документация понадобится отделу QA, чтобы отличить баги и фич.

• технический писатель
• техническое задание
• техническая документация

• Управление разработкой
• Подготовка технической документации

Источник: habr.com