книги / Надежность программного обеспечения систем обработки данных

о, + 9

°= - v -

где Gi — обтай объем всей имеющейся документации

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

Коэффициент масштаба системы вычисляется из за­ висимости!

N

где И — количество программ в системе

Этот коэффициент используется для выравнивания объема потребного времени на проектирование каждой программы системы Автор утверждает, что время для проектирования двух однопрограммных систем больше времени проектирования одной двухпрограммной системы Следовательно, он полагает, что системное время не долж но увеличиваться пропорционально для каждой допол­ нительной программы в системе Основные коэффициен­ ты по данному ме-Году оценки приведены в табл 11 2

211

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

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

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

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

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

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

существует возможность расширения областей исполь­ зования ПО

Одним из основных недостатков метода прототипов является субъективизм в оценке затрат на разработку ПО При использовании метода Хортадо также имеет место влияние субъективного фактора, так как исполь­ зуются данные, полученные эмпирическим путем Кроме

212

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

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

Среди многообразия оценочных методов наиболее ин­ тересным и (фактически применяемым является метод IBM. Этот метод в литературе иногда встречается под названием «процент от другого элемента» и предполага­ ет, что стоимость части предлагаемого проекта считается заранее Определенной долей другого проекта. Метод IBM наделен на проведение оценки пбтребнЫх Трудовых ресурсов.

Для эффективного применения Метода системное про­ ектирование Должно быть доведено До такой степени, чтобы были известны потребности модулей во вводевыводе, а также Thmii и предполагаемая сложность самих мбдулей. Должны быть известны также уровень Квали­ фикации разработчиков и Степень их информированно­ сти о сути данного проекта.

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

Ш а г 1 Вычисление чистого времени разработки, программ. Время разработки программ по методу вклю­ чает время, необходимое для корректировки логики прог* рамм, их кодирования, разработки отладочных данных, отладки программ я подготовки документации.

Сложность программы задается как переменная, вы­ числение которой зависит от типа ввода-вывода и функ­ ции обработки в программах. Вычисление сложности программы начинается с присвоения весов характерис­ тикам ввода-вывода Например, карточному вводу в уни­ фицированном формате присваивается одно очко, а лен­ точному файлу с записями переменной длины — 3 очка Далее веса придаются функциям обработки, которые рас­ сматриваются по пяти следующим категориям: нзмене-

213

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

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

214

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

2IS

Знание программистом данной работы — это перемен­ ная, измеряющая степени соответствия опыта Програм­ миста ‘темучто требуется для выполнения заданной работы Табл 116 содержит весовые коэффициент^ по которым различные уровни знания программистом дан­ ной работы коррелнруются с тремя классами знаний; много знаний, некоторые знания, нет никаких знаний. Каждому1программисту присваиваются. весовые коэффи­ циенты, отражающие связь между степенью осведомлен-' ности в заданной работе и требуемым уровнен знаний. Весовые Значения' всех коэффициентов Программистов суммируются

Т а б л и ц а 116

Эн*пие работы net истоду IBM

21 6

Чистое ч»ремя разработки программ — основная рас­ четная величина Следующие четыре величины вычис­ ляются как доля от чистого времени разработки

Ш аг 2 Определение прочего системного времени Вычисление прочего системного времени включает вы­ числение времени, которое уходит на проектирование, отладку И внедрение системы Время, которое предпола­ гается отвести на эти этапы, изменяется от 70 до 110% чистого времени разработки программ

Ш а г 3 Определение коэффициента потерь для проекта. С помощью коэффициента потерь предприни­ мается попытка учесть время программиста аналитика, фактически поглошаемое такой деятельностью, как реше

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

Изменений спецификаций работы и т д Разумная вели­ чина потери находится в диапазоне от 5 до 10% суммы чистого времени.

.j Ш а г *4 Вычисление непросктнето времени Эта пе­ ременная вводится для учета времени, расходуемого персоналом на деятельность, ие имеющую отношения к разработке предлагаемой системы

Непрректная деятельность включает: обучение, отпу c^a, праздники, $олезни, личные обстоятельства и т. д. Возможная доля непроектного времени может находить­ ся в пределах от 20 до 35% суммы чистого времени раз­ работки программы и прочего системного времени

Ш аг 5 Определение общего времени разработки проекта Общее время разработки проекта вычисляется путем суммирования потребностей времени из предыду­ щих четырех шагов, т е суммируется чистое время раз­ работки программ, прочее системное время, время по­ терь и непроектное время

Метод IBM имеет ряд недостатков Чистое время раз­ работки программ, являющееся Основным расчетным по­ казателем, находится в большой зависимость от субъек­ тивных факторов Ошибки, возникающие рри вычисле­ нии чистого времени разработки программ, усиливаются использованием процента этой величины для вычисления прочего системного времени, времени потерь и непроект­ ного времени Таким образом, общее время разработки проекта — это сумма всех вышеуказанных переменных, включающая накапливаемые ошибки всех стадий

И*я*ользуч коэффициенты, приведенные в табл 11 3— И 6, необходимо учитывать, что эти величины основаны

217

на средних значениях и требуется корректировка, от ражающая фактическую среду, в которой ведется ра­ бота

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

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

На основе качественного анализа строится уравнение регрессии вида

y l = a i x , \ + a t x , 2 + . . . + с и Д т - М , ,

Уравнение регрессии решается традиционными мето­ дами и не представляет трудностей.

112КОСВЕННЫЕ МЕТОДЫ

Ккосвенным методам оценки затрат относятся ме­ тоды, не предусматривающие выявления прямых взаимо­ связей между параметрами управления и множеством факторов, влияющих на процесс разработки ПО. Оценка

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

Значительную помощь в проведении этих работ мо­ жет оказать использование приемов моделирования. Мо­ дели надежности и сложности ПО рассматриваются в гл. 12 как вспомогательный аппарат Для определения

218

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

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

11.3 ГРАФИЧЕСКИЕ МЕТОДЫ

Наиболее часто используются на практике два гра­ фических метода планирования ресурсов: с применени­ ем ленточных графиков (диаграмм Ганта) и с помощью сетевых графиков.

Ленточные графики просты в построении, наглядны и легко поддаются изменению. Они позволяют планиро­ вать сроки завершения различных работ, а также нагляд­ но графически иллюстрировать опережение или отстава­ ние от плановых сроков разработок На рис. 11,1 приве­ ден типичный пример ленточного графика, регламенти­ рующего сроки выполнения шести работ, составляющих некоторый проект.

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

11-1 Вариант ленточного графика

№

11 2 Ленточный график с детализацией

выясняется, что работы А1 и ЛЗ выполняются с двухме­ сячным отставанием, а работы А2 и А4 выполняются в соответствии с планом. Выявление этого факта еще не дает прямого ответа на вонрос руководителя, будет ли проект выполнен в срок. Можно, конечно, детализиро­ вать перечисленные работы (рис. 11.2), но и это ничего не скажет о своевременности завершения проекта в целом.

Основной недостаток ленточного графика в том и со­ стоит, ЧТО с его ПОМощьЮ невозможно показать Взаимо­ связи отдельных работ, в связи с чем трудно Оценить зВачймбСть каждой Отдельной работы для достижения конечной цели (основная же сложность при разработке, йалример программного средства, Заключается в отра­ жений йё количества работ, а нменйо количества свя­ зей). Этот недостаток отсутствует в применяемых в на­ стоящее Время Сетевых графиках.

Сетевой график — это ориентированный граф без контуров, рёбра рторого имеют одну длину или несколько числовых характеристик. В отличие от ленточного гра­ фика, где основным является только один элемент — ра­ бота, в сетевом графике, как правило, имеются два ос­ новных элемента — работа (изображается на графике ребром) и событие (соответствует вершине).

Работами называются любые процессы, действия, при­ водящие к получению определенных результатов (собы­ тий), например, действия; «разработка Модуля М» или «комплексное рабочее тестирование подсистемы» и т. д. Кроме работ действительных, т. е требующих затрат времени, существуют так называемые фиктивные работы (зависимости). Фиктивной работой называется связь между какими-то событиями, не требующая затрат вре­

220