Quality assurance.Итеративная разработка

Карпов М. А., 5241/1

QA (quality assurance)

На русский язык это можно перевести как "проверка качества", хотя обычно говорят просто о тестировании.

Это процесс, который позволяет проверить соответствие разработанного программного обеспечения стандартам, которые были заданы на этапе проектирования.

Проектирование

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

Что нужно сделать, чтобы система из ненадежных элементов работала? Нужно её сделать с огромной избыточностью.

Ещё варианты?

Надо уменьшить размер команды.

Почему? За счет этого вы повышаете КПД её отдельных элементов, вы позволяете им оказывать большее влияние на общий результат работы системы за счет уменьшения количества связей, которые как раз всё это КПД гасят.

Для повышения КПД мы делаем ненадёжную систему, но зато она даёт очень эффективный результат.

Тенденции

• Переход к итерациям• Процессный менеджмент• Маленькие команды

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

Rational Unified Process (RUP)В основе RUP лежат следующие принципы:• Ранняя идентификация и непрерывное (до окончания проекта)

устранение основных рисков.• Концентрация на выполнении требований заказчиков к

исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

• Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

• Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

• Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

• Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Динамическая структура

Статическая структура RUP • Для описания осмысленной последовательности выполнения

работ и задач используются рабочие процессы. Они описывают кто, что, как и когда выполняет в процессе.

• В RUP входят 6 основных дисциплин: — Бизнес-моделирование (Business modeling);— Управление требованиями (Requirements);— Анализ и Проектирование (Analysis and Design);— Реализация (Implementation);— Тестирование (Test);— Развертывание (Deployment).

•И три вспомогательные:— Управление проектом (Project management);— Управление изменениями (Change management);— Среда (Environment).

Этап проектирования в RUP

• На этапе проектирования производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

• Документирование требований (включая детальное описание для большинства прецедентов).

• Спроектированную, реализованную и оттестированную исполняемую архитектуру.

• Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

• Сниженные основные риски.

Agile, Scrum (1)• Удовлетворение клиента за счёт ранней и бесперебойной поставки

ценного ПО• Приветствие изменения требований, даже в конце разработки. Это

может повысить конкурентоспособность полученного продукта• Частая поставка рабочего ПО (каждый месяц или неделю или ещё

чаще)• Тесное, ежедневное общение заказчика с разработчиками на

протяжении всего проекта• Проектом занимаются мотивированные личности, которые

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

(лицом к лицу)

Agile, Scrum (2)• Работающее ПО — лучший измеритель прогресса• Спонсоры, разработчики и пользователи должны иметь возможность

поддерживать постоянный темп на неопределенный срок• Постоянное внимание на улучшение технического мастерства и

удобный дизайн• Простота — искусство НЕ делать лишней работы• Лучшие архитектура, требования и дизайн получаются у

самоорганизованной команды• Постоянная(Частая) адаптация(улучшение эффективности работы) к

изменяющимся обстоятельствам

Двенадцать основных приёмов XP (1)• Короткий цикл обратной связи (Fine scale feedback) – Разработка через тестирование (Test driven

development)– Игра в планирование (Planning game)– Заказчик всегда рядом (Whole team, Onsite customer)– Парное программирование (Pair programming)

• Непрерывный, а не пакетный процесс – Непрерывная интеграция (Continuous Integration)– Рефакторинг (Design Improvement, Refactor)– Частые небольшие релизы (Small Releases)

Двенадцать основных приёмов XP (2)

• Понимание, разделяемое всеми – Простота (Simple design)– Метафора системы (System metaphor)– Коллективное владение кодом (Collective code

ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

– Стандарт кодирования (Coding standard or Coding conventions)

• Социальная защищенность программиста (Programmer welfare): – 40-часовая рабочая неделя (Sustainable pace, Forty hour

week)

Проблемы

• «Программисты не тестируют!»• «А у меня на машине всё работает!»• «Настоящий мужик свои проблемы решает

сам!»• Проблема ответственности• Проблема прозрачности

Чем раньше находится ошибка, тем она дешевле обходится

• Парное программирование• Ревью кода до коммита• Рефакторинг

Исправление ошибок и автоматизация

• Непрерывная интеграция• Юнит-тесты• Разработка через тестирование (TDD)• Автоматизиро-

ванное приёмочное тестирование

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

• Недостаток мотивации• Недостаток дисциплины• Унаследованный код• …

Инструментарий

• Definition of Done - Что значит «ГОТОВО»?• Доска• Технический долг• Daily scrum,

product backlog,нет назначений

Спасибо за внимание!

“Getting Real”, 37signals

Фредерик Брукс«Мифический человеко-месяц или Как создаются программные системы»

Том Демарко и Тимоти Листер«Человеческий фактор. Успешные проекты и команды»

Джо Мараско«IT-проекты: фронтовые очерки»