Подготовка документации на программные средства (775475), страница 2
Текст из файла (страница 2)
Описание программы (код вида документа -13) должно содержать сведения о логической структуре и функционировании программы. Необходимость данного документа также определяется на этапе разработки и утверждения технического задания.
Ведомость эксплуатационных документов (код вида документа - 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами: 30, 31, 32, 33, 34. 35. 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания.
Формуляр (код вида документа - 30) должен содержать основные характеристики ПО, комплектность и сведения об эксплуатации программы.
Описание применения (код вида документа - 31) должно содержать сведения о назначении программного обеспечения, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств.
Руководство системного программиста (код вида документа - 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения.
Руководство программиста (код вида документа - 33) должно содержать сведения для эксплуатации программного обеспечения.
Руководство оператора (код вида документа - 34) должно содержать сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программного обеспечения.
Описание языка (код вида документа - 35) должно содержать описание синтаксиса и семантики языка.
Руководство по техническому обслуживанию (код вида документа - 46) должно содержать сведения для применения тестовых и диагностических программ при обслуживании технических средств.
Программа и методика испытаний (код вида документа - 51) должны содержать требования, подлежащие проверке при испытании программного обеспечения а также порядок и методы их контроля.
Пояснительная записка (код вида документа - 81) должна содержать информацию о структуре и конкретных компонентах ПО, в том числе схемы алгоритмов, их общее описание, а также обоснование принятых технических и технико-экономических решении. Составляется стадии эскизного и технического проекта.
Прочие документы (код вида документа - 90 - 99) могут составляться на любых стадиях разработки, т.е. на стадиях эскизного, технического и рабочего проектов.
Код вида документа указывается в его децимальном номере, например:
42333253.00037-01 34 01 (руководство оператора).
Допускается объединять отдельные виды эксплуатационных документов, кроме формуляра и ведомости. Необходимость объединения указывается в техническом задании, а имя берут у одного из объединяемых документов. Например, в настоящее время часто используется эксплуатационный документ, в который отчасти входит руководство системного программиста, программиста и оператора. Он называется «Руководство пользователя».
Рассмотрим наиболее важные программные документы более подробно.
Руководство пользователя
Как уже указывалось выше, в настоящее время часто используют еще один эксплуатационный документ, в который отчасти входит руководство системного программиста, программиста и оператора. Этот документ называют Руководством пользователя. Появление такого документа явилось следствием широкого распространения персональных компьютеров работая на которых пользователи совмещают в своем лице трех указанных специалистов.
Составление документации для пользователей имеет свои особенности, связанные с тем, что пользователь, как правило, не является профессионалом в области разработки программного обеспечения. Ниже даны рекомендации по написанию подобной программной документации:
-учитывайте интересы пользователей - руководство должно содержать все инструкции, необходимые пользователю;
-излагайте ясно, используйте короткие предложения;
-избегайте технического жаргона и узко специальной терминологии, если все же необходимо использовать некоторые термины, то их следует пояснить;
-будьте точны и рациональны - длинные и запутанные руководства обычно никто не читает, например, лучше привести рисунок формы, чем долго ее описывать.
Руководство пользователя, как правило, содержит следующие разделы:
-общие сведения о программном продукте;
-описание установки;
-описание запуска;
-инструкции по работе (или описание пользовательского интерфейса);
-сообщения пользователю.
Раздел Общие сведения о программе обычно содержит наименование программного продукта, краткое описание его функции, реализованных методов и возможных областей применения.
Раздел Установка обычно содержит подробное описание действий по установке программного продукта и сообщений, которые при этом могут быть получены.
В разделе Запуск, как правило, описаны действия по запуску ПО и сообщений, которые при этом могут быть получены.
Раздел Инструкции по работе обычно содержит описание режимов работы, форматов ввода-вывода информации и возможных настроек.
Раздел Сообщения пользователю должен содержать перечень возможных сообщений, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
Руководство системного программиста
По ГОСТ 19.503-79 руководство системного программиста должно содержать всю информацию, необходимую для установки ПО, его настройки и проверки работоспособности. Кроме того в него часто включают и описание необходимого обслуживания, которое раньше приводилось в руководстве оператора (ГОСТ 19.505-79) и/или руководстве по техническому обслуживанию (ГОСТ 19.508-79). В настоящее время данную схему используют для составления руководства системному администратору.
Руководство системного программиста должно содержать следующие разделы:
-общие сведения о программе;
-структура программы;
-настройка;
-проверка;
-дополнительные возможности;
-сообщения системному программисту.
Раздел Общие сведения о программе должен включать описание назначения и функций программы, а также сведения о технических и программных средствах, обеспечивающих выполнение данной программы (например, объем оперативной памяти, требования к составу и параметрам внешних устройств, требования к ПО и т.п.).
В разделе Структура программы должны быть приведены сведения о структуре программы, ее составных частях, о связях между составными частями и о связях с другими программами.
В разделе Настройка программы должно быть приведено описание действий по настройке программы на условия практического применения.
В разделе Проверка программы должно быть приведено описание способов проверки работоспособности программы, например контрольные примеры.
В разделе Дополнительные возможности должно быть приведено описание дополнительных возможностей программы и способов доступа к ним.
В разделе Сообщения системному программисту должны быть указаны тексты сообщений, выдаваемых в ходе выполнения настройки и проверки программы, а также в ходе ее выполнения, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
2.3.Типы технической документации на программный продукт.
Всю документацию на программный продукт можно разделить на следующие категории:
1. Документация управления проектом — организационные документы, которыми обмениваются между собой те, кто так или иначе участвует в создании программы.
2. Документация разработки — технические документы, которыми обмениваются между собой те, кто так или иначе участвует в создании программы.
3. Документация продукции — технические документы, которые предоставляются потребителю в комплекте поставки программы или отдельно от нее.
В составе документации продукции можно выделить эксплуатационную документацию, то есть такую, которая используется при эксплуатации системы. В свою очередь, в составе эксплуатационной документации можно выделить документацию пользователя, адресованную лицам, непосредственно работающим с программой.
3.Разработка документации программных средств.
Состав технической документации на программный продукт.
Документация разработки программного продукта.
Состав документации разработки программного продукта в значительной мере зависит от методологии, которую исповедует коллектив разработчиков. Каждая методология предусматривает свой набор документов. Эти наборы во многом похожи, хотя одни и те же документы в них могут по-разному называться и иметь разную структуру.
При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы:
• Документы управления разработкой ПС.
• Документы, входящие в состав ПС.
Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков, менеджерами ПС и лицами, управляющими разработкой ПС.
Эти документы могут быть следующих типов:
• Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС.
• Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.
• Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС.
• Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.
• Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) Во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:
• Пользовательская документация ПС (П-документация).
• Документация по сопровождению ПС (С-документация).
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;
(2) документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
• Внешнее описание ПС (Requirements document).
• Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы (подсистемы).
• Для каждой программы ПС описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
