КАЧЕСТВО
Качество современного программного обеспечения не устраивает сегодня никого. Возможно, этот постулат покажется вам чересчур категоричным, но как иначе объяснить тот факт, что бурные обсуждения очередных уязвимостей или неадекватной функциональности тех или иных продуктов вспыхивают с печальной регулярностью. Под огонь критики чаще всего попадает лидер отрасли - корпорация Microsoft: сейчас, к примеру, в центре внимания находятся проблемы, возникшие в связи с выпуском сервис-пакета Windows XP SP2. Пока что речь идет в основном не об ошибках, а о некорректном взаимодействии или конфликтах с уже эксплуатируемым прикладным и системном ПО, причем среди конфликтующих оказались и собственные продукты Microsoft (Visual Studio .Net, Operations Manager, SQL Server и Systems Management Server). На самом деле подобные и многие другие проблемы свойственны всей софтверной отрасли, а потому давайте уберем удобную мишень Microsoft и обратимся к относительно недавней истории.
Пробный шар
В начале 2002 г. консалтинговая компания AMR Research (www.amrresearch.com) выпустила своеобразный манифест Enterprise Commerce Management (ECM) Vendor Expectations and Software Bill of Rights (www.amrresearch.com/AboutUs/Services/ECM/FinalVED.pdf), выработанный и одобренный представителями тридцати фирм (и потребителей, и поставщиков ПО) из списка Fortune 1000. Акцент в нем был сделан не на способах повышения качества ПО, технологиях тестирования программ и процедурах сертификации по ISO 9000 или CMM, а на тех требованиях к ПО и вендорам, которые кажутся наиболее важными для пользователей. Требования эти, сформулированные в главе "Билль о правах пользователей ПО" (Software Bill of Rights), сразу получили горячее одобрение многих субъектов рынка, но спустя короткое время уже мало кем вспоминались. А поскольку манифест предполагал добровольное одобрение и принятие обязательств следовать его основным положениям, то забвение оказалось лучшим способом уйти от весьма обременительных обещаний.
Понимая, что билль не может быть слишком пространным, авторы ограничились шестью пунктами, упомянув, что устанавливаемые в них требования следует рассматривать как минимальные. Впоследствии, как считали учредители, поставщик программных продуктов мог бы простуказывать свою приверженность положениям данного документа и облегчать тем самым выбор покупателя. Итак, вот какие права пользователей ПО предлагалось добровольно соблюдать вендорам.
1. Право на ПО хорошего качества. Клиент должен получать продукт, не содержащий ошибок, в момент выпуска коммерческой версии. Речь идет о тщательном тестировании ПО самим вендором, а не о перекладывании этой работы на плечи пользователей и последующей публикации многочисленных заплаток. Разработчик должен полностью раскрывать используемые им стандарты контроля качества, предавая гласности методики тестирования и применяемые метрики. Кроме того, он обязан принимать участие в программах по независимой оценке удовлетворенности его клиентов.
2. Право на соблюдение сроков выпуска новых версий. Если чересчур частые апгрейды приводят к нарушениям обещанных сроков, следует удлинить циклы обновления. Наряду с соблюдением обещаний по выпуску очередных версий вендор обязан предоставлять пользователю планы стратегического развития продуктовой линейки на более длительный период. Если же в силу тех или иных причин сроки срываются либо меняется стратегия развития продукта, поставщик должен оповещать об этом клиента заблаговременно.
3. Право на четкое ценообразование. Оно должно строиться не с целью повышения доходов вендора, а для точного удовлетворения насущных потребностей покупателя. В структуре цены следует разделить стоимостлицензии, сопровождения, технической поддержки, поставки новых версий и апгрейдов, причем клиент должен иметь возможность приобретать каждую такую услугу отдельно. Наряду с прайс-листом пользователь вправе получать от вендора расчеты совокупной стоимости владения как на текущий период, так и на более отдаленную перспективу. Помимо продажи в бессрочное пользование желательно иметь альтернативные схемы лицензирования (подписка, аренда и т. д.).
4. Право на получение детальной отчетности по затратам на разработку. Это странное на первый взгляд положение призвано удовлетворить любопытство тех клиентов, которые платят за техподдержку и сопровождение, но хотели бы убедиться в том, что их средства идут не на разработку новых модулей (которые потом им придется покупать за свои же деньги), а нсовершенствование функциональности существующих.
5. Право на эффективную техническую поддержку. Ее следует предоставлять согласно четко сформулированным соглашениям по уровням обслуживания (SLA) и с учетом потенциальной серьезности ущерба от тех или иных инцидентов. Клиент должен иметь возможность сам устанавливать уровни критичности возникающих проблем, формулировать логику процедур последовательного подключения служб поддержки с указанием телефонов и иных координат для общения с каждой из них. Вендор должен оказывать поддержку не менее четырех лет с момента выпуска коммерческой версии продукта, а по истечении этого срока обязан опубликовать условия поддержки по специальной цене.
6. Право на получение полной информации. Речь идет о сведениях, перечисленных в предыдущих пунктах, а также об общей бизнес-практике вендора. Обычно клиенты неохотно делятся с общественностью негативными впечатлениями о продукте или услуге, опасаясь юридического преследования со стороны вендора. Билль объявляет такую практику неприемлемой и призывает поставщиков не навязывать заказчикам такого рода соглашения о неразглашении. AMR Research предложила публиковать подобную информацию на своем сайте в формате, который должен был разработать специальный консультативный совет. Прошло уже более двух лет и, как это ни печально, ни самого формата, ни соответствующих ему публикаций на сайте AMR так и не появилось.
Вспомним о рядовом пользователе
Инициатива, о которой шла речь выше, относилась главным образом к мощным бизнес-приложениям, но понятно, что аналогичные проблемы испытывают и потребители продуктов персонального назначения. Не удивительно, что другими людьми стали выдвигаться схожие программы под тем же эффектным слоганом "билля о правах". Автор одной из них (www.princeton.edu/~rcurtis/softrights.html) - Рик Кертис из Принстонского университета - пишет: "Мы регулярно щелкаем на кнопке "Я согласен", стоящей под лицензионными соглашениями End User License Agreements, в которых софтверные компании, оперируя юридическим жаргоном, многословно разъясняют, каким образом они в любой ситуации не несут никакой ответственности за собственные продукты".
Билль Рика Кертиса во многом повторяет базовые положения документа AMR Research, но при этом детализирует многие из них. Так, по его мнению, вендоры должны добровольно взять на себя ряд конкретных обязательств. Новая версия программы обязана открывать все файлы, созданные предыдущей, а если апгрейды следуют чаще, чем раз в год, то и еще более ранней. Новые функции должны быть тщательно документированы, особенно если они каким-то образом повлияли на существовавшие прежде. Если некая функция исчезает из продукта, следует объяснить, как ее можно реализовать альтернативными способами и как она должна быть исключена из построенного клиентом специализированного решения, чтобы при этом не нарушалась работа такого решения. Конечно, компания вправе прекратить развитие программного продукта, но тогда она обязана в течение 24 месяцев после обнародования подобного решения обеспечить бесплатную поддержку и выпуск заплаток и технических обновлений. Если вместо снятого с производства будет выпускаться другой продукт, то клиенты, купившие старое ПО менее чем за полгода до объявления нового, должны получить такой продукт бесплатно.
О серьезности проблем качества в отрасли как нельзя лучше свидетельствует интерпретация права на получение ПО без ошибок, данная Кертисом. Он призывает вендоров снабжать релизы своих продуктов полным документированным перечнем замеченных ошибок! Билль лишь смиренно призывает разработчиков оперативно выпускать к ним бесплатные заплаткиБольшинство производителей антивирусных средств делает это уже по нескольку раз в день, но здесь хоть есть внешняя причина - вирусописательство. Впрочем, новые вирусы зачастую используют неизвестные доселе бреши в ОС или приложениях, а потому антивирусные заплатки приходится дополнять аналогичными конструкциями для других программ. Кажется, мы приближаемся к тому, что каждое обновление ПО или укрепление оборонных редутов будет вызывать цепную реакцию апгрейдов, производимых в реальном времени. И хотя технологически такие операции вполне осуществимы (они уже применяются), не следует забывать о естественных ограничениях, которые могут сделать подобные технологии просто бесполезными. Недавно организация SANS Institute (www.sans.org) обнародовала результаты своих исследований, из коих следует, что в среднем незащищенный ПК с коммутируемым доступом в Интернет продержится под натиском зловредных программ не более 16 минут (еще в прошлом году среднее "время жизни" составляло 40 минут). Иными словами, машина пользователя может оказаться под несанкционированным внешним контролем раньше, чем на нее будет установлена соответствующая заплатка.
Новые инструменты
Проблема качества ПО возникла не сегодня, решают ее уже не одно десятилетие, но настоящего успеха на этом направлении нет. А ведь практически все крупные разработчики применяют изощренные средства автоматизированного тестирования ПО - тестирования функционального, регрессионного, интеграционного, стрессового, нагрузочного и т. д. Возможно, правы те, кто считает, что подобные инструменты в принципе не могут гарантировать безошибочность программ, поскольку проверяют их работоспособность на ограниченном наборе контрольных примеров, построенных на основе технических требований. Один из пунктов билля Рика Кертиса требует, в частности, чтобы развертывание одного продукта не приводило к проблемам при исполнении другого или к зависанию ОС. Как можно гарантировать это на стадии тестирования, если разработчик попросту не знает, какие еще приложения будут установлены на машине пользователя и какие "косметические" изменения внесет в операционную систему ее производитель?
В последние годы большие надежды возлагаются на так называемые средства статической проверки исходного кода (static source code checkers), предлагаемые небольшими фирмами Fortify Software (www.fortifysoftware.com)Reflective (www.reflectivecorp.com), Coverity (http://Fcoverity.com) и Ounce Labs (www.ouncelabs.com). Любопытно, что одна из таких фирм - Intrinsa - была приобретена корпорацией Microsoft за 60 млн. долл. еще в 1999 г. Они проверяют исходный код, не зная ничего о логике программы и ее функциях, с целью обнаружения фрагментов, могущих стать причиной тех или иных проблем (к примеру, типичной ошибки переполнения буфера). Инструменты эти создаются выходцами из академической и университетской среды, которые пытаются реализовать сформулированные там принципы "правильного программирования". Профессор Дэвид Эванс, работающий сегодня в Reflective, считает, что со временем подобные инструменты будут включаться в состав компиляторов. Во всяком случае вендору трудно будет объяснить своему заказчику, почему при наличии инструментов такого рода приложение работает некорректно. "Странно, что до сих пор люди пишут коды, приводящие к переполнению буфера", - возмущается он.
Некоторые эксперты считают, что не все здесь так просто. Подобные инструменты обнаруживают не ошибки, а подозрительные куски кода. Нередко большая часть "находок" - вполне доброкачественная продукция, но проверка кода и вынесение решения по его дальнейшей судьбе требуют столь значительных усилий, что в условиях промышленной разработки такая технология оказывается неприемлемой.
Еще одна, весьма своеобразная разновидность средств тестирования появилась сравнительно недавно в связи с исками компании SCO Group к разработчикам ОС Linux и ее пользователям (в основном корпоративным). В этих исках утверждается, что часть открытого исходного кода Linux без какого-либо разрешения взята из принадлежащего SCO диалекта операционной системы Unix. Представители SCO выступили с предупреждением, адресованным как дистрибьюторам Linux, так и пользователям, пообещав судебное преследование и тем и другим (последние по сути обвиняются в скупке краденого). Чем бы ни кончились эти события, предприятия, применяющие ПО с открытым кодом, поняли, что при всех его достоинствах у них всегда есть риск быть втянутыми в юридические баталии по поводу авторских прав. Рынок среагировал мгновенно, и на нем появились инструменты для проверки исходного кода на чистоту в смысле копирайта.
Добровольно или по закону?
Юридические вопросы, казалось бы, не имеют отношения к документам, подобным "биллю о правах", предлагающим вендорам принять те или иные нормы в добровольном порядке. Тем не менее еще один билль с аналогичным названием, предложенный Симом Канером (http://blackbox.cs.fit.edu/blog/kaner), призывает как раз к пересмотру ряда устоявшихся юридических норм, нарушающих, по его мнению, права потребителей ПО. Один из пунктов билля Канера ставит под сомнение своеобразную священную корову - право вендора запрещать дизассемблирование и обратное проектирование (reverse engineering) своих продуктов. Вендоры обычно говорят, что такая норма защищает их от кражи интеллектуальной собственности. Однако обратное проектирование применяется и для множества других полезных и законных целей: выявления брешей в системе безопасности, обнаружения ошибок (и исправления их, если разработчик не способен сделать это, например, из-за собственного банкротства), обеспечения взаимодействия с другими программными или аппаратными средствами, выявления случаев нарушения авторского права.
Еще одна традиция, с которой на массовом рынке ПО все уже смирились, - обеспечение доступа к лицензионному соглашению лишь после покупки продукта. И хотя всегда есть возможность вернуть в конечном итоге коробку или диск и получить назад свои деньги, процедура эта довольно сложна и неудобна для потребителя. Более того, он лишен возможности сравнить лицензионные или гарантийные соглашения по конкурирующим продуктам, прежде чем сделать выбор в пользу одного из них. По американским законапокупатель любого другого товара стоимостью выше 15 долл. имеет право ознакомиться с условиями контракта до оплаты сделки.
Важное требование, выдвигаемое Канером, обязывает производителя ПО гарантировать, что передача любой информации с компьютера пользователя должна быть им лично санкционирована явным образом. Причем перед ее отправкой в Сеть пользователь должен иметь возможность просмотреть информацию (а если она была зашифрована, то предварительно расшифровать ее). Наверное, это требование очень сложно выполнить, но включение его в условия контракта будет материально стимулироватразработчика перекрыть все лазейки, с помощью которых шпионские программы похищают пароли, номера кредитных карт и прочие конфиденциальные данные.
Удивление у автора билля вызывает и декларируемый во многих лицензионных соглашениях запрет на публичное обсуждение недостатков приобретенной программы, сравнение ее с конкурирующими продуктами и распространение скриншотов, иллюстрирующих подобные сопоставления. Такая практика противоречит базовым положениям закона об авторском праве, разрешающим репродуцировать фрагменты произведений с целью критикиобсуждения, извлечения уроков и по сути гарантирующим свободу слова. А как можно с позиций прав потребителя толковать запрет на перепродажу, дарение, сдачу в аренду или на любую иную форму смены собственника прикладной программы? Ведь купив книгу или автомобиль, вы имеете право распоряжаться им по своему усмотрению, без каких либо ограничений!
За что платит потребитель услуги
Последняя претензия имеет смысл лишь в случае приобретения бессрочной лицензии на ПО. Сегодня же все чаще и вендоры, и клиенты склоняются к модели лицензирования по подписке. Как констатирует в своем недавнем исследовании "The future of software licensing: software licensing under siege" (Будущее лицензирования ПО: лицензирование в осаде") аналитическая компания IDC, стагнация на софтверном рынке стимулирует поиск новых методов лицензирования. Если сегодня подписка приносит вендорам лишь 25% доходов, то уже через два-три года эта величина достигнет отметки 50%. Производителям ПО такая схема позволяет более уверенно прогнозировать свои финансовые поступления, а клиентам - избегать крупных единовременных выплат и представлять в финансовой отчетности расходы на ПО более приемлемым для себя образом.
Есть и другая объективная причина подобной смены лицензионной политики. Все большее распространение получают идеи виртуализации, динамического выделения ресурсов, вычислений как коммунальной услуги и, в частности, предоставления программы в виде сервиса. Думается, именно переход на сервисную модель заставит отрасль вновь вернуться к инициативам, подобным "биллю о правах". Ведь если раньше клиент покупал ПО так же, как он приобретает производственное оборудование, полностью отвечая впоследствии за его эксплуатацию, то теперь он подписывается на вполне конкретную услугу. Согласитесь, утверждать в лицензионном соглашении, что разработчик не несет ответственности за возможные ошибки, в данном случае ему будет гораздо сложнее: иначе непонятно, за что вообще платит заказчик услуги.
Мы затронули лишь небольшую часть проблем, связанных с качеством ПО. Тема эта, судя по всему, очень актуальна и для поставщиков тиражируемых решений, и для разработчиков заказных систем, и конечно же для потребителей, как индивидуальных, так и корпоративных. Хотелось бы пригласить все заинтересованные стороны к ее обсуждению на страницах нашего издания.
