Отправить E-Mail
http://www.interface.ru
Документ опубликован: 24.09.01
Разработчики информационных систем нередко оказываются в положении богатых туристов, оплативших восхождение на Эверест. Внизу они планируют, в какой позе сфотографируются на вершине и что ответят знакомым, когда те спросят, не было ли страшно. Но, не преодолев и половины пути, мечтают только о том, чтобы все это поскорее закончилось и наемный инструктор отнес их с обмороженными ногами и ушами назад.
Начиная проект по разработке того или иного программного решения, хочется знать наверняка, что он будет достойно завершен. Что же этому мешает? Может быть, недостаточный профессионализм участников проекта? Переоценка ими собственных возможностей? Отсутствие опыта? Все это действительно может стать причиной развала проекта. Но бывает ведь, что в проекте увязают квалифицированные специалисты, вполне отдающие себе отчет, какова истинная сложность задачи. Дело в том, что всякая коммерческая разработка ведется в условиях ограниченного времени. Поэтому этапы проекта, которые не удается выполнить должным образом в разумные сроки, завершаются, точнее объявляются завершенными по "тайм-ауту". Если такое происходит с одним из ключевых этапов, то вся последующая работа идет вкривь и вкось. Обычно события развиваются примерно следующим образом. Сначала делается попытка составить техническое задание, которое описывало бы будущую систему в полном объеме. Сделать этого не удается по нескольким причинам. Во-первых, непонятно, как построить описание системы. Можно написать что-то вроде пользовательской документации к несуществующему продукту, но с таким ТЗ программистам работать будет довольно сложно. Им придется решить головоломку: по действиям пользователя догадаться, как должна быть устроена программа. Иными словами, программист хочет прочитать в техническом задании, что должен делать он, а не пользователь (а последний, заметим, хочет узнать из документации не как устроена программа, а что ему с ней делать). Можно начать описывать устройство системы, но при этом велик риск, что "пасьянс не сойдется". Система получится функционально несогласованной. Конечно, существует стандарт ЕСПД (ГОСТ 19), определяющий, в частности, структуру ТЗ и другие требования к этому документу. Но он не решает проблему, а только "прячет" ее в предусмотренный этим стандартом раздел "Требования к функциональности". Во-вторых, полное техническое задание должно иметь очень большой объем. В самом деле, объем у ТЗ обычно не меньше, чем у пользовательской документации, которая даже для сравнительно небольших систем может насчитывать несколько сотен страниц. Иногда получается, что составитель ТЗ должен написать около тысячи страниц текста. Это очень большая работа. Для ее выполнения даже профессиональному техническому писателю потребуется месяца три-четыре. Итак, столкнувшись с серьезными проблемами при составлении полноформатного технического задания, постановщик задачи идет по другому пути. Сначала пишут небольшое ТЗ, в котором обозначают общие требования к системе (назначение, основные задачи, решаемые системой, и т.п.). Затем берут какое-нибудь RAD-средство и создают приложение-прототип. При этом проектирование системы подменяется ее прототипированием. "Черт, в этом отчете я же еще обязательно должен показывать сумму внеоборотных активов. Только как я ее вычислю? Можно, кончено, взять: Стоп. Вот что, пусть пользователь вводит это значение сам. Но где??? А главное, с какой стати он должен делать это "руками"? А, придумал, я его перехитрю. Сделаю такое специальное окошко, и пусть он думает,:" - таков примерно ход мысли постановщика задачи, "рисующего" прототип в Delphi или CTD. К несчастью, описанный выше процесс практически всегда сходится. Прототип демонстрируют заказчику (или начальнику), он его смотрит и дает отмашку на начало работ, в глубине души полагая, что полдела уже сделано. После этого программисты начинают заполнять прототип кодом, и до поры до времени этот блицкриг удается. Однако "сопротивление среды" постоянно возрастает. Условности и упрощения, допущенные в прототипе, оказываются неприемлемыми в реальной системе. Их замена полноценными решениями требует изменения структуры БД, доработки алгоритмов, редизайна пользовательского интерфейса. Почти завершенная, как еще совсем недавно казалось, система начинает рассыпаться, подобно вавилонской башне. Из-за сделанных на скорую руку изменений в структуре БД катастрофически снижается производительность, подправленные алгоритмы сбоят, новый интерфейс вызывает недоумение и недовольство у заказчика. О качественном тестировании и документировании нет и речи. Вдобавок все это нередко происходит в условиях цейтнота и, как следствие, недостаточного финансирования (поскольку выплаченные заказчиком авансы к этому времени уже истрачены). Счастье, если проект удается завершить без скандала с заказчиком. Как же не дать проекту зайти в тупик? Один из возможных способов - использовать методологии, эффективность и результативность которых проверена на практике. Одной из таких методологий является Rational Unified Process (RUP). Важное преимущество этой методологии состоит в том, что она не просто подробно изложена в виде базы знаний, но и подержана полнофункциональным комплектом CASE-средств. Эти CASE-средства охватывают все этапы процесса разработки от составления "use cases" и проектирования информационной системы до тестирования и ведения проектной документации. В то же время они позволяют четко организовать взаимодействие между всеми участниками проекта и сделать сам процесс разработок более контролируемым, управляемым и предсказуемым. Другая стратегия - избегать всеми способами ведения собственных разработок, использовать тиражируемые решения, интегрируя их друг с другом и приспосабливая к своим потребностям и особенностям. Или приспосабливаясь к ним: человек до сих пор не создал ничего более гибкого, чем он сам.
| Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
| По техническим вопросам обращайтесь
к вебмастеру Документ опубликован: 24.09.01 |