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

Введение

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

Многие  организации, занимающиеся созданием  программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды  долларов по всему миру в целом. И  все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает и большинство программных  продуктов неприемлемо ненадежно  даже после «основательного тестирования». 
О состоянии дел лучше всего свидетельствует тот факт, что большинство людей, работающих в области обработки данных, даже не может правильно определить слово «тестирование», и это на самом деле главная причина неудач. 
«Тестирование — процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет.» Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение антонима слова «тестирование». Читатель с некоторым опытом программирования уже, вероятно, понимает, что невозможно продемонстрировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успехом, то такое определение логически некорректно. Правильное определение тестирования

таково:Тестированиещпроцессщвыполненияпрограммыщсщнамерениемщнайтиошибки. 
Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этимищтестами. 
Психологические эксперименты показывают, что большинство людей, поставив цель (например, показать, что ошибок нет), ориентируется в своей деятельности на достижение этой цели. Тестовик подсознательно не позволит себе действовать против цели, т. е. подготовить тест, который выявил бы одну из оставшихся в программе ошибок. Поскольку мы все признаем, что совершенство в проектировании и кодировании любой программы недостижимо и поэтому каждая программа содержит некоторое количество ошибок, самым плодотворным применением тестирования будет найти некоторые из них. Если мы хотим добиться этого и избежать психологического барьера, мешающего нам действовать против поставленной цели, наша цель должна состоять в том, чтобы найти как можно больше ошибок. Сформулируем основополагающий вывод: 
Если ваша цель — показать отсутствие ошибок, вы. их найдете не слишком много. Если же ваша цель — показать наличие ошибок, вы найдете значительнуюрихщчасть. 
Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности — с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны. 
Тестирование оказывается довольно необычным процессом (вот почему оно и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего (тестовика) — заставить программу сбиться. Он доволен, если это ему удается; если же программа на его тесте не сбивается, он не удовлетворен. 
Еще одна причина, по которой трудно говорить о тестировании — это тот факт, что о нем известно очень немногое. Если сегодня мы располагаем 5% тех знании о проектировании и собственно программировании (кодировании), которые будут у нас к 2000 г., то о тестировании нам известно менее 1%. 
 
 
 
 
 
 
 
 
 
 
 

Глава I.Общие понятия управлением качества программного обеспечения 1.Основные определения качества программного обеспечения

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

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

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

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

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

   Обеспечение качества — планируемые и систематически осуществляемые виды деятельности в рамках системы качества, необходимые для создания уверенности в том, что объект будет удовлетворять требованиям по качеству. Различают внутреннее и внешнее обеспечение качества. Внутреннее обеспечение качества создает уверенность у руководства, внешнее -  уверенность у потребителя.

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

   Модель  для обеспечения качества - стандартизированный или  избранный набор требований системы качества, объединенных с целью удовлетворения потребностей обеспечения качества в данной ситуации.

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

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

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

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

   Надзор  за качеством — непрерывное наблюдение и проверка состояния объекта, а также анализ протоколов с целью проверки выполнения требований качества.

   В тестировании можно выделить несколько  различных процессов, такие термины, как тестирование, отладка, доказательство, контроль и испытание, часто используются как синонимы и, к сожалению, для  разных людей имеют разный смысл. Хотя стандартных, общепринятых определений  этих терминов нет, попытка сформулировать их была предпринята на симпозиуме по тестированию программ. Нашу классификацию  различных форм тестирования мы начнем с того, что дадим эти определения, слегка их дополнив и расширив их список. 
Тестирование (testing), как мы уже выяснили,—процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки. 
Доказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию — взгляд во многом ошибочный;  
Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой,щилищмоделируемой,щсреде. 
Испытание (validation) — попытка найти ошибки, выполняя программу в заданнойщреальнойщсреде. 
Аттестация (certification) — авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом. 
Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными даннымищдлящотладки. 
Тестирование модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включаетщтакжещматематическоещдоказательство. 
Тестирование сопряжении (integration testing) — контроль сопряжении между частями системы (модулями, компонентами, подсистемами). 
Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями. 
Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной. 
Тестирование приемлемости (acceptance testing) — проверка соответствия программыщтребованиямщпользователя. 
Тестирование настройки (installation testing) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшиещвщпроцессещнастройкищсистемы.

   2.Факторы  разработки открытого  программного обеспечения.

Разработка  открытого программного обеспечения  опирается на несколько ключевых факторов: устойчивое сообщество, модульность  кода, управление проектами и управление процессом тестирования. Чтобы получить продукты высокого качества, необходимо хорошо представлять себе эти значение этих факторовщищихщвзаимосвязьщдругщсщдругом.                                  Устойчивоещсообщество                                                                                         Высокое качество открытого программного обеспечения во многом определяется существованием устойчивого сообщества, способного быстро разрабатывать код, эффективно его отлаживать и создавать новые возможности. Выводы многих исследований сводятся к тому, что формирование устойчивого сообщества должно стать основной целью проекта по созданию открытого программного обеспечения [1–3]. Изучение эволюции подобных проектов показало, что одним из важнейших факторов успеха было участие в них большого числа волонтеров [4]; кроме того, необходимо, чтобы программная система и сообщество развивались параллельно.                                                                                              Концентрическая модель. Это одна из самых распространенных моделей устойчивого сообщества. В данной модели (см. рисунок) устойчивое сообщество состоит из небольшого ядра основных разработчиков и постоянно растущего числа помогающих им программистов («соразработчиков»), а также из специалистов, сообщающих об ошибках, и пользователей. Концентрические «слои» соответствуют различным категориям участников процесса разработки.

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

Для концентрической  модели характерно следующее.

• Основная группа должна быть небольшой. Именно эта группа пишет немалую часть кода, но, кроме того, она осуществляет общий контроль над системой. Члены основной группы интегрируют в систему только высококачественный код, определяют и выполняют план реализации проекта, а также поддерживают достаточно частый выпуск новых, итеративных версий кода. Согласно данным исследования, посвященного проекту Apache, основная группа разработчиков из 15 человек создала более 80% всего кода, реализующего функции системы [6]. Как правило, основные группы бывают очень невелики, но при этом они выполняют основной объем работ.
• Соразработчики добавляют и поддерживают функции системы. Возможность легко добавлять новые функции зависит от уровня модульности кода. Соразработчики, как правило, выбирают направления, четко очерченные в планах реализации проекта, или те, которые «задевают их за живое». Также они занимаются исправлением ошибок, анализом предлагаемого кода и оказывают другую помощь, освобождая основную группу от чересчур объемной работы по исправлению ошибок.
• Специалисты, сообщающие об ошибках, отвечают за тестирование и обнародование его результатов. Основные разработчики и соразработчики практически не занимаются решением этих задач. Достаточно большой размер этих групп гарантирует, что систему будет тестировать больше людей (и на большем числе платформ), чем этого могла бы добиться любая коммерческая организация. Эта группа играет основную роль в уменьшении «плотности» ошибок.

Участие и мотивация. Устойчивое сообщество нередко привлекает к работе программистов-волонтеров. Изучению мотивации волонтеров посвящено немалощисследований.                                                                                           Высокая модульность кода упрощает разработку и позволяет новичкам вносить свой вклад «на периферии», не влияя на основную систему, однако сама по себе модульность не сможет заинтересовать программистов в проекте. Аудрис Москус и его коллеги провели исследование Mozilla — проекта с высоким уровнем модульности, который сперва не заинтересовал волонтеров. Число его участников стало расти только после того, как основная группа доработала документацию, подготовила учебные руководства, а также усовершенствовала инструментарий и процессы разработки. Кроме того, важным стимулом для участия волонтеров в проекте становится желание изучить новые технологии и инструменты и попробоватьщсилыщвщрешениищновыхщзадач.                                                 Группы, создающие программы категории Open Source, должны понимать, что программисты редко соглашаются стать волонтерами бескорыстно — они хотят получить определенный статус в сообществе за счет признания их заслуг. Исследователи пришли к следующим выводам.