Что такое документирование процесса разработки пс
Primary tabs
Forums:
лекция к третьей аттестации по технологиям программирования ФКН ВГУ
_____________________________________________
Источники(читать подробнее)=
Ключевые слова и фразы(для поиска)=
Документирование ТП ФКН ВГУ
Документирование
Документирование
Цели документирования
Документация, создаваемая при разработке программных средств необходима для =
Классы документов
Эту документацию можно разбить на две группы: =
ДОКУМЕНТИРОВАНИЕ ПРОЦЕССА РАЗРАБОТКИ (Process documentation)
Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС
Они обеспечивают связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами, управляющими разработкой
Стандарты.
Стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка данного ПС
Рабочие документы.
Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС
Заметки и переписка.
Product documentation (ДОКУМЕНТАЦИЯ ПРОДУКТА)
Документы, входящие в состав ПС (product documentation), описывают ПС =
Эти документы используются не только на стадии эксплуатации ПС, но и на стадии разработки для управления процессом его разработки
Типы документов продукта
Эти документы образуют два комплекта с разным назначением:
Пользовательская документация
Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС
К этому типу документации относятся документы, которыми руководствуется пользователь при:
Категории пользователей
Следует различать две категории пользователей ПС:
Ординарный пользователь ПС (end-user) использует ПС для решения задач в своей предметной области и может не знать многих деталей работы компьютера или принципов программирования
Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ
Например, Администратор ПС может =
Состав документации
Состав пользовательской документации зависит от аудиторий пользователей, на которых ориентировано данное ПС, и от режима использования документов
Пользовательская документация должна содержать информацию, необходимую для каждой пользовательской аудитории
Режим использования документа
Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ
Обычно пользователю достаточно больших программных систем требуются =
Состав пользовательской документации =
Разработка пользовательской документации
Разработка пользовательской документации начинается сразу после создания внешнего описания и ее качество может существенно определять успех ПС.
Она должна быть достаточно проста и удобна для пользователя, поэтому к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели
Документация сопровождения
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки
Эта документация необходима, если предполагается изучение устройства ПС и модернизация его программ
В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей.
Команда разработчиков-сопроводителей должна будет изучать эту документацию и затем вносить в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы: =
и технологию их разработки =содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы:
И ещё =
= содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает:
Общая проблема сопровождения ПС заключается в обеспечении согласованности всех его представлений при внесении в него любых изменений
Чтобы этому помочь, связи и зависимости между документами и их частями должны быть зафиксированы
Ввиду ограниченности сроков изготовления программных продуктов, они обычно плохо документируются
Решению этой проблемы может помочь автоматизация этого вида деятельности
Для автоматического формирования документации к программному проекту используются специальные CASE-средства, называемые генераторами документации
Генератор документации
Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям, полученным на выходе компилятора
Принципы работы генератора документации
Генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам, процедурам/функциям и т. п.)
В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев
На основе всей собранной информации формируется готовая документация в одном из общепринятых форматов.
_____________
матфак вгу и остальная классика =)
ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ
13.1. Документация, создаваемая и используемая в процессе разработки программных средств
При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы [13.1]:
В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (e nd-user ) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС ( system administrator ) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС [13.2]. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции ), либо для уточнения некоторой информации ( использование в виде справочника ).
В соответствии с работами [13.1, 13.2] можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:
Документация по сопровождению программных средств
Документация по сопровождению ПС можно разбить на две группы:
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
Документация второй группы содержит
Упражнения к лекции 13
13.1. Что такое менеджер программного средства?
13.2. Что такое ординарный пользователь программного средства?
13.3. Что такое администратор программного средства?
13.4. Что такое руководство по инсталляции программного средства?
13.5. Что такое руководство по управлению программным средством?
13.6. Что такое руководство по сопровождению программного средства?
ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ
13.1. Документация, создаваемая и используемая в процессе разработки программных средств
При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы [13.1]:
В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (e nd-user ) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС ( system administrator ) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС [13.2]. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции ), либо для уточнения некоторой информации ( использование в виде справочника ).
В соответствии с работами [13.1, 13.2] можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:
Документация по сопровождению программных средств
Документация по сопровождению ПС можно разбить на две группы:
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
Документация второй группы содержит
Упражнения к лекции 13
13.1. Что такое менеджер программного средства?
13.2. Что такое ординарный пользователь программного средства?
13.3. Что такое администратор программного средства?
13.4. Что такое руководство по инсталляции программного средства?
13.5. Что такое руководство по управлению программным средством?
13.6. Что такое руководство по сопровождению программного средства?
Что такое документирование процесса разработки пс
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ
Общие требования к разработке и документированию
Embedded system software.
General requirements for development and documentation
Дата введения 2003-07-01
1 РАЗРАБОТАН Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации
ВНЕСЕН Научно-исследовательским институтом стандартизации и унификации
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 июня 2002 г. N 247-ст
3 Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени
5 ПЕРЕИЗДАНИЕ. Октябрь 2005 г.
1 Область применения
Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения.
Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт неприменим для аппаратных элементов программно-аппаратного обеспечения.
2 Нормативные ссылки
В настоящем стандарте использована ссылка на следующий стандарт:
3 Определения и сокращения
В настоящем стандарте применяют термины с соответствующими определениями по ГОСТ Р ИСО/МЭК 12207, а также приведенные ниже:
3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий для выполнения конкретной задачи.
3.2 анализ полноты покрытия: Определения степени, до которой работы процесса верификации ПО удовлетворяют поставленной цели.
3.3 аномальное поведение: Поведение, которое не соответствует заданным требованиям.
3.4 аппаратные средства: Материальная часть вычислительной системы, включающая в себя электрические и электронные элементы (например, приборы и схемы), электромеханические элементы (например, дисководы) и механические элементы (например, стойки).
3.5 архитектура: Организационная структура системы или ЭКПО, в которой идентифицированы компоненты, их интерфейсы и концепция взаимодействия между ними.
3.6 аттестация инструментальных средств: Процесс получения сертификационного доверия к программному инструментальному средству применительно к конкретной встроенной системе.
3.7 база данных: Совокупность взаимосвязанных данных, сохраненных в одном или более компьютерных файлах в виде, позволяющем обращаться к ним пользователям или компьютерным программам с помощью системы управления базой данных.
3.8 библиотека разработки ПО: Контролируемая совокупность документов, промежуточных и конечных программных продуктов, а также инструментальных средств и процедур, используемых для управления текущей разработкой и последующей поддержкой ПО.
3.9 верификация: Оценка результатов процесса с целью гарантии корректности и непротиворечивости в отношении входов и стандартов, существующих для данного процесса.
3.10 заплата: Исправление, вносимое непосредственно в объектную программу, а не в текст, на языке программирования.
3.11 изменение ПО: Модификация исходного кода, исполняемого объектного кода или сопутствующих документов относительно их базовой линии.
3.12 имитатор: Устройство, компьютерная программа или система, используемая при верификации ПО, которая принимает те же входные данные и производит те же выходные данные, что и объектная система.
3.13 интегральный процесс: Процесс разработки ПО, который остается активным на протяжении жизненного цикла ПО.
3.14 интеграция аппаратуры и ПО: Процесс объединения ПО с объектным компьютером.
3.15 интеграция ПО: Процесс объединения компонентов кода.
3.16 интерфейс: Взаимосвязь между двумя или более объектами (типа ЭКПО/ЭКПО, ЭКПО/ЭКА, ЭКПО/пользователь или между модулями ПО), которые совместно используют и обеспечивают данные или обмениваются ими.
3.17 инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
3.18 инструментальный компьютер: Компьютер, на котором разрабатывают ПО.
3.19 исходный код: Код, написанный на исходном языке программирования, таком как язык ассемблера и/или язык высокого уровня, в машинно-читаемой форме, пригодной для ввода в ассемблер или компилятор.
3.20 квалификационное тестирование: Тестирование, выполняемое с целью убедить заказчика, что ПО соответствует заданным требованиям.
3.21 класс эквивалентности: Такое разбиение входной области программы, при котором тестирование для представительного значения класса эквивалентно тестированию для любого другого значения из этого класса.
3.22 код: Реализация конкретных данных или конкретной компьютерной программы в символьной форме, такой, например, как исходный код, объектный код или машинный код.
3.23 коммерчески доступное ПО: Коммерчески доступное программное средство, продаваемое производителем по официальным каталогам. Коммерчески доступное ПО не предназначено для переделки или усовершенствования. ПО, разработанное по специальным контрактам для специализированных приложений, не является коммерчески доступным ПО.
3.24 компонент: Замкнутая часть, комбинация частей или элемент, которые выполняют в системе отдельную функцию.
3.25 контракт: Соглашение о разработке ПО, установленное между заказчиком и разработчиком.
3.26 критерии перехода: Минимальные условия, определенные процессом планирования ПО, которые должны быть выполнены для входа в процесс.
3.27 мертвый код: Исполняемый объектный код (или данные), который в результате ошибки проектирования не может быть выполнен (код) или использован (данные) в функциональной конфигурации среды объектного компьютера и не может быть прослежен в системных или программных требованиях. Исключение составляют встроенные идентификаторы.
3.28 многоверсионное неидентичное ПО: Множество из двух или более программ, разработанных отдельно по одним и тем же функциональным требованиям. Ошибки одной версии обнаруживают путем сравнения выходных результатов разных программ.
3.29 модифицированное покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз, и для каждого условия в решении должно быть показано его независимое влияние на результат решения. Независимость влияния условия на результат решения демонстрируют путем рассмотрения всех возможных комбинаций условий.
3.30 непоставляемое программное средство: Программное средство, которое в соответствии с контрактом не требуется поставлять заказчику или другому обозначенному получателю.
3.31 объектный код: Представление компьютерной программы на низком уровне, обычно не в форме, непосредственно пригодной для объектного компьютера, а в форме, включающей в себя, помимо информации о процессорных командах, информацию о размещении программы.
3.32 объектный компьютер: Компьютер, на котором эксплуатируют ПО.
3.33 отказоустойчивость: Свойство системы продолжать правильное выполнение функций при наличии ограниченного числа аппаратных или программных дефектов.
3.34 отключенный код: Исполняемый объектный код (или данные), который согласно проекту предназначен для выполнения (код) или использования (данные) только при определенных условиях.
3.35 оценка безопасности системы: Систематическая, всесторонняя оценка предлагаемой системы с целью показать, что она удовлетворяет требованиям, предъявленным к обеспечению безопасности.
3.36 ошибка: Неправильность в требованиях, проекте или коде.
3.37 передача ПО: Последовательность действий, определяющих ответственность за передачу разработанного ПО организацией, имеющей право на эти действия (обычно организацией, которая выполняет разработку ПО), в организацию, осуществляющую поддержку ПО.
3.38 перепроектирование: Процесс исследования и изменения существующей системы для преобразования ее в новую форму.
3.39 поддержка ПО: Набор действий, гарантирующий, что установленное для эксплуатационного использования ПО продолжает выполнять все функции в соответствии с предназначением системы. Поддержка ПО включает в себя сопровождение ПО, помощь пользователям и связанные с этим действия.
3.40 покрытие операторов: Такое выполнение программы при тестировании, при котором каждый оператор в программе должен быть выполнен хотя бы один раз.
3.41 покрытие решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении должно быть выполнено с каждым возможным результатом хотя бы один раз.
3.42 покрытие условий/решений: Такое выполнение программы при тестировании, при котором каждая точка входа и выхода программы должна быть вызвана хотя бы один раз; каждое условие в решении программы должно быть выполнено со всеми возможными результатами хотя бы один раз; все результаты каждого решения должны быть выполнены хотя бы один раз.
3.43 поставляемое программное средство: Программное средство, требуемое по контракту, которое будет поставлено заказчику или другому обозначенному получателю.
3.44 построение: Версия ПО, отвечающая определенному подмножеству требований, которые должны быть обеспечены в конечном ПО.
3.45 прерывание: Приостановка задачи, например выполнения компьютерной программы, вызванная событием, внешним для этой задачи. Прерывание позволяет обработать возникшее событие и вернуться к прерванной задаче.
3.46 программная система: Система, состоящая из ПО и, возможно, компьютерного оборудования для его выполнения.
3.47 программное обеспечение (ПО): Совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ.
3.48 программное средство: ПО и связанные с ним документы, вновь созданные, модифицированные или сгруппированные для удовлетворения требованиям контракта.
3.49 программное средство многократного использования: Программное средство, разработанное для конкретного применения, но с возможностью другого применения, или разработанное специально для многократного использования в различных проектах или для многофункционального использования в одном проекте.
3.50 производные требования: Дополнительные требования, появившиеся в результате выполнения процессов разработки ПО, которые не являются непосредственно связанными с требованиями верхнего уровня.
3.51 процедура тестирования: Детальные инструкции для того, чтобы генерировать и выполнить множество тестовых наборов и оценить результаты их выполнения.
3.52 разработка ПО: Набор действий, результатом выполнения которых являются программные средства. Разработка ПО может включать в себя новую разработку, модификацию, многократное использование, перепроектирование или любое другое действие, требуемое для создания программных средств.
3.54 связность по данным: Зависимость программного компонента от данных, которые используются не только исключительно в этом компоненте.
3.55 связность по управлению: Степень влияния одного программного компонента на выполнение другого программного компонента.
3.56 сертификационное доверие: Принятие сертифицирующей организацией того факта, что процесс или средство удовлетворяет сертификационным требованиям.
3.57 система: Набор аппаратных и программных компонентов, созданный для выполнения определенной функции или множества функций.
3.58 словарь данных: Детальное описание данных, параметров, переменных и констант, используемых в системе.
3.59 совместный просмотр: Совещание с участием представителей и заказчика и разработчика, в процессе которого проверяют и обсуждают состояние проекта, программные средства и/или проблемы проекта.
3.60 соискатель: Человек или организация, претендующая на получение утверждения от сертифицирующей организации.
3.61 соисполнитель разработки: Организация, которая не является ни главным подрядчиком, ни субподрядчиком данной разработки, но которая принимает участие в разработке системы или проекта.
3.62 среда разработки ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для разработки ПО.
3.63 среда верификации/тестирования ПО: Интегрированная система, включающая в себя аппаратные средства, ПО, программно-аппаратные средства, процедуры и документы, необходимые для выполнения верификации/тестирования ПО. Элементами данной среды могут являться имитаторы, статические анализаторы, генераторы тестовых данных, анализаторы путей и т.п., а также элементы, используемые в среде разработки ПО.