Содержание
1. Введение
2. Основные определения
3. Процесс разработки программного обеспечения
3.1. Жизненный цикл программного обеспечения
3.2. Модели жизненного цикла программного обеспечения
3.2.1. Каскадная модель
3.2.2. Инкрементная модель
3.2.3. Итерационная модель
3.2.4. Спиральная модель
3.2.5. V-модель жизненного цикла
3.2.6. Модель быстрого прототипирования
3.2.7. Agile-методологии
3.2.7.1 Описание методологии
3.2.7.2 Экстремальное программирование - XP
3.2.7.3 Гибкая разработка - SCRUM
3.2.8. Подгонка жизненного цикла разработки
4. Качество программных продуктов
4.1. Определение качества. Стандарты качества
4.2. Стоимость качества
4.3. Введение в CMMI
4.4. Управление требованиями
5. Тестирование программного обеспечения
5.1. Цели и задачи. Основные определения
5.1.1. Методологии тестирования
5.1.2. Уровни тестирования
5.1.3. Виды тестирования
5.2. Процесс тестирования
5.2.1. Этапы и задачи
5.2.2. Принципы организации тестирования
5.2.3. Планирование тестирования
5.2.4. Автоматизация тестирования
5.2.5. Примеры. Модульное тестирование. Разработка через тестирование
5.3. Дефекты. Причины, описания, отслеживание
5.4. Типы дефектов и статические методы тестирования
5.3.1. Классификация дефектов
5.3.2. Инспекции и сквозные просмотры
5.3.3. Проверка «за столом»
5.5. Техники создания тест-кейсов
5.5.1. Проектирование и исполнение
5.5.2. Методология черного ящика
5.5.3. Методология белого ящика
6. Приложение 1 – Конфигурационное управление – построение «билдов»
7. Приложение 2 – RUP и UML
8. Приложение 3 – Глоссарий
9. Литература
1. Введение
Данное учебно-методическое пособие содержит материал для изучения дисциплины "Управление качеством разработки программного обеспечения". В нем освещены вопросы, связанные с обеспечением и контролем качества программного обеспечения в рамках процесса его разработки. Особое внимание уделено процессу тестирования программных продуктов. В курсе "Управление качеством разработки программного обеспечения" тестирование программного обеспечения рассматривается в аспекте жизненного цикла программного обеспечения. Отображены специфика в подходах к организации, базовым принципам и выполнению тестирования в зависимости от применяемой модели жизненного цикла программного обеспечения и методологии разработки.
В настоящее время существуют различные значения термина “качество”. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software Process, описывает качество как “достижение отличного уровня пригодности к использованию”. Существуют корпоративные стандарты управления качеством. Так, например, компания IBM ввела в оборот “качество, управляемое рыночными потребностями”. Критерий Бэлдриджа (Baldrige) для организационного качества (National Institute of Standards and Technology, “Baldrige National Quality Program”, https://www.quality.nist.gov) использует похожую фразу - “качество, задаваемое потребителем” (“customer-driven quality”), определяя удовлетворение потребителя основным принципом в отношении качества.
Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ISO 9001 как “ степень соответствия присущих характеристик требованиям” как это сформулировано в официальном переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и словарь”. Интересно, что и сама “ степень соответствия ” также выступает в роли ограничения проекта, а в приложении к индустрии программного обеспечения представлена практически во всех областях проектной деятельности – от управления требованиями (“атрибуты качества” как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п.).
В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как количественно выраженный компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах решения задач заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как “cost of quality” – “стоимость качества”). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения в ISO 9001 с учетом достигнутого компромисса между заказчиком и исполнителем (поставщиком) в отношении характеристик качества.
Рассматриваются вопросы качества программного обеспечения, выходящие за рамки отдельных процессов жизненного цикла. Так например, качество программного обеспечения является постоянным объектом внимания программной инженерии и обсуждается во многих областях знаний в сфере информационных технологий, что вполне обосновано, если учесть поистине катастрофический уровень «проваленных» проектов и неудовлетворенность пользователей программных продуктов, ставшая притчей во языцех для программной индустрии. В общем случае, описывается ряд путей достижения качества программного обеспечения. В частности, эта область знаний касается «статических техник», не требующих выполнения (создания) оцениваемых программных систем, в отличие от «динамических техник», рассмотренных в области знаний “Тестирование”.
Другой важный стандарт – CMMI, предоставляет рекомендации по совершенствованию процесса. Требуется упомянуть и ISO 15504 “Information Technology - Software Process Assessment”, известный как SPICE - Software Process Improvement and Capability dEtermination.
Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation, категория “Engineering”). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207.
Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что сертификация по ISO 9001 помогает в достижении старших уровней зрелости по CMMI.
SQA (Software Quality Assurance) концентрируется на процессах. Роль SQA состоит в том, чтобы обеспечить соответствующее планирование процессов, дальнейшее исполнение процессов на основе заданного плана и проведение необходимых измерений процессов с передачей результатов измерений заинтересованным сторонам (организационными структурам и лицам).
Тестирование, в общем случае, представляет собой деятельность, выполняемую для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.
Техники управления качеством разделены на статические (без выполнения кода) и динамические (с выполнением кода). Тестирование входит в состав динамических техник.
Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов, выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия требуемому поведению системы.
Как уже отмечалось ранее, тестирование программного обеспечения тесно связано с программированием (ГОСТ 12207). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию программного обеспечения в SWEBOK.
2. Основные определения
Программа – последовательность формализованных инструкций, предназначенная для исполнения устройством управления вычислительной машины. Инструкции программы записываются при помощи машинного кода или специальных языков программирования.
Программное обеспечение (ПО) - это совокупность всей информации, данных и программ, которые обрабатываются компьютерными системами. На компьютерном жаргоне – часто используется слово «софт» от английского «software»
Системное ПО (system software) - это набор программ, которые управляют компонентами вычислительной системы (ОС, драйвера устройств и т.п.).
Инструментальное ПО (programming software) - программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ (среда разработки, компиляторы, СУБД, текстовые редакторы и т.п.).
Прикладное (специальное) ПО (application software) – программы, предназначенные для выполнения определенных пользовательских задач и расчитанные на непосредственное взаимодействие с пользователем (офисные приложения, бухгалтерские программы, ERP, электронная почта и т.п.).
Программный продукт (ПП) - это программное обеспечение, предназначенное для удовлетворения потребностей пользователей широкого распространения и продажи (записанное на носителях данных; снабженное программной документацией).
Коробочный программный продукт - это программный продукт, предназначенный для неопределенного круга покупателей и поставляемое на условиях "как есть", со стандартными для всех покупателей функциями.
Заказной программный продукт – программный продукт, появление которого обусловлено требованием конкретного заказчика и продажа которого может, по требованию заказчика, сопровождаться проектной доработкой или разработкой функций, дополняющих стандартные (базовые) возможности.
Процесс разработки программного продукта – это структура, согласно которой построена разработка программного обеспечения.
Жизненный цикл программного обеспечения (ПО) - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации (ISO 12207).
Модель жизненного цикла ПП - описание набора фаз (этапов, стадий) проекта по созданию ПО, в которых выполняются отдельные процессы, разбитые на операции и задачи.
Проект – это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Проект представляет собой уникальную (в отличие от операций) деятельность, имеющую начало и конец во времени, направленную на достижение определённого результата (цели ), создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.
Требование – задокументированная уникальная потребность (необходимость) того, что должен делать конкретный продукт или каким он должен быть.
Отладка (Debugging) – деятельность, направленная на установление точной природы известной ошибки, а затем - на исправление этой ошибки. Результаты тестирования являются исходными данными для отладки.
Контроль (Verification) – попытка найти ошибки, выполняя программу в тестовой, или смоделированной, среде.
Испытание (Validation) – попытка найти ошибки, выполняя программу в заданной реальной среде.
3. Процесс разработки программного обеспечения.
Промышленное применение компьютеров и растущий спрос на программы поставили актуальные задачи существенного повышения производительности разработки программного обеспечения, разработки индустриальных методов планирования и проектирования программ, переноса организационно-технических, технико-экономических и социально-психологических приемов, закономерностей и методов из сферы материального производства в сферу применения информационных технологий.
Комплексный подход к процессам разработки, эксплуатации и сопровождения программного обеспечения выдвинул ряд насущных проблем, решение которых исключит «узкие места» в процессе разработки программного обеспечения, уменьшит сроки завершения работ.
Поскольку компьютерная программа практически любого типа становится изделием - продуктом, подход к ее изготовлению во многом должен быть аналогичен подходу к производству промышленной продукции.
Процесс разработки программного продукта – это «организационная структура», согласно которой построена разработка программного обеспечения. Эта структура определяется моделью жизненного цикла ПП.
Основные этапы процесса разработки программного обеспечения:
· Сбор и анализ требований
· Разработка архитектуры
· Кодирование
· Тестирование
· Документирование
· Сопровождение
Жизненный цикл программного обеспечения.
Концепция проекта в области информационных технологий описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ), представляя его как последовательность стадий и выполняемых процессов. Для каждого этапа жизненного цикла определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Жизненный цикл программного обеспечения - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного обеспечения и заканчивается в момент его полного изъятия из эксплуатации.
Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения, но все они содержат общие основополагающие этапы:
· постановка задачи = сбор и анализ требований
· проектирование решения = разработка архитектуры
· реализация = кодирование, тестирование и документирование
· эксплуатация = сопровождение
Жизненный цикл программного обеспечения начинается с того момента, когда пользователь (заказчик), т.е. тот, кто нуждается в продукте для решения задачи, излагает свою проблему, которую он хочет решить с помощью ПП. Это составляет содержание этапа постановки задачи и определения требований.
Определение требований включает описание общего контекста задачи, ожидаемых функций системы и ее ограничений. На данном этапе основную роль играет аналитик, который обладает навыками описания требований в различной форме.
В процессе согласования требований со стороны будущей команды разработчиков в обсуждении участвует менеджер проекта, а также, возможно, архитектор, как действующее лицо, способное оценить технические возможности реализации идеи заказчика.
Принципиально то, что на данном этапе самого проекта еще нет и можно говорить только о предпроектных работах, в которых участвуют представители будущей команды разработки или специалисты, занимающиеся предпроектной подготовкой. Определение требований в фактических проектах не может ограничиваться лишь предпроектными работами. Для большинства прикладных задач требования поступают в течение всего развития проекта.
Постановка задачи является одним из наиболее важных этапов. Она выполняет функции контракта между пользователем и исполнителем. Как и юридически плохо составленный контракт, плохая постановка задачи бесполезна. При хорошей постановке задачи как пользователь, так и команда разработки ясно и недвусмысленно представляют задачу, которую необходимо выполнить, т.е. в этом случае учитываются интересы как пользователя, так и исполнителей. Пользователь может планировать использование еще не созданного программного обеспечения, опираясь на знание того, что оно может. Хорошая постановка задачи служит основой для формирования ее решения.
Постановка задачи (спецификация программы), по существу, означает точное, полное и понятное описание того, что происходит при выполнении конкретной программы. Пользователь обычно смотрит на компьютер, как на черный ящик: для него неважно, как работает компьютер, а важно, что может компьютер из того, что интересует пользователя. При этом основное внимание фокусируется на взаимодействии человека с машиной.
Характеристики Хорошей Постановки Задачи:
Точность, т.е. исключение любой неоднозначности. Не должно возникать вопросов относительно того, каким будет вывод программы при каждом конкретном вводе.
Полнота, т.е. рассмотрение всех вариантов для заданного ввода, включая ошибочный или непредусмотренный ввод, и определение соответствующего вывода.
Ясность, т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи - это единственный контракт между ними.
Часто требование точности, полноты и ясности находятся в противоречии. Так, многие юридические документы трудно понять, потому что они написаны на формальном языке, который позволяет предельно точно сформулировать те или иные положения, исключая любые самые незначительные разночтения.
Например, некоторые вопросы в экзаменационных билетах иногда сформулированы настолько точно, что студент тратит больше времени на то, чтобы понять вопрос, чем на то чтобы на него ответить. Более того, студент вообще может не уловить основной смысл вопроса из-за большого количества деталей. Наилучшая постановка задачи та, при которой достигается баланс всех трех требований.
Разработка проектных решений, отвечающих на вопрос о том, как должна быть реализована система, чтобы она могла удовлетворять специфицированным требованиям, выполняется на этапе проектирования. Поскольку сложность системы в целом может быть очень высока, главной задачей этого этапа является последовательная декомпозиция системы до уровня очевидно реализуемых модулей или процедур. Наиболее активная роль на данном этапе — архитектор, для которого декомпозиция системы есть главная задача в проекте.
На следующем этапе – этапе реализации - кодируется каждый из модулей, выявленных при декомпозиции, программируется на наиболее подходящем для данного приложения языке. Основные действующие лица этапа — руководитель команды и разработчики. Традиционно именно данный этап считали основой проекта в целом, что, не отражает современного взгляда на проект.
Интеграция построенных и используемых модулей в систему является одним из видов работ этапа реализации. Фаза разработки заканчивается этапом тестирования, главными лицами которой являются инженеры по тестированию и этапом документирования, главными лицами которого являются технические писатели.
Фаза эксплуатации и сопровождения включает в себя всю деятельность по обеспечению нормального функционирования программных систем, в том числе фиксирование в скрытых во время исполнения программ ошибок, поиск их причин и исправление, повышение эксплуатационных характеристик системы, адаптацию системы к окружающей среде, а также, при необходимости, и более существенные работы по совершенствованию системы. Все это дает право говорить об эволюции системы.
В связи с этим фаза эксплуатации и сопровождения разбивается на два этапа: собственно сопровождение и развитие. В ряде случаев на данную фазу приходится большая часть средств, расходуемых в процессе жизненного цикла программного обеспечения.