Разработка и анализ требований к программной системе
На основе технического задания начинается моделирование работы продукта с конечными пользователями (используя макеты пользовательского интерфейса, к примеру) и производится тестирование технического задания. Это позволяет увеличить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт. Проектирование системы… Читать ещё >
Разработка и анализ требований к программной системе (реферат, курсовая, диплом, контрольная)
Процесс работы с требованиями к продукту можно разделить на 4 этапа:
- — Определение концепции продукта.
- — Сбор требований.
- — Анализ требований.
- — Проектирование системы
Определение концепции продукта На этапе определения концепции продукта, проводится работа с его инвестором, целью которой является выработка единого видения будущего продукта. По окончанию этого этапа производится вывод о том, будет ли этот продукт разрабатываться или нет.
Сбор требований Первый этап, с которого следует начинать разработку продукта — это сбор требований. Он может выполняться сразу и полностью (в рамках каскадного процесса) или же последовательно, по частям (в циклических и итерационных процессах).
На этапе сбора требований основная работа ведется с заказчиком системы и её будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы.
Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки.
Анализ требований Сразу за сбором требований идет их анализ. Эти два процесса могут выполняться одним человеком последовательно или параллельно группой людей (Группа, занимающаяся сбором требований, передает их аналитикам, которые сразу анализируют полученные данные).
Продолжительность анализа требований, как правило, занимает в несколько раз меньше времени, чем сбор требований и в большей степени зависит от требований к документообороту, принятому в компании.
На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе.
Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей, а это, в свою очередь, поможет сэкономить бюджет и не даст расползтись рамкам проекта.
Проектирование системы Проектирование — процесс предшествующий разработке продукта. Для проектов, использующих итерационную/циклическую модель разработки, с самого начала должно производиться высокоуровневое проектирование системы — определение высокоуровневой архитектуры, а в начале каждой итерации должна происходить её детализация.
Целью всех предыдущих этапов был сбор информации о том, кому и зачем необходим будущий продукт. Этап проектирования — это первый этап, на котором группа разработки принимает проектные решения о том, какую функциональность будет нести продукт, чтобы удовлетворить пользователей.
Результатом этого этапа является законченное техническое задание к продукту. Оно должно содержать полное описание поведения будущего продукта и не содержать неоднозначностей и вопросов.
На основе технического задания начинается моделирование работы продукта с конечными пользователями (используя макеты пользовательского интерфейса, к примеру) и производится тестирование технического задания. Это позволяет увеличить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт.