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

уметь оценивать сложность системы по числу её элементов, а именно по числу потенциальных путей взаимодействия между её элементами, т. е. п!, где п - число её элементов. Систему назовем малой, если п < 7 (6! = 720 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].
В дальнейшем мы в основном будем рассматривать водопадный подход с некоторыми модификациями. Во-первых, потому, что в этом подходе приходиться иметь дело с большинством процессов программ­ной инженерии, а во-вторых, потому, что в рамках этого подхода созда­ется большинство больших программных систем. Именно этот подход рассматривается в качестве индустриального подхода разработки про­граммного обеспечения. Исследовательское программирование исходит из взгляда на программирование как на искусство. Оно применяется, когда не удается точно сформулировать требования к ПС (когда водо­падный подход не применим). В нашей книге мы этот подход рассмат­ривать не будем. Прототипирование рассматривается как вспомога­тельный подход, используемый в рамках других подходов, в основном, для прояснения требований к ПС. Компьютерной технологии (включая обсуждение жизненного цикла ПС, созданного по этой технологии) бу­дет посвящена отдельная глава. Сборочное программирование мы так­же рассматривать не будем, хотя о повторно используемых программ­ных модулях мы говорить будем, обсуждая свойства программных модулей.
В рамках водопадного подхода различают следующие стадии жиз­ненного цикла ПС (см. рис. 3.1): разработку ПС, производство про­граммных изделий (ПИ) и эксплуатацию ПС.
Стадия разработки ПС { software development ) состоит из этапов его внешнего описания, конструирования ПС, кодирования (программиро­вание в узком смысле) ПС и аттестации ПС. Всем этим этапам сопутст­вуют процессы документирования и управления ПС { software manage ­ ment ). Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых час­тей программного средства может быть начато до завершения этапа конструирования.
Этап внешнего описания ПС включает процессы, приводящие к созданию документа, который мы будем называть внешним описанием ПС { software requirements document ). Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюда­теля с фиксацией требований относительно его качества. Внешнее опи­сание ПС начинается с анализа и определения требований к ПС со стороны пользователей (заказчика), а также включает процессы спе­цификации этих требований.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать полную версию