Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

ЛИТЕРАТУРА

1. И.Г. Гоулд, Дж.С. Тутилл. Терминологическая работа IFIP (Международная федерация по обработке информации) и ICC (Международный вычислительный центр) // Журн. вычисл. матем. и матем. физ., 1965, №2. — с. 377-386.

2. Г. Майерс. Надежность программного обеспечения. — М.: Мир, 1980.

3. Ian Sommerville. Software Engineering. — Addison-Wesley Publishing Company, 1992.

4. Э. Дейкстра. Заметки по структурному программированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. — М.: Мир, 1975. — с. 7-97.

5. Criteria for Evalution of Software. — ISO TC97/SC7 #367 (Supersedes Document #327).

6. С.И. Ожегов. Словарь русского языка. — М.: Советская энциклопедия, 1975.

7. Ф.Я. Дзержинский, И.М. Калиниченко. Дисциплина программирования Д: концепция и опыт реализации методических средств программной инженерии. — М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988. — с. 9-16.

8. В. Турский. Методология программирования. — М.: Мир, 1981.

9. Г. Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. — М.: Конкорд, 1992.

10. Е.А. Жоголев. Система программирования с использованием библиотеки подпрограмм // Система автоматизация программирования. — М.: Физматгиз, 1961. с. 15-52.

11. Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы / Пер. с англ. А.П. Ершова. — М.: Наука, 1979.

12. R.C. Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). — p. 879-893.

13. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. — М.: Мир, 1980.

14. Е.А. Жоголев. Технологические основы модульного программирования // Программирование, 1980, №2. — с.44-49.

15. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. — М.: Мир, 1981.

16. В.В. Липаев. Качество программного обеспечения. — М.: Финансы и статистика, 1983.

17. Б. Шнейдерман. Психология программирования. — М.: Радио и связь, 1984.

18. Revised version of DP9126 — Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. — Part 6.

19. В.Ш. Кауфман. Языки программирования. Концепции и принципы. М.: Радио и связь, 1993.

20. Требования и спецификации в разработке программ: пер. с англ. — М.: Мир, 1984.

21. В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. — Новосибирск: Наука (Сибирское отделение), 1987.

2. ЗАМОК ДРАКОНА

Математика делает то, что можно, так, как нужно, тогда как информатика делает то, что нужно, так, как можно. Человеку свойственно ошибаться.

Сенека

3. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ

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

1. Интеллектуальные возможности человека

Дейкстра [1] выделяет три интеллектуальные возможности человека, используемые при разработке ПС:

• способность к перебору,

• способность к абстракции,

• способность к математической индукции.

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

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

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

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

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

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

Рис. 1. Грубая схема разработки и применения ПС.

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

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

Чтобы понять природу ошибок при переводе рассмотрим модель [3], изображённую на Рис. 2. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:

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

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

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

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

Рис. 2. Модель перевода.

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

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

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

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

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

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

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

ЛИТЕРАТУРА

1. Э. Дейкстра. Заметки по структурному программированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. — М.: Мир, 1975. — с. 7-97.

2. Е.А. Жоголев. Технологические основы модульного программирования // Программирование, 1980, №2. — с.44-49.

3. Г.Майерс. Надежность программного обеспечения. — М.: Мир, 1980.

2. ЗАМОК ДРАКОНА

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

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

4. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ

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

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

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

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

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

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

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

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

Под жизненным циклом ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [1, 2, 3, 4]. Жизненный цикл включает все процессы создания и использования ПС (software process).

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

Рис. 1. Стадии и фазы жизненного цикла ПС.

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

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

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

Кодирование (coding) — создание текстов программ на языках программирования, их отладку с тестированием ПС.

Характеристики

Список файлов книги