Страница 2 из 3
2. Убедиться, что:
– при открытии окна обработка останавливается (попробовать кликнуть мышью по интерфейсу программы вне окна, не должно быть возможно);
– при нажатии «ОК» окно закрывается, обработка продолжается (попробовать кликнуть мышью по интерфейсу программы вне окна, должно быть возможно).
Такова традиционная модель: выясняем у заказчика, что нужно сделать, фиксируем, далее выполняем, проверяем результат на соответствие критериям, передаем результат заказчику.
Жизненный цикл требования состоит из его формулирования (сбора) и выполнения – это и есть простая модель требования.
Традиционная методология водопада отлично согласуется с такой моделью требования.
Поговорим об этом подробнее.
«Водопад» – методология на простой модели требований
Как известно, «Водопадная», или каскадная модель – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Традиционно для каскадной модели фазы следуют в таком порядке:
– определение требований;
– проектирование;
– конструирование;
– воплощение;
– тестирование и отладка;
– инсталляция;
– поддержка.
Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно.
Сначала полностью завершается этап «определение требований», в результате чего получается список требований.
После того как требования полностью определены, происходит переход к проектированию и далее, последовательно, по всем фазам, вплоть до инсталляции и поддержки.
Задумаемся, какие ограничения устанавливаются для требований в момент завершения фазы определения требований по каскадной методологии? Ответ достаточно очевиден – в этот момент требования фиксируются и далее являются неизменными.
Что означает «неизменными» с точки зрения проекта? Как минимум, следующее:
– содержание требования, как его понимают все участники проекта, более не меняется;
– связи требования с другими требованиями прояснены и не изменяются значимым для понимания других требований образом;
– не возникает новых требований;
– существующие требования не удаляются из рассмотрения.
По существу, мы имеем вышеописанную нами простую модель требований, когда они зафиксированы, поняты и более не могут изменяться вплоть до окончания проекта.
Долгое время «водопадная» методология, как наиболее просто представляющая разработку, формировала упрощенный взгляд аналитиков и специалистов заказчика на требования, как нечто, что нужно просто собрать и выполнить.
Этот взгляд практически полностью акцентирует внимание аналитика на сборе и фиксации требований и связанных с этим коммуникации с заказчиком. Как только требование зафиксировано, работа аналитика считается выполненной вплоть до приемки результата.
Допущения простой модели требования довольно быстро ограничили область применения «чистой» «водопадной» методологии, потому что в реальности требования далеко не всегда столь стабильны, как допускается для этой методологии.
Это порождает серьезные риски в проектах, которые достаточно часто недооценивают.
Ответом на выявление этих рисков стало развитие гибридных, итерационных, гибких методологий, рассматривающих требования не статично, а в динамике, но об этом чуть позже.
Стоит отметить, что развитые инструменты управления требованиями (тот же IBM Rational), предоставляют возможности именно управления изменениями в требованиях, но их использование в реальных проектах не очень распространено в силу высоких затрат как на приобретение и сопровождение самих инструментов, так и на связанные с их использованием процессы. Поэтому встретить эти средства можно только в очень масштабных и длительных проектах, и то редко.
Для начинающих свой путь аналитиков часто фокусировка на сборе и фиксировании требований выглядит некоторым культом, инициацией в профессии. Они часто полагают, что суть работы аналитика в том, чтобы получить от заказчика требования и зафиксировать их.
Это верно, но лишь отчасти, другие аспекты работы по поддержанию жизненного цикла требований остаются в тени.
При этом простая модель не выделяет других аспектов, для этого нужна иная модель.
Рассмотрим детально каждое из допущений простой модели и сформируем эту другую модель.
Глава 2. Как работать, если требования постоянно меняются?
Вместо эпиграфа
"Однажды к раввину пришел посетитель и начал жаловаться:
– Ребе, у меня все так плохо, так плохо! Я потерял работу, моя жена болеет, дочка никак не может выйти замуж, мой сын не хочет учиться. Ребе, подскажите, может, вы знаете, что мне делать?
– Да-да, есть одно старинное средство, – ответил раввин. – Нужно взять много бумажек, написать на них: «И это все пройдет», и разложить во всех комнатах.
Озадаченный человек поблагодарил и ушел.
Через пару лет возвращается тот же человек и благодарит:
– Ребе, как я вам благодарен, как благодарен, просто нет слов! Я нашел отличную работу, жена выздоровела, дочка вышла замуж, сын закончил учебу и устроился на фирме. Все просто отлично! Спасибо вам большое! Да, только еще хотел спросить – те бумажки, которые я в квартире разложил, их можно уже убирать?
– Зачем убирать? – удивился раввин. – Пусть пока полежат".
Да, говорит известная притча, проекты, как и вся наша жизнь, крайне изменчивы.
И для требований, как отражения жизни, фраза «и это все пройдет» часто более чем справедлива.
Что это означает для нас, как специалистов, работающих с требованиями? Вернемся к постулатам простой модели требований и посмотрим на них с позиции течения жизни.
Результат такого рассмотрения обеспечит нам более приближенную к жизни, чем простая, модель требований.
Динамическая модель требований
Ранее мы назвали допущения-постулаты для простой модели требований.
Пройдем по этим ранее заявленным постулатам, которыми обеспечивалась характерная для простой модели фиксация «неизменности» требований.
Насколько неизменным в реальности является тот постулат, что содержание требования, как его понимают все участники проекта, более не меняется?
На самом деле, это допущение не очень точно, потому что со временем коммуникации приводят к углублению и, иногда, изменению понимания требований участниками проекта. Чем длиннее по времени и сложнее проект, тем более вероятно, что понимание требований со временем претерпит изменения.
Далее, постулат, что связи требования с другими требованиями прояснены и не изменяются значимым для понимания других требований образом в ходе проекта.
Связи – элемент, характеризующий сложность системы. Очевидно, что по мере углубления и детализации понимания могут быть как выявлены новые связи, так и установлена ошибочность представления о каких-то связях, ранее кажущихся существующими.
Так что, длительность и сложность проекта и в этом постулате существенно увеличивает вероятность того, что неизменность, в данном случае, связей будет нарушена.
К тем же выводам мы придем, рассмотрев набор требований с точки зрения неизменности его состава, то есть, что не возникает новых требований, а существующие требования не удаляются из рассмотрения.
Увы, и это гарантировать тем труднее, чем длительнее и сложнее проект.
Проиллюстрируем тем же примером диалогового окна программы, что был приведен при описании простой модели. Вот пара требований из списка: