Неправильный перевод информации как причина ошибок в программных средствах

--PAGE_BREAK--
3.5. Методы упрощения создаваемой ПС

Мы уже обсуждали в главе 2 сущность вопроса упрощения систем при разработке ПС. Известны два общих метода упрощения систем:

•    обеспечения независимости компонент системы,

•    использование в системах иерархических структур.

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

3.6. Обеспечение точности перевода

Обеспечение точности перевода направлено на достижение одно­значности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует при переводе информации при­держиваться определённых правил (определённой дисциплины). Май-ере предлагает использовать общую дисциплину решения задач, рас­сматривая перевод как решение задачи [35]. Лучшим руководством по решению задач он считает книгу Пойа «Как решать задачу» [38]. В со­ответствии с этим весь процесс перевода можно разбить на следующие этапы:

•    обеспечение понимания задачи;

•   составление плана (включая цели и методы решения);

•    выполнение плана (с проверкой правильности каждого шага);

•    анализ полученного решения.

Подробно обсуждать этот вопрос мы здесь не будем.

3.7. Преодоление барьера между пользователем и разработчиком

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

3.8. Контроль принимаемых решений

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

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

•    смежный контроль,

•    сочетание как статических, так и динамических методов контроля.

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

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

Вопросы к главе 3

3.1. Что такое жизненный цикл ПС1

3.2. Что такое внешнее описание ПС1

3.3. Что такое сопровождение ПС!

3.4. Что такое качество ПС!

3.5. Что такое смежный контроль!

Не переходи мост, пока не дошёл до него. Народная пословица

Глава 4

ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО

СРЕДСТВА

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

4.1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства

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

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

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

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

Исходным документом для разработки внешнего описания ПС яв­ляется определение требований к ПС. Через этот документ передается от заказчика (пользователя) к разработчику основная информация отно­сительно требуемого ПС, поэтому формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком. Трудно­сти, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в «узких» местах деятельности пользователей может на са­мом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадывают­ся). Кроме того, проблемы, которые необходимо отразить в определе­нии требований, могут не иметь определённой формулировки [65], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесо­образно и реализуемо «заказываемое» ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обла­дать. Иногда бывает полезным разработка упрощенной версии требуе­мого ПС, называемую прототипом ПС. Анализ «пробного» применения прототипа позволяет выявить действительные потребности пользовате­лей и существенно уточнить требования к ПС.

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

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

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

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

4.2. Определение требований к программному средству

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

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

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

Известны три способа разработки определения требований к ПС [35]:

•   управляемая пользователем разработка,

•    контролируемая пользователем разработка,

•    независимая от пользователя разработка.

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

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

ПС. Разработанные требования, как правило, утверждаются представи­телем пользователя.

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

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

4.3. Спецификация качества программного средства

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

Для конкретизации качества ПС по каждому из критериев исполь­зуется стандартизованный набор достаточно простых свойств ПС, раз­работанных ISO[7, 22, 59, 63], однозначно интерпретируемых разра­ботчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от при­митивов качества ПС.

Функциональность: завершённость.

Надёжность: завершённость, точность, автономность, устойчи­вость, защищённость.

Лёгкость применения: П-документированность, информативность (применительно к документации по применению), коммуникабель­ность, устойчивость, защищённость.

Эффективность: временная эффективность, эффективность по ре­сурсам (по памяти), эффективность по устройствам.

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

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

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

Модифицируемость: расширяемость, лёгкость изменения, структу­рированность, модульность.

Мобильность: независимость от устройств, автономность, структу­рированность, модульность.

Ниже определяются используемые примитивы качества ПС [22, 59, 63]. Здесь приводится достаточно большой список, состоящий из 19 примитивов качества, которые следует рассматривать как независимые (самостоятельные) понятия. Некоторые их комбинации образуют более крупные понятия — критерии и подкритерии качества. Такие комбина­ции можно рассматривать как определённые системы. Но ни одна из этих комбинаций не содержит более шести примитивов (см. выше), так что правило, сформулированное в п. 2.1, здесь не нарушается.

Завершённость {
completeness
) ПС — свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, тре­бующимися для выполнения своих явных и неявных функций.

Точность {
accuracy
) ПС — мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.

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

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

Защищённость {
defensiveness
) ПС — свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным дест­руктивным (разрушающим) действиям пользователя.

П-документированностъ {и.
documentation
) ПС — свойство, харак­теризующее наличие, полноту, понятность, доступность и наглядность

учебной, инструктивной и справочной документации, необходимой для применения ПС.

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

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

Временная эффективность {
time

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

Эффективность по ресурсам {
resource

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

Эффективность по устройствам {
device

efficiency
) ПС — мера, ха­рактеризующая экономичность использования устройств компьютера для решения поставленной задачи.

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

Понятность {
understandability
) ПС — свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его на­значение, сделанные допущения и ограничения, входные данные и ре­зультаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких при­митивов ISO[59], как согласованность, самодокументированность, чет­кость и, собственно, понятность (текстов программ).

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

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

Расширяемость (
augmentability
) ПС — свойство, характеризующее способность ПС к наращиванию объёма памяти для хранения данных или расширению функциональных возможностей отдельных компо­нент.

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

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

Независимость ПС от устройств (
device

independence
) — свойство, характеризующее способность ПС работать на разнообразном аппарат­ном обеспечении (различных типах, марках, моделях компьютеров).

4.4. Функциональная спецификация программного средства

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

Функциональная спецификация состоит из трёх частей:

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

•    определение функций ПС, определённых на множестве состояний этой информационной среды (такие функции будем называть внеш­ними функциями ПС);

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

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

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

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