книги / Надежность программного обеспечения систем обработки данных

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

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

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

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

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

Абсолютная надежность была и остается иедостижй-

U I

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

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

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

1)краткое описание Необходимо кратко отразить общее назначение разрабатываемого ПО и его функции;

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

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

4)публикации. Для документации, разрабатываемой

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

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

доводки ПО; 6) совместимость Сюда включается понятие исполь­

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

7)конфигурация Данная категория определяет раз­ личные конфигурации ТО и ПО, сопровождающие дан­ ный продукт разработки,

8)безопасность Данная категория описывает цели защиты разрабатываемого продукта Если предусматри­

112

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

кзащите повышаются,

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

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

11)надежность Пели по достижению надежности в значительной мере зависят от конкретного типа разраба­ тываемого ПО. Однако можно определить некоторые общие вопросы, которые должны быть рассмотрены;

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

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

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

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

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

допуска ошибок; обнаружение и исправление ошибок пользователя и

оборудования.

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

1)стоимостные ограничения,

2)график выполнения работ;

3)задачи каждого этапа тестирования;

4)цели адаптации, т. е. усилия, описывающие сте­ пень расширяемости, которая должна быть достигнута;

5)цели сопровождения, еодержачцие'’««обрвжения о

поддержании ПО в процессе эксплуатации;

113

6) уровни надежности, достигаемые после каждого этапа разработки ПО для обеспечения заданной иадежг

тации.

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

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

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

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

5 .3 .ВНЕШНИЕ СПЕЦИФИКАЦИИ ПРОЕКТА

Внешний проект является результатом процесса опи­ сания планируемого поведения продукта ПО, как если бы оно воспринималось наблюдателем, посторонним по отношению к продукту Целью внешнего проекта явля-

114

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

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

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

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

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

1 IS

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

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

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

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

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

116

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

скоторой средний пользователь будет применять систе­ му (т. е. частое и регулярное применение, применение от случая к случаю и т. д.);

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

4)обеспечьте пользователю возможность принять средство «помощь» с достаточно широким набором функ­ ций При разработке листингов помощи важно планиро­ вать четкие и короткие ответы на запросы пользователя, чтобы пользователь «не сердился» на систему;

5)проектируйте сообщения пользователю в коррект­ ной форме и приближайте язык сообщения к языку поль­ зователя;

6)проектируйте подтверждение ввода данных с тем, чтобы пользователь или оператор знал о завершении процесса.

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

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

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

ему возможность проверить введенное до обработки,

3)проектируйте систему так, чтобы ошибки пользо­ вателя обнаруживались немедленно;

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

Другой областью повышения надежности является

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

Одним из вопросов проектирования, который всегда возникаем при внешнем проектировании интерактивной

117

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

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

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

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

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

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

118

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

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

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

3.Преобразования системы. Многие внешние функции (кроме генерации внешних выводов) также изменяют

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

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

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

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

119

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

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

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

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

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

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

126