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

    уметь оценивать  сложность системы по числу её элементов, а именно по числу потенциальных  путей взаимодействия между её элементами, т. е. п!, где п - число её элементов. Систему назовем малой, если п < 7 (6! = 720 < 1000), систему назовем большой, если п > 7. При п=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Человек, создавший большую систему (систему требований, систему управления, программную систему и т. п.), рискует увязнуть в переборе большого числа вариантов. Задача технологии программирования - научиться делать большие системы простыми.

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

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

    При разработке и использовании ПС мы многократно  имеем дело [35, с. 22-28] с преобразованием (переводом) информации из одной формы  в другую (см. рис. 2.1). Заказчик формулирует  свои потребности в ПС в виде некоторых  требований. Исходя из этих требований, разработчик создает внешнее описание ПС, используя при этом спецификацию (описание) заданной аппаратуры и, возможно, спецификацию базового программного обеспечения. На основании внешнего описания и спецификации языка программирования создаются тексты программ ПС на этом языке. По внешнему описанию ПС разрабатывается также и пользовательская документация. Текст каждой программы является исходной информацией при любом ее преобразовании, в частности, при исправлении в ней ошибки.

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

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

    2.3. Модель перевода

    Чтобы понять природу ошибок при переводе рассмотрим модель [35, с. 22-28], изображённую на рис. 2.2. На ней человек осуществляет перевод  информации из представления А в  представление В. При этом он совершает  четыре основных шага перевода:

    •   он получает информацию, содержащуюся в представлении А, с помощью своего читающего механизма R;

    •    он запоминает полученную информацию в своей памяти М;

    •    он выбирает из своей памяти преобразуемую  информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;

    •    с помощью этого механизма  он фиксирует представление В.

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

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

    2.4. Основные пути  борьбы с ошибками

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

    •    сужение пространства перебора (упрощение  создаваемых систем),

    •    обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

    •   обеспечение однозначности интерпретации представления информации,

    •    контроль правильности перевода (включая  и контроль однозначности интерпретации).

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

    2.1. Что  такое простая и сложная системы!

    2.2. Что  такое малая и большая системы!

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

    Лучшее - враг хорошего.

    Народная  мудрость

    Глава 3

    ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ

    ПРОГРАММНЫХ СРЕДСТВ

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

    3.1. Специфика разработки  программных средств

    Разработка  программных средств имеет ряд  специфических особенностей [22].

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

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

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

    • Продукт  разработки имеет и другую специфическую  особенность: ПС при своём использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.

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

    3.2. Жизненный цикл  программного средства

    Под жизненным циклом ПС {software life cycle) понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [22, 24, 25, 44]. Жизненный цикл охватывает довольно сложный процесс создания и использования ПС. Этот процесс может

    быть  организован по-разному для разных классов ПС и в зависимости  от особенностей коллектива разработчиков.

    В настоящее  время можно выделить пять основных подходов к организации процесса создания и использования ПС [65].

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

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

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

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

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

    повторно  используемыми {reusable). Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования [32].

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