Пристальный взгляд на качество программ

Потребители и разработчики смотрят на программу с разных сторон. Как оценивать программу? Как сопоставить технические решения, принимаемые разработчиками требованиям пользователей? На эти вопросы пытается ответить предлагаемая статья.

Ни у кого не вызывает сомнения, что создаваемые программные продукты должны быть «качественными», однако, что это означает определить достаточно сложно. Причем отнюдь не из-за недостатка материалов - скорее наоборот, материалов предостаточно. Имеются отечественные [1] и международные [2] стандарты, существуют фундаментальные труды [3,4] и практические методики. Их применение на практике, однако, чрезвычайно затруднено. Во-первых, показателей качества невообразимо много (сотни, если не тысячи). Во-вторых, их мало, так как многие практические аспекты, естественно понятные специалисту, в них не отражены. В-третьих, они противоречивы. И, наконец, главное - они плохо упорядочены. Основная проблема, по-видимому, заключается в том, что попытки упорядочить показатели качества, в основном опираются на иерархию.

Но даже, если разрешить на нижнем уровне множественное наследование от основных показателей (как это делается в работе [3]), такие попытки обречены на провал. Дело в том, что со стороны потребителя и разработчика программа имеет принципиально разные измерения. Сопоставление одних другим - сложная задача (в качестве одного из немногих успешных подходов к ее решению можно назвать Quality Function Deployment).

Однако даже оставаясь в плоскости только технических показателей, мы вынуждены оперировать чрезвычайно большим числом измерений, поэтому в данной работе предлагается простой способ упорядочения показателей, основанный на анализе естественных аспектов программирования. Программа является моделью, отображающей сущности прикладной области и окружения - «хорошее» отображение должно быть полным, согласованным (сохранять отношения между объектами) и по возможности не избыточным.

Множество конкретных показателей можно получить, если с основными категориями свойств отображений пересечь аспекты программирования (декомпозиция, именование, комментирование и пр.). Причем каждая категория свойств содержит некоторое число классов. Например, согласованными должны быть отношения подобия (свойство единообразия) и порядка (упорядоченность). Таким образом, конкретных показателей получится много. В то же время их можно представить в компактном, наглядном виде, а главное, ничего не пропустить.

На основе анализа взаимной корреляции ранжированных потребительских и технических характеристик, возможен выбор целевых показателей, что дает ориентиры разработки и критерии ее оценки. Существенно уменьшить размерность задачи сопоставления характеристик позволяет использование ранее наработанного опыта, прежде всего заключенного в стандартах. Новый шаг в упрощении задачи состоит в использовании профилей - адаптированной к конкретному проекту совокупности [компонентов] стандартов [5].

Показатели качества программ и варианты их упорядочения

Как справедливо отмечается в http://oop.cs.technion.ac.il/236804-Fall-1997/metrics/part1.html в качестве параметров, характеризующих программу, могут выступать самые разнообразные показатели. Вплоть до веса распечатки в граммах, который можно рассматривать как грубое приближение наиболее распространенного показателя - числа строк кода. Поэтому вопрос заключается в выборе наиболее информативных показателей и соответствующих подходов для их сопоставления, выработке компромиссов и получения интегральных оценок.

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

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

Реальные ситуации включают как нормальные условия, так и всевозможные неблагоприятные обстоятельства (ошибки оператора, сбои и отказы среды, исчерпанность ресурсов, преднамеренные «атаки»). Время обслуживания включает, в частности, время на восстановление после сбоев/отказов, в том числе, время, необходимое для подключения специального персонала. А стоимостная оценка соответственно оплату этого персонала.

Большинство из характеристик, определяющих удобство, могут быть оценены в единицах времени: время, необходимое на освоение программы, время для подготовки входных данных, время выполнения задания, время анализа выходных данных и даже время, необходимое для восстановления сил пользователя после работы с программой. Если учесть заработную плату пользователя, то удобство можно выразить в денежных единицах.

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

Как международный [2], так и отечественный [1] стандарты определяют три уровня характеристик. Первые два уровня представляют структурированный пользовательский взгляд на программу, которая рассматривается как готовый продукт, и поэтому не затрагиваются показатели, характеризующие затраты/сроки первоначальной разработки. На практике же, как правило, их приходится учитывать при выработке общего баланса требований.

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

В целом ни один из применяемых или даже пропагандируемых к применению показателей, не может служить надежной базой для оценки программы. Рассмотрим два наиболее характерных примера: показатель надежности - наработка на отказ и показатель «сложности» - длина программы. Первый относится к пользовательским характеристикам и может быть измерен при относительной готовности программы в процессе ее функционирования. Второй является техническим и характеризует взгляд разработчика.

Наработка на отказ - среднее время между появлением угроз, нарушающих безопасность [6] заменяет трудно измеримую оценку ущерба, наносимую соответствующими угрозами. Подход к измерению этой характеристики был заимствован из области оценки качества технических средств. Для большинства современных программных средств его информативность, к сожалению невелика. Например пользователь диалоговой программы привык пользоваться меню, указывая кнопки с помощью клавиатуры, а его коллеге удобнее правая кнопка «мыши». У первого программа работает стабильно, у второго нередки аварийные ситуации. Дефект программы заключается в том, что во всплывающем при нажатии кнопки «мыши» меню, при определенных обстоятельствах не отключена одна строка, случайное попадание на которую, вызывает отказ.

Или другой пример. Два программиста, разрабатывающие два похожих модуля пользуются одним новым компилятором. У первого проблем нет, у второго случаются. По-видимому, стиль программирования у второго программиста таков, что на нем всплыли дефекты компилятора.

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

Чрезвычайно порочной необходимо признать процветающую до сегодняшнего дня практику оценки программы по числу строк (пусть не пустых и без комментариев) [7]. При сопоставлении двух программ, реализующих одну прикладную задачу в равной и достаточной степени проверенных, если одна много короче, то предпочтение нужно отдать ей. Почти наверняка она создавалась более квалифицированным персоналом, в ней меньше скрытых ошибок и ее, скорее всего, легче модифицировать. Стоить она также должна дороже. Хотя, конечно времени на отладку и модификацию длинной программы уйдет больше.

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

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

Концептуальная модель аспектов программирования

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

Рис. 1. Концептуальная модель аспектов программирования

Сейчас нас интересует, прежде всего, код программы как модели решения задачи прикладной области, изготовленной средствами современной системы программирования, и опирающейся на некоторую программно-аппаратную среду. Для этого кратко перечислим основные сущности программы и ее окружения, их отношения и соответствующие отображения (рис.1).

С прикладной областью (точнее с ее моделью, представленной в спецификациях) код связывает отображение реализации. Среда обслуживает код, поставляя ему набор услуг по определенным правилам (протоколам). Функционирование программы представляет собой исполнение кода в рамках среды. Для разработчика код доступен в виде набора документов, часть из которых имеет текстовую форму представления, другие, например, описание диалога - графическую. Условно, тем не менее, мы будем называть соответствующую совокупность текстом программы.

Сам код для современных объектно-ориентированных языков состоит из иерархии конструктивов: типы (классы), объекты (переменные) и процедуры (методы). В свою очередь процедуры представляются иерархией операторов, а компоненты операторов иерархией выражений. Конструктивы связывает не только отношение иерархии, но и отношение обслуживания. Это то же обслуживание, что и с внешней средой. Между кодом и средой нет жесткой границы - сегодня некоторый компонент является частью кода, а завтра он может перейти в среду.

Большинство современных систем программирования требует от программиста явного определения представления кода программы в терминах иерархии модулей (проектов) и файлов. Под модулями рационально понимать не только разновидности исполняемых частей программы, статических и динамических библиотек, но и различные виды документации. Рассмотрение единого информационного пространства программы, включающего как собственно представление кодов, так и ее описание для различных категорий пользователей и позволяет отслеживать согласованность между документами различной природы.

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

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

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

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

Контекст включает общепризнанные знаковые системы (например, разрешающий символ должен быть скорее зеленым, чем красным), стандарты де-факто по организации интерфейса (справка вызывается по F1), положения психологии и эргономики.

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

Разработка программы должна проводиться не только в контексте достижений современной информатики, но и с учетом опыта смежных областей. К сожалению, часто программисты оглядываются только на логику и вычислительную математику. Хотя, например, было бы чрезвычайно уместно иметь в виду положения общей теории систем [8], особенно при формировании иерархии конструктивов (соотнесение числа уровней и количества компонентов на каждом уровне - проблемы хорошо изученные в более широком контексте, чем программирование).

Конкретные условия разработки, принципы организации и структура коллектива разработчиков - это еще один компонент контекста. Принимаемые декомпозиционные решения существенным образом зависят от того, организованы программисты в виде «хирургической бригады» Брукса [9] или как группа равноправных соисполнителей.

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

Свойства аспектов программирования

Базовые технические характеристики программы определяются свойствами отношений и отображений, составляющих аспекты программирования. Эти свойства принадлежат к одной из трех категорий: полнота - в программе есть все, что нужно, отсутствие избыточности - в программе нет ничего лишнего, согласованность - программа и ее части соответствуют правилам и законам внешнего мира. Оценка свойства имеет два значения: ДА - свойство есть, НЕТ - свойства нет.

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

Рассмотрим конкретные виды свойств по их категориям, а затем определим основные принципы их оценки.

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

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

Согласованность. Категория согласованности охватывает весьма разнообразные свойства, поэтому для обозначения их общности приведем формальное определение:

Согласованность

"a, b a^o b Ю M(a)^o M(b)

В частности:

Единообразие

Подобные сущности должны быть отображены подобным образом

"a, b a ~ b Ю M(a) ~ M(b)

Неамбивалентность

Различные сущности должны быть представлены различно

"a, b a № b Ю M(a) № M(b)

Последовательность

Отображение должно сохранять упорядоченность сущностей

"a, b a < b Ю M(a) < M(b)

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

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

Необходимо отметить, что в общем случае констатация несогласованности отнюдь не идентична констатации ошибки. Если отмечается взаимная несогласованность, то нужно еще разобраться, в каком из выявленных мест допущена ошибка. Если речь идет о композиционной несогласованности, то она констатирует лишь возможное направление улучшения программы. Наконец, учитывая, что критериев согласованности может быть чрезвычайно много, и то, что они часто противоречивы, констатация несогласованности является лишь поводом для сопоставления их приоритетов.

Оценка свойств аспектов программирования

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

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

Оценку можно проводить лишь при условии определенности критериев. Что должно входить (не входить) в программу, и с чем она должна быть согласована - необходимо зафиксировать заранее. Здесь возможны абсолютные требования (например, нормы естественного языка), требования уровня разрабатывающей организации (например, стандарт кодирования), а также требования, формируемые для данной программы. Процесс формирования технических требований должен проводиться на основе анализа совокупности потребительских качеств, которыми должна обладать программа и их взаимозависимости.

Соотнесение характеристик методом QFD

Сопоставляя потребительские и технические характеристики между собой, можно обнаружить случаи, как независимости, так и положительной и отрицательной корреляции. Эффективная форма анализа зависимостей между потребительскими и техническими характеристиками Quality Function Deployment (QFD) была предложена в Японии еще в 1966 году (http://www.shef.ac.uk/uni/companies/msmu/QFD-IntroIV.htm).

Рис 2. Дом качества

Основа QFD - построение фигурной матрицы, названной в соответствии со своей формой «Дом качества» (рис. 2), в рамках которой фиксируется информация о качестве продукта и принимаемых решениях.

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

Левое крыло - столбец приоритетов пользовательских характеристик. Правое крыло - таблица рейтингов потребительских характеристик (с точки зрения пользовательского восприятия) для существующих на рынке подобных продуктов.

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

Предпосылками QFD являются маркетинговые исследования, определяющие, что хочет пользователь, насколько важны те или иные качества (левое крыло, шаги 1 и 2), а также, как решают подобные проблемы другие поставщики (правое крыло, шаг 3). Каждому продукту, включая свой текущий, наших конкурентов, свой перспективный по каждому требованию присваивается рейтинг. Рейтинг для перспективного продукта выбирается из следующих соображений.

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

После определения набора технических характеристик (шаг 4), заполняется центральная часть дома - определяются зависимости между потребительскими и техническими характеристиками (шаг 5). На шестом шаге анализируется уровень реализации в конкурирующих продуктах. После анализа взаимной корреляции технических характеристик (шаг 6), исходя из полученных сведений, формируются целевые показатели для разрабатываемого продукта (шаг 7).

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

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

Рис 3. Использование Дома качества

Рассмотрим теперь пример использования дома качества при выборе технических характеристик программного продукта в аспектах его пользовательской документации и справочного обеспечения (рис. 3). На этом примере проиллюстрируем особенности QFD- метода и наметим направления его развития.

Анализируются две группы пользовательских характеристик: эффективность обучения (освоения) программы и экономия затрат на ее разработку и эксплуатацию. Со стороны технических характеристик принимаются во внимание:

• полнота отображения программы (включающая как охват тем, так и вспомогательные компоненты: индексы, поиск по ключевым словам, демонстрационные примеры);
• согласованность с текущей версией кода, языковыми нормами, тенденциями пользовательских интерфейсов, с терминами;
• варианты представления справочной информации (в виде печатного документа или интерактивных справок, расположенных на диске или Web-странице);
• формы выхода (неформатированный текст, полиграфический текст и графика, анимация).

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

Неформатированный текст легче разрабатывать, он компактнее и позволяет экономить на хранении и считывании, однако менее информативен, чем полиграфические, а тем более анимационные справки.

Анализ корреляции между техническими параметрами показывает, что наиболее отвечают современным представлениям справки на WEB-странице, они же позволяют добиться наибольшей полноты.

Некоторые показатели независимы друг от друга. Полностью автономны показатели совместимости с языковыми нормами и терминологическая согласованность. Если характеристика имеет значение ДА/НЕТ и при условии, что она влияет на потребительские характеристики в одну сторону (положительную или отрицательную), ее можно вынести «за скобки».

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

В реальных ситуациях целесообразна смешанная стратегия, в которой оперативная справочная информация представлена неформатированным текстом, имеется дисковая часть справок, содержащая часто употребимые стабильные темы, а также Web-данные, не ограниченные в объеме и динамике модификации. Для формирования такой стратегии необходимо конкретизировать как пользовательское представление об обучении, так и состав технических характеристик. Подсказки должны выдаваться мгновенно и быть краткими, для их представления достаточен неформатированный текст. Демонстрационный пример, хранящийся в Web, должен быть хорошо оформлен, но его вывода можно и подождать. Таким образом, для каждой категории будут различные приоритеты и, следовательно, необходимо строить свой Дом качества. При этом часть информации, касающаяся зависимостей с представлениями и формами вывода останется неизменной.

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

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

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

Удачный выход предложен в работе [5] - использовать гармонизированные совокупности базовых стандартов и нормативных документов разного уровня, адаптированные для конкретного класса программ и конкретной организации - профили. Оставаясь действенным инструментом упорядочения, профили, в отличие от стандартов, много динамичнее и ближе к практике.

Заключение

Задача оценки качества программных продуктов является одной из важнейших для современного программирования. Выбор системы показателей, адекватной как классу программы, так и условиям разработки, а также определение их плановых (целевых) значений и взаимных приоритетов позволяет четко сориентировать разработчиков на конкретные цели, равно как и обеспечивает объективную базу для контроля качества программ.

Ключевым вопросом предлагаемого в статье подхода является выявление основных точек зрения на программу - аспектов программирования и их взаимоотношений. Для его решения была построена соответствующая концептуальная модель, в которой отражены естественные стороны процесса программирования как отношения и отображения, соотносящие сущности прикладной области, кода программы (модели преобразования данных), его представления в виде файлов (документов), его исполнения, среды, а также культурного контекста, в котором разрабатывается и эксплуатируется программа.

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

Конкретизация технических требований к программе возможна на основе анализа ее потребительских характеристик. Перспективный подход для сопоставления характеристик программ дает метод QFD. Однако его применение осложняется большой размерностью матрицы сопоставления характеристик. Для снижения ее размерности предлагается: выносить однозначные независимые характеристики, группировать (обобщать) характеристики на основе [профилей] стандартов, использовать автоматизированную поддержку для разложения/сборки матрицы.

Об авторe

Литература