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

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

Все концентрируют свое внимание на содержимом экранных форм. То, что происходит за экраном , структура базы данных и проектирование ее схемы остаются без внимания.

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

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

Поскольку функциональные возможности наращиваются параллельно в нескольких направлениях, необходимо жестко контролировать структуру базы данных, которая будет поддерживать эти возможности. УРП может превратиться во всеобщую свалку, где таблицы сколачиваются на скорую руку, а столбцы лепятся друг к другу без какого-либо положительного эффекта. В итоге получаются базы данных, которые содержат избыточные или противоречивые данные и работают очень плохо.

При разработке методом УРП легко забыть о необходимости подготовки документации.

Методы УРП и СРП использовать можно, но, наш взгляд, только в тех случаях, если:

Объем проекта и требования с точки зрения бизнеса четко определены.

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

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

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

Если не все из этих условий выполняются, то метод УРП использовать Можно, однако следует офаничить его применение какой-то частью приложения.

Глава 1. Введение 31

Moscoiv-анализ

Независимо от того, какой метод применяется при разработке проекта, всегда полезно иметь под рукой какое-нибудь средство для экстренных случаев. В процессе анализа и проектирования необходимо классифицировать планируемые функции системы по степени важности. Один из форматов, который нам нравится, - это MoSCoW{термин позаимствован у Клегга и Баркера).* Эта аббревиатура расшифровывается следующим образом:

Must have (необходимые функции) Should have (желательные функции) Qould have (возможные функции) W.ont have (отсутствующие функции)

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

Функции категории необходимые обеспечивают возможности, которые являются критическими для успешной работы системы (она должна рассчитывать сумму арендной платы, отвечать на запрос о цене не позже, чем через 5 секунд в 95% случаев, работать 20 часов в сутки и т.д.).

Реализация остальных функций {желательных и возможных) ограничена временными или финансовыми рамками. Цикл реализации проекта определяется графиком или сметой. Мы разработаем функции категории необходимые и максимально возможное (в порядке приоритета) число функций категорий желательные и возможные, соответствующее отпущенным на это средствам или времени.

Применим Moscow-метод к нашей прокатной фирме. Приведенный в качестве примера список намеренно противоречив.

Необходимо обеспечить:

Время обработки запроса о цене в 95% случаев - 5 секунд.

Бесшовную интеграцию с бухгалтерским ПО третьих фирм.

Поддержку четвертой категории автомобилей.

Поддержку скидок за приверженность и скидок за объем заказов.

Экранные формы с поддержкой ввода всех данных.

Перенос всех справочных и транзакционных данных цз унаследованной системы.

Полный аудиторский контроль всех транзакций.

Желательно обеспечить:

Создание управленческих отчетов.

Поддержку изменяющихся уровней пользовательского доступа и безопасности.

Clegg, Dai and Richard Barker, Case Method Fast-Track, A RAD Approach, Addison-Wesley, 1994.

32 Oracle

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

9 Экранные формы для запросов. /

Можно обеспечить:

9 Ввод новых схем скидок.

ф Поддержку специальных серий счетов-фактур для одного клиента. 9 Настройку счетов-фактур в соответствии с требованиями клиентов.

Отсутствующие возможности:

Поддержка архивов старых данных.

Специальные возможности при подготовке отчетов.

Планирование этапа проектирования

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

Тщательное планирование существенно важно для любого проекта и любого этапа проекта. Планирование этапа проектирования, как правило, является обязанностью руководителей проекта и главного или ведущего проектировщика (если такой у вас есть). Несмотря на то, что выгоды планирования должны быть очевидны всем, давайте их все-таки перечислим. Итак, планирование позволяет:

разбить глобальную задачу на маленькие, независимые, управляемые и (помимо всего прочего) реализуемые щаги;

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

выявить зависимости между задачами (т.е. какие задачи должны быть заверщены до выполнения других задач);

определить узкие места, т.е. ресурсы (обычно это отдельное лицо или бригада), от которых план зависит сильнее всего;

спрогнозировать потребности в кадрах для проекта;

получить четкое представление о том, когда можно начинать этап реализации.

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