Аварийный тест

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

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

Стыковочные тесты

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

Комплексные тесты

Проверяют правильность работы всех или большинства частей программы после их объединения.

2.8.1 Модульное тестирование

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

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

Существует два подхода к комбинированию модулей: пошаговое и монолитное тестирование. В пошаговом тестировании в свою очередь существуют два способа: тестирование снизу вверх и тестирование сверху вниз. Не Пошаговое тестирование предпочтительнее монолитного.

2.9 Надежность программного обеспечения

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

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

Надежность - это «свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования». Таким образом, надежность является внутренним свойством системы, заложенным при ее изготовлении и проявляющимся при эксплуатации. Это свойство проявляется только во времени, и без более или менее длительного наблюдения нельзя сделать заключение о надежности системы. Характеристики надежности зависят от условий эксплуатации, поэтому при определении их значений необходимо учитывать ее особенности.

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

2.9.1 Критерии надежности систем

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

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

P = P.

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

Q = P = 1 - P.

Частота отказов a есть плотность распределения времени работы до первого отказа:

.

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

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

.

Аналогично можно представить другие характеристики, описывающие надежность для невосстанавливаемых систем при условии, что они уже функционировали в течение времени to:

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

распределение наработки до i - го отказа: Fi = P;

распределение времени до i - го восстановления: Vi = P;

вероятность возникновения n отказов до достижения длительности наработки t: Pn.

Кроме того, отказы можно характеризовать средним числом H за время t, интенсивностью потока отказов = d H / dt и наработкой на отказ T = t / H.

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

вероятностью восстановления за время t;

плотностью распределения времени восстановления;

средним временем восстановления.

Кроме того, используются показатели среднего числа восстановлений за некоторое время и параметр потока восстановлений.

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

2.9.2 Типы программного обеспечения с точки зрения надежности

Программы для вычислительных машин можно разделить на три основных типа:

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

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

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

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

2.9.3 Анализ надежности программного обеспечения

К задачам анализа надежности программного обеспечения можно отнести следующее:

формулирование основных понятий, используемых при исследовании параметров и показателей надежности программ;

выявление и исследование основных факторов, определяющих характеристики надежности сложных программных комплексов;

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

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

исследование ошибок в программах, динамики их изменения при отладке и модернизации и их влияния на надежность;

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

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

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

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

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

2.9.4 Диагностика функционирования комплексов программ

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

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

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

проверку правильности функционирования в данном режиме работы в данный момент времени;

поиск и локализацию неисправностей в системе.

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

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

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

При тестовом диагнозе различаются прямая и обратная задачи.

2.9.5 Основные факторы, влияющие на надежность функционирования комплексов программ

Одни и те же типы сбоев и отказов при исполнении комплексов программ могут быть вызваны различными факторами, которые можно разделить на 3 группы.

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

искажения исходной информации, поступающей от внешних абонентов;

самоустраняющиеся отказы или сбои в аппаратуре вычислительной системы;

невыявленные ошибки в комплексе программ.

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

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

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

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

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

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

2.10 Разработка программной документации

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

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

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



Рис. 2.4. Системная документация

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

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

A. Проект системы. К этим документам относится графические схемы задания и развернутые планы проекта, охватывающие структуру и основные детали программы.

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

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

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

A. Руководство пользователя. В руководстве содержатся общее описание и подробные сведения о ее применении, разъясняются сообщения об ошибках.

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

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

IV. Реализация системы. Данная часть документации отражает результаты действия группы программирования.

A. Символьный код. Это набор текстов самодокументированных программ, составленных в удобной для восприятия форме.

B. Информация, выдаваемая ЭВМ. Сюда входят таблицы перекрестных ссылок, карты загрузки, таблицы атрибутов, данные о времени выполнения программ и любая другая машинная информация.

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

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

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

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

3. Организационно-экономическая часть

3.1 Экономическая эффективность программного продукта

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

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

Э = Эо - Сs

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

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

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

В соответствии с этапами жизненного цикла ПО основные затраты Сs, снижающие идеальную эффективность за цикл жизни Тж, можно представить следующими составляющими:

совокупные затраты на создание ПП и обеспечение решения заданных функциональных задач, в том числе на технологическое обеспечение и аппаратуру ЭВМ при разработке ПО в течение времени Тр - Ср;

затраты на эксплуатацию программных и аппаратных средств, реализующих ПП, а также совокупные потери эффективности за время Тэ вследствие ограниченных характеристик ЭВМ и неидеальности программ - Сэ;

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

накладные расходы Сн.

В результате совокупную реальную эффективность функционирования ПО за весь жизненный цикл длительностью Тж можно представить в виде:

Э = Эо - Ср - Сэ - Сс - Сн.

3.2 Составляющие затрат на создание программного продукта

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

Наибольшее значение в составе Ср при разработке сложных комплексов программ имеют следующие составляющие затрат:

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

на изготовление опытного образца ПП как продукции производственно-технического назначения - С2 р;

на разработку, подготовку и применение технологии программных средств автоматизации разработки программ - С3 р;

на технологические и реализующие ЭВМ, используемые для автоматизации разработки программ - С4 р;

на подготовку и повышение квалификации специалистов-разработчиков - С5 р.

Первые две составляющие С1 р и С2 р являются непосредственными затратами на создание программных средств. Составляющие С3 р и С4 р можно рассматривать как затраты, обеспечивающие оснащенность процесса создания ПП. Затраты на подготовку и повышение квалификации наиболее трудно формализовать и учитывать в конкретной разработке программных средств. В нашем случае эта составляющая не учитывается.

3.2.1 Затраты на непосредственную разработку ПП

Затраты на непосредственную разработку комплекса программ С1 р являются важнейшей составляющей в жизненном цикле ПП. Наибольшее влияние на них оказывает объем ПП. Затраты на разработку С1 р и объем программ Пк связаны через показатель интегральной средней производительности труда разработчиков Р. Для учета влияния на С1 р различных факторов удобно пользоваться коэффициентами изменения трудоемкости - Сij, учитывающими зависимость i_ой составляющей совокупных затрат от j_го фактора. Непосредственные затраты на разработку можно представить как частное от объема ПП и производительность труда, корректируемое произведением коэффициентов изменения трудоемкости:

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

факторы, отражающие особенности создаваемого комплекса программ как объекта разработки, и требования к его общим характеристикам;

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

факторы, отражающие оснащенность процесса создания ПП аппаратурными средствами, на которых базируются системы автоматизации разработки;

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

Для каждого фактора может быть выделен параметр, наиболее полно отражающий его содержание численными значениями. Для большинства факторов произведены оценки диапазона возможного изменения относительных затрат на разработку одной команды в ПП при варьировании соответствующего параметра в указанном диапазоне. Эти изменения затрат характеризуются коэффициентами Сij изменения усредненной трудоемкости разработки строки текста программы за весь цикл создания ПП при варьировании j_го фактора i_ой группы. Кроме оценок предельных значений КИТ, приводятся их средние значения.

Факторы объекта разработки	Параметры фактора	Диапазон изменения параметра	Диапазон КИТ	Среднее значение КИТ
1. Сложность ПП - С11	Число операторов в тексте программ на ассемблере Пк	104 - 107	1 - 4	2 - 3
2. Надежность функционирования ПП - С13	Часы проработки на отказ программ Тн	1 - 103	1 - 5	2-2.5
3. Ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ - С14	Процент использования памяти и производительности Р	50-95	1 - 3	1.3-1.5
4. Длительность предполагаемой эксплуатации - С15	Годы эксплуатации Тэ	1 - 20	1 - 3	1.3-1.5
5. Предполагаемый тираж - С16	Число предполагаемых экземпляров	1 - 1000	1 - 3	1.3-1.5
6. Мобильность использования компонент ПП из других разработок - С17	Процент возможного использования компонент	0 - 80	1 - 1.4	1.1-1.2
7. Мобильность использования ПП для других разработок - С18	Процент возможного использования компонент	0 - 80	0.4 - 1	0.5-0.7

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

Эта группа факторов отличается наибольшим влиянием на затраты и производительность труда.

3.2.2 Сложность разработки программного продукта

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

В качестве первого приближения суммарные затраты на разработку сложного ПП в зависимости от объема программ можно представить выражением:



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

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

Ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ. При использовании создаваемым ПП производительности и памяти реальной ЭВМ менее чем на 50% можно не учитывать эти ограничения.

где р - реальная загрузка ЭВМ.

Длительность предполагаемой эксплуатации ПП изменяется от нескольких месяцев до нескольких лет. По экспертным оценкам, увеличение предстоящей длительности эксплуатации ПП на порядок от 1 до 10 лет приводит к увеличению КИТ С15 примерно в 1.5-2 раза. Такую зависимость можно описать логарифмической функцией:

где а15 изменяется в диапазоне от 1 до 0.5.

Предполагаемый тираж программ N составляет

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

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

Мобильность использования ПП из других разработок позволяет снижать затраты при сборочном программировании новых ПП. При этом относительное повышение производительности труда пропорционально доле использования в новом ПП. При сборочном программировании кроме 10-20% затрат на создание новых программных компонент, необходимы ресурсы на комплексирование нового ПП, его комплексную отладку, испытания и документирование. В результате суммарные затраты заметно возрастают и эквивалентное повышение производительности труда С18 может составлять 2.5-3 раза. Необходимо учитывать затраты, которые требуются на создание адаптируемых компонент и всего первичного ПП. В результате программная мобильность с учетом затрат на ее подготовку в среднем дает снижение КИТ на 30-50%.

3.2.3 Затраты на изготовление опытного образца как продукции производственно-технического назначения

Затраты на изготовление опытного образца ПП как продукции производственно-технического назначения - С2 р определяется необходимостью обеспечить отчуждение всего комплекса программ от его непосредственных разработчиков. Удельный вес этих затрат находится в пределах 10-15% от общих затрат на разработку С1 р. Для изготовления ПП как продукции производственно-технического назначения необходимо:

изготовить и оформить опытный образец ПП на носителях данных;

разработать комплект документации, обеспечивающий квалифицированную эксплуатацию ПП.

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

3.2.4 Затраты на создание комплекта документации

Затраты на создание комплекта документации С2р2 практически пропорциональны объему программы:

,

,

где Д = 50-100 страниц документации на тысячу команд,

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

3.2.5 Затраты на технологию и программные средства автоматизации разработки ПП

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

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

В нашем случае затраты распределяются только на эксплуатацию ЭВМ в течение разработки ПП. Поэтому общие затраты на ЭВМ будут выглядеть так:

С4 р = С4р1 = а41*Тр,

где а41 - стоимость машинного времени реализующей ЭВМ.

3.3 Составляющие затрат на эксплуатацию программ, влияющих на процесс разработки ПП

Затраты на эксплуатацию программ, влияющих на процесс разработки ПП:

затраты на производство и внедрение экземпляра ПП - С1э

затраты на реализующую ЭВМ - С2э

затраты на эксплуатацию реализующей ЭВМ - С3э

затраты на эксплуатацию экземпляра - С4э

потери вследствие задержек и потерь сообщений - С5э

потери вследствие сбоев и отказов ПП - С6э

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

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

Затраты на внедрение - С1э3 можно снижать за счет эффективных средств обучения персонала. И в некоторых случаях обучение специалистов и внедрение экземпляра сложных ПС может требовать 2-7% общих затрат на разработку ПП. Поэтому в нашем случае С1э = С1э3.

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

Для ПП, работающих в реальном времени, при малом использовании периферийных устройств затраты на реализующую ЭВМ определяются в основном следующими факторами:

объем оперативной По и командной Пк памяти ЭВМ - f2э1;

быстродействие вычислительной системы f2э2;

уровень технологии и автоматизации проектирования программ U, влияющий на степень использования ресурсов реализующей ЭВМ f2э3.

Как известно, память является одной из самых дорогих компонент вычислительной машины. Для размещения сложных программ объемом 104-107 команд стоимость ЭВМ практически пропорциональна суммарному объему памяти или объему памяти, необходимому для размещения ПП. Поэтому можно принять f2э1 = а2э*.

Вторым фактором, определяющим стоимость вычислительных систем, является их быстродействие или производительность. В некоторых пределах затраты на реализующие ЭВМ практически линейно зависит от логарифма величины быстродействия. Поэтому можно принять f2э2 = 2-3.

В нашем случае f2э3 = 1 из-за низкого уровня автоматизации.

В результате суммарные затраты на реализующую ЭВМ с определенным ПП можно описать следующим приближенным выражением:

С2э = f2э1 *f2э2,

где Б - быстродействие ЭВМ.

Коэффициент а2э учитывает текущее состояние технологии изготовления аппаратуры ЭВМ. Его можно оценить по техническим характеристикам и стоимости реальных вычислительных машин.

Затраты на эксплуатацию реализующей ЭВМ - С3э для комплекса программ в реальном времени практически постоянны в единицу времени и можно принять, что:

С3э = а3э*Тэ

Коэффициент а3э соответствует удельной стоимости машинного времени. Затраты на эксплуатацию экземпляра ПП на реализующей ЭВМ - С4э так же, как и предыдущие, можно считать прямо пропорциональными времени эксплуатации ПП - Тэ:

С4э = а4э*Тэ

Коэффициент а4э в основном зависит от типа памяти, используемой для хранения программ. Наименьшие затраты при эксплуатации программ требуются при использовании постоянных или полупостоянных запоминающих устройств. В этом случае удельные затраты за время жизненного цикла ПП обычно составляет малую долю от затрат на реализующую ЭВМ. Обычно а4э<<а3э, вследствие чего С4э может не учитываться.

Потери эффективности функционирования ПП вследствие задержек и потерь сообщений, подлежащих обработке, - С5э обусловлены ограниченностью ресурсов реализующей ЭВМ. Ограничение ресурсов отражается как непосредственно на разработке ПП, так и на его эксплуатации. Влияние этого ограничения в процессе разработки и приводит к необходимости тщательного учета и экономичного использования ресурсов реализующей ЭВМ, что увеличивает С14. Более тщательное проектирование ПП в условиях ограниченных ресурсов ЭВМ позволяет снизить потери С5э, однако увеличивает затраты за счет КИТ - С14. При единственном экземпляре эти затраты возможно учитывать за счет С14.

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

Сэ = С1э + С2э + С3э + С4э + С5э + С6э.

3.4 Составляющие затрат на сопровождение программ

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

Основными факторами, влияющими на процесс разработки ПП, являются:

объем программного продукта

длительность жизненного цикла ПП

уровень технологии разработки ПП

степень использования ресурсов реализующей ЭВМ

надежность ПП

число версий ПП

мобильность ПП

тиражность ПП

Затраты на сопровождение ПП сводятся к трем составляющим:

на обнаружение и устранение ошибок в каждой версии ПП - C1с

на доработку и совершенствование программ, формирование и испытание новых модернизированных версий ПП - C2с

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

Затраты на обнаружение и устранение ошибок C1с определяются двумя факторами: затратами на обнаружение каждой ошибки и затратами на устранение всех выявленных ошибок про формировании очередной версии. Линейная структура ПП и отсутствие в ней алгоритмически сложных мест сводят C1с к нулю.

Затраты на развитие и модернизацию программы C2с близки по содержанию к затратам на первичную разработку ПП Ср. Модернизация производится поэтапно и для каждой новой версии изменяется только некоторая часть от объема всего ПП. Обычно эта часть составляет не более 20% от всего комплекса. Сложность связей в ПП приводит к тому, что удельные затраты на изменяемые программы при модернизации каждой версии могут быть несколько больше, чем затраты на создание программ такого же объема при первичном проектировании. ПО управления автоматизированным комплексом многоканальной связи реализовано в виде машинного кода, специфика ассемблерного текста которого применительно к данной задаче исключает его модернизацию. В целом, цели и технические требования к таким ПП оговорены заранее. Подобные продукты разрабатываются в каждом случае под конкретную архитектуру. Поэтому, составляющая затрат на развитие и модернизацию такого ПО C2с также будет равна нулю.

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

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

3.5 Расчет затрат на программный продукт

Исходные данные:

- объем ПП составляет примерно 300 операторов на ассемблере;

- надежность функционирования ПП около 20 часов наработки на отказ;

- ограничение ресурсов производительности и оперативной памяти реализующей ЭВМ не менее 50%;

- длительность эксплуатации составит не менее 5 лет;

- данная программа будет существовать в единственном экземпляре;

- после создания ПП предполагается использовать около 40% наработок;

- при создании ПП число наработок из других программ составило не более 20%;

- в процессе проектирования велась пошаговая разработка компонент ПП с контролируемыми этапами технологии и поэтапным контролем результатов работ;

- при разработке ПП, который относится к ПП ниже среднего класса сложности применялась только реализующая ЭВМ, которая также использовалась для имитации внешней среды и тестов;

- на разработку и отладку произведенного ПП потребовалось в среднем по 0,3 Мбайта;

- уровень квалификации заказчика выше среднего.

Суммарные затраты:

Cs = Cp + Cэ + Сс + Сн

Поскольку мы пренебрегли затратами на сопровождение программного продукта, формула принимает следующий вид:

Сs = Ср + Сэ + Сн.

Рассчитаем каждое слагаемое.

Составляющие затрат на разработку программного продукта:

Ср = С1 р + С2 р + С3 р + С4 р.

Факторы, влияющие на затраты при разработке

С1 р = Пк/Р * П Сij

С11 = lg = 1;

С13 = lg = 2.3;

С14 = 0.51;

С15 = а15*lg = 0.5*lg = 0.85;

С16 = 2.3;

С17 = 1.4;

С18 = 0.9;

С31 = 0.65;

С32 = 1;

С33 = 0.5;

С34 = 1;

С41 = 0.7;

С42 = 0.75;

С51 = С52 = 0.8;

С53 = 0.95;

С54 = 1.1;

Остальные коэффициенты примем равными единице.

Р - производительность = 60 команд на ассемблере в день

Пк = 300 команд

Зарплата составляет 150 руб./день

Рассчитаем С1 р.

С1 р = 3.131 * 150 = 470 рублей.

Затраты на изготовление опытного образца ПП

С2 р = а2 р * Д * Пк* Зарплата_в_день,

где а2 р = 1 день / 10 страниц;

Д - 50 страниц / 1000 команд;

С2 р = 6 * 150 = 900 рублей.

Затратами на технологию и программные средства мы пренебрегаем.

Затраты на ЭВМ

С4 р = а41*Тр

где а41 = 24000 / = 480 руб. / месяц

С4 р = 1 * 400 = 480 рублей.

Итак:

Ср = 470 + 900 + 480 = 1850 рублей.

Затраты на эксплуатацию программ

Сэ = С1э + С2э + С3э

С1э мы пренебрегаем вследствие единичного изготовления программного продукта.

С2э = а2э**lg

где

а2э = 0.005*5500*7 рублей

По + Пк = 0,5Мбайта

Б - быстродействие = 10 000 000 операций в секунду.

С2э = 190 рублей.

Затраты на эксплуатацию реализующей ЭВМ

С3э = 60 месяцев * 480 рублей / месяц = 28 800 рублей.

Итого Сэ = 28 990 рублей.

Учитывая, что Сн составляют 50% от Ср, то

Сн = 0,5*1850 = 925 рублей.

Сs = 1850+28990+925 = 31 765 рублей.

Все результаты сведем в таблицы.

Затраты на разработку ПП

Составляющие	Затраты	% от общих затрат
С1 р	470	25
С2 р	900	49
С4 р	480	26

Затраты на эксплуатацию

Составляющие	Затраты	% от общих затрат
С2э	190	4
С3э	28 800	96

Общие затраты на создание программного продукта

Составляющие	Затраты	% от общих затрат
Ср	1 850	6
Сэ	29 900	91
Сн	925	3

Мы рассчитали суммарные затраты на разработку данного ПП и увидели, что они составили примерно 32 675 рублей. Наибольшие затраты были на эксплуатацию реализующей ЭВМ.

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