Среда разработчиков

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

Какие работы надо распределить? Некоторые из них очевидны: нужны программисты в широком смысле, в котором мы употребляем этот термин ("аналитики", "функциональные аналитики". "проектировщики" и т.д.); прикладные программисты - владеющие современными программными и аппаратными средствами и методикой разработки прикладных программных систем; системные программисты - специалисты в области системных программ (операционных систем, драйверов), владеющие спецификой устройства вычислительной техники на уровне микросхем и обработки прерываний. Вероятно, будет еще руководитель проекта. Заметим по этому поводу, что "технический" руководитель может отличаться от "административного", поскольку имеются две одинаковые опасности доверить техническое руководство проектом "менеджеру", некомпетентному в программировании, или загрузить крупного специалиста по информатике административными вопросами. Менее широко признаны, но все же важны в большом проекте следующие обязанности:

- технический помощник - член бригады, который обладает особым опытом в одной или нескольких конкретных областях: язык программирования, используемое оборудование, система управления базами данных, документирующие системы и т.д. Распределяя определенным образом свое время, такой специалист поступает в распоряжение своих коллег, чтобы помочь в разрешении встречающихся им технических трудностей. Ясно, что эти обязанности могут делить несколько членов бригады, в частности, если их знания дополняют друг друга или если круг задач не требует полной загрузки программиста; таких технических помощников можно выбирать по очереди среди "программистов". Важным моментом здесь является то, что эта роль должна быть признана официально.

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

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

Тема 8. Принципы и методы разработки надежного программного обеспечения. Основные определения, связанные с обнаружением и исправлением ошибок.

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

ПРОВЕРКА ПРАВИЛЬНОСТИ ПРОГРАММ.

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

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

Все принципы и методы разработки надежного программного обеспечения можно разбить на четыре группы:

1. Предупреждение ошибок.

2. Обнаружение ошибок.

3. Исправление ошибок.

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

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

Обнаружение ошибок. Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая стратегия в этом случае - включить средства обнаружения ошибок в само программное обеспечение. Немедленное обнаружение имеет два преимущества: можно минимизировать как влияние ошибки, так и последующие затруднения для человека, которому придется извлекать информацию об этой ошибке, находить ее место и исправлять.

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

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

8.1. Основные определения.

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

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

Контроль - попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

Испытание - попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка - не является разновидностью тестирования. Хотя слова "отладка" и "тестирование" часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки. Эти два вида деятельности связаны - результаты тестирования являются исходными данными для отладки.

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

Тестирование сопряжений - контроль сопряжений между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций - контроль внешнего поведения системы, определенного внешними спецификациями.

Комплексное тестирование - контроль и испытание системы по отношению к исходным целям. Комплексное тестирование является процессом испытания, если выполняется в среде реальной, жизненной.

Тестирование приемлемости - проверка соответствия программы требованиям пользователя.

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

8.2. Базовые правила тестирования.

Обсудим некоторые из важнейших аксиом тестирования. они приведены в настоящем разделе и являются фундаментальными принципами тестирования.

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

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

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

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

Избегайте невоспроизводимых тестов, не тестируйте "с лету". В условиях диалога программист слишком часто выполняет тестирование "с лету", т.е., сидя за терминалом, задает конкретные значения и выполняет программу, чтобы посмотреть, что получится. Это -неряшливая и нежелательная форма тестирования. Основной ее недостаток в том, что такие тесты мимолетны; они исчезают по окончании их выполнения. Никогда не используйте тестов, которые тут же выбрасываются.

Готовьте тесты как для правильных, так и для неправильных входных данных. Многие программисты ориентируются в своих тестах на "разумные" условия на входе, забывая о последствиях появления непредусмотренных или ошибочных входных данных. Однако многие ошибки, которые потом неожиданно обнаруживаются в работающих программах, проявляются вследствии никак не предусмотренных действий пользователя программы. Тесты, представляющие неожиданные или неправильные входные данные, часто лучше обнаруживают ошибки, чем "правильные" тесты.

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

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

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

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

Никогда не изменяйте программу, чтобы облегчить ее тестируемость. Часто возникает соблазн изменить программу, чтобы было легче ее тестировать. Например, программист, тестируя модуль, содержащий цикл, который должен повторяться 100 раз, меняет его так, чтобы цикл повторялся только 10 раз.

8.3. Отладка.

Рекомендуемый подход к методам отладки аналогичен особенностям проектирования и включает в себя следующие этапы:

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

2. Разработайте план. Следующий шаг - построить одну или несколько гипотез об ошибке и разработать план проверки этих гипотез.

3. Выполните план. Следуя своему плану, пытайтесь доказать гипотезу. Если план включает несколько шагов, нужно проверить каждый.

4. Проверьте решение. Если кажется, что точное местоположение ошибки обнаружено, необходимо выполнить еще несколько проверок, прежде чем пытаться исправить ошибку. Проанализируйте, может ли предполагаемая ошибка давать в точности известные симптомы. Убедитесь, что найденная причина полностью объясняет все симптомы, а не только их часть. Проверьте, не вызовет ли ее исправление новой ошибки.

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

Еще одна трудность при отладке - такое состояние, когда все идеи зашли в тупик и найти местоположение ошибки кажется просто невозможно. Это означает, что Вы либо смотрите не туда, куда нужно, и следует еще раз изучить симптомы и построить новую гипотезу, либо подозрения правильные, но разум уже не способен заметить ошибку. Если кажется, что именно так и есть, то лучший принцип - "утро вечера мудренее". Переключите внимание на другую деятельность, и пусть над задачей работает Ваше подсознание. Многие программисты признают, что самые трудные свои задачи они решают во время бритья или по дороге на работу.

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

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

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

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

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

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

Изучение процесса отладки.

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

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

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

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

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

4. Что следовало сделать при проектировании или тестировании, чтобы предупредить появление этой ошибки или обнаружить ее раньше?

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

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

Дата добавления: 2014-01-13