Проект успешно завершен?

Есть один печальный, но реальный факт: не каждый проект доходит до этапа реализации. Наиболее распространенная причина этого - просто отказ делать то, что нужно, - описана в следующем разделе. Специалисты приводят разные данные, но некоторые из них полагают, что 40% проектов либо полностью прекращаются, либо значительно уменьшаются в объемах. Важнейший аспект проектирования, о котором мы лишь упомянули выше, - это необходимость выявления рисков и управления ими. Каждый проект сопряжен с риском; как проектировщики, мы должны сконцентрировать внимание на технических рисках и начать противодействовать им как можно раньше. Выявив эти риски, мы должны сформулировать их и составить план их устранения или минимизации.

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

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

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

3. Разработать ПО промежуточного уровня, работающее между приложением и пакетом бухгалтерского учета. Прикладное ПО производит простые и четко определенные вызовы этого ПО, например, в виде PostDebit <счет><сумма>. ПО промежуточного уровня превращает такой вызов в вызов системы бухучета. Это ПО можно разработать отдельно от основного приложения. Если будет приобретен новый пакет бухгалтерского учета, нам придется лишь переписать программы промежуточного уровня, поскольку наши приложения полностью изолированы от внутренних механизмов бухгалтерских программ.

На наш взгляд, самый лучший вариант - третий, поэтому мы начинаем проектировать систему с ПО промежуточного уровня.

Журнал проектирования

Следует подчеркнуть важность регистрации всех вопросов, возникающих в процессе проектирования системы. Нужно регистрировать (где-нибудь, не важно, где именно) все обсуждаемые варианты, варианты, которые учитывались, и окончательные решения. Эту информацию можно хранить в CASE-репозитарии, в документах текстового процессора, в текстовых файлах и даже на бумаге. Самое главное - обязательно сохранить ее где-нибудь.

Почему мы акцентируем внимание на этом? Да потому, что имеем печальный опыт, когда наши проектировщики изменяли первоначальные решения. Это происходило, в частности, из-за того, что никто из участников проекта не мог объяснить, почему ранее принято то или иное решение, так как аргументы в его пользу были давно забыты. В некоторых случаях причина принятия первоначального решения становилась ясна несколько месяцев спустя, когда новый, как будто лучший, подход оказывался тупиковым.

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

Вот небольшой фрагмент журнала проектирования системы проката автомобилей:

Журнал проектирования

Раздел: распределение данных

Исходные предпосылки (7.02.95 г.). Существует общее мнение, что фирме следует перестать полагаться только на центральный мэйнфрейм. Нужно перейти на распределенную систему. Основные преимущества - более высокие производительность и устойчивость. Решить эти проблемы можно путем модернизации мэйнфрейм-системы и установки горячей резервной машины. Ввод распределенной архитектуры не позволит полностью устранить зависимость от центрального сервера, и группу проектировщиков все еще не убеждает теория о том, что в случае отказа центрального хоста его функции временно сможет принять на себя один из других серверов. Нас также волнует то, что в регаональных офисах нет квалифицированного персонала для управления сервером, поэтому все обслуживание и администрирование придется осуществлять дистанционно.

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

Совещание с представителями Oracle (27.09.95 г.). Мы обсудили все возможности репликации, которые может обеспечить Oracle, и решили, что в основном будем использовать снимок с защитой от записи. Oracle организовала посещение эталонного узла, чтобы мы увидели, как он работает.

7 л 1 о а

Альтернативные методы и подходы

в предыдущих разделах мы представили процесс проектирования баз данных довольно упрощенно. Действительно, ранее было отмечено, что проектирование обычно не выполняется с первого захода . Однако в нашем примере с прокатом автомобилей мы описали его именно так. Где же в реальной жизни заканчивается анализ и начинается проектирование? Где заканчивается проектирование и начинается реализация? В большинстве случаев на эти вопросы нельзя ответить однозначно. Завершая отдельные стадии анализа и имея его результаты, проектировщики параллельно работают над решением первоочередных задач проектирования. Периоды, когда работа ведется параллельно, бывают весьма продолжительными. Аналогично, программисты, не дожидаясь завершения отдельных стадий проектирования, могут работать над компоновкой модулей. Это имеет смысл особенно при наличии общих модулей, которые должны часто вызываться в приложении.

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

Ускоренная и совместная разработка приложений

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

Имеют место случаи давления со стороны спонсоров проекта или распорядителей бюджета, которые направлены на досрочное проведение этапа реализации, с тем чтобы получить какой-то результат и как можно скорее продемонстрировать его. Во многих случаях, когда анализ и проектирование урезаются, избираются подходы, представляемые уш: ускоренная разработка приложений (УРП) или совместная разработка приложений {СРП). Мы скептически относимся к этим методам. Начнете ли вы строить мост или изготавливать машину, не закончив проектирование? Наверное, нет. Так почему же такие методы считаются приемлемыми при разработке информационных технологий? Так быть не должно.

30 Oracle