скую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надёжности [35]:
• предупреждение ошибок,
• самообнаружение ошибок,
• самоисправление ошибок,
• обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах (в нашем случае - в ПС) или хотя бы свести их количество к минимуму. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
• упрощение создаваемой ПС,
• обеспечение точности перевода,
• преодоление барьера между пользователем и разработчиком в понимании информации, которой они обмениваются,
• обеспечение контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т. е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надёжности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе её выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе её выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако эти подходы используются весьма редко (относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во-вторых, до-
бавление в программу дополнительных фрагментов приводит к ее усложнению (иногда - значительному), что в какой-то мере мешает методам предупреждения ошибок.
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], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо "заказываемое" ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать. Иногда бывает полезным разработка упрощенной версии требуемого ПС, называемую прототипом ПС. Анализ "пробного" применения прототипа позволяет выявить действительные потребности пользователей и существенно уточнить требования к ПС.