Живые требования – тот еще фрукт. Актуализируем и реализуем, пока не испортились

Эскиз диалогового окна

Кажется, теперь все на месте (понятно, что можно численно задать расположение кнопки, надписи на ней и далее детализировать, но для примера нам достаточно и этого).

Раз так, требование можно фиксировать и, затем, выполнять.

Важным следствием фиксации и неизменности требований является такое свойство этой модели как неизменные критерии приемки, которые можно сформулировать сразу после фиксации требований.

Поставим в соответствие нашим требованиям критерии приемки и вот что получится:

1.

– выведено диалоговое окно с кнопкой «OK», окно соответствует эскизу по набору и взаиморасположению компонентов (численно проконтролировать заданные параметры – размер окна 450х140 пикселов);

– заголовок «Подтвердите действие»;

– в окне текст «Ваша карточка сохранена!»;

– форматирование следующее: цвет текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA, шрифт: Arial – для заголовка и кнопки размер 10, для текста – 8;

2.

– при открытии окна обработка останавливается (попробовать кликнуть мышью по интерфейсу программы вне окна, не должно быть возможно);

– при нажатии «ОК» окно закрывается, обработка продолжается (попробовать кликнуть мышью по интерфейсу программы вне окна, должно быть возможно).

Такова традиционная модель: выясняем у заказчика, что нужно сделать, фиксируем, далее выполняем, проверяем результат на соответствие критериям, передаем результат заказчику.

Жизненный цикл требования состоит из его формулирования (сбора) и выполнения – это и есть простая модель требования.

Традиционная методология водопада отлично согласуется с такой моделью требования.

Поговорим об этом подробнее.

«Водопад» – методология на простой модели требований

Как известно, «Водопадная», или каскадная модель – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Традиционно для каскадной модели фазы следуют в таком порядке:

– определение требований;

– проектирование;

– конструирование;

– воплощение;

– тестирование и отладка;

– инсталляция;

– поддержка.

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.

Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно.