Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов

Подождите немного. Документ загружается.

271

из-за неопределенности единиц измерения творческой части программистской

деятельности.

На остальных процессах ТЛ могут применяться оценки затрат на разработку,

связанные, например, с такими единицами измерения, как количество строк,

операторов и т.п., разрабатываемых в ходе ведения работ, учитываемых и

контролируемых в базе проекта.

Процесс сборки на ТЛ основан на применении метода сборочного

программирования. Основные затраты идут на создание новых компонентов, на

анализ и комплектацию готовых КПИ и на определение «цены модульности» при

их сборке. В связи с этим в расчет производительности труда входят затраты для

вновь создаваемых объектов по ТЛ и затраты на определение интерфейса готовых

компонентов.

Минимизации затрат на определение интерфейса модулей. С этой целью

рассмотрим вначале задачу оценки вариантов компоновки структуры программы Р

по исходному графу. Применяя метод упорядоченного перебора вариантов связи

модулей по данным (экспортируемым и импортируемым) на основе анализа

операторов вызова, определим коэффициент K

ИН

информационной независимости

модулей программы Р:

ИН







где ξ

– мера связанности по данным l-модуля; ξ

– мера связанности по всем

данным программы P и определяется как суммарная сложность описания

межмодульных интерфейсов, входящих в Р:

= ξ

–







«Цена модульности» создаваемой программы Р из модулей , т.е. объем интер-

фейса V

ДОП

(в строках или командах) создаваемых интерфейсных модулей-связи

для N разноязыковых модулей, можно вычислить по формуле

ДОП





)(

nljk



где d(M’

) – длина модуля–связи для M

и M

. Объем создаваемой программы

= (V

доп

+ VKMd

ИН







)( ),

где ΔV =

ДОП



– коэффициент отклонения проектного объема V от

полученного; d(M

) – длина l-модуля в одном языке L.

Зная объем V

доп

и число исполнителей на операции сборки, можно подсчитать

трудоемкость выполнения операции создания интерфейса. В затраты на

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

модулей, определения их функциональной пригодности и соответствия типов

272

входных данных типам и структурам данных реализуемой ПрО.

Стоимостные затраты сборочного создания ПС. Данные затраты

определим следующим образом:

С = С

аз

+ С

зм

+ С

сб

где С

аэ

– стоимостные затраты на анализ задачи ПрО; С

зм

– на анализ возмож-

ностей использования готовых объектов для реализации задач ПрО; С

сб

– на сборку

комплекта модулей.

Затраты на анализ задач С

аз





r 1

r1r

)(DCb ,

где C

. ) – затраты на анализ данных r-задачи ПрО (r= N,1 число задач); b

если задача выбрана для реализации функции ПрО, 0 – в противном случае.

Определим затраты на анализ возможностей использования имеющегося

набора функциональных модулей для реализации требуемых задач СОД или АСУ:

зм

= )(

1 1

MCa



 

где C

)– затраты на анализ функциональных возможностей j-модуля для

решения r-задачи (j= N,1 —число модулей); а

= 1, если j-модуль используется

для выполнения r-задачи, 0– в противном случае. Затраты на сборку модулей

определяются следующим образом:

сб

))'((

1 1 1

jrk

MVCd



  

где C

( )'((

MV ) , в которой )'(

MV = V

ДОП

– затраты на сборку М

и М

модулей; d

jrk

= 1, если k – это параметр из набора х={х

,..., х

} и является входным

для j-модуля r-задачи (l =

,1 N – число параметров), 0 – в противном случае.

Таким образом, формула (9.20) приобретает вид

С =

))'(()()(

1 1 1

1 1

1 21

jrkjr

rjr

MVCdMCaDCb



   



. (9.10)

Основными ограничениями данного выражения являются:

1) необходимость реализации требуемых функциональных задач ПрО







где N

– число реализуемых функциональных задач;

2) совместимость выбираемого набора модулей с языковыми средствами среды

программирования a

= ρ'

, в которой ρ

= 1, если j-модуль описан в ЯП

высокого уровня и ρ

= 0 – в противном случае; ρ'

,= 1, если в среде

программирования имеется система программирования в языке L и ρ'

,= 0 в

противном случае;

3) решение r-задачи за время Т

273









4) объем, необходимый для реализации агрегата:

max







где V

max

– максимальный объем допустимой памяти для загрузки в нее

сформированного агрегата.

Расчет стоимостных затрат, выраженных формулой (9.12), является трудоемким

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

Повышение производительности труда разработчиков. Повышение

производительности и достижение требуемого качества ПС зависят от:

– правильности и полноты методов и средств, выбранных для реализации

данного вида ПС и представленных упорядоченной последовательностью

(исходное качество процесса) на ТЛ;

– контроля соблюдения технологии ТЛ и результатов изменения состояний

объекта для определения степени отклонения от регламентных ТМ и средств, а

также для определения погрешностей отклонения отдельных свойств текущего

состояния объекта от установленных метрик и определения максимума

погрешности на конечном процессе ЖЦ как степени несоответствия объекта

разработки требованиям заказчика;

– унификации и стандартизации конструктивных элементов объекта разработки

(функциональные заготовки и готовые модули) и их качества;

– спецификации и квалификации субъектов (умение программиста работать на

инструментальных средствах и др.), автоматизирующих выполнение операций ТЛ;

– организации и управления разработкой (планирование норм, учет, контроль

хода разработки и др.).

9.4. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОГРАММ ПО

ТЕХНОЛОГИЧЕСКИМ ЛИНИЯМ

Под управлением качества ПС будем понимать действия (операции),

осуществляемые в ходе разработки ПС по ТП в целях установления, обеспечения и

поддержки необходимого уровня качества.

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

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

Под качеством программных продуктов будем понимать совокупность свойств,

обуславливающих его пригодность к использованию по назначению при

регламентации совокупности условий функционирования. Каждое свойство

является его качественной характеристикой и в процессе разработки может

выражаться определенными признаками, которые могут оцениваться экспертным

и аналитическим путями.

Для разных классов программных объектов на процессе разработки требований

вырабатывается номенклатура показателей качества и устанавливаются их базовые

значения в соответствии с имеющимся образцом. Показатели включаются в

описание процессов, и на их основе проводится контроль качества.

Обеспечение качества представляет собой совокупность планируемых и

274

систематически проводимых мероприятий, направленных на удовлетворение

заданным требованиям к качеству. Достижение заданных показателей качества ПС

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

системы управления качеством.

Многие методы управления качеством программных продуктов [6-9 и др.]

ориентированы либо на количественную оценку готового результата, либо на

оценку надежности, получаемую на основе ошибок, фиксируемых при ком-

плексных испытаниях объекта разработки. Методы оценки надежности позволяют

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

употреблению.

Узким местом многих методов оценки качества и надежности как одного и

свойств является их слабая ориентация на начальные процессы разработки ПС. В

[162] предложены прогнозирующие модели надежности, применяемые на процессе

программирования и сборки программного продукта. Однако для постепенного

достижения требуемого качества требуется применять методы экспертной и

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

Ряд работ посвящен методам экспертной оценки [29, 41, 42, 87 и др.], которые

требуют проведения мероприятий по созданию экспертных групп и методик

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

или количественно.

В работе [92], в частности, для систем, работающих с базами данных,

предлагается уделять большое внимание не только процедурам экспертизы,

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

работы экспертной комиссии, затрагивающей интересы коллективов разработчиков

системы.

В результате исследований по управлению качеством ниже будет приведен ряд

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

предметной области СОД и принятой организацией контроля, сбора

статистической информации в ходе разработки программного продукта

определенного вида по ТЛ. Предложено на каждом процессе иметь операцию

контроля проектных решений, принимаемых при выполнении преобразования

состояния объекта разработки.

Работы на следующем процессе начинаются после того, когда результаты

предыдущего процесса удовлетворяют требованиям контроля качества.

Оценка качества – это количественное определение значений показателей

свойств как создаваемого программного объекта, так и инструментов,

поддерживающих процесс его разработки (трансляторов, редакторов, отладчиков и

т. п.), на основе ТЛ.

Основная цель оценки качества в ходе разработки – проверка правильности

выполнения операций ТП, выявление отклонений фактических показателей

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

характере и причинах отклонений. В табл. 9.1 приведены задачи управления

качеством, ранжируемые по процессам общего назначения.

Модель качества разрабатывается на процессе ТПР при создании ТЗ на

проектируемое ПС. Модель учитывает структуру ТЛ, в которой указываются ТО

контроля атрибута или показателя качества в ходе разработки и формула оценки.

Рассмотрим показатели свойств качества программ на ТЛ более конкретно.

275

Табл и ц а 9.1

Наименование процесса Решаемые задачи

Разработка ТЗ и спецификаций

требований

Разработка моделей качества

Разработка ПС Управление качеством. Сравнение фактических показателей

качества с проектными

Испытание ПС Оценка полученных и эксплуатационных показателей.

Экспертиза технической документации. Оценка научно-

технического уровня ПС

Изготовление ПС Оценка качества изготовления ПС и документации

Эксплуатация ПС Оценка эксплуатационных показателей качества. Заключение о

соответствии исходным требованиям

Сопровождение ПС Оценка удобства сопровождения ПС

Показатели свойств назначения. В этом показателе оценочный показатель

сложность характеризуется объемом, выраженным количеством операторов

исходного текста:

V =

 

),(







iOk

где 0[i] – количество операторов в i-модуле; k– уровень ЯП (k=1) для Ассемблера и

k=10 для ЯП высокого уровня).

Полнота реализации функций характеризует степень удовлетворения

требований пользователя к функциям и определяется по двум оценочным

показателям:

1) коэффициент полноты реализованных функций

= F / P ,

где Р – число функций, включенных в требования к ПС; F

= )(





F – общее число

реализованных функций; F

= 1, если функция реализована, 0 – в противном случае;

2) средний взвешенный показатель полноты реализованных функций

Ф =

)(

FW 





где

- коэффициент весомости функции F

определяется из условия





= 1.

Показатель защищенности (П

) информации определяется из соотношения П

, где V

– объем данных, фактически защищенных; V

– требующих защиты.

Показатели свойств функционирования. Основной показатель этого свойства

– корректность. Он определяется степенью соответствия ПС требованиям

пользователя, и им можно управлять в ходе разработки. Методами определения

корректности (контроль проектных решений, тестирование) достигается снижение

числа ошибок путем применения на операциях процессов формальных методов

проектирования.

Оценка качества программ, созданных по ТЛ, связана с понятием корректности

и надежности. Проводится эта оценка на основании собранной статистики по

результатам тестирования и испытаний, накапливаемых в журнале регистрации

276

ошибок (таб. 9.7–9.9) с помощью моделей.

Международный стандарт ANSI/IEEE–729–83 разделяет ошибки в разработке

программ на следующие.

Ошибка (error) – состояние программы, при котором выдается неправильные

результаты, причиной которых являются изъяны (flaw) в операторах программы

или в технологическом процессе ее разработки, что приводит к неправильной

интерпретации исходной информации, следовательно и к неверному решению.

Дефект (fault) в программе является следствием ошибок разработчика на

любом из этапов разработки и может содержаться в исходных или проектных

спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В

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

Отказ (failure) – это отклонение программы от функционирования или

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

ограничениями и рассматривается как событие, способствующее переходу

программы в неработоспособное состояние из–за ошибок, скрытых в ней дефектов

или сбоев в среде функционирования.

Отказ может быть результатом следующих причин:

– ошибочная спецификация или пропущенное требование, что означает, что

спецификация точно не отражает того, что предполагал пользователь;

– спецификация может содержать требование, которое невозможно выполнить

на данной аппаратуре и программном обеспечении;

– проект программы может содержать ошибки (например, база данных

спроектирована без защиты от несанкционированного доступа пользователя, а

требуется защита);

– программа может быть неправильной, т.е. она выполняет несвойственный

алгоритм или он сделан не полностью.

Иными словами, отказы, как правило, являются результатами одной или более

ошибок в программе или наличия разного рода дефектов.

Данные типы ошибок влияют на оценку надежности ПС, которая

характеризуется такими основными атрибутными свойствами: безотказность и

восстанавливаемость. Первое свойство характеризуется тем, что программа

работает без сбоев и отказов. В случае их возникновения собирается статистика о

среднем времени наработки на отказ и интенсивности отказов. Эти данные –

входные для оценки надежности по моделям надежности, приведенным в п.7.6.

Восстанавливаемость определяется средним временем обнаружения и

устранения ошибки. В качестве числовой характеристики можно использовать

коэффициент готовности

= Т

ср

(Т

ср

+ Т

где Т

ср

– среднее время наработки на отказ; Т

= Т

о +

– среднее время

восстановления; Т

– среднее время обнаружения ошибки; Т

– время локализации

ошибки.

Показатели эргономичности характеризуют удобство эксплуатации и

оцениваются в процессе эксплуатации. Учет таких показателей в ходе разработки

заключается в проверке наличия средств поддержки переноса программы на

другой компьютер или на другую платформу. Упрощенную формулу переноса

программы дадим такую П = З

/ З

где З

– затраты на адаптацию в новой операционной среде; З

– затраты на

277

полную разработку в новой операционной среде.

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

операций при подготовке ПС к работе и ее запуску.

Документируемость определяется полнотой документации (по составу),

простотой изложения, структурностью информации. Оценивается экспертным

путем специалистами из группы нормоконтроля. Оценка носит качественный ха-

рактер и оформляется в виде протокола, специалистами, которые проводили

экспертизу. К настоящему времени разработаны новые подходы и методы

экспертного оценивания программных продуктов (например, в [141] разработана

математическая теория оценивания процессов и программных продуктов).

Показатели свойств технологичности характеризуются рациональным

выделением и использованием типовых, унифицированных компонентов,

способствующих сокращению трудовых затрат на создание ПС по ТЛ.

Уровень унификации определяется коэффициентами применяемости (К

ПР

) и

повторяемости (К

ПОВ

), которые вычисляются по формулам

ПР

= (N - N

) * N,

ПОВ

= N

/ N,

где N– общее количество составных элементов в формируемом ПС; N

– количество

оригинальных элементов; N

– количество повторно используемых элементов

(модулей).

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

показателей основными факторами, влияющими на качество на процессах

проектирования, являются методики, инструкции и контроль хода разработки.

Факторами, влияющими на эксплуатационные характеристики, являются:

корректность постановки задач и исходных требований; полнота тестирования;

полнота и точность отображения результатов в ПТД.

Контроль качества проектирования ПС по ТЛ. В процессе разработки

контролю на полноту подвергаются функциональная ФА и системная СА

архитектуры. Контроль является качественным и провидится экспертным путем на

основании требований к функциям. Результат контроля функций фиксируется в

карте, структура которой приведена в табл. 9.2.

Таблица 9.2

Показатели функций

Номер Наименование Оценка реализации Вес

Структурный контроль СА проводится экспертом для отметки состояний

элементов разрабатываемого ПС на ТП и фиксируется в опросной карте контроля

СА (табл. 9.3). Результаты оформляются протоколом, передаются в группу

контроля и используются для количественных оценок.

Структурный контроль программных компонентов до начала процесса

программирования предназначен для выявления и устранения ошибок в ПТД.

Основными контролируемыми показателями являются: полнота СА;

технологичность СА; структурная сложность компонентов и/или модулей;

трудоемкость кодирования. Результат контроля компонентов фиксируется в

сводной карте (табл. 9.4).

278

Таблица 9.3

Номер

вопроса

Содержание Оценка эксперта

1 Используются ли повторно используемые

компоненты (их доля)?

2 Выделены ли компоненты по функциональному

принципу ?

3 Независимы ли компоненты?

4 Стандартизован ли интерфейс между

компонентами?

5 Предусматриваются ли средства восстановления при

ошибках и какие:

– использование контрольных точек,

– контроль данных,

– другие .

6 Предусматриваются ли средства восстановления при

разрушении и какие:

– использование страховой копии,

– восстановление с помощью транзакций,

– другие.

7 Предусмотрены ли средства защиты данных?

8 Унифицированы ли основные компоненты ?

Таблица 9.4.

Контроль компонента Название

Количество проверенных модулей

– обнаруженных ошибок,

– модулей с отклонениями от технологии

требуемых повторных просмотров

Время контроля

Карта контроля СА используется при оценке показателя технологичности;

са

)(

PW 





где

= 1, если ответ положительный, 0 – отрицательный;

– весовой

коэффициент вопроса в карте; N – количество вопросов.

Базовое значение Т

са

находится в интервале 0,8 < Т

са

≤ 1.

Показатель сложности разрабатываемого ПК определяется с помощью

оценочных элементов; количества модулей, их длины, объема и структурной

сложностью модуля.

Они определяются по ПТД (паспортов модулей и описаний в СЯВ или ЯПП) и

используются при прогнозировании трудоемкости кодирования. При оценке

длины, объема, трудоемкости и сложности используются метрики Холстеда [202],

в которых длина словаря операндов (К

) определяется по следующей формуле:

= А



+ В ,

А = M

/ (M



log 2



/2 ,

B = M

- 2



А ,

где К

- длина словаря операторов модуля. Нижняя длина модуля определяется по

формуле:

N = К



log (К

) + К



log (К

) ,

279

а верхняя считается равной 2N. Запишем объем модуля в битах:

V = N



log 2 (К



) ,

Время на программирование модуля можно определить по формуле

T = E / (Q



60),

где Q характеризует квалификацию программиста, определяемую по формуле

(9.8). Эти и другие сведения заносятся в карту модуля (табл. 9.5).

Таблица 9.5.

Карта модуля (имя)

Характеристики модуля (имя) Обозначения

Длина словаря операторов K

Длина модуля N

Объем модуля V

Уровень квалификации Q

Трудоемкость кодирования E

Технологичность текста T

В технологичность текста входит качественная оценка структуры модуля,

оформления текста в требованиях технологии, а также наличие переменных без ин-

дексов и изменение параметра цикла в теле цикла и др.

9.5. ТЕСТИРОВАНИЕ ПРОГРАММ И СБОР ДАННЫХ ОБ ОШИБКАХ

Процесс тестирования прикладных программ СОД по соответствующим ТЛ

включает следующие основные операции: составление плана тестирования;

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

и отладки; повторное тестирование.

В зависимости от того, кто проводит тестирование, рассматриваются три

режима:

1. проведение всех видов операций тестирования специальной группой;

2. совместное проведение работ по тестированию разработчиками и группой

тестирования, которая планирует, контролирует и принимает решение о

доработках;

3. выполнение работ по тестированию программ на процессах ТЛ.

Первые два режима не всегда выполнимы, как правило, из-за недостатка ресурсов

для образования группы тестирования. Поэтому в основном каждый коллектив

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

Таблица 9.6

Тест Таблица тестов Лист

Имя теста Тестовая ситуация Ожидаемая реакция

Таблица 9.7

Журнал регистрации ошибок (статистика)

Лист

Вид объекта

В том числе

Источник Тип

Тестируемый

элемент объекта

Количество

обнаруженных ошибок

1 2 3 4 5

6 7 8 9 10 11 12

280

Таблица 9.8

Журнал регистрации ошибок (время выполнения)

Лист

Дата Начало

сеанса,

час.,

мин.

Конец

сеанса

час.,

мин.

Номер

ошибк

Время

выявл

ения

Имя

теста

Тип Лист

Содержат

ельное

описание

ошибки

Дата

устране

ния

ошибки

Место

ошибки

Таблица 9.9

Журнал регистрации ошибок (сообщение об ошибке) Лист

Дата

обнаружения

ФИО

обнаружившего

Дата устранения Подпись

устранившего

Примечание

Описание ситуации:

Реакция на ситуацию :

Предположение об источнике ошибки:

Анализ ошибки и корректирующие действия:

Место ошибки: Тип: Источники:

Описание ошибки:

Описание исправлений:

Описание проверочного теста:

В рамках технологий ТЛ в целях соблюдения единства технологической

дисциплины может быть использован набор карт для отображения в них заданий

на тестирование отдельных модулей (табл. 9.6) или компонентов, собираемых из

модулей, и для регистрации ошибочных ситуаций (табл. 9.7 – 9.9) в ходе

тестирования.

Тестирование модулей и компонентов состоит в обеспечении на тестах

следующих критериев: прохождение каждого оператора не менее одного раза;

выполнение программы не менее одного раза на совокупности тестов,

включающих наборы входных и выходных данных; тестирование функций хотя бы

один раз; тестирование межмодульных интерфейсов. Тестирование программ по

ТЛ: вначале выполняется автономное тестирование модулей нижнего уровня без

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

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

затем тестирование в комплексе. Процесс повторяется до тех пор, пока не будет

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

тестирование корневого модуля совместно с заглушками, замещающими

непосредственно вызываемые им модули, затем после подсоединения (замещение

заглушки) в процессе тестирования выбирается очередной модуль. Процесс

продолжается до тех пор, пока не будут подсоединены и протестированы все