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

Август 10, 2022

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

Содержание

2. Документация на ПО Документация - печатный текст, сопровождающий программное обеспечение для объяснения принципов его функционирования или
4. Классификация программной документации:
5. Типы документации Документация на процесс разработки (англ. process documentation) - внутренняя документация —используется в процессе разработки
6. Документация на продукты разработки (англ. product documentation) - внешняя документация— всевозможные руководства для пользователей, техническое задание,
7. Документирование процессов разработки Виды документации: ▶ планы, оценки затрат и расписания: составляются менеджерами для управления процессом
8. Пользовательская документация Пользовательская документация (англ. user documentation) документы, описывающие использование программной системы конечными пользователями. Организация пользовательской
9. Пользовательская документация ПС (user documentation) необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации
10. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может
11. Типичный состав пользовательской документации для достаточно больших ПС: Общее функциональное описание ПС. Дает краткую характеристику функциональных
12. Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима,
13. Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы: Внешнее
14. Документация второй группы содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС
15. Стандарты Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации
16. Единая система программной документации (ЕСПД) — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и
17. К числу основных недостатков ЕСПД можно отнести: • ориентацию на единственную «каскадную» модель жизненного цикла ПС;
18. ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС. До
19. Стандарты ЕСПД подразделяют на группы:
20. Обозначение стандарта ЕСПД должно состоять из: числа 19 (присвоенных классу стандартов ЕСПД); одной цифры (после точки),
21. Перечень документов ЕСПД 1. ГОСТ 19.001-77 ЕСПД. Общие положения. 2. ГОСТ 19.101-77 ЕСПД. Виды программ и
22. Руководство программиста (ГОСТ 19504-79) Руководство программиста должно содержать следующие разделы: назначение и условия применения программ; характеристика
23. Описание программы (гост 19.402-78) Основная часть документа должна состоять из вводной части и следующих разделов: введение;
24. Программа и методика испытаний (гост 19.301-79) В этом документе содержится описание того, что и как необходимо
25. Гост 19.102-77 ЕСПД. Стадии разработки программных средств. Данный стандарт устанавливает стадии разработки программ и программной документации
31. Наряду с комплексом ЕСПД официальная нормативная база РФ в области документирования ПС и в смежных областях
32. Документация в гибкой методологии Недостатки традиционного подхода к документированию: ▶ Производство документации и поддержка документов в
33. Структура документации Основной стандарт: IEEE 1063 Standard for Software User Documentation [2001]. Структура документации на ПО:
34. Стиль документации ▶ проверка грамматики (присутствует в современных средах разработки); ▶ короткие и ясные предложения; короткие
35. Форматы документации Печатная документация; ▶ Электронная документация: ▶ локальные файлы (plain text, Markdown, HTML, PDF, …);
36. Онлайн-документация Преимущества: ▶ доступность для потребителей, актуальность документации; ▶ гипертекстовая связанность в пределах документации и с
37. Генерация документации Генератор документации — программа — программа или пакет программ — программа или пакет программ,
38. Этапы генерации документации ( MVC): 1. определение используемых представлений для исходных файлов; 2. создание синтаксического дерева
39. Для составления документации используются комментарии к классам, полям, методам вида /** … */. ▶ Для секционирования
40. Пример документации: Javadoc
42. Сертификация программ Сертификация программного обеспечения – это подтверждение его надежности, мобильности, эффективности, корректности и заявленных свойств.
43. Сертификация программ может быть проведена для таких видов продукции: сетевое программное обеспечение; системы управления базой данных;
45. Скачать презентацию

Слайд 2

Документация на ПО
Документация - печатный текст, сопровождающий программное обеспечение для объяснения

принципов его функционирования или использования.
Цели документирования:
▶ посредничество между разработчиками ПО;
▶ упрощение сопровождения и эволюции;
▶ информация для планирования и оценки затрат в процессе разработки;
▶ инструкции по использованию и управлению программной системой;
▶ основание для сертификации системы

Слайд 3

Слайд 4

Классификация программной документации:

Слайд 5

Типы документации
Документация на процесс разработки (англ. process documentation) - внутренняя документация

—используется в процессе разработки программного обеспечения и недоступна конечному пользователю (различные внутренние стандарты, комментарии исходного текста, технологии программирования и т.д.):
▶ планы разработки;
▶ расписания;
▶ документы оценки качества процессов разработки;
▶ организационные и проектные стандарты.

Слайд 6

Документация на продукты разработки (англ. product documentation) - внешняя документация— всевозможные

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

Слайд 7

Документирование процессов разработки
Виды документации:
▶ планы, оценки затрат и расписания: составляются

менеджерами для управления процессом разработки;
▶ отчеты: использование ресурсов на различных этапах создаются менеджерами;
▶ стандарты: ограничения на процесс разработки (специфичные для организации или национальные / международные);
▶ рабочие документы (working paper): особенности архитектуры системы, стратегии Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС. ;
▶ общение между разработчиками и менеджерами.
Большая часть документации на процесс разработки может быть заменена неформальными дискуссиями между разработчиками, менеджерами и заказчиком. Необходимая документация на процесс разработки:
▶ явно определенная договором с заказчиком;
▶ необходимая для сертификации системы;
▶ расписание тестирования (заменяется автоматическими тестами);
▶ рабочие документы (могут быть выделены в отдельные статьи).

Слайд 8

Пользовательская документация
Пользовательская документация (англ. user documentation) документы, описывающие использование программной системы

конечными пользователями. Организация пользовательской документации:
▶ учебные пособия описание шагов для решения определенных задач с помощью программной системы;
▶ темы объединение логически связанных документов в главы / разделы, описывающие определенный аспект ПО;
▶ справочники перечень выполняемых системой функций.

Слайд 9

Пользовательская документация ПС (user documentation) необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой

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

Слайд 10

Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной

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

Слайд 11

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

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

Слайд 12

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима,

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

Слайд 13

Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС.

Она включает следующие документы:
Внешнее описание ПС (Requirements document).
Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы (подсистемы).
Для каждой программы ПС описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
Для каждого модуля его спецификация и описание его строения (design description).
Тексты модулей на выбранном языке программирования (program source code listings).
Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ. Для обеспечения приемлемого качества этой документации полезно следовать общепринятым рекомендациям и стандартам

Слайд 14

Документация второй группы содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС

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

Слайд 15

Стандарты
Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов

Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.
Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС.
Стандарты ЕСПД носят рекомендательный характер.
В соответствии с Законом РФ «О стандартизации» эти стандарты становятся обязательными при условии заключения контракта на разработку или поставку программного продукта.

Слайд 16

Единая система программной документации (ЕСПД) — это комплекс государственных стандартов, устанавливающих

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

Слайд 17

К числу основных недостатков ЕСПД можно отнести:
• ориентацию на

единственную «каскадную» модель жизненного цикла ПС;
• отсутствие четких рекомендаций по документированию характеристик качества ПС;
• отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например ЕСКД;
• нечетко выраженный подход к документированию ПС как товарной продукции;
• отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю;
• отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.

Слайд 18

ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на

процессы жизненного цикла ПС. До пересмотра всего комплекса многие стандарты могут с пользой применяться в практике документирования ПС:

стандарты ЕСПД вносят элемент упорядочения в процесс документирования ПС;
предусмотренный стандартами ЕСПД состав программных документов вовсе не такой «жесткий», как некоторым кажется:
стандарты позволяют вносить в комплект документации на ПС дополнительные виды программных документов (ПД), необходимых в конкретных проектах, и исключать многие ПД;
стандарты ЕСПД позволяют вдобавок мобильно изменять структуры и содержание установленных видов ПД исходя из требований заказчика и пользователя.
При этом стиль применения стандартов может соответствовать современному общему стилю адаптации стандартов к специфике проекта: заказчик и руководитель проекта выбирают уместное в проекте подмножество стандартов и ПД, дополняют выбранные ПД нужными разделами и исключают ненужные, привязывают создание этих документов к той схеме ЖЦ, которая используется в проекте.

Слайд 19

Стандарты ЕСПД подразделяют на группы:

Слайд 20

Обозначение стандарта ЕСПД должно состоять из:
числа 19 (присвоенных классу стандартов

ЕСПД);
одной цифры (после точки), обозначающей код классификационной группы стандартов, указанной в таблице;
двузначного числа (после тире), указывающего год регистрации стандарта.

Слайд 21

Перечень документов ЕСПД
1. ГОСТ 19.001-77 ЕСПД. Общие положения.
2. ГОСТ 19.101-77 ЕСПД. Виды

программ и программных документов.
3.  ГОСТ 19.102-77 ЕСПД. Стадии разработки.
4.  ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
5.  ГОСТ 19.104-78 ЕСПД. Основные надписи.
6.  ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
7.  ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
8.  ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
9.  ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
10.  ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.
11.  ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
12.  ГОСТ 19.402-78 ЕСПД. Описание программы.
13.  ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
14.  ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
15.  ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
16.  ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
17.  ГОСТ 19.504-79 ЕСПД. Руководство программиста.
18.  ГОСТ 19.505-79 ЕСПД. Руководство оператора.
19.  ГОСТ 19.506-79 ЕСПД. Описание языка.
20.  ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
21.   ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
22.   ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
23.    ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Слайд 22

Руководство программиста (ГОСТ 19504-79)
Руководство программиста должно содержать следующие разделы:
назначение и

условия применения программ;
характеристика программы;
обращение к программе;
входные и выходные данные;
сообщения.
В разделе «Назначение и условия применения программ» должны быть указаны назначение и функции, выполняемые программой, условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программного обеспечению и т.п.).
В разделе «Характеристика программы» должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т.п.).
В разделе «Обращение к программе» должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.).
В разделе «Входные и выходные данные» должно быть приведено описание организации используемой входной и выходной информации и, при необходимости, ее кодирования.
В разделе «Сообщения» должны быть указаны тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.

Слайд 23

Описание программы (гост 19.402-78)
Основная часть документа должна состоять из вводной части

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

Слайд 24

Программа и методика испытаний (гост 19.301-79)
В этом документе содержится описание того,

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

Слайд 25

Гост 19.102-77 ЕСПД. Стадии разработки программных средств.
Данный стандарт устанавливает стадии разработки

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

Слайд 26

Слайд 27

Слайд 28

Слайд 29

Слайд 30

Слайд 31

Наряду с комплексом ЕСПД официальная нормативная база РФ в области документирования

ПС и в смежных областях включает еще ряд стандартов Они разработаны на основе прямого применения международных стандартов ИСО: ГОСТ Р ИСО/МЭК 929493 Информационная технология. Руководство по управлению документированием программного обеспечения. Устанавливает эффективное управление документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990.
ГОСТ Р ИСО/МЭК 912693 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт определяет шесть комплексных характеристик, которые описывают качество ПО: функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991.
ГОСТ Р ИСО 912794 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. В контексте настоящего стандарта под потребительским программным пакетом (ПП) понимается «программная продукция, спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое». Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП. Стандарт полностью соответствует международному стандарту ИСО 9127:1989.

Слайд 32

Документация в гибкой методологии
Недостатки традиционного подхода к документированию:
▶ Производство документации

и поддержка документов в актуальном состоянии занимает много времени и средств и приводит к замедлению процесса разработки.
▶ Требования к ПО меняются настолько быстро, что документация устаревает практически сразу после написания.
Необходимые виды документации:
▶ пользовательская документация;
▶ обоснование архитектурных решений;
▶ документация критических систем.

Слайд 33

Структура документации
Основной стандарт: IEEE 1063 Standard for Software User Documentation [2001].

Структура документации на ПО:
1. данные, позволяющие идентифицировать документ (заголовок, дата составления и т. п.);
2. содержание;
3. список иллюстраций и таблиц (опционально);
4. введение назначение документа и краткое описание содержимого;
5. информация по использованию советы по эффективному использованию различными группами пользователей (новичками, опытными пользователями, администраторами, …);
6. концепция ПО описание вариантов использования программной системы;
7. команды описание команд, поддерживаемых системой;
8. выдаваемые программой сообщения об ошибках и способы их устранения; 9. словарь используемых в документе специфичных терминов;
10. связанные документы и информационные ресурсы;
11. навигация (особенно для электронных документов);
12. алфавитный указатель по командам;
13. поиск по содержанию (для электронных документов).

Слайд 34

Стиль документации
▶ проверка грамматики (присутствует в современных средах разработки);
▶ короткие

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

Слайд 35

Форматы документации
Печатная документация;
▶ Электронная документация:
▶ локальные файлы (plain text,

Markdown, HTML, PDF, …);
▶ интегрируемая в общесистемную справочную систему (man, info, …);
▶ интегрируемая в среду разработки (напр., исходные Java-файлы или javadoc-архивы при разработке на Java в Eclipse).
▶ Онлайн-документация:
▶ поддерживаемая разработчиком (руководство по установке / Getting started / справочные руководства, …);
▶ Web 2.0-документация, поддерживаемая пользователями (wiki, блоги, вопросы на stackoverflow, …)

Слайд 36

Онлайн-документация
Преимущества:
▶ доступность для потребителей, актуальность документации;
▶ гипертекстовая связанность в

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

Слайд 37

Генерация документации
Генератор документации — программа — программа или пакет программ — программа или пакет программ, позволяющая получать документацию — программа или пакет программ, позволяющая получать документацию, предназначенную

для программистов — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям(полученным на выходе компилятора).
Обычно генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам и их членам/свойствам/методам, процедурам/функциям и т. п.). В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев. На основе всей собранной информации формируется готовая документация, как правило, в одном из общепринятых форматов — HTMLОбычно генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам и их членам/свойствам/методам, процедурам/функциям и т. п.). В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев. На основе всей собранной информации формируется готовая документация, как правило, в одном из общепринятых форматов — HTML, HTMLHelpОбычно генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам и их членам/свойствам/методам, процедурам/функциям и т. п.). В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев. На основе всей собранной информации формируется готовая документация, как правило, в одном из общепринятых форматов — HTML, HTMLHelp, PDFОбычно генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам и их членам/свойствам/методам, процедурам/функциям и т. п.). В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев. На основе всей собранной информации формируется готовая документация, как правило, в одном из общепринятых форматов — HTML, HTMLHelp, PDF, RTF и других.

Слайд 38

Этапы генерации документации ( MVC):
1. определение используемых представлений для исходных файлов;
2.

создание синтаксического дерева для исходных файлов;
3. создание моделей для элементов программы (классов, методов, ...);
4. генерация представления на основе моделей (напр., HTML-страниц).
Примеры генераторов документации:
▶ Javadoc (основной для Java);
▶ Sphinx (основной для Python);
▶ Doxygen (основной для С / С++).

Слайд 39

Для составления документации используются комментарии к классам, полям, методам вида /**

… */.
▶ Для секционирования комментариев применяются теги:
▶ @param для описания параметров методов;
▶ @return для описания возвращаемого значения метода;
▶ @throws для условий порождения исключений;
▶ @since для установления версии ПО, в которой появился класс / метод.
▶ Для маркировки применяются HTML-теги.
▶ Теги @link, @see позволяют ссылаться на другие элементы документации.

Слайд 40

Пример документации: Javadoc

Слайд 41

Слайд 42

Сертификация программ
Сертификация программного обеспечения – это подтверждение его надежности, мобильности, эффективности, корректности

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

Слайд 43

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

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

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

Содержание

Документация на ПОДокументация - печатный текст, сопровождающий программное обеспечение для объяснения

Классификация программной документации:

Типы документацииДокументация на процесс разработки (англ. process documentation) - внутренняя документация

Документация на продукты разработки (англ. product documentation) - внешняя документация— всевозможные

Документирование процессов разработкиВиды документации: ▶ планы, оценки затрат и расписания: составляются

Пользовательская документацияПользовательская документация (англ. user documentation) документы, описывающие использование программной системы

Пользовательская документация ПС (user documentation) необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой

Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной

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

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима,

Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС.

Документация второй группы содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС

СтандартыОснову отечественной нормативной базы в области документирования ПС составляет комплекс стандартов

Единая система программной документации (ЕСПД) — это комплекс государственных стандартов, устанавливающих

К числу основных недостатков ЕСПД можно отнести: • ориентацию на

ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на

Стандарты ЕСПД подразделяют на группы:

Обозначение стандарта ЕСПД должно состоять из: числа 19 (присвоенных классу стандартов

Перечень документов ЕСПД1. ГОСТ 19.001-77 ЕСПД. Общие положения.2. ГОСТ 19.101-77 ЕСПД. Виды

Руководство программиста (ГОСТ 19504-79) Руководство программиста должно содержать следующие разделы: назначение и

Описание программы (гост 19.402-78) Основная часть документа должна состоять из вводной части

Программа и методика испытаний (гост 19.301-79)В этом документе содержится описание того,

Гост 19.102-77 ЕСПД. Стадии разработки программных средств.Данный стандарт устанавливает стадии разработки