Для чего предназначено руководство по управлению пс

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

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

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

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

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

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

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

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

что передавать пользователям, а что — службе сопровождения? как управлять всем этим процессом?

Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование?

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

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

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

Общая характеристика состояния

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

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

Следует отметить, что стандарты ЕСПД носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС. Дело в том, что в соответствии с Законом РФ «О стандартизации» эти стандарты становятся обязательными на контрактной основе — то есть при ссылке на них в договоре на разработку (поставку) ПС.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

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

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

Итак, ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС.

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

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

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

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

Краткое представление стандартов ЕСПД

Из всех 28 стандартов ЕСПД остановимся только на тех, которые могут чаще использоваться на практике. Выделим также еще один, существенно более «свежий», чем остальные, отличающийся совместимостью с современными международными стандартами.

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

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требование к содержанию и оформлению. Напомним, что техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы. Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта ПС.

Следующий стандарт ориентирован на документирование результирующего продукта разработки: ГОСТ 19.402-78 ЕСПД. Описание программы.

Сделаем два замечания.

1. Несмотря на возможность применения не всех, а только отдельных стандартов комплекса, использованная в них терминология, способы обозначения и другие детали могут потребовать опоры на такие общие стандарты, как ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов, и другие.
2. Состав документа «Описание программы» в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.502-78 ЕСПД. Описание применения, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора.

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

Надо также выделить ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний, который (в адаптированном виде) может использоваться для разработки документов планирования и проведения испытательных работ по оценке готовности и качества ПС.

Наконец, выделим последний по году принятия стандарт. Это ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные графические и правила выполнения. Он устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения и полностью соответствует стандарту ИСО 5807:1985.

О других межгосударственных стандартах

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

ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения. Разработан взамен ГОСТ 19781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения (ПО) систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ.

ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

Государственные стандарты РФ (ГОСТ Р)

В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это — самые «свежие» по времени принятия стандарты. Некоторые из них впрямую адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление.

ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается». Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.

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

ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.

Как двигаться вперед

Как уже говорилось — пока нет лучшего, можно извлекать пользу и из тех стандартов ЕСПД, которые приняты еще около 20 лет назад. Но всем ясно, что ориентироваться надо на современные стандарты.

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

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

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

Валерий Васильевич Васютович — начальник отделения, Сергей Сергеевич Самотохин — старший научный сотрудник ВНИИ стандарта ГОССТАНДАРТА РФ. Им можно написать по адресу STAND.NII@g23.relcom.ru.

---

Коротко

Основные документы Стандарты для наведения порядка в программном хозяйствеГОСТ 19.202-78 ЕСПД. Спецификация ГОСТ 19.401-78 ЕСПД. Текст программы ГОСТ 19.403-79 ЕСПД. Ведомость держателей подлинников ГОСТ 19.501-78 ЕСПД. Формуляр ГОСТ 19.507-79 ЕСПД. Ведомость эксплуатационных документов Новые стандарты — руководителю: ГОСТ Р ИСО/МЭК 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению ГОСТ Р ИСО/МЭК 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов

---

Где приобрести?

Справочная информация Для приобретения стандартов в области документирования рекомендуем обращаться в следующие организации. ИПК «Издательство стандартов», Территориальный отдел распространения НТД (магазин «Стандарты»), 17961, Москва, ул. Донская д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р). ВНИИКИ Госстандарта России (читальный зал), 103001, Москва, Гранатный пер. д. 4, тел. 290-50-94 (в части международных, зарубежных стандартов и других НТД).

Обновлено: 18.05.2023

ГОСТ Р ИСО/МЭК ТО 9294-93

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

РУКОВОДСТВО ПО УПРАВЛЕНИЮ ДОКУМЕНТИРОВАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Information technology. Guidelines for the management of software documentation

ОКСТУ 4002
ОКС 35.080

Дата введения 1994-07-01

Предисловие

1 РАЗРАБОТАН И ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационная технология»

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 20 декабря 1993 г. N 260

Стандарт подготовлен на основе применения аутентичного текста технических рекомендаций ИСО/МЭК ТО 9294-90* «Информационная технология. Руководство по управлению документированием программного обеспечения»

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

3 ВВЕДЕН ВПЕРВЫЕ

4 ПЕРЕИЗДАНИЕ. Ноябрь 2003 г.

Переиздание (по состоянию на июль 2008 г.)

1 Область применения

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

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

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

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

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

2 Нормативные ссылки

ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов

ИСО 2382-84 Обработка данных. Словарь. Часть 1: Основные термины

ИСО 6592-85 Обработка информации. Руководство по документированию прикладных систем на основе ЭВМ

Примечание — До прямого применения данных международных стандартов в качестве государственных стандартов Российской Федерации они могут быть получены по запросам из ВНИИКИ Госстандарта России.

3 Определения

В настоящем стандарте применяют следующие термины.

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

3.2 документация: Набор из одного или более связанных документов.

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

4 Роль руководителей

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

Эффективность выполнения руководящей роли можно рассматривать как основанную на трех элементах:

1) руководящая обязанность по документированию.

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

2) руководящая поддержка обязанностей персонала по документированию.

Для этого требуется руководство и стимулирование персонала при проведении требуемого документирования и обеспечение его ресурсами для содействия в данной работе;

3) признаки руководящих обязанностей и поддержки.

Для этого требуется обеспечить:

а) опубликованные официальные отчеты о стратегии документирования;

б) стандарты и руководства, определяющие все аспекты документирования программного обеспечения;

в) опубликованные процедуры документирования;

г) выделение соответствующих ресурсов для документирования;

д) планирование документирования, осуществляемое как неотъемлемая часть процесса разработки программного обеспечения;

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

5 Функции программной документации

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

Программную документацию можно рассматривать как имеющую шесть основных функций:

1) информация для управления (см. 5.1);

2) связь между задачами (см. 5.2);

3) обеспечение качества (см. 5.3);

4) инструкции и справки (см. 5.4);

5) сопровождение программного обеспечения (см. 5.5);

6) исторические справки (см. 5.6).

5.1 Информация для управления

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

5.2 Связь между задачами

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

В типовом варианте:

специалисты в предметной области начинают проект;

аналитики формируют требования к системе;

проектировщики разрабатывают системный и программный проекты;

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

специалисты по обеспечению качества и ревизоры оценивают общую полноту и качество функционирования программного обеспечения;

сопровождающие программисты улучшают эксплуатируемое программное обеспечение и разрабатывают его изменения или расширения.

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

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

5.3 Обеспечение качества

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

5.4 Инструкции и справки

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

5.5 Сопровождение программного обеспечения

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

5.6 Исторические справки

Документация, требуемая в качестве исторической справки по проекту. Данная документация может помочь в переносе и переводе программного обеспечения в новое окружение.

6 Установление стратегии документирования

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

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

Стратегия должна поддерживать основные элементы эффективного документирования:

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

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

2) документирование должно быть управляемым.

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

3) документация должна соответствовать ее читательской аудитории.

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

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

Процесс разработки должен быть определен;

5) должны быть определены и использованы стандарты по документированию.

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

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

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

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

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

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

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

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

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

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

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

Документы, входящие в состав ПС (software product documen­ta­tion), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами). Во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 описание архитектуры ПС (description of the system architect­ture), включая внешнюю спецификацию каждой ее программы (подсистемы).

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

 для каждого модуля спецификацию и описание его строения (design description);

 тексты модулей на выбранном языке программирования (program source code listings);

 документы установления достоверности ПС (validation docu­ments), описывающие, как устанавливалась достоверность каждой программы ПС, и как информация об установлении достоверности связывалась с требованиями к ПС.

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

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

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

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

По своему назначению документацию ППП можно классифицировать как:

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

 эксплуатационную (пользовательскую) документацию программного продукта, создаваемую для конечных пользователей пакета и позволяющую им осваивать и квалифицированно применять его для решения конкретных прикладных задач.Технологическая документация включает:

 документацию тестирования компонентов и комплексов про­грамм;

 документацию испытаний ППП;

 документацию сопровождения и управления конфигурацией ППП.В состав проектной документации входят:

 отчет по обследованию предметной области, для которой предназначен разрабатываемый ППП, с описанием комплекса за­дач;

 описание концепции проектирования;

 техническое задание на проектирование;

 спецификации эскизного и технического проекта;

 документация на разработанные программные модули пакета;

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

В состав документации тестирования входят:

 исходные данные для проведения тестирования (методы тестирования, тестовые наборы, эталонные значения, реальные ресурсы тестирования — временные, аппаратно-программные, люд­ские, критерии полноты и качества тестирования);

 программа (сценарии) тестирования;

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

 описание методов и методик испытаний;

 акт завершения работ;

 акт приемки ППП в эксплуатацию.В состав документации сопровождения управления конфигу­рацией входят:

 отчеты пользователей о выявленных дефектах и предло­жения по корректировке программ;

 журнал выявленных дефектов и предложений по совершенствованию и развитию версии ППП;

 журнал подготовленных и утвержденных корректировок, а также реализованных изменений в новой версии пакета;

 отчет о результатах эксплуатации снятой с сопровождения версии пакета;

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

 паспорт на программное средство, где содержатся общие сведения о ППП, его основные характеристики, комплектность, акт о приемке, гарантии изготовителя (поставщика);

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

 руководство администратора программного средства, кото­рое регламентирует функции администрирования, процедуры по инсталляции и подготовке ППП к эксплуатации, порядок и средства ведения базы данных и восстановления ин­формации при сбоях;

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

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

В процессе сопровождения в програм­мы вносятся различные изменения:

 исправление ошибок — корректировка программ, выдаю­щих неправильные результаты в условиях, ограниченных техниче­ским заданием и документацией;

 модернизация — расширение функциональных возможно­стей или улучшение качества решения отдельных задач в соответ­ствии с новым или дополнительным техническим заданием на ППП;

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

Выход коммерческого программного продукта на рынок про­граммных средств связан с организацией продаж массовому поль­зователю. Как правило, для каждого программного продукта существует своя форма кривой продаж, которая отражает спрос V во времени t (рис. 11).

Вначале продажа программного продукта идет вверх — возрас­тающий участок кривой. Затем наступает стабилизация. Далее происходит падение объема продаж, что является сигналом к изменению маркетинговой политики фирмы в отноше­нии данного программного продукта, требуется модификация продукта, изменение цены или снятие с продажи.

Эксплуатация программного продукта идет параллельно с его сопровождением, при этом эксплуатация программ может начи­наться и в случае отсутствия сопровождения, или продолжаться в случае завершения сопровождения еще какое-то время. После сня­тия программного продукта с продажи его сопровождение может выполняться определенное время.

Рис. 11. Кривая продаж программного продукта

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

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программ­ных продуктов длительность жизненного цикла измеряется двумя-тремя годами. Хотя достаточно часто встречаются и давно снятые с производства программные продукты.

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

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

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

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

ПС как с точки зрения их применения пользователями, так и с точки зрения их

разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует

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

(в ее фазах применения и сопровождения), но и на стадии разработки для управления

процессом разработки (вместе с рабочими документами) — во всяком случае они должны

быть проверены (протестированы) на соответствие программам ПС. Эти документы

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

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

Структурный подход разработки программного обеспечения

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

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT модели и соответствующие функциональные диаграммы; DFD диаграммы потоков данных; ERD диаграммы «сущность-связь».

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

Модульное программирование

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

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

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

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

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

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

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

Понятие жизненного цикла ПО.

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

В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС:

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

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

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

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

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

Свидетельство и скидка на обучение каждому участнику

Зарегистрироваться 15–17 марта 2022 г.

Описание презентации по отдельным слайдам:

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

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

ЦЕЛИ ДОКУМЕНТИРОВАНИЯ Документация, создаваемая при разработке программных средств необходима для = передачи информации между разработчиками ПС, управления разработкой ПС, передачи пользователям информации, необходимой для применения и сопровождения ПС.

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

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

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

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

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

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

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

Документирование программных средств Совокупные затраты на документирование крупных программных продуктов могут достигать 20 – 30% от общей трудоемкости проекта и необходимого числа (десятки) специалистов в жизненном цикле проекта ПС. В более простых случаях, ор­ганизация работ может быть упрощена, затраты на документирование снижаются приблизительно до 10%, однако всегда целесообразно выделять специалистов, непосредственно ответственных за создание, адекватность и контроль полноценного комплекта документов на программный продукт. Состав и общий объем документов широко варьируется в зависимости от класса и характеристик объекта раз­работки, а также в зависимости от используемой технологии.

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

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

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

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

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

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

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

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

  

• Морские лилии размножение кратко

  

• Литература при петре 1 кратко

  

• Открытие позитрона античастицы кратко

  

• Особенности природы европы кратко

  

• Интересные факты о плавании кратко

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

Документирование — это важная часть в разработке программного обеспечения, но часто ей уделяется недостаточно внимания.

Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния (базовой линии) программных объектов в системе, управления их изменениями и выпуском.

Данный процесс состоит из шести работ. Общее число задач по данным работам равно 6.

Источник: