В этом уроке вы узнаете, как системный аналитик участвует в реализации и тестировании ПО.
У RANA.Software новый проект. Команда займётся созданием ПО для «Капсулы», сети капсульных мини-отелей, расположенных в разных районах города. Капсулу можно арендовать на несколько часов, чтобы быстро восстановить силы.
В первой версии ПО решили остановиться на минимальном наборе функций: регистрация личного кабинета, бронирование капсулы, отмена бронирования, просмотр истории бронирований.
У команды есть несколько месяцев, чтобы разработать, доставить, протестировать и представить ПО заказчику. Проект ПО для «Капсулы» Айгуль и Даня уже подготовили, так что начинается новый этап — реализация.
Даня
Волнительно! Я почти ничего не знаю о реализации и тестировании 😞
Айгуль
Поверь мне, после архитектуры и API с этими этапами ты точно справишься!
Модели разработки ПО
В прошлых спринтах вы узнали, как системный аналитик разрабатывает требования к ПО (в том числе моделирует их), а также как он участвует в проектировании ПО.
После того как проект ПО готов, команда разработки приступает к его реализации и тестированию.
Работа системного аналитика отличается в разных моделях разработки ПО: в каскадной (Waterfall) и гибкой (Agile). Отличия проявляются как в процессе разработки требований к ПО и его проектировании, так и во время реализации и тестирования ПО.
Реализация и тестирование требований к ПО
В каскадной модели разработки ПО (Waterfall) весь проект представляет собой одну продолжительную итерацию. В этой итерации члены команды разработки сначала разрабатывают требования к ПО (в том числе моделируют их), затем проектируют будущее ПО с учётом выбранных технологий, реализуют проект ПО и тестируют результаты реализации.
Системный аналитик в каскадной модели разрабатывает все возможные требования к ПО в самом начале проекта и передаёт их разработчикам, архитектору ПО и дизайнеру пользовательского интерфейса и тестировщикам.
После этого работа СА над проектом может считаться практически завершённой: он может всего лишь отвечать на вопросы других членов команды разработки или вовсе переключиться на другой проект.
В гибкой модели разработки ПО (Agile) команды разработки выполняют проект короткими итерациями. В течение каждой итерации члены команды разработки также разрабатывают требования к ПО, проектируют ПО, реализуют и тестируют его.
В гибкой модели работа СА над проектом не завершается до выполнения проекта — он непрерывно разрабатывает требования к ПО. Он также остаётся полностью вовлечённым в процесс разработки: участвует в проектировании, реализации и тестировании ПО, помогая другим членам команды.
Например, СА и разработчик могут обсуждать требования к ПО параллельно с написанием разработчиком программного кода.
Часто СА совместно с тестировщиком в гибкой модели тестирует результаты реализации каждой функций. Например, основываясь на критериях и сценариях приёмки истории: на основе одних сценариев приёмки тестировщик пишет автоматизированные тесты, в то время как на основе других СА тестирует результат реализации истории вручную.
Так как в гибкой модели СА тесно работает с другими членами команды разработки, ему необходимо обладать знаниями не только в системном анализе, но и в проектировании систем, написании программного кода и в тестировании.
В этом спринте
В этом спринте вы узнаете больше о реализации ПО и его тестировании.
Поговорим о языках программирования и процессе написания программного кода, чтобы вы могли эффективно взаимодействовать с разработчиками. А ещё разберём план тестирования, уровни и типы тестов, чтобы выстраивать совместную работу с тестировщиками.
В этом спринте вы также узнаете, как проводить ручное тестирование ПО.