Документация определяющая строение программ пс

Содержание

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

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

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

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

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

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

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

Документация с помощью man

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

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

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

Возможности программы для создания пользовательской документации — Часть 1 — Изучаем Dr.Explain

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

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

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

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

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

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

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

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

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

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

(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;

(2) документацию, помогающую вносить изменения в ПС.

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

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

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

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

Руководство по сопровождению ПС, которое описывает известные проблемы вместе с ПС, описывает, какие части системы являются аппаратно- и программно-зависимыми, и как развитие ПС принято в расчет в его строении (конструкции).

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

Документация ПС

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

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

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

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

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

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

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

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

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

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

-документы, входящие в состав ПС.

Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) — лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов:

— планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС;

— отчеты об использовании ресурсов в процессе разработки. Создаютсяменеджерами;

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

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

— заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) — во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:

— пользовательская документация ПС (П-документация);

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

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

В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС.

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

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

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

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

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

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

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

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

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

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

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

Читайте также:

Что такое cae программы

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

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

— документация, определяющая строение программ и структур данных ПС и технологию их разработки;

— документация, помогающая вносить изменения в ПС.

— внешнее описание ПС (Requirements document);

— описание архитектуры ПС, включая внешнюю спецификацию каждой ее программы (подсистемы);

— для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

— для каждого модуля — его спецификация и описание его строения;

— тексты модулей на выбранном языке программирования;

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

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

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

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

1.10 Перечень вопросов, изучаемых в курсе «Технология разработки программного обеспечения»

1 Сущность предмета ТП, его задачи. Актуальность проблемы технологии программирования. История развития ТП.

3 Уникальное ПО и ПО, как продукция. Требования к ПО как к продукции. Доведение ПО до товарного уровня.

4 Жизненный цикл ПС. Модели жизненного цикла ПС.

5 Водопадная модель ЖЦ ПС.

6 Каскадная модель ЖЦ ПС. Усовершенствование каскадной модели ЖЦ ПС.

7 Спиральная модель ЖЦ.

8 Понятие качества ПО. Критерии качества ПО: функциональность, надежность, их примитивы.

9 Критерии качества: легкость применения, эффективность, их примитивы.

10 Критерии качества: сопровождаемость, мобильность, их примитивы.

11 Функциональные и конструктивные критерии качества. Факторы, определяющие качество ПО.

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

13 Стиль программирования. Типы комментариев, их расположение. Выбор имен переменных. Размещение операторов. Пользовательский интерфейс (командный, графический).

14 Цель модульного программирования. Основные характеристики программного модуля. Размер модуля. Рутинность модуля.

15 Связность модуля.

16 Сцепление модулей.

17 Методы разработки структуры ПС. Восходящая разработка ПС. Архитектурный подход разработки ПС.

18 Нисходящая разработка ПС. Конструктивный подход разработки ПС. Метод целенаправленной конструктивной реализации.

19 Вспомогательные средства проектирования ПС (схемы Варнье-Орра, СИС, схемы HIPO, привести примеры).

20 Порядок разработки программного модуля.

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

22 Методы проектирования модуля: пошаговая детализация; анализ сообщений.

23 Методы проектирования модуля: метод расширения ядра, спецификация модуля, иерархическое проектирование модулей.

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

25 Источники ошибок в ПС: интеллектуальные возможности человека, модель перевода информации. Причины появления ошибок.

26 Методы обнаружения ошибок. Логические ошибки. Ошибки в числовых расчетах.

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

28 Основные принципы тестирования программ. Заповеди по тестированию, предложенные Г. Майерсом. Методы тестирования, два подхода к тестированию.

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

30 Логическая организация данных. Представление данных (внешнее, внутреннее). Физическая организация данных. Эргономические факторы при проектировании данных.

31 Выбор и обоснование языка программирования. Критерии выбора языка программирования.

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

33 Характеристика языка АДА.

34 Внешнее описание ПС.

35 Определение требований к ПС.

36 Функциональная спецификация ПС. Методы контроля внешнего описания ПС.

37 Техническое задание на разработку ПС.

38 Организация процесса проектирования ПС.

39 Понятие архитектуры ПС. Основные классы архитектур ПС. Контроль архитектуры ПС.

40 Определение основных компонентов системы: потоков данных и процессов.

41 Вспомогательные средства проектирования ПС (функциональные схемы, ПЕРТ-диаграмма, сети Петри). Проектная документация.

42 Необходимость коллективной разработки ПО.

43 Метод бригады главного программиста. Состав бригады.

44 Обязанности главного программиста.

45 Функции заместителя главного программиста.

46 Работа членов бригады. Работа секретаря (библиотекаря).

47 Преимущества и трудности бригадного подхода.

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

49 Организация контроля при коллективной разработке программ.

50 Современная организация коллектива разработчиков ПС. Организация коллективов для создания очень больших комплексов программ.

51 Прикладное тестирование специалистов.

52 Понятие и классификация ППП. Структура и основные компоненты ППП.

53 Этапы развития пакетов прикладных программ (ППП).

54 Показатели качества ППП.

55 Разработка и оформление модулей в ППП.

56 Системный анализ библиотеки модулей. Средства сборки программ.

57 Технология разработки ППП. Автоматизация разработки ППП.

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

59 Пользовательская документация ПС.

60 Документация по сопровождению ПС.

61 Документация ПО. Стандартизация программной документации. Единая система программной документации (ЕСПД). Классификация и обозначение стандартов ЕСПД.

62 Назначение ЕСПД, область распространения и состав ЕСПД. Виды программных документов. Виды эксплутационных документов. Схемы алгоритмов.

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

64 Общие требования к программным документам.

65 Техническое задание. Требования к содержанию и оформлению.

66 Программа и методика испытаний. Текст программы, описание программы, пояснительная записка, описание применения (документация).

67 Руководство системному программисту, руководство программисту, руководство оператору. IEEE.

68 Общая характеристика состояния применения ЕСПД. Межгосударственные стандарты.

69 Расчет стоимости ПС.

70 Расчет экономической эффективности от внедрения ПС.

71 Надежность ПС. Показатели надежности: качественные, порядковые, количественные.

72 Факторы, определяющие надежность ПО.

73 Применение статистики к расчету надежности ПО.

74 Модели, базирующиеся на теории надежности технических систем.

75 Модель ошибок Шумана. Модель надежности.

76 Модели, сеющие предварительные ошибки.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

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

12) Документирование — Технологии программирования

Любой проект должен сопровождаться хоть какой-то документацией (прим. редактора = например readme файл с иноформацией о том как именно использовать «таблетку» — это,так сказать , минимальная документация)

Цели документирования

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

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

Классы документов

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

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

Описание проекта
Планы
Задания исполнителям (задание распределённое между конкретными людьми или группами, участвующими в реализации проекта)
отчёт о ходе работ — создаются менеджерами для контролирующих органов
Протоколы встреч и обсуждений
Отчёты о результатах активности
Журналы

Технические требования
Технические спецификации
Сведения о выпуске (Release notes)
Руководства (напр — по эксплуатации и настройки)

ДОКУМЕНТИРОВАНИЕ ПРОЦЕССА РАЗРАБОТКИ (Process documentation)

Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС
Они обеспечивают связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами, управляющими разработкой

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

Стандарты.

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

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

Рабочие документы.

Рабочие документы — это основные технические документы, обеспечивающие связь между разработчиками — актуальны в определённое время в рамках процесса разработки

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

Заметки и переписка.

Заметки и переписка — Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками

Product documentation (ДОКУМЕНТАЦИЯ ПРОДУКТА)

Документы, входящие в состав ПС (product documentation), описывают ПС =

с точки зрения его применения пользователями,
с точки зрения его разработчиков и сопроводителей (в соответствии с назначением ПС)

Эти документы используются не только на стадии эксплуатации ПС, но и на стадии разработки для управления процессом его разработки

Типы документов продукта

Эти документы образуют два комплекта с разным назначением:

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

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

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС
К этому типу документации относятся документы, которыми руководствуется пользователь при:

при инсталляции ПС,
при применении ПС для решения своих задач,
при управлении ПС (например, когда данное ПС взаимодействует с другими системами)

Категории пользователей

Следует различать две категории пользователей ПС:

ординарных пользователей ПС (те , кто используют ПС для решения своих прикладных задач)
и администраторов ПС

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

Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ

Например, Администратор ПС может =

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

Состав документации

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

Режим использования документа

Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ

Обычно пользователю достаточно больших программных систем требуются =

либо документы для изучения ПС (использование в виде инструкции),
либо для уточнения некоторой информации (использование в виде справочника)

Состав пользовательской документации =

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

Разработка пользовательской документации

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

Она должна быть достаточно проста и удобна для пользователя, поэтому к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели

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

Не всегда получается изложить мысли разработчика в форме понятной для пользователя — но надо стараться или же привлекать так называемых «технических писателей»

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

Документация сопровождения

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

Эта документация необходима, если предполагается изучение устройства ПС и модернизация его программ

То есть тексты пишутся для разработчиков , подобных исполнителям (исполнители — это те, кто изначально создали ПС)

В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей.

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

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

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

и технологию их разработки =содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы:

внешнее описание ПС (Requirements document — то есть описание , с точки зрения зависимости от параметров среды , в которой будут выполняться коды ПС — например — зависимость от операционной системы);
описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы;
для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

И ещё =

для каждого модуля — его спецификация и описание его строения (design description);
тексты модулей на выбранном языке программирования (program source code listings);
документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС

= содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает:

известные проблемы, связанные с ПС,
какие части системы являются аппаратно- и программно-зависимыми,
возможности дальнейшего развития ПС

Общая проблема сопровождения ПС заключается в обеспечении согласованности всех его представлений при внесении в него любых изменений

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

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

Решению этой проблемы может помочь автоматизация этого вида деятельности
Для автоматического формирования документации к программному проекту используются специальные CASE-средства, называемые генераторами документации

Генератор документации

Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям, полученным на выходе компилятора

Принципы работы генератора документации

Генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам, процедурам/функциям и т. п.)

В ходе анализа также используется мета-информация об объектах программы, представленная в виде документирующих комментариев

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

_____________
матфак вгу и остальная классика =)

Источник: fkn.ktu10.com