Управление качеством программного продукта

Управление качеством программного продукта Тема 1 ПОНЯТИЕ КАЧЕСТВА ПРОГРАММНОГО ПРОДУКТА 1.1. Роль программной инженерии в обеспечении качества программных средств Неуклонное повышение качества выпускаемых программных продуктов - основная цель современной информационной индустрии. Вопросами качества озабочены не толь- ко разработчики ПС для зарубежного заказчика (уровень требований которого всегда был высок), но и организации, работающие для российского заказчика. Это, в первую очередь, объясняется обострением конкуренции разработчиков, а, кроме того, - повыше- нием уровня знаний потребителей о качестве ПС и, как следствие, ростом их требований к качеству. В последние годы программная индустрия достигла такого уровня развития, при ко- тором требования к обеспечению качества стали обязательным пунктом заключаемых договоров на разработку программных систем (ПС). Программная система - группа интегрированных программных средств, поддер- живающих определенный деловой процесс потребителя (или его часть) и использующих общие хранилища данных. Пример ПС - группа программных приложений, составляю- щих автоматизированное рабочее место (АРМ) специалиста в определенной предметной области. Термин программное обеспечение (ПО) используется применительно к совокупности программных средств, приобретаемых или разрабатываемых с целью эксплуатации в со- ставе системы (системы автоматизации, информационные системы и др.). Примеры про- граммных средств: шрифт, драйвер, программное приложение. Мы говорим «программ- ное обеспечение системы», если хотим подчеркнуть его принадлежность к системе (включающей также техническое, организационное и другие виды обеспечения систе- мы). Основа качественной разработки программных систем – рациональная инфраструк- тура программной инженерии. Желание компаний получить наивысшую отдачу от инве- стиций в создание ПС побуждает их постоянно возвращаться к вопросу о текущей прак- тике разработки. Разработка ПС как вид бизнеса прошла за последние 30 лет тернистый путь от «закрученных» кодов на Коболе, Фортране и ПЛ/1, создаваемых исключительно в отделах Вычислительно-информационных центров, до приложений, проектируемых, моделируемых и разрабатываемых профессионалами в области информационных систем практически в постоянном взаимодействии с конечными пользователями. К сожалению, разработчики ПС нечасто завершают программные проекты вовремя, укладываются в рамки бюджета и полностью отражают в программных продуктах требо- вания спецификаций заказчика. Последствия поставки плохо разработанных программ- ных продуктов - это всегда убытки клиентов: не только материальные и финансовые по- тери, но и падение престижа. Эти проблемы, в свою очередь, негативно отражаются на конкурентоспособности организации-разработчика программных продуктов. И практи- кующие специалисты в области программных систем, и пользователи сходятся во взгля- дах на понятие плохого программного продукта как такого, который: • не обеспечивает поддержку стратегии бизнеса или потребностей пользователей; • недостаточно надежен, гибок, эффективен и плохо сопровождается; • является дорогим и слишком долго разрабатываемым. Причины плохого состояния практики разработки ПС заключаются в том, что разра- ботчики программных продуктов (ПП) испытывают недостаток в современных автома- тизированных инструментальных средствах, методологии разработки, обучении специа- листов. Кроме того, из-за неадекватной инфраструктуры, сообществу их потенциальных пользователей не отводится ведущая роль в определении методологий эксплуатации ПС, стандартных процедур обработки деловой информации, планов обеспечения ее безопас- ности и пр. Поэтому многие пользователи прерывают применение программных продук- тов, которые не только плохо разработаны и несовместимы, но и подвергают опасности целостность данных компании. Пользователи сталкиваются с недостатками в программных продуктах из-за того, что те не имеют завершенной технологии поддержки всего жизненного цикла ПС, начи- ная от ее замысла и кончая списанием. Многие организации-разработчики продолжают использовать тот же ограниченный и не интегрированный набор инструментальных средств и методологий для построения ПС, что и десятилетие тому назад. Эта практика продолжается, несмотря на существенный прогресс в применяемых пользователями ос- новных информационных технологиях и повышение их требований к разрабатываемым по договорам программным продуктам. Руководство организаций-разработчиков по техническим, экономическим и соци- альным причинам запаздывает с созданием эффективной инфраструктуры, способной обеспечить специалистов инструментальными средствами и методологиями, поддержи- вающими разработку высококачественных ПС. Инфраструктура программной инженерии - интегрированный набор общедоступных технических, технологических и методологических ресурсов организации-разработчика, которые делают возможным выполнение процесса программной инженерии коллектива- ми проектов, открываемых по договорам с заказчиком программных продуктов. Проект – это ограниченная временными рамками деятельность, цель которой со- стоит в создании уникального программного продукта. Процесс программной инженерии – это множество логически связанных видов де- ятельности по определению, проектированию и построению программных продуктов (прикладных программных систем). Этот процесс направлен на обеспечение и контроль качества ПП. Совместное использование ресурсов инфраструктуры позволяет организации повы- шать продуктивность исполнения программных проектов, создавая потенциал для со- вершенствования качества программных систем и снижения их стоимости. 1.2. Аспекты определения качества программных средств Качество - это совокупность свойств программной системы, обеспечивающих ее способность удовлетворять установленные или предполагаемые потребности в соответ- ствии с назначением. При определении требований к качеству, обычно перечисляются внешние характе- ристики качества, отражающие требования к функционирующему программному про- дукту. Далее, для того чтобы количественно определить критерии качества, по которым будет осуществляться проверка и подтверждение соответствия ПС предъявляемым к ней требованиям, специфицируются: подходящие внешние измеримые свойства (внешние атрибуты) ПС и связанные с ними метрики (или показатели), представляющие собой мо- дели оценивания атрибутов; приемлемые диапазоны изменения значений (мер) соответ- ствующих атрибутов. Метрики, определение и применение которых возможно только для работающего на компьютере программного обеспечения, находящегося на стадии тестирования или функционирования в составе системы, называются внешними метриками. После определения требований к внешним метрикам специфицируются внутренние характеристики качества и внутренние атрибуты ПС. Они используются для планиро- вания достижения требуемых внешних характеристик качества конечного программного продукта и их встраивания в промежуточные (рабочие) продукты ПС в ходе разработки. Далее специфицируются внутренние метрики для квантификации внутренних ха- рактеристик качества, которые могли бы использоваться для проверки соответствия промежуточных продуктов спецификациям внутренних требований к качеству на стади- ях разработки. Понятие внутренних характеристик качества, атрибутов и метрик связывается с не работающими на компьютере рабочими продуктами ПС (документами, текстами кода, тестами и др.), получаемыми на стадиях разработки, предшествующих тестированию (определение требований, проектирование, кодирование). Нужно отметить, что внешние и внутренние характеристики качества касаются свойств самой программной системы. Они отражают, в большей мере, взгляд заказчика и разработчика на программную систему. Однако непосредственный конечный пользователь ждет достижения максимального совокупного эффекта от применения ПС - повышения продуктивности работы и общей удовлетворенности программным продуктом. Такой взгляд на качество ПС обозначается термином «качество в использовании» или «эксплуатационное качество» ПС. Качество ПС в использовании - совокупный эффект характеристик качества для конечного пользователя, измеряемый в терминах результата использования, а не свойств самой программной системы. На качество в использовании может влиять любая характе- ристика качества. Это понятие шире, чем какая-либо одна характеристика (например, удобство применения или надежность). Качество ПС должно оцениваться исходя из определенной модели качества. В соот- ветствии со стандартом ISO/IEC 9126 модель качества представляет собой множество взаимосвязанных характеристик, образующих базис для спецификации требований к ка- честву и оценивания качества ПС. На качество ПС, а также на выбор модели качества, множества внешних и внутрен- них метрик качества влияют следующие факторы, определяющие требования к каче- ству: 1. Прикладная область и категории пользователей. Модель качества может вклю- чать множество характеристик качества. Но, каждая из этих характеристик имеет тот или иной вес (значимость) в определенной прикладной сфере и для соответствующего сооб- щества пользователей и отражает точку зрения на качество отдельных категорий пользо- вателей. Например, для критических систем качество обычно связывается с удовлетво- рением требований к защищенности информации, безопасности функционирования, до- стоверности, производительности и др. Причем, атрибут производительность (реактив- ность) наиболее важен для жестких систем реального времени, достоверность - для сверхнадежных и отказоустойчивых систем, защищенность информации - для учрежден- ческих и банковских систем. Безопасность функционирования важна с позиций анализа угроз и инженерии безопасных систем. Этот фактор необходимо учитывать как один из основных при формировании модели качества конкретной ПС. 2. Цель моделирования качества. В зависимости от цели моделирования качества, модель может в разной степени отражать взгляд на качество различных категорий участ- ников процессов разработки и эксплуатации (сопровождения) ПС - менеджеров, разра- ботчиков, персонала сопровождения, пользователей, - и содержать упорядоченное мно- жество характеристик, обеспечивающих непротиворечивость их интересов. Стратегия измерения и повышения качества должна основываться на учете приоритета (по значи- мости, по времени удовлетворения) тех или иных интересов. В большинстве случаев приоритетным, с точки зрения участников проекта ПС, явля- ется взгляд менеджера и его интересы в управлении риском проекта. 3. Стадия жизненного цикла. Для того чтобы должным образом управлять каче- ством на каждой стадии ЖЦ ПС, необходимо рассматривать разнообразные аспекты ка- чества и учитывать изменение представлений о качестве с течением ЖЦ. Стандарт ISO/IEC 9126 предлагает варьировать взгляды на качество продукта по стадиям ЖЦ следующим образом: целевое качество - необходимое и достаточное качество, которое отражает реальные потребности пользователя. Поскольку потребности, заявленные заказчиком, не всегда отражают реальные нужды пользователей относительно качества программного продук- та, и эти нужды могут изменяться после того, как заявлены (установлены), - целевое ка- чество рассматривается разработчиками как концептуальная сущность, которая не может быть полностью определена в начале проекта и должна рассматриваться как ориентир. Требования к целевому качеству должны по возможности включаться в спецификацию требований к качеству ПС и оцениваться путем измерения эксплуатационного качества по завершении разработки программного продукта; затребованное (установленное) качество продукта - это тот уровень значений ха- рактеристик внешнего качества, который фактически заявлен в спецификации требова- ний к качеству и должен использоваться как цель для его проверки. Требования ко всем или некоторым характеристикам качества указываются в спецификации требований к ПС. Наряду с оптимальными значениями характеристик должны также указываться ми- нимальные значения, что поможет заказчикам и разработчикам избежать ненужного пре- вышения стоимости и сроков разработки; качество программного проекта – внутреннее качество ПС, представленное в опи- сании основных частей или всего проекта, например, архитектуры программного обеспе- чения, структуры программ, стратегии проектирования интерфейса пользователя и т.п. Качество проекта – основа качества программного продукта, которое может быть лишь незначительно улучшено в ходе кодирования и тестирования; оцененное (или прогнозируемое) качество продукта - качество, которое оценива- ется или предсказывается как качество конечного программного продукта на каждой стадии разработки на основании характеристик качества программного проекта; качество поставляемого продукта - это качество готового к поставке продукта, как правило, протестированного в моделируемой среде на моделируемых данных. качество в использовании (эксплуатационное качество) - качество ПС, измеряемое в терминах результатов ее использования, а не свойств. Качество ПС в пользовательской среде может отличаться от качества в среде разработки из-за недоучета особенностей среды и сценариев применения ПС и, как следствие, неадекватного тести- рования. Пользователь оценивает только те атрибуты ПС, которые видны ему в ходе фактического использования. 4. Размер и сложность. За исключением очень простых проектов, различные ком- поненты ПС обычно имеют совершенно разные требования к характеристикам качества. Например, компоненты, обеспечивающие интерфейс с пользователем, характеризуются высокими требованиями к удобству применения, а базы данных - повышенными требо- ваниями к целостности. Концептуальное разделение единого программного продукта на компоненты, характеризующиеся однотипными требованиями к качеству, помогает сни- зить конфликты между требованиями. 5. Методология проектирования и наличие CASE-инструментов. В пределах одной организации процессы разработки могут иметь различное наполнение и варьироваться в зависимости от применяемых в проектах методологий и интегрированных инструментов. Эти различия ограничивают возможность использования одного и того же множества метрик по различным проектам. Очевидно, например, что не имеет смысла сравнивать число строк кода, разработанного с применением структурных методов, с числом строк, разработанных объектно-ориентированным методом. 6. Уровень зрелости организации-разработчика. Существует множество моделей зрелости организаций-разработчиков ПС, определяющих критерии оценивания мощно- сти процессов и эффективности проектов разработки. Стремление организаций- разработчиков обеспечить конкурентоспособность выпускаемой программной продук- ции служит хорошим стимулом не только для повышения технического и технологиче- ского уровня проектов, но и для постоянного совершенствования процессов организации и управления разработкой, их оценивания по моделям зрелости и получения соответ- ствующих сертификатов (например, сертификатов системы качества). Очевидно, что чем выше уровень зрелости организации, тем совершеннее процессы, связанные с обеспече- нием качества ПС. 7. Исторический опыт разработки. В достаточно зрелой организации-разработчике ПС, специализирующейся на выпуске однотипных программных продуктов, складыва- ются определенные подходы к обучению сотрудников, стратегии проектирования и про- граммирования, приемы сбора и регистрации всевозможных данных, методологии вы- полнения измерений ПС и т.д. Это дает им возможность использовать собственный опыт разработки программных систем со схожими характеристиками, накапливать полезную историческую информацию по проектам, относящуюся к качеству, и, таким образом, бо- лее точно строить модель качества, выбирать подходящие метрики, устанавливать коли- чественные меры для всех характеристик качества ПС и прогнозировать достижение ос- новных характеристик качества (например, надежности) уже на ранних стадиях разра- ботки. 8. Конфликты требований. Множество функциональных и нефункциональных тре- бований к программной системе (в том числе требований к качеству) могут вступать в конфликты, которые должны разрешаться на всех стадиях ее разработки. Тема 2 ПОДХОДЫ К ПОВЫШЕНИЮ КАЧЕСТВА ПРОГРАММНЫХ СИСТЕМ 2.1. Применение процессов контроля качества Первый шаг к повышению качества ПС состоит во внедрении в повседневную прак- тику организаций-разработчиков специально предназначенных для этого поддерживаю- щих процессов ЖЦ ПС, регламентируемых стандартом ISO/IEC 12207 по процессам жизненного цикла ПС, а именно процессов гарантирования качества, верификации, ва- лидации, совместного просмотра и аудита. Применение этих процессов обеспечивает руководство организации и проекта методами и средствами контроля за соблюдением требований к процессам разработки и качеству рабочих продуктов на каждой стадии ЖЦ проекта. Применяемый далее термин «гарантирование качества» соответствует обычно ис- пользуемому за рубежом термину «Software Quality Assurance» (SQA), получившему в издаваемой у нас переводной литературе по программной инженерии и отечественных стандартах разные варианты перевода, например, «обеспечение качества», «контроль ка- чества». Может сложиться впечатление, что именно (и только) процесс SQA должен обеспе- чивать качество программных продуктов или контролировать качество, что неверно. Без вовлечения в контроль качества других процессов ЖЦ достижение целей качества было бы невозможным. Процесс SQA обеспечивает гарантии (от assurance – давать заверения, гарантиро- вать), что программные продукты и процессы в жизненном цикле проекта соответствуют предъявляемым к ним требованиям. Эти гарантии основаны на том, что SQA планирует и осуществляет контроль и оказание помощи в той деятельности по проекту, которая непосредственно связана со «встраиванием» в программные продукты свойств, обеспе- чивающих качество. SQA устанавливает стандарты, отвечающие передовой практике программной инженерии (нормы, правила, требования - как к процессам, так и к их про- дуктам) и контролирует их соблюдение в ходе ЖЦ. SQA гарантирует, что проблемы, неизбежно возникающие в любой комплексной де- ятельности (каковой является совместное выполнение процессов ЖЦ), своевременно идентифицируются и устраняются, что запланированные процессы пригодны для приме- нения и надлежащим образом выполняются в соответствии с планом и что результаты выполняемых в проекте измерений могут быть использованы для регулирования дея- тельности в процессах ЖЦ. Цель SQA – установить, почему допускаются ошибки и как они могут быть устране- ны. Таким образом, объектом исследований SQA являются в основном процессы ЖЦ ПС, а не программные продукты (в том числе рабочие продукты), качество которых должно быть обеспечено. Для контроля качества программных продуктов (включая все рабочие продукты) предназначены процессы верификации и валидации. Процессы верификации и валидации определяют, действительно ли продукты определенного этапа процесса разработки и сопровождения ПС соответствуют виду и потребностям данного шага и отвечают требованиям, предъявляемым к ним в начале этапа, а также в начале процесса. Задача верификации и валидации – проверить и под- твердить, что конечный программный продукт будет отвечать своему назначению и удовлетворять пользователей. Эти процессы контролируют качество путем выявления ошибок в продуктах процессов ЖЦ, не исследуя коренных причин появления этих оши- бок. Цель верификации – исследуя трансформации одних (входных) рабочих продуктов в другие (выходные) рабочие продукты проверить, правильно ли разрабатывается про- граммный продукт (например, правильный ли код программного модуля по отношению к спецификации проекта этого модуля). Цель валидации – исследуя совокупность рабочих продуктов, полученных на опре- деленном этапе процесса разработки, убедиться в том, что они разработаны правильно, то есть отвечают назначению и специфицированным исходным требованиям к про- граммному продукту (например, совокупность программных модулей действительно представляет требуемый программный продукт, совокупность выполненных тестов дей- ствительно достаточна для проверки всех функций ПС и т.п.). И процесс верификации, и процесс валидации должны выполняться, начиная с са- мых ранних стадий ЖЦ ПС и применительно ко всем рабочим продуктам разработки (включая, например, планы). Эти процессы тесно взаимосвязаны и обычно определяются одним термином «верификация и валидация», которому соответствует термин «Verification and Validation» (V&V), используемый в зарубежной литературе. Нужно отметить, что контроль процессов SQA и V&V осуществляет руководство проекта или организации (для независимого SQA или независимой верификации и вали- дации), а сами процессы координируют действия по проверке рабочих продуктов и дру- гих процессов. Существует множество методов, пригодных для применения как в целях SQA, так и в целях V&V. Один из видов их классификации – деление на статические и динамические, не связанные и связанные с выполнением программ на компьютере, соот- ветственно. Статические методы касаются исследования документации по проекту (процес- сам, рабочим продуктам и пр.) одним лицом или группой лиц (коллективно), возможно с применением инструментальных средств поддержки. К методам коллективной работы относятся инспекции, ревизии, сквозной контроль и др. Они могут также определяться и выполняться как самостоятельные поддерживаю- щие процессы ЖЦ. Методы индивидуальной работы предполагают проведение аналитических исследо- ваний (например, анализ потоков данных, причинно-следственный анализ, анализ дере- вьев событий и деревьев отказов, анализ сложности алгоритмов, формальное доказатель- ство корректности и др.). К динамическим методам обычно относят тестирование, имитационное моделиро- вание и символическое выполнение. Отметим, что тестированию, с одной стороны, отводится место среди основных процессов ЖЦ ПС, а с другой - его принято считать ключевым методом V&V . Ценность этих методов состоит в обеспечении обратной связи при управлении про- ектом и стимула к повышению качества программных продуктов и усовершенствованию процессов. 2.2. Использование прогнозирования при управлении программным проектом Прогнозирование (от греческого prognosis – знание наперед, предвидение) заключа- ется в специальном исследовании перспектив какого-либо явления. Научно-техническое прогнозирование – один из ключевых этапов управления. Осуществляется методами экс- траполяции, интерполяции, моделирования, обобщения мнений экспертов, исторической аналогии, построения прогнозных сценариев и т.п. В практической программной инженерии обычно используется так называемое нор- мативное прогнозирование. Оно сводится к определению возможных путей решения проблем управления проектами разработки ПС с целью достижения желательного ре- зультата посредством сопоставления реальных данных и нормативов с учетом заранее заданных критериев. Такое прогнозирование основывается на обобщении эксперимен- тальных данных и знании объективных закономерностей развития наблюдаемых явлений в проекте. Прогнозирование предполагает предсказание значений определенных величин в бу- дущем по измеренным данным и полученным оценкам реально существующих в настоя- щем объектов. Например, с объемом кода прогнозирование заключается в ответе на во- прос, каким будет размер разрабатываемой ПС (выраженный в единицах KSLOC), если известно число функций, которые она должна будет выполнять, а также объемы и струк- тура информации, которая должна будет обрабатываться при выполнении каждой функ- ции? Таким образом, основа прогнозирования – измерение и оценивание. С целью повышения качества разрабатываемых ПС, в ходе управления программ- ным проектом нужно прогнозировать влияние на качество всех ранее упомянутых фак- торов, однако отрасль прогнозирования в программной инженерии имеет пока еще слишком слабую экспериментальную базу для формирования каких-либо нормативов, а измерение, как процесс, вообще отсутствует в отечественной практике разработки ПС. 2.3. Значение повышения зрелости организации для обеспечения качества ПП Концепция зрелости организаций-разработчиков ПС стала популярной благодаря работам Уотса Хамфри из института SEI (Software Engineering Institute) (США), хотя ее истоки – в 60 годах (работы Р. Лайкерта). У. Хамфри разработал пятиуровневую модель зрелости - СММ (от Capability Maturity Model), которая определяет характеристики об- щего процесса программной инженерии в организации, находящейся на определенном уровне зрелости, и указывает эволюционный путь его улучшения. Зрелость организации можно охарактеризовать как степень четкости (ясности) определения, управления, измерения, контроля и выполнения процесса разработки ПС в организации. Она свидетельствует, с одной стороны, о совершенстве всей совокупности процессов в организации в целом, а, с другой стороны, о степени их применимости (адаптируемости) к конкретным проектам организации. Знание степени зрелости органи- зации помогает предсказать возможности каждого проекта в достижении поставленных перед ним целей. Модель зрелости представляет собой шаблон для оформления маленьких эволюци- онных шагов по улучшению процесса в виде пяти уровней зрелости, каждый из которых является четко определенной платформой для достижения зрелого процесса программ- ной инженерии. Такая структура СММ определяет приоритетность действий в направ- лении повышения зрелости процесса. Пять уровней зрелости по модели СММ таковы: уровень 1 - начальный. Он включен в модель только с целью образования точки от- счета (базы) для оценивания последующих улучшений процесса на более высоких уров- нях модели. Характеризуется тем, что процесс разработки ПС неструктурирован и хао- тичен, а бюджет, график и качество разработки непредсказуемы; уровень 2 - повторяемый. На этом уровне управление проектом нацелено на кон- троль соблюдения планов по стоимости, продолжительности и функциональности разра- ботки. Дисциплина разработки позволяет применять отработанные приемы управления неоднократно для схожих между собой проектов. Разработка новых проектов ведется на основе ранее накопленного опыта и в соответствии с основными стандартами в области технологии программирования; уровень 3 - фиксированный. Процесс программной инженерии (охватывающий дея- тельность как в части управления разработкой, так и в части собственно разработки) ин- ституциализирован в организации (утвержден, стандартизован и документирован). Внед- рена программа обучения штата разработчиков ПС и менеджеров. Коллективы отдель- ных проектов следуют базовому процессу разработки в организации и настраивают его для достижения целей конкретного проекта; уровень 4 - управляемый. Достигается цель количественной оценки качества про- граммных продуктов и процесса разработки в рамках единой программы измерения. Осуществляется сбор и анализ данных по проектам, что дает возможность управлять риском проекта и, при необходимости, “возвращать” процесс в установленные рамки; уровень 5 - оптимизируемый. Обеспечивается непрерывное улучшение процесса благодаря наличию средств количественной оценки его слабых и сильных сторон. Дан- ные об эффективности процесса разработки используются для проведения анализа в це- лях перехода на новые технологии и совершенствования процесса разработки в органи- зации. Данные о новых приемах инженерии изучаются и распространяются по организа- ции. Коллективами проектов производится причинно-следственный анализ ошибок в проектах. Таким образом, уровни зрелости в СММ описывают характеристики организации на соответствующих уровнях. Каждый уровень зрелости определяет проблемы, которые преобладают на уровне, и образует фундамент для эффективной реализации процессов на последующих уровнях, поэтому пропуск уровней противоестественен. Уровни зрелости, за исключением первого, касаются ряда ключевых направлений процесса программной инженерии. Каждое направление, в свою очередь, представлено пятью общими разделами, а каждый раздел определяет перечень рекомендуемых прак- тических действий (приемов, процедур), при совместном выполнении которых достига- ются цели, поставленные во главу угла по соответствующему ключевому направлению процесса. 2.4. Управление качеством и внедрение системы качества Полноценное обеспечение качества можно связывать только с непрерывным управ- лением качеством на количественной основе. Управление качеством ПС - целенаправленная систематическая деятельность по планированию, учету, контролю и регулированию качества ПС в ходе ее разработки. Способность непрерывно управлять происходящими процессами в условиях огра- ниченных стоимостных, временных, трудовых и других ресурсов и обеспечивать посто- янную оптимизацию пользовательских требований и ограничений - свидетельство высо- кой зрелости организации. В соответствии с моделью СММ, чем выше уровень управления и шире спектр ас- пектов управления, тем выше уровень зрелости организации-разработчика ПС. Напри- мер, принадлежность ко второму уровню зрелости по модели СММ характеризуется наличием, как минимум, таких ключевых направлений – «управление требованиями», «управление работами соисполнителей» и «управление конфигурацией», а также присут- ствием отдельных элементов управления – «планирование проекта», «гарантирование (контроль) качества (SQA)» и «мониторинг (учет и контроль) проекта». По мере созда- ния и организационного оформления процессов ЖЦ и применения инженерного подхода к разработке у организации-разработчика появляется возможность дополнить деятель- ность по управлению элементом регулирования и сделать ее полноценной. Такая воз- можность объясняется прозрачностью (просматриваемостью) процессов и измеримо- стью как процессов, так и продуктов ПС. Так, на третьем уровне модели СММ, плани- рование и мониторинг проекта перерастают в «интегрированное управление проектом», а затем в «управление процессами» (на четвертом уровне СММ) и «управление измене- ниями» (на пятом уровне СММ). То же можно сказать и о качестве ПС, управляемость которого повышается от уров- ня к уровню – от SQA (на втором уровне СММ) к улучшению качества за счет осуществ- ления инженерии процессов (на третьем уровне СММ) и, наконец, к управлению каче- ством ПС (на четвертом уровне СММ). Только управление качеством, как направление деятельности организации- разработчика ПС, может стать залогом создания конкурентоспособных программных продуктов, качество которых может непрерывно улучшаться. Основополагающими стандартами в области качества продукции являются стандар- ты ISO серии 9000. Эти стандарты рекомендуют каждой разрабатывающей или постав- ляющей программные продукты организации иметь свою систему качества. Система качества ПС - это совокупность организационной структуры, ответствен- ности, процедур, процессов и ресурсов, направленных на реализацию управления каче- ством ПС. Действующая в организации-разработчике ПС система качества обеспечивает решение задач контроля, инженерии и управления качеством и действительно может га- рантировать высокое качество программных продуктов. 2.5. Область знаний программной инженерии «Качество программного обеспе- чения» Качество ПО (Software Quality) – совокупность свойств программного продукта, обеспечивающих его способность удовлетворять установленным или предполагаемым требованиям заказчика (пользователя). В это определение понятия вкладывается разный смысл в зависимости от контекста его применения и аспектов рассмотрения. Можно раз- личать, например, рыночное качество ПО (market-driven quality), потребительское каче- ство (customer-driven quality); качество ПО с позиций его сопровождения, обеспечения безопасности и т.п.; качество внутренне, внешнее и эксплуатационное. Залог повышения качества при процессном подходе – применение процессов проверки (верификации, те- стирования, аудита и др.), нацеленных на своевременное обнаружение и устранение де- фектов в ПО и изъянов в самих процессах ЖЦ. Даная область знаний SWEBOK охваты- вает вопросы статической проверки продуктов и процессов. Вопросы тестирования, как способа динамической проверки работы ПО, в данной области знаний SWEBOK не рас- сматриваются. Область знаний включает следующие разделы: ▪ основы качества ПО (Software Quality Fundamentals), ▪ процессы управления качеством (Software Quality Management Processes), ▪ практические соображения (Practical Considerations). В разделе Основы качества ПО подчеркивается, что все вопросы качества должны рассматриваться в контексте требований к программному продукту, которые не только определяют необходимые характеристики качества ПО, но и обусловливают выбор ме- тодов их количественной оценки и критериев приемки ПО. ИТ-специалисты должны воспринимать вопросы качества как часть своей профес- сиональной культуры. Требования к характеристикам качества всегда являются резуль- татом определенного компромисса (как по но-менклатуре и значениям характеристик, так и по стоимости обеспечения и ценности этих характеристик для заказчика). Стои- мость качества дифференцируется как стоимость предупреждения дефектов, стоимость оценки качества, цены внутренних сбоев и внешних потерь. Большинство альтернатив- ных компромиссных решений по качеству должно предлагаться и приниматься в процес- се работы с требованиями, однако вопросы, касающиеся качества, могут подниматься на протяжении всего ЖЦ ПО и в рамках любых процессов ЖЦ. Способы построения моделей качества различны - иерархии, графические образы и т.п. Базовый стандарт по качеству ПП - ISO/IEC 9126-1:2001 «Software Engineering - Product Quality, Part 1: Quality Model» - предлагает рассматривать качество на трех уров- нях его обеспечения в артефактах проекта (внутреннее качество, внешнее качество и ка- чество ПО в эксплуатации) и рекомендует иерархическую модель качества для каждого из этих уровней. Оценивается качество в соответствии со стандартом ISO/IEC 14598:1999 «Information Technology – Software Product Evaluation». Непосредственное отношение к качеству создаваемого продукта имеет управление качеством (SQM, от Software Quality Management) и качество процессов программной инженерии. В области управления (менеджмента) качества важнейшими являются стан- дарты TickIT и ISO 90003:2004 «Software and Systems Engineering -Guidelines for the Ap- plication of ISO 9001:2000 to Computer Software», а в области качества (мощности, зрело- сти) процессов ЖЦ – стандарты CMMI и ISO/IEC 15504:2004 «Information Technology - Software Process Assessment» (модель SPICE, от Software Process Improvement and Capa- bility dEtermination). Эти стандарты взаимно дополняют друг друга, причем сертифика- ция процессов по ISO 9001 помогает в достижении старших уровней зрелости. Понимание термина продукт в данной области знаний расширено включением лю- бых артефактов, создаваемых в результате выполнения всех процессов ЖЦ, используе- мых для создания конечного программного продукта (например, спецификации систем- ных требований и требований для программных компонентов, моделей, кода, тестовой документации и др.). Признаком высокой зрелости организации является наличие и ис- пользование собственных (исторических) данных относительно требований к качеству отдельных артефактов и результатов оценки их фактического достижения. Это дает воз- можность оценивать соответствие заданным характеристикам качества не только конеч- ного продукта, но и промежуточных результатов/продуктов ЖЦ в рамках всех процессов программной инженерии. Качество ПО может повышаться в ходе итеративного процесса его постоянного улучшения, требующего контроля, координации и обратной связи при управлении одно- временно выполняемыми процессами: разработки, обнаружения, устранения и предот- вращения дефектов, а также совершенствования процессов ЖЦ. Раздел Процессы управления качеством ПО рассматривает во взаимосвязи процес- сы обеспечения гарантии качества (SQA, от Software Quality Assurance), верификации и валидации, обзора (совместного просмотра) и аудита, а также собственно процесс управления качеством (SQM), обеспечивающий функции контроля и оценки по всем ас- пектам процессов, продуктов и ресурсов, включая требования к процессам, измерения процессов и их результатов и установление обратной связи. SQA концентрируется на процессах. Роль SQA состоит в том, чтобы обеспечить планирование процессов, дальнейшее исполнение процессов на основе заданного плана и проведение необходимых измерений процессов. Верификация и валидация (V&V, от Verification and Validation) применяется к артефактам проекта в его контрольных точ- ках с целью проверки и подтверждения их правильности. Действия по V&V регламенти- руются базовыми стандартами IEEE 1012:1998 «Software Verification and Validation» и IEEE 1059:1993 «IEEE Guide for Software Verification and Validation Plans». Деятельность по обзорам и аудитам продуктов включает пять типов действий: управленческие обзоры, технические обзоры, инспекции, сквозной контроль и аудиты, и регламентируется стан- дартом IEEE 1028:1997 «IEEE Standard for Software Reviews». Практические соображения в данной области касаются, прежде всего, определе- ния факторов, влияющих на выбор стратегии SQM. Один из них – критичность обла- сти применения ПО. Комплексной характеристикой качества такого ПО является гаран- тоспособность (dependability) - совокупность свойств ПО, обеспечивающих его отказо- устойчивость (fault tolerance), безопасность эксплуатации (safety), защищенность инфор- мации (security), а также удобство и простоту использования (usability). Другой важный фактор – уровень необходимой целостности ПО, связываемый с оценкой возможных последствий отказа ПО и вероятности его возникновения. Обеспе- чение целостности ПО требует привлечения приемов анализа опасностей окружению и угроз целостности информации. В этом разделе высказываются также практические соображения относительно опи- сания характеристик дефектов (рекомендуемый стандарт IEEE 1044:1993 «IEEE Stand- ard for the Classification of Software Anomalies»), сбора и регистрации данных о дефектах, отчетов об устранении дефектов и т.п. Дается классификация приемов SQM, включая статические и динамические, коллек- тивные и индивидуальные, а также аналитические (формальные и неформальные) прие- мы. Подчеркивается, что тестирование может и должно применяться для решения таких задач SQM: • оценка и тестирование инструментов, используемых в проекте (согласно ISO/IEC 14102:1995 «Information Technology - Guideline for the Evaluation and Selection of CASE Tools»), • тестирование соответствия компонентов ПО и COTS-продуктов (от commercial of- the-shelf, готовый к использованию продукт, продукт «с полки») потребностям их ис- пользования в создаваемом продукте (согласно ISO/IEC 12119: 1994 «Information Tech- nology–Software Packages - Quality Requirements and Testing»). Эта область знаний охватывает также такие аспекты, как количественная оценка ка- чества ПО с использованием метрик и оценка стоимости процесса SQM. Тема 3 МЕТРИКИ КАЧЕСТВА ПРОГРАММНЫХ СИСТЕМ 3.1. Метрика как основа измерения Атрибуты программной системы, характеризующие ее качество, измеряются с ис- пользованием метрик качества. Метрика – это комбинация конкретного метода измерения (способа получения значений) атрибута сущности и шкалы измерения (средства, используемого для структу- рирования получаемых значений). Метрика определяет меру атрибута – переменную, которой присваивается значение в результате измерения. Например, сущность – «отчет об обнаруженных дефектах», ат- рибут – «список дефектов», метод измерения – «подсчет количества дефектов в списке», шкала – «целые числа больше нуля», мера атрибута – «общее число дефектов», имя мет- рики (обычно одноименное мере) – «общее число дефектов». Мера атрибута может быть непосредственной, если она не зависит от мер других ат- рибутов, либо косвенной, полученной по мерам других атрибутов. По определению стандарта ISO/IEC 9126-2 метрика качества программной систе- мы представляет собой «модель измерения атрибута, связываемого с характеристикой качества ПС. Служит индикатором одного или многих атрибутов. Для того чтобы правильно пользоваться результатами измерений, для каждой меры нужно идентифицировать шкалу измерения. Стандарт ISO/IEC 9126-2 рекомендует применять 5 видов шкал измерения значений (упорядоченных от менее строгих к более строгим): номинальная шкала. Это классификационная шкала, выполняющая категоризацию свойств оцениваемого объекта. Категории не упорядочены. Например, дефекты могут классифицироваться на дефекты интерфейса, логики, объявления данных и др. ; порядковая шкала. Позволяет упорядочивать характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями. Например, для уровня серьезно- сти последствий события шкала может включать значения «низкий», «средний», «высо- кий», «критический». Для уровней СММ – 1, 2, 3, 4, 5. Расстояние между значениями по шкале не играет роли. Характеристики, имеющие номинальную или порядковую шкалу измерения, называются качественными (или категорийными). Все остальные - количе- ственными. интервальная шкала. Отмечает существенные различия свойств объекта, «дистан- цию» между ними (например, календарные даты или значения плотности дефектов - 1.5 дефекта/KSLOC, 3.5 дефекта/KSLOC и т.д.). Используется в арифметических операциях и операциях сравнения; относительная шкала. Значения по этой шкале различаются по отношению к вы- бранной единице (например, времени, изменяющемся от 0 до бесконечности, или стои- мости). Применяя эту шкалу можно рассчитать, например, время между отказами, размер программного компонента в SLOC и др. Считается наиболее предпочтительной шкалой измерений. Позволяет применять широкий спектр инструментов измерения (гистограмм, диаграмм Парето и др.); абсолютная шкала. Это специальный случай относительной шкалы. В этой шкале указывается абсолютное значение величины. Например: «размер программы равен 2К», «число обнаруженных ошибок равно 20». Измеренное значение метрики само по себе не несет информации об уровне удовле- творения требований к качеству. Для этих целей шкала должна быть разделена на обла- сти (ранги), соответствующие различным степеням удовлетворения требований. Приме- ры деления шкалы: • деление значений по двум категориям - удовлетворительные и неудовлетворительные значения; • деление шкалы по четырем категориям, ограниченным тремя уровнями значений - те- кущим, худшим и плановым . По мере накопления практики измерений и знаний об измеряемых атрибутах шкалы их измерения могут эволюционировать от менее информативных (номинальной и поряд- ковой) к более информативным (относительной или абсолютной). 3.2. Классификация мер качества Для разработки процедур сбора данных, интерпретации мер и их нормализации с целью сравнения, нужно различать следующие типы мер, определяемых метриками. меры размера. Представляют размер ПС в разных единицах измерения, например: ◦ функциональный размер (учет функциональных возможностей ПС. Значение пред- ставлено в условных единицах функциональности ); ◦ размер программы (учет числа строк исходного кода, количества модулей, количе- ства операторов на языке программирования); ◦ объем ресурсов, используемых работающей программой (учет объема оперативной памяти, дисковой памяти или сетевого трафика, загруженности процессора - количества обрабатываемых инструкций в секунду и др.); меры времени. Представляют периоды реального времени (в секундах, минутах или часах), процессорного времени (в секундах, минутах или часах работы процессора) или календарного времени (в рабочих часах, календарных днях, месяцах, годах), например: ◦ время функционирования системы с непрерывной или дискретной работой компо- нентов программного обеспечения (учет истекшего времени (при работе программного обеспечения в системе в течение установленного периода времени), учет времени с мо- мента включения (при непрерывном использовании встроенного программного обеспе- чения системы реального времени), учет нормализованного времени (при совместной ра- боте нескольких компьютеров, обменивающихся данными); ◦ время выполнения (время, необходимое работающему программному компоненту системы для завершения решения определенной задачи в определенных условиях); ◦ время использования (время, затрачиваемое определенным пользователем на ре- шение задач с помощью ПС), например: время сеанса работы (от начала до завершения), время решения задачи и др.; меры усилий. Представляют полезное (продуктивное) время, связанное с опреде- ленной задачей проекта, например: ◦ производительность труда (при индивидуальной работе); ◦ трудоемкость (при коллективной работе); меры интервалов между событиями. Представляют интервалы времени между наступлением событий, происходящих в определенный период наблюдения, например, время между последовательными отказами. Вместо этой меры может использоваться частота наступления событий; счетные меры. Представляют собой статические счетчики (для учета определен- ных элементов в рабочих продуктах ПС (документах)) или кинетические (динамические) счетчики (для учета событий или действий человека), например: ◦ количество обнаруженных ошибок (учет ошибок в ходе инспекции, тестирования, функционирования или сопровождения ПС); ◦ структурная сложность программы (количество путей в программе, цикломати- ческая сложность и др.); ◦ число несовместимых элементов (учет ошибок согласования (требований, стандар- тов, форматов и др.), учет ответов типа «да»/«нет» в вопросниках); ◦ число изменений (учет элементов конфигурации, в которых произошли изменения): ◦ число обнаруженных отказов (учет отказов при тестировании, функционировании или сопровождении ПС); ◦ число попыток (учет попыток корректировки дефектов или ошибок); ◦ эргономические счетчики – число нажатий клавиш, щелчков на кнопках и др. ◦ счетчики-оценки (-очки, -баллы) (учет результатов, представленных в вопросни- ках, контрольных листах и др.). При выполнении измерений базовые меры размера, времени и счета могут исполь- зоваться в различных комбинациях. Они служат основой для нормализации и обеспечи- вают возможность сопоставления метрик. 3.3. Классификация метрик качества Для удобства применения общих приемов измерений метрики обычно классифици- руют как: объективные/субъективные. Объективные метрики включают подсчеты элементов, которые могут быть независимо проверены (число строк кода, число ошибок, сложность и др.). Они снижают влияние личного мнения на вычисление и анализ метрик. Субъек- тивные метрики основываются на индивидуальном или коллективном понимании или предпочтении определенных характеристик или условий (уровень сложности проблем, стоимостные коэффициенты и др.); примитивные/вычисляемые. Примитивные (базовые) метрики можно непосред- ственно наблюдать (размер программы в KSLOC, число дефектов, найденных при тести- ровании и др.). Вычисляемые метрики не могут непосредственно наблюдаться, но могут вычисляться по примитивным метрикам (число дефектов, приходящихся на SLOC, тру- доемкость и др.); динамические/статические. Динамическим метрикам свойственен компонент вре- мени. Значения изменяются с течением времени, начиная с момента сбора данных (например, число ошибок в месяц). Статические метрики инвариантны ко времени (чис- ло обнаруженных дефектов, общая трудоемкость работ и др.); предсказывающие/объясняющие. Значения предсказывающих (прогнозирующих метрик) могут быть получены заранее (например, оцениваемая интенсивность отказов). Значения объясняющих метрик появляются пост-фактум (реальная интенсивность отка- зов). По отношению к виду объекта измерения (работающая программа или совокупность документов) меры и соответствующие метрики подразделяются на внешние, внутренние и метрики использования ПС. Внешние метрики используют меры работающего на компьютере программного продукта, полученные в результате измерения его поведения в ходе тестирования и функционирования. Внешние метрики разрабатываются с целью: • демонстрации качества программного продукта, представленного характеристиками и подхарактеристиками качества, на стадии тестирования и эксплуатации; • использования для подтверждения (валидации) того, что программный продукт удо- влетворяет внешним требованиям к качеству; • предсказания реального эксплуатационного качества; • определения степени, в которой программный продукт будет удовлетворять установ- ленным и предполагаемым требованиям пользователей в ходе реальной эксплуатации. Можно сказать, что совокупность внешних метрик предназначена для оценивания внешнего качества - степени, в которой продукт удовлетворяет установленным (заяв- ленным) и подразумеваемым потребностям при использовании в определенных услови- ях. Разработка внешних метрик основывается на выполнении следующих измерений: • поведения программного продукта при тестировании и функционировании в сочета- нии с другими программными продуктами, аппаратным обеспечением или системой об- работки информации в целом; • поведения пользователя (сценариев использования ПС). Под измерением (оценкой) поведения понимается оценка масштабов возможных по- следствий неадекватного поведения, которые угрожают жизни или здоровью людей, природным ресурсам, могут привести к разрушению данных, несогласованности или не- достоверности информации, потере безопасности, деградации сервиса (услуг), экономи- ческим потерям и др. Примерами внешних метрик для такой характеристики качества как надежность, мо- гут быть среднее время между отказами, число устраненных дефектов при тестировании, интенсивность отказов и др. Внутренние метрики обеспечивают возможность пользователям, разработчикам, те- стировщикам и менеджерам оценивать качество промежуточных и конечных продуктов ПС непосредственно по их свойствам, без выполнения на компьютере. Внутренние метрики разрабатываются таким образом, чтобы они могли: • представлять (отражать) качество не выполняющихся на компьютере промежуточ- ных и конечных программных продуктов по тем характеристикам и подхарактеристикам качества, которые определены в модели качества ПС ; • служить руководством к действию при планировании и улучшении процессов, кото- рые воздействуют на промежуточные и конечные продукты; • использоваться при верификации того, что промежуточные и конечные продукты удовлетворяют требованиям к внутреннему качеству ПС, предусмотренным планами со- вершенствования процессов; • предсказывать внешние метрики качества. Можно сказать, что совокупность внутренних метрик предназначена для оценивания внутреннего качества - множества атрибутов продукта, которое определяет его способ- ность удовлетворять установленным или реальным потребностям при использовании в определенных условиях. Разработка внутренних метрик основывается на выполнении измерений статических атрибутов, которые определены и могут быть оценены по тексту исходного кода, графи- ческому или табличному представлению потоков управления и данных, структур пере- хода состояний или по документам ПС. Примерами внутренних метрик для надежности могут быть число ошибок, найден- ных при инспекции кода, число устраненных дефектов в результате инспекции кода, прогнозируемое число оставшихся ошибок и др. Метрики качества в использовании (метрики эксплуатационного качества) изме- ряют степень, в которой программный продукт, установленный и эксплуатируемый в определенной среде, удовлетворяет потребности пользователей в эффективном, продук- тивном и безопасном решении задач. Метрики качества в использовании помогают оценить не свойства самой ПС, а ви- димые результаты ее эксплуатации - эксплуатационное качество. Очевидно, что для правильного измерения эксплуатационного качества важно учи- тывать контекст применения ПС – особенности категорий ее пользователей, специфику решаемых ими задач, а также физические и социальные факторы среды их работы. Примерами эксплуатационных метрик качества могут быть точность и полнота до- стижения целей пользователей, производительность труда, ресурсы, потраченные в связи с достижением эффективного решения задач, мнение пользователей относительно свойств ПС и др. Внутренние, внешние и эксплуатационные метрики качества взаимосвязаны. Достижение эксплуатационного качества зависит от удовлетворения критериев внешнего качества, основанных на внешних мерах и метриках качества, которые, в свою очередь, зависят от удовлетворения соответствующих критериев внутреннего качества, основанных на внутренних мерах и метриках, связанных с внешними. Обычно требования пользователей к качеству специфицируются с помощью внеш- них метрик и эксплуатационных метрик качества, а внутренние метрики выбираются та- ким образом, чтобы они могли использоваться для предсказания значений внешних мет- рик. Построить строгую теоретическую модель, устанавливающую взаимосвязь внешних и внутренних метрик, сложно, поэтому, как правило, строится гипотетическая модель, взаимосвязь метрик в которой моделируется статистически в ходе использования метрик. 3.4. Модели качества программных систем Модель качества программной системы представляет множество взаимосвязан- ных характеристик, образующих базис для спецификации требований к качеству и оце- нивания качества. Как эталон при решении вопросов, связанных с качеством, характеризуемым внут- ренними и внешними атрибутами ПС, стандарт ISO/IEC 9126-1 предлагает двухуровне- вую иерархическую модель (Рис. 1) Рис. 1. Обобщенная модель качества Эта модель качества может использоваться для: В соответствии с моделью качества, предложенной в стандарте ISO/IEC 9126-1, свойства (или атрибуты) ПС, характеризующие ее качество, укладываются в шесть кате- горий, каждая из которых ассоциируется с одной из характеристик качества, приведен- ных в Таблице 1. Перечень подхарактеристик качества представлен в таблице 2. Таблица 1 Характеристики качества ПС Подхарактеристики качества ПС Таблица 2 Характеристики эксплуатационного качества ПС Таблица 3 Измерения нужны на всех уровнях модели качества, поскольку удовлетворение кри- териев внутреннего качества обычно не достаточно для обеспечения гарантии достиже- ния критериев внешнего качества, а удовлетворение критериев внешнего качества (ис- пользуемых для измерения подхарактеристик) обычно не достаточно для обеспечения гарантии удовлетворения критериев эксплуатационного качества. Например, надежность может быть измерена и оценена внешне, путем наблюдения числа отказов в заданный период времени выполнения в ходе наблюдений за работой ПС, а также «измерена» внутренне, путем проведения инспекции детальных проектных спецификаций и исход- ного кода с целью предсказания уровня устойчивости к аномалиям. Ресурсы для оценивания качества должны распределяться между различными уров- нями (видами) измерения в зависимости от целей оценивания качества, а также особен- ностей продукта и процесса разработки. В представленной модели все множество атрибутов ПС, характеризующих ее каче- ство, образует иерархическую структуру характеристик и подхарактеристик. Наивысший уровень этой структуры состоит из характеристик качества, а самый низкий - из атрибутов качества. Это не в полной мере иерархия, поскольку некото- рые атрибуты могут вносить свой вклад в более чем одну характеристику, также как на одну характеристику качества может влиять больше чем один атрибут ПС. Может быть прослежена также обратная связь в модели. С одной стороны, внешние подхарактеристики качества (такие как функциональная пригодность, точность, отказо- устойчивость или временная эффективность) влияют на наблюдаемое качество в исполь- зовании. С другой стороны, недостаток качества в использовании (например, если поль- зователь не может закончить начатую задачу) может быть прослежен обратно к внешне- му качеству (например, к функциональной пригодности или управляемости) и затем к соответствующим внутренним атрибутам, которые должны быть изменены для устране- ния установленного недостатка. Существует множество моделей качества, большинство которых являются иерархи- ческими по природе. Одна из первых иерархических моделей качества ПС была предложена Мак-Коллом в 1977 году. Наивысший уровень деления в модели отражает три аспекта качества ПС: функциональность, модифицируемость и способность к адаптации и взаимодействию с аппаратным обеспечением. Эти три основные целевые характеристики качества далее подразделяются на 11 факторов качества и затем на 23 критерия качества. Критерии качества представляют собой целевые числовые уровни факторов каче- ства, оцениваемые по шкале от 0 до 10. Для оценивания факторов используются следу- ющие метрики качества : ▪ удобство проверки на соответствие стандартам, ▪ точность управления и вычислений, ▪ степень стандартности интерфейсов, ▪ функциональная полнота, ▪ однородность используемых правил проектирования и документации, ▪ степень стандартности форматов данных, ▪ устойчивость к ошибкам, ▪ эффективность работы, ▪ расширяемость, ▪ широта области потенциального использования, ▪ независимость от аппаратной платформы, ▪ полнота протоколирования ошибок и других событий, ▪ модульность, ▪ удобство работы, ▪ защищенность, ▪ самодокументированность, ▪ простота работы, ▪ независимость от программной платформы, ▪ возможность соотнесения проекта с требованиями, ▪ удобство обучения. Отдельный критерий качества не обязательно связывается только с единственным фактором качества, следовательно, образуется скорее сетевая, чем строго иерархическая структура. В 1978 году Боэм предложил иерархическую модель, подобную по природе модели МакКолла. Начальные разделения по иерархии в двух моделях схожи, хотя проблема установления интерфейса и адаптируемости отнесена не к верхнему, а к промежуточно- му уровню модели. Нижний уровень содержит основополагающие критерии качества. В пределах этих уровней устанавливается в целом 19 критериев качества. Критерии в этой модели не независимы и их взаимодействие друг с другом часто вызывает конфликты. К сожалению, адекватность этих моделей главным образом предполагается исходя из здравого смысла, а не доказывается на основе эмпирических оценок. Тем не менее, эти модели послужили базисом для дальнейшей работы по моделированию качества ПС. В 1987 году Ваттсом была предложена модель, развивающая модель МакКолла, а за ней в 1988 году появилась модель Дьюча и Виллиса . Эта модель описывает 15 пользова- тельских и 27 технических атрибутов, которые могут связываться с факторами качества и критериями качества, соответственно. Наконец, в 1991 году Международная организация по стандартизации (ISO) предло- жила концепцию качества ПС и иерархическую модель качества, содержащую 6 характе- ристик качества: функциональность, надежность, эффективность, удобство применения, сопровождаемость и переносимость (стандарт ISO 9126, 1991 год). Слабость этой модели состоит в том, что не все подхарактеристики оп- ределены численно и таким образом во- прос их применения открыт для различных интерпретаций. Эти недостатки устранены в новой модели ISO/IEC 9126, которая рассматривалась ранее. Существуют трудности в применении иерархических моделей качества. Во-первых, многие из предлагаемых целевых требований к качеству (характеристик качества) было бы естественнее включать в функциональные требования к ПС и не при- бегать для их оценки к методам метрического анализа. Например, характеристика «спо- собность к взаимодействию» может выступать в качестве целевого требования к интер- фейсу ПС, а ее достижение - проверяться путем тестирования. Таким же образом можно поступить с характеристикой «переносимость» и рядом других. Во-вторых, иерархические модели являются статическими по природе, то есть они не описывают, как проецировать метрики от их текущих значений на определенном эта- пе разработки к новым значениям на последующих стадиях проекта, что очень важно, например, для определения риска проекта. Эти модели вообще не дают никаких указаний о том, как использовать метрики и атрибуты ПС для идентификации и классификации риска, управления процессом разра- ботки и т.д. Как альтернативу классическим иерархическим моделям, Джилб предложил модель, которая хотя и базируется на иерархии характеристик и подхарактеристик каче- ства, но имеет важные отличия: • модель локально адаптируема (в масштабе организации); • характеристики ресурсов включены в модель наряду с характеристиками качества; • модель связана с эволюционной моделью процесса разработки. В рамках этой модели Джилб выделил четыре характеристики качества и четыре ха- рактеристики ресурсов, хотя к ним могут быть сделаны дополнения в ходе процесса настройки модели. Предложенные характеристики качества таковы: работоспособность, готовность, адаптируемость и удобство использования, а характеристики ресурсов - вре- мя, деньги, люди и инструменты. Еще одна известная модель качества - конструктивная модель качества (COQUAMO), которая была разработана Китченхем. Эта модель использует некоторые факторы качества из классических моделей Джилба, МакКолла и Боэма и затем помеща- ет их в рамки соответствующих категорий конкретного проекта . Отряд иерархических моделей продолжил пополняться и в последующие годы. Так в 1996 году Дромей предложил гибкую модель, которая позволяет в большей степени учесть особенности разрабатываемой ПС. Для построения модели нужно: 1) выбрать множество атрибутов качества верхнего уровня, которые будут исполь- зовать для оценивания; 2) построить список всех компонентов или модулей системы; 3) идентифицировать определяющие (главные) свойства каждого компонента, ока- зывающие наибольшее влияние на свойства конечного продукта; 4) определить, каким образом каждое свойство отражается на атрибутах качества; 5) оценить правильность модели; 6) установить слабые места и устранить их (возвращаясь в цикле на один из преды- дущих шагов 1 - 5). Модель строится таким образом, чтобы улучшить понимание взаимосвязи между ат- рибутами (характеристиками) и суб-атрибутами (подхарактеристиками) качества и точ- нее определить свойства программного продукта, которые влияют на атрибуты качества. В рамках программы ESPRIT разработан метод и инструмент Squid (Software quality in Development) для управления, оценки и предсказания качества продукта и процесса разработки ПС, который может настраиваться на нужды отдельной организации и бази- роваться на своей собственной базе данных. Squid специфицирует модель качества в терминах характеристик качества, которые уточняются до тех пор, пока не станут непо- средственно измеримыми (атрибутами). Как и в модели по стандарту ISO/IEC 9126-1, ха- рактеристики и атрибуты качества могут быть внутренними и внешними. Пользователю дается возможность определить, каким образом внутренние характеристики влияют на внешние, связывая их в модель данных. Достоинство модели состоит в том, что она учитывает большинство факторов, вли- яющих на качество ПС, помогая избежать конфликтов между различными требованиями к качеству, дает возможность указывать множество мер для функционально различаю- щихся компонентов ПС (вычислительных, интерфейсных, информационных (баз дан- ных)) и устанавливать различные правила выполнения измерений. Своеобразную модель качества COQUALMO (COnstructive QUALity MOdel) недав- но предложил Боэм, продолжая развитие модели COCOMO для определения трудоемко- сти и стоимости разработки ПС. Эта модель ориентирована на достижение целей каче- ства в сочетании с определением затрат на достижение этих целей. Модель позволяет определить «цену ошибки», своевременное устранение которой приводит к повышению качества. В большинстве случаев при разработке моделей приоритетным, с точки зрения участников разработки проекта ПС, является взгляд менеджера проекта и его интересы в управлении риском проекта (по качеству, стоимости и продолжительности). Именно эта точка зрения учтена, например, при разработке модели в SATC (Software Assurance Technology Center) . Предложенная модель поддерживает классификацию рисков и по- следующую полную оценку риска проекта. Она описывает, каким образом проецируются друг на друга метрики на разных стадиях проекта, что дает возможность определять риск различных атрибутов ПС, интересующих менеджера. Стандарт ISO/IEC 9126 включает большое количество мер, однако они не отражают причинно-следственных взаимосвязей, существующих между характеристиками, подха- рактеристиками, измеряемыми атрибутами качества и множеством их прямых и косвен- ных мер. Параллельно с разработкой иерархических моделей проводились исследования спо- собов учета и представления каузальных взаимосвязей в проблематике качества ПС. В 1999 году А.Абраном и Л.Буглионе была предложена модель QEST (Quality Factor + Economic, Social and Technical dimensions) (Рис. 2). Это трехмерная структура- оболочка, которая позволяет одновременно представлять зависимость значений парамет- ров продукта, отражающих три аспекта его измерения (три точки зрения на продукт). Три измерения модели образуют геометрическую фигуру - правильный четырех- гранник (тетраэдр), стороны которого представляют нормализованные значения изме- ренных величин по каждому из измерений, а вершина - нормализованное оптимальное целевое значение для каждого измерения Модель адаптирована авторами для совместно- го представления количественных и не количественных (качественных) мер разрабаты- ваемого программного продукта, интегрированных в единый (интегральный) показатель его качества, полученный экспертным путем на основе опроса всех заинтересованных в нем лиц. Три измерения модели отражают: 1. Экономический аспект (E). Точка зрения менеджеров на стоимость и график раз- работки (поставки) продукта. 2. Социальный аспект (S). Точка зрения пользователей на характеристики эксплуа- тационного качества (качества в использовании) продукта. 3. Технический аспект (T). Точка зрения разработчиков на обеспечение, измерение и оценивание достижения требований к качеству продукта. Вершина (P) тетраэдра описывает максимальный уровень качества продукта (эффек- тивности проекта). Стороны правильного тетраэдра (пирамиды) равны единице. Все три измерения нормализованы на интервале {0,1}. Значения по каждому измерению представляют со- бой взвешенные суммы списка n значений нормализованных коэффициентов, отражаю- щих каждую из трех точек зрения экспертов на продукт (номинальные оценки). Эти зна- чения откладываются на сторонах пирамиды {Qe, Qs, Qt}. Полученные точки соединя- ются линиями. Образуется сечение пирамиды, «отделяющий» лучшие и худшие оценки качества продукта. В ходе выполнения проекта формируются «реальные срезы» эффек- тивности проекта. Рис.2. Модель QEST для оценивания качества ПС в ходе проекта В 2001 году А.Абраном и Н.Кецеси была предложена схема GDQA (Graphical Dynamic Quality Assessment). В этой схеме изначально определяется иерархическая мо- дель качества ПС, включающая декомпозицию артефактов в категории процессов, про- дуктов и ресурсов проекта (вплоть до выделения измеримых свойств). Затем выполняет- ся их приоритезация, «взвешивание» и нормализация для последующего сопоставления. Далее устанавливается взаимосвязь факторов качества, находящихся на разных уровнях, поскольку многие атрибуты качества нижнего уровня могут вносить вклад в несколько характеристик верхнего уровня иерархии. После этого производится отражение атрибу- тов на соответствующие меры и связанные с ними метрики качества ( в данном подходе они называются функциями), а затем определяются входные переменные, значения кото- рых можно установить, анализируя проектные документы, код, отчеты о тестировании и др. Общепризнанным «мерилом» качества ПС служит внутренняя метрика надежности– количество обнаруженных дефектов в рабочих продуктах ПС, а также внешние метри- ки: ◦ ожидаемое количество скрытых дефектов в ПС, ◦ реальное количество выявленных дефектов в ПС, ◦ количество устраненных (откорректированных) дефектов, ◦ плотность дефектов. С этих позиций основные процессы ЖЦ ПС (ПРо) можно ассоциировать с процес- сами внесения дефектов, а процессы проверки (ПРп) – с процессами выявления и устра- нения дефектов в рабочих продуктах ПС (РП) . Для прогнозирования качества конечного программного продукта важно знать, ка- кие факторы, и каким образом влияют на качество на каждой стадии разработки. Одна- ко существует большой уровень неопределенности относительно этого влияния. Потому на практике широко используется интуитивный подход и вероятностные рассуждения, основанные на собственном опыте менеджера проекта. Очевидно, что по мере накопле- ния опыта возникает потребность коррекции суждений. 3.5. Построение метрик и моделей качества Для создания модели качества ПС необходимо: 1. Определить цели измерения и выполнять все последующие действия с учетом факторов, влияющих на качество. 2. Идентифицировать компоненты ПС, качество которых должно моделироваться отдельно. 3. Выделить и классифицировать наиболее существенные, несущие ответственность за качество свойства (атрибуты) для каждого компонента. 4. Сформулировать аксиомы для связывания свойств ПС с характеристиками каче- ства. 5. Определить систему внутренних и внешних метрик качества ПС, адекватную пе- речню характеристик качества и атрибутов ПС. 6. Проверить модель качества. Процесс, выполняемый при разработке собственных или выборе существующих метрик качества ПС, отвечающих целевым требованиям к качеству ПС (или ее компо- нента), включает следующие шаги: Шаг 1. Определение понятий. Определения всех используемых понятий (сущно- стей и измеряемых атрибутов) должны соответствовать указанным в применяемых стан- дартах или приводиться в документе, описывающем принятую модель качества ПС. Нельзя допускать неоднозначности толкования терминов различными категориями лиц, использующих метрики (пользователями, заказчиками, разработчиками). Шаг 2. Определение внутренней структуры (модели) каждой метрики. Значения базовых метрик измеряются непосредственно и модель таких метрик – это наименование соответствующей переменной. Значения сложных метрик представляют собой математические модели, использующие базовые или другие сложные метрики. Предпочтителен прагматический подход к моделированию метрик - метрики должны от- ражать наиболее важные аспекты измеряемого атрибута и не быть слишком сложными. Модели метрик могут быть заимствованы из стандартов, научной литературы, из опыта других организаций и т.д. и должны накапливаться и при необходимости адаптироваться к нуждам конкретных измерений. Шаг 3. Формулирование метода вычисления метрики (критерия оценивания). Модель каждой метрики декомпозируется до уровня метрик-примитивов (базовых метрик) и далее для этих примитивов определяется механизм получения значения (кри- терий оценивания). Пример метрики-примитива со сложным механизмом получения зна- чения – SLOC (число строк исходного кода). Метрики-примитивы и критерии их оценивания образуют первый уровень необхо- димых собираемых данных. Методы определения значений метрик таковы: измерительный. Метод основан на получении информации о свойствах и характери- стиках ПС с использованием измерительных технических и программных средств (раз- мер загрузочного модуля, время выполнения ветви программы и др.); регистрационный. Метод основан на получении информации во время испытаний или при непосредственном использовании ПС по назначению, когда регистрируются и подсчитываются определенные события (моменты времени сбоев, число отказов и др.); расчетный. Метод основан на использовании теоретических и эмпирических зави- симостей на ранних стадиях разработки, а также статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении. Этим методом прогнозируются харак- теристики и подхарактеристики на ранних стадиях разработки (точность, устойчивость, надежность и др.). Расчетный метод используется и для определения фактических значе- ний характеристик по результатам тестирования; экспертный. Метод заключается в определении значений характеристик группой специалистов-экспертов. Применяется в том случае, если задача определения значений не может быть решена иными методами. Для проведения экспертизы устанавливаются контролируемые признаки, включаемые в виде вопросов в аналитические опросные ан- кеты экспертов. Шаг 4. Определение критерия «хорошего» значения метрики. Когда известно, что измерять и как измерять, нужно определить, как интерпретировать результаты изме- рений, и какими должны быть пределы их изменений. Критерием истины во многих слу- чаях служит мнение заказчика и пользователя. Могут также использоваться опублико- ванные сведения о приемлемых значениях тех или иных метрик, полученные в отрасле- вой производственной практике значения и др. Наиболее достоверный источник инфор- мации – собственные исторические данные об измерении схожих проектов. Шаг 5. Документирование метрик. На этом шаге нужно принять решение о фор- мате отчета, о цикле извлечения и регистрации данных (частоте измерений), о механиз- мах учета данных (твердая копия, электронная копия), о порядке их распределения (направления) различным участникам процесса измерения, об ограничениях (определя- ющих готовность метрики к использованию) и др. Шаг 6. Определение дополнительных квалификаторов метрик. Метрика считает- ся хорошо спроектированной, если она является обобщением различных взглядов и уровней измерения и если ее можно применять, например, на уровне класса продуктов, одного продукта или компонентов этого продукта ПС. В качестве дополнительных ква- лификаторов может указываться контекст применения и другие ограничения. Процесс подготовки к использованию метрик качества ПС для выполнения измере- ний включает выполнение следующих шагов, рекомендованных стандартом ISO/IEC 9126-2: Шаг 1. Идентификация собираемых и измеряемых элементов данных. При подготовке к измерению данных нужно: • выполнить их декомпозицию на элементы - количественные описания фактов, ис- пользуемых для вычисления значений метрик; • определить время, частоту и продолжительность сбора значений (мер) соответствую- щих элементов данных; • разработать формы учета и отчета о результатах оценивания, обзора и/или тестирова- ния продуктов. Шаг 2. Идентификация ограничений и контекста использования метрик. Прежде всего, необходимо установить ограничения на использование метрик при те- стировании. Большинство внешних метрик используют измеряемые значения, получен- ные в ходе тестирования. Поэтому на их достоверность влияет тщательность (глубина) тестирования. По аналогии, на достоверность значений внутренних метрик влияет тща- тельность (глубина) применения инспекций и других методов верификации. Нужно устанавливать степень этого влияния. Эффективность проверок (тестирования или вери- фикации) может определяться, например, в таких единицах, как количество «человеко- часов обзоров», потраченных на проверку определенного числа строк исполнительного кода, или «количество выполненных тестов». А уровни их значений, в свою очередь, мо- гут устанавливаться исходя из того, как много пользователей и как часто будут исполь- зовать те или иные компоненты (функции) ПС. Нужно также устанавливать ограничения на степень соответствия полученных ре- зультатов проверок спецификациям исходных требований, поскольку сами специфика- ции могут быть не всегда правильными. Поэтому перед планированием тестирования на соответствие спецификациям необходимо выполнять их верификацию. Для правильного применения метрик помимо ограничений необходимо также уста- новить контексты их использования. Без указания контекста, описывающего ситуацию и условия, в которых будут собираться данные, и применяться метрики, меры могут ин- терпретироваться не адекватно. Например, такие метрики, как «время на освоение» или «время на выполнение операции» существенно зависят от опыта оператора. Поэтому, наряду с указанием значения метрики нужно указывать условия (контекст), в которых значение получено. Могут быть полезны и другие виды информации: • виды процессов, действий и задач, в ходе выполнения которых собираются данные; • время, продолжительность сбора данных (применения метрик); • персонал, участвующий в сборе данных (применении метрик); • среда тестирования ПС и ее отличия от среды эксплуатации; • условия и виды тестирования; • пользовательские профили (категория, опыт и др.); • сведения о видах процедур сбора данных (автоматизированные, ручные, вопросники и др.); • уровень проверки правильности данных, что важно для оценки степени точности дан- ных (самопроверка, инспекция и др.). Шаг 3. Идентификация свойств метрик. Точность и корректность оценивания ка- чества зависит от свойств, которыми обладает каждая метрика, участвующая в оценива- нии. Свойства метрик соответствуют требованиям к измерениям, предъявляемым стан- дартом ISO/IEC 14598-1 , и требованиям к оцениванию, предъявляемым ISO/IEC 14598- 5. Наличие необходимых свойств должно проверяться. Стандарт ISO/IEC 9126-2 определяет следующие свойства метрик: надежность (степень свободы от случайных ошибок оценщика); показательность (наглядность); готовность к использованию (документальные свидетельства возможности исполь- зовать метрику); экономичность (документальные свидетельства оправданности затрат на примене- ние метрики); корректность (объективность, беспристрастность, точность отражения мнения оценщика); значимость результатов (предоставление значимых результатов измерения поведе- ния ПC или характеристик ее качества). Шаг 4. Идентификация метода визуализации и интерпретации. Существует множество методов и инструментов, которые могут быть использованы для визуализа- ции и анализа результатов измерений и должны быть идентифицированы при подготовке к измерениям, например: ◦ гистограммы и диаграммы Парето (для определения частоты появления собы- тий); ◦ графики «время – значение» (для предсказания изменений (тренда)); ◦ графики «метрика X - метрика Y» (для выполнения корреляционного анализа); Шаг 5. Идентификация метода демонстрации правильности метрик. Нужно идентифицировать методы, которые будут применяться для демонстрации правильности выбранных метрик, например: демонстрация коррелируемости. Объяснение отклонения значений характеристик отклонением значений соответствующих метрик; демонстрация трассируемости. Подтверждение того, что изменение значений ха- рактеристик качества сопровождается изменением значений метрик (в одном и том же направлении); демонстрация согласованности. Подтверждение того, что если значения характери- стик качества продуктов 1, 2, …, n связаны отношением Q1>Q2>…>Qn, то и значения соответствующих метрик связаны отношением M(Q1)>M(Q2)> …>M(Qn); демонстрация предсказуемости. Подтверждение того, что погрешность предсказа- ния характеристики качества с помощью метрики будет допустимой; демонстрация дифференцирующих способностей. Подтверждение того, что приме- нение метрики позволит отличать компоненты ПС с приемлемыми значениями характе- ристик качества от компонентов с неприемлемыми значениями характеристик. Тема 4 ПРИМЕНЕНИЕ МЕТРИК И МОДЕЛЕЙ КАЧЕСТВА 4.1. Спецификация требований к качеству Как уже отмечалось, для идентификации согласованных требований к качеству важ- но выбрать подходящие внутренние и внешние метрики качества и определить ожидае- мые диапазоны значений (адекватные критерии оценки качества), что позволит детали- зировать характеристики и подхарактеристики качества, требуемые моделью качества ПС. Выбираемые внутренние и внешние метрики должны быть попарно связанными, что позволит определить модель дальнейшего улучшения качества в ходе разработки ПС. Каждая внутренняя метрика должна соответствовать улучшаемому атрибуту ПС, а внешняя - определять степень достижения улучшений. Для построения модели и определения требований к качеству можно использовать целеориентированный подход, который создает концептуальный базис для определения множества целей и их преобразования в перечень конкретных вопросов, которые приме- няются для спецификации мер и метрик, пригодных для получения информации, необ- ходимой для ответа на вопросы. Можно привести следующий пример его применения для определения целей качества: Цели (Goals) G1: Повысить надежность программного продукта Вопросы (Questions): 1. Внешние вопросы, касающиеся того, как проверить достижение цели в ходе те- стирования или эксплуатации. Q1.1: как долго продукт работает без отказа? Q1.2: как часто обнаруживаются ошибочные входные данные и предотвращается отказ? 2. Внутренние вопросы, касающиеся того, как проверить достижимость цели каче- ства в ходе разработки. Q1.3: как много ошибок обнаруживается при проведении инспекции? Q1.4: какие типы ошибок наиболее часты? Метрики (Metrics): 1. Внешние метрики (External Metrics). EM1: среднее время между отказами. EM2: коэффициент обнаружения ошибок ввода. 2. Внутренние метрики (Internal Metrics). IM1: плотность дефектов, обнаруженных при инспекции. IM2: число входов, для которых реализована функция обнаружения ошибочных данных. Множество требований к качеству ПС могут вступать в конфликты, которые долж- ны разрешаться на ранних стадиях разработки. Для выявления и устранения такого рода конфликтов Дьютч и Виллис предложили использовать «матрицу конфликтов». Фраг- мент такой матрицы, используемой для обозначения конфликтующих характеристик и подхарактеристик качества, представлен на Рис.3. Положительное воздействие одной характеристики на другую отмечается в матрице символом «+», а отрицательное - символом «-». Одно из ключевых свойств матрицы конфликтов - необязательная симметрия взаимосвязей конфликтующих характеристик. Например, если в качестве приоритетного требования к качеству пользователем выбрана надежность, - ее обеспечение может нанести урон рациональности (эффективности по времени и ресурсам), хотя обратное отрицательное влияние (рациональности на надеж- ность) может отсутствовать. Может быть и другое представление матрицы конфликтов требований. Например, в методологии Quality Function Deployment (QFD) («развертывание» функции качества) предлагается идентифицировать и разрешать конфликты с использованием треугольной матрицы, символизирующей «крышу» так называемого «дома качества». При этом пред- полагается, что конфликтующие взаимосвязи полностью симметричны. Рис. 3.. Фрагмент матрицы конфликтов характеристик качества Оценивание и предсказание характеристик ПС на ранних стадиях ЖЦ – два наибо- лее полезных аспекта использования метрик. Предсказания могут выполняться с использованием байесовских сетей, регрессион- ного анализа или корреляционного анализа. Если нужно предсказать значение в будущем определенной характеристики (атрибу- та), используя текущее значение этой характеристики (атрибута), - применяется регрес- сионный анализ множества данных, наблюдаемых в определенный период времени. Так можно, например, по значениям среднего времени между отказами ПС при тестировании определить среднее время между ее отказами при эксплуатации. Если нужно определять будущие значения характеристики (атрибута), используя текущие измеренные значения другого атрибута, т. е. определять внешнюю меру по внутренней мере, непосредственно не связанной с данной внешней мерой, строятся корреляционные зависимости и выпол- няется корреляционный анализ. Например, можно использовать значения сложности мо- дулей, полученные при кодировании, для предсказания трудоемкости внесения измене- ний и тестирования при сопровождении. Если нужно оценить текущие значения атрибута, которые не могут быть непосред- ственно измерены, или есть какая-либо другая мера, имеющая строгую корреляционную зависимость с целевой мерой, - также полезен корреляционный анализ. Например, по- скольку количество оставшихся ошибок в программном продукте невозможно измерить, • его можно оценить, зная количество обнаруженных ошибок и тенденции в процессе обнаружения. Существуют и другие аспекты применения метрик: оценка качества на промежуточных этапах разработки ПС. Для управления каче- ством полезно использовать метрики промежуточных продуктов в определенные мо- менты выполнения процессов разработки и сопровождения ПС, а также оценки эффек- тивности процессов ЖЦ ПС, особенно если требования к качеству продуктов этих про- цессов заранее установлены путем указания ожидаемых измеряемых значений; трассирование эффективности проекта ПС. Для управления проектом ПС полезно применять метрики, предназначенные для оценки ключевых характеристик промежуточ- ных продуктов проекта в определенные моменты разработки. В этих случаях меры могут интерпретироваться с точки зрения управления для принятия адекватных решений; идентификация, наблюдение и предупреждение риска. Это особенно важно для кри- тических программных систем, характеристики и подхарактеристики качества, а также атрибуты которых, идентифицируются как факторы риска. В этих случаях меры могут интерпретироваться с точки зрения заказчика или конечного пользователя; оценивание характеристик ПС при ее приобретении. Полезно применять метрики для оценивания продуктов ПС при их приобретении в случае наличия альтернатив. Это должны быть метрики, отражающие взгляд пользователя на модель качества при прие- мочных испытаниях ПС – кандидатов; идентификация расхождений между требуемым и достигнутым уровнем качества. С одной стороны, можно идентифицировать расхождения между внутренними требова- ниями к качеству и качеством, достигнутым до начала тестирования, а с другой, - меж- ду внешними требованиями к качеству и качеством, достигнутым в процессе тестирова- ния. До начала тестирования внутренние метрики служат в качестве индикаторов внеш- него качества, а затем, в ходе тестирования, внешние метрики применяются для пред- ставления реально достигнутого уровня качества; анализ проблем с качеством. Метрики могут использоваться для отождествления источника наиболее вероятных проблем с каждой из подхарактеристик качества. Перио- дическое выполнение такого рода анализа в процессе разработки позволяет контролиро- вать факт появления проблем, частоту их появления и принятие решений по проблемам; идентификация компонентов ПС, предрасположенных к появлению проблем. Мет- рики можно использовать отдельно для каждого компонента ПС, выполняя идентифика- цию «проблемных» компонентов путем построения распределений значений метрик и корреляционных зависимостей, анализ которых позволяет установить отклонения значе- ний от ожидаемых, выход за границы диапазонов или превышение пороговых значений. Для извлечения максимальной пользы от применения анализа метрик ПС должна быть создана система сбора и хранения данных о качестве продуктов на уровне органи- зации – репозиторий наблюдаемых и вычисляемых результатов внешних и внутренних измерений. Это поможет накапливать опыт и повышать точность анализа метрик. 4.2. Парадигма «встраивания» качества в программной инженерии В 60-годы в Японии была предложена методология обеспечения качества при созда- нии промышленной продукции, получившая название методологии «развертывания» ка- чества (QFD, от Quality Function Deployment). Позже она была адаптирована к производ- ству программной продукции. Методология QFD ориентирована на последовательную трансляцию пользовательских требований к создаваемому продукту в технические тре- бования на всех стадиях его разработки и производства. Основная цель QFD состоит в преодолении трех основных недостатков, свойствен- ных традиционным подходам к разработке: пренебрежение мнением (голосом) заказчика, потеря информации и несогласованность требований ввиду их реализации различными исполнителями с использованием различных методов. Фактически QFD изменила пара- дигму производства качественной промышленной продукции: традиционная идея повы- шения качества за счет контроля создаваемой продукции была заменена идеей производ- ства бездефектной продукции за счет встраивания элементов обеспечения качества в процессы производства. QFD, используя серию матриц, декомпозирует спецификации продукта или описания проблем до уровня определения предписаний конкретных дей- ствий. Эти предписания определяют минимальный уровень усилий, которые необходимо потратить для удовлетворения требований заказчика. QFD кладет в основу бригадный подход к работе и помогает производственным бригадам систематически достигать со- гласия по вопросам: «что делать?», «каким образом лучше делать?», «в каком порядке делать?», «какие ресурсы использовать?». QFD предлагает также четкую технологию проведения совместных обсуждений и решения проблем всеми заинтересованными сто- ронами. Самая распространенная матрица, используемая QFD, - это «Дом Качества» (Рис.4). Символический Дом Качества содержит следующие компоненты: целевое утверждение. Первый шаг процесса QFD состоит в достижении консенсуса относительно общей цели потребителя (заказчика) продукта и его поставщика (разработ- чика). Целевое утверждение обычно представляется в форме вопроса и определяет, чего нужно попытаться достичь. Хорошо сформулированная цель позволяет бригаде (команде проекта) сосредоточиться на пользовательских требованиях, представленных в виде еди- ной задачи; голос заказчика (потребителя). После того, как сформулировано пробное целевое утверждение, может быть проведено совещание для проверки полноты учета (охвата) мнения заказчика. Мнение заказчика выражается в виде перечня конкретных требований с указанием желательных атрибутов и достоинств будущего продукта. Эти требования определяют все те блоки «ЧТО», которые должны быть созданы. QFD предлагает метод учета Голоса Заказчика путем идентификации индивидуальных характеристик продукта, услуги или проблемы. В совещании должны принимать участие группа QFD, представи- тели заказчика и руководства поставщика, а также представители заинтересованных подразделений (например, службы маркетинга). Каждый блок «ЧТО» должен представ- лять единственное требование; рейтинги важности. QFD предлагает систематизированный метод определения сте- пени важности требований заказчика. Рейтинги важности служат и как факторы взвеши- вания, и как множители к другим значениям в матрице, позволяя делать определенные статистические заключения. Шкалы рейтингов важности и методы опроса участников голосования могут быть различными, использующими числовые значения или символь- ные обозначения (для удобства участников голосования из разных стран), но во всех случаях, чем выше рейтинговое значение, тем больше уровень важности; конкурентная оценка заказчика. На этом шаге процесса QFD оценивается степень восприятия продукта заказчиком по сравнению с другими заказчиками-конкурентами. В качестве базы для сравнения используются данные, полученные от различных заказчиков и представленные в графическом виде. Это дает возможность оценить, насколько хоро- шо конкуренты воспринимают требования, выдвинутые заказчиком, и помогает: • убедиться в том, что список требований важен для сообщества пользователей; • учесть дополнительные требования заказчиков; • установить достоинства и недостатки продукта; • определить слабые места продуктов, используемых конкурентами. Рис. 4. Матрица «Дом Качества» голос поставщика (разработчика). На этом шаге процесса QFD рассматриваются все вопросы, касающиеся блока «КАК», то есть выясняются способы достижения требо- ваний, образующих блок «ЧТО». В блоке «КАК» указываются необходимые процессы, средства и методы. Акцент переносится с идентификации проблемы на ее решение. Про- цесс поиска решений представляет собой совещание с использованием приемов мозгово- го штурма; адресные (локальные) цели. После того как составлен перечень возможных решений в блоке «КАК», необходимо установить наилучшее из них. Адресные цели используются для того, чтобы помочь определить, квантифицируемы ли предложения в блоке «КАК», то есть, можно ли их оценить количественно. Адресные цели указывают, каким образом предложенное решение может способствовать повышению или снижению чего-либо. Для представления адресных целей используют символьные обозначения (например, стрелки «вверх» или «вниз») либо числовые значения. Если цель не может быть оценена количественно, она должна быть удалена из списка; корреляционная матрица. Эта матрица символизирует собой крышу Дома Качества (Рис.5). Она показывает положительные и отрицательные связи между решениями в бло- ке «КАК». Определяя, какие решения сочетаются друг с другом и где могут возникнуть конфликты, корреляционная матрица помогает идентифицировать, какие ресурсы могут использоваться сразу для нескольких целей. Она указывает также, куда необходимо направить дополнительные усилия или применительно к чему провести дополнительные исследования. Корреляционная матрица строится после того, как все решения «КАК» внесены в матрицу QFD и идентифицированы адресные цели. Проводится попарное сравнение решений, и присваиваются указанные выше обозначения. Положительная связь указывает, что решения дополняют друг друга, а отрицательная - что решения от- рицательно сказываются друг на друге и необходимо разрешение конфликта. Рис. 5. Проверка совместимости принятых решений Корреляционная матрица использует следующую символику: « ++ » - для указания очень хорошего взаимодействия; « + » - для указания положительной связи; « - » - для указания отрицательной связи; « хх » - для указания очень плохого взаимодействия (конфликта). конкурентная оценка технических решений. Эта оценка подобна конкурентной оценке заказчика, но касается технических деталей продукта или услуг, а не требований заказчика. В результате оценки определяются целевые значения - количественные меры для каждого решения из блока «КАК» (на основе отраслевых, ведомственных и других стандартов). При выборе базы для оценок сравниваются решения конкурентов- производителей продуктов и определяется тот уровень технических решений в продукте, который обеспечит его конкурентоспособность на рынке; вероятностные коэффициенты. Служат для взвешивания каждого решения по ве- роятности его успеха. Низкий коэффициент вероятности может указывать на то, что оце- ниваемое техническое решение не будет конкурентоспособным. Это значит, что должны быть применены или разработаны новые технологии, методы и приемы. Для оценивания обычно используются числовые шкалы. Чем выше значение по шкале - тем выше веро- ятность правильности выбранного решения; матрица взаимосвязи. Это центральная матрица в Доме Качества. Используется для анализа того, насколько каждое решение из блока «КАК» удовлетворяет каждое требо- вание из блока «ЧТО». Если устанавливается связь между элементами «КАК» и «ЧТО» - это означает, что решение удовлетворяет определенному требованию или устраняет определенную проблему. Если на вопрос, «может ли решение помочь в достижении тре- бования?», оценщики получают ответ «нет» -в соответствующей позиции матрицы про- ставляется «0». Если ответ – «да», связь далее должна быть категоризирована как «силь- ная», «средняя» или «слабая» с указанием численных значений. Обработка выполняется, начиная с левого столбца матрицы. Переход к следующему столбцу «КАК» производит- ся только после завершения обработки данного столбца. Для вычисления оценки в каж- дой ячейке матрицы рейтинг важности умножается на число, указанное в ячейке для со- ответствующего требования; абсолютная и относительная оценка. Абсолютная оценка представляет собой сум- му взвешенных значений связи для каждого решения из блока «КАК». Относительная оценка - это ранг. Абсолютные оценки вычисляются путем суммирования оценок в мат- рице связей по каждому столбцу решений из блока «КАК» и отражают важность каждого решения по отношению к требованиям. Тема 5 МОДЕЛЬ КАЧЕСТВА SQFD 5.1. Методология QFD для программных систем В последнее десятилетие методология QFD, изначально разработанная для промыш- ленного производства, была перенесена в среду разработки программного обеспечения систем и получила название SQFD (Software Quality Function Deployment) – «развертыва- ние» качества в программном обеспечении. Сейчас она с успехом применяется фирмами DEC, AT&T, Hewlett-Packard, IBM и Texas Instruments при разработке программных си- стем различных классов. SQFD концентрирует внимание на повышении качества процесса разработки про- граммных систем путем реализации технологий повышения качества в ходе определения исходных требований в ЖЦ разработки. SQFD адаптируется к любой существующей ме- тодологии программной инженерии, применяемой для выявления и количественного обоснования критических требований заказчика. Ее применение приводит к повышению производительности труда аналитиков и программистов, сокращению количества изме- нений, вносимых в проект, снижению числа ошибок, распространяющихся с одной ста- дии ЖЦ на другую, и т.д. Создаваемые на ее основе системы качества требуют меньшего сопровождения и позволяют экономить на этом денежные средства. SQFD адаптирует к условиям разработки ПС наиболее часто используемую матрицу QFD - Дом Качества. В этой модели присутствуют такие компоненты: требования пользователя. Извлекаемые при анализе проблемной области пользова- тельские требования (к которым относятся требования конечных пользователей, мене- джеров, разработчиков системы и др.) фиксируются слева по оси y. Представляют собой простые утверждения в терминологии пользователя. Сопровождаются подробными определениями, образующими словарь SQFD; технические спецификации продукта. Пользовательские требования преобразуются в технические, измеримые спецификации требований к программному продукту и фик- сируются над осью x. Одному пользовательскому требованию может соответствовать не- сколько технических спецификаций; корреляционная матрица. Пользователям предлагается идентифицировать уровень коррелируемости между различными пользовательскими требованиями и техническими спецификациями продукта (сильная, средняя, слабая корреляция) и заполнить корреля- ционную матрицу. При этом должны быть учтены мнения всех категорий пользователей; приоритеты требований пользователя. На основе пользовательских данных вы- страиваются приоритеты установленных требований и перечисляются справа по оси y. В ходе определения приоритетов может использоваться дополнительная информация о конкурирующих продуктах; приоритеты технических спецификаций продукта. Приоритеты технических спе- цификаций определяются путем суммирования произведений приоритетов пользователь- ских требований и корреляционных значений и фиксируются под осью x. Веса получен- ной строки приоритетов технических спецификаций затем обычно преобразуются в про- центное представление суммарных весов строки приоритетов. Могут использоваться до- полнительные данные об адресных (целевых) мерах технических спецификаций с учетом оценок стоимости, сложности и графика работ; конечный продукт. Конечный продукт процесса SQFD будет, как минимум, вклю- чать измеримые технические спецификации ПС, указатели их важности в процентном соотношении и адресные (частные) меры. Методология SQFD (как и QFD) имеет как достоинства, так и недостатки. Методо- логия переносит акцент в разработке на начальные стадии, что позволяет сосредоточить- ся на тщательном планировании и снизить изменяемость требований. Она обеспечивает «встраивание» качества в процесс проектирования, что приводит к предупреждению распространения дефектов на более поздние стадии ЖЦ, а это, в свою очередь, сокраща- ет продолжительность и стоимость проекта, повышает производительность труда и каче- ство конечного продукта. В числе недостатков SQFD - существенная стоимость и слож- ность методологии. Для успешного применения она требует полной поддержки со сто- роны руководства и автоматизации процессов принятия решений. 5.2. Задачи обеспечения гарантии качества Существует две категории объектов обеспечения гарантии качества и связанных с ними задач: рабочие продукты и процессы ЖЦ. Гарантируя качество рабочих продуктов нужно убедиться в том, что: ▪ все планы, требуемые по условиям договора, надлежащим образом документиру- ются, согласовываются с договором, взаимно непротиворечивы и выполнимы; ▪ рабочие продукты и связанная с ними документация согласуются с условиями до- говора и отвечают требованиям планов; ▪ предназначенные для поставки продукты полностью удовлетворяют предъявляе- мым к ним требованиям и приемлемы для заказчика (потребителя). Гарантируя качество процессов нужно убедиться в том, что: ▪ все процессы ЖЦ ПС, используемые в рамках проекта, согласуются с договором и следуют планам; ▪ применяемые приемы программной инженерии, среда разработки, среда тестиро- вания и среда применения ПС согласуются с договором; ▪ требования договора с головным исполнителем доводятся до соисполнителей (при их наличии) и что создаваемые соисполнителями рабочие продукты удовлетворя- ют требованиям договора с головным исполнителем; ▪ заказчик и другие заинтересованные стороны обеспечиваются необходимой под- держкой в соответствии с договором, устными договоренностями и планами; ▪ метрики продуктов и процесса и приемы измерения (при наличии процесса изме- рения) соответствуют утвержденным стандартам и процедурам; ▪ назначенный штат исполнителей проекта имеет опыт и знания, необходимые для достижения требований проекта, и получает любую необходимую помощь в обу- чении. Перечень решаемых задач может детализироваться и уточняться в зависимости от исходных требований к ПС, поставленных целей качества и условий среды разработки и применения ПС. На широту спектра задач планирования, управления и контроля каче- ства влияют, в частности, следующие факторы: ▪ состав компонентов ПС (разрабатываемое или приобретаемое программное обес- печение); ▪ необходимость следования специализированным стандартам разработки ПС (например, отраслевым стандартам); ▪ наличие стандартов по качеству и соответствующего исторического опыта; ▪ наличие методов и специальных автоматизированных инструментов (или интегри- рованных сред) разработки и сопровождения ПС, а также оценивания и повышения качества; ▪ обеспечение всех процессов в проекте ресурсами (финансовыми, кадровыми, вре- менными, техническими); ▪ категории пользователей ПС и обеспечение необходимого уровня их подготовки к использованию системы; ▪ сфера применения ПС (уровень необходимой целостности и безопасности систе- мы). Ответственность за формирование перечня задач гарантирования качества ПС и их решение возлагается на независимую группу качества (группу SQA), которая действует в соответствии с утвержденным планом обеспечения гарантии качества (планом качества). Непредвзятость в работе группы качества (на уровне организации или проектов) обеспе- чивается путем предоставления ей ресурсов, полномочий и организационной свободы от лиц, непосредственно ответственных за разработку программного продукта или выпол- нение процесса. Группа качества, работающая в рамках проекта, принимает участие в формировании планов, подборе стандартов, методологий, методов и инструментов, кото- рые должны использоваться в проекте ПС и удовлетворять проектным ограничениям и общей политике организации. Участие группы SQA в этих работах способствует получе- нию гарантий, что разработанные планы, а также стандарты и процедуры (или базовые определения процессов) отвечают нуждам проекта и применяются при проведении обзо- ров и аудиторских проверок в ходе ЖЦ. Нужно отметить, что в зависимости от выбранной модели процессов ЖЦ для кон- кретного проекта, включающей определенное подмножество процессов, действий и за- дач, на группу качества могут возлагаться обязанности по выполнению не только соб- ственно процесса SQA, но и других процессов ЖЦ, в том числе процессов Измерения, V&V, Аудита и Управления решением проблем. В этом случае она совмещает сбор ин- формации о процессе и продуктах с ее расширенным анализом, установлением причин- но-следственных связей в проекте и выработкой рекомендаций для руководства проек- том. В группу качества могут, например, включаться инженер по качеству, инженер по надежности, инженер по безопасности, представители группы измерения и группы те- стирования. При функционировании на уровне организации группа качества осуществляет также обратную связь к базовым процессам ЖЦ организации и контактирует с группой инже- нерии процесса разработки с целью усовершенствования процессов. Кроме того, органи- зацияразработчик может пользоваться услугами органов независимой верификации и ва- лидации (IV&V, от Independent V&V), аудита и сертификации систем качества. Для успешного функционирования группы качества важно обеспечить надлежащий уровень документирования стандартов и процедур, поскольку действия SQA по монито- рингу процессов и оценке продуктов основываются на определенных правилах установ- ления меры соответствия проекта стандартам и регламентированным процедурам. Например, руководство NASA GB A201 выделяет, например, следующие категории стандартов, обеспечивающих нормативную информационную поддержку SQA: стандарты документирования. Определяют форму и содержание документации по пла- нированию и контролю (управлению) процессов, а также документации на продукт, и обеспечивают непротиворечивость документов в проекте; стандарты проектирования. Определяют форму и содержание проекта. Обеспечивают правила и методы для преобразования требований к ПС в проект программного обеспе- чения и для его представления в документации проекта; стандарты кодирования и интерфейсов. Определяют язык, на котором должен быть написан код, и любые ограничения на использование особенностей языка. Указывают принятые структуры языка, соглашения о стиле, правила представления структур данных и интерфейсов в определенной парадигме программирования. Этот список можно дополнить другими категориями стандартов, например: ▪ стандарты спецификации требований; ▪ стандарты сопровождения; ▪ стандарты управления конфигурацией; ▪ стандарты измерения (объема, сложности и других атрибутов ПС); ▪ стандарты оценивания качества; ▪ стандарты оценивания процессов; ▪ стандарты планирования отдельных процессов (в частности, планирования управ- ления проектом, качеством, риском, конфигурацией, безопасностью). Все процессы, выполняемые в ЖЦ проекта, должны иметь документированные определения, а также описания процедур и методов выполнения отдельных действий. Перечень стандартов, применяемых процедур и методов должен определяться при пла- нировании создания ПС и фиксироваться в плане управления проектом (SPMP, от Software Project Management Plan), который, в частности, содержит раздел, касающийся процессов контроля разработки ПС. Результатом осуществления SQA являются отчеты руководству, включающие описание обнаруженных недостатков и рекомендаций по приведению разработки в соответствие со стандартами и/или процедурами. 5.3. План качества Осуществление процесса SQA регламентируется разработанным и документально оформленным, реализуемым и сопровождаемым (а при необходимости и актуализируе- мым) Планом выполнения действий и решения задач по процессу гарантирования каче- ства для ЖЦ проекта (сокращенно, Планом качества или SQAP (от Software Quality As- surance Plan)). План описывает, каким образом организация разработчик гарантирует обеспечение качества ПС. План должен включать следующее: ▪ стандарты, методологии, процедуры и инструменты для выполнения действий по гарантированию качества (или ссылки на них в официальной документации орга- низации); ▪ процедуры для проверки (обзора) договора и условия их координации; ▪ процедуры для идентификации, сбора, накопления, сопровождения и размещения отчетов о качестве; ▪ ресурсы, план-график работ и ответственности за проведение действий по гаранти- рованию качества; ▪ описание отдельных (избранных) действий и задач из других поддерживающих процессов, таких как Верификация, Валидация, Совместный просмотр, Аудит и Управ- ление решением проблем. Хотя многие аспекты качества ПС описываются в различных планах, например, в Плане управления конфигурацией, Плане верификации и валидации, Плане обеспечения безопасности функционирования ПС и др., без единого Плана качества эти отдельные планы могут оказаться взаимно не согласованными, а некоторые аспекты качества ПС упущенными. Масштаб, сфера применения и содержание SQAP должны соответствовать размеру и сложности программной системы и риску, который может возникнуть в связи с отказами системы. План может существовать в виде отдельного документа или быть частью плана обеспечения гарантии качества крупной системы, включающей ПС в качестве подсисте- мы. Он может ссылаться на другие планы в проекте, например, план управления риском, V&V и др. Наряду с другими рабочими продуктами проекта План качества должен находиться в сфере управления конфигурацией и подвергаться проверке со стороны руководства проекта. План обеспечения гарантии качества ПС 1. Введение 1.1. Назначение 1.2. Сфера применения 1.3. Определения и сокращения 1.4. Ссылки 2. Управление 2.1. Организация 2.2. Задачи 2.3. Ответственности 3. Документация 4. Стандарты, процедуры, соглашения и метрики 5. Обзоры и аудиторские проверки 6. Испытания (тестирование) 7. Сообщения о проблемах и корректирующие действия 8. Инструменты, технологии и методологии 9. Контроль кода 10. Контроль носителя 11. Контроль поставщика 12. Сбор, ведение и хранение отчетов (записей) 13. Обучение 14. Управление риском План может быть дополнен другими разделами, обеспечивающими охват требова- ний конкретного проекта ПС. Если проект предполагает разработку нескольких про- граммных продуктов, - может быть создано несколько планов SQAP, отражающих спе- цифику каждого из них. Организация SQA. Описывается структура SQA, основные организационные элементы SQA и связи между ними, характер организационной независимости группы SQA от ор- ганизации-разработчика (группы разработки). Задачи управления SQA. Описываются основные задачи, которые должны решаться при проведении SQA: • определяются границы фрагмента ЖЦ ПС, охватываемого SQA; • перечисляются задачи, выполняемые в рамках SQA • устанавливаются взаимосвязи между задачами SQA и действиями по V&V в контроль- ных точках обзоров проекта. Ответственности SQA. Идентифицируются организационные элементы, отвечающие за решение каждой задачи SQA. Указываются лица, отвечающие за план SQA, а также ли- цо, в целом несущее ответственность за качество ПС. Документация. Составляется перечень документов, находящихся под контролем SQA. Он должен в основном совпадать со списком, представленным в плане управления про- ектом ПС. Определяется, каким образом группа SQA будет проверять адекватность каж- дого документа. Как минимум, перечень контролируемых документов должен включать: спецификацию требований к ПС; описание проекта ПС; план верификации и валидации ПС; отчет о верификации и валидации ПС; документацию пользователя; план управле- ния конфигурацией ПС и др. Стандарты, процедуры, соглашения и метрики. Описываются все стандарты, процеду- ры, соглашения и метрики, которые будут использоваться в процессе разработки, и определяются этапы ЖЦ ПС, к которым они будут применены. Указывается, каким обра- зом будет гарантироваться согласованность с каждым стандартом, процедурой, соглаше- нием и метрикой. Список стандартов, процедур, соглашений и метрик, подлежащих применению на различных этапах ЖЦ, может включать стандарты документирования, кодирования, комментирования, процедуры тестирования, метрики и др. Обзоры и аудиторские проверки. Описываются все виды проверок, проводимых в кон- трольных точках процесса разработки с целью обеспечения гарантии качества. Устанав- ливаются порядок и методы проведения каждого обзора технических аспектов разработ- ки (технического обзора) и аспектов управления разработкой (управленческого обзора), аудиторской проверки работ по проекту. Согласно IEEE Std. 730-1 в минимальном объе- ме перечень проверок должен включать: • обзор требований к ПС; • обзор предварительного проекта2; - обзор детального проекта (критический обзор); • обзор плана верификации и валидации; • функциональную аудиторскую проверку; • физическую аудиторскую проверку; • внутренние аудиторские проверки; • управленческие обзоры; • обзоры плана управления конфигурацией. Фактическое множество проверок определяется совместно руководством проекта и группой SQA. Испытания. Описываются любые необходимые испытания (тестирование) ПС, не включенные в план верификации и валидации. Устанавливается порядок их проведения. Сообщения о проблемах и корректирующие действия. Описывается, каким образом проблемы, выявленные в ходе разработки и непосредственно касающиеся качества про- дукта, будут регистрироваться, отслеживаться и решаться. В частности: ◦ распределяется ответственность за сообщение о проблемах и наблюдение за их решением; ◦ устанавливается ответственность за обеспечение гарантии, что все проблемы, непосредственно касающиеся качества ПС, решены. Инструменты, технологии и методологии. Оговариваются все специальные про- граммные инструменты, технологии и методологии, которые будут использоваться для поддержки действий по SQA, и назначаются ответственные лица за их внедрение и при- менение. Контроль кода. Описывается, как исходный и объектный код будут контролиро- ваться в ходе разработки проекта. Контроль среды. Описываются методы и средства, используемые для идентифика- ции носителя каждого программного продукта и документации, включая хранение, ко- пирование и восстановление. Контроль поставщика. Описываются средства, используемые для обеспечения га- рантии, что программное обеспечение, предоставляемое поставщиком, будет отвечать установленным требованиям проекта. В частности: ◦ определяются методы, применяя которые можно удостовериться, что поставщики получили адекватные и полные требования; ◦ определяются методы, используемые для обеспечения гарантии пригодности для проекта ранее разработанного программного обеспечения; ◦ описываются процедуры, которые должны использоваться для обеспечения гаран- тии, что методы SQA поставщиков согласуются с настоящим планом SQA. Управление риском. Указываются методы и процедуры, применяемые для иденти- фикации, оценки, мониторинга и контроля областей риска, особенно касающихся аспек- тов качества ПС (надежности, безопасности функционирования и др.). Полнота и правильность плана SQA должны проверяться и подтверждаться руко- водством проекта (или организации). 5.4. Формы документов процесса контроля качества Описание процессов в стандарте ISO/IEC 12207 выполнено по единой схеме: ▪ Назначение (Purposes) (цели) процесса; ▪ Результаты (Outcomes) выполнения процесса (продукты, артефакты, существен- ное изменение состояния, достижение определенных целей и требований); ▪ Перечень действий (Activities), составляющих процесс; Описание каждого действия и выполняемых заданий (задач) (Tasks). Описания не содержат каких-либо требований к составу входных и выходных рабочих продуктов (РП) процессов. Однако, для выполнения задач SQA по проверке рабочих продуктов процес- сов, а также для оценивания эффективности процессов и их совершенствования, состав рабочих продуктов должен быть определен. В части 5 стандарта ISO/IEC 15504-5, содержащей пример модели оценивания, сов- местимой с эталонной, все процессы ассоциированы с входными и выходными рабочими продуктами и дано краткое описание этих рабочих продуктов. Рабочие продукты отнесе- ны к следующим категориям: РП уровня организации, РП ведения проекта и вспомога- тельные РП. Описание каждого РП касается его сути (содержания), но не формы пред- ставления. Форма, в которой могут существовать однотипные рабочие продукты в раз- ных проектах, обычно определяется применяемыми методологиями и CASE- инструментами разработки (например, SSADM, CDM Oracle), а также требованиями и рекомендациями специализированных отраслевых стандартов и руководств (например, стандарта Министерства Обороны США MIL Std. 498 «Software Development and Documentation» (Разработка и документирование ПО) или стандарта Министерства Обо- роны Великобритании DEF STAN 0055 «Requirements for Safety Related Software in Defence Equipment» (Требования к ПО обеспечения безопасности военного оборудова- ния). Входными рабочими продуктами для процессов контроля качества являются прак- тически все выходные продукты основных и поддерживающих процессов ЖЦ (докумен- тация проекта, планы и отчеты о выполнении процессов, данные проверок в контроль- ных точках проекта и др.). В ходе SQA проверяется их соответствие стандартам, собирается информация о «ка- честве» процесса программной инженерии (допущенных ошибках и причинах их появ- ления) и контролируются темпы продвижения разработки (выполненные объемы работ, потраченное время, трудоемкость, затраты). По результатам всестороннего анализа полученной информации готовятся выходные рабочие продукты процессов контроля качества – планы проверок, отчеты о состоянии разработки, данные об эффективности процессов ЖЦ, рекомендации для руководителей проекта или организации. Некоторые образцы этих рабочих продуктов уже были указаны (например, план измерения, план качества). 5.5. Ключевые метрики для контроля разработки Ключевыми метриками, применяемыми при решении задач SQA, являются: ▪ метрики трудоемкости и стоимости разработки; ▪ метрики размера и сложности разрабатываемого программного продукта; ▪ метрики ошибок. Трудоемкость и стоимость разработки. Существует немало методов оценивания трудоемкости и стоимости ПС, имеющих как достоинства, так и недостатки (они рас- смотрены в рамках дисциплины «Экономика ИТ-отрасли»). Размер. Основная проблема и препятствие для применения ряда методов определе- ния стоимости состоит в том, что для предсказания усилий на разработку нужно сначала предсказать размер конечной системы в единицах SLOC (число строк исходных ин- струкций кода). Существуют руководства по определению длины кода «готового» про- граммного продукта. Однако, во-первых, они непригодны для прогнозирования, а, во- вторых, длина кода не всегда отражает размер современных программных продуктов (например, продуктов, предназначенных для интенсивной работы с базами данных сред- ствами современных СУБД). Достойную альтернативу измерению SLOC составляет определение размера ПО в условных единицах функциональности (FP, от Functional Points), выполняемое на ранних стадиях ЖЦ исходя из анализа функциональных требо- ваний к программному обеспечению. Методологию анализа показателей функциональ- ного размера (FPA, Function Point Analysis) предложил А.Альбрехт в 1979 году. Сложность. Оценка таких характеристик качества ПС, как надежность или сопро- вождаемость, не может быть выполнена до тех пор, пока не получена хотя бы первая версия кода ПС. Однако еще до завершения разработки системы полезно знать, какие ее компоненты могут оказаться менее надежными, сложнее тестируемыми или хуже сопро- вождаемыми, и принимать это во внимание при распределении ресурсов разработки и тестирования. Многочисленные исследования показали, что хорошим «предсказателем» для этих целей служат метрики сложности . Наиболее известными метриками сложности являют- ся метрики М.Холстеда (1977 год) и метрика «цикломатическое число» Т.МакКейба (1976 года) . М.Холстед определил следующие метрики сложности: размер программы (длина), размер словаря, предсказанный размер (с учетом развития) и объем программы, основы- ваясь на синтаксических элементах программы (операторах и операндах). Он предложил также уравнения для оценки трудоемкости, времени программирования и количества ошибок. Метрики ошибок. Обнаружение и своевременное устранение ошибок – основная задача процессов контроля качества ПС. Между тем не достигнуто согласие по опреде- лению основных понятий в этой области – дефект, ошибка, отказ. Эти понятия по-разному определяются не только в научной литературе по качеству и надежности программного обеспечения, но и в стандартах. Проще всего поступили разработчики стандарта IEEE Std.1044 «Standard Classification for Software Anomalies» (Стандартная классификация аномалий программного обеспечения), которые предпочли использовать единый термин «аномалия» (anomaly) вместо других – error, fault, failure, incident, flaw, problem, gripe, glitch, defect или bug - что для целей этого стандарта оправ- данно. Существуют глубокие причинно-следственные связи между отказами ПС в эксплуа- тации, дефектами в поставляемом программном обеспечении, ошибками разработчика и изъянами в процессах создания ПС. Отказ (failure) - событие перехода ПС из работоспособного состояния в неработо- способное или получения результатов, которые находятся вне области допустимых зна- чений. Отказы ПС могут быть обусловлены как внешними причинами (ошибками эле- ментов среды функционирования, в том числе человека-оператора), так и внутренними причинами - дефектами в ПС. Дефект (defect) в ПС – запись элемента программы (кода) или текста документа (рабочего продукта), использование которой может привести к событию, заключающе- муся в неправильной интерпретации этого элемента компьютером (ошибке (fault) в про- грамме - ошибочному состоянию программы) или человеком (ошибке (error) исполните- ля – заблуждению исполнителя). Дефект всегда является следствием ошибки исполните- ля процесса на любом из этапов разработки. Дефектом могут обладать спецификации требований, проектные документы, тексты кода, эксплуатационная документация и т.д. Выходные рабочие документы одних про- цессов, содержащие не устраненные при проверке дефекты, служат входными докумен- тами для других процессов, а дефекты в них – источником ошибок исполнителей этих процессов. Кроме того, ошибки исполнителей могут являться следствием изъянов в определении процессов (неправильная последовательность действий, неправильно вы- бранный инструмент и др.), способствующих неправильной интерпретации исходной информации человеком и принятию неверных решений, или просто недостаточной про- фессиональной зрелостью. Ошибки исполнителей, в свою очередь, приводят к дефекту в рабочем продукте, и цикл «ошибка (error) – дефект (defect) – ошибка (error)» повторяется. Дефекты в коде, не обнаруженные в результате проверок текста кода, служат источником потенциальных ошибок и отказов ПС. «Сработает» дефект или нет, зависит от того, по какому сценарию будет работать с программой пользователь, и «столкнется» ли обработчик кода с непра- вильным элементом. Тема 6 ИНСТРУМЕНТЫ АНАЛИЗА КАЧЕСТВА 6.1. Применение графических инструментов в инженерии качества Для эффективного выполнения своих функций, необходимо оценить потребности в инструментах, поддерживающих процессы измерения, обеспечения гарантии качества и управления качеством, а также верификации и валидации. Кратко рассмотрим графические инструменты, появившиеся несколько десятилетий назад и испытанные временем. Многие из них имеют японское происхождение, поэтому в литературе по качеству и управлению процессами (а также в Интернет) их можно найти под общим заголовком «японские инструменты» анализа качества. Кроме того, от- давая дань создателям, некоторые инструменты называют их именами, например, карты У.Шухарта (контрольные карты) или диаграмма К.Исикавы (причинно-следственная диаграмма). Инструменты раннего периода уходят корнями в базовую математическую статистику и ориентированы на обработку числовых данных, а относительно новые – предназначены для визуализации логически взаимосвязанной нечисловой информации. Достаточно полный обзор графических инструментов анализа данных содержится в электронном учебнике фирмы StatSoft (на русском языке) , а также в Интернет, напри- мер, на сайтах организаций SkyMark Corporation (www.skymark.com/resources/tools), Clemson University (deming.ces.clemson.edu/pub/ tutorials/qctools/homepg.htm) и др. Далее перечислены лишь самые простые (базовые) инструменты. Расслоение данных. Простейший из инструментов - таблица расслоения данных. Предназначена для классификации данных по нескольким критериям. Пример таблицы расслоения – форма сбора данных о дефектах. Всё множество данных «расслаивается» исходя из двух критериев – «тип дефекта» и «дата обнаружения». Для сопоставления данных по отдельным слоям удобно использовать диаграммы: круговые, точечные, стол- биковые, ленточные и др. Этот вид графических инструментов поддерживается средствами ведения электрон- ных таблиц (например, Excel). Для построения диаграмм используется Мастер диаграмм. Диаграмма выполнения. Диаграмма выполнения (Run Chart) или временной график • удобный инструмент контроля хода выполнения процесса в масштабе времени и выяв- ления закономерностей в наступлении каких-либо контролируемых событий (например, изменения производительности труда в зависимости от дня недели или скорости переда- чи информации по каналам связи в зависимости от времени суток). По оси х на графике – градация времени, а по оси y – градация события (Рис.6). Рис. 6. Вид диаграммы выполнения Диаграммы выполнения могут использоваться, также, для контроля устойчивости процесса и обнаружения вариабельности, вызванной особыми причинами. В этом случае для построения графика должно использоваться не менее 25 данных результатов наблю- дений. Если 8 и более точек на графике оказывается по одну сторону центральной линии графика, параллельной оси х, это свидетельствует о влиянии особой причины на процесс. Если график делает 6 последовательных «скачков» в одном направлении, это указывает на тренд процесса под влиянием особой причины. А если определенный фрагмент гра- фика появляется 8 и более раз – нужно попытаться избавиться от особой причины. Нуж- но отметить, однако, что более мощным инструментом для контроля устойчивости про- цесса являются контрольные карты. Диаграмма рассеяния. Диаграмма рассеяния (Scatter Diagram) используется для проверки гипотез о наличии определенной взаимосвязи между двумя измеряемыми ве- личинами (например, размером модуля и плотностью дефектов, размером ПС и затрата- ми и др.). По оси х указывается шкала измерения для одной величины (независимой пе- ременной), а по оси y – для другой, зависимой переменной (Рис.7) Рис. 7. Вид диаграммы рассеяния Если при возрастании значений по оси x возрастают значения по оси y – существует положительная корреляция. Если при возрастании значения по оси x, значения по оси y убывают – отрицательная корреляция. Чем теснее группируются значения вокруг вооб- ражаемой кривой зависимости величин, – тем строже эта зависимость между величина- ми. Если представить себе кривую зависимости сложно, - возможно зависимость отсут- ствует. Корреляция, однако, не всегда означает, что изменение одной величины влечет за собой изменение другой, поскольку может существовать и третья величина, влияющая на обе исследуемые. Построение диаграмм рассеяния полезно для выяснения, связаны ли величины каким-либо образом. Столбиковая диаграмма. На столбиковой диаграмме (Bar chart) последователь- ность значений представляется в виде столбцов (одному наблюдению соответствует один столбец). Если выбрано несколько переменных, - строится составная диаграмма, где все переменные отображаются одновременно в виде групп столбцов (одна группа для каждо- го наблюдения), что позволяет исследовать распределение данных по группам. Этот вид диаграмм удобен, например, для сравнения двух серий данных - измеренных и ожидае- мых (Рис.8). Два специальных типа столбиковых диаграмм - гистограммы и диаграммы Парето. Гистограмма. Гистограммы (Histogram) создаются путем группирования результа- тов измерений по секциям и последующего подсчета количества «попаданий» измерен- ных значений в каждую секцию. Секции представляют собой непересекающиеся столб- цы одинаковой ширины, в основании которых - равные отрезки действительной прямой, покрывающие область возможных значений измеренных величин (непрерывная шкала). Высота столбца пропорциональна числу попаданий значений в секцию. Рис.8. Пример столбиковой диаграммы Гистограммы могут использоваться для характеристики наблюдаемых значений практически любых атрибутов продукта или процесса (например, размера модулей, вре- мени устранения дефекта, времени между отказами, количества дефектов, найденных при тестировании и др.). Пусть, например, числа в таблице 5.10 – это данные 80 измерений количества вре- мени (в часах), ежедневно затрачиваемого группой сопровождения ПС после ее сдачи в эксплуатацию, полученные менеджером за 16 недель наблюдений. Исследуется измене- ние количества часов потраченного времени по дням одной недели и по неделям. Гистограмма для данных о процессе сопровождения ПС представлена на Рис.9. Высота столбца гистограммы отражает количество элементов наблюдений, которые могут быть отнесены к одной секции. Рис. 9. Пример гистограммы Например, один раз на сопровождение было потрачено от 37 до 38 часов работы персо- нала в день (значение 37,2), два раза – от 38 до 39 часов (значения 38,5 и 38,6) и т.д. Больше всего раз встречались данные в секции 44-45 (12 раз). Диаграмма Парето. Полезность применения диаграмм Парето (Pareto Chart) в инженерии качества состоит в том, что они могут использоваться при анализе процессов для привлечения внимания разработчиков к тем факторам, которые оказывают наиболь- шее общее влияние на разрабатываемую систему, и отсеивания несущественных факто- ров, что позволяет вовремя выбрать правильное направление работы по улучшению про- цессов и продуктов. С помощью этих диаграмм можно, например, найти и графически проиллюстриро- вать ответы на такие вопросы, как «на предупреждении каких ошибок нужно сосредото- чить усилия?» или «какие действия в процессе вносят наибольший вклад в проблему?» и др. Диаграмма Парето представляет собой множество столбцов одинаковой ширины, упорядоченных по убыванию высоты и отображающих, в простейшем случае, счетчики частоты или количества наблюдаемых данных, сгруппированных по определенному кри- терию. При проведении более сложных видов анализа диаграммы Парето могут ранжи- ровать факторы по убыванию оценок экономических последствий их влияния (в стои- мостном выражении). Рис. 10. Диаграмма Парето Диаграммы Парето удобны, также, для сравнения состояний процессов или продук- тов до и после усовершенствований и определения эффективности выполненных дей- ствий по усовершенствованию. Однако, если процессы неустойчивы, сравнение диа- грамм Парето может привести к неправильным выводам, поскольку демонстрируемые различия могут быть обусловлены неконтролируемыми вариациями процессов. Это зна- чит, что диаграммы Парето лучше применять для исследования устойчивых процессов. Контрольные карты. Контрольные карты (Control Chart) используются для ана- лиза стабильности процессов. Карта содержит центральную линию (CL, Central Line), ко- торая представляет среднее значение исследуемой характеристики процесса, и две линии контрольных пределов – верхний контрольный предел (UCL, Upper Control Limit) и ниж- ний контрольный предел (LCL, Lower Control Limit), которые вычисляются по одной из возможных мер вариабельности процесса, например, выборочным средним или диапазо- нам (размахам) значений. Карты для выборочных средних часто называют X-картами и строят для получения ответа на вопрос, «изменяется ли основная тенденция процесса в период наблюдения?». Карты для размахов выборки называют R-картами и строят для получения ответа на во- прос, «не влияют ли на дисперсию наблюдаемых величин какие-либо особые причины при выполнении процесса?». X- и R-карты используются совместно для идентификации точек, в которых процесс выходит из-под контроля. Данные измерений характеристик продукта или процесса группируются в последовательные множества (подгруппы) и ре- зультаты группирования используются для вычисления пределов, по которым проверя- ется стабильность (контролируемость) процесса. Поскольку значения, наносимые на карту, представляют статистические величины, они могут быть любой функцией измеримых свойств продукта или процесса. Эти значе- ния определяются путем измерения таких атрибутов, как размер группы разработчиков, продолжительность работы между контрольными точками в ЖЦ или событиями, время, потраченное разработчиками на решение задачи, производительность, текучка кадров, число модулей, имеющих дефекты, число обнаруженных дефектов на 1000 модулей и т.д. Рис.11. Примеры X-карты и R-карты Причинно-следственная диаграмма. Причинно-следственная диаграмма (C&E, Cause and Effect diagram) используется для того, чтобы установить множество возмож- ных причин появления одной изучаемой проблемы. Другие названия этого графического инструмента - диаграмма Исикавы, «рыбья кость» (fish-bone), диаграмма анализа перво- причин (root cause analysis). Наиболее эффективно применяется в условиях коллективной работы над проблемой в режиме мозгового штурма. Пример диаграммы показан на Рис. 12. Основная линия диаграммы (хребет рыбы) отображает проблему (или характеристи- ку, которую нужно улучшить или проконтролировать) и имеет обозначение на правом конце. Ответвления от основной линии (главные кости, отходящие от хребта) диаграммы размещаются под углом к ней и соответствуют главным причинам (или категориям при- чин), непосредственно связанным с проблемой (для наглядности категории указаны в блоках на основной линии диаграммы). Обычно выделяют 3 – 6 категорий причин. Далее каждое ответвление вновь интерпретируется как основная линия – представитель про- блемы более низкого, второго уровня рассмотрения, и уже относительно этой линии производится ветвление причин. Рис. 12. Пример C&E диаграммы для процесса сопровождения системы Практически полезная глубина ветвления – 4-5 уровней проблем. Таким образом, C&E диаграмма используется для представления всех обнаруживаемых потенциальных или реальных причин, детализируемых и упорядочиваемых по уровням важности. Она помогает установить первопричины существующей или возможной проблемы, иденти- фицировать области риска и ранжировать риски по степени относительной важности. 6.2. Применение методов интеллектуального анализа данных Конец XX века отметился появлением и бурным развитием технологии интеллекту- ального анализа данных (ИАД) или добычи данных (DM, Data Mining), обусловленным необходимостью аналитической обработки сверхбольших объемов информации, накап- ливаемой в современных хранилищах данных. Элементы этой технологии находят при- менение и в инженерии качества ПС. Процесс добычи данных в инженерии качества заключается в извлечении ранее неиз- вестной и потенциально полезной информации из множества разрозненных (сырых) ис- торических данных измерений с целью выявления скрытых закономерностей и принятия обоснованных решений относительно контроля качества программных продуктов и про- цесса разработки. Особенность анализируемых данных состоит в том, что они могут представлять ре- зультаты измерений, выполненных в различных организациях с применением разных метрик (отвечающих целям этих организаций) и структурированных таким образом, что к ним сложно непосредственно применить автоматизированные или полу автоматизиро- ванные методы извлечения знаний без предварительной обработки. Суррогатные наборы данных могут содержать лишние или несущественные данные (шумы), массивы с про- пущенными данными и др. Поэтому перед применением к ним алгоритмов DM данные из различных источников должны быть просеяны, интегрированы и согласованы. Процесса добычи данных включает 4 шага: Шаг 1. Выбор типов данных, для которых будет применяться алгоритм извлечения знаний, идентификация расположения данных, получение к ним доступа и транспорти- ровка в одно централизованное хранилище – репозиторий - для последующего примене- ния. Шаг 2. Предварительная обработка данных, которая заключается в просеивании данных, форматировании, преобразовании типов, нормализации, выявлении неопреде- ленных или отсутствующих значений, а также, «порождении» новых атрибутов (как, например, атрибут «серьезность дефекта», который может быть порожден для сущности «дефект» как функция от «времени обнаружения», «времени локализации» и «времени устранения» дефекта). Шаг 3. Применение алгоритма добычи данных – извлечение интересной и потенци- ально полезной информации путем применения моделей и методов выявления знаний. Предварительно обработанные данные могут использоваться, например, для: 1. разработки точной классификационной модели предсказания количества дефектов в программных модулях (сама модель будет представлять собой новую информацию); 2. автоматического построения диаграмм, отражающих интересные ассоциации между характеристиками проекта и профилями ошибок (новая информация будет полу- чена в результате последующего исследования диаграмм); 3. получения целостной картины проективных характеристик и профилей ошибок с помощью инструментов визуализации данных (новая информация будет извлечена в ре- зультате интерактивного исследования визуальных образов данных). Эти примеры представляют основные направления добычи данных – построение моделей, автоматическое исследование образцов (pattern extraction) и визуальное иссле- дование данных (visual data exploration). Шаг 4. Интерпретация (ассимиляция) извлеченной информации – оценивание надежности и эффективности разработанных моделей или определение экспертом в дан- ной проблемной области степени новизны и полезности новой информации. В поиске интересной информации шаги процесса добычи данных могут повторяться неоднократно – аналитик может изменить критерий выбора данных, если посчитает ин- формацию неинтересной; произвести дальнейшую фильтрацию данных, если они не адекватны алгоритму DM; уточнить алгоритм, если в результате его применения обна- руживается слишком мало интересных фактов. Качество извлеченной информации зависит как от правдивости исходных «сырых» данных, так и от методов, используемых в процессе добычи данных, а также способно- стей аналитиков правильно выполнять действия по DM. Выбор методов добычи данных определяется задачами, которые должны решаться с использованием анализа исторических данных в области программной инженерии. Ос- новные задачи классифицируются по следующим категориям: Задачи оценивания и прогнозирования. Исследование атрибутов множества сущно- стей (продуктов, процессов и ресурсов) и использование их значений для квантификации нового исследуемого атрибута. Например, прогнозирование трудоемкости разработки ПС по известным характеристикам проекта. Для решения этих задач могут использо- ваться такие методы DM, как нейронные сети (artificial neural network) или байесовские сети (Bayesian belief network), которые позволяют строить достоверные прогнозы, не уточняя конкретный вид тех зависимостей, на которых прогноз основан. Задачи классификации. Исследование атрибутов заданной сущности и отнесение ее к определенному классу или категории, основываясь на значениях этих атрибутов. Например, отнесение модулей к одному из двух классов – «с большой вероятностью де- фектов» или «с малой вероятностью дефектов». Для решения этих задач могут использо- ваться методы деревьев классификации (classification trees) или оптимального сокраще- ния набора данных (optimal set reduction) (это метод иерархической классификации). Задачи выявления ассоциаций. Поиск ассоциативных групп значений атрибутов, т.е. значений, почти всегда появляющихся вместе. Например, определение того, какие значения двух атрибутов - «опыт» и «подготовка» - для сущности «группа разработки» ассоциируются с характеристикой качества конечного продукта - «надежность». Для решения этих задач может использоваться метод анализа взаимосвязанных со- бытий (анализа структуры транзакции) (в экономике этот метод называют методом ана- лиза структуры покупки (market basket analysis)) или метод анализа значений атрибута (attribute focusing) . По первому методу анализируются «интересные» события и связанные с ними зна- чения атрибутов, а по второму - «интересная» функция распределения значений или «ин- тересные» корреляции между значениями атрибутов. Установленные факты отобража- ются с помощью столбиковых диаграмм, упорядочиваемых по степени «интереса», кото- рый они представляют для экспертов. Вопросы, которые возникают у экспертов в про- цессе анализа диаграмм, и побуждают к извлечению новых знаний. Задачи кластеризации. Отличаются от задач классификации тем, что классы или категории, к которым должны быть отнесены сущности, заранее не заданы и должны быть сформированы в результате определения множества однородных подгрупп данных. Разделение популяции данных на подгруппы производится не в соответствии с какой- либо моделью классификации, а по измерениям расстояния между ними. Если, напри- мер, база данных содержит записи о модулях системы и нужно разделить все множество записей на группы, руководствуясь значениями атрибута «количество модификаций», расстояние будет измеряться разницей между количеством модификаций разных моду- лей. Это простейший вид кластеризации по одному критерию. Задачи визуализации данных. Визуализация данных заключается в отображении многомерных данных на двумерном экране компьютера. Достигается путем связывания записей данных с «визуальными атрибутами», каждый из которых далее ассоциируется с измерением реальных данных. Задачи исследования визуализированных данных. Осмысление сложной информа- ции с помощью интерактивного управления визуализацией многомерных неструктури- рованных наборов данных путем построения сценариев отображения данных в режиме «что если». Тема 7 ТЕСТИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ 7.1. Основные понятия в области тестирования Тестирование – неотъемлемая составляющая процесса программной инженерии, один из методов дальнейшего улучшения качества разработанного программного обес- печения системы посредством выявления оставшихся дефектов, не обнаруженных ранее всеми другими видами проверок. Термин testing (тестирование) широко используется в литературе, но определяется по-разному. Стандарт ANSI/IEEE Std. 610.12:1990 определяет термин testing в самом его широ- ком смысле как любое действие по анализу ПО (включая методы как динамической, так и статической проверки). Г. Майерс определяет этот термин в самом узком смысле: «тестирование процесс выполнения программы (или ее части) с целью обнаружения ошибок… Отладка (debugging) – диагностирование точной природы известных ошибок и их исправление» . Слово testing может быть переведено не только как тестирование, но и как испыта- ния. Однако, понятие «испытания» лучше связывать с завершающими стадиями ЖЦ, на которых выполняется не поиск ошибок, а подтверждение пригодности разработанного программного продукта. По мере развития программной инженерии понимание целей и задач тестирования менялось. Выделяют следующие «исторические» периоды, отражающие прогресс в по- нимании целей тестирования и его места в жизненном цикле ПС: 1) период до 1956 года - ориентация на отладку; 2) период с 1957 по 1978 гг. - ориентация на установление соответствия ПС исход- ным требованиям; 3) период с 1979 по 1982 гг. – ориентация на обнаружение дефектов, оставшихся по- сле реализации; 4) период с 1983 по 1987 гг. – ориентация на анализ, проверку и тестирование с це- лью оценки качества ПС на всех стадиях разработки; 5) период с 1988 по 1995 гг. – интеграция действий по проверке и тестированию в жизненный цикл ПС с целью предотвращения появления дефектов на всех стадиях раз- работки (с охватом всех действий по верификации, валидации и тестированию). С появлением в 1995 году стандарта ISO/IEC 12207, в котором все действия, связан- ные с созданием ПС, представлены в виде отдельных процессов ЖЦ, произошло разде- ление задач верификации, валидации и тестирования по отдельным процессам. Тестиро- вание отнесено к основным процессам, но представлено не одним, а группой процессов. Кроме того, ряд задач тестирования решаются в рамках других процессов разработки, в частности, задачи планирования тестирования распределены по процессам: «Проектиро- вание архитектуры системы», «Анализ требований к ПО», «Проектирование ПО». Авто- номное и интеграционное тестирование ПО выполняются в рамках процессов «Построе- ние ПО» и «Интеграция ПО», поскольку неразрывно с ними связаны. Таким образом, произошла интеграция тестирования с процессами разработки, и се- годня тестирование рассматривается как непрерывная деятельность, выполняемая на протяжении всего процесса разработки. Планирование тестирования должно начинаться на стадии анализа требований, а планы и процедуры тестирования должны систематиче- ски и постоянно уточняться по мере разработки системы. В SWEBOK область знаний «Тестирование ПО» представлена пятью основными разделами (Рис. 13). Терминология тестирования. Тестирование заключается в динамической проверке поведения программы на конечном множестве тестовых данных, специальным образом выбранных из бесконечного входного пространства, на соответствие установленному ожидаемому поведению: динамическое: тестирование всегда предполагает выполнение программы; конечное: даже для небольшой программы теоретически возможно создать такое количество те- стов, для выполнения которых могут понадобиться годы. Рис. 13. Область знаний «Тестирование ПО» Неполнота - одна из основных проблем тестирования, поскольку на практике полное множество тестов можно рассматривать как бесконечное. Количество же тестов, которые могут быть выполнены в ограниченные сроки, конечно. Таким образом, тестирование всегда предполагает некий «компромисс» между ограниченными сроками и потенциаль- но неограниченным количеством тестов. Это приводит к проблемам тестирования, таким как принятие решений об адекватности тестирования, и проблемам управления – оценке затрат (стоимости, времени, персонала) на тестирование; выбранных: с проблемой адекватности тестирования связана проблема выбора огра- ниченного множества тестов. Методы тестирования, в основном, отличаются подходами к выбору множества тестовых данных из входного пространства; ожидаемое поведение: нужно уметь определять, правильны ли полученные резуль- таты выполнения программы, соответствует ли наблюдаемое выполнение ожиданиям пользователя или спецификациям. В литературе по тестированию это называется про- блемой оракула (эталона), для решения которой могут применяться разные подходы (оценка результатов, сравнение с существующим эталоном, согласование с пользовате- лем трактовок понятий «дефект» и «отказ»). Хотя основная цель тестирования – обнаружить дефекты в программной системе и установить ее функциональную пригодность, необходимо рассматривать и другие его цели - тестирование удобства применения, производительности и прочие. Отсюда следу- ет два основных подхода к выполнению тестирования – деструктивный (отрицательное, разрушительное тестирование) и конструктивный (положительное или демонстрацион- ное). При деструктивном подходе тесты выбираются с целью обнаружения дефектов, и эффективным считается тест с высокой вероятностью их обнаружения. При конструктивном подходе тесты выбираются для демонстрации соответствия ха- рактеристик ПС установленным требованиям пользователя или целям качества. Тестирование программной системы на протяжении процесса разработки выполня- ется на нескольких уровнях. Для каждого уровня тестирования определяется категория объектов тестирования (вся система, программные компоненты, модули) и набор прове- ряемых целей (тестируемых характеристик). Цели и объекты совместно определяют критерий выбора множества тестов, как от- носительно его полноты - «какой объем тестирования достаточен для достижения уста- новленной цели?», так и его состава - «какие тесты должны быть выбраны для достиже- ния установленной цели?». Первый вопрос касается выбора критерия покрытия, а второй – критерия выбора типов тестов. На каждом уровне тестирование повторяется многократно, образуя циклы тестиро- вание-исправление-повторное тестирование. В современной программной инженерии все виды действий, связанные с тестирова- нием, начиная с планирования до оценки результатов, должны интегрироваться в четко определенный, документируемый и контролируемый процесс тестирования. Докумен- тирование процесса тестирования облегчает взаимодействие между разработчиками, группой тестирования и руководством проекта, а также позволяет сделать процесс види- мым, повторяемым и измеряемым. К ключевым вопросам тестирования отнесены следующие: 1. Критерии выбора тестов/Критерии адекватности тестов (или правила пре- кращения тестирования). Эти критерии могут применяться как для создания набора те- стов, так и для проверки, насколько выбранные тесты адекватны решаемым задачам (те- стирования), а также помогают определить, когда можно или необходимо прекратить те- стирование. 2. Эффективность тестирования/Цели тестирования. Тестирование – это наблю- дение за поведением программы, выполняемой в целях тестирования с заданными пара- метрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий. 3. Тестирование для выявления дефектов. В тестировании для выявления дефектов применяется деструктивный подход, а успешным считается тест, обнаруживающий де- фект. Этот подход принципиально отличается от другого подхода, когда тесты запуска- ются для демонстрации того, что программа удовлетворяет предъявляемым к ней требо- ваниями и, соответственно, тест считается успешным, если не найдено дефектов. 4. Проблема оракула. «Оракул» в тестировании – это любой агент (человек или про- грамма), оценивающий поведение программы и формирующий заключение о результате теста (тест пройден или нет). Это заключение существенно зависит от трактовки понятия «отказ» и «дефект» в конкретном контексте. 5. Теоретические и практические ограничения тестирования. Ограничения обу- словлены невозможность исчерпывающего тестирования и его экономической нецелесо- образности для конкретных ПС. Тестирование должно проводиться с учетом риска отка- за ПС и основываться на таких стратегиях тестирования, получивших распространение в современных методологиях разработки, как тестирование, основанное на риске (risk- based testing), и управляемое риском тестирование (riskdriven testing). 6. Проблема неосуществимых путей. Неосуществимые пути – это пути потока управления программы, которые не могут быть выполнены ни при каких входных пара- метрах. Это сложнейшая проблема путевого тестирования и особенно его автоматизации. 7. Тестопригодность. Этот термин имеет два разных значения. Первое –это степень легкости описания критериев тестового покрытия для ПС, второе – вероятность, что вы- полнение программы при тестировании приведет к ее отказу, при наличии дефекта. Связь тестирования с другими видами деятельности. Тестирование имеет много общего с процессами верификации и валидации (V&V). Общность процесса тестирова- ния с процессами V&V заключается в единстве состава и структуры планов, рекоменду- емых IEEE Std. 829, а также объектов и применяемых методов. Отличие этих процессов состоит в условиях их применения. Тестирование – основной процесс в ЖЦ, выполняе- мый всегда, для всех объектов ПО системы независимо от ее критичности. Процессы V&V, в современной трактовке стандартов IEEE Std. 1012 и ISO/IEC 12207 – поддержи- вающие процессы, которые могут применяться к выбранным объектам тестирования для проверки планов их тестирования и подтверждения того, что выполненное тестирование адекватно уровню критичности ПС. По отношению к процессу тестирования V&V вы- полняет контрольную функцию и подтверждает соответствие объектов установленным требованиям. Тестирование ПС тесно связано с отладкой и собственно программированием, но охватывает гораздо более широкий круг проблем и участников – программистов, тести- ровщиков, аналитиков. 7.2. Виды и уровни тестирования Структурирование процесса тестирования ПС по уровням обычно связывается либо с видами тестируемых объектов (модуль, система или ее части), либо с проверяемыми целями качества ПС (функциональность, безопасность, надежность и др.) на разных ста- диях ее создания и эксплуатации. Традиционно выделяется три уровня тестирования ПО: автономное или модульное (unit testing), интеграционное (integrating testing) и системное (system testing). В стандарте ISO/IEC 12207 прослеживаются четыре уровня тестирования: ▪ модульное (в процессе «Построение (Конструирование) ПО»), ▪ интеграционное (в процессе «Интеграция ПО»), ▪ тестирование ПО (как процесс), ▪ системное (в процессе «Системная интеграция»). Модульное тестирование предполагает проверку функционирования объектов в изоляции друг от друга. Оно обычно выполняется разработчиками с доступом к коду и чередуется с отладкой. Объектами тестирования являются отдельные процедуры (методы и классы при объектном подходе), программные модули и программные компоненты, со- стоящие из тесно связанных модулей. Цели модульного тестирования – обнаружение дефектов в реализации функций объ- ектов и подтверждение соответствия объекта спецификациям проекта (техническому проекту). Наиболее полно вопросы систематического модульного тестирования освеще- ны в стандарте IEEE 1008-87 “Standard for Software Unit Testing” . Интеграционное тестирование предназначено для проверки правильности взаи- модействия между программными объектами, протестированными автономно. Совре- менные систематические стратегии интеграции определяются архитектурой ПС и моде- лью разработки (обычно итерационной с приращениями). Интеграционное тестирование выполняется при каждой сборке новой версии ПС с целью выявления дефектов в интер- фейсах между интегрируемыми компонентами и подтверждения их соответствия проек- ту архитектуры ПС. Тестирование программного обеспечения заключается в проверке функционирова- ния интегрированной версии ПО системы в моделируемой среде. Цели тестирования на этом уровне – выявление дефектов в реализации внешних функций ПО и подтверждение его соответствия спецификации функциональных требований. Выделение уровня си- стемного тестирования обусловлено необходимостью обеспечения и оценки качества сопряжения ПО с другими, в том числе, не программными компонентами современных систем. На этом уровне тестирования производится проверка соответствия ПС целям ка- чества, установленным в требованиях к системе (с акцентом на нефункциональные тре- бования), таким как надежность, устойчивость, производительность, переносимость и др., а также внешним интерфейсам с другими системами, средой, аппаратным обеспече- нием. 7.3. Виды испытаний программной системы Помимо рассмотренных уровней тестирования объектов ПС, существуют виды те- стирования ПС в целом, выполняемые на заключительных стадиях ее разработки и в хо- де эксплуатации. К ним, прежде всего, относятся испытания ПС. Определены следующие виды ис- пытаний - предварительные, приемочные, установочные и эксплуатационные. Предварительные испытания программной системы можно считать наивысшим уровнем ее «формального» тестирования, выполняемого в среде разработки с целью обнаружения возможных оставшихся дефектов и оценки достигнутого уровня качества ПС. «Формальный» означает, что тестирование выполняется строго в соответствии с установленными документированными процедурами и с участием представителей заказ- чика. Испытания осуществляются в два приема – тестирование ПО и тестирование си- стемы. Следовательно, цель предварительных испытаний - обнаружение несоответствия ПС внешним спецификациям функциональных и технических характеристик. Приемочные и все последующие испытания непосредственно не связываются с по- нятием тестирования, ибо их цель - подтвердить соответствие (или несоответствие) системы исходным требованиям пользователя. В соответствии со стандартом ISO/IEC 12207 эти испытания выполняются в рамках разных процессов ЖЦ. Цель приемочных испытаний (приемочного, квалификационного тестирования) – определение степени соответствия разработанной ПС исходным требованиям заказчика (пользователя). Эти испытания проводятся исключительно в контексте требований за- казчика (пользователя) и с его непосредственным участием и, как правило, в среде экс- плуатации. В трактовке стандарта ISO/IEC 12207 приемочное тестирование, как вид те- стирования, не включено в «Процесс тестирования», а выполняется в рамках процессов «Поставка» и «Приемка заказчиком» (потребителем) и связывается с процессом «Вали- дации». Тестирование инсталляции (установочные испытания) выполняется в среде экс- плуатации (в рамках процесса «Инсталляция ПС») и относится к уровню системного те- стирования. Включает тестирование процедур инсталляции ПС с внешних носителей. Иногда под приемочным тестированием (acceptance test) понимают предварительное те- стирование объекта тестирования при его передаче от разработчика группе тестирова- ния, выполняемое с целью определения пригодности объекта для тестирования . Перед окончательным выпуском системы проводится Альфа и Бета тестирование. Для этого система передается небольшой группе пользователей -внутренних (Альфа) или внешних (Бета), которые эксплуатируют систему и информируют разработчика о выяв- ленных проблемах. Обнаруженные отказы и дефекты свидетельствуют о качестве вы- полненного ранее тестирования. Альфа и Бета тестирование подобны эксплуатационным испытаниям, выполняемым на этапе опытной эксплуатации системы. Но, в отличие от них, обычно проводятся для систем, разрабатываемых для широкого круга пользователей, а не для конкретного за- казчика. Эти виды тестирования не регламентируются планом тестирования и непосред- ственно не входят в процесс тестирования. Регрессионное (regression test) и повторное (re-test) тестирование. Эти понятия часто смешиваются, поскольку оба вида тестирования касаются повторного выполнения тестов. Однако они имеют некоторые отличия. Повторное тестирование выполняется на любом уровне тестирования для проверки внесенных изменений, и не регламентируется планом тестирования. Регрессионное тестирование связано с развитием ПС и особенно широко применяется в итерационных моделях разработки (для тестирования новых вер- сий ПС). Оно заключается в повторении подмножества ранее выполненных тестов (для того, чтобы убедиться в том, что то, что ранее работало, еще работает), а также разра- ботке новых тестов для проверки правильности внесенных изменений. В отличие от повторного тестирования, регрессионное тестирование планируется. При его планирова- нии решается проблема отбора минимального набора регрессионных тестов. 7.4. Виды тестирования характеристик программной системы По отношению к проверяемым характеристикам и целям качества любого объекта системы можно выделить следующие виды тестирования. Функциональное тестирование (называемое также тестированием на соответ- ствие или тестирование корректности) направлено на проверку соответствия наблюда- емого поведения системы (или отдельных элементов) спецификациям (внешним и внут- ренним). Выполняется, как правило, в среде разработки по планам, разработанным на основе спецификаций функциональных требований. Цель функционального тестирования состоит в обнаружении несоответствий меж- ду реальным поведением реализованных функций и исходными требованиями, представ- ленными в спецификации функций, и определении полноты функционального покрытия относительно спецификации функций. Выполняется на уровнях модульного тестирова- ния и тестирования ПО в целом. Функциональные тесты могут быть получены по внеш- ним спецификациям функций, проектной информации или прототипу ПО. Тестирование безопасности (Security testing) заключается в проверке возможности несанкционированного доступа к ПС. Выполняется путем моделирования возможных атак внешних пользователей (в том числе других ПС) с целью «взломать» систему защи- ты. Тестирование удобства применения (эргономичности) предназначено для оцени- вания простоты применения и изучения системы конечными пользователями, эффектив- ности ее использования для решения задач пользователя и способности к восстановле- нию при ошибках пользователя. Часто включает также тестирование документации (on- line, справочной службы, подсистемы обучения). Этот вид тестирования требует знания современных стандартов по эргономике, например, ISO 13407:1999 , а также согласован- ных с заказчиком требований к пользовательскому интерфейсу. Применяется в рамках процесса анализа требований (тестирование прототипа), тестирования программных компонентов, реализующих интерфейс, тестирования ПО и приемочных испытаний си- стемы. Тестирование технических характеристик. Это процесс поиска несоответствий программной системы целям качества (целевым требованиям), зафиксированным во внешних спецификациях наряду с описанием ее функций. Исходной посылкой для его выполнения является измеримость и принципиальная достижимость установленных це- левых требований (к надежности, производительности, совместимости, конфигурации и др.). Эти виды тестирования получили названия, соответствующие целям тестирования, и обычно проводятся в рамках тестирования системы в специально моделируемой среде, максимально приближенной к среде эксплуатации, или в среде эксплуатации. Тестирование на надежность. Этот вид тестирование рассматривают как основное средство улучшения надежности, поскольку с ростом количества выявленных и устра- ненных дефектов надежность ПС растет. Тестирование на надежность выполняется на наборах данных, выбранных случайным образом из входного пространства в соответ- ствии с операционным профилем. Все отказы при выполнении тестов регистрируются применительно к интервалам времени между отказами (или моментам времени наступ- ления отказов от начала тестирования). Процесс возникновения отказов рассматривается как случайный (стохастический) процесс, а для количественной оценки достигнутой надежности применяются модели роста надежности. Тестирование производительности (Performance testing). Выполняется для про- верки достижения установленных требований к производительности или для оптимиза- ции производительности. Иногда подразделяется на следующие виды: • нагрузочное тестирование (load testing) - проверка работоспособности ПС при ожида- емых нормальных загрузках; - тестирование на устойчивость (stress testing) - проверка работоспособности в нестан- дартных условиях (при чрезмерных и отсутствующих загрузках); • тестирование объема (volume testing) - проверка внутрипрограммных или системных ограничений, связанных, например, с большими массивами данных, предельными объе- мами БД и другими характеристиками объема. Тестирование конфигурации (Configuration testing). Выполняется для проверки ра- ботоспособности ПС в разных конфигурациях (операционных системах). Сравнительное тестирование (Back-to-back testing). Вид тестирования, при кото- ром один и тот же набор тестов выполняется на двух реализованных версиях, а результа- ты сравниваются. Особенно актуален в итерационных моделях разработки. Тестирование восстановления (Recovery testing). Проводится для проверки проце- дур восстановления системы после отказов. Управляемая тестами разработка (Test-driven development). Подход к разработке, согласно которому тесты модулей создаются до начала их кодирования. Тесты исполня- ют роль некого прототипа модуля и заменителя спецификации требований. Подход при- меняется в экстремальном программировании 7.5. Методы тестирования Методы тестирования различаются подходами к проектированию тестов. Традиционно методы тестирования разделяют на две категории - «черный ящик» (без до- ступа к исходному коду) и «белый» ящик (с доступом к исходному коду) . Подробная классификация методов тестирования, основанная на подходах к проектированию тестов, представлена на Рис. 14. 1. Методы тестирования, основанные на опыте и интуиции. Специализированное тестирование (Ad hoc). Это наиболее распространенный (хо- тя и не считающийся систематическим) подход, при котором тесты разрабатываются ис- ходя из интуиции тестировщика и его опыта в тестировании подобных систем. Эффек- тивность подхода полностью определяется мастерством тестировщика. Подход не требу- ет подробной спецификации функций ПО, но и не обеспечивает оценивания полноты те- стового покрытия. Развитием подхода можно считать «исследовательское тестирование» (exploratory testing), основные принципы которого – совмещение изучения программного продукта с проектированием тестов и их выполнением. Такое тестирование обычно осу- ществляется независимыми тестировщиками применительно к завершенным программ- ным продуктам. 2. Методы, основанные на спецификации (или методы функционального тести- рования). В традиционной классификации их относят к методам «черного ящика». Они при- меняются для тестирования внешних и внутренних функций программы и предполагают наличие спецификации (формальной или не формальной), используемой в качестве эта- лона. Отличаются между собой подходами к выбору тестовых данных из множества вхо- дов (входного пространства) функций. Рис. 14. Классификация методов тестирования К основным методам функционального тестирования относятся: ◦ таблицы решений; ◦ функциональные диаграммы; ◦ эквивалентное разбиение; ◦ анализ граничных значений; ◦ разбиение входного пространства на категории; ◦ тестирование переходов между состояниями; ◦ тестирование по формальным спецификациям. Метод, использующий таблицы решений для проектирования тестов, был предло- жен Дж.Гуденафом и С.Герхартом . Каждая колонка такой таблицы представляет комби- нацию условий, которые могут существенно повлиять на выполнение программы. Эти условия идентифицируются на основе анализа спецификаций. Затем определяется мно- жество их возможных значений, и устанавливаются ограничения относительно их совме- стимости. Таким образом, сокращается количество тестовых предикатов (например, ограничение может говорить о том, что, если условие 1 выполняется, то ни условие 2, ни условие 3 не могут выполняться). Второй метод, предложенный Б.Эльмендорфом и описанный Г.Майерсом, заключа- ется в преобразовании спецификации в функциональные диаграммы. По этому методу вначале идентифицируется каждая отдельная функция, затем определяются все причины, существенно влияющие на ее поведение, и все ответные реакции (следствия). Следующий шаг состоит в построении графа (диаграммы), связывающего комбина- ции причин с ожидаемыми реакциями на них. Далее для каждого следствия, указанного на графе, определяются тестовые наборы путем перебора всех комбинаций причин, по- рождающих это следствие. Хотя строгое соблюдение метода может обеспечить построение эффективных те- стов, он сложен в практическом применении для функционально сложных программ, по- скольку с ростом числа причин усложняется граф причинно-следственных связей, а установление ограничений сопряжено с добавлением новых промежуточных узлов. В методе эквивалентного разбиения множество значений входных анных функции, образующих ее входное пространство, разбивается на набор подмножеств таким обра- зом, что в каждое подмножество попадают значения, эквивалентные друг другу с точки зрения их использования в тестах для обнаружения ошибок. Говорят, что все тесты, ко- торые могут быть построены на основе эквивалентных значений, представляют один «класс эквивалентности», и для тестирования достаточно выбрать только самые эффек- тивные из них. В методе анализа граничных значений, дополняющем предыдущий метод, данные выбираются на границах входной области, поскольку многие отказы происходят из-за дефектов, связанных с обработкой предельных значений входов. Простое и ценное расширение этого метода – тестирование устойчивости, когда те- стовые данные выбираются также и вне области для тестирования отказоустойчивости программы к недопустимым входам. Методы эквивалентного разбиения и анализа граничных значений считаются базо- выми методами функционального тестирования и должны применяться совместно при проектировании набора тестов для каждого уровня тестирования. В развитие этих методов был создан метод, основанный на спецификациях функций, и использующий для построения функциональных тестов разбиение входного про- странства функций на определенные категории (category partition method или CP-метод) . Суть метода заключается в ряде последовательных декомпозиций функции, начиная с исходной функциональной спецификации, и кончая отдельными деталями каждой тести- руемой процедуры, и создании спецификаций тестов на основе выделения категорий ин- формации о параметрах функции и условий ее выполнения. В методе тестирования переходов между состояниями программа (реализующая функцию) представляется в виде модели, отражающей все возможные состояния ее вы- полнения, переходы между этими состояниями, события, вызывающие переходы, и дальнейшие действия по обработке данных, определяемые этими переходами. Описание спецификаций на формальном языке (имеющем точно определенный син- таксис и семантику) позволяет автоматически строить по ним функциональные тесты и в то же время обеспечивает эталон для проверки результатов. Существует целый ряд мето- дов генерации тестов по формальным спецификациям. Все упомянутые методы функционального тестирования относятся к «систематиче- ским» методам в отличие от случайных (стохастических) и статистических методов. При случайном тестировании входные данные для тестов выбираются случайно. В качестве инструмента для генерации входных данных могут применяться датчики слу- чайных чисел. Для интерактивных программ тестировщик использует случайную комби- нацию действий с программой, пытаясь выявить области ее неустойчивого функциони- рования. 3. Методы, основанные на анализе кода (или структурные). В традиционной классификации структурные методы относят к методам «белого ящика». Согласно этим методам структура программы представляется в виде направлен- ного графа, в котором идентифицируются потоки управления или потоки данных. Соот- ветственно, методы делятся на две основные категории: тестирование потока управления (путей) и тестирование потока данных. В методах тестирования потока управления данные из входного пространства выбираются таким образом, чтобы обеспечить максимальное покрытие кода. Основные методы приведены ниже: Тестирование строк. Выбираются данные, обеспечивающие выполнения всех строк (операторов) программы. Этот метод дает самый слабый критерий покрытия, называе- мый «покрытие строк», и приемлем для программ, не содержащих логических условий и циклов. Тестирование ветвлений. Выбираются данные, обеспечивающие выполнение путей, выделяемых в программе с помощью логических условий, принимающих значения Ис- тина и Ложь. Тестирование логических условий. Если ветвления в программе образуются в резуль- тате выполнения сложных логических условий, данные для их тестирования должны вы- бираться таким образом, чтобы проверить все значения логических условий. Этот метод дает наиболее полный критерий покрытия кода программы, который называется крите- рием «логические условия». Опять таки, для удовлетворения критерия покрытия строк было бы достаточно одного теста, а для покрытия ветвлений – двух. Тестирование циклов. Тесты разрабатываются для проверки каждого цикла при гра- ничных значениях переменных цикла и внутри их границ (для тестирования устойчиво- сти циклы проверяются при значениях вне границ). Этот метод дает критерий покрытия, называемый «все циклы». В методе тестирования потока данных тестовые данные выбираются таким обра- зом, чтобы проследить пути каждой переменной в программе от назначения значений до самого последнего использования (для всех переменных). Этот метод требует большого количества тестов, поэтому на практике трассируются только наиболее критичные зна- чения переменных. Особый интерес, например, представляют значения переменных, участвующих в операциях деления (необходимо предотвращать возможность обраще- ния делителя в 0!), условия и циклы, выполнение которых зависит от значений перемен- ных. Метод тестирования потока данных может также применяться для поиска трудно обнаруживаемых ошибок времени выполнения, связанных с использованием памяти. Структурные методы обычно применяются на уровне модульного тестирования программы ее разработчиком и чередуются с отладкой, хотя могут использоваться и в процессах V&V для проверки критических программ. Методы функционального и структурного тестирования должны рассматриваться не как альтернативные, а как взаимодополняющие, поскольку используют разные источни- ки информации для построения тестов и предназначены для выявления разных типов ошибок. 4. Методы направленного поиска ошибок. Эти методы используются для проектирования тестов, специально предназначенных для обнаружения ошибок определенных типов. К основным методам этой категории относятся: ◦ предположение об ошибках (error guessing); ◦ подсев ошибок (error seeding) ; ◦ мутационное тестирование (mutation testing). Согласно методу выдвижения предположений об ошибках на основании «исторической» информации об ошибках, обнаруженных в подобных программах, опыта тестировщика, а также каталогов известных ошибок, составляется список возмож- ных ошибок и ошибочных ситуаций. Одним из «классических» примеров применения метода является проверка деления на 0. В традиционной классификации метод относится к категории методов «черного ящика». Методы подсева ошибок и мутационного тести- рования предназначены для проверки тщательности уже выполненного тестирования. В традиционной классификации они относятся к категории методов «белого ящика». В методе подсева ошибок в код, протестированный на определенном наборе тестов, специально вносится небольшое количество ошибок, а затем программа повторно тести- руется. Если при тестировании обнаруживаются не все внесенные ошибки, набор тестов считается не достаточным. Отношение количества обнаруженных внесенных ошибок к общему количеству внесенных ошибок предполагается примерно равным отношению количества найденных реальных ошибок к общему числу ошибок, содержащихся в про- грамме. Если выявлены все внесенные ошибки, то считается, что, либо набор тестов до- статочен, либо, что эти ошибки было слишком легко найти. При мутационном тестировании создается много копий основной программы, в каждую из которых вносится небольшое изменение, называемое «мутацией», для имита- ции ошибки в операторе или операнде, не отражающееся на синтаксической корректно- сти программы. Каждая копия тестируется на одном и том же наборе тестов. Если в про- цессе тестирования все внесенные изменения обнаружены, программа считается проте- стированной адекватно и корректной (могут быть также обнаружены ранее не выявлен- ные ошибки). Для того чтобы метод был эффективным в обнаружении ошибок, требует- ся большое количество мутантов, что возможно только при автоматической их генера- ции. 5. Методы, основанные на анализе ожидаемого использования. К этой категории отнесено два основных метода: ◦ статистическое тестирование; ◦ тестирование по операционному профилю. При статистическом тестировании входные данные для проектирования тестов выбираются из входного пространства в соответствии с частотой их появления в буду- щих сценариях использования программы. При выполнении тестов фиксируются момен- ты отказов и вычисляются интервалы между отказами MTBF (Mean Time Between Failure), обычно в единицах процессорного времени (CPU) или времени выполнения. По- лученная информация используется для оценки надежности и предсказания момента за- вершения тестирования. Метод применяется на уровне системного тестирования. Для определения частоты использования функций программы, а также моментов отказов, в код вставляются команды-счетчики. Тестирование по операционному профилю применяется в рамках методологии ин- женерии надежности (SRE, от Software Reliability Engineering) и называется методом SRET (от Software Reliability Engineered Testing). Методология SRE охватывает полный цикл разработки программных систем с повышенными требованиями к надежности, а те- стирование SRET (являющееся по сути статистическим) основано на приоритезации вхо- дов не только по частоте, но и с учетом критичности функций, режимов и последствий отказов систем при эксплуатации. К категории методов, основанных на анализе ожидаемого использования, можно от- нести также метод тестирования по сценариям возможного использования, суть кото- рого заключается в идентификации возможных сценариев работы пользователя и разра- ботке по ним сценариев тестирования (test-cases). Этот метод применяется во всех со- временных инструментах автоматизации функционального тестирования программ, имеющих интерфейс пользователя (инструменты Capture-Replay). Он также используется в популярной методологии RUP (Rational Unify Process) , согласно которой сценарии те- стирования формируются на этапе анализа и проектирования по набору «бизнес- сценариев» (use-cases). Обобщением данного метода можно считать тестирование на базе моделей (model- based testing, model-driven testing), применяемое в рамках соответствующего подхода к разработке (model-driven development). Такие известные подходы к тестированию как тестирование, основанное на риске (risk-driven testing, risk-based testing), представляют не методы разработки тестов, а ско- рее стратегии направленного тестирования и минимизации набора тестов. Эти стратегии подобны тестированию по операционному профилю, но проводятся методами система- тического тестирования и учитывают не только частоту использования, но и величину риска отказа ПС. 6. Методы, учитывающие специфику программной системы. Рассмотренные выше методы универсальны и применимы к любым типам ПС. Од- нако они не учитывают характерных особенностей построения систем разного типа, тре- бующих применения специфических подходов к тестированию. К ним относят следующие методы: ◦ тестирование объектно-ориентированных программ; ◦ компонентное тестирование; ◦ тестирование Web-приложений; ◦ тестирование графического интерфейса пользователя; ◦ тестирование протоколов на соответствие; ◦ тестирование систем реального времени; ◦ тестирование критических систем. Особенности типов ПС обусловливают не столько применение специальных мето- дов проектирования тестов, сколько выбор методов и видов тестирования, наиболее под- ходящих для определенных объектов тестирования. 7.6. Анализ результатов тестирования На эффективность тестирования и устранения дефектов оказывает большое влияние степень четкости процесса подготовки и анализа отчетов о проблемах, а также наличие хорошего инструмента для его поддержки. При отсутствии промышленного инструмен- та, группа тестирования может создать свою систему отслеживания проблем, например, с помощью MS Access. Цели системы отслеживания проблем: ◦ отслеживание состояния тестирования и устранения дефектов; ◦ организация взаимодействия между сотрудниками и решение спорных вопросов относительно классификации и приоритетов устранения дефектов; ◦ определение причин дефектов и выявление «узких мест» в процессах разработки и тестирования. С отчетами о проблемах в процессе тестирования работают тестировщики, разра- ботчики, руководитель проекта и группа качества. Поэтому для эффективного решения проблемы важно определить полномочия пользователей системы отслеживания проблем (как исполнителей процесса «Решение проблем»). Процесс решения проблем, обнаруженных при тестировании, может быть представ- лен следующей последовательностью шагов. Шаг 1. Открытие проблемы. При обнаружении проблемы тестировщик составляет отчет о проблеме («открывает проблему») и передает его программисту для анализа. При автоматизированном ведении отчетов тестировщик помещает отчет в базу данных. Шаг 2. Изучение. Программист анализирует отчет и принимает решение (согласен или нет). Если проблема вызвана случайным отказом, связанным, например, со сбоем оборудования, средой тестирования, нарушениями технологии тестирования или непо- ниманием тестировщика - она отклоняется. Если установлено, что проблема связана с дефектом в ПО, программист устанавливает приоритет устранения дефекта. В спорных случаях решение о приоритете устранения принимает руководитель проекта. Шаг 3. Действие. Программист выполняет устранение дефекта и повторное авто- номное тестирование и возвращает отчет с отметкой «Исправлена» тестировщику. При автоматизированном ведении отчетов тестировщик находит отчеты с этой отметкой в ба- зе данных. Шаг 4. Закрытие. Тестировщик выполняет проверку исправлений и закрывает про- блему. Закрыть отчет о проблеме может только тестировщик. При автоматизированном ведении отчетов о проблемах они хранятся в базе данных для последующего анализа, формирования отчетов, а также для накопления исторических данных. Отчеты об откло- ненных дефектах могут удаляться из базы данных (но только тестировщиком!). Шаги 1 - 4 касаются отслеживания каждого отдельного дефекта, но для анализа ре- зультатов и управления процессом тестирования используются обобщенные и классифи- цированные данные о дефектах. Этот анализ и обобщение выполняется менеджером группы тестирования и менеджером проекта. Обобщенные данные используются также группой качества для анализа текущего состояния проекта. Классификация дефектов, обнаруженных при тестировании Существуют разные подходы к классификации дефектов, которые вносятся в ПС и выявляются на разных стадиях ее разработки. Наиболее полная классификация представ- лена в стандарте IEEE Std. 1044:1993 . В нем вместо термина дефект используется тер- мин аномалия для обозначения любых отклонений в ПC, ее спецификациях, документа- ции, а также планах или процедурах, связанных с разработкой или использованием ПC. Наиболее важными аспектами классификации дефекта являются: симп- том;серьезность; приоритет устранения; стадия разработки и источник; тип. Симптом дефекта касается его видимого проявления, наблюдаемого тестировщи- ком при выполнении тестов. Описание симптома необходимо для анализа дефекта разра- ботчиком и определения истинной причины дефекта. Рекомендуемая IEEE Std.1044:1993 классификация симптомов такова: • Аварийное завершение программы • Не ожидаемое поведение программы • "Зависание" программы Проблема ввода ◦ Корректные данные не вводятся ◦ Неправильные данные вводятся ◦ Описание данных отсутствует или неправильно ◦ Параметры не полные или отсутствуют Проблема вывода ◦ Неправильный формат ◦ Неправильные результаты/данные ◦ Вывод не полный или отсутствует ◦ Грамматика/синтаксис ◦ Неудовлетворительная производительность ◦ Ощущение общего отказа продукта ◦ Сообщение об ошибке системы ◦ Другое Для классификации дефектов по серьезности стандарт IEEE Std.1044:1993 рекомендует такую порядковую шкалу: ◦ Критический ◦ Серьезный ◦ Значительный ◦ Незначительный ◦ Не дефект В каждом конкретном случае «серьезность» дефекта зависит от типа системы и должна определяться в контексте последствий дефекта для системы (или для пользовате- ля). 7.7. Критерии завершения тестирования Как известно, наиболее распространенный критерий завершения тестирования – ис- черпано время, выделенное на его проведение. Этот критерий никак не учитывает вы- полненного объема тестирования и риска отказа ПС из-за оставшихся дефектов. Более строгие критерии основываются на количественных измерениях. В подходе, основанном на метриках покрытия, критерии формируются путем вы- числения метрик функционального и структурного покрытия и отражают объем выпол- ненного тестирования. Структурные критерии применяются при автономном тестирова- нии и основаны на методах структурного тестирования, а функциональные - применяют- ся на всех уровнях и основаны на методах функционального тестирования. Согласно подходу, основанному на профиле дефектов, тестирование прекращается, если нет новых и открытых дефектов серьезности. Этот критерий применяется при функциональном и системном тестировании. Согласно подходу, основанному на оценках интенсивности отказов, тестирование продолжается до тех пор, пока не будут достигнуты установленные в требованиях значе- ния метрик надежности (интенсивность отказов и/или среднее время работы без отказа). Критерий применяется на уровне системного тестирования и предполагает статистиче- ское тестирование (по операционному профилю). Поскольку ни один из критериев не гарантирует полноты тестирования, при приня- тии решения о завершении тестирования необходимо использовать комплексные крите- рии. Например, комплексный критерий завершения тестирования для информационных систем: • все запланированные функциональные тесты прошли (Тплан = 100%); • структурное тестирование было выполнено набором тестов, который обеспечил 100% покрытие строк, 80% покрытие логических условий и 100% покрытие вызо- вов процедур; • нет открытых дефектов серьезности 1, 2 и 3 и плотность дефектов ниже, чем 0.5 дефектов на KSLOC; • интенсивность обнаружения отказов не выше 40 новых отказов на 1000 часов те- стирования; • продолжительность непрерывного функционирования ПС без отказа достигает 100 часов. В условиях ограниченных ресурсов на тестирование критерий завершения может быть сформулирован исходя из оценок риска отказа ПС. Он учитывает, какие идентифи- цированные риски устранены путем тестирования, и какова серьезность оставшихся де- фектов. Согласно данному критерию, тестирование может быть завершено, если все из- вестные дефекты серьезности закрыты, новые - не обнаружены, а риск отказа из-за оставшихся дефектов настолько мал, что дальнейшее тестирование экономически не вы- годно.