Альтернативы программированию

Наталия Елманова

Конверторы, OLAP и Office

«Своя» СУБД

О готовых компонентах

Кому нужен hard-coded-документооборот

Действительно ли выгодна дешевая альтернатива дорогому продукту?

Интранет-сайт или корпоративный портал?

Альтернативы для заказчиков и руководителей проектов

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

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

Конверторы, OLAP и Office

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

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

Дублирование функциональности Microsoft Office в создаваемых приложениях вообще является весьма обычным явлением. Тысячи программистов по всему миру пишут приложения, способные строить графики, генерировать и печатать документы, а потом эти приложения устанавливаются на компьютеры, уже оснащенные программой Microsoft Office, которую можно заставить сделать все это с помощью максимум десятка строк кода. И далеко не всегда эти тысячи программистов руководствуются соображениями, связанными с приобретением лицензий, — зачастую причиной написания такого кода является консерватизм или банальное незнание возможностей Office, либо (что греха таить!) мысли типа «А я сделаю лучше!».

Еще один довольно типичный пример — создание приложений для бизнес-анализа, в процессе которого на создание совершенно типовой OLAP-функциональности тратится несколько человеко-месяцев или даже человеко-лет. Часто это происходит опять же из-за незнания возможностей современных OLAP-средств, связанных с созданием решений на их основе, — даже об OLAP-возможностях Excel, не говоря уже о возможностях SQL Server, как показывает практика, многие разработчики и не догадываются.

«Своя» СУБД

ще в начале 90-х годов, будучи младшим научным сотрудником одного из московских вузов, я воочию наблюдала конфликт, разгоревшийся между моим коллегой, очень неплохим программистом, и его руководителем. Руководителю был нужен обыкновенный список литературы к отчету, который он поручил создать моему коллеге. Угадайте, что получил руководитель в итоге? Как ни смешно — настольную СУБД для MS-DOS с генератором отчетов, которая действительно печатала бы список литературы и даже аннотации книг, будь все эти данные введены в единственную таблицу, содержавшую означенный список. Это была именно СУБД собственного производства, а не решение на базе готового продукта типа dBase или FoxBase. Дело в том, что моего коллегу не устроил принцип хранения данных в этих СУБД, в частности хранение данных из MEMO-полей в отдельных файлах. О том, сколько времени заняло производство бумажного документа столь экстраординарным способом, думаю, лучше не рассказывать — к моменту его готовности надобность в нем, естественно, давно отпала…

Данный пример можно было бы считать просто феноменом из области психологии межличностных отношений, если бы не одно «но» — производство своих СУБД без серьезных на то оснований наблюдается в нашей стране сплошь и рядом. И речь идет вовсе не о каталоге домашних компакт-дисков, созданном школьником, еще не успевшим узнать о существовании такого класса продуктов, как СУБД, а о корпоративных проектах с немалым бюджетом.

Наиболее выдающимся из известных мне случаев можно назвать разработку собственной СУБД для решения конкретной прикладной задачи на одном из крупных предприятий, начатую в конце 80-х годов и прекращенную в конце 90-х, после того как член команды разработчиков IT-отдела этого предприятия случайно увидел Oracle 7 в офисе одной из компаний-партнеров и поинтересовался возможностями этой СУБД у местных разработчиков. Причиной принятия решения о разработке собственной СУБД было отсутствие удовлетворительных средств контроля ссылочной целостности в dBase и FoxBase, которые изначально планировалось использовать в качестве средства хранения корпоративных данных. Суммарные трудозатраты на эту разработку оказались явно выше, чем приобретение мэйнфрейма (не говоря уже о сервере подешевле) и одной из серверных СУБД. А ведь и Oracle, и DB2 существовали и в те времена, просто руководству IT-отдела того самого предприятия об их существовании было, как ни странно, не известно...

Естественно, я никого не призываю никогда не создавать собственные СУБД. Но прежде чем решаться на такой шаг, следует убедиться, что этому решению действительно нет альтернативы.

О готовых компонентах

УБД, как правило, интересна конечному пользователю (или заказчику) не столько сама по себе, сколько как компонент решения, с которым конечный пользователь имеет дело. Удобство использования СУБД в качестве компонента готового решения чаще всего сомнений не вызывает.

Немного сложнее дело обстоит с компонентами, встраиваемыми в клиентские приложения, например с элементами управления ActiveX, VCL-компонентами для Delphi, библиотеками классов для платформы Microsoft .NET, которые в огромном количестве производятся и продаются различными независимыми компаниями и охватывают все более или менее массовые области применения, начиная со штрих-кодов, наносимых на этикетки товаров, и заканчивая средствами доступа к мэйнфреймам и интеграции приложений. Использование таких компонентов часто экономит немало средств, поскольку их приобретение оказывается более выгодным, чем разработка с нуля аналогичной функциональности. Однако многие руководители проектов считают их применение в какой-то степени рискованным: при смене версии средства разработки соответствующей версии нужного компонента может и не оказаться, как это произошло несколько лет назад с очень популярной библиотекой компонентов для Delphi RX Library, созданной программистами из известной страховой компании «Росно», сменившими затем и место работы, и страну проживания. Риск есть и в случае применения в проектах продуктов более крупных компаний, которые тоже могут уйти с рынка компонентов, как это сделала компания TurboPower, известная многим пользователям той же Delphi.

Тем не менее отказываться от применения готовых компонентов не стоит. Как минимум, есть смысл перед принятием решения об отказе задать себе несколько вопросов, например: «Будет ли создаваться новая версия этого приложения через год-два?» или «Сколько времени будет эксплуатироваться данное приложение до момента его замены?» Как показывает практика, если приложение прожило пять-шесть лет, а затем наступило время его обновления, то заменой одного лишь отсутствующего компонента в списке связанных с этой задачей проблем дело не ограничится — слишком много изменений происходит за такой срок и в индустрии в целом, и в бизнес-процессах любой компании.

Кому нужен hard-coded-документооборот

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

Одним из примеров подобного «изобретательства» было создание собственной системы документооборота одной из российских компаний. Реализация ее была весьма оригинальной: как только по каким-либо причинам путь прохождения документов в компании менялся, в код приложения, написанного на C++, его автором вносились соответствующие изменения.

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

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

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

Действительно ли выгодна дешевая альтернатива дорогому продукту?

есколько лет назад в нашу редакцию на тестирование было прислано программное обеcпечение для создания электронных магазинов, написанное небольшим отделом разработки одной из российских компаний. На первый взгляд продукт производил неплохое впечатление: трехзвенная архитектура, удачный выбор СУБД, современные на тот момент технологии (ASP, SQL Server). И стоил он недорого — раза в три дешевле Microsoft Commerce Server, использовавшего тот же самый набор технологий. Правда, в функциональности он заметно уступал.

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

Поначалу мне даже показалось, что это такой хитрый способ ведения бизнеса: купит клиент продукт, попробует его установить, ничего у него не получится и вот тут-то разработчики и предложат ему дополнительные услуги — мол, неквалифицированный у вас персонал… Но все оказалось намного проще — продукт некому было тестировать и документировать. А если бы было кому, то, надо полагать, его цена не оказалась бы столь низкой. Приемлемое качество продукта требует затрат определенных ресурсов в процессе его производства, а вот их-то и не было.

К сожалению, многие российские заказчики рассматривают внедрение того или иного программного обеспечения лишь с точки зрения затрат на его приобретение, не задумываясь о том, в какую сумму обойдутся его установка, сопровождение, обновление. В этом плане упомянутый продукт, естественно, имеет преимущества перед аналогичным продуктом Microsoft. Но каковы должны быть требования к персоналу компании-заказчика, который, устанавливая продукт, должен уметь исправлять ошибки в скриптах для SQL Server, каковы должны быть зарплаты специалистов, удовлетворяющих этим требованиям, и какими будут убытки магазина, возникшие из-за простоя данного программного обеспечения по причине ошибки, не выявленной в ходе разработки? Такие вопросы обычно задаются уже после приобретения — а затем начинаются те самые дополнительные затраты и убытки, которые делают совокупную стоимость владения такой разработкой запредельно высокой…

Что могло бы стать альтернативой подобному недорогому продукту? Как минимум, внедрение того же Microsoft Commerce Server. Да, цена его приобретения высока по сравнению с упомянутым выше российским продуктом, но и он сам, и прилагаемые к нему готовые решения на его основе уже протестированы достаточно тщательно, а требования к персоналу и к затратам его рабочего времени, равно как и убытки, связанные с простоем магазина, в случае его приобретения окажутся намного ниже.

Интранет-сайт или корпоративный портал?

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

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

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

А многим ли разработчикам интранет-сайтов и руководителям IT-подразделений известно, что стандартную функциональность корпоративного интранет-сайта можно получить практически бесплатно в составе Windows Server 2003, просто настроив службы SharePoint Services? У меня есть серьезные основания полагать, что немногим. И уж точно мало кто догадывается о том, что этот продукт существует аж с 2001 года и входит в состав некоторых версий Office XP (и, право слово, наш журнал об этом писал не один раз!). Не буду идеализировать этот продукт, но тем не менее отмечу, что сэкономить с его помощью многие человеко-месяцы написания и тестирования кода вполне возможно, особенно если потребности пользователей стандартны. Во многих случаях внедрение служб SharePoint Services может быть вполне удачной альтернативой как разработке своего интранет-сайта, так и приобретению дорогостоящего корпоративного портала.

Альтернативы для заказчиков и руководителей проектов

оворя о выборе технологий для решения той или иной задачи, не стоит уповать на то, что разработчик всегда сделает правильный выбор. Знания об альтернативах «бездумному» кодированию нужны всем, кто связан с решением задач автоматизации чего бы то ни было, — от руководителей проектов до IT-менеджеров компании-заказчика и специалистов по тестированию. Вполне очевидно, что время, потраченное на получение таких знаний, то есть на чтение компьютерных журналов, книг, обзоров и информационных материалов компаний — производителей программного обеспечения, многократно окупится хотя бы за счет того, что подобные знания помогут избежать реализации проекта, сама идея которого порочна в силу наличия более дешевых альтернатив.

КомпьютерПресс 9'2004