Тесты
<<  Testschool Методы тестирования. Классификация по видам тестирования Как сделать на компьютере видео для школьников  >>
Лук планирования
Лук планирования
Разработчики получают задачу, берут соответствующий фрагмент
Разработчики получают задачу, берут соответствующий фрагмент
24
24
Циклы работ XP
Циклы работ XP
Компоненты системы непрерывной интеграции
Компоненты системы непрерывной интеграции
Scrum
Scrum
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Диаграммы вариантов использования (Use case diagrams)
Диаграммы вариантов использования (Use case diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы компонент (Component diagrams)
Диаграммы компонент (Component diagrams)
Картинки из презентации «Тестирование в экстремальном программировании и в методологии SCRUM» к уроку информатики на тему «Тесты»

Автор: Mux. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока информатики, скачайте бесплатно презентацию «Тестирование в экстремальном программировании и в методологии SCRUM.pptx» со всеми картинками в zip-архиве размером 532 КБ.

Тестирование в экстремальном программировании и в методологии SCRUM

содержание презентации «Тестирование в экстремальном программировании и в методологии SCRUM.pptx»
Сл Текст Сл Текст
1Тестирование в экстремальном 30продукта. Завершение (Postgame): действия,
программировании и в методологии SCRUM. 1. необходимые для подготовки продукта к
2Проект. Одним из ключевых понятий выходу на рынок. 30. Павловская Т.А. (НИУ
технологии разработки программного ИТМО).
обеспечения, как и многих других областей 31Реализация проекта в Scrum. Фаза
деятельности, является понятие проекта. реализации разбита на последовательность
Проект есть уникальное временное итераций - спринтов (Sprint). В результате
предприятие, направленное на создание каждого спринта в продукте реализуется
определенного, уникального продукта и новый, заметный для владельца продукта,
услуги. Технология управления проектом объем функциональности. В конце каждого
есть совокупность знаний, навыков, спринта продукт остается в работоспособном
инструментов и методов для планирования и состоянии. Спринт начинается с сессии
реализации действий, направленных на планирования (Sprint Planning Meeting) -
достижение поставленной в рамках проекта определяется объем функциональности,
цели. Процесс разработки программного которая будет реализована в течение
обеспечения является плохо определенным и спринта. Ежедневно проводится собрание
динамичным. 2. Павловская Т.А. (НИУ ИТМО). участников проекта - скрам-сессия (Daily
3Четыре «П» разработки ПО. Персонал Scrum Meeting). По завершению спринта
(кто это делает) Процесс (способ, которым проводится демонстрационная сессия (Sprint
это делается) Проект (выполнение Review Meeting). 31. Павловская Т.А. (НИУ
необходимых действий) Продукт (артефакты). ИТМО).
3. Павловская Т.А. (НИУ ИТМО). 32Документация в Scrum. Всего 3
4Продукт. Артефакт – любой вид документа: журнал продукта (Product
информации, создаваемый, изменяемый и Backlog) высокоуровневый список
используемый сотрудниками при создании функциональных и технических требований,
системы Артефакты: Само приложение необходимых для реализации продукта журнал
Спецификация требований Проектная модель спринта (Sprint Backlog) детализированный
Исходный и объектный код Тестовые список функциональных и технических
процедуры … 4. Павловская Т.А. (НИУ ИТМО). требований, необходимых для успешного
5Проект. Совокупность действий, завершения итерации график спринта
необходимых для создания артефакта: (Burndown Chart). показывает ежедневное
контакт с заказчиком написание изменение общего объема работ, оставшегося
документации проектирование до завершения итерации. 32. Павловская
программирование тестирование … 5. Т.А. (НИУ ИТМО).
Павловская Т.А. (НИУ ИТМО). 33Технология RAD. Rapid Application
6Процесс. Процесс создания ПО – Development — Быстрая разработка
определение полного набора видов приложений. Ориентирована на максимально
деятельности, необходимых для быстрое получение первых версий
преобразования требований пользователя в разрабатываемого ПО. Она предусматривает:
продукт. Процесс служит шаблоном для ведение разработки небольшими группами
создания проекта. Процесс определяет: кто (3-7 человек), каждая из которых
делает что делает когда делает как достичь проектирует и реализует отдельные
цели Процессы делятся на тяжеловесные и подсистемы, позволяет улучшить
легковесные (гибкие). 6. Павловская Т.А. управляемость проекта; использование
(НИУ ИТМО). готовых компонентов способствует
7Семейства процессов разработки ПО. уменьшению времени получения
тяжеловесные (heavyweight) применяются при работоспособного прототипа; наличие четко
фиксированных требованиях и многочисленной проработанного графика цикла,
группе разработчиков разной квалификации рассчитанного не более чем на три месяца,
облегченные (lightweight, agile) существенно увеличивает эффективность
применяются при малочисленной группе работы. Технология RAD хорошо
квалифицированных разработчиков и зарекомендовала себя для относительно
грамотном заказчике, который имеет небольших стандартных проектов,
возможность участвовать в процессе Начнем разрабатываемых для конкретного заказчика.
с гибких технологий - наиболее актуальных. 33. Павловская Т.А. (НИУ ИТМО).
7. Павловская Т.А. (НИУ ИТМО). 34Этапы RAD. Бизнес-моделирование
8Стратегии создания ПО. В начале (моделируются информационные потоки между
определены все требования? Циклов бизнес-функциями) Моделирование данных
конструирования. Промежуточное ПО (набор объектов, которые требуются для
распространяется? Водопад-ная. поддержки бизнес-процессов) Моделирование
Итеративные. Итеративные. Инкрементная. обработки (определяются преобразования
Эволюционная. +. +. -. 1. >1. >1. -. объектов, обеспечивающие реализацию
? +. 8. Павловская Т.А. (НИУ ИТМО). бизнес-функций. Описание обработки для
9Технологии программирования. — Почему добавления, изменения, удаления и поиска
вы пилите тупой пилой, ведь это очень данных) Создание приложения (используются
долго и трудно? — Некогда точить, пилить готовые компоненты и утилиты
надо!!! Технология программирования автоматизации) Объединение и тестирование
(технология разработки ПО) — способ (компоненты тестировать не надо). 34.
организации процесса создания программы, Павловская Т.А. (НИУ ИТМО).
совокупность приемов и способов выполнения 35Спиральная модель разработки ПО. На
определенных видов деятельности. На разных 1-й итерации может использоваться макет,
уровнях и по разным критериям выделяют который оценивается заказчиком.
пересекающиеся модели: Водопадная Программное обеспечение создается
(каскадная) модель, нисходящее итерационно с использованием метода
(структурное) программирование прототипирования. Прототипом обычно
Макетирование Спиральная (итерационная) называют действующий программный продукт,
модель разработки ПО реализующий отдельные функции и внешние
Объектно-ориентированное программирование интерфейсы разрабатываемого программного
Гибкие (agile) технологии: экстремальное обеспечения. 35. Павловская Т.А. (НИУ
программирование (XP), Scrum, TDD, FDD… ИТМО).
RUP Компонентный подход (COM, CORBA) 36Особенности спиральной модели.
САSЕ-технологии RAD … 9. Павловская Т.А. Основным достоинством спиральной схемы
(НИУ ИТМО). является то, что, начиная с некоторой
10Источники сложности проекта. Наличие итерации, продукт можно предоставлять
высококвалифицированных специалистов на пользователю, что позволяет: сократить
рынке труда. Стабильность используемой время до появления первых версий
технологической платформы, стабильность и программного продукта; заинтересовать
функциональность инструментов разработки. большое количество пользователей,
Эффективность используемых методов обеспечивая быстрое продвижение следующих
разработки, включая методы моделирования, версий продукта на рынке; ускорить
проектирования, тестирования и управления формирование и уточнение спецификаций за
версиями. Доступность специалистов, счет появления практики использования
обладающих экспертизой в прикладной продукта; уменьшить вероятность морального
области. Используемая методология и ее устаревания системы за время разработки.
соответствие данному проекту. Сроки и Основной проблемой использования
финансирование проекта. Множество других спиральной схемы является определение
организационных и технических переменных. моментов перехода на следующие стадии. Для
10. Павловская Т.А. (НИУ ИТМО). ее решения обычно ограничивают сроки
11Проблемы управления проектами. Многие прохождения каждой стадии, основываясь на
процессы разработки неуправляемы. Их экспертных оценках. Спиральную модель
исходные данные и желаемый результат применяют для программ, основанных как на
неизвестны или определены очень нечетко. процедурной, так и на
Процесс достижения желаемого результата не объектно-ориентированной парадигме. 36.
поддается формализации (например, Павловская Т.А. (НИУ ИТМО).
разработка архитектуры и исчерпывающее 37Пример реального процесса разработки
тестирование продукта). Идентифицированные ПО. 37. Павловская Т.А. (НИУ ИТМО).
процессы разработки сопровождаются 38Обзор идеи. Выдвигается идея нового
неизвестным количеством продукта Назначается менеджер по продукту
неидентифицированных. Требования к (PdM). Он оценивает идею и составляет ее
продукту часто меняются в течение краткий обзор, который направляет на
жизненного цикла проекта, что требует утверждение HPdM. Назначается PjM
сложной процедуры изменения и согласования Milestone S3: HPdM принимает решение о
требований. Попытки предложить формальную, дальнейшем анализе бизнес-идеи. 38.
детализованную методологию разработки ПО Павловская Т.А. (НИУ ИТМО).
оказываются безуспешны, потому что сам 39Обзор проекта. Pjm назначает
процесс разработки не поддается системного архитектора (SWA) и старшего
детализации и формализации. Слепое тестера (CQA). Pdm, pjm, представитель
следование методологиям, предполагающим спонсора, SWA, CQA формируют руководящую
управляемость и предсказуемость процессов группу (steering group), принимающую
разработки, приводит к непредсказуемым решения по проекту. SWA анализирует
результатам проекта. 11. Павловская Т.А. техническую возможность реализации. Pjm
(НИУ ИТМО). составляет обзор по своему проекту. Pjm
12Водопадная модель жизненного цикла ПО. составляет черновик плана проекта (project
Синонимы: классический ЖЦ, каскадная plan) pdm подготавливает отчет об анализе
модель. 12. Павловская Т.А. (НИУ ИТМО). бизнес-идеи продукта. Milestone S2: HBU
13Модель с промежуточным контролем. 13. или hpdm дают добро на начало разработки
Павловская Т.А. (НИУ ИТМО). проекта. 39. Павловская Т.А. (НИУ ИТМО).
14Макетирование (прототипирование). 1. 2 40Подготовка проекта. PjM уточняет план
Проектирование продукта. проекта, назначает команду разработчиков,
Построение/уточнение макета. Оценка макета организует взаимодействие с другими
заказчиком. 14. Павловская Т.А. (НИУ отделами (документация, локализация,
ИТМО). поддержка пользователей, технические
15Инкрементная модель. Поставка 1-го тренинги и т.д.) PdM и SWA составляют
инкремента. 1-й инкремент. Проектирование. список требований к программному продукту
Кодиро-вание. Тестиро-вание. Анализ. (Stakeholder Requirements):
Поставка 2-го инкремента. 2-й инкремент. Функциональность (Functionality), Удобство
Проектирование. Кодиро-вание. использования (Usability), Надежность
Тестиро-вание. Анализ. Поставка 3-го (Reliability), Быстродействие
инкремента. 3-й инкремент. Проектирование. (Performance), Безопасность (security),
Кодиро-вание. Тестиро-вание. Анализ. 15. Обеспеченность поддержкой (Supportability)
Павловская Т.А. (НИУ ИТМО). требования могут градуироваться по
16Гибкие технологии разработки ПО. приоритетам: обязательно (must),
Минимизируют риски благодаря разделению желательно (should), возможно (may). SWA с
процесса разработки на небольшие итерации SWE возможно создают прототип продукта
(1-4 недели). Каждая итерация может StakeHolder Requirements – основной
рассматриваться как полноценный проект продукт по завершению фазы. Milestone S1:
(может включать в себя планирование, Product Council разрешает начать
анализ требований, проектирование, разработку продукта. 40. Павловская Т.А.
реализацию, тестирование и (НИУ ИТМО).
документирование). Обычно результатом 41Разработка продукта (Development) - 1.
итерации не является продукт, готовый к SWA разрабатывает на утверждение SG дизайн
выходу на рынок. Но целью каждой итерации продукта (Design Description) и
является получение стабильной версии спецификацию по Интерфейсу пользователя
продукта. В конце каждой итерации (UI description), проводит декомпозицию на
происходит переоценка приоритетов проекта, модули, описывает все в удобном для
что значительно сокращает риски. Все разработки виде (напр. UML), PjM планирует
гибкие методологии имеют общие сроки и расстановку сил по разработке
характеристики: • итеративная разработка; каждого модуля CQA начинает подготовку
• фокус на взаимодействии и коммуникации; Test Plan и Test Specification Тестовая
• полный или частичный отказ от создания спецификация строится с учетом требований.
дорогостоящих промежуточных артефактов Она описывает методы тестирования, Test
проекта. 16. Павловская Т.А. (НИУ ИТМО). Cases, их важность и критерии проверки.
17Основные идеи agile. • Личности и их Milestone DA: дизайн утверждается SG
взаимодействие важнее, чем процессы и (Руководящей группой). 41. Павловская Т.А.
инструменты. • Работающее программное (НИУ ИТМО).
обеспечение важнее, чем полная 42Разработка продукта (Development) - 2.
документация. • Сотрудничество с Выполняется итеративно: анализ, дизайн,
заказчиком важнее, чем переговоры по программирование, тестирование. Milestones
контракту. • Реакция на изменения важнее, Dn – D1: завершение билда N, …, 1.
чем следование плану. Краеугольным камнем Milestone D1: Фиксация - Code &
гибких технологий программирования feature freeze (alpha version) Нет
является разработка через тестирование: серьезных дефектов - No any urgent bugs
автоматические тесты пишутся для любой CQA подготовил тестовую спецификацию
части реализации, которая гипотетически Первая версия. TWriter подготовил черновик
«может сломаться»; тесты пишутся руководства пользователя Продукт готов к
непосредственно перед написанием системному тестированию. 42. Павловская
соответствующего кода; существующий код Т.А. (НИУ ИТМО).
никогда не меняется без написания 43Альфа-тестирование. Итеративное
соответствующих тестов; выполняется тестирование продукта тестерами под
регулярный запуск всех автоматических руководством CQA. Как только серьезных
тестов. 17. Павловская Т.А. (НИУ ИТМО). проблем больше не обнаруживается, продукт
18Основы манифеста гибких технологий. • переходит в статус beta version. Milestone
Главное – удовлетворение требований V3: product beta-version & draft of
заказчика путем скорой и непрерывной User Guide, нет серьезных проблем и
поставки ценного и работоспособного ПО. • отклонений от требований. 43. Павловская
Приветствуются изменяющиеся требования: их Т.А. (НИУ ИТМО).
используют для повышения 44Бета-тестирование. Продукт отсылается
конкурентоспособности продукта. • на ознакомление и тестирование
Работоспособное ПО поставляется как можно ограниченному набору пользователей (User
чаще, периодами от пары недель до пары Support team, beta testers, sales
месяцев. • Бизнесмены и разработчики engineers, external partners). Milestone
ежедневно работают сообща. • Над проектом V2: готов Release Candidate, no any
должны работать мотивированные unresolved problems found. Тестирование
профессионалы, которым оказывается доверие окончательной версии: Release candidate
и создаются все условия для работы. • version отсылается избранным заказчикам.
Наиболее эффективным способом передачи Milestone V1: Руководящая группа принимает
информации (как внутри команды решение о том, что продукт готов к выходу.
разработчиков, так и вовне) является 44. Павловская Т.А. (НИУ ИТМО).
личный разговор. • Работающий продукт — 45Подготовка к выпуску и выпуск. PdM и
основной показатель прогресса. • HPdM проверяют, что продукт готов к выходу
Поддерживается постоянный устойчивый ритм на рынок (все собрано, документация
ведения разработки. • Постоянное внимание подготовлена, отделы поддержки и тренинга
к техническому совершенству и качеству готовы, реклама дана, произведена
проектирования повышает гибкость проекта. Интернет-подготовка, завод готов
• Простота — искусство НЕ делать лишней отштамповать диски, отдел доставки готов
работы — крайне необходима. • Лучшие их доставить, определены цены, согласовано
требования (SRS), архитектурные и с продавцами, и т.п.). Milestone R2: все
технические решения создаются подготовлено и согласовано, назначена
самоорганизующимися командами. • Команда точная дата выхода. Выпуск (R2) Продукт
регулярно рассматривает и внедряет любые заливается на болванки, доставляется в
методы повышения своей эффективности. 18. магазины. Дается контрольная отмашка о
Павловская Т.А. (НИУ ИТМО). выходе продукта в свет. 45. Павловская
19Лук планирования. 19. Павловская Т.А. Т.А. (НИУ ИТМО).
(НИУ ИТМО). 46Унифицированный процесс (RUP).
20Проектирование в гибких технологиях. Разработчики: Г. Буч, А. Якобсон, Д. Рамбо
Отказ от длительного проектирования перед (Rational, 1998) Обобщенный каркас
началом работы и выполнение проектирования процесса разработки ПО
на протяжении всего выполнения проекта. В Компонентно-ориентирован УП управляет
начале проекта выполняется лишь действиями всех его участников:
формирование общего представления. Для разработчиков руководства пользователей
этого используются системные метафоры, на заказчиков Процесс должен постоянно
основе которых формируется высокоуровневая адаптироваться к реальному положению дел,
схема проекта. Процесс разработки состоит которое определяется: доступными
из большого количества очень коротких технологиями утилитами персоналом
циклов. Конечный результат этапа организационными шаблонами. 46. Павловская
планирования – список задач, подлежащих Т.А. (НИУ ИТМО).
реализации на следующей итерации. 20. 47Характеристики УП. Управляемый
Павловская Т.А. (НИУ ИТМО). вариантами использования
21Разработчики получают задачу, берут архитектурно-ориентированный итеративный и
соответствующий фрагмент разрабатываемого инкрементный использует UML основан на
кода, выполняют рефакторинг, необходимый компонентном подходе, использует стандарт
для упрощения написанного кода, составляют визуального моделирования. Архитектура -
тесты, а только затем создают сам код, представление всего проекта с выделением
который должен пройти тесты. Поскольку важных характеристик. Архитектура
циклы «проектирование–тест–код» описывается различными представлениями и
непродолжительны, а заказчик часто охватывает наиболее важные статические и
получает работающие версии программного динамические аспекты системы. Разработка
продукта, обратная связь осуществляется делится на мини-проекты (итерации), в ходе
непрерывно и служит для контроля, что которых реализуется группа вариантов
проектирование и кодирование продвигаются использования. Итерации не обязательно
в нужном направлении. Так как изменения на аддитивны. 47. Павловская Т.А. (НИУ ИТМО).
каждом цикле малы, решения, от которых 48Преимущества управляемого УП.
приходится отказываться, невелики, в Ограничивает финансовые риски затратами на
результате чего можно быстро реагировать одну итерацию Снижает риск непоставки
на изменения с наименьшими затратами. 21. продукта Ускоряет темпы процесса
Павловская Т.А. (НИУ ИТМО). разработки в целом Облегчает адаптацию к
22Экстремальное программирование. неизбежным изменениям требований. 48.
Основная идея экстремального Павловская Т.А. (НИУ ИТМО).
программирования (ХР) — устранить высокую 49Жизненный цикл УП. Каждый цикл состоит
стоимость изменений, вносимых в ПО в из 4х фаз, каждая фаза разделяется на
процессе как разработки, так и итерации Результатом каждого цикла
эксплуатации. Цикл разработки в ХР состоит является новый выпуск системы Каждая фаза
из очень коротких итераций. Четырьмя заканчивается вехой Веха определяется по
базовыми действиями в цикле являются: наличию определенного набора артефактов
выслушивание заказчика проектирование Артефакт – любой вид информации,
кодирование тестирование. Заказчик создаваемый, изменяемый и используемый
постоянно присутствует в группе сотрудниками при создании системы. 49.
разработчиков. При принятии решений всегда Павловская Т.А. (НИУ ИТМО).
стремятся выбрать самое простое, тесты 50Назначение вех. По ним руководитель
пишутся еще до написания кода. Сборка принимает решения перед тем, как перейти
системы выполняется ежедневно. Идеолог ХР на следующую фазу Возможность отслеживать
- Кент Бек. 22. Павловская Т.А. (НИУ процесс Возможность прогнозирования оценок
ИТМО). в других процессах. 50. Павловская Т.А.
23Основные принципы ХР. Коллективное (НИУ ИТМО).
владение Заказчик с постоянным участием 51Цикл разработки. 51. Павловская Т.А.
40-часовая неделя Открытое рабочее (НИУ ИТМО).
пространство Стандарты кодирования Не 52Содержание фаз. Проектирование:
более чем правила. Планирование Частая детальное описание вариантов использования
смена версий Метафора Простой проект Тесты архитектура в виде представлений всех
Переработка системы Программирование в моделей план действий и оценка ресурсов.
паре Непрерывная интеграция. Область Анализ и планирование требований: идея
применимости ХР: небольшие и средние превращается в концепцию готового продукта
проекты. 23. Павловская Т.А. (НИУ ИТМО). создается бизнес-план разработки
2424. Павловская Т.А. (НИУ ИТМО). упрощенная модель вариантов использования
25Тестирование в ХР. Тестирование пробный вариант архитектуры выявление
модулей (unit testing): позволяет рисков и расстановка приоритетов грубая
разработчикам убедиться, что код работает оценка проекта. 52. Павловская Т.А. (НИУ
корректно, и без опасений выполнять ИТМО).
рефакторинг (refactoring). помогает не 53Построение уточнение базового уровня
авторам кода понять, зачем нужен тот или архитектуры реализация всех вариантов
иной фрагмент кода и как он функционирует использования Внедрение бета-версия
Приемочное тестирование (acceptance тренинги сотрудников заказчиков
testing): позволяет убедиться в том, что исправление дефектов. 53. Павловская Т.А.
система действительно обладает заявленными (НИУ ИТМО).
возможностями и функционирует корректно. 54Модели УП. Модели – наиболее важный
TDD (Test Driven Development): пишется тип артефактов. Каждая модель описывает
тест (не проходит) пишется код, чтобы тест систему с определенной точки зрения на
прошел выполняется рефакторинг кода. 25. определенном уровне абстракции. Вариантов
Павловская Т.А. (НИУ ИТМО). использования Анализа Проектирования
26Циклы работ XP. 26. Павловская Т.А. Развертывания Реализации Тестирования Все
(НИУ ИТМО). модели связаны, они полностью описывают
27Компоненты системы непрерывной систему. Набор моделей дает варианты
интеграции. 27. Павловская Т.А. (НИУ обозрения системы для всех сотрудников.
ИТМО). 54. Павловская Т.А. (НИУ ИТМО).
28Scrum. 28. Павловская Т.А. (НИУ ИТМО). 55UML. Язык для специфицирования,
29Scrum. Основой Scrum является визуализации, конструирования и
итеративная разработка. Scrum определяет документирования программных продуктов.
итеративные правила управления проектом, Также используется в бизнес-моделировании
которые призваны обеспечивать достижение и моделировании любых иных (не
максимального эффекта от реализованной программных) систем. UML позволяет
функциональности. В Scrum определяются задавать следующие аспекты: Диаграммы
основные правила взаимодействия участников вариантов использования (use case
команды, которые призваны обеспечивать diagrams) Диаграммы классов (class
максимально быструю реакцию на diagrams) Диаграммы поведения Диаграммы
существующую ситуацию. Каждая итерация в состояний (statechart diagrams) Диаграммы
Scrum может быть описана так: планируем – действий (activity diagrams) Диаграммы
фиксируем – реализуем – анализируем. За взаимодействия (interaction diagrams)
счет фиксирования требований на время Диаграммы последовательностей(sequence
одной итерации и изменения длины итерации diagrams) Диаграммы
методология Scrum позволяет управлять взаимодействий(collaboration diagrams)
балансом между гибкостью и Диаграммы реализации (implementation
предсказуемостью разработки. 29. diagrams) Диаграммы компонент (component
Павловская Т.А. (НИУ ИТМО). diagram) Диаграммы развертывания
30Общие положения. 3 роли: владелец (deployment diagram). 55. Павловская Т.А.
продукта (Product Owner) - отвечает за (НИУ ИТМО).
определение требований к продукту команда 56Диаграммы вариантов использования (Use
(Team) - группа самостоятельных и case diagrams). 56. Павловская Т.А. (НИУ
инициативных разработчиков, ответственных ИТМО).
за реализацию проекта скрам-мастер 57Диаграммы деятельности (Activity
(ScrumMaster) отвечает за решение всех diagrams). 57. Павловская Т.А. (НИУ ИТМО).
организационных проблем и соблюдение 58Диаграммы последовательностей действий
методологии Scrum. 3 фазы проекта: (Sequence diagrams). 58. Павловская Т.А.
Подготовка (Pregame): общий план проекта, (НИУ ИТМО).
список основных требований к продукту, 59Диаграммы компонент (Component
высокоуровневая архитектура продукта. diagrams). 59. Павловская Т.А. (НИУ ИТМО).
Реализация (Game): итеративное развитие
Тестирование в экстремальном программировании и в методологии SCRUM.pptx
http://900igr.net/kartinka/informatika/testirovanie-v-ekstremalnom-programmirovanii-i-v-metodologii-scrum-116861.html
cсылка на страницу

Тестирование в экстремальном программировании и в методологии SCRUM

другие презентации на тему «Тестирование в экстремальном программировании и в методологии SCRUM»

«Экстремальный спорт» - Экстримальные виды спорта. Неистребимое желание человека подержать за глотку саму старуху Смерть. На бодиборде катаются преимущественно лежа (или “ничком”). Главный редактор и директор проекта : нурмухаметов ирек. Лыжный спорт. Французы выдумали термин "Экстремальный лыжный спорт" в 1970-х.

«Курсы программирования» - Занимательное программирование. Коллаж, способы создания коллажа. Задачи курса. Использование различных эффектов. Создание программ, которые решают сложные пользовательские задачи. Работа с текстом в Photoshop (ввод, редактирование форматирование символов и абзацев). Многообразие фильтров в Photoshop.

«Классификация языков программирования» - Денисом Ритчи. Системы программирования. Язык программирования Pascal относится к: Томасом Курцем, Джоном Кемени. Повтори классификацию языков программирования по степени детализации и способу программирования. Задание. На слайдах будут приведены вопросы с вариантами ответа. Никлаусом Виртом. Процедурным языкам; логическим языкам; объектно-ориентированным языкам.

«Язык программирования Паскаль» - Обучает хорошему стилю программирования, воспитывает дисциплину структурного программирования. Алгоритмический язык Паскаль. назван в честь английского ученого Блеза Паскаля. Гибок и развит в отношении типов данных. Блез Паскаль (1623 – 1662). Язык программирования Паскаль. ЯП Паскаль выбран как наиболее удовлетворяющий целям обучения:

«Линейное программирование» - Решение задач линейного программирования в MS Excel. Результаты. На рисунке: оптимальное решение находится в одной из вершин многоугольника решений А, В, С, D. В MS Excel 2007 кнопка Поиск решения появится во вкладке Данные. В MS Excel 2007: 4) Кнопка Перейти (внизу окна Параметры Excel). Первое ограничение.

«История развития языков программирования» - Другая важная классификация величин - простые и структурированные. Система, разработанная Дж. Языки программирования высокого уровня. Величины могут быть постоянными и переменными. Понятие «переменная» в языках программирования отличается от общепринятого в математике. Значения постоянных величин не изменяются в ходе выполнения программы.

Тесты

21 презентация о тестах
Урок

Информатика

130 тем
Картинки
900igr.net > Презентации по информатике > Тесты > Тестирование в экстремальном программировании и в методологии SCRUM