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

Прототипирование – ключевая стратегия выявления требований в большинстве современных методологий. Программный прототип – «зеркало», в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путём прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя даёт ещё больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.

Метод RAD – один из наиболее известных способов быстро создавать прототипы[4].

RAD базируется на следующих базовых принципах:

§ Эволюционное прототипирование;

§ CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;

§ Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;

§ Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;

§ Жёсткие временные рамки, как противоядие от «расползания границ» проекта: если команда не укладывается в срок – функционал сужается.

Литература к лекции

1. Марка Д.А. Методология структурного анализа и проектирования. – С.-Пб.: Питер, 1995. – 235 с.

2. Мацяшек Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ. - М.: Издательский дом " Вильямс", 2002. - 432 с.: ил. - Парал. тит. Англ.

3. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005.

https://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf

4. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.

[1] Терминология RUP

[2] В нашем случае – группой аналитиков требований

[3] На практике возможны ситуации, когда требование, сформулированное одним из представителей Заказчика, не подтверждается другим представителем, имеющим большие властные полномочия. Надо отчётливо понимать, что каждое требование в конечном итоге транслируется, с одной стороны, в компоненту информационной системы, а с другой – может быть выражено в определённом количестве денежных знаков, которые Заказчик должен будет выплатить Исполнителю по приёмке работы. Поэтому право формулировать требования и область компетенции того или иного эксперта должны быть формально оговорены внутренним документом Заказчика, с которым следует ознакомится до начала проведения интервью.

[4] Хотя задачи RAD на этом не ограничиваются