CC BY
97
дефектов во всех продуктах, создаваемых на фазах жизненного цикла ПИ (в планах, в требованиях заказчика к ПИ, спецификациях высокоуровневого и детального проектирования, кодах и во всех других продуктах фаз) в результате всех видов обзоров и тестирования, производить запись обнаруженных ошибок и дефектов в базу данных ошибок и дефектов (БДОД), а после их устранения записывать в нее количество закрытых ошибок и дефектов. В БДОД необходимо регулярно производить подсчет найденных, закрытых и открытых ошибок и дефектов на момент окончания очередного ее обновления. По результатам такого подсчета автоматически осуществляется построение графиков, аналогичных показанным на рисунке 5. Графики (рис. 5) автоматически корректируются одновременно с обновлением БДОД.
В ИДУ обновление графиков осуществляется каждую неделю с начала проекта ПИ (этот график является одним из компонентов еженедельного метрического отчета по каждому проекту ПИ). При этом каждый руководитель проекта в свой работе по управлению проектом стремится к тому, чтобы к окончанию любой фазы жизненного цикла ПИ было бы найдено и устранено такое общее число ошибок и дефектов на ней, которое бы соответствовало метрикам стандартного процесса этой фазы (см. возрастающие части графика графической модели рис. 4).
Анализ графического метрического отчета, показанного на рисунке 5, является не только эффективным средством отслеживания возможного качества создаваемого ПИ, но и средством для выработки управляющих воздействий по улучшению деятельности по предотвращению дефектов.
Так, например, если в результате обзоров и тестирования в нескольких еженедельных метрических отчетах подряд указывается меньшее число ошибок и дефектов, чем определено метриками стандартного процесса (см. рис. 4), то это является свидетельством низкого качества обзоров и(или) плохо продуманного тестирования (три и более отчетов подряд) или сигналом к необходимости повышения качества выполнения этих мероприятий (два отчета подряд).
В заключение отметим, что графическая модель обнаружения и устранения ошибок и дефектов в программном проекте (рис. 4) и еженедельный метрический отчет о количестве обнаруженных, открытых и закрытых ошибок и дефектов (рис. 5) совместно представляют собой эффективное средство для отслеживания уровня качества выполнения программного проекта и управления качеством создаваемых ПИ.
Список литературы
1. Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software [2] Six Sigma Producibility Analysis and Process Characterization, by M. J. Harry and
2. R. Lawson, Motorola University Press, Chapter 6, (708) 576-7507.
3. Suzanne de Treville, Norman M. Edelson, and Rick Watson, "Getting Six Sigma Back to Basics," Quality Digest, May 1995, pp. 42-47.
4. IEEE Standards Collection. Software Engineering, 1993 Edition. - New York: IEEE, 1993. - 952 p.
5. Robert B. Grady, Practical Software Metrics for Project Management and Process Improvement, HP Professional Books, 1992, 270 p.
СРАВНЕНИЕ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ ПО КРИТЕРИЮ ФУНКЦИОНАЛЬНОЙ ПОЛНОТЫ
Г.Н. Хубаев
В настоящей работе объектом рассмотрения являются сложные программные системы (ПС), но описанный алгоритм может применяться для оценки функциональной полноты и других характеристик любых сложных систем, имеющих десятки, сотни и тысячи функций (свойств, признаков, реализуемых услуг и т.п.). Так, ПС, базирующаяся на предложенном алгоритме, успешно использовалась не только по своему основному назначению, но и для формализованного анализа текстов (текстовых файлов).
В сегодняшних условиях рынок ПС в состоянии предложить потенциальному покупателю
множество систем одного назначения, отличающихся по составу и качеству выполняемых функций (эксплуатационных параметров, характеристик, предоставляемых услуг и др.). Поэтому перед покупателем-пользователем встает проблема выбора из перечня конкурирующих систем одной или нескольких, в наибольшей степени удовлетворяющих его требованиям, например, к функциональной полноте или другим эксплуатационным характеристикам. Если речь идет о программных продуктах (ПП), то для реализации оптимального выбора необходимо, во-первых, располагать количественной оценкой того, насколько (в какой сте-
пени) программы-претенденты удовлетворяют конкретным требованиям покупателя-пользователя; кроме того, желательно одновременно определить, какие из нужных пользователю функций не реализуются тем или иным ПП. Во-вторых, и для потребителя, и для конкурирующих фирм-разработчиков ПП важно выявить лучшие по критерию функциональной полноты системы. Желательно также определить перечень функций, реализуемых всеми представленными на рынке ПП.
Напомним, что в современных ПП количество выполняемых ими функций (функциональных операций) может достигать нескольких сотен. Очевидно, что в этих условиях вряд ли удастся традиционными методами (вручную) оценить степень соответствия ПП требованиям пользователя, сравнить ПП-претенденты по функциональной полноте. Поэтому в [1,2] для решения подобных задач предложен формализованный подход. Отметим, что за прошедшие годы методика подтвердила прикладную полезность и неоднократно использовалась коллегами и учениками автора. Описанный ниже алгоритм реализовывался с помощью разных инструментальных средств. Здесь мы рассмотрим одну из программно реализованных его модификаций.
Алгоритм сравнения. Пусть 2= (21) (1=1,2,..., п) - множество сравниваемых ПП (ПП-претен-дентов); К=(К.) (]=1,2,..., т) - множество, составляющее словарь реализуемых ПП (Ъ.) функций.
Исходную информацию представим в виде таблицы (Ху), элементы которой определяются следующим образом:
X.. = <) 1, если .-я функция реализуется 1-м ПП.
4 I 0, если не реализуется (не выполняется).
Выделим ПП Ъ. и Ък (., к = 1, 2,..., п) и введем следующие обозначения:
Р.к1 - число функций, выполняемых и Ъ., и Ък, то есть
Р1к1) = 2 пЪк| - мощность пересечения множеств 21={Х1.) и 2к=(Хк.) (]ет; х|х. лхк. = 1);
Р1(10) - число функций, выполняемых ПП Ъ.,
но не реализуемых ПП Ък, то есть Р.к0) = \ Ък|
- мощность разности множеств Ъ. = (Х. и Ък =
(Хч);
Р1(01) - число функций, выполняемых ПП Ък, но не реализуемых ПП Ъ., то есть Р1(к01) = |ък \
- мощность разности множеств Ък и Ъ.;
Р1<к10) = и ъЛ - мощность объединения
множеств Z; и Zk, то есть Pi
(00)
ik
P(11) + P( Pik + P<
(10)
+ P,
(01)
Для оценки того, какая часть (доля) функций, выполняемых ПП Zb реализуется также и ПП Zk, можно использовать величину
Hik = Pik1)/(Pik1) + Pik0)),(0 < Hik < 1).
Взаимосвязь между ПП Zi и Zk оценивается по значениям Pik1) и
Gik = Pik11)/Pik00),(0< Gik < 1), где G ik - мера подобия Жаккарда.
Выбирая различные пороговые значения е элементов матриц P, G и H, можно построить логические матрицы поглощения (включения) P0, Go, Ho. Например, элементы матрицы H0 получают следующим образом:
HO _ I 1, если Hik >eh,i ф k
.0, если Hik < eh,i = k . Граф, построенный по логическим матрицам P0, G0, H0, дает наглядное представление о взаимосвязи между сравниваемыми ПП (по выполняемым функциям).
Строку с перечнем функций, которые интересуют пользователя (должны выполняться ПП-претендентом), обозначим через Ze.
Дополнив таблицу {Xij} (ien, jem) строкой Xej (jem), рассчитаем матрицы P(10), P(11). Затем,
выделив строки, у которых Pe(10) = 0 либо
Hej = P^1 / (Pen) + P™) = Ue Ф j, j e n), получим
перечень ПП, полностью удовлетворяющих требованиям пользователя к функциональной полноте программного средства (или любой другой сложной системы).
Последовательность шагов реализации алгоритма
1) В справочнике функций, выполняемых сравниваемыми ПП, отмечаются те функции (функциональные операции), которые должны выполняться условным (реально не существующим) ПП, и формируется новая строка Ze. Этой строкой дополняется исходная таблица {Xij}, то есть в таблице Zi = {Xij} появляется строка Ze (ie(n+1), je m).
Строятся матрицы Pjn), Pi(10), Pi(01),Hij (i, jen+1).
2) В матрицах Pij или Hij (i, jen+1) выделяются строки Pej и Hej (jen+1).
3) Из n элементов Zi, каждый из которых соответствует одному из рассматриваемых ПП,
выбираются только те, у которых Pe(j10) = 0 или
Hej=1 (jen), то есть ПП, которые включают в ка-
честве подмножества перечень функций, реализуемых условным ПП Ze.
Предположим, что число удовлетворяющих этому условию программных пакетов равно d, dc n.
4) Формируется новая матрица Z(1) (ied).
5) Для подмножества Z® (ie d) строится матрица P(01) = {Pi(01)} (i, jed).
6) По матрице {Pj(01)} последовательно для
ре01) = 1,Ре(01) = 2 и т.д. строится таблица А, в которой перечисляются функции, не предусмотренные в условном пакете Ze, но реализуемые пакетом Zj (jed).
Таблица А
Код (номер) ПП, Zi Наименование ПП Идентификатор и наименование выполняемой функции
Zk XXX Rk, г
Rk, г+s
Zt Rt,p
Из таблицы А пользователь выбирает одну или несколько заинтересовавших его функций, которыми дополняется строка Ze, после чего процесс повторяется, начиная с шага 2.
7) По матрице Р(10) = |Р;(10)} последовательно
для Р^0 = 1, = 2 и т.д. строится таблица В,
аналогичная таблице А, в которой перечисляются функции, предусмотренные в Ze, но не реализуемые пакетом Zj, а по матрицам Р(11),И0,О0 для
выбранных пороговых значений е их элементов можно выделить и представить в виде таблицы подмножества общих (или часто реализуемых) функций, оценить степень взаимосвязи между изучаемыми ПП по выполняемым функциям и т.д.
Рассмотрим численный пример. Предположим, что в таблице 1 представлены данные о выполняемых ПС й) функциях
,(10)
Легко убедиться, что даже в таком простейшем случае (п=6, т=15) сравнение и оптимальный выбор ПС по критерию функциональной полноты осуществить весьма не просто. Но ведь ситуации, когда п, т > 100 вполне обычны. Поэтому анализ будем проводить, следуя предложенному ранее алгоритму.
Сначала для таблицы 1 вычислим матрицы Р(01), О и И, а затем построим логические матрицы поглощения Р0(01), О0 и И0, выбрав следующие пороговые значения элементов:
ер = 1(РН <ер), е8 = 0,5(0|к >е8)
и еь=1(1,кеп).
0 7 00 0 7 0 0 1 1 1 0
5 0 42 2 2 0 0 0 0 0 0
Р(01)= 2 8 00 1 9 ; Р0(01) = 0 0 0 1 1 0
4 8 20 1 10 0 0 0 0 1 0
6 10 52 0 11 0 0 0 0 0 0
3 0 32 1 0 0 1 0 0 1 0
1 0,38 0,75 0,5 0,25 0,63
0,3 1 0,2 0,2 0 1
H= 1 0,33 1 0,33 0,17 0,5 ;
1 0,5 1 1 0,25 0,5
1 0 0,5 0,5 1 0,5
0,4 0,8 0,25 0,17 0,08 1
0 01 10 0 0 0 0 0 0 0
0 00 00 1 0 0 0 0 0 1
Ос 1 00 10 0 ; H0 = 1 0 0 0 0 0
1 01 00 0 1 0 1 0 0 0
0 00 00 0 1 0 0 0 0 0
0 10 00 0 0 0 0 0 0 0
Предположим теперь, что для потребителя-пользователя нужно, чтобы ПС-претендентом выполнялись функции Я2, Я5, Я6, Ях0. Обратившись к построенным матрицам, обнаружим, что интересующие пользователя функции реализуются тремя ПС: Zь Z3, Z4 (см. четвертый столбец матрицы Р(Р0) или четвертую строку матрицы И(И0)). Что касается ПС Z2, Z5, Z6, то в них нужные пользователю функции реализованы лишь частично. Продолжая действовать в соответствии с описанным
Таблица 1
Наименование Наименование (код) выполняемой функции
(идентификатор^ R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 ERj je 15
Z1 1 1 0 1 1 1 0 0 0 1 0 0 0 1 1 8
Z2 0 0 1 0 1 1 1 1 1 0 1 1 1 0 1 10
Z3 1 1 0 1 1 1 0 0 0 1 0 0 0 0 0 6
Z4 0 1 0 0 1 1 0 0 0 1 0 0 0 0 0 4
Z5 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 2
Z6 0 0 1 1 1 1 1 1 1 0 1 1 1 1 1 12
ERi ie6 2 4 2 3 5 5 2 2 2 3 2 2 2 3 3
алгоритмом, легко ответить на все основные вопросы, возникающие при количественной сравнительной оценке ПС по критерию функциональной полноты.
Область применения, преимущества. Нам
не известны другие алгоритмы и методики, позволяющие с меньшими затратами финансовых и интеллектуальных ресурсов осуществить следующее:
1) составить полный перечень функций, реализуемых всеми представленными на рынке ПП;
2) систематизировать сведения о составе и функциональной полноте существующих ПП;
3) количественно оценить степень соответствия того или иного ПП требованиям пользователя к функциональной полноте;
4) проранжировать ПП по критерию функциональной полноты;
5) на стадии предварительного анализа исключить из дальнейшего рассмотрения ПП, в ко-
торых не реализуются нужные пользователю функции;
6) сформировать группу ПП, имеющих одинаковую функциональную полноту, сопоставить их цены и другие характеристики;
7) расширить для потребителя-пользователя возможности оптимального выбора на рынке программных средств, предоставив перечень выполняемых каждым ПП функций, а разработчику ПП показать место его продукта среди существующих ПС и одновременно дать первоначальную оценку конкурентным рыночным позициям фирм-разработчиков ПП.
Список литературы
1. Хубаев Г.Н. Анализ информационных потребностей пользователей при создании АРМ // Автоматизированные рабочие места в системе управления предприятием. - Л.: ЛИЭИ, 1989.
2. Хубаев Г.Н. Методика анализа предметной области // Компьютеризация информационных процессов в управлении народным хозяйством. - М.: МЭСИ, 1988.
ЯЗЫК ЗАПРОСОВ РЕЭЛТ - РЕЛЯЦИОННЫЕ ЭЛЕКТРОННЫЕ ТАБЛИЦЫ
В.Н. Краснов
В статье приводится описание свойств оригинального механизма выполнения запросов к базе данных (БД) и получения отчетных форм [1-3], реализованного в инструментальном средстве автоматизации программирования (ИСАП) интерфейса БД и названного реляционная электронная таблица (РЕЭЛТ). Средство определения РЕЭЛТ является высокоуровневым языком запросов. Данный язык разрабатывался как альтернативный языкам SQL и QBE для использования на этапе обслуживания БД. В прикладных пакетах РЕЭЛТ используется как основной язык запросов при работе конечного пользователя со сложной реляционной БД.
Все файлы БД составляют некоторое множество файлов. Один файл БД может быть представлен в виде нескольких таблиц, отличающихся условием группировки записей. При использовании термина файл будет подразумеваться одна из таблиц, полученных из этого файла посредством выполнения сортировки записей определенным образом. Каждая таблица БД именуется.
Подчинением одной таблицы другой является установление связи 1:М от подчиняющей таблицы к подчиняемой по ключу. Каждая таблица может в разных случаях являться подчиняемой (подчиненной) разным таблицам БД.
При вложенном подчинении таблиц мы полу-
0,1 - oSTaafu 0 k0={1,4}
1,1 W 1,2 1,3 1,4 - oSTaafu 1 k1 ={4,0,0,3,0}
2,1 2,2 2,3 - oSTaafu 2 Рис. 1 k2={3,0,0,0}
чаем многоуровневую схему подчиненности таблиц.
Рассмотрим пример.
Интересующий нас файл БД имеет следующие связи с подчиненными ему таблицами (рис. 1).
Нумерация уровней: 0, 1, ... ,и-1. и - количество уровней в схеме. Узел дерева может состоять из нескольких таблиц: главной и связанных с нею отношениями 1:1 или М:1. Верхний узел связан с нижним отношением 1:М.
РЕЭЛТ определяется на этой схеме представлением файлов БД. В реализации описываемого механизма запросов пользователю предоставляется удобный диалоговый интерфейс, включающий средства описания выражений для вычисления
