Забота о качестве - первоочередная задача разработчиков

Не сроки выпуска, а качество является важнейшим критерием при разработке ПО. Корпорация Microsoft стала активно проповедовать такой подход, объявив 29 ноября, что будет выпускать предварительные версии ОС Vista по мере достижения определенных качественных рубежей, а не по календарному графику.

Однако философия качества была сформулирована за неделю до этого во время организованной Лабораторией eWeek Labs дискуссии за круглым столом, посвященной обеспечению качества приложений на протяжении всего их жизненного цикла и способам его достижения. В обсуждении приняли участие представители компаний - производителей средств обеспечения качества, корпорации Microsoft - создателя платформы и инструментов, а также клиенты этих компаний.

Массовый выпуск продуктов с десятками функций побуждает разработчиков задавать такие критерии готовности ПО, как “90-процентная завершенность". Однако при более коротких сроках разработки становится затруднительно замаскировать дефект с помощью списка новых возможностей. “Я считаю итерации завершенными, когда продукт достигает определенного уровня качества. Это - ключевой элемент управления проектом", - заявил во время организованной Лабораторией eWeek Labs дискуссии Ян Мак-Лиод, старший вице-президент по продуктам компании Segue Software (Лексингтон, шт. Массачусетс).

Другие участники круглого стола согласились с Мак-Лиодом, что в списке целей разработчиков качество занимает верхнюю строчку, и подчеркнули, что слово “качество" подразумевает не только полное соответствие спецификациям, но и удовлетворение предъявляемых реальными пользователями требований, что гораздо шире.

Объем и характер гарантии качества (Quality Assurance, QA) еще больше расширяются, когда организации используют приобретенное ПО и сетевые сервисы как компоненты специализированных бизнес-приложений. “Мы все шире и шире применяем компонентную архитектуру. Это ведет к повышению уровня сложности приложений по мере того, как они становятся все более распределенными, все менее жестко связанными и все более подверженными изменениям со стороны создателей этих компонентов", - заявил Элдад Манив, вице-президент по управлению продуктами компании Identify Software (Нью-Йорк).

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

Создавая экосистему качества

“Мы руководствуемся концепцией, которую называем “полностью готовым инструментальным набором для полного жизненного цикла" (fully connected life-cycle tool bench)", - заявил Крис Мейстрик, директор по инжинирингу ПО компании Jewelry Television (Ноксвил, шт. Теннеси). Компания занимается распространением телепрограмм для конечных пользователей по телевизионным каналам и через Интернет. Прежде, до полного обновления в прошлом году, она называлась America’s Collectibles Network. “Мы сосредоточили свои усилия на интеграции, - сказал Мейстрик. - Инженер использует набор инструментов. Мы не хотим заставлять его на протяжении всего жизненного цикла ПО разыскивать необходимые инструменты где-то еще, поскольку это отвлекало бы его от решения собственных задач и делало его труд неэффективным".

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

Например, рассказал Мейстрик, “...мы используем Microsoft Project. Но мы не вводим в него информацию вручную, а принудительно закладываем в Project свои требования и автоматически получаем готовую схему. У нас каждая подпрограмма автоматически генерирует уведомления о необходимости внесения изменений, которые привязаны к исходному коду. Вот как у нас делается".

Результатом, говорит Мейстрик, является среда, где релевантная информация может доставляться его инженерам, которые могут быстро ее использовать. “Инженеры работают с Eclipse, - сказал он. - Им необходимо знать, какие требования предъявляются к этой технологии. Они могут захотеть познакомиться с результатами тестовых испытаний, которые не смог пройти продукт. Но в любом случае они хотят, чтобы все это предоставлялось им в рамках используемой ими среды".

Мак-Лиод из компании Segue сказал, что надеется дождаться более полной интеграции инструментов, применяемых в отрасли. “Качество пронизывает все элементы экосистемы - формулирование требований, разработку и управление тестированием, исправление дефектов, мониторинг и диагностику в процессе развертывания и работы. Обычно вы сталкиваетесь с интеграцией типа “точка - точка", обладающей известными проблемами контроля за конфигурацией интерфейсов, согласования формата данных, соглашения об общем репозитории, - отмечает он. - Имеется несколько инициатив, таких, как схема жизненного цикла приложения (application life-cycle framework project). Это сравнительно новый проект в рамках Eclipse, представляющий собой попытку стандартизировать интеграцию".

Мейстрик из Jewelry Television уверен, что его усилия принесут плоды: “Решение проблем качества ПО представляет собой значительные инвестиции стратегического характера для нашей компании. Оно диктуется потребностями бизнеса и возврата вложенных средств. В течение прошлого года мы убедились, что реализация подобных идей и концепций дает непосредственный результат. В компании этому уделяется внимание на самом высоком уровне".

Немногие отрасли смогли продемонстрировать столь же быстрый взлет, как телевизионный и онлайновый бизнес компании Мейстрика. Среди них - игорный бизнес в Лас-Вегасе. Компания Station Casinos (Лас-Вегас) является одним из главных игроков в этой области, где управляет десятком игорных заведений и гостиниц.

Игорному бизнесу требуется непрерывно создавать новые ощущения у клиентов. При этом он уделяет неослабное внимание обеспечению максимального времени работы при минимальных издержках. “Все, что мы предпринимаем для увеличения доходов, в основном связано с ИТ, - говорит вице-президент и CIO компании Station Casinos Маршал Эндрю. - Мы стремимся сократить жизненный цикл, пройти процесс QA, применять продукты там, где они помогут нам извлекать прибыль. Мы подыскиваем продукты, услуги и комплексные навыки, которые позволяют нам своевременно реагировать на требования рынка".

Эндрю прекрасно знает о сложившейся сегодня высокой доле затрат времени на QA. “Если создание программы занимает, например, шесть месяцев, то на QA обычно требуется три месяца. На QA приходится 50% времени, необходимого для программирования. Мы стремимся сократить период QA, не жертвуя качеством, применяя инструменты, которые уменьшают время QA, а в процессе QA выявляют дефектные фрагменты, которые мы можем вернуть программистам. Таким образом, им не приходится тратить дни или часы на обнаружение проблемы", - сказал он.

Эндрю привел пример из недавнего прошлого, когда система, с которой работают пользователи, рушилась каждый день, что существенно влияло на прибыль. Применив технологию AppSight Black Box компании Identify Software и поработав с техническим персоналом Microsoft, рассказал он, “...мы выявили несколько сценариев. Без этих инструментов мы искали бы их много недель. Я был настроен несколько скептически, но теперь я твердо в них верю".

Корпорация Microsoft (Редмонд, шт. Вашингтон) была представлена на конференции Сэмом Гакенхеймером, отвечающим за планирование групп продуктов Microsoft Visual Studio Team System и Microsoft Solutions Framework. Гакенхеймер подчеркнул, что для обеспечения качества приложения необходимо видеть весь процесс от начала до конца. По его словам, все начинается с дизайна: “Мы спрашиваем, что должен сделать архитектор в период работы над дизайном, чтобы увидеть, правильно ли определен дизайн приложения и учитывает ли оно такие возможности, как нарушение безопасности".

Менеджеры, управляющие процессом разработки, считает Гакенхеймер, должны понять, что большинство программистов не являются и никогда не станут экспертами по безопасности и что поэтому автоматический анализ потенциальных проблем безопасности должен включаться во все инструменты и процессы и присутствовать в них повсеместно. “Мы стремимся автоматически проверять код на предмет безопасности. Мы включили в состав Visual Studio Team System наши инструменты, разработанные для внутреннего использования, чтобы продемонстрировать приемы программирования, которые позволяют сократить количество проблем", - сказал он.

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

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

Гакенхеймер из Microsoft надеется справиться с ней двумя путями. “Мы тестируем фрагменты кода и отслеживаем прохождение программы через тестирование. В результате все разработчики могут видеть, что работает, а что нет, - сказал он. - Мы берем результаты проведенного тестирования - теста под нагрузкой, когда с приложением одновременно взаимодействует тысяча пользователей, - и предоставляем их в распоряжение разработчика для внесения изменений на возможно более раннем этапе".

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

Можно значительно сократить задержки и в процессе разработки, считает Гакенхеймер. “На этапе определения дизайна вы получаете возможность сразу проверить, будет ли работоспособен избранный вами способ создания распределенной системы. Это экономит массу времени в поэтапном процессе поиска ответов на вопросы вроде “Какой порт мне нужно открыть?", “Следует ли нам изменить процедуру аутентификации на данном сервере?". Такие проблемы не относятся собственно к программированию. Но здесь каждый слепой представляет себе ногу слона по-своему", - сказал он.

Более широкий выбор лучше интегрированных инструментов требует пересмотра роли разработчика и тестировщика, считает Андре Пино, руководитель службы маркетинга Segue Software. “Многие сохраняющиеся проблемы с качеством являются результатом разрозненных усилий по его обеспечению. Есть разработчики, тестирующие фрагменты кода, есть те, кто тестирует интерфейс пользователя и проводит функциональное тестирование, другие люди тестируют производительность. Проблема заключается в том, что гарантию качества нельзя разделить на части, хотя она зависит от многих людей и многих видов деятельности".

Коллега Пино из Segue Software, Маклиод, согласен с этим. Он сказал: “Поскольку разработчики проводят все больше тестов, тестировщикам, возможно, следует уделять больше внимания пользователям, вместо того чтобы просто проверять соответствие требованиям".

Поскольку производительность труда разработчика возрастает благодаря вложению средств в повышение качества, менеджерам предприятий следует потратить часть сэкономленных средств на то, чтобы лучше понимать и удовлетворять потребности пользователей. Инструменты повышения качества должны в определенном смысле рассматриваться как предоставляющие возможность такого более широкого подхода, а не как конечный пункт погони за качеством: “Я не видел ни одного инструмента, который позволил бы мне узнать, что в моих требованиях к программе содержится ошибка. Я не видел инструмента, который подсказал бы мне, каким образом необходимо изменить мои требования", - сказал Далим Хандейкер, менеджер расположенных в Торонто офисов компании CGI Group по производительности и настройке приложений для предприятий. CGI оказывает своим клиентам квалифицированные услуги.

Гакенхеймер из Microsoft согласен, что ключевые аспекты обеспечения качества требуют участия пользователей и готовности разработчиков отнестись к ним с пониманием и совершенствовать продукт: “Обычно требования к программам не охватывают такие вещи, как производительность и связанные с ней впечатления пользователей. Перечень требований не обязательно является наилучшим способом решения этих проблем".

Участники дискуссии согласились, что экономические вопросы качества приложений не урегулированы.

“Несколько лет назад было выпущено очень интересное исследование Национального института стандартов и технологий (National Institute of Standards and Technology), в котором изучался общий экономический эффект качества ПО, - сообщила Уиздо из Identify Software. - В этом докладе утверждалось, что целых 80% затрат на разработку ПО связано с исправлением дефектов. Решение данной проблемы имеет принципиальное значение".

Повышение производительности труда разработчика вместо простого наращивания человеко-часов - это принципиальный вывод, к которому пришел Эндрю из Station Casinos: “Мы обнаружили, что очень трудно найти опытных технических специалистов даже за пределами штата. Поэтому мы стремимся повышать эффективность с помощью более совершенных инструментов и более качественного обучения", - сказал он. Кроме того, сообщил он, инвестиции со временем амортизируются, а зарплаты ежемесячно отражаются в вашей декларации о доходах.

Говорить одновременно о технологии процесса и корпоративных финансах значит затрагивать еще один ключевой момент: соблюдение требований закона Сарбейнса - Оксли. “Необходимость последовательно обеспечивать качество и сделать процесс разработки прозрачным и поддающимся контролю создает ложное представление, будто прежде мы все делали неправильно, - заявил Мейстрик из Jewelry Television. - А теперь нам говорят, что впредь мы должны делать все по-хорошему. Но нам и самим это необходимо".

“Платформа, состоящая из продуктов нескольких производителей и многих версий продуктов, создает множество трудностей", - поделился наблюдением Хандейкер из CGI.

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

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

С редактором по вопросам ИТ Питером Коффи можно связаться по адресу:peter_coffee@ziffdavis.com.