Создание прототипа интегрированного пакета оценки трудоемкости программного обеспечения тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат технических наук Токарев, Михаил Валентинович

• Токарев, Михаил Валентинович
• кандидат технических наук
• 1995

Оглавление диссертации кандидат технических наук Токарев, Михаил Валентинович

Введение.

Глава 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.5.2 Представительность диаграмм потоков данных.

25!з Нормы. Определения. Нормируемость иашин Колмогорова-Успенского.

2.6 Асинхронные вычислительные процессы.

2.7 Выводы.

Глава 3.

3 1 Структура и задачи главы.

3*2 требования предъявляемые к системам автоматизации.

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

3.2.2 САЗЕ-системы. Требования, концептуальная основа.

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 Выводы.

Введение диссертации (часть автореферата) на тему «Создание прототипа интегрированного пакета оценки трудоемкости программного обеспечения»

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

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

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

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

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

В России результатом работ по технологии программирования в рамках которых были созданы системы автоматизации разработки являются: ЯУЗА, РУЗА Г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, DFÜ) с помощью модели вычислений Колмогорова-Успенского для которых доказана представительность и разрешимость приведенных формальных заданий, а также их нормируемость.

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. Подтверждены основные необходимые свойства приведенной методики оценки без которых она не представляет значительного интереса*.

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

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

Список литературы диссертационного исследования кандидат технических наук Токарев, Михаил Валентинович, 1995 год

1. Агафонов В.H. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука, 1987. - 240 с.

2. Агафонов В.Н. Языки и средства спецификации программ (обзор) // Сборник статей "Требования и спецификации в разработке программ." М.: Мир, 1984, с. 285.

3. Баранов С.Н., Котляров В.П., Морозов Н.Б. Технология разработки программного обеспечения микроЭВМ: Расширяемые системы программирования. Учеб.пособие. Л.: ЛПИ, 1989.-96с.

4. Баранов С.Н., Ноздрунов Н.Р. Язык Форт и его реализация. Л.: Машиностроение, 1988. 198 с.

5. Боэм Б.Ц. Инженерное проектирование программного обеспечения: Пер. с англ. М.: Радио и связь, 1985. - 512 с.

6. Брукс Ф.П. Как проектируются и создаются программные комплексы. М.: Наука, 1979.

7. Вельбицкий И.В. Графический стиль и стратегия профессиональной технологии программирования // Тез. доклада II Всесоюзн. конф. "Технология программирования": информационные материалы. -Киев: ИК АН УССР, 1986.

8. Гейн К., Сарсон Т. Структурный системный анализ: средства и методы М.: Эйтекс, 1992.

9. Грис Д. Наука программирования: Пер. с англ. М.: Мир,1984. -416 с.

10. Деморович Я., Кнут Е., Радо П. Автоматизированные методы спецификации: Пер. с англ. М.: Мир, 1989. 115 с.

11. Евстигнеев В.А. Применение теории графов в программировании. // Под ред. Ершова А.П., М.: Наука,1985.

12. Евстигнеев В.А., Кожевникова Г.П. Сложность программ: топологические меры, основанные на понятии управляющего графа // Отчет N АТИ-ПГ 359/03. Новосибирск: НФ ИТМ и ВТ, 1985. - 37 с.

13. Евстигнеев В.А., Кожевникова Г.П. Сложность программ: топологические меры, не использующие понятия управляющего графа / Отчет N 362/04. Новосибирск: НФ ИТМ и ВТ, 1985.-56 с.

14. Ершов А.П. Отношение методологии и технологии программирования // II Всесоюзн.конф. "Технология программирования": Информационные материалы. Киев: ИК АН УССР, 1986. -с.10-12.

15. Глушков В.М. Введение в кибернетику Киев: Изд-во АН УССР, 1964.-324 с.

16. Зиглер К. Методы проектирования программных систем. -М.: Мир, 1985.

17. Зиглер. Методв проектирования программных систем: Пер. с англ. М.: Мир, 1985.

18. Иткин В.Э., Котляров В.П. Вопросы конструирования устойчивых алгоритмов на базе многовыходных модулей // Актуальные вопросы технологии программирования. JI. ЛИИАН, 1989.-с.36-48.

19. Кальянов Г.Н. CASE: Компьютерное проектирование программного обеспечения М.: НЦИЭ ИнтерЭВМ, 1990, 115с.

20. Картис Б. Измерения и эксперименты в проектировании программных средств // ТИИЭР, 1980. т.68. - N 9. - М.: Мир, -с. 129-145.

21. Программное обеспечение ЭВМ // АН БССР, Институт математики, 1988 вып. 79.

22. Коллинз Г., Блэй Дж. Структурные методы разработки систем: от стратеги-ческого планирования до тестирования. М.: Финансы и статистика, 1986.

23. Колмогоров А.Н. Теория информации и теория алгоритмов. -М.: Наука, 1987.-304с.

24. Колмогоров А.Н., Бардзинь Я.М. О реализации сетей в трехмерном пространстве // Проблемы кибернетики. 1967, вып. 19. - М.: Наука. - с. 261-268.

25. Колмогоров А.Н., Успенский В.А. К определению алгоритма //Успехи математических наук, 1958. т.13, вып.4. - с. 3-28.

26. Котляров В.П. Технология программирования персональных ЭВМ и микропроцессорных систем для встроенных применений // II Всесоюзн.конф. "Технология программирования": Информационные материалы. Киев: ИК АН УССР, 1986.-с.43-51.

27. Котляров • В.П. Фрагментно-модульная технология программирования // Вопросы технологии программирования. Л.: ЛИИАН, 1988. с.74-105.

28. Котляров В.П. САБЕ-технологии и возможности современных СА8Е-средств в поддержке этапов проектирования программного продукта // Системная информатика Новосибирск: (Наука), 1994 - вып. 4: методы теоретического и системного программирования - с.272-307.

29. Котляров В.П., Питько А.Е., Розман М.М. Диалоговая система разработки ПО управляющих микроЭВМ по сборочной фрагментно-модульной технологии программирования // Вопросы технологии программирования. Л.: ЛИИАН, 1988. - с.106-109.

30. Котляров В.П., Розман М.М. Подход к спецификации программного обеспечения управляющих применений микроЭВМ // Инструментальные средства поддержки программирования. Л.: ЛИИАН СССР, 1988. - с. 143-152.

31. Котляров В.П., Токарев М.В. Оценка трудоемкости программного проекта в системе сборочного программирования // Сб. ШВсес.семинар "Качество программного обеспечения", Дагомыс, Тез. докл. М: СНПО "Алгоритм", 1991.

32. Котляров В.П., Токарев М.В. Управление, проектированием программного продукта в интегральной системе типа СА$Е1. // Материалы семинара "САБЕ технология". ~М.: ЦРДЗ. -1993.

33. Липаев В.В. Качество программного обеспечения. М.: Финансы и статистика, 1983. - 262с.

34. Липаев В.В. Тестирование программ. М.: Радио и связь, 1986. - 296 с.

35. Липаев В.В., Потапов П.И. Оценка затрат на разработку программных средств. М.: Финансы и статистика, 1988. -224с.

36. Майерс Г. Надежность программного обеспечения: Пер. с англ. М.: Мир, 1980. 360с.

37. Муса Д.Д. Измерение и обеспечение надежности программных средств // ТИИЭР, 1980. - т.68. - N 9 - М • Мир -с. 113-128.

38. Непомнящий В.А., Рякин О.М. Прикладные методы верификации программ. М.: Радио и связь, 1988. - 256 с.

39. Пайл Я. Ада язык встроенных систем: Пер. с англ. - М.: Финансы и статистика, 1984. - 237 с.

40. Перечень основных директивных и нормативно-методических документов по технологии программирования // II Всесоюзн. конф. "Технология программирования": Информационные материалы. Киев: ИК АН УССР, 1986. - с. 87-91.

41. Проблемно-технологический комплекс Комфорт. Комплект документации / ОФАП "Красная заря" per.N 012.00211-01 1987.

42. Розман М.М. Методы и средства поддержки ранних стадий проектирования программного обеспечения в расширяемых системах автоматизации программирования контроллеров, Диссертация на соискание степени к.т.н. по специальности 05.13.11 -Л.Ж 1990-278с.

43. Росс Д. Структурный анализ (SA): язык для передачи понимания // Сборник статей "Требования и спецификации в разработке программ." М.: Мир, 1984, с. 240. •

44. Сафонов В.О. Языки и методы программирования в системе "Эльбрус" -М.: Наука, 1989 -392с.

45. Слисенко А.О. Сложностные задачи теории вычислений // Успехи математических наук, 1981. - т.36, вып.6(222) - с 21103.

46. IEEE Standarts Collection. Software Engineering // IEEE Standarts For Software Productivity Metric. 1045-1992, IEEE

47. Standarts For Software Quality Metrics Metodologic. 1061-1992 -N-Y.: Edition IEEE Inc., 1993.

48. Тассел Ван Д. Стиль, разработка, эффективность, отладка и испытания программ: Пер. с англ. М.: Мир, 1985. 332 с.

49. Токарев М.В. Методика проектирования расширяемых встроенных типов данных для сборочной системы программирования. // Сб. научных трудов. -С.Пб.: СПбГТУ N442, 1992.

50. Успенский В.А., Семенов А.Л. Алгоритмы, или машины, Колмогорова // Колмогоров А.Н. Теория информации и теория алгоритмов. М.: Наука, 1987. с. 279-289.

51. Успенский В.А., Семенов А.Л. Теория алгоритмов: Основные открытия и приложения. М.: Наука, 1987. - 288 с.

52. Фокс Дж. Программное обеспечение и его разработка: Пер. с англ. М.: Мир, 1985. - 386 с.

53. Холстед М.Х. Начала науки о программах: Пер. с англ. М.: Финансы и статистика, 1981. - 128 с.

54. Шнейдерман Б. Психология программирования: Человеческие факторы в вычислительных и информационных системах: Пер. с англ. -М.: Мир, 1973. 280 с.

55. Штрик CASE: Машинное проектирование программного обеспечения -М.: НЦИЭ ИнтерЭВМ, 1990 115с.

56. Янг С. Алгоритмические языки реального времени: конструирование и разработка: Пер. с англ. М.: Мир, 1985. -400с.

57. Boehm В. Software Engineering. IEEE Transaction on

58. Computers, 1976, - V.5. - p. 25.

59. Boehm В W Verifying and Validating Software Requirements and Design Specifications // IEEE Software. 1984. - V. 1. - N1. - p. 8898.

60. Cristian F Correct and Robust Programs//IEEE Transactions on Software Engineering. 1984. - V SE-10. - N2. - p. 163-174.

61. Gridy R.P. Practical Software Metrics For Project Management And Process Improvement BTR. -N-Y.: Printes Hall Inc., 1992270p.

62. Gries D. Modules for Re-Use // Lecture Notes in Computer Science. 1987. - V.287. - p. 373-375.

63. Hamphry H.U. Managing The Software Process, Software Engineering Instityte // Addison WESLEY, Publ. сотр. -1989. -494p.-//JT

64. Harrison W. Software Complexity Metrics: a Bibliography and Category Index // SIGPLAN Notices. 1984. - V.19. - N 2. - p. 17-27./

65. Knuth D.E. Literate Programming // The Computer Journal 1984. V.27 - N2 - p.97-111.

66. Meyer B. On Formalism in Specifications // IEEE Software. 1985&-V. 2.-Nl.-p. 75-88.

67. Names В., Farr L. Some Cost Contribytors to Large-Scale Programs // AFIPS Proceedings, SJCC Springer Verlag, 1964. -N25.-p. 239-248.

68. Nanus В., Farr L. Some cost contributors to large scole Programms. - AFIPS Proc. SJCC, Spring 1964, N25, p. 233-248.

69. Richard A. Zahniser Design by Walking Around // Communication of the ACM. Octuber, - 1993.- p. 56.

70. Stubbs M. A New Notation for Dataflow Specifications // IEEE on Transaction and Software Engineering, 1992. - V.8. - N 1. p. 159-172.

71. The Computer Journal. 1987. - V.37. - N 3.

72. Vernik R.J., Turner I. Techniques and Tools for Analysing Software Products // IEEE on Transaction and Software Engineering, 1992. - v.24. - N 3. - p. 98-105.

73. Weinwurm G.F. Research in the management of computer programming. Report SP - 2059, System Development Corp., Santa Monica, 1965.

74. Wolf A.L., Clarke L.A., Wileden J.C. Ada Based Support for Programming-in-the-Large// IEEE Software. 1985. - V2 - N2 p.58-72

75. Workman D.A. GRASP: A Software Development System // Software Practice and Experience. 1984. - VI3 - N1 - p. 17-32.

76. CASE.AHattHTHK для IBM PC. // Руководство пользователя. -M.: ЭЙТЭКС, 1993, с. 1-24.

77. Pokrovski S.B., Stepanov G.G. HYPERTEXT as environment foi-software development, Proc. IV Simp., INFORMATICA'91 (Grenoble, Fran.), INRIA. 1991, p. 144-150.