Статья только в электронной версии журнала
Питер Коффи (PC Week Labs)
Microsoft реагирует на претензии, предъявляемые к дефектам ее продуктов и программных “заплат”; независимые поставщики озабочены проблемами открытости платформ
Недавно избранный президент корпорации Microsoft Стив Балмер направил жесткое обращение к персоналу своей компании. Он признал тот факт, что в продуктах Microsoft слишком много ошибок, и заявил, что компания обязана приумножить свои усилия в отношении гарантий высокого качества.
Корпоративные пользователи задаются естественным вопросом: что же мешало компании делать это раньше?
ИТ-менеджеры отмечают, что качество коммерческого ПО для персональных компьютеров за последние годы заметно упало. Неуклонно растет количество сообщений об ошибках, которые посылаются на узлы типа BugNet (www.bugnet.com), отслеживающие данные о дефектах ПО (рис. 1).
Рис. 1. Ошибок становится все больше
“С каждым следующим поколением Windows все большая часть ошибок остается неисправленной”, - утверждает Брюс Браун, издатель сайта BugNet.
Проблема качества ПО связана со многими обстоятельствами - усложнением продуктов, нетерпеливым желанием производителей поскорее выпустить новый продукт, ростом пользовательских ожиданий. Но в конечном счете все сводится к одному: сталкиваясь с проблемами, компании теряют свое время и деньги.
Последствия низкого качества ПО многократно возрастают, когда оно установлено на большом числе ПК. По данным Кема Кейнера, специалиста по качеству программных продуктов из Санта-Клары (шт. Калифорния), пользователи США ежегодно теряют порядка 5 млн. рабочих дней из-за плохого дизайна ПО, невразумительной документации и фактических ошибок в программах. Это явствует из статистики, согласно которой ежегодно регистрируется около 200 млн. обращений за технической поддержкой при среднем времени консультации 12 минут. Помимо этого пользователи тратят время на изучение технических руководств и чтение учебной литературы, пытаясь разобраться в премудростях, нередко связанных с плохой разработкой.
Поэтому неудивительно, что ИТ-менеджеры начинают пристально следить за качеством продукции своих поставщиков и требовать от производителей полного устранения ошибок.
Web умножает ошибки
Одной из главных причин, способствующих росту числа дефектов ПО, является его распространение в Web. С помощью Сети ИТ-менеджеры могут практически мгновенно и без каких-либо затрат обновлять используемое ПО. Однако это ведет к снижению ответственности его изготовителей (ISV). Многие производители поддаются соблазну выпускать недоработанные версии, вслед за которыми создаются вспомогательные пакеты (service pack), расширяющие возможности и исправляющие ошибки этих версий.
Нередко сами корректирующие пакеты порождают новые ошибки. Достаточно упомянуть недавно выпущенный Microsoft сервисный пакет для Office 97, который помимо прочего предназначен для устранения ряда дефектов в Excel. Этот пакет исправляет одни ошибки, но при этом создает другие.
Имея дело с сервисными пакетами и промежуточными апгрейдами, ИТ-менеджеры неизбежно сталкиваются с необходимостью принимать сложные решения. Нередко думают так: “Раз эта вещь работает, зачем ее исправлять? Подождем пару недель и посмотрим, что нам сообщит BugNet или другой подобный сайт”. С другой стороны, промедление может быть чревато неприятностями (скажем, если у продукта найдена “дыра” в защите, а сервисный пакет позволяет ее устранить).
ИТ-менеджерам следует при любой модернизации ПО начинать с запуска пробных программ. Это позволяет изолировать многие возможные ошибки и предотвратить их неприятные последствия.
В ряде крупных организаций, где имеются собственные сильные разработчики, например в Los Alamos National Laboratories, предпочитают поддерживать обратные связи с поставщиком ПО начиная с самых ранних стадий его работы над продуктом.
Чем дальше заходит цикл разработки ПО, тем труднее воздействовать на дизайн и качество создаваемого продукта и тем дороже обходятся его исправления (рис. 2). Так, решив эти вопросы на этапе формулировки исходных требований, вы заплатите как минимум на 99% меньше, чем в том случае, когда использование ПО уже началось.
Рис. 2. Убейте их в самом начале, не то они съедят ваши деньги
Получая новое ПО, сотрудники ИТ-отдела могут воспользоваться средствами тестирования типа BoundsChecker фирмы NuMega Technologies, которые помогают выявить некоторые проблемы, не используя исходного кода продукта.
ИТ-организации вправе потребовать от внешних разработчиков, чтобы они пользовались подобными средствами, и связать объективные оценки качества с материальной заинтересованностью подрядчиков.
Другой причиной увеличения количества ошибок является усложнение настольных приложений, из-за чего ISV становится все труднее тестировать свои продукты. Эти сложности во многом связаны с деятельностью Microsoft и ее стремлением обеспечить взаимодействие между изначально независимыми продуктами, функционирующими в среде Windows.
Теоретически все это должно было бы радовать пользователей, поскольку в такой ситуации повышается планка требований к качеству ПО и усиливается рыночная конкуренция между разработчиками приложений, создающими новые продукты на общей разделяемой платформе Microsoft Windows.
Однако на практике все обстоит по-другому.
Конкурирующие производители приложений сходятся во мнении, что базовые программные продукты, которые Microsoft объявляет “открытыми” и документированными, на самом деле открыты лишь для свободной интерпретации: как правило, разработчикам нельзя обойтись без точного знания всех особенностей внутренней технологии Windows.
Больше платформ - больше проблем.
Представители ряда ISV отмечали в своих беседах с сотрудниками Тестового центра PC Week Labs, что им действительно становится все труднее создавать высококачественные продукты для разрастающегося семейства Windows-платформ.
“Когда все нужно приводить к одному знаменателю, получается наихудший результат, - пожаловался один из них при обсуждении трудностей написания приложений для Windows CE. - Разные процессоры имеют разные правила выравнивания операндов. Программист должен поддерживать порядок на таком уровне детальности, который не поддается контролю в рамках Си++, т. е. фактически работать на уровне машинного кода. А это увеличивает сложность программ и затрудняет их тестирование”. (Никто их опрошенных сотрудниками PC Week Labs разработчиков не захотел делать заявлений для печати. Многие связывали это с нежеланием потерять право на ранний доступ к технической информации Microsoft.)
Рост числа дефектов ПО для ПК воздействует на пользовательские настроения. Сегодня средний пользователь далеко не всегда спешит приобрести все, что ему предлагают: у него есть опыт знакомства с “прелестями” незрелых продуктов.
Поскольку ПК становятся разновидностью бытовой техники, рядовой пользователь все больше ждет от ПО интуитивно понятного интерфейса и четкого функционирования. Когда оно не удовлетворяет этим запросам, компании терпят серьезные убытки из-за того, что их сотрудникам приходится тратить время в учебных классах или простаивать в ожидании технической помощи поставщика.
Одновременно эволюционируют формы работы с настольными приложениями - вместо коротких рабочих сессий их все чаще используют в течение целого рабочего дня, а иногда даже круглосуточно. Вместо стандартных сеансов запуска приложения для создания или редактирования документа и последующего выхода из программы пользователи теперь, как правило, на весь рабочий день запускают индивидуально настроенное приложение. Поэтому такие скрытые дефекты, как накапливающийся недостаток памяти или других ресурсов, все чаще проявляются и становятся явной помехой в работе. Независимо от платформы, будь то Windows CE или Windows NT, теперь проявились целые классы дефектов, которые прежде, при кратковременных сеансах работы с настольным ПО, могли оставаться незамеченными.
Учитывая изменение стиля работы пользователей, повышение требований со стороны среды, в которой запускаются приложения, а также коммерческие мотивы, способствующие выпуску второсортного ПО, вряд ли нужно удивляться, что отрасль программирования для ПК в конечном счете оказалась в состоянии кризиса.
Смогут ли Microsoft и другие поставщики противостоять нарастающему валу программных дефектов? По крайней мере в краткосрочной перспективе это далеко не просто. Проблема качества в корне отличается от иных вызовов, например внезапного появления Интернета, которые приходилось принимать разработчикам в прошлом. Качество - не функция, добавляемая к уже существующему продукту. Борьба за высокое качество - это длительный процесс, начинающийся с создания проекта и продолжающийся еще долгое время после продажи продукта пользователям.
Любые усилия, направленные на повышение качества ПО, неизбежно затрагивают проблемы управления коллективом разработчиков. Microsoft должна внести существенные изменения в базовые процессы создания ПО, и это испытание может оказаться для компании более тяжелым, чем все, что случалось в ее жизни прежде. Чтобы достичь нужного уровня качества, группы разработчиков Microsoft и других ISV нуждаются прежде всего в крепком руководстве.
Корпоративным пользователям недостаточно лишь подсчитывать количество дефектов и воздействовать на производителей, требуя от них улучшений. Они вполне могут рассматривать ПО не только как продукт, но и как определенный вид услуги. Это значит, что поставщики корпоративного ПО должны быть вовлечены в непрерывный диалог с пользователями, а производственные интересы должны все время, а не от случая к случаю влиять на деятельность разработчиков.
Но и этого мало. Корпоративные пользователи должны поддерживать движение за открытость исходного кода, поскольку в таком случае ИТ-менеджерам будет проще устанавливать собственные приоритеты в отношении проблем ПО.
ИТ-менеджеры, ориентирующиеся на высокое качество, постепенно могли бы отходить от Windows в направлении более управляемых и централизованных архитектур. Это могут быть архитектуры, основанные на технологиях Java (этот язык порождает меньше ошибок по сравнению с Си или Си++), Jini фирмы Sun Microsystems или серверов приложений и баз данных типа Oracle8i.
Несомненно, основную угрозу несут в себе сетевые продукты, и это может побудить ведущих производителей сетевого ПО последовать примеру Балмера и наставить своих разработчиков на путь решительной борьбы с ошибками.
