автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Создание прототипа интегрированного пакета оценки трудоемкости программного обеспечения

CftHKT--ПЕТЕРПУРГСКЯИ ГОСНДАРСТПЕИНЫЙ ТЕХНИЧЕСКИЙ НИИВКРСКТЕТ

? Г15 uTi " ...........

; На крапах рукописи.

ТОКАРЕВ Михаил Валентинович

!1/|К 6Я1.3

СОЗДАНИЕ ПРОТОТИПА ИНТЕГРИРОВАННОГО ПАКЕТА ОЦЕНКИ ТРНЛОЕШСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Специальность 03.13.11 "Иатеиатичоское и программное обеспечение вычислительных иааин, комплексов, систем и сетей"

АВТОРЕФЕРАТ

диссертации на соискания дчсной степени . кандидата технических наук

САПКТ-НЕТЕРВИРГ 139Я

Работа выполнена в Санкт-Петербургском государственном техническом университете.

Научный руководитель: кандидат технических наук, дошит, заведующий лабораторией Котляров Б, П.

Официальные оппоненты: доктор технических наук, профессор Доыарацкий А. Н., кандидат технических наук Скоеарев О. И.

Ведунья организация: ^ Научно-производственное об"единение "Импульс".

Защита состоится "_"__1995г. в__часов

на заседании специализированного совета К 063. 38. 07 в Санкт-Петербургском государственном техническом университете по адресу: 195251, С-Петербург, Политехническая

ул. , Д. 2Я, _ уч. корп. , ауд._.

О диссертацией можно ознакомиться в Фундаментальной библиотеке университета.

Автореферат разослан _"__1996г.

Ученый секретарь

специализированного

совета.

/

ОБЩАЯ Ш'ШЕРШ'.ТИМ РПБОТН

Агстдальность гвин. Трудно найти такие сферы чплппочос-кой деятельности кипа "ы не проникли в том или ином окне компьютерные технологии. Эти технологии находят применение и в больиих системах, таких как системы диспетчеризации полетов, и в отдепышх узлах управления технологическим оборудованием распределении* систем. Разрабатнпаемне программные систем» предназначаются и для микропроцессоров и для больших вычислительных кпнплпкепп.

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

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

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

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

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

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

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

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

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

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

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

н

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

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

6. Методика и инструментальный пакет были использованы при разработке трех проектов средней слоншости С10*#!) строк).

Методы исследования. Иоставлешше в диссертациоиной работе задачи реиавтея на ochorb теории графов представительных вычислительных моделей Колмогорова-Успенского н метрической теории алгоритмов.

Научная новизна, Научиув новизну представляют предложенные в диссертационной работе:

• 1. Формальная представительная иодеяь спецификации, полученная как частный случай алгоритма Колмогорова-Успенского.

2. Формализация диаграмм потоков данных и "суцность-связь" на основе предложенной модели.

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

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

5. Методика оценки объемных и топологических характеристик проекта или его частей и их нормирования на основе сбора и обработки статистической информации, получаемой после реализации проектов и уточнения оценок.

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

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

G

среда в tiüSBúMUia снизить трудоемкость проектирования ПО при сокращении сроков разработки и улучшении качества выпускаемого продукта за счет экономии ресурсов при отладке и сонропождении 110 и переноса усилий по улучшению качества па более ранний этапы жизненного цикла 110,

Реализация резулыатов работы. На базе инструментальных систем HYPERTEXT, ANALYTIC и КОМФОРТ и пакета оценки качества создан прототип интегрированной технологической системы для проектирования прш раымного обеспечения, включавшая в себя элементы управления качественными характеристиками спецификаций и 110. Обций объем разработанного ПО составляет около 200 Кбайт, объем разработанных и исследованных спецификаций — 2 Мбайта.

Апробация работа. Основные результаты работы докладывались и обсуждались на семинарах РГТ11 Ш1Т при ГКВТИ, ВЦ СО РАН (Новосибирск), .МИ АН РСФСР (С.-Петербург), кафедры "Информационные и управляющие системы С116ГТ9.

Методика оценки качества программного обеспечения, исполь-зуюцая формализованное представление спецификации на программный продут внедрена и ПИНАН, СПбГТУ, ftOOT "Интелтех" г. С.-Петербург.

Публикации. Но материалам диссертационной работы опубликовано 6 печатных работы, одна работа находится в печати.

Структура и объем работы. Диссертация состоит из введения, четырех глав и трех приложений. Список использованной литературы содержит ОС наименований. Текст диссертации содержит 130 страниц машинописного текста, ÜB рисунков и 18 таблиц.

СОДЕРШИЕ РАВОТЙ.

Во введении отмечена актуальность темы диссертационной работы, определены ее цели и задачи, перечислены научные и практические положения, выносимые на зациту, а также даны определения основных понятий согласованных со стандартами IEEE, ANSI и ЕСПД.

В первой главе рассмотрен взгляд на технологив программирования с точки зрения качества проекта, возможности управление им, а также рассмотрены типовые инструментальные CílSE-пакети приз-

ванные помочь разработчику при0проектиротшши больвих программных комплексов.

В первой пункте глава приведена сравнительная характеристика существующих CflSE-средств с ((сльи вменения средств управления проектом и отмечена слабая ноддерика этого требования в coupe, мешшх CUSE. Здесь ае рассматривается «дна из известных систеи, разработанная Фирмой ИсПоппе] Douglas Corp. и продстопляичая из себя наиболее разоитуп инструментальную среду поддоркки проектирования ПО, включаплда в eolia подсистемы моделирования и анализа потоков данных и структур данных, генератор прототипов, генератор отчетов и средства описания процессии.

Приводится классификация суцвствдоцих CftSE-систем, которая отражает основные свойства и недостатки этих систем (табл.1).

В следующем пункте приводятся стандарты на используемую в работе терминологии разработанною институтом инменеров ПО (SEI - Software Engineering Institute) и IEEE которая рекомендуется к использованию при создании систеи и проведении работ по управления качеством проектирования программных комплексов.

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

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

В конце главы приводится итоговая таблица , показывающая реалияованность пакнейиих требований к СОХП-систенпм в существующих инструментальных комплектах и, в частности, те ваинейяип характеристики которые должны поддерживать СЛЗЕ-средствд исходя из стандартов определенных IEEE. Исходя из требований зтой таблицы в рпИоте построен прототип интегрирований CASE -скстеин, вилючлищий

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

Во второй главе в качестве формальной модели спецификаций 'предлагается использовать представительную вмчнслительпув модель теории алгоритмов — алгоритм Колмогорова-Успенского.

Плгориты Колмогорова-Успенского вводит итеративный алгоритм детерминированного преобразования конструктивных объектов. КаядыА конкретный war алгоритма локален, т.е. воздействует в строго ограниченной лвласти (Активной зоне). Конструктивные объекты, подлежащие переработке, реализуются в пиде колмогоровских <Б,к)— комплексов -- ориентированных, инициальных графов, состоящих из конечного числа типов, с ограничением на алфавит "Б" и удовлетворяющих колмогоровскому свойству разметки. Оператор непосредственной переработки Q задан в виде конечного мномества правил подстановки ни,. Ui—xUl, Qi>. где IJi, Ni — комплексы, fli — изоморфное отобракение, сохранявшее колмогоровскос свойство разметки.

Алгоритмический процесс расчленяется на маги заранее ограниченной слояности; каждый шаг состоит в "непосредственной переработке" возникшего к этому »arg состояния S в состояние S'=QrCS).

Процесс переработки:

fío в = Qr (fl„).....6¿ - Or (fí¿~¿) для i=0,1.....

продолжается до тех пор пока либо не произойдет остановка без результата (если оператор Qr не определен для получивиегося состояния), либо не появится сигнал о получении "реиения". При этом не исклпчается возможность неограниченного продоладния процесса.

Непосредственная переработка S в S' = Qr (S) производится ливь на основании информации о виде заранее ограниченной "активной части" состояния S, и затрагивает ли«ь эту активнув часть.

Приводится определение недетерминированного вычислительного процесса с оракулом. Под вычислением с оракулом понимается функция двух аргументов: S - предыдушего состояния вычислительной ма-I гчнн и параметр? ((. принимавшего значения 0 и 1, в зависимости от ' того применим ли рассматриваемвй алгоритм к состоянию S. При реализации модели недетерминированных вычислений с оракулом процесс но«ет развиваться тремя способами:

S

П. в какой-либо момент племени I,' процесс приходит в заключительное состояние;

2). при каком-либо I" процесс заканчивается безрезультатно (процесс злперваптся, но результат не монет быть извлечен в силу каких-либо нргчин);

3). процесс продолжается неогроиичянно. не приводя к результату.

При построении попой модели внчислитпимгого процесса определенно Колчогорова-Испенскш'п суяэется до класса конечных процессов. При этой предлагается рассматривать реиенип типа П. - переходом в нормальное состояние, тина 2). - переходии я аномальное состояние, типа 3). - переходом п состояние тайм-аута СЪ1ио-оиЬ>, В результате использования суженной модели рассуждения ведутся о модели недетерминированного конечного автомата с фиксированным множеством классов состояний, которое хотя и не всегда определяет по входу конкретное состояние на выходе, но всегда точно определяет конечное множество таких состояний.

й настоящей главе предлагается конкретизация алгоритма, основанная на двух концепциях: формальные задания алгоритмов являются конструктивными объектами, а лпбой конструктивный объект может быть представлен в пиде состояния кплыпгоропского г В,к^комплекса.

Проводится доказательство того что формальные задания в виде ЕЯП, ПРО, СТО являются конструктивными объектами, а следовательно на них распространяются такие важиейвие свойства алгоритма Колмогпрнпа-Эспенского как представительность, рээренииость и нормируемость. На основании этого вывода появляется возможность использования методики оценки характеристик предлагаемой в главе 3.

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

точно определена.

Тан кик объективность оценок относительна и предлагаемой методике используется понятие "норна". Колмогоровым была предложв-' на следующая модель подсчета нормы. Фиксируете« некоторый ансамбль комплексов. Предполагается что вершины комплекса реализуется ¡»арами единичного диаметра, а ребра — гибкими трубками также фиксированного диаметра. Тогда можно так выбрать диаметр труб, что для некоторых положительных действительных чисел с и й выполняется пледувцнй условия: V

1. веяний комплекс с п верминами может быть реализован внутри сферы радиусом с\/п}

?., объем любой реализации почти всякого комплекса с п веряи-нами не меньше йгМк

Лтптся определение нормы п на ансамбле X, которая обладает свойствами:

1. число элементов х, для которых п(х)<в, равно 2**и с точностью до ограниченного от нуля множителя и

2. существует алгоритм, дающий по любому числу ш список всех элементов ансамбля X, для которых п(х) < в.

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

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

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

2. связь с числом веряин — число вержин комплекса не должно превосходить нормы, умноженной на некоторую константу, не зависящую от комплекса. '

Далее доказывается что соотношения (*), применяемые для оценки характеристик формальных спецификаций соответствуют введенным определениям для норм, а следипательио ими можно пользоваться

/О

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

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

П третьей глав« рассмотрены необходимые качества формальных спецификаций программное» продукта на основе чего формулируется методика оценки качептяа ПО.

Представлены основные требования к CflSE-систеиам (Computer Aided Software Systeu). Эти системы строятся на основе концептуального представления ннзненного цикла ПО, моделей спецификаций и методики их использования для целей контроля, оценки характеристик и т.д..

Предложена концептуальная модель развития жизненного цикла ПО, важное место в которой занимает строгая формализация спецификаций на проект в виде fIFO, ERD; СТО. Эти три типа диаграмм были выбраны исходя из того что больяинство других диаграмм сводится к ним и соответственно большинство CflSE-систем используют именно их. Они давт достаточно полное и неизбыточное представление о разрабатываемой системе и. что, немаловажно, многие проектировщики привыкли представлять систему таким образом, Влагодаря небольшому количеству вводимых ограничений на спецификации появляется возможность нормирования соответствуицих характеристик.

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

Предлагаемая методика включает: !. Определение функциональной полноты формального падания со-ответствупщей спецификации проекта или его частей. Эта процедура должна выполняться опытным системным аналитиком. В силу атого про-

а

\

<a.i inj

í i¡s(b) s 2 ¡ii(llí|(bj» + 2 Oj ns(I¡j) i=l J=1

ffliii Illi)'

ns(Dj) = 2 nsOtij^jj)) 2 ojj,ns(Bjj) i = l j—ï

^usCbij,,...!,) s £ ns(Hfi(bjj,...j,» + 2 Cjj,..j„!ls(Bjj..,.j„

lùj mj

np(B)s np(2 111,(1'/)) + 2 oj np(lij) i=î j=l

œjj. mjj'

np(Bj) = np<2 Itfi(BjjJ) + 2 ojj,np(Bjj) i=l j-=l

np(Bii,...jJsnp(2 ltf¡(Bjj,...],)>+ 2 oJji...|,,np(BJ),...j„) i=l J=1

Цвдура оценки субъективна и часто в большей степени влияет не на качество оценки, а на дальнейшие результаты проектирования. При этон ошибка том иеныпй, чем более детализирована спецификация не-реализовашшх крмпонент проекта.

2. Р;.знетку формального задания спецификации с помоцьга специальной процедуры введения пометок (для чего необходимо изначально выполнять разработки при поддержке специальных программных пакетов). Создание сливарсй операторпв и операндов проекта (внполняет-ся автоматически при выполнении соогиегствувщих ограничений).

3. Получение оценок метрик каждого модуля проекта (или его< части).

4. Оценка норм емкости и трудоемкости для проекта (или ого части), инвариантная относительно оцегочкнх формул (в работе исследовались оценочные формулы Холстеда, 'Линаева, Боэма).

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

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

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

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

Тр

С**) ПН - —---- , где Тр — реальная трудоемкость

Г

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

С***) Тр = ПК Скоит Т~

Тр = ПК Ссп Т*, где i!l> — поправочные коэффициенты, Сконт и Сен — мультипликативная составляющая для отчисления оценок на этапе разработки контекста и спецификации соответствии.

Тр

Ссп =----.

Тр

Сконт - ---- , где Тр — реальная трудоемкость, ,

Т"

внчисляекая после реализации проекта, Т" и ТЛ — оцениваемые трудоемкости ил соответствуй^ этапах проектирования.

Представлены проекта которые исследовались при поыоци предлагаемой методики. В какдои проекте фиксировалось 3-4 стадии развития: начало разработки спецификации ( анализа требований), промежуточные этапы, при которых часть проекта реализована в виде спецификаций, часть в виде контекста, а некоторые модули реализован« полноетьл в Koiuù- и, наконец, выпуск готового изделия — программного комплекса. Пила продемонстрирована процедура выбора альтерпатхшшх вариантов проектных рсаешй в реализационных версиях на основе сделанных рассчетов. Например, били вобраны один из двух Сво второй) и трех (в первом) вариантов проекта, Сила обосновано процедура вибора по критерии минимума трудоемкости (трудоемкость разработки отброаешшх вариантов оказалась больно).

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

l'a основании проведенных исследований был сделан вывод о том, что оцени«, проводимые на различных этапах проекта сопоставимы и

ни мере развития проекта сходятся к определенной величине. Это демонстрируется графиком на рис. 1. Здесь приводится фрагмент таблицы. Результирувщие колонки расчитываются на основе метрик Холстеда, Вояма м Липаева.

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

Окончательным выводом проведенных исследований является то что оценки, получаемое по методу Холстеда менее точна на всем протяжении проекта, однако на начальных этапах другие методы применять невозможно. Поэтому предлагается,''на первых этапах, noua невозможно использовать методики Липаева или Боэма вести оценк'у трудоемкости по холстедовским метрикам, однако, в дальнейшем, частично использовать оценки Холстеда, на основании которых с больной точность» делать прогнозы, используя липаевские или боэмовские. На рис. 2 изображены графики показывавшие зависимости оиибки при оценке от различных этапов проектирования и применяемого метрического аппарата. На первом этапе суцестйует возможность оценки только по Холстеду. Далее появляется графики для метрик Липаева и Боэма.

ЗШВЧЕНИЕ

Основные результаты работы могут быть сформулированы еле-дуицим образом.

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

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

¿Г

___

Сходимость оценок по Холстеду

Этап 1

Этап 2 Этап 3 Этап 4

• Холстед аар! - Холсггсд вар2)

Проект 2 Модуль П1 п2 N1 N2 п Н V Т Боэм Липаев

Вариант! МЮОО 14 9 46 40 23 66 I З.ЭЕ+2 1.5Е+5 3.6Е+2 3,1Е»2

М1Ю0 8 9 12 15 17 27 1,1 Е*2 1.2Е+4 7.1Е+1 4,2Е+1

К1200 11 9 17 13 20 30 1,ЗЕ+2 1,7Е+4 1.1Е+2 7.0Е+1

М1300 10 9 17 12 19 29 1.2Е+2 1.5Е+4 1,1Е+2 7.0Е+1

ИТОГО трудоемкость проекта

в,1Е*5 1.2Е+3 8,9Е+2

Рис. Ошибка оценки трудоемкости

-• —Литеввар1

■■ а- Лишзве вар2 ---- Боэм еар1

- - боэм вар?

- — Хслстсд вар2 -- Холстед вар!

0Х'Е»и

Г>|ап 1

Яглп ?

Эгяя Л

Эта н '1

У6

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

- определен специальный вид колыогоровских (Б.к)-комп-лексов, позволяпций формально описать и интерпретировать основние объекты ьзнка спецификаций;

- предложена конкретизация (Б.к)-комплексов в виде формального задания спецификаций (СТО, ВДВ, ПРО>;

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

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

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

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

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

ПО;

- обосновано применение конкретных метрик качества ПО.

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

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

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

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

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

ния;

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

подсчета характеристик;

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

- инвариантность' методики относительно языка на которой реализованы спецификации,

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

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

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

?.. Котляров D.H., Токарев М.8. Управление проектированием программного продукта п интегральной системе типа COSE1. // Материалы семинара "CASE - технология". -И.: ЦРДЗ. - 1993.

3. Токарев И.В. Методика проектирования расииряемых встроенных типов данных для. сборочнпг? системы программирования. // Сб. научных трудов. -С.110.: СНбГТУ N442, 199?..

4. Котляров В.П., Токарев Ы.В. Метод карантинного исполнения в операционной среде, зачищенной от несанкционированного доступа. // Тез. докладов Республиканского научно-технического семинара "Методы и технические средства защити информации". -С.Пб.: СПбГТУ, 1993.

¡i. Котляров В.П., Токарев К.В. Гипертекстовая среда как инструментарий проектирования программного проекта. // Пользовательский интерфейс. Исследование, проектирование, реализация. -П.: КЗ, 1993, с. 39-S3.

R. Котляров В. П., Токарев V. Ii. Метрика программного проекта, ориентированная на управление проектированием расииряемых систем // Сб. flporiлеиние технологии программировании. -0.116.: С1ШИРА11, 1992.

(1) ГК'ЧйГИ).

У. Kol.Jjvirnv Ü.P., Tokarev H.V. Ii Mol bod of quftranliup execution

is

ti the operating sphere protected froi unathorlzed acces? // flbs-racts International Congress on Computer Systeis and Applied Hat-esatles. -S.-Pefcerbiirg: 12-23 July. 1993.

ft

Введение.

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

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

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

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.