Содержание

Введение…………………………………………………………………………...3

Глава 1. Затраты  связанные с жизненным циклом программных средств……5

1.1.Основные понятия  о затратах в жизненном цикле………………………….5

1.2.Основные составляющие  затрат на разработку программных проектов……………………………………………………………………………7

Глава 2. Анализ экономической эффективности  внедрения  программных средств..…………………………………………………………………………..25

2.1. Понятие и  расчет экономической эффективности  программных средств……………………………………………………………………………25

2.2. Методы оценок  инвестиций в программные проекты…………………..29

2.3. Экономическая  эффективность программных продуктов  в сфере оценок инвестиций. ……………………………………………………………………...33

Глава 3. Разработка информационной системы развлекательного центра…..40

3.1. Краткая информация  о развлекательном центре …………………………40

3.2. Видение выполнения  проекта и границы проекта………………………..40

3.3. Отчет об  обследовании……………………………………………………..41

3.4. Формирование  бизнес-процессов………………………………………….44

3.5. Спецификации  настроек типовой информационной  системы…………..47

3.6.Проектирование реализации операций бизнес-процесса в информационной системе………………………………………………………48

3.7. Диаграммы  UML……………………………………………………………49

3.8. Разработка модели бизнес-процессов развлекательного центра в программной среде AllFusion Process Modeler ………………………………..50

Заключение……………………………………………………………………….52

Список использованной литературы…………………………………………...54

Приложения 
 
 

Введение. 

     Тема  курсовой работы «Оценка экономической  эффективности программных проектов». Данная тема представляется достаточно актуальной, так как в наши времена высоких информационных технологий создание программных средств превратилось в целую отрасль, если можно так выразится, и представляет собой полноценный бизнес способный приносить большую прибыль, но только тогда, когда он ведется грамотно, и если его ведут компетентные люди, настоящие профессионалы своего дела. Приступая к разработке крупных проектов, руководители, прежде всего, пытаются понять целесообразность создания, и пробуют оценить возможную эффективность применения готового продукта, а также проводят расчеты на то, оправдаются ли затраты на его разработку и использование. По этой причине  такие проекты традиционно начинаются с анализа и разработки технико-экономического обоснования предстоящего жизненного цикла проекта и эксплуатации предполагаемого продукта. Заказчику проекта необходимо оценить реальную потребность в его создании и возможную конкурентоспособность, а потенциальному разработчику-поставщику создаваемого продукта, провести оценку реализуемости проекта в условиях и ресурсах, предлагаемых заказчиком. Должен быть подготовлен согласованный между заказчиком и разработчиком первичный документ, в котором определены цели и задачи проекта, предполагаемые характеристики продукта и необходимые ресурсы для его реализации. Эти данные должны быть предварительно сбалансированы и обеспечивать реализацию целей проекта при выделенных ресурсах с минимальным допустимым риском. Однако масштабы целей и функций сложных проектов имеют устойчивую тенденцию изменяться и увеличиваться по мере развития, а первоначально выделяемые ресурсы не удовлетворять их реализацию. Технико-экономическое обоснование проектов на начальном этапе их развития должно содержать оценки рисков реализации поставленных целей, обеспечивать возможность планирования и выполнения жизненного цикла продукта или указывать на недопустимо высокий риск его реализации и целесообразность прекращения разработки. В общем при создании программных средств оценить полностью количество тех ресурсов, которые необходимы, на данный момент не возможно. Да и полноценную выгоду, которую может принести разработанное программное средство оценить тоже нельзя. В связи с этим данная тема еще не исчерпала свой запас неизвестности, хотя ей и занимаются и занимались  огромное количество ученых, самым известным представляется Липаев В.В..[5] Степень разработанности данной проблемы достаточно-таки глубока, но имеющий еще под собой огромный потенциал неизвестной нам информации, которую следует изучать. Так  Липаев В.В. в одной из своих книг[5] предлагает создать целую отрасль для оценки экономической эффективности создания программных средств.

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

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

Глава 1. Затраты связанные  с жизненным циклом программных средств.

1.1.Основные  понятия о затратах  в жизненном цикле.

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

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

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

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

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

1.2.Основные  составляющие затрат  на разработку  программных проектов.

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

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

     Рис. 1 Состав затрат в жизненном цикле программных средств.

     Для относительно небольших программного средств, с малым жизненным циклом, доля этих затрат может достигать 70 - 90%.  Для сложных программного средства, предназначенных для длительного  массового использования, и разрабатываемых на базе высокоавтоматизированной технологии, доля этой группы затрат составляет только 20 - 30% всех затрат на этапе разработки. Тем не менее, Ср является по смыслу наиболее существенной составляющей, определяющей непосредственное создание функциональной части программных средств [5].

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

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

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

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

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

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

     Основные  составляющие дополнительных затрат, обеспечивающие требуемые характеристики качества программного средства целесообразно структурировать в соответствии с их номенклатурой в стандарте ISO 9126 (Приложение 1). Однако желательно эти затраты связывать с процессами жизненного цикла  программных средств. Важнейшее значение имеет установление и формализация исходных требований к характеристикам качества программных средств. Поэтому целесообразно выделять затраты на системный анализ, концепцию и проектирование требований ко всему комплексу характеристик и их атрибуты качества на начальных этапах проекта программных средств (рис. 1). На этих этапах неопределенность оценки влияния факторов наибольшая, тем не менее даже приблизительный их учет позволяет избегать грубых ошибок при оценке затрат на разработку, которые делаются экспертами зачастую без детального анализа влияния различных факторов на требуемое качество программных средств. Подобный анализ может быть базой для рационального, первичного распределения ограниченных ресурсов разработки и для управления их использованием по мере развития проекта. Учет возможного изменения затрат в зависимости от основных параметров проекта способствует упорядочению процесса разработки программных средств и концентрации усилий на тех факторах и затратах, которые могут дать максимальный эффект в повышении качества, при конкретных условиях создания программ и реальных ограничениях ресурсов.[5]

     После проведения системного проектирования, а также предварительного распределения  ресурсов, возможна ошибка в оценке совокупных затрат на разработку программного средства с требуемым качеством, приблизительно в полтора-два раза. Разработка архитектуры комплекса программ на основе прототипов и подготовка к программированию готовых апробированных алгоритмов позволяет ее уменьшить до 20-30%. Такую достоверность можно получить, конечно, только при подробном анализе и оценке влияния важнейших факторов и требований к качеству конкретного программного средства.

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

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

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

• при создании потенциально переносимых программных средств и баз данных, когда свойства эффективной мобильности предусматриваются при их первоначальной разработке, учитываются возможные платформы и области повторного использования таких программ и данных;
• при непосредственной реализации (с соответствующими затратами) процессов переноса программных средств и баз данных, в различной степени подготовленных при проектировании для переноса на иные платформы и/или для повторного использования компонентов на той же платформе в аналогичном проекте.
• при оценивании затрат первого этапа следует учитывать, что к настоящему времени накоплен большой объем прикладных программ и информации в базах данных, при создании которых не учитывалась возможность их последующего переноса на иные платформы - так называемые "унаследованные" системы. Более того, в ряде случаев из-за ограниченных ресурсов вычислительных средств при реализации крупных функциональных задач, программы и данные в таких системах в максимальной степени адаптировались при разработке к особенностям и параметрам ЭВМ для эффективного использования их ресурсов. В зависимости от степени совместимости между аппаратными и операционными платформами соответствующих ЭВМ возможны различные условия мобильности - полной или частичной несовместимости платформ, программных интерфейсов, языков программирования или диалектов одного языка и других параметров.

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

     Кроме того, любой перенос связан с затратами, которые требуются для:

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

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

     В ряде случаев может быть целесообразна  настройка готовых компонентов  на новые условия применения. При  больших изменениях условий применения, эффективной может оказаться  сборка нового программного средства с частичным использованием апробированных компонентов и с разработкой небольшой части программных модулей, обеспечивающих новые функции, интерфейсы и условия применения программного средства. При этом относительное снижение затрат пропорционально доле использования готовых комплектующих компонентов и степени их пригодности для использования в новом программном средстве. В пределе при построении нового программного средства на 80 - 90% из готовых компонентов, суммарные затраты могут сокращаться в 3 - 5 раз. В этом случае, кроме 10 - 20% затрат на создание новых программных компонентов, необходимы ресурсы на комплексирование нового программного средства, его квалификационное тестирования, испытания и документирование.

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

     Затраты на обеспечение корректности комплекса программ зависят от полноты прослеживания реализации требований к программного средства сверху вниз, в требованиях к компонентам вплоть до объектного кода программ и от степени их покрытия тестами. Эти затраты входят непосредственно в процесс разработки и зависят от объема и детальности процессов верификации и тестирования. Для сложных программных средств при требовании их высокой корректности, они могут составлять до 30% от затрат на обеспечение первичной, функциональной пригодности. Для относительно простых комплексов программ эта величина в среднем не превышает 20%. Эти затраты приходятся на верификацию и тестирование программных компонентов, что должно обеспечивать корректность, безопасность и надежность программных средств в целом. Хотя характеристики и их атрибуты принципиально различаются, затраты на их реализацию полностью разделить невозможно. Поэтому оценивание и выделение ресурсов на решение этих задач целесообразно анализировать совместно (рис. 1).

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

     Затраты на обеспечение безопасности и надежности функционирования программного средства определяются требуемым уровнем защищенности и сложностью (размером) программ для ее реализации. При наличии особенно высоких требований к безопасности критических программных средств эти затраты могут даже в 2 - 3 раза превышать затраты на решение базовых, функциональных задач. Для типовых административных систем трудоемкость создания программных средств защиты обычно составляет 20 - 40% затрат на решение основных, функциональных задач. Однако практически, в любых системах должен присутствовать минимум программных компонентов, обеспечивающих надежность и защиту от преднамеренных и случайных угроз.

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

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

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

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

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

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

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

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