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

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

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

    Этап  внешнего описания ПС включает процессы, приводящие к созданию документа, который мы будем называть внешним описанием ПС {software requirements document). Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюдателя с фиксацией требований относительно его качества. Внешнее описание ПС начинается с анализа и определения требований к ПС со сто-

    роны   пользователей  (заказчика),   а  также  включает  процессы   спецификации этих требований.

    

    Рис. 3.1. Структура жизненного цикла ПС

    Конструирование ПС {software design) охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.

    Кодирование ПС {software coding) включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС.

    На этапе  аттестации ПС {software certfication) производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то разработка ПС считается законченной. Это обычно оформляется в виде документа, фиксирующего решение комиссии, проводящей аттестацию ПС.

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

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

    Стадия  эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [44, 65].

    Применение  ПС (software operation) - это использование ПС для решения практических задач на компьютере путём выполнения его программ.

    Сопровождение ПС (software maintenance) - это процесс сбора информации о качестве ПС в эксплуатации, устранения обнаруженных в нём ошибок, его доработки и модификации, а также извещения пользователей о внесённых в него изменениях [22, 44, 65].

    3.3. Понятие качества  программного средства

    Каждое  ПС должно выполнять определённые функции, т. е. делать то, что задумано. Хорошее  ПС должно обладать еще целым рядом  свойств, позволяющим успешно его  использовать в течение длительного периода, т. е. обладать определённым качеством. Качество (quality) ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданным потребностям пользователей [59]. Из этого определения не следует, что разные ПС должны обладать одной и той же совокупностью таких свойств с их наилучшими показателями, поскольку улучшение одного из таких свойств ПС часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и ухудшения других свойств этого ПС. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, в какой гарантируется успешное его использование.

    Совокупность  свойств, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т. е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС (criteria of software quality) принято считать [7, 30,49,59,63]:

    •     лёгкость применения,

    •     надёжность,

    •     функциональность,

    •     эффективность,

    •     сопровождаемость,

    •     мобильность.

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

    Надёжность  ПС подробно обсуждалась в первой главе.

    Лёгкость  применения (easy of use) ПС - это характеристики ПС, позволяющие минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывающие положительные эмоции определённого или подразумеваемого пользователя.

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

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

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

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

    3.4. Обеспечение надёжности - основной мотив  разработки программных  средств

    Рассмотрим  теперь общие принципы обеспечения  надёжности ПС, что является основным мотивом разработки ПС, задающим специфиче-

    скую  окраску всем технологическим процессам  разработки ПС. В технике известны четыре подхода обеспечению надёжности [35]:

    •    предупреждение ошибок,

    •    самообнаружение ошибок,

    •    самоисправление ошибок,

    •    обеспечение устойчивости к ошибкам.

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

    •    упрощение создаваемой ПС,

    •    обеспечение точности перевода,

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

    •   обеспечение контроля принимаемых решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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