Управление качеством программного обеспечения становится особенно важным направлением работы ИТ‑департаментов в условиях современного постоянно изменяющегося бизнеса. Что необходимо предпринять, чтобы качество информационных систем, а также процессов их разработки и передачи в промышленную эксплуатацию соответствовало требованиям бизнеса? Intelligent Enterprise беседует с начальником отдела тестирования компании «ЛУКОЙЛ-ИНФОРМ» Виктором Ематиным.
Intelligent Enterprise: Какими параметрами, с вашей точки зрения, можно описать степень качества программного обеспечения?
Виктор Ематин: Неверно было бы утверждать, что в нашей профессиональной деятельности мы сталкиваемся лишь с программным обеспечением. Мы взаимодействуем не с абстрактным ПО, а с конкретными информационными системами, представляющими собой совокупность программного обеспечения и программно-аппаратных средств. Я отмечаю это различие, потому что для технических специалистов, к которым я отношу себя, это действительно важно. Программное обеспечение не ассоциируется для нас только лишь с параметрами, характеризующими его функциональное назначение, как это часто представляет себя заказчик. Для нас имеет смысл более богатый спектр характеристик и нюансов поведения систем.
Что же касается определения уровня качества, то для решения этой задачи мы используем целый ряд подходов, наиболее общим среди которых является идеология стандартов серии ISO. В соответствии с этим подходом качество системы складывается из двух слагаемых — качества продукта и качества процесса его создания и сопровождения. Методический подход с использованием различных инструментов поддержки разработки как раз позволяет соединить эти два условия получения качественного результата. Другими словами, применяя их, мы так или иначе вынуждены придерживаться определенных и уже доказавших свою эффективность процессов, а функциональная мощь инструмента дает возможность создавать код, не содержащий ошибок, то есть качественный программный продукт.
Для проверки требования заказчика мы проводим функциональное и нагрузочное тестирование — выполнение определенных задач с использованием программного продукта в конкретной информационной среде заказчика. В ходе тестирования мы выявляем отличия полученных результатов от зафиксированных в требованиях или ожидаемых характеристик исходя из предшествующего опыта использования аналогичных систем.
Сами характеристики могут быть связаны с функциональностью ПО, с его производительностью, с отсутствием уязвимостей с точки зрения информационной безопасности и т. д. Но стоит отметить, что составить какой‑то универсальный список характеристик качества, заранее удовлетворяющий всем пожеланиям, пожалуй, невозможно. Его нужно каждый раз формировать заново в соответствии с индивидуальными пожеланиями заказчика, конфигурацией имеющихся у него систем и другими факторами. Это, конечно, не искусство, а ремесло, но с элементами творчества. Ведь в каждом конкретном случае тестирование должно выполняться в соответствии с индивидуальным сценарием.
Как сделать, чтобы прикладное или системное ПО точно соответствовало функциональным требованиям заказчика?
Начнем с рассмотрения формальной стороны процесса. Работа с заказчиком представляет собой формирование договорных отношений по принципу «решение заказчика означает закон для исполнителя». В заключаемом договоре прописываются SLA, в соответствии с которыми заказчик принимает систему. Этим требованиям система должна удовлетворять на протяжении всего периода эксплуатации. Как же можно достичь этого? Нами используются стандартные и проверенные на практике методы и подходы к сопровождению систем. Например, при разработке, сопровождении и внедрении систем мы используем известную концепцию жизненного цикла ПО. Много внимания мы уделяем обучению специалистов, так как их работа вносит существенный вклад в процесс создания систем, а квалификация почти всегда отражает качество создаваемого продукта.
Мы применяем самые передовые инструменты не только для повышения эффективности работ, непосредственно связанных с созданием ПО, но и для обеспечения тщательного тестирования, скрупулезной проверки и функциональных параметров, и таких характеристик, как, например, масштабирование или производительность систем до их внедрения у заказчика. Надо сказать, что очень часто соответствие функциональных характеристик системы тому, что реально заказано бизнесом, поглощает все внимание разработчиков, и на такие важнейшие вещи, как масштабирование ПО, этого внимания просто не остается.
Что касается методической стороны работы, хочу отметить, что мы работаем в соответствии с моделью CMM (модель степени зрелости) и, по нашим оценкам, уже перешли примерно со второго на третий уровень ее зрелости. То есть согласно CMM из повторяемой модели мы перешли на установленную или определенную. Мы развили такие дисциплины, как автоматизация тестирования на базе инструментов HP (прежде всего Quality Center, затем HP LoadRunner, HP QTP), управление запросами с использованием инструмента JIRA от Atlassian. Благодаря системе SubVersion мы осуществляем управление версиями, с помощью продуктов Microsoft SharePoint и Word документируем системы. Хочу также отметить, что у нас есть Wiki‑система Confluence от Atlassian, на базе которой имеется возможность организовывать богатую Web‑среду взаимодействия разработчиков в ходе проекта.
Особо хотел бы выделить продукты HP, поскольку этими инструментами поддерживается очень широкий спектр технологических платформ. HP предоставляет очень квалифицированную техподдержку. К тому же HP является одним из стратегических партнеров «ЛУКОЙЛ-ИНФОРМ».
Таким образом, сейчас мы обладаем достаточно внушительным портфелем инструментов, позволяющим автоматизировать многие процессы разработки и эксплуатации информационных систем. Под каждую бизнес-задачу, для каждого проекта формируется свой набор характеристик качества ПО, подтягивается и индивидуальная конфигурация инструментария, призванная обеспечить достижение требуемых характеристик качества для заказанной бизнесом системы.
Для приемки систем, разработанных сторонними организациями, мы используем так называемые шаблоны программ и методик испытаний (ПМИ), которые были нами разработаны в соответствии с ГОСТами и нашими потребностями. Постепенно мы приходим ко все более формальной процедуре приемки. Наши подрядчики перенимают этот опыт, приводя свои планы тестирования, документацию и отчетность в соответствие с нашими требованиями.
Как можно оценить качество пользовательского интерфейса и документирования? Дело в том, что эти характеристики ПО, по сути, очень субъективны. Даже в случае удачных и методически грамотных разработок разные пользователи иногда выносят далеко не одинаковые суждения о качестве как интерфейса, так и документации на систему…
Действительно, важность документирования и пользовательского интерфейса сложно переоценить. В моем представлении они занимают следующее место после функциональности системы и характеристик ее производительности.
Но этот вопрос сопряжен с рядом нюансов. Для начала мне бы хотелось отметить универсальные особенности некоего «обобщенного» корпоративного пользователя, которые я для себя выделяю. Пожалуй, наиболее существенно то, что корпоративный пользователь достаточно дисциплинирован и ограничен в выборе. Такой сотрудник обычно обладает более чем ограниченными возможностями кастомизации пользовательского интерфейса, и это совершенно оправданно. В ряде случаев он даже не может поменять расположение тех или иных значков и иконок, сменить цвета оформления и как‑то изменить дизайн. Ему приходится использовать уже готовый продукт. Быстродействие, красота интерфейса и его соответствие последним модным тенденциям, столь типичные и востребованные качества при работе в Интернете и с некоторыми широко используемыми (в том числе отнюдь не для делового применения) офисными продуктами, занимают далеко не первые места в шкале приоритетов классического корпоративного пользователя.
Однако такая непритязательность бизнес-пользователя не свидетельствует о том, что мы не должны тестировать и классифицировать ПО по данным параметрам и оценивать качество этих параметров. Для этого, разумеется, необходимо учитывать и отраслевой опыт, и мировые тенденции. По уровню производительности интерфейса (пожалуй, наиболее объективный параметр его качества) нам следует приближаться к типовым современным решениям.
Что же касается каких‑то отличительных особенностей пользовательских интерфейсов в корпоративных системах, то, наверное, сегодня мы наблюдаем постепенное эволюционное сближение как продуктов, так и системных интерфейсов если не по корпоративному рынку в целом, то точно внутри определенных отраслей. Например, ERP, BW, системы документооборота. В отношении пользовательской документации я хочу высказать в чем‑то провокационную мысль. Я полагаю, что мы наблюдаем постепенное отмирание электронной документации, а уж ее бумажного эквивалента — тем более. Это связано с совокупностью нескольких факторов. Интерфейс с каждой новой версией становится все более интуитивно понятным, и уровень пользователей с каждым годом растет. Этому способствует широкое распространение компьютеров, уроки информатики в школе, поголовное использование Интернета и другие характерные черты нынешнего информационного общества. В результате современный пользователь гораздо быстрее вникает в систему и начинает с ней работать. Ему больше не требуются специальные курсы, тренинги и учебные материалы, как это было еще несколько лет назад. Эта тенденция характерна для всего общества в целом, и она также достаточно явственно прослеживается в корпоративном сегменте.
Однако я ни в коей мере не хочу умалять важности документации и интерфейса на сегодняшний день. Мы прилагаем все усилия для того, чтобы пользователям было удобно работать с имеющимися продуктами.
И если мы даже говорим, что интерфейс корпоративных систем достаточно консервативен по своему дизайну и архитектуре, то это совершенно не значит, что набор функций различных категорий пользователей в системе столь же консервативен. Это не так, это уже вопрос функциональности. Для более оперативного реагирования на запросы наших клиентов мы используем гибкие методологии. Например, наш отдел переходит на использование Kanban, чтобы оперативно реагировать на любые критические запросы пользователей.
Насколько можно связать качество ПО и возможность планирования его жизненного цикла — от момента постановки задачи до последующей утилизации?
Если мы коснемся управления нашей деятельностью при разработке и сопровождении систем, то жизненный цикл был и ранее описан в различных объемных и сложных методологиях: ГОСТах и ISO‑стандартах. Данный вопрос проработан также в популярной методологии RUP, которую мы несколько адаптировали и изменили для нашего управления. В настоящее время именно RUP мы и применяем, она как раз описывает весь жизненный цикл ПО. Современный бизнес очень динамичен, и интенсивность генерируемых изменений постоянно растет. И мы пытаемся соответствовать заданному темпу. Это очень непросто, нам приходится существенно модифицировать подходы. Мы начинаем применять гибкие методологии, чтобы детально контролировать не весь жизненный цикл, а делать акценты на более приоритетных этапах, в данном конкретном случае — на тестировании.
А какие пожелания вы могли бы адресовать бизнесу, чтобы конечный результат, к которому все должны стремиться, гарантированно достигался?
Я хотел бы отметить следующие аспекты. ИТ‑служба, безусловно, стремится к тому, чтобы планировать свою деятельность вместе с бизнесом на различных временных промежутках — не только краткосрочных, но и среднесрочных, и долгосрочных. Если по каким‑либо причинам бизнес посчитает целесообразным закрыть проект, это необходимо делать открыто для всех участников проекта. В случае же, наоборот, принятия решения об открытии проекта необходимо подробно описывать все тендерные процедуры и своевременно информировать участников.
Любая ИТ‑служба хочет иметь определенные фиксированные этапы взаимодействия с бизнесом. У нас во взаимодействии с бизнесом накоплен достаточно большой опыт, и мы такие этапы научились выделять и фиксировать. Мы используем стандартизованные шаблоны документов, которые позволяют учесть те многоплановые аспекты, которые ранее встречались в нашей практике. Можно сказать, что с каждым годом мы все глубже понимаем бизнес, научились говорить с ним на одном языке, успешно добиваемся повышения качества взаимодействия.
Насколько связаны на практике деятельность в области обеспечения качества эксплуатируемого в организации ПО с политикой обеспечения качества работы компании в принципе, если таковая имеется?
Проектный менеджмент пришел в нашу отрасль из машиностроения и строительства, так что история используемых процессов и методов весьма богата. Однако ИТ‑сфера славится тем, что здесь куда больше гибкости в создании конечного продукта, а вместе с этим и возможностей для разного рода ошибок и недопонимания. Очевидно, что программное обеспечение обладает большим числом «степеней свободы» нежели микросхема или электронное оборудование, не говоря уже про строительство и машиностроение. Так что разных вариаций ошибок, недочетов, сбоев и даже различных сценариев краха системы действительно очень много. Иными словами, нам, наверное, приходится преодолевать больше препятствий, если ставится общая задача — за время Х перевести бизнес из точки А в точку B, которая характеризуется более зрелыми, совершенными и качественными бизнес-процессами. Собственно, поэтому нам так необходимы продуманные методические подходы, а также богатый инструментарий поддержки разработки, управления изменениями и приемки внешних систем.
Из этого также следует понимание того, что усовершенствования, которые предпринимаются бизнесом в целях повышения качества бизнес-процессов, и наши усилия по обеспечению качества информационных систем должны быть синхронизированы друг с другом, иметь множество точек пересечения (а соответственно и возможных точек контроля). Методологии внедрения систем должны отражать то, как бизнес их воспринимает, а он воспринимает предлагаемые ему инструменты через собственную призму политики обеспечения качества.
Эти самые точки пересечения мы должны иметь по всему жизненному циклу информационных систем. Они присутствуют и на этапе постановки задач, когда вводятся тендерные политики или упомянутые выше шаблоны по документообороту. Они могут появляться уже на этапе эксплуатации, когда мы говорим о регламентировании скорости обслуживания, определяем время, необходимое на исправление ошибок. То есть работа ведется в тех точках пересечения, в которых мы напрямую взаимодействуем с конечным заказчиком — с бизнесом и пользователями.
