Слайд 1КОМПЬЮТЕРНОЕ МОДЕЛИРОВАНИЕ
ЖИЗНЕННЫЙ ЦИКЛ МОДЕЛИ
КАЧЕСТВО
ТЕСТИРОВАНИЕ
Сосновский Ю.В.
Слайд 2Технологические основы языков программирования высокого уровня
Сложность задач
Технологии программирования
Структурное программирование
Модульное программирование
Объектный
подход
ОО и алгоритмическая декомпозиция. Алгоритмы, классы и объекты.
ОО Анализ
ОО Проектирование
ОО
Программирование
Принципы объектного подхода.
Слайд 3СЛОЖНОСТЬ ЗАДАЧ
Сложные задачи порождают сложные программные системы
Слайд 4КАК БОРОТЬСЯ СО СЛОЖНОСТЬЮ?
Разработка ПО по сути проблем похожа на
производство
Процесс создания ПО имеет много аналогий с производственным процессом
В любом
производстве есть способы преодоления сложности: технологии
Слайд 5ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ
Технология программирования – совокупность методов, приемов и средств для
сокращения стоимости и повышения качества разработки программных систем
Слайд 6ОПРЕДЕЛЕНИЯ
Программный продукт (ПП) - это программное обеспечение, предназначенное для удовлетворения
потребностей пользователей широкого распространения и продажи (записанное на носителях данных
и снабженное программной документацией)
Коробочный программный продукт – это программный продукт, предназначенный для неопределенного круга покупателей и поставляемое на условиях «как есть», со стандартными для всех покупателей функциями
Заказной программный продукт – программный продукт, появление которого обусловлено требованием конкретного заказчика и продажа которого может, по требованию заказчика, сопровождаться проектной доработкой или разработкой функций, дополняющих стандартные
Процесс разработки программного продукта – это структура, согласно которой построена разработка программного обеспечения
Жизненный цикл программного обеспечения (ПО) – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации (ISO 12207)
Слайд 7
Модель жизненного цикла ПП – описание набора фаз (этапов, стадий)
проекта по созданию ПО, в которых выполняются отдельные процессы, разбитые
на операции и задачи
Проект – это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Проект представляет собой уникальную (в отличие от операций) деятельность, имеющую начало и конец во времени, направленную на достижение определённого результата (цели), создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска
Требование – задокументированная уникальная потребность (необходимость) того, что должен делать конкретный продукт или каким он должен быть
Слайд 8
Отладка (Debugging) – деятельность, направленная на установление точной природы известной
ошибки, а затем - на исправление этой ошибки. Результаты тестирования
являются исходными данными для отладки
Контроль (Verification) – оценка соответствия характеристик ПП требованиям, объявленным в ТЗ
(попытка найти ошибки, выполняя программу в тестовой, или смоделированной среде)
Испытание (Validation) – оценка соответствия характеристик ПП требованиям заказчика при решении его реальных задач
(попытка найти ошибки, выполняя программу в заданной реальной среде и, что важнее – решает ли ПП заданные проблемы заказчика)
Слайд 9ПРОЦЕСС РАЗРАБОТКИ ПО
Основные этапы процесса разработки ПО:
Сбор и анализ требований
Разработка
архитектуры
Кодирование
Тестирование
Документирование
Сопровождение
Слайд 10ЖИЗНЕННЫЙ ЦИКЛ ПО
Постановка задачи
Постановка задачи (спецификация программы) означает точное, полное
и понятное описание того, что происходит при выполнении конкретной программы
Точность,
т.е. исключение любой неоднозначности
Полнота, т.е. рассмотрение всех вариантов для заданного ввода, включая ошибочный или непредусмотренный ввод, и определение соответствующего вывода
Ясность, т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи - это единственный контракт между ними
Слайд 11ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА PLCM
Модель жизненного цикла - структура, состоящая из
процессов, работ и задач, включающих в себя разработку, эксплуатацию и
сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999]
Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990]
ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207
Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД)
Слайд 12УРОВНИ ЖИЗНЕННОГО ЦИКЛА
Скотт Амблер (Scott W. Ambler):
ЖЦ разработки программного обеспечения
– проектная деятельность по разработке и развертыванию программных систем
ЖЦ программной
системы – включает разработку, развертывание, поддержку и сопровождение
ЖЦ информационных технологий (ИТ) – включает всю деятельность ИТ-департамента
ЖЦ цикл организации – охватывает всю деятельность организации в целом
Слайд 13PDCA-ЦИКЛ
«Подходящая» модель ЖЦ:
направляет проект
улучшает скорость разработки
улучшает отслеживание и контроль над
проектом
минимизирует издержки и влияние рисков
улучшает отношение с клиентом
«Неподходящая» модель ЖЦ:
замедляет
выполнение работ
вынуждает делать лишнюю работу
проект оказывается неуспешным
• “P” – Plan – Планирование
• “D” – Do – Выполнение
• “C” – Check – Проверка
• “A” – Act – Реакция (действие)
Слайд 14МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПО
Каскадная (водопадная, нисходящая)
Макетирование (прототипирование)
Инкрементная
Эволюционная
Слайд 16КАСКАДНАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ПО
Синонимы: классический ЖЦ, водопадная модель
(1970, W.W.
Royce)
Характерна для периода 1970-1985 гг.
Слайд 19КАСКАДНАЯ МОДЕЛЬ АКТУАЛЬНА …
научно-вычислительного характера
операционные системы и компиляторы
системы реального
времени и управления конкретными объектами
повторная разработка типового продукта
выпуск новой
версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (миграция уже существующего продукта на новую платформу)
Слайд 20МОДЕЛЬ С ПРОМЕЖУТОЧНЫМ КОНТРОЛЕМ:
Слайд 21МАКЕТИРОВАНИЕ (ПРОТОТИПИРОВАНИЕ)
Построение/
уточнение макета
Оценка
макета заказчиком
1
2 Проектирование продукта
Слайд 22ИНКРЕМЕНТНАЯ МОДЕЛЬ ЖЦ РАЗРАБОТКИ ПО
Инкрементная разработка представляет собой процесс частичной
реализации всей системы и постепенного наращивания функциональных возможностей
Слайд 24Анализ
Проектирование
Кодиро-вание
Тестиро-вание
Поставка 1-го
инкремента
1-й инкремент
Анализ
Проектирование
Кодиро-вание
Тестиро-вание
2-й инкремент
Анализ
Проектирование
Кодиро-вание
Тестиро-вание
3-й инкремент
Поставка 2-го
инкремента
Поставка 3-го
инкремента
Слайд 25«+»
не требуется заранее тратить средства, необходимые для разработки всего проекта
в
результате выполнения каждого инкремента получается функциональный продукт
заказчик располагает возможностью высказаться
по поводу каждой разработанной версии системы
позволяет разбить возникшую проблему на управляемые части
существует возможность поддерживать постоянный прогресс в ходе выполнения проекта
снижаются затраты на первоначальную поставку программного продукта
ускоряется начальный график поставки
Слайд 26
снижается риск неудачи и изменения требований
заказчики могут распознавать важные возможности
продукта на ранних этапах разработки
риск распределяется на несколько меньшие по
размеру инкременты
требования стабилизируются на момент создания определенного инкремента
улучшается понимание требований для более поздних инкрементов
в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика
в процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработки команды не прекращали работу над проектом
возможность начать построение следующей версии проекта на переходном этапе предыдущей версии сглаживает изменения, вызванные сменой персонала
в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика
потребности клиента лучше поддаются управлению, т.к. время разработки каждого инкремента очень незначительно
Слайд 27«--»
в модели не предусмотрены итерации в рамках каждого инкремента
определение полной
функциональной системы должно осуществляться в начале жизненного цикла, чтобы обеспечить
определение инкрементов
формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом
общие затраты на выполнение проекта не будут снижены
поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах
для модели необходимы хорошее планирование и проектирование
может возникнуть тенденция к оттягиванию решений трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки
Слайд 29СПИРАЛЬНАЯ МОДЕЛЬ
Спиральная модель была предложена как альтернатива
каскадной
модели, учитывающая повторяющийся характер разработки ПО
Основные принципы спиральной
модели можно сформулировать следующим образом:
Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам
Создание прототипов ПО для уточнения и выявления требований
Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту
Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок.
Использование каскадной модели как схемы разработки очередного варианта
Активное привлечение заказчика к работе над проектом
(Бари Боэм, 1988г.)
Слайд 30СПИРАЛЬНАЯ (ЭВОЛЮЦИОННАЯ) МОДЕЛЬ РАЗРАБОТКИ ПО
Программное обеспечение создается итерационно с использованием
метода прототипирования.
Требования изначально не могут быть осознаны и установлены
Прототипом называют
действующий программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения.
Слайд 31ОСОБЕННОСТИ СПИРАЛЬНОЙ МОДЕЛИ
Достоинством спиральной схемы - начиная с некоторой итерации,
продукт можно предоставлять пользователю.
сократить время до появления первых версий программного
продукта;
заинтересовать большое количество пользователей,;
ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;
уменьшить вероятность морального устаревания системы за время разработки.
Проблема спиральной схемы - определение моментов перехода на следующие стадии.
Слайд 32V-МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА
V-образная модель была разработана как разновидность каскадной модели
V-образная
модель ЖЦ создана с целью помочь работающей над проектом команде
в планировании с обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается действиям, направленным на верификацию и аттестацию продукта
Слайд 34ПРЕИМУЩЕСТВА V-МОДЕЛИ
в модели особое значение придается планированию, направленному на верификацию
и аттестацию разрабатываемого продукта
в модели предусмотрены аттестация и верификация всех
внешних и внутренних полученных данных, а не только самого ПП
определение требований выполняется перед разработкой проекта системы, а проектирование программного обеспечения — перед разработкой компонентов
модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию
менеджеры проекта может отслеживать ход процесса разработки
Использование модели эффективно в том случае, когда доступными являются информация о методе реализации решения и технология, а персонал владеет необходимыми умениями и опытом в работе.
V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность
Слайд 37AGILE МЕТОДОЛОГИИ
Модели "скоростного" жизненного цикла (Bullock 2003)
2001 - "Манифест скоростной
разработки программного обеспечения« (Agile-manifesto)
Гибкая методология разработки (англ. Agile software development)
— это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения
Слайд 38АКТУАЛЬНЫЕ МЕТОДОЛОГИИ
РАЗРАБОТКИ ПО
Agile-программирование
Rational Unified Process (RUP)
Ранняя идентификация и
непрерывное устранение основных
рисков.
Концентрация на выполнении
требований заказчиков к программе
(анализ
и построение модели
прецедентов (вариантов
использования)).
Ожидание изменений в требованиях,
проектных решениях и реализации в процессе разработки.
Постоянное обеспечение качества на всех этапах разработки проекта.
Работа над проектом в команде
Слайд 40ГИБКАЯ РАЗРАБОТКА (AGILE)
Короткие циклы – итерации (программный проект в
миниатюре)
Личности и их взаимодействия важнее, чем процессы и инструменты (один
офис)
Работающее программное обеспечение важнее, чем полная документация
Сотрудничество с заказчиком важнее, чем контрактные обязательства
Реакция на изменения важнее, чем следование плану
Слайд 41AGILE MANIFESTO
удовлетворение клиента за счѐт ранней и бесперебойной поставки ценного
ПО;
приветствие изменения требований, даже в конце разработки ( это
может повысить конкурентоспособность полученного продукта);
частая поставка рабочего ПО (каждый месяц или неделю или ещѐ чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
Слайд 42AGILE MANIFESTO
работающее ПО — лучший измеритель прогресса;
спонсоры, разработчики и
пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
постоянное внимание на улучшение технического мастерства и удобный дизайн;
простота — искусство НЕ делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам.
Слайд 43ТЕХНОЛОГИЯ RAD
Rapid Application Development — быстрая разработка приложений. Она предусматривает:
ведение
разработки небольшими группами (3-7 человек), каждая из которых проектирует и
реализует отдельные подсистемы (улучшает управляемость проекта);
использование готовых компонентов (уменьшение времени получения работоспособного прототипа);
наличие четко проработанного графика цикла, рассчитанного не более чем на три месяца (увеличивает эффективность работы).
RAD хорошо зарекомендовал себя для небольших стандартных проектов для конкретного заказчика.
RAD ориентирован на разработку информационных систем, которые можно разбить на отдельные модули и где производительность не критична.
Слайд 44ЭТАПЫ RAD
Бизнес-моделирование (моделируются информационные потоки между бизнес-функциями)
Моделирование данных (набор объектов,
которые требуются для поддержки бизнес-процессов)
Моделирование обработки (определяются преобразования объектов, обеспечивающие
реализацию бизнес-функций. Описание обработки для добавления, изменения, удаления и поиска данных)
Создание приложения (используются готовые компоненты и утилиты автоматизации)
Объединение и тестирование (компоненты тестировать не надо).
Слайд 45ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ
Цель экстремального программирования (ХР) — устранить высокую стоимость изменений,
вносимых в ПО в процессе как разработки, так и эксплуатации.
Цикл разработки в ХР состоит из очень коротких итераций.
выслушивание заказчика
проектирование
кодирование
тестирование.
Заказчик постоянно присутствует в группе разработчиков.
При принятии решений всегда стремятся выбрать самое простое, тесты пишутся еще до написания кода.
Сборка системы выполняется ежедневно.
Авторы:
Кент Бек, Уорд Каннингем, Мартин Фаулер и др., 1996-1999
Слайд 46ОСНОВНЫЕ ПРИНЦИПЫ ХР
Планирование
Частая смена версий
Метафора
Простой проект
Тесты
Переработка системы
Программирование в паре
Непрерывная
интеграция
Коллективное владение
Заказчик с постоянным участием
40-часовая неделя
Открытое рабочее
пространство
Стандарты кодирования
Не более чем
правила
Область применимости ХР: небольшие и средние проекты.
Слайд 47Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование
(Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole
team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Extreme programming explained
Слайд 48РЕФАКТОРИНГ
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её
внешнего поведения и имеющий целью облегчить понимание её работы
В
основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований
Цель рефакторинга — сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным
Слайд 49НЕОБХОДИМОСТЬ РЕФАКТОРИНГА
Дублирование кода
Длинный метод
Большой класс
Длинный список параметров
«Завистливые» функции — метод,
который чрезмерно обращается к данным другого объекта
Избыточные временные переменные
Классы данных
Не
сгруппированные данные
Слайд 50SCRUM
Технология (набор принципов), на которых строится процесс разработки, позволяющий в
жѐстко фиксированные небольшие промежутки времени (спринты от 2 до 4
недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определѐн наибольший приоритет.
Ken Schwaber & Jeff Sutherland, 1996
Слайд 51С ЧЕГО ВСЕ НАЧИНАЛОСЬ
Курица говорит свинье: «Давай откроем ресторан!»
Свинья
смотрит на курицу и отвечает: «Хорошая идея, и как мы
его назовем?»
Курица подумала и говорит: «Почему бы не назвать «Яичница с беконом?»».
«Так не пойдѐт», — отвечает свинья, «ведь тогда мне придѐтся полностью посвятить себя проекту, а ты будешь вовлечена только частично»…
Слайд 52РОЛИ
«Свиньи»
ScrumMaster — тот, кто ведѐт Scrum митинги. Является интерфейсом между
менеджментом и командой (менеджер проекта или teamlead). Важно подчеркнуть, что
Скрам Мастер не раздает задачи членам команды - команда является самоорганизующейся и самоуправлямой
Владелец Продукта (Product Owner) — человек, отвечающий за разработку продукта который представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта
Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (7±2 человека).
«Цыплята»
Пользователи (Users)
Клиенты, Продавцы (Stakeholders)
Эксперты-консультанты (Consulting Experts)
Слайд 53
Product Backlog — приоритезированный список имеющихся на данный момент бизнес-требований
и технических требований к системе.
Включает в себя use cases,
defects, enhancements, technologies, stories, features, issues, и т.д..
Также включает задачи, важные для команды, например «провести тренинг». Постоянно пересматривается и дополняется
Слайд 54ПЛАНИРОВАНИЕ СПРИНТА
митинг1
Участники: команда, Product Owner, Scrum Master, пользователи, менеджмент
Цель: Определить
цель спринта и Sprint Backlog -функциональность, которая будет разработана в
течение следующего спринта
Артефакт: Sprint Backlog
митинг2
Участники: Скрам Мастер, команда
Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность
Артефакт: в Sprint Backlog появляются задачи
Слайд 55ПРОЦЕСС. ВСТРЕЧИ
Планирование спринта (Planning Meeting)
Митинг (Daily Scrum)
Что
сделано с момента предыдущего митинга до текущего?
Что будет сделано
с момента текущего митинга до следующего?
Какие проблемы мешают достижению целей спринта?
Демонстрация (Demo Meeting)
Ретроспектива (Retrospective Meeting)
Слайд 56SCRUM
Scrum - принципы разработки для предоставления пользователю работающего ПО с
новыми возможностями в жёстко фиксированные сроки (спринты от 2 до
4 недель)
Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении.
Строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость
Митинг происходит каждый день в течение спринта (начинается точно вовремя; все могут наблюдать, но только «свиньи» говорят; длится не более 15 минут; проводится в одном и том же месте в течение спринта).
В течение митинга каждый член команды отвечает на 3 вопроса (Что сделано с момента предыдущего митинга, что будет сделано до следующего митинга, какие проблемы мешают достижению целей спринта)
Слайд 63ОСНОВНЫЕ КРИТЕРИИ КАЧЕСТВА ПО
Качество – степень соответствия требованиям (потребностям и
ожиданиям пользователя)
Качество ПО определяется в стандарте ISO 9126 как вся
совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц
Слайд 64ПРЕДСТАВЛЕНИЕ КАЧЕСТВА В СТАНДАРТЕ ISO 9126
ISO 9126 (ГОСТ Р
ИСО / МЭК 9126-23) – «Информационная технология. Оценка программного продукта.
Характеристики качества и руководство по их применению
Слайд 65КРИТЕРИИ КАЧЕСТВА ПО
Внешние характеристики:
Корректность (наличие/отсутствие дефектов в спецификации, проекте и
реализации)
Практичность (легкость изучения и использования)
Эффективность (степень использования системных ресурсов)
Надежность (способность
системы выполнять необходимые функции; интервал между отказами)
Целостность (способность предотвращать неавторизованный или некорректный доступ)
Адаптируемость (возможность использования в других областях и средах)
Правильность (степень безошибочности данных, выдаваемых системой)
Живучесть (способность продолжать работу при недопустимых данных или в напряженных условиях)
Внутренние характеристики:
удобство сопровождения
тестируемость
удобочитаемость
гибкость
портируемость
возможность повторного использования
понятность
Слайд 66ISO 9000
ISO 9001:2000 Quality management systems — Requirements. Models for
quality assurance in design, development, production, installation, and servicing
Системы
управления качеством — Требования. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании
Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла (Аналог — ГОСТ Р-2001)
Слайд 67
ISO 9004:2000 Quality management systems — Guidelines for performance improvements
Системы управления качеством. Руководство по улучшению деятельности. (Аналог — ГОСТ
Р-2001)
ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software
Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения
Слайд 68ХАРАКТЕРИСТИКИ И АТРИБУТЫ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПО ISO 9126
Слайд 82СТОИМОСТЬ КАЧЕСТВА
Preventive costs (стоимость предотвращения низкого качества продукта\сервиса):
Планирование качества
Разработка/оценка процессов
Планирование
улучшения качества
Обучение
Стоимость всех активностей для предотвращения ошибок (QA)
Appraisal costs (стоимость
оценки):
Стоимость тестирования
Стоимость выполнения ревью
Стоимость выполнения инспекций
Все затраты на выявление дефектов (QC)
Failure cost (цена «неудач»/ошибок, обнаруженных до и после поставки продукта\предоставления сервиза заказчику, internal failure cost and external failure cost):
Стоимость идентификации, анализа, исправления ошибок и проверки исправления ошибок
Повторное тестирование
Стоимость переработок, работ по обработке жалоб заказчика
Слайд 83СТОИМОСТЬ КАЧЕСТВА
B. Boehm and V. Basili «Software Defect Reduction Top
10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1,
January 2001, pp. 135-137.): стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период выработки требований к продукту
Слайд 84УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ
ГОСТ Р и ISO/IEC 12207
V&V
Спецификация — (Specification) набор требований и
параметров, которым удовлетворяет некоторая сущность.
Согласно определению, приведенному в Единой системе
конструкторской документации (ЕСКД) спецификация — документ, определяющий состав сборочной единицы, комплекса, комплекта. В спецификации содержится подробное перечисление узлов и деталей какого-либо изделия, конструкции, установки, и т. п., входящих в состав сборочного или монтажного чертежа.
Также под спецификацией часто подразумевается документ с перечислением условий, которым должен удовлетворять производственный заказ (требования клиента к производителю).
Слайд 85ТРЕБОВАНИЯ К ПО
Требования к ПО — совокупность утверждений относительно свойств
программной системы, подлежащая реализации при создании программного обеспечения. Создаются в
процессе анализа требований к программному обеспечению
Виды требований по уровням:
Бизнес-требования — определяют назначение программного обеспечения
Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе (use case)
Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять
диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD)
Слайд 86ТЕСТИРОВАНИЕ ПО
Тестирование – проверка соответствия ПО требованиям, осуществляемая с помощью
наблюдения за его работой в специальных, искусственно построенных ситуациях (тесты)
Набор
тестов конечен
Критерии полноты тестирования: важность, эквивалентность и отношение между ситуациями тестирования
Критерий тестового покрытия: если программа правильно работает в ситуации A, то, скорее всего, в ситуации B также все будет правильно (используется одна из ситуаций одного класса)
Слайд 87СТАНДАРТЫ ТЕСТИРОВАНИЯ
IEEE 829-1998 Standard for Software Test Documentation - описывает
виды документов, служащих для подготовки тестов
IEEE 1008-1987 (R1993, R2002) Standard
for Software Unit Testing - описывает организацию модульного тестирования
ISO/IEC 12119:1994 (ГОСТ Р-2000, IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing - описывает требования к процедурам тестирования программных систем
Слайд 88ОРГАНИЗАЦИОННЫЕ ПРИНЦИПЫ УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ
Программирующая организация не должна сама тестировать разработанные
ею программы
Необходимо досконально изучать результаты применения каждого теста
Тесты для
неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных
Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать
Не следует выбрасывать тесты, даже если программа уже не нужна
Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены
Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части
Тестирование — процесс творческий
Слайд 89ТЕСТОВЫЕ МЕТРИКИ
Покрытие функциональных требований
Покрытие кода продукта. Наиболее применимо для
модульного уровня тестирования
Покрытие множества сценариев
Количество или плотность найденных дефектов
Соотношение
количества найденных дефектов с количеством тестов на данную функцию продукта
Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику
Слайд 90
5.2.4. Автоматизация тестирования
5.2.5. Примеры. Модульное тестирование. Разработка через тестирование.
Приложения модульного
тестирования
Экстремальное программирование предполагает как один из постулатов использование инструментов автоматического
модульного тестирования. Этот инструментарий может быть либо созданным третьей стороной (например, Boost.Test), либо быть создан группой разработчиков данного приложения.
В экстремальном программировании используются модульные тесты для разработки через тестирование. Для этого разработчик до
Разработка через тестирование (test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.
высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них:
Для Java
JUnit JUnit.org
Слайд 91ТИПИЧНЫЙ ЖИЗНЕННЫЙ ЦИКЛ ДЕФЕКТА
Новый — дефект зарегистрирован тестировщиком
Назначен — назначен ответственный за
исправление дефекта
Разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как
правило, сопровождается резолюцией, например:
Исправлено (исправления включены в версию такую-то)
Дубль (повторяет дефект, уже находящийся в работе)
Не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т.п.)
«У меня всё работает» (запрос дополнительной информации об условиях, в которых дефект проявляется)
Далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус Назначен (если он описан как исправленный, но не исправлен), либо в статус Закрыт.
Открыт повторно — дефект вновь найден в другой версии.
Примеры систем отслеживания ошибок
Свободно распространяемые
BUGS - the Bug Genie
Bugzilla
eTraxis
Mantis bug tracking system
Слайд 92
Итак, по времени появления ошибки можно разделить на три
вида:
структурные ошибки набора;
ошибки компиляции;
ошибки периода выполнения.
В теоретической информатике программные ошибки
классифицируют по степени нарушения логики на: • синтаксические; • семантические; • прагматические.
Слайд 93ТЕСТИРОВАНИЕ ПО
метод белого ящика (white-box testing, прозрачного ящика, структурное тестирование)
– разработчик теста имеет доступ к исходному коду и может
тесты, связанные с библиотеками тестируемого ПО
метод чёрного ящика – доступ к ПО через стандартные интерфейсы. Нацелено на проверку требований (тесты на основе требований и ограничений из спецификаций, стандартов, внутренних нормативных документов)
Тестирование на соответствие (conformance testing)
Слайд 94УРОВНИ ТЕСТИРОВАНИЯ
Модульное тестирование (Unit-testing) – тестируется минимально возможный для компонент
(отдельный класс или функция)
Интеграционное тестирование (Integration testing) – отдельные программные модули
объединяются и тестируются в группе
Системное тестирование (System testing) – тестирование на полной, интегрированной системе для проверки соответствия системы исходным требованиям (метод «черного ящика»)
Приемочное тестирование (Acceptance testing) – тестирование готового продукта конечными пользователями на реальном окружении, в котором будет функционировать тестируемое приложение
Слайд 95ТЕСТИРОВАНИЕ
Статическое тестирование (Static testing) –тестируемая программа (код) не выполняется. Анализ
происходит на основе исходного кода
(Обзоры (Reviews), Инспекции (Inspections), Сквозные
просмотры (Walkthroughs), Аудиты (Audits),
тестирование требований, спецификаций, документации)
Динамическое тестирование (Dynamic testing)
Альфа-тестирование — тестирование в процессе разработки
Бета-тестирование — тестирование выполняется пользователями (end-users)
Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”)
«Смок-тест» (Smoke Testing, «дымовое тестирование») в тестировании означает минимальный набор тестов на явные ошибки (обычно выполняется самим программистом)
Слайд 96ВИДЫ ТЕСТИРОВАНИЯ
Функциональное тестирование (functional testing)
Тестирование производительности (perfomance testing)
Стрессовое тестирование
(stress testing)
Нагрузочное тестирование (load testing)
Тестирование удобства использования (usability testing)
Тестирование интерфейса
пользователя (UI testing)
Тестирование безопасности (security testing)
Тестирование локализации (localization testing)
Тестирование совместимости (compatibility testing)
Виды тестирования 20140407_v1.docx
Слайд 97ТИПЫ ДЕФЕКТОВ И СТАТИЧЕСКИЕ МЕТОДЫ ТЕСТИРОВАНИЯ
по времени появления:
структурные ошибки набора
ошибки
компиляции
ошибки периода выполнения
В теоретической информатике программные ошибки классифицируют по степени
нарушения логики:
синтаксические
семантические
прагматические
(Майерс)
Семантика - система правил однозначного толкования отдельных языковых конструкций, позволяющих воспроизвести процесс обработки данных
Слайд 98ВЫЯВЛЕНИЕ
ОШИБОК
Инспекции исходного текста
1. Программиста просят рассказать о логике
работы программы. Во время беседы возникают вопросы, преследующие цель обнаружения
ошибки.
2. Программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования
Сквозное тестирование
экспериментально установлено, что при проведении инспекций
и сквозных просмотров определяются в среднем 38 % общего
числа ошибок в учебных программах.
При использовании инспекций исходного текста в фирме IBM
эффективность обнаружения ошибок составляла 80 %
Практическое тестирование Инспекция кода 20140407_v1.docx
Слайд 100ИЗВЕСТНЫЕ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ
Структурное программирование
Теорема о базисных конструкциях.
Алгоритм: один вход и
один выход.
Нет безусловным переходам (goto).
Поддержка: операторы ЯПВУ.
Модульное программирование
Разбиение задачи на
подзадачи до тех пор, пока они не станут простыми.
Подход к коллективной разработке.
Поддержка: подпрограммы, модули ЯПВУ.
Слайд 101Технологические основы языков программирования высокого уровня
Сложность задач
Технологии программирования
Структурное программирование
Модульное программирование
Объектный
подход
ОО и алгоритмическая декомпозиция. Алгоритмы, классы и объекты.
ОО Анализ
ОО Проектирование
ОО
Программирование
Принципы объектного подхода.
Слайд 102ОБЪЕКТНЫЙ ПОДХОД...
Перечисленных технологий стало недостаточно вследствие роста сложности задач.
Объектно-ориентированная технология.
Объектный
подход:
объектная декомпозиция
(отличия от алгоритмической)
объектная модель (классы + объекты).
Слайд 103ОБЪЕКТНЫЙ ПОДХОД
OOA + OOD + OOP
OOA – object-oriented analysis –
объектно-ориентированный анализ.
OOD – object-oriented design – объектно-ориентированное проектирование.
OOP – object-oriented
programming – объектно-ориентированное программирование.
Слайд 104ПРИНЦИПЫ ОБЪЕКТНОГО ПОДХОДА
Абстрагирование.
выделяем главное, выявляем виды абстракций
Инкапсуляция.
скрываем детали реализации
Иерархия.
иерархия помогает
разбить задачу на уровни и постепенно ее решать
Агрегация и наследование.
абстракции
можно создавать на основе имеющихся
Полиморфизм.
полиморфизм позволяет иметь естественные имена и выполнять действия, релевантные ситуации
Слайд 105ТЕНДЕНЦИЯ ПОСЛЕДНЕГО ДЕСЯТИЛЕТИЯ
Постепенно унифицируются подходы к разработке ПО
Создаются языки описания
и моделирования сложных систем
Agile IBM: http://www.rational.com/rup
MSF: http://www.microsoft.com/msf
Есть русский перевод:
http://www.microsoft.com/rus/msf
Agile:
http://www.agilemanifesto.org
Различные языки моделирования слились в один
Слайд 107UML
Unified Modeling Language
Де-факто и де-юре стандартный язык моделирования в современной
ИТ-индустрии
Пока еще преподается не во всех технических вузах СНГ, но
ситуация улучшается
http://www.omg.org/uml
http://www.rational.com/uml
http://www.uml.org
Слайд 108СТРУКТУРА СТАНДАРТА UML
Графическая
нотация
Метамодель
OCL (Object Constraint Language или язык ограничений)
Примеры
расширения
языка
Слайд 109ЛЕГЕНДА О ВАВИЛОНСКОЙ БАШНЕ
В Библии предание о том, как Бог,
разгневанный дерзостью людей, вознамеривавшихся соорудить башню до небес (Вавилонская башня)
«смешал их языки» (они перестали понимать друг друга) и рассеял человечество по всей земле.
Слайд 110UML
Для визуального моделирования нужна специальная нотация или язык.
UML (unified modeling
language) – это язык для
визуализации,
специфицирования,
конструирования,
документирования элементов программных
систем.
UML – язык общего назначения, предназначенный для объектного моделирования.
Слайд 111МОДЕЛИ UML
UML позволяет описывать систему следующими моделями:
Модель функционирования
Как описывается функциональность
системы с точки зрения пользователя.
Объектная модель
Как выглядит проект системы с
точки зрения объектного подхода.
Динамическая модель
Как взаимодействуют друг с другом компоненты системы в динамике, с течением времени. Какие процессы происходят в системе.
Слайд 112ДИАГРАММЫ UML
Диаграммы UML предназначены для визуального отображения моделей и их
компонентов.
UML 2.0 – 13 типов диаграмм
Структурные диаграммы (6)
Диаграммы поведения (3)
Диаграммы
взаимодействия (4)
Слайд 113ПОНЯТИЯ UML
Для описания структуры:
Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет.
Для описания поведения:
Действие, Событие, Сообщение, Метод, Операция, Состояние, Вариант использования.
Для описания связей:
Агрегация, Ассоциация, Композиция, Зависимость, Наследование.
Некоторые другие понятия:
Стереотип, Кратность, Роль.
Слайд 114АКТЕРЫ И
ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ В UML
Актер в UML – человек,
машина или программа, воздействует на систему, является внешним по отношению
к ней.
Вариант использования в UML – описание последовательности действий – (часто с вариантами – сценариями).
Слайд 115СВЯЗЬ АКТЕРОВ И
ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
Актеры и варианты использования общаются
посредством посылки сообщений.
Сообщения могут идти в обе стороны.
Стрелка показывает
инициатора общения
(актер на рисунке) и может быть опущена.
Слайд 117
http://staruml.sourceforge.net/en/
dia-installer.de
