ЧЕЛОВЕЧЕСКИЙ ФАКТОР

Написание программ

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

Руководство по сопровождению программ

1. ОБЩИЕ СВЕДЕНИЯ

1.1. Аннотация. Кратко характеризуются программные средства, подлежа­щие сопровождению.

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

1.3. Используемые материалы. Перечень цитируемых материалов:

А. Сведения о заказчике проекта (с приложением утвержденных до­кументов).

Б. Ранее опубликованные материалы по проекту.

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

Г. Прочие справочные материалы.

2. ОПИСАНИЯ ПРОГРАММ

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

2.1. Описание программы (с указанием ее идентификатора). Указывается наименование программы, ярлык или метка и язык программирова­ния.

Задача и метод решения. Даются описание решаемой задачи или реализуемой программной функции и используемый для этого метод.

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

2 1 3. Обработка Описываются особенности процесса обработки и его цели, важные для программиста-эксплуатационника:

А) логическая последовательность обработки;

Б) связи;

В) переменные и константы;

Г) формулы;

Д) действия по обработке возможных ошибок;

Е) условия и ограничения;

Ж) используемые области памяти, настройки, внутренние ключи и флаги;

З) общие области памяти.

2.1.4. Выход. Описывается результат работы программы и представ­ляется его макет. Указывается информационный носитель.

2.1.5. Интерфейсы. Описываются интерфейсы с другими программны­ми средствами: форматы данных, сообщения, параметры, тре­бования к преобразованиям, интерфейсные процедуры и спо­собы сопряжения

2 1.6. Таблицы. Идентифицируются каждая таблица и ее элементы.

Указываются местоположение, структура и назначение 2.1.7. Описание прогона Характеризуются рабочие процедуры по ор­ганизации прогона программы, включая запрузку, работу, за­вершение работы и обработку ошибок.

2.2. Описание программы (с указанием ее идентификатора). Дается по­следовательное описание всех остальных программ аналогично разд. 2.1

Рис. 5 20. Содержание руководства по сопровождению программы [8].

3. УСЛОВИЯ ЭКСПЛУАТАЦИИ

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

А) тип процессора и объем внутренней памяти;

Б) запоминающие устройства, оперативно-доступные и автономные средства, запоминающие среды, формы хранения информации и используемая аппаратура;

В) оперативно-доступные и автономные устройства ввода—вывода;

Г) аппаратура передачи данных.

3.2. Вспомогательные программные средства. Характеризуются вспомога - тельиые программы, нужные для каждой рабочей программы.

3.2.1. Операционная система. Идентифицируется требуемая операци­онная система с указанием номера версии или выпуска и лю­бых важных особенностей.

3.2.2. Транслятор и ассемблер. Идентифицируются и описываются транслятор либо ассемблер с указанием версии или выпуска и любых существенно важных особенностей.

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

3.3. База данных. Описывается вся используемая документация по базе данных или даются ссылки на соответствующие тома. Даются све­дения о применяемых кодах, единицах измерения, форматах, диапа­зонах значений либо даются ссылки на соответствующие справочни­ки данных.

4. ПРОЦЕДУРЫ ЭКСПЛУАТАЦИИ И СОПРОВОЖДЕНИЯ

4.1. Программные соглашения. Указываются и описываются все соглаше­ния, принятые в рамках системы программирования

4.2. Процедуры верификации. Описываются проверочные процедуры, наце­ленные на контроль правильности функционирования программ как в исходном виде, так и после модификации. Даются ссылки на тес­товые данные н на процедуры тестирования.

4.3. Процедуры исправления ошибок. Характеризуются все ситуации возник­новения ошибок, нх источники и действия по исправлению

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

4.5. Листинги и блок-схемы. Дается в качестве приложения, описывается илн указывается по ссылке способ приобретения копий листингов про­грамм или блок-схем.

Рис. 5.20. Продолжение.

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

Отчет о результатах испытаний

1. ОБЩИЕ СВЕДЕНИЯ

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

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

1.3. Используемые материалы. Перечень цитируемых материалов:

А. Сведения о заказчике проекта (с приложением утвержденных до­кументов).

Б. Ранее опубликованные материалы по проекту.

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

Г. Прочие справочные материалы.

2. РЕЗУЛЬТАТЫ ИСПЫТАНИЙ И ВЫВОДЫ

Идентифицируются и представляются результаты испытаний и выводы

По каждому тесту отдельно в разделах с номерами от 2Л до 2.N.

2.1. Тест (с указанием идентификатора).

2.1.1. Работа с динамическими данными. Динамические входы и вы­ходы, использовавшиеся при тестировании (в том числе про­межуточные результаты), сравниваются с динамическими ин­формационными входами и выходами, которые должны были получиться. Отмечаются обнаруженные особенности. 2Л 2. Работа со статическими данными. Статические входы и выходы данного теста (в том числе промежуточные результаты) срав­ниваются с требуемыми статическими входами и выходами. От­мечаются обнаруженные особенности.

2. N. Тест (с указанием идентификатора). Представляются аналогично разд. 2 1 результаты и выводы по каждому из остальных тестов

3. ВЫВОДЫ ПО ФУНКЦИЯМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Идентифицируются и представляются отдельно по каждой функции соот­ветствующие выводы — в разделах с номерами от З 1 до 3.N.

3.1. Функция (с указанием идентификатора).

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

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

3. N. Функция (с указанием идентификатора). Представляются аналогично разд. 3.1 результаты тестирования всех остальных функций.

4. ЗАКЛЮЧЕНИЕ ПО АНАЛИТИЧЕСКОМУ ОТЧЕТУ

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

Рис. 5 21. Содержание отчета о результатах испытаний [8].

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

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

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

А) степень срочности каждого исправления;

Б) стороны, ответственные за исправления;

В) порядок корректировки недоработок.

В заключение характеризуется степень готовности ПО к практическо­му использованию.

Рис. 5.21. Продолжение.

Приходится в настоящее время наибольшая доля затрат на программное обеспечение и высказал предположение, что эта тенденция в будущем сохранится. Почти 75% работы по про­граммированию связано с модификацией или расширением уже используемых программ [34], причем программирование на этом этапе в гораздо большей мере подвержено ошибкам, чем на этапах разработки программ [19]. Программисты, создаю­щие исходную программу, редко участвуют в ее обслуживании и сопровождении на протяжении всего жизненного цикла со­зданного программного изделия: они меняют место работы или берутся за решение более важных задач, оставляя сопровожде­ние на долю менее опытных программистов или новых сотруд­ников организации [16]. По этой причине необходимо создание полностью завершенных, удобочитаемых, самодокументируемых программных модулей, понятных не только их разработчикам.

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

5.3.1. Стиль программирования Структурное программирование

Методология структурного программирования стала реально­стью, когда в 1968 г. Дейкстра [9] указал на то, что примене­ние операторов безусловного перехода GOTO приводит к нару­шению упорядоченности структуры машинных программ. Это положило начало движению сторонников структурного програм­мирования, которое вызвало массу изменений в технике про­граммирования и проектирования программ, однако рас­смотрение практического аспекта одной из таких концепций

Представляет несомненный интерес. Согласно этой концепции, программы, разработанные с использованием небольшого числа четко определенных управляющих структур, могут создаваться и модифицироваться гораздо быстрее и с существенно меньшим количеством ошибок, чем неструктурированные программы с «макаронной» структурой связей [6, 11, 18, 36]. На рис. 5.22 показаны в сравнении характеристики двух типов структуриро­ванных программ и «макаронной» программы (с запутанными связями) для одной и той же крупномасштабной задачи. В раз­ных языках программирования существуют самые различные управляющие структуры, но главный вывод, который можно сделать на основании данных рис. 5.22, состоит в том, что наи­большую пользу для получения информации о назначении про­граммы дает применение общего принципа передачи управле­ния сверху вниз.

Введение комментариев

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

При построении комментариев целесообразно руководство­ваться следующими принципами:

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

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

3. Комментарии требуются для описания сложных или труд­ных для запоминания информационных структур.

4. Комментарии должны выделяться с помощью дефиса или каким-то иным способом (рис. 5.23).

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

Лучше сказать: «Вывод на печать фамилии студента, имею­щего наивысшую среднюю оценку за семестр» [34].

Целый ряд экспериментов в области программирования выз­вал, однако, сомнения в полезности использования комментари­ев в тексте программы [24, 27, 32]. В этих экспериментах пред­полагалось, что комментарии мало что дают для понимания программы в целом. Вместе с тем программы, использовавшие­ся в рамках экспериментов, были невелики, а комментарии, по всей видимости, становятся полезными, начиная лишь с некото­рого размера программы. Кроме того, полезность комментариев
В некоторых случаях может уменьшаться из-за нечеткости и плохого форматирования их текстов.

В более позднем эксперименте [41] исследовалось влияние комментариев на степень понимания программистами функцио­нального назначения отдельных блоков крупной программы. В рамках эксперимента фигурировали четыре типа разбиения на модули одной и той же программы с комментариями и без них. Независимо от способа разбиения программы с коммен­тариями дали намного лучший эффект, чем варианты без тако-

-- Запрос у пользователя имена требуемого файла рабочей зоны --многолучевой антенны. Добавление суффикса ".MCF"Кимени:открытие — файла и возбрат данных.

LOOP

Prompt (Control, Prompt-String). —Запрос у пользователя 3-символьного имени фай - Coverage-Name .= Get-Input (Control) (1 . . 9), - - ЛйРабочей ЗОНЫ Многолучевой Антенны. BEGIN

Open (Coverage-Name & " MCF");

Close (Coverage-Name), EXIT EXCEPTION WHEN OTHERS => Put-Line (Control), END, END LOOP,

—Расчет диаграммоовразующей матрицы Эля лучей с целью построения требуемой диаграммы. Beam-Matrix = Calculaie-Beam-Contributions (Control, Coverage-File, Beam-Weights) І

Рис. 5.23. Вставка комментариев В программу: с помощью нескольких де­фисов или включением в правую часть программных строк.

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

Имена переменных

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

1. Выбирайте в качестве имен общепринятые привычные тер­мины, имеющие отношение к прикладной области, которую представляет кодируемая программа.

2. Используйте легкоразличимые имена.

3. Употребляйте такие имена, длина которых вполне доста­точна для придания им осмысленности и в то же время не при­водит к частому переносу программных строк.

Исследования, касающиеся анализа эффективности исполь­зования символических имен переменных, дают довольно проти­воречивые результаты. Один из таких экспериментов провели Шнейдерман и МакКей [35]: они предложили программистам - новичкам для ознакомления четыре программы, в которых име­на были представлены в символической и в иных формах. При-

Менительно к мнемоническим именам наблюдались существенно лучшие результаты тестов понятности (рис. 5.24). Этот резуль­тат, однако, вступает в противоречие с итогами некоторых дру­гих экспериментов, которые не выявили сколько-нибудь суще­ственного выигрыша от использования символических имен [25, 32]. Одно из объяснений таких коренных различий в оценке полезности символических имен состоит в том, что истинно мне­монические имена (способствующие запоминанию и пониманию) действительно вносят полезный вклад, однако бывает явно про­ще при подборе имен облегчить понимание программы для самого себя, чем сделать это для кого-то другого. Очень лако­нично выразил суть этой проблемы Ньюстед [25]: «Мнемоника одного программиста — это пустой набор слов для другого».

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