Создание прототипа интегрированного пакета оценки трудоемкости программного обеспечения

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

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

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

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

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

В России результатом работ по технологии программирования в рамках которых были созданы системы автоматизации разработки являются: ЯУЗА, РУЗА Г36, 37, 38], РИТМ-технология [231. Р-технология Ш и ТИП Г 47.1.

Из фундаментальных работ зарубежных авторов наиболее известны работы Института программного инжиниринга (БЕ!) (52, 641, где в 1986 году была инициирована работа по усовершенствованию проектирования программного обеспечения. Основной целью данной работы являлась выработка рекомендаций, позволяющих управлять качеством проектирования.

Были выдвинуты пять уровней квалификации программистских кол лсктивов (рис. 1.1):

1. Начальный:

2. Уровень повторяемости:

3. Уровень определения:

4. Управления:

5. Оптимизации.

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

Рис. 1.1 5 уровней.

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

В работах SKI периода 1986;1992 годов [62, 641 были разра бптаны процедуры, поддерживающие проектирование ПО, рекомендации коллективам разработчиков, предложены модели проектирования, документация, способы оценивания текущего состояния проекта и его качества, а такие специальные вопросники для выяснения уровня раз вития коллектива программистов.

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

Существует множество моделей жизненного цикла ПО. Рассмотрим наиболее распространенные.

Первая модель, показанная на рис. 1.2, 1.3 внедрена в круп нейших фирмах (ПР. Motorola) [621. На ней представлены все этапы ШЦ. а также процессы, поддерживающие все эти этапы. Па рисунках подробно представлен этап проектирования, а такие некоторые базо вые модели программных средств.

Следующая модель построена на основе стандарта SSftOli, она по казана на рис. 1.4.

В России модель ШЦ определена Гостом (ГОСТ 601 90), кото рый вводит следующие этапы жизненного цикла:

1. формирование требований к программной системе:

2. разработка концепции системы:

3. разработка технического задания:

АНАЛИЗ ТРЕБОВАНИЙ.

ПРОЕКТИРОВАНИЕ.

РАЗРАБОТКА.

ИНСТАЛЛЯЦИЯ.

ПОДДЕРЖКА.

ПЛАНИРОВАНИЕ.

УПРАВЛЕНИЕ ПРОЕКТОМ.

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

ДОКУМЕНТИРОВАНИЕ.

Рис. 1.2 Жизненный цикл ПО и поддерживающие его процессы.

— у.

Предварительное проектирование.

Детальное проектирование.

Кодирование и тестирование модулей.

Интеграция и тестирование.

Системные интеграция и тестирование.

Рис. 1.3 Жизненный цикл ПО: этап проектирования.

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

Выбор варианта автоматизации.

Разработка технического задания.

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

Разработка логического проекта.

Физическое проектирование.

Рис. 1.4 Жизненный цикл ПО: стандарт ББА ПМ.

4. эскизный проект;

5. технический проект;

6. рабочая документация;

7. ввод в действие;

8. сопровождение.

Так как все эти модели во многом схожи, в дальнейших рассуз 4 дениях будем опираться на первую модель (рис. 1.2, 1.3). как паи более полную и распространенную во всем мире.

Рассмотрим некоторую интерпретацию модели й! Ц, предлояенную в работе [291 (рис. 1.5). На этом рисунке в стилизованном виде изобретен процесс разработкиПО. На входе — требования к программному продукту, на выходе готовый программный продукт. Заиленные участки этой «грязной трубы» (т.е. процесса проектирова ния) моделируют отсутствие средств инструментальной поддервки со ответствующей фазы. На них выходной поток готовой продукции ничтожно мал. Заилеиность моделирует и те участки, которые достаточно инструментированы, но работают не в полную силу, их ресурсы используются ограниченно, что приводит к дополнительным затратам. Модель «грязной трубы» показывает, что производительность разработки программного изделия определяется наиболее «заиленными» (неавтоматизированными) этапами, среди которых особо следует выделить этап проектирования. Очевидно, что на этом этапе затрачивается на ибольшее количество усилий и эта стадия наименее подде^аивапа инструментально. Действительно, существует большое число транслято ров, оптимизаторов, средств автотестирования, которые, в последнее время, были дополнены пакетами автоматической генерации кода по спецификациям. Однако они еще не дают решающих преимуществ. Ошиб ки, возникающие на стадии проектирования наиболее трудноустранимы (или неустранимы вообще). Их цена слишком велика (см. рис. 1.6).

Обратная связь по параметрам оценочных формул.

Прямая связь — прогнозирование харях теристик Ь.

Программный продукт.

Рис. 1.5 Жизненный цикл программы. п г.

Относительные затраты на исправление ошибки анализ проектирокодирование испытали* эксппуататребований валие ция.

Рис. 1.6 Сравнительные затраты на исправление ошибки, возникшей в процессе разработки ПО.

Г61, Понтону данная работа посвящена разработке технологии СО-Здания программного продукта, пбегприираш"р$ ВОЗМОЖНОСТЬ пчр-««. г. р-ния качегт^ом на раннихтанах проектирования программного изделия^тап проектирования программного обеспечения выбран в силу его слабой поддержки. Далее будет показано, что многие фирмы работавшие над этой проблемой, хотя и предлагашт много частных методик и инструментальных средств, но, к сожалении, слишком трудоемки или слишком дороги. Инструменты, поддерживающие такие методики часто называют CftSE-средстваыи.

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

В процессе достижения цели решены следующие задачи,.

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

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

3. Обосновано применение метрик и методов в процессе оценки характеристик программного продукта.

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

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

— У/ленные задачи.

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

Научней новизну предетавляшт предложенные автором: формальная представительная модель спецификации, полученная как частный случай алгоритма Колмогорова-Успенского;

2. формализация диаграмм потоков данных и «сущность-связь» на основе предложенной методики;

3. обоснование корректности использования норм в области Формального задания спецификаций;

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

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

Общий объем разработанного ПО составил около 200 Кбайт объем разработанных и исследованных спецификаций — более 2 Мбайт.

Основные результаты работы докладывались и обсуждались на семинарах РГТП МП! при ГШ’Й, СЦСО PftH («Новосибирск), ЯВИ РСФСР.

Методика оценки качества программного обеспечения, использущ-щая формализованное представление спецификаций внедрена б АО «Интел тех, ШШП, СПбГТЗ.

Основные определений.

Приведем базовые определения, использованные в работе [4 $К.

Цикл аизни программного обеспеченна — период времени, который начинается когда программный продукт задумывается и заканчивается когда ПО перестает использоваться. Цикл жизни обычно состоит изобщего представления, требований, проектирования" кодирования, тестирования, инсталляции, поддервки и сопровождения, Эти Фазы могут перекрываться.

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

Метрика — количественная оценка характеристики г атрибута) системы, ее компоненты или процесса.

Метрика качества — количественная оценка атрибута качества ПО.

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

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

База данных или репозиторий — совокупность связанных данных, запоминаемых вместе в одном или более компьютерных файлах.

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

Проектные требования — требования которые определяет или специфицируют проект системы или ее компоненты.

Проектная спецификация — документ, описывающий проект системы или компоненты и содержащий описание архитектуры, управляющей логики, структуры данных, форматы ввода/вывода, интерфейсы.

ГЛнВЙ I.

4″? Выводы.

В данной главе была рассмотрена конкретная методика проведения оценки характеристик проектов".

После краткого описания исследуемых проектов был проведен подсчет метрик качества всех вариантов проектов на нескольких стапках жизненного цикла. Затем, испопьчпа пакет эпйктппинку та 5 лит;

Г, МГ-!УКЛ."П!Г.Ь УаПГ. ТГТРПИСТИКИ Г-тптт^ПР ГП ТПГ* ГГ. — V.—п г" .-, г 7т/ч, Кг., Янлаг-ва).

П п к л г лкп ппнп ап опшгику ггг. Лг-г «-т-.-:.. , — ,.

-<- и а. равных •мапа.у «П. что позволило не просто паижмро-Гчг.т1» «-.дриаНТЫ на каПиМ либо этапе, яг? я. на иплгр поздних г тапки*' ппптрррдкт!, прагилмюсть выбора ~ой или ияой разработки. рдее одним вазгнрйшим свойством данной ыг т («л к «-'к ч}?- лурт.' ¦.- «-"•-. ипяппгти КР.падиг.ппалис г. мршти. и г, к глтоплй г-, .-:.-,.-••. •: .. г «» «.

ЖНО ?-.агпал1,зог.атьс.Т п ло прппгкг^оННЯ теч ИЛИ ИНЫХ ХараКТО ристик качества на ранних стадиях проектирования программ подобной сложности".

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

— т тимся к рис. 4Л п<. Здесь видно, что оценки, получаемые по Поэму или Пипаеву более точны, чем холстедовские. Но если первые нельзя использовать на этапе разработки спецификации, то холстедовские можно, Поэтому предлагается на этом этапе ИЩ недостающие оценки в Формулах Поэма и Яипаева считать по Холстеду, В результате точность возрастает в 2−3 раза.

Необходимо отметить, что до написания этой работы авторами других работ [20, 32, 33, 401 начинались исследования в этой области и некоторые свойства этих оценок узе были проверены для 1 проектов средней сложности.

Заключение

.

Таккн образом в работе было сделано сл едущее:

1, Па основе анализа современных средств инструментальной поддераки сформулирована основные требования, который должны удовлетворять СЙБЕ-снстеыи.

2, Выявлены недостатки существующих СЙ$Е-средств в части возможности получения оценки характеристик ПО и управления качеством ПО на всем протяжении жизненного цикла, начиная с ранних стадий создания формальных спецификаций,.

3″ Для теоретического обоснования разрабатываемой методики сделано следунщее:

— определен специальный вид колногоровскнх (П, к)-комп-ленсов, позволявший формально описать и интерпретировать основные объекты языка спецификацийпредложена конкретизация (Б, к)~конплексов в виде формального задания спецификаций С СТО, КПП, ПГО);

— доказана представительность введенных формальных заданий ;

— дано более узкое определение вычислительного процесса по отношении! к колногоровсконц;

— доказана возможность нормирования качественных характеристик введенных формальных заданий".

4, Разработаны метрики и методы оценки характеристик формальных спецификаций, созданных на базе требований к проектирдеионд ПО, Для этого:

— проведен анализ методов оценки объемных характеристик.

ПО;

— обосновано применение конкретных метрик качества 110,.

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

8. Разработана методика создания формальных спецификаций" вкличанщая в себя возможность оценки, отслекивания и управления объемными характеристиками ПО* ранжирования альтернативных вариантов одного и того же проекта или его части исходя из оценки их трудоемкости, Проведены исследования по применении данной методики на двух проектах средней сложности.

8. Подтверждены основные необходимые свойства приведенной методики оценки без которых она не представляет значительного интереса*.

— сопоставимость оценок на различных этапах проектированияинвариантность их относительно используемой методики подсчета характеристиксходимость оценок с развитием проекта к определенной реальной величине;

— инвариантность методики относительно языка на котором реализованы спецификации. д На основе результатов исследований предложен рациональный подход к оценке трудоемкости проекта, основанный на порядке применения в измерительном процессе метрик Холстеда, Боэма и Липаева для дос тижения большей точности оценок.