Демонстрация проходит в конце спринта(не более 4-8 часов), показывается инкремент
Прототип системы (достоинства и недостатки макетирования).
Программный прототип (макет) - это ранняя реализация системы, в которой демонстрируют только часть ее функциональных возможностей.
Прототип создается с целью помочь разработчикам и пользователям (заказчикам) лучше понять друг друга, лучше понять требования к системе. Например, после того, как пользователь увидел хоть что-то, он, добавит требования к системе более осознанно.
Выделяются следующие прототипы: отбрасываемые, эволюционирующие, операционные, вертикальные, горизонтальные, интерфейсные и алгоритмические.
“отбрасываемые” прототипы создаются, чтобы опробовать какое-либо архитектурное решение.
“Эволюционирующий” – прототип постепенно развивается до конечного продукта.
“Горизонтальный” означает, что в интерфейсе изначально заложены почти все функциональные возможности системы. А “вертикальный” прототип реализует мало функций, но делает их качественно.
Достоинства прототипов:
● Обеспечивают определение более полных требований к ПО.
● Обеспечивают снятия неопределенностей.
Недостатки макетирования:
● Заказчик может принять макет за продукт(«немножко подправьте и всё»)
● Разработчик может принять макет за продукт(в прототипе может использоваться неоптимальный язык программирования, алгоритмы, про которые потом можно забыть…)
Масштаб проекта и риски
Масштаб проекта определяется следующими тремя переменными:
● Набором функций, которые необходимы пользователю.
● Ресурсами, которыми располагает проект.
● Временем, которое выделено на реализацию.
Если объем работ, необходимый для реализации функций системы, равен имеющимся ресурсам, умноженным на выделенное время, то проект имеет достижимый масштаб.
Под риском понимается вероятность того, что реализация функции окажет негативное влияние на график и бюджет. Если функция с высоким риском является всего лишь полезной, то ее можно удалить.
Таким образом, своевременное выявление риска, а так же принятие соответствующих мер позволяют предотвратить срыв проекта.
Каждый выявленный риск должен с радостью восприниматься командой проекта, т. к. в этом случае с ним можно начать хоть что-то делать. Настоящей проблемой являются риски, которые не удалось выявить. Такие риски похожи на мины, которые ждут своего часа и цели. Для выявления рисков в команде должен быть человек со скептическим складом ума.
Содержание основных рабочих процессов по созданию ПО (анализ требований, системный анализ, проектирование).
Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения.Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации достаточным для проектирования системы. Требования могут быть функциональными и нефункциональными.
Системный анализ — последовательность действий по установлению структурных связей между переменными или элементами проектируемой системы.
Проектирование программного обеспечения — процесс создания проекта программного обеспечения. Проектирование подразумевает выработку свойств системы на основе анализа постановки задачи, а именно: моделей предметной области, требований к ПО. Проектированию обычно подлежат:
● Архитектура ПО
● Устройство компонентов ПО
● Пользовательские интерфейсы.
Содержание основных рабочих процессов по созданию ПО (кодирование, тестирование).
Основным документом для этого этапа работы является техническое задание. Кодирование заключается в создании программного обеспечения в соответствии с архитектурой системы и технологией создания системы, определенными на этапах обследования и технического проектирования.
Тести́рование програ́ммного обеспе́чения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.
Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:
● Надёжность
● Сопровождаемость
● Практичность
● Эффективность
● Мобильность
● Функциональность
Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:
По объекту тестирования:
1. Функциональное тестирование (functional testing)
2. Тестирование производительности (performance testing)
a. Нагрузочное тестирование (load testing)
b. Стресс-тестирование (stress testing)
c. Тестирование стабильности (stability / endurance / soak testing)
3. Юзабилити-тестирование (usability testing)
4. Тестирование интерфейса пользователя (UI testing)
5. Тестирование безопасности (security testing)
6. Тестирование локализации (localization testing)
7. Тестирование совместимости (compatibility testing)
По знанию системы:
1. Тестирование чёрного ящика (black box)
2. Тестирование белого ящика (white box)
3. Тестирование серого ящика (grey box)
По степени автоматизации:
1. Ручное тестирование (manual testing)
2. Автоматизированное тестирование (automated testing)
3. Полуавтоматизированное тестирование (semiautomated testing)
По степени изолированности компонентов:
1. Компонентное (модульное) тестирование (component/unit testing)
2. Интеграционное тестирование (integration testing)
3. Системное тестирование (system/end-to-end testing)
По времени проведения тестирования:
1. Альфа-тестирование (alpha testing)
a. Тестирование при приёмке (smoke testing)
b. Тестирование новой функциональности (new feature testing)
c. Регрессионное тестирование (regression testing)
d. Тестирование при сдаче (acceptance testing)
2. Бета-тестирование (beta testing)