Каким критериям качества должно соответствовать программное обеспечение? Что такое архитектурная тактика программного обеспечения? Как модель отслеживания способна повысить эффективность контроля качества? На эти и другие вопросы отвечает доцент Университета Иннополис Мохамад Кассаб.

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

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

Кроме того, критерии качества часто имеют сквозную природу, то есть их внедрение воздействует на несколько модулей, а то и на всю систему. Практика показывает, что программная отрасль не отличается аккуратностью в вопросах сроков и бюджетных рамок. Согласно недавнему докладу на основе исследования, в котором я, по сути, был главным редактором, — и это было международное исследование, — всего 20% проектов укладываются в заданные временные и бюджетные рамки. В недавнем отчете IBM написала, что 50% расходов на создание программ уходит на реализацию критериев качества. И в своих исследованиях я пытаюсь разобраться в этих вопросах.

Как критерии качества взаимодействуют с функциональными требованиями? И как критерии качества взаимодействуют между собой? Какие понятия характеризуют эти взаимодействия? На основе каких механизмов отслеживания теоретически и практически принимаются решения по разработке требований и архитектурному проектированию для критериев качества? Какие аспекты сложности критериев качества учитываются в нынешней практике разработки требований и архитектурного проектирования? На какие важные области следует обращать внимание при выделении критериев качества? Какое влияние критерии качества оказывают на сложность создания ПО? Какие новейшие методологии исследований и труды используются для анализа связи между усилиями по реализации критериев качества и объемом ПО? Как улучшить современную практику оценивания проекта создания ПО на ранних стадиях с учетом воздействия критериев качества?

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

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

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

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

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

Мы проверили эту таксономию в контексте нескольких отраслей и провели исследование отзывов на адекватность таксономии реальности. И результаты исследования весьма многообещающи. Кроме того, мы проверили модель отслеживания критериев, то есть отслеживание критериев качества в промышленности. К примеру, мы занялись улучшением нынешних методов контроля качества в монреальском офисе Nokia. Мы подошли к этой задаче с предложением нового процесса выполнения тестов. Раньше в Nokia при любых изменениях выполнялся строго определенный ряд операций. У них было примерно 25 операций, которые выполнялись с целью стабилизации, чтобы никакое изменение не расстроило ключевой функционал. Тогда как модель отслеживания критериев качества, которую предложил я, не требовала выполнения списка операций, а динамически генерировала операции на основе ряда правил.

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

Что же до оценки трудозатрат, то сейчас я работаю с людьми из нескольких университетов над задачей по автоматизации моей модели. Таким образом, конечная цель — брать за ввод технические требования ПО, а на выходе получать оценку трудозатрат на создание ПО. Моя цель — создать инструмент, который автоматизирует мою модель оценки трудозатрат на выполнение критериев качества. Кроме того, меня интересует область гибкой разработки требований и то, как современная практика разработки вписывается в гибкие модели. Кстати, между этими понятиями есть разница.

Гибкая разработка требований означает целенаправленный способ разработки требований.

Он применим во всех потенциально гибких областях: разработке, разработке софта, каскадной модели. Тогда как разработка требований в гибкой практике означает использование нынешних методов разработки требований в рамках гибких процессов разработки софта. С появлением гибких методологий дисциплина разработки требований оказалась перед испытанием. Шли споры насчет роли, которую разработка требований должна играть в процессе гибкой разработки софта.

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

Кроме того, я интересуюсь разработкой программ в сфере образования.

Например, образование по Сети становится все популярней, особенно во многих учебных заведениях в Соединенных Штатах.

Я участвовал в создании ряда учебных программ по разработке ПО и методов их изложения в учебных заведениях Соединенных Штатов. И некоторые из этих программ преподаются в онлайн-режиме. Всегда стоял вопрос: как адаптировать курс по разработке ПО к сетевому формату изложения? Однажды даже был курс в половинчатом формате, то есть часть курса преподавалась удаленно, через Сеть, а часть в режиме присутствия. И стоял вопрос: какие части курса преподавать в режиме присутствия, а какие вынести в сетевой формат изложения? Над этой темой я сейчас и работаю: изучаю, анализирую мнения студентов об обучении разработчиков и то, как они взаимно оценивают сетевой формат и режим присутствия.

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