Программное обеспечение управления качеством

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

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

Модульностьшкода.                                                                                      Исследование разработки ядра Linux, проведенное Гвендолином Ли и Робертом Коулом, еще раз подтвердило, что модульность кода позволяет многим программистам расширять основную программу, работая над отдельными модулями. При этом им не нужно менять основную систему или слишком глубоко разбираться в ней, а также зависеть от результатов работы других разработчиков . Это снижает риск появления новых ошибок в других модулях.                                                                                                               Изучение опыта проектов Apache и Mozilla позволило прийти к выводу, что низкая плотность ошибок в обоих проектах стала следствием высокой модульности кода. Немаловажную роль сыграл и тот факт, что поиском и исправлениемщошибокщзанималосьщмножествощлюдей.                                       Самое масштабное на сегодняшний день исследование, посвященное тому, как модульность кода влияет на качество открытого программного обеспечения, охватывающее сто систем, написанных на Си, устанавливает четкую взаимосвязь между высокой модульностью и качеством. Исследование описывает, как благодаря хорошей архитектуре к системе добавляются компоненты небольшого размера, и как в итоге это приводит к низкой плотности ошибок, высокому уровню удовлетворенности пользователей и способствует эффективной поддержке и развитию системы.                      Еще одно исследование, касающееся разработки ядра Linux, показало, что модульность кода позволяет множеству программистов работать над одним и тем же комплексным решением, часто конкурируя друг с другом, что увеличивает вероятность создания качественного решения в срок. Также исследователи отмечают, что конкуренция ведет также к более качественному, эффективному и долговременному исправлению ошибок .

Управление  проектами. Разработка открытого программного обеспечения значительно отличается от создания коммерческого программного обеспечения (и это влияет на уровень качества) в двух аспектах, связанных со взаимным анализом кода и управлениемщлюдьми.                                                                                                           Взаимный анализ кода. Взаимный анализ кода при разработке открытого программного обеспечения позволяет оценить, заслуживает ли предлагаемый кодщвключениящвщсистему.                                                                                         Как утверждает Эрик Реймонд, частому выпуску новых версий способствует взаимный анализ кода и быстрая реакция на комментарии и код специалистов, выполняющих этот анализ, что стимулирует их участие и заинтересованность . Это находит отражение в продукте, который динамично развивается и расширяется и быстро достигает высокого качества. С другой стороны, Стив Макконнелл считает, что взаимный анализ кода, выполняемый большим числом участников, действительно полезен, но он не обязательно эффективен, и что, согласно лучшим практическим методам программной инженерии, оптимальным является, когда такую работу выполняютщпять–шестьщчеловек.                                                          Утверждение Реймонда, что «при достаточном количестве глаз все ошибки оказываются мелкими» , означает следующее: если программную ошибку видит достаточно много людей, то по крайней мере один из них, скорее всего, поймет, в чем ее причина, и сможет ее исправить. Это особенно важно, учитывая, что, согласно выводам исследования ядра Linux, 75% разработки, как правило, — это рутинные, трудоемкие задачи, такие как отладка, анализ кода и исправление ошибок. Поскольку проекты категории Open Source располагают значительно большим количеством людских ресурсов, чем коммерческие проекты, то их разработка может вестись быстрее, чем это позволяет модель закрытых исходных текстов, и дает возможность добиваться более высокого качества . Кристина Гашек и Тони Лори убедились, что при создании открытого программного обеспечения над разработчиками не так довлеют факторы времени и затрат, как при реализации коммерческого программного обеспечения, поэтому, хотя участие большого числа рецензентов не гарантирует эффективность взаимного анализа, возможно, это не так уж и важно .                              Конечно, анализ кода при разработке коммерческих проектов практикуется десятилетиями. Изучение того, как применялись методы разработки открытого программного обеспечения в Hewlett-Packard, показало, что анализ кода в данном случае ведется непрерывно, а при создании традиционного программного обеспечения это, как правило, процесс, в лучшем случае, состоящий из одного или двух этапов . Другие пришли к выводу, что взаимный анализ кода, выполняемый людьми, не входящими в состав основной команды проекта и не заинтересованными в том, чтобы закрывать на что-то глаза, заметно способствует повышению качества .                              В исследовании, посвященном проекту Apache, выяснилось, что основная команда использовала списки почтовой рассылки разработчиков для того, чтобы пригласить широкий круг участников для взаимного анализа кода, в результате чего были получены полезные отзывы на изменения, которые были учтены еще до выпуска формальной версии . Это показывает, как в подобном проекте можно исправлять ошибки на ранних этапах развития системы . Быстрый выпуск версий от прототипа и дальше способствует обнаружению ошибок на первых этапах развития проекта, хотя их можно было бы найти даже раньше, если бы существовала более осмысленная документация.                                                                                                                В целом, исследователи согласны с тем, что взаимный анализ кода, выполняемый многочисленными разработчиками, особенно когда он ведется параллельно с частым выпуском новых версий, может серьезно и позитивно влиятьщнащкачествощпрограммногощобеспечения.                                                                                                     Управление людьми. Этот аспект управления проектом играет существенную роль в разработке программного обеспечения высокого качества. К этой области относится создание эффективной среды и формирование культуры, которую некоторые считают не менее важной, чем архитектура системы . При разработке открытого программного обеспечения активно поддерживаются инновации и творчество, что способствует формированию более ориентированного на людей процесса, чем традиционная разработка, гдещдоминируютщметоды,щинструментыщищметодики.                                                                                   Слова «ориентированный на людей процесс» означает, что волонтеры вправе присоединиться к основной группе и предложить свою помощь в работе над конкретной функциональностью. Ютака Ямаучи и его коллеги согласны с тем, что это приводит к формированию стиля стихийной работы, которую начинают координировать лишь на определенном этапе — серьезное отличие от традиционной разработки, при которой координация и планирование осуществляются изначально . Разработку открытого программного обеспечения характеризуют как действие, эксперимент и инновации, за которыми следуют координация, взаимный анализ кода, совершенствованиещищстабильность.                                                          Однако другие исследования показывают, что действие не всегда предшествует координации. При разработке Apache, когда основная группа находила альтернативные решения проблемы, она просила прислать свои отзывы специалистов из списка почтовой рассылки разработчиков. Затем с учетом этих отзывов выбирался окончательныйщвариантщрешения.                                        Действительно, работой можно управлять по-разному, и многие исследования показывают, что четкое, рациональное принятие решений в проектах категории Open Source производится параллельно с развернутой поддержкой процесса-инструментария для совершенствования совместной разработки и отладки. По мнению Тима О’Рейли, сообщество должно создавать процедуры обсуждения и утверждения новых возможностей, позволяющие решить, кто получает доступ к источникам, и взаимодействовать таким образом, чтобы не мешать свободной разработке.                                                                                                  Процесс тестирования.При разработке программного обеспечения с закрытыми кодами очень большое значение придается строгости процесса тестирования. При создании же открытого программного обеспечения процесс обнаружения ошибок и их исправления идет на протяжении всего жизненного цикла проекта и, в частности, во время тестирования системы, а потому в меньшей степени зависит от строгости процедур. Вместо этого для обеспечения высокого качества используется множество других методик.

Глава II.Тестированиещпрограммныхщпродуктов.                                                                     1.Философия тестирования качества программного обеспечения.

     В философском определении термин «качество» означает: «Качество есть в первую очередь тождественная с бытием определенность, так что нечто перестает быть тем, что оно есть, когда оно теряет качество» (Гегель) 
Тестирование программного обеспечения охватывает целый ряд видов деятельности, весьма аналогичный последовательности процессов разработки программного обеспечения. Сюда входят постановка задачи для теста, проектирование, написание тестов, тестирование тестов и, наконец, выполнение тестов и изучение результатов тестирования. Решающую роль играет проектирование теста. Возможен целый спектр подходов к выработке философии, или стратегии проектирования тестов. Чтобы ориентироваться в стратегиях проектирования тестов, стоит рассмотреть два крайних подхода, находящихся на границах спектра. Следует отметить также, что многие из тех, кто работает в этой области, часто бросаются в одну или другую крайность. 
Сторонник (или сторонница) подхода, соответствующего левой границе спектра, проектирует свои тесты, исследуя внешние спецификации или спецификации сопряжения программы или модуля, которые он тестирует. Программу он рассматривает как черный ящик. Позиция его такова: «Меня не интересует, как выглядит эта программа и выполнил ли я все команды или все пути. Я буду удовлетворен, если программа будет вести себя так, как указано в спецификациях». Его идеал — проверить все возможные комбинациищищзначениящнащвходе. 
Приверженец подхода, соответствующего другому концу спектра, проектирует свои тесты, изучая логику программы. Он начинает с того, что стремится подготовить достаточное число тестов для того, чтобы каждая команда была выполнена по крайней мере один раз. Если он немного более искушен, то проектирует тесты так, чтобы каждая команда условного перехода выполнялась в каждом направлении хотя бы раз. Его идеал — проверить каждый путь, каждую ветвь алгоритма. При этом его совсем (или почтищсовсем)щнещинтересуютщспецификации. 
Ни одна из этих крайностей не является хорошей стратегией. Читатель, однако, уже, вероятно, заметил, что первая из них, а именно та, в соответствии с которой программа рассматривается как черный ящик, предпочтительней. К сожалению, она страдает тем недостатком, что совершенно неосуществима. Рассмотрим попытку тестирования тривиальной программы, получающей на входе три числа и вычисляющей их среднее арифметическое. Тестирование этой программы для всех значений входных данных невозможно. Даже для машины с относительно низкой точностью вычислений количество тестов исчислялось бы миллиардами. Даже имей мы вычислительную мощность, достаточную для выполнения всех тестов в разумное время, мы потратили бы на несколько порядков больше времени для того, чтобы эти тесты подготовить, а затем проверить. Такие программы, как системы реального времени, операционные системы и программы управления данными, которые сохраняют «память» о предыдущих входных данных, еще хуже. Нам потребовалось бы тестировать программу не только для каждого входного значения, но и для каждой последовательности, каждой комбинации входных данных. Поэтому исчерпывающее тестирование для всех входных данных любой разумной программы неосуществимо. 
Эти рассуждения приводят ко второму фундаментальному принципу тестирования: тестирование — проблема в значительной степени экономическая. Поскольку исчерпывающее тестирование невозможно, мы должны ограничиться чем-то меньшим. Каждый тест должен давать максимальную отдачу по сравнению с нашими затратами. Эта отдача измеряется вероятностью тою, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Считая, что затраты ограничены бюджетом и графиком, можно утверждать, что искусство тестирования, по существу, представляет собой искусство отбора тестов с максимальной отдачей. Более того, каждый тест должен быть представителем некоторого класса входных значений, так чтобы его правильное выполнение создавало у нас некоторую убежденность в том, что для определенного класса входных данных программа будет выполняться правильно. Это обычно требует некоторого знания алгоритма и структуры программы, и мы, таким образом, смещаемся к правому концу спектра.

2.Интеграция  модулей.

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

3.Восходящее, нисходящее тестирование.

    При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня («терминальные» модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопряжениищпрограммы. 
При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из возможных решении — написать для каждого модуля небольшую ведущую программу. Тестовые данные представляются как «встроенные» непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тестируемый модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется и лучшее решение: воспользоваться программой тестирования модулей — это инструмент тестирования, позволяющий описывать тесты на специальном языке и избавляющий от необходимостищписатьщдрайверы.                                                                    Нисходящее тестирование (называемое также нисходящей разработкой не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое, При нисходящем подходе программа собирается и тестируется сверху вниз. Изолировано тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются (например, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и провереныщвсещмодули. 
При этом подходе немедленно возникает два вопроса: что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули-заглушки», которые моделируют функции отсутствующих модулей. Фраза «просто напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксированные выходные данные, которые она всегда и возвращает. Это иногда оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощренной, приближаясь по сложности к модулю,щкоторыйщонащпытаетсящмоделировать. 
Интересен и второй вопрос: «в какой форме готовятся тестовые данные и как они передаются программе?» Если бы головной модуль содержал все нужные операциищввода и вывода, ответ был бы прост: 
Тесты пишутся в виде обычных для пользователей внешних данных и передаются программе через выделенные ей устройства ввода. Так, однако, случается редко. В хорошо спроектированной программе физические операции ввода-вывода выполняются на нижних уровнях структуры, поскольку физический ввод-вывод — абстракция довольно низкого уровня. Поэтому для того, чтобы решить проблему экономически эффективно, модули добавляются не в строго нисходящей последовательности (все модули одного горизонтального уровня, затем модули следующего уровня), а таким образом, чтобы обеспечить функционирование операций физического ввода-вывода как можно быстрее. Когда эта цель достигнута, нисходящее тестирование получает значительное преимущество: все дальнейшие тесты готовятся в той же форме, которая рассчитана на пользователя. 
Остается еще один вопрос: в какой форме пишутся тесты до тех пор, пока не будет достигнута эта цель? Ответ: они включаются в некоторые из заглушек. 
Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим. Самое значительное достоинство — в том, что этот метод совмещает тестирование модуля, тестирование сопряжении и частично тестирование внешних функций. С этим же связано другое его достоинство — когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения относительно осуществимости программы в целом или если в проекте программы могут оказаться серьезные дефекты. 
Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки». Как читатель сейчас уже, вероятно, понимает, это преимущество спорно. 
Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является тот, что модуль редко тестируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потребовать крайне изощренных заглушек. Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Он, конечно, собирается вернуться и закончить тестирование рассматриваемого модуля позже, когда уберет заглушки. Такой план тестирования определенно не лучшее решение, поскольку об отложенныхщусловияхщчастощзабывают. 
Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наоборот. Большинство опытных проектировщиков признает, что проектирование программы — процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то возникает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэкономить больше, чем те несколько дней или недель, которые рассчитывает выиграть проектировщик, приступая к программированиющслишкомщрано.                                               

4.Методы  тестирования программного  обеспечения: метод  большого скачка,  метод Сандвича,  модифицированный  метод Сандвича.

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