Чтение онлайн

– Эскиз окна приведен на следующем рисунке, размер окна 450х140 пикселов.

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

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

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

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

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

1. Визуально убедиться, что:

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

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

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

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

2. Убедиться, что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– поддержка.

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

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

Сначала полностью завершается этап «определение требований», в результате чего получается список требований.

После того как требования полностью определены, происходит переход к проектированию и далее, последовательно, по всем фазам, вплоть до инсталляции и поддержки.

Задумаемся, какие ограничения устанавливаются для требований в момент завершения фазы определения требований по каскадной методологии? Ответ достаточно очевиден – в этот момент требования фиксируются и далее являются неизменными.

Что означает «неизменными» с точки зрения проекта? Как минимум, следующее:

– содержание требования, как его понимают все участники проекта, более не меняется;

– связи требования с другими требованиями прояснены и не изменяются значимым для понимания других требований образом;

– не возникает новых требований;

– существующие требования не удаляются из рассмотрения.

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

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

Этот взгляд практически полностью акцентирует внимание аналитика на сборе и фиксации требований и связанных с этим коммуникации с заказчиком. Как только требование зафиксировано, работа аналитика считается выполненной вплоть до приемки результата.

Допущения простой модели требования довольно быстро ограничили область применения «чистой» «водопадной» методологии, потому что в реальности требования далеко не всегда столь стабильны, как допускается для этой методологии.

Это порождает серьезные риски в проектах, которые достаточно часто недооценивают.

Ответом на выявление этих рисков стало развитие гибридных, итерационных, гибких методологий, рассматривающих требования не статично, а в динамике, но об этом чуть позже.

Стоит отметить, что развитые инструменты управления требованиями (тот же IBM Rational), предоставляют возможности именно управления изменениями в требованиях, но их использование в реальных проектах не очень распространено в силу высоких затрат как на приобретение и сопровождение самих инструментов, так и на связанные с их использованием процессы. Поэтому встретить эти средства можно только в очень масштабных и длительных проектах, и то редко.

Для начинающих свой путь аналитиков часто фокусировка на сборе и фиксировании требований выглядит некоторым культом, инициацией в профессии. Они часто полагают, что суть работы аналитика в том, чтобы получить от заказчика требования и зафиксировать их.

Это верно, но лишь отчасти, другие аспекты работы по поддержанию жизненного цикла требований остаются в тени.

При этом простая модель не выделяет других аспектов, для этого нужна иная модель.

Рассмотрим детально каждое из допущений простой модели и сформируем эту другую модель.

"Однажды к раввину пришел посетитель и начал жаловаться:

– Ребе, у меня все так плохо, так плохо! Я потерял работу, моя жена болеет, дочка никак не может выйти замуж, мой сын не хочет учиться. Ребе, подскажите, может, вы знаете, что мне делать?

– Да-да, есть одно старинное средство, – ответил раввин. – Нужно взять много бумажек, написать на них: «И это все пройдет», и разложить во всех комнатах.