Обеспечение сопровождаемости программного средства

Обеспечение сопровождаемости ПС сводится к обеспечению изучаемости ПС и к обеспечению его модифицируемости.

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

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

· используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по возможности, включайте комментарии (хотя бы в краткой форме) на самой ранней стадии разработки текста модуля;

· используйте осмысленные (мнемонические) и устойчиво различимые имена (оптимальная длина имени - 4-12 литер, цифры - в конце), не используйте сходные имена и ключевые слова;

· соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля: при ее объявлении или, в крайнем случае, при инициализации переменной в качестве константы);

· не бойтесь использовать необязательные скобки - они обходятся дешевле, чем ошибки;

· размещайте не больше одного оператора в строке; для прояснения структуры модуля используйте дополнительные пробелы (отступы) в начале каждой строки; этим обеспечивается удобочитаемость текста модуля;

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

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

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

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

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

Структурированность и модульность упрощают ручную модификацию программ ПС.

Контрольные вопросы

1. Назовите общую характеристику процесса обеспечения качества программного средства.
2. Укажите обеспечение легкости применения программного средства.
3. Перечислите примитивы качества ПС.
4. Сформулируйте понятия пользовательского интерфейса.
5. Перечислите важнейшие принципы пользовательского интерфейса.

 

ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ СОСТАВЛЕНИЕ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

Виды программных документов

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

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

Ведомость держателей подлинников (код вида документа - 05) должна содержать список предприятий, на которых хранятся подлинники программных документов. Необходимость этого документа определяется на этапе разработки и утверждения технического задания только для программного обеспечения со сложной архитектурой.

Текст программы (код вида документа - 12) должен содержать текст программы с необходимыми комментариями. Необходимость этого документа определяется на этапе разработки и утверждения технического задания.

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

Ведомость эксплуатационных документов (код вида документа - 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами: 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания.

Формуляр (код вида документа - 30) должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы.

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

Руководство системного программиста (код вида документа - 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения.

Руководство программиста (код вида документа - 33) должно содержать сведения для эксплуатации программного обеспечения.

Руководство оператора (код вида документа - 34) должно содержать сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программного обеспечения.

Описание языка (код вида документа - 35) должно содержать описание синтаксиса и семантики языка.

Руководство по техническому обслуживанию (код вида документа - 46) должно содержать сведения для применения тестовых и диагностических программ при обслуживании технических средств.

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

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

Прочие документы (коды вида документа - 90-99) могут составляться на любых стадиях разработки, т. е. на стадиях эскизного, технического и рабочего проектов.

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

Рассмотрим наиболее важные программные документы более подробно.

Пояснительная записка

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

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

• введение;

• назначение и область применения;

• технические характеристики;

• ожидаемые технико-экономические показатели;

• источники, используемые при разработке.

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

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

Раздел Технические характеристики должен содержать следующие подразделы:

• постановка задачи, описание применяемых математических методов и допущений и ограничений, связанных с выбранным математическим аппаратом;

• описание алгоритмов и функционирования программы с обоснованием принятых решений;

• описание и обоснование выбора способа организации входных и выходных данных;

• описание и обоснование выбора состава технических и программных средств на основании проведенных расчетов или анализов.

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

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

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

Руководство пользователя

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

Составление документации для пользователей имеет свои особенности, связанные с тем, что пользователь, как правило, не является профессионалом в области разработки программного обеспечения. В книге С. Дж. Гримм [17] даны рекомендации по написанию подобной программной документации:

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

• излагайте ясно, используйте короткие предложения;

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

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

Руководство пользователя, как правило, содержит следующие разделы:

• общие сведения о программном продукте;

• описание установки;

• описание запуска;

• инструкции по работе (или описание пользовательского интерфейса);

• сообщения пользователю.

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

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

В разделе Запуск, как правило, описаны действия по запуску программного продукта и сообщений, которые при этом могут быть получены.

Раздел Инструкции по работе обычно содержит описание режимов работы, форматов ввода-вывода информации и возможных настроек.

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