ТСПП - Лекция 1
.pdfУровни тестирования это:
–тестирование отдельных элементов, которое заключается в проверке отдельных, изолированных и независимых частей ПО;
–интеграционное тестирование, которое ориентировано на проверку связей и способов взаимодействия (интерфейсов) компонентов друг с другом, включая компоненты, расположенные на разных архитектурных платформах распределенной среды;
–тестирование системы предназначено для проверки правильности функционирования системы в целом, с обнаружением отказов и дефектов в системе и их устранение. При этом контролируется выполнение сформулированных нефункциональных требований (безопасность, надежность и др.) в системе, правильность задания и выполнения внешних интерфейсов системы со средой окружения и др.
Квидам тестирования относятся:
–функциональное тестирование, которое заключается в проверке соответствия выполнения специфицированных функций;
–регрессионное тестирование – тестирование системы или ее компонентов после внесения в них изменений;
–тестирование эффективности – проверка производительности, пропускной способности, максимального объема данных и системных ограничений в соответствии со спецификациями требований;
–нагрузочное (стресс) тестирование – проверка поведения системы при максимально допустимой нагрузке или при превышении;
–альфа и бета-тестирование – внутреннее и внешнее тестирование системы. Альфа –без плана, бета с планом тестирования;
–тестирование конфигурации – проверка структуры и идентификации системы на различных наборах, а также проверку работы системы в различных конфигурациях.
Квидам тестирования относятся также подходы и методы проверки поведения системы на этапе испытания ПО и приемки в соответствии с требованиями и заданными параметрами относительно состава ПО, количества и типа компьютеров, среды и ОС.
Техники тестирования бывают таких видов:
–«белый (стеклянный) ящик», основанный на задании информации о структуре ПО или системе;
–«черный ящик», основанный на задании тестовых наборов данных для проверки правильности работы компонентов и системы в целом без знания их структуры;
–основанные на спецификациях, анализе граничных значений, таблицах принятия решений, критериев потоков данных, статистики отказов и др.;
11
–основанные на использовании блок–схем, по которым строятся программы и наборы тестов для покрытия всех условий выполнения частей системы и системы в целом;
–на основе обнаруженных дефектов, условий использования, природы и особенностей приложения и др.
Управление тестированием это:
–планирование процесса тестирования (составление планов, тестов, наборов данных) и измерение показателей качества ПО;
–проведение тестирования reuse-компонентов и паттернов, как основных объектов сборки ПО;
–генерация необходимых тестовых сценариев, соответствующих среде выполнения ПО;
–верификация правильности реализации системы и валидация реализованных требований к ПО;
–сбор данных об отказах, ошибках и др. непредвиденных ситуациях при выполнении программного продукта;
–подготовка отчетов по результатам тестирования и оценка характеристик системы.
Стандарт ISO/IEC, ГОСТ 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, а рассматривает тестирование, как необъемлемую часть ЖЦ.
Измерение результатов тестирования. Измерение, как часть планирования и разработки тестов, базируется на размере программ, их структуре и количестве обнаруженных дефектов. Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Документация на тестирование включает, согласно стандарту IEEE 829-98, описание тестовых документов, их связи между собой и с процессом тестирования. Без документации по процессу тестирования, невозможно провести сертификацию продукта и оценку модели СММ1 [22]. После завершения тестирования рассматриваются вопросы стоимости и рисков, связанных с появлением сбоев и недостаточно надежной работой системы. Стоимость тестирования является одним из ограничений, на основе которого принимается решение о прекращении или продолжении тестирования.
Таким образом, данная область знаний SWEBOK представляет разработчику методы проверки правильности ПО: верификация, валидация, тестирование. Определяются типы, уровни и техники тестирования ПО, методы планирования процесса и тестовых наборов данных для прогонки ПО в режиме испытания конкретного модуля или системы в целом, а также методы измерения результатов тестирования.
12
1.5. Сопровождение ПО (Software maintenance)
Сопровождение ПО – совокупность действий по обеспечению работы ПО, а также по внесению изменений в случае обнаружения ошибок в процессе эксплуатации, по адаптации ПО к новой среде функционирования, а также по повышению производительности или других характеристик ПО.
Сопровождение (согласно стандартов ISO/IEC 12207 и ISO/IEC 14764) считается модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта.
Область знаний «Сопровождение ПО» состоит из следующих описаний разделов:
–основные концепции (Basic Concepts),
–процесс сопровождения (Process Maintenance),
–ключевые вопросы сопровождения ПО (key Issue in Software Maintenance) ,
–техники сопровождения (Techniques for Maintenance).
Сопровождение рассматривается с точки зрения удовлетворения требований в данном ПО, корректности его выполнения, процессов обучения и оперативного учета процесса сопровождения.
Основные концепции включают базовые определения и терминологию, подходы к эволюции и сопровождению ПО, а также к оценке стоимости сопровождения и др.
К основным определениям относится ЖЦ ПО (стандарт ISO/IEC 12207) и документация. Эта область трактуется, как процесс выполнения, анализа необходимости модификации, оценки стоимости работ по изменению функций. Рассматриваются проблемы, связанные с увеличением сложности продукта при большом количестве изменений и преодоления этого.
Процесс сопровождения включает: модели процесса сопровождения и планирование деятельности людей, которые проводят запуск ПО, проверку правильности его выполнения и внесения в него изменений.
Процесс сопровождения согласно стандарту ISO/IEC 14764 проводиться путем:
–корректировки, т.е. изменения продукта при реализации обнаруженных ошибок и нереализованных задач;
–адаптации, т.е. настройки продукта к изменившимся условиям эксплуатации или новой среды выполнения данного ПО;
–улучшения, т.е. изменения продукта для повышения производительности или уровня сопровождения;
–проверки ПО для поиска и исправления скрытых ошибок, обнаруженных при эксплуатации системы.
13
Ключевые вопросы сопровождения ПО. Основными из этих вопросов являются управленческие, измерительные и стоимостные.
Сущность управленческих вопросов состоит в контроле ПО в процессе модификации, совершенствовании функций и недопущении снижения производительности системы.
Оценка стоимости затрат на сопровождение зависит от типа ПО, квалификации персонала, платформы и др. Знание этих факторов позволяет не только их сохранить, но и уменьшить.
Вопросы измерения относятся к оценке характеристик системы после ее модификации, например, после тестирования оценка качества полученного ПО.
Эволюция ПО. Известный специалист в области ПО Леман (1970г.) предложил рассматривать сопровождение как эволюционную разработку программных систем, поскольку сданная в эксплуатацию система не всегда является полностью завершенной, ее надо изменять в течение срока эксплуатации. В результате программная система становиться более сложной и плохо управляемой, возникает проблема уменьшения ее сложности.
К техникам эволюции ПО относятся реинженерия, реверсная инженерия и рефакторинг.
Реинженерия – это улучшение возможностей, функций в устаревшем ПО путем его реорганизации и реструктуризации, перепрограммирования или настройка на другую платформу или среду с обеспечением удобства его сопровождения
Реверсная инженерия состоит в восстановлении спецификации (графов вызовов, потоков данных и др.) по полученному коду системы (особенно, когда в нее внесено много изменений) для наблюдения за ней на более высоком уровне. Восстанавливается идентификация программных компонентов и связей между ними для обеспечения перестройки системы к новой форме.
Рефакторинг ориентирован на улучшение структурных характеристик и качественных показателей объектно-ориентированных программ без изменения их поведения. Этот процесс реализуется путем изменения отдельных операций над текстами, интерфейсами, средой программирования и выполнения ПО, а также настройки или внесения изменений в инструментальные средства поддержки ПО. Если сохраняется форма существующей системы при изменении, то рефакторинг – один из вариантов обратной инженерии.
Таким образом: рассмотренные проблемы сопровождения позволяют специалистам узнать весь круг вопросов сопровождения, эволюции и унаследования старых программных систем.
14
1.6. Управление конфигурацией ПО
Управление конфигурацией – дисциплина идентификации компонентов системы, определения функциональных и физических характеристик аппаратного и программного обеспечения для проведения контроля внесения изменений и трассирования конфигурации на протяжении ЖЦ.
Конфигурация системы – состав функций, программных и физических характеристик программ или их комбинаций, аппаратного обеспечения, обозначенные в технической документации системы и реализованные в продукте.
Конфигурация ПО включает набор функциональных и физических характеристик ПО, заданных в технической документации и достигнутых в готовом продукте. Т.е это сочетание разных элементов продукта вместе с заданными процедурами сборки и отвечающие определенному назначению.
Элементы конфигурации – график разработки, проектная документация, исходный и исполняемый код, библиотека компонентов, инструкции по установке системы и др.
Область знаний «Управление конфигурацией ПО» состоит из следующих разделов:
–управление процессом конфигурацией (Management of SMC Process),
–идентификация конфигурации ПО (Software Configuration Identification),
–контроль конфигурации ПО (Software Configuration Control),
–учет статуса конфигурации ПО (Software Configuration Status Accounting),
–аудит конфигурации ПО (Software Configuration Auditing),
–управление релизами (версиями) ПО и доставкой (Software Release Management and Delivery).
Управление процессом конфигурации. Это деятельность по контролю эволюции и целостности продукта при идентификации, контроле изменений и обеспечении отчетности информации, касающейся конфигурации.
Включает:
–систематическое отслеживание вносимых изменений в отдельные составные части конфигурации и проведение аудита изменений и автоматизированного контроля за внесением изменений в конфигурацию системы или ПО;
–поддержка целостности конфигурации, ее аудит и обеспечение внесения изменений в один объект конфигурации, а также в связанный с ним другой объект;
–ревизия конфигурации на предмет проверки разработки необходимых программных или аппаратных элементов и согласованности версии конфигурации
стребованиями;
–трассировка изменений в конфигурацию на этапах сопровождения и эксплуатации ПО.
Идентификация конфигурации ПО проводится путем выбора элемента
15
конфигурации ПО и документирования его функциональных и физических характеристик, а также оформления технической документация на элементы конфигурации ПО.
Контроль конфигурации ПО состоит в проведении работ по координации, утверждению изменений в элементы конфигурации после формальной ее идентификации, а также оценке результатов.
Учет статуса конфигурации ПО проводится в виде комплекса мероприятий для определения уровня изменений в конфигурацию, аудита конфигурации в виде комплекса мероприятий по проверке правильности внесения изменений в конфигурацию ПО. Информация и количественные показатели накапливается в соответствующей БД и используются при управлении конфигурацией, составлении отчетности, оценке качества и выполнении других процессов ЖЦ.
Аудит конфигурации – это деятельность, которая выполняется для оценки продукта и процессов на соответствие стандартам, инструкциям, планам и процедурам.
Аудит определяет степень удовлетворения элемента конфигурации заданным функциональным и физическим характеристикам системы.
Различают функциональный и физический аудит конфигурации, который завершается фиксацией базовой линии продукта.
Управление релизами (версиями) ПО это: отслеживание имеющейся версии элемента конфигурации; сборка компонентов; создание новых версий системы на основе существующей путем внесения изменений в конфигурацию; согласование версии продукта с требованиями и проведенными изменениями на этапах ЖЦ; обеспечение оперативного доступа к информации относительно элементов конфигурации и системы, к которым они относятся. Управление выпуском охватывает идентификацию, упаковку и передачу элементов продукта и документации заказчику.
При этом используются следующие основные понятия.
Базис (baseline) – формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.
Библиотека ПО – контролируемая коллекция объектов ПО и документации, предназначенные для облегчения процесса разработки, использования и сопровождения ПО.
Сборка ПО – объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.
Таким образом, описание данной области показывает, что процесс управления конфигурации является важным процессом идентификации элементов, формирования версии системы и их управления.
16
1.7. Управление инженерией ПО
Управление инженерией ПО (менеджмент) – руководство работами команды разработчиков ПО в процессе выполнения плана проекта, определение критериев и оценка процессов и продуктов проекта с использованием общих методов управления, планирования и контроля работ.
Как любое управление, менеджмент ПО предполагает:
–планирование,
–координацию,
–измерение,
–контроль,
–отчет по процессу управления проектом.
Координацию людских, финансовых и технических ресурсов при реализации задач проекта выполняет менеджер проекта, аналогично тому, как это делается в технических проектах.
В его обязанности входит соблюдение запланированных бюджетных и временных характеристик и ограничений, стандартов и сформулированных требований. Общие вопросы управления проектом содержится в ядре знаний
SMBOK [19] в разделе Management Process Activities, а также в стандарте ISO/IEC 12207 – Software life cycle processes [14], где управление проектом рассматривается как дополнительный и организайионный процесс ЖЦ,
Область знаний «Управление инженерией ПО состоит из следующих разделов:
–организационное управление (Organizational Management),
–управление процессом и проектом (Process/Project Management),
–измерение инженерии ПО (Software Engineering Measurement).
Организационное управление – это планирование и составление графика работ, оценка стоимости работ, подбор и управление персоналом, контроль за выполнением работ согласно принятых стандартов и планов. Главными проблемами организационного управления проектом являются: управление персоналом (обучение, мотивация и др.), коммуникации между сотрудниками и средой (сценарии, встречи, презентации и др.), а также риски (минимизация риска, техники определения риска, выбор решений по их предотвращению и др.).
Для управления проектом создается такая структура коллектива, специалисты которой могут выполнить проект, они распределяются по работам и все вместе реализуют задачи проекта под руководством менеджеру проекта.
Задачам проекта сопоставляется оборудование, средства и исполнители. Проводится распределение обязанностей специалистов и их выполнение с
учетом заданной стоимости и срока разработки проекта.
Процесс управления проектом включает: составление плана проекта, построение графиков работ (сетевых или временных диаграмм) исходя из имеющихся ресурсов, а также распределение персонала по работам с учетом сроков и стоимости их выполнения и др.; анализ финансовой, технической, операционной и социальной политики организации для выбора правильной
17
стратегии выполнения плана; контроль процесса управления планами и продуктами на процессах.
Управление продуктом заключается в уточнении требований и проверки (валидацию) их на соответствие, в просмотре и ревизии требований на соответствие заданным спецификациям качества, а также в проверке (верификации) правильности реализованных функций в отдельных продуктах проекта. Процесс управления проектом базируется на заданных сроках выполнения работ, их начала и окончания.
Результаты планирования отображаются в сетевых диаграммах (PERT –
Program Evaluation and Review Technique, CРM – Сritical Path Method и др.),
предназначенных для отображения полного комплекса работ, времени их выполнения и зависимостей между разными работами.
Сетевая диаграмма PERT является графом, в вершинах которого располагаются работы, а дуги задают взаимные связи между этими работами. Такой граф является наиболее распространенным представлением сети для управления разными видами работ на сегодняшний день.
Другой тип сетевой диаграммы является событийным, когда в ее вершинах указываются события, а работы задаются линиями между двумя узлами– событиями. Ожидаемое время выполнения работы для сетевых диаграмм оценивается с помощью среднего весового значения трех оценок:
оптимистической, пессимистической и ожидаемой – вероятностной. Эти оценки берутся из заданного времени на разработку и заключений экспертов, оценивающих отдельные работы и в комплексе. Есть и другие методы оценок. После составления плана решается вопрос управления и контроля проекта согласно плану, выбранного процесса и сущности проекта. Корректно составленный план обеспечивает выполнение требований и целей проекта. Процесс контроля более всего направлен на внесение изменений в проект, оценку риска и оценка принимающих решений.
Управление рисками является важной проблемой выполнения проекта и представляет собой процесс определения рисков и разработки мероприятий по уменьшению их влияния на ход выполнения проекта.
Риск – вероятность проявления неблагоприятных обстоятельств, которые могут повлиять негативно на реализацию качества проекта и на управление разработкой (например, увольнение сотрудника и отсутствие замены для продолжения работ и др.).
Для управления риском проводится идентификация и анализ риска, оценка критических рисков и планирование непредвиденных ситуаций, касающихся рисков.
Предотвращение риска заключается в выполнении действий, которые снимают риск (например, увеличение времени разработки и др.), уменьшают вероятность появления нового риска при реорганизации проекта, БД или транзакций, а также при выполнении ПО.
Измерение в инженерии ПО проводится для определения отдельных характеристик объектов инженерии (продуктов, процессов и т.п.) и их измерение.
18
Проводится комплекс работ, связанных с выбором метрик для оценки качества процессов и продуктов, а также обстоятельств и зависимостей, влияющих на их измерение.
Кним относятся:
–совершенствование процессов управления проектом;
–оценки временных затрат и стоимости ПО, их регулирование;
–определение категорий рисков и отслеживание факторов для регулярного расчета вероятностей их возникновения;
–проверка заданных в требованиях показателей качества отдельных продуктов проекта и проекта в целом [15].
Проведение разного рода измерений является важным принципом любой инженерной деятельности, а в программном проекте оно положительно влияет на результат выполнения и создания ПО, необходимого заказчику и потребителям. Без измерений в инженерии ПО процесс управления становится неэффективным и превращается в самоцель.
Таким образом, рассмотрение основных принципов формирования команды разработчиков, методов планирования работ и оценки процессов создания ПО и самого продукта позволяет менеджеру коллектива разработчиков проекта сосредоточится на планировании работ, оценках трудозатрат, распределения ресурсов и управления изменениями и рисками.
1.8 Процесс инженерии ПО_
Процесс инженерии ПО включает концепции, инфраструктуру, методы определения и измерения этапов ЖЦ, поиск ошибок и внесение изменений, а также анализ и оценку качества продукта.
Область знаний «Процесс инженерии ПО (Software Engineering Process)» состоит из следующих разделов:
–концепции процесса инженерии ПО (Software Engineering Process Concepts),
–инфраструктура процесса (Process Infrastructure),
–определение процесса (Process Definition),
–оценка процесс (Process Assessments),
–количественный анализ процесса (Qualitative Process Analysis),
–выполнение и изменение процесса.(Process Implementation and Change).
Данная область знаний связана со всеми элементами управления процессами ЖЦ ПО, изменения которых проводятся в связи с их совершенствованием. Цель управления в применении лучших процессов, соответствующих реальной практике выполнения конкретного проекта.
Инфраструктура процесса базируется на основных положениях стандартов IEEE/IEC 12207 и 15504, а также на видах ресурсов (групп разработчиков, технических средств, программных продуктов и др.) и процессе инженерии ПО (групповом или по типу экспериментальной фабрики (Experience Factory– EF), базирующейся на моделях проекта и продукта, моделях качества и риска.
19
Инфраструктура включает уровни управления, отношения в коллективе, инженерные методы организации и интеграции программного продукта. Основной задачей EF является совершенствование ПО после получения опыта и уроков его разработки.
Определение процесса основывается на: типах процессов и моделей (водопадная, спиральная, итерационная и др.); моделях ЖЦ процессов и средств,
стандартах ЖЦ ПО ISO/IEC 12207 и 15504, IEEE std 1074-91 и 1219-92; а также методах и нотациях задания процессов и автоматизированных средствах их поддержки.
Основной целью процесса является повышение качества получаемого продукта, улучшение различных аспектов программной инженерии, автоматизация процессов и др.
К нотациям определения процессов диаграммы потоков данных, диаграммы переходов и состояний. Ряд нотаций используются в рамках RUP. Есть специальные нотации для графического представления бизнес-процессов
(Business Process Management Notation).
Автоматизация заключается в использовании тех или иных диаграмм и нотаций (RUP, MSF, IBM, Rational Rose и др.).
Оценка процесса проводится с использованием соответствующих моделей и методов оценки. Например, оценка потенциальной способности специалиста для выполнения соответствующей работы. SWEBOK обращает внимание на необходимость проведения оценки возможности организации, проводить разработку ПС на основе модели оценки зрелости (СММ [22]) и процессов, согласно которым проводится разработка ПО.
Оценки относятся также и к техническим работам программной инженерии, к управлению персоналом и качеству ПО. Для этого проводится наблюдение за выполнением процесса, сбор информации, моделирование, классификация полученных дефектов, а также статический контроль и оценка процесса.
Качественный анализ процесса состоит в идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования. Рассматривается две техники анализа: обзор данных и сравнение данного процесса с основными положениями стандарта ISO/IEC–12207; сбор данных о качестве процессов; анализ главных причин отказов в функционировании ПО, откат назад от точки возникновения отклонения до точки нормальной работы ПО для выяснения причин изменения процесса.
Выполнение и изменение процесса. Существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе детальных измерений процесса. Оценка совершенствования процессов проводится для установления количественных характеристик процессов и продуктов. После процесса развертывания ПО, выполняются вычисления, после чего проводится инспекция результатов выполнения, анализ и принятие решений, в частности возникновение необходимости изменения процесса, организационной структуры
20