Содержание к диссертации
Глава 1.
1.1 Структура и задачи главы.
1.2 Обзор CASE-технологий
1.2.1 Модели программных средств, используемые в CASE системах.
1.2.2 Сравнение характеристик существующих CASE-средств.
1.2.3 CASE-система фирмы McDonnel Douglas Corporation.
1.3 Некоторые технологические аспекты, использующиеся в фирме HP.
1.3.1 Фазы жизненного цикла программного проекта.
1.3.2 Использование стандарта SEI для управления качеством проектирования.
1.4 Качественные характеристики программ и возможность количественного анализа.
1.5 Выводы.
Глава 2.
2.1 Структура и задачи главы.
2.2 Основные определения последовательных вычислительных процессов, в вычислительной модели Колмогорова-Успенского.
2.2.1 Общие понятия.
2.2.2 Распространение понятия "конструктивный объект" на структуру, состоящую из конструктивных объектов.
2.2.3 Вычисления с оракулом.
2.3 Графы как модели объектов.
2 4 Диаграммы сущность-связь (ER-диаграммы).
2.4.1 Общие понятия.
2 4.2 Конкретизация понятия состояния машины Колмогорова-Успенского.
2.5 Диаграмма потоков данных (DF-диаграммы).
2.5.1 Общие определения.
2Л2 Представительность диаграмм потоков данных.
25ІЗ Нормы. Определения. Колмогорова-Успенского.
2.6 Асинхронные вычислительные процессы.
2.7 Выводы.
Глава 3.
3 1 Структура и задачи главы.
3 2 Требования предъявляемые к системам автоматизации.
3.2.1 Необходимые качества спецификаций программных продуктов.
3.2.2 CASE-системы. Требования, концептуальная основа.
3.3 Методика проектирования программного обеспечения.
3.3.1 Основные этапы проектирования.
3.3.2 Формализация этапов проектирования.
3.3.3 Методика оценки характеристик качества проекта.
3.4 Описание инструментальных средств.
3.4.1 Построитель контекстных диаграмм.
3.4.2 Редактор потоковых диаграмм.
3.4.3 Пакет оценки характеристик.
3.5 Требования к разработке ПО и необходимые ограничения на каждом этапе проектирования.
3.6 Принципы построения контекстных и потоковых диаграмм.
3.6.1 Требования к разработчику при проектировании системы с помощью диаграммера.
3.6.2 Требования к разработчику при проектировании системы с помощью редактора гипертекстов.
3.6.3 Требования к разработчику при использовании пакета управления качеством проектирования.
3.7 Получение метрик качества и оценок норм емкости и трудоемкости.
3.8 Выводы.
Глава 4.
4.1 Структура и задачи главы.
4.2 Применение методики оценки и оценочные формулы.
4.3 Краткая характеристика проектов использованных в процессе оценки.
4.3.1 Система автоматического контроля и управления газопроводом.
4.3.2 Система слежения за воздушными объектами.
4.4 Анализ альтернативных вариантов системы автоматизации
контроля и управления газопроводом.
4.5 Рассчет характеристик проектов по предлагаемой методике.
4.5.1 Оценка вариантов разработки первого проекта.
4.5.2 Оценка вариантов разработки второго проекта.
4 6.Результаты оценки проектов по предлагаемой методике
4.7 Выводы. Заключение.
Приложение А. Рассчетные таблицы.
Приложение Б. Основные понятия метрологии программ.
Приложение В. Формулы рассчета трудоемкости проектов.
Введение к работе
В технологии производства любого продукта вакнейшую роль играет инструментальное обеспечение процесса. Причем инструментарий должен быть удобным в использовании, интегрированным и, как минимум, позволять получать высококачественный продукт.
Все вышесказанное целиком относится и к такому специфическому продукту как программное обеспечение (ПО). Однако, в отличие от обычного производства, инструментарий, применяемый при проектировании ПО, намного сложнее в следствие размытости качественных характеристик производимого продукта и трудности создания однозначных формальных требований к нему.
Поэтому, в последнее десятилетие, в нашей стране и за рубежом, наметилась приоритетная ниша применений - поиск или создание интегрированных инструментальных средств поддержки проектирования ПО, позволяющих не просто измерять качество конечного продукта, но и управлять им.
Для выполнения задачи получения качественного продукта необходимо уделять должное внимание этому начиная г. начальных этапов проектирования НО. Практически все средства поддервки проектирования имеют возмокность отслеживать качественные характеристики на том этапе когда создан прототип системы или когда она полностью создана. Конечно полезно знать какие качественные параметры имеет вновь созданное ПО, однако . очевидно, что по реализации продукта изменение его качества представляет из себя трудноразрешимую (или даже невыполнимую) задачу.
531954
В дайной диссертационной работе сделана попытка не только оценивать качественные характеристики для сравнения проектов, по и управлять качеством проектирования во время разработки прогдщшхтго средства. Необходимо разработать методику и программные сред ства позволяющие отслеживать качество ПО начиная с самых жизненного цикла ПО, и управлять качеством на основе накоп ленных статистических данных по проектам.
В России результатом работ по технологии программирования в рамках которых были созданы системы автоматизации разработки являются: ЯУЗА, РУЗА Г36, 37, 38], РИТМ-технолгігия Г231. Р-технология Ш и ТИП [47.1.
Из фундаментальных работ зарубежных авторов наиболее известны работы Института программного инжиниринга (SFI) (62, 641, где в 1986 году была инициирована работа по усовершенствованию проектирования программного обеспечения. Основной целью данной работы являлась выработка рекомендаций, позволяющих управлять качеством проектирования.
Были выдвинуты пять уровней квалификации программистских кол лективов (рис. 1.1):
1. Начальный:
2. Уровень повторяемости:
3. Уровень определения:
4. Управления:
5. Оптимизации.
На первом уровне процесс проектирования традиционный хаотический, в котором документация обеспечивает сдачу готового продукта, но не обеспечивает никаких процедур достижения гарантиро ванного уровня качества программного продукта. Па второй появляется планирование, отслеживание результатов, обзоры качества продукта. На третьем уровне внимание направляется на определение и организацию процесса проектирования, интегрированного управления этим процессом и координацию групп программистов между гобой. На следующем уровне находятся те коллективы которые могут управлять качеством"проектирования при помощи строго документированных процедур, инструментов и методологий. И наконец, на пятом уровне появляется возможность оптимизации всех составляющих процесса проектирования, начиная с начальных стадий жизненного цикла (ИЩ) программного обеспечения (ПО).
В работах SKI периода 1986-1992 годов 162, 641 были разра ботаны процедуры, поддерживающие проектирование ПО, рекомендации коллективам разработчиков, предложены модели проектирования, документация, способы оценивания текущего состояния проекта и его качества а такие специальные вопросники для выяснения уровня раз вития коллектива программистов.
Из отмеченного выше видно какое большое значение уделяется в мировой практике процедурам, технологиям, позволяющим оценивать качественные характеристики ПО.
Существует множество моделей жизненного цикла ПО. Рассмотрим наиболее распространенные.
Первая модель, показанная на рис. 1.2. 1.3 внедрена в круп нейших фирмах (HP, Motorola) [621. На ней представлены все этапы ШЦ, а также процессы, поддерживающие все эти этапы. Па рисунках подробно представлен этап проектирования , а такие некоторые базо вые модели программных средств.
Следующая модель построена на основе стандарта SSftUli, она по казана на рис. 1.4.
В России модель ІІІЦ определена Гостом (ГОСТ 34.601 90), кото рый вводит следующие этапы жизненного цикла:
Так как все эти модели во многом схожи, в дальнейших рассуз дениях будем опираться на первую модель (рис. 1.2, 1.3). как паи более полную и распространенную во всем мире.
Рассмотрим некоторую интерпретацию модели й!Ц, предлояенную в работе [29] ( рис. І.З ). На этом рисунке в стилизованном виде изображен процесс разработки__ПО. На входе — требования к программному продукту , на выходе готовый программный продукт. Заиленные участки этой "грязной трубы" (т.е. процесса проектирова ния) моделируют отсутствие средств инструментальной поддерїзкм со птветствующей фазы. На них выходной поток готовой продукции ничтожно мал. Заилеиность моделирует и те участки, которые достаточно инструментированы, но работают не в полную силу, их ресурсы используются ограниченно, что приводит к дополнительным затратам. Модель "грязной трубы" показывает, что производительность разработки программного изделия определяется наиболее "заиленными" (неавтоматизированными) этапами, среди которых особо следует выделить этап проектирования. Очевидно, что на этом этапе затрачивается на и большее количество усилий и эта стадия наименее поддсряивана инструментально. Действительно, существует большое число транслято ров, оптимизаторов, средств авто тестирования, которые, в последнее время, были дополнены пакетами автоматической генерации кода по спецификациям. Однако они еще не дают ремашщих преимуществ. Оыио" ки, возникающие на стадии проектирования наиболее трудноустранимы ( или неустранимы вообще ). Их цена слишком велика .
Разработан программный комплекс в виде прототипа интегрированного инструментария, позволяшщего автоматизировать вышепостав -ІІ ленные задачи.
5. Методика и инструментальный пакет были использованы при разработке трех проектов средней слоаности (10 %5 строк).
Научной новизну предетавляшт предложенные автором:
1. формальная представительная модель спецификации , полученная как частный случай алгоритма Колмогорова-Чепенского;
2. формализация диаграмм потоков данных и "сущность-связь" на основе предложенной методики;
3. обоснование корректности использования норм в области Формального задания спецификаций;
4. методика подсчета объемных и топологических метрик по соот-в е т с т в у шщиа с пецификациям;
5. методика оценки объемных и топологических характеристик проекта или его частей и их нормирования;
6. результаты исследования конкретных проектов по предложенной методике.
Практическая ценность работы определяется созданием прототипа интегрированной системы отслеживания и управления качеством программных проектов на основе собираемой в процессе проектирования и по его окончании информации, поддержкой разработки Формальных спецификаций на проект; методикой проектирования продуктов при использовании сборочной технологии; метрическим обеспечением процесса проектирования..
Общий объем разработанного ПО составил около 200 Кбайт объем разработанных и исследованных спецификаций — более . МГмйт.
Методика оценки качества программного обеспечения, использущ-щая формализованное представление спецификаций внедрена Б НО "ИН-телтех", ШОДнП, СПбГТЗ.
Основные определений.
Приведем базовые определения, использованные в работе [4S1.
Цикл мизни программного обеспечения — период времени,, который начинается когда программный продукт задумывается и заканчивается когда ПО перестает использоваться. Цикл ЖИЗНИ обычно состоит из; общего представления, требований, проектирования» кодирования, тестирования, инсталляции, поддержки и сопровождения, Эти Фазы могут перекрываться.
Программный инструмент — компьютерная программа используемая при проектировании, тестировании, анализе или сопровождении программы или документации к ней.
Метрика — количественная оценка характеристики системы, ее компоненты или процесса.
Метрика качества - количественная оценка атрибута качества ПО.
Функциональная декомпозиция — тип модульной декомпозиции, в которой система разбивается на компоненты в соответствии с системными функциями и подфункциями.
Структура данных — физическая или логическая связь между элементами данных, спроектированная для поддержки Функций манипулирования специфическими данными.
Паза данных или репозиторий — совокупность связанных данных, запоминаемых вместе в одном или более компьютерных файлах.
Проектирование — процесс определения архитектуры, компонент, интерфейсов и других характеристик системы.
Проектные требования — требования которые определяет или специфицируют проект системы или ее компоненты.
Проектная спецификация — документ, описывающий проект системы или компоненты и содержащий описание архитектуры, логики, структуры данных, форматы ввода/вывода, интерфейсы
