Модель Нельсона. Данная модель при расчете надежности ПО учитывает вероятность выбора определенного тестового набора для очередного выполнения программы. Предполагается, что область данных, необходимых для выполнения тестирования программного средства, разделяется на k взаимоисключающих подобластей Zi, i = 1,2,…, k.
6. Модели надежности ИС. Эмпирические модели.
Эмпирические модели базируются на анализе структурных особенностей программ.
Модель сложности. Сложность ПО характеризуется его размером (количеством программных модулей), количеством и сложностью межмодульных интерфейсов. Под программным модулем в данном случае следует понимать программную единицу, выполняющую определенную функцию и взаимосвязанную с другими модулями ПО.
Существует несколько разновидностей модели сложности. В каждой из них дается некая оценка сложности программы, которая считается пропорциональной ее надежности.
Модель, определяющая время доводки программ. Анализ модульных связей ПО строится на том, что каждая пара модулей имеет конечную (возможно, нулевую) вероятность того, что изменения в одном модуле вызовут изменения в другом. Данная модель позволяет на этапе тестирования, а точнее при тестовой сборке системы, определять возможное число необходимых исправлений и время, необходимое для доведения ПО до рабочего состояния.
7. Обеспечение надежности функционирования ИС.
Информационная система — это сложная человеко-машинная система, включающая в свой состав эргатические звенья, технические средства и программное обеспечение. Все методы обеспечения надежности и достоверности ИС можно отнести к двум классам. Один включает в себя методы, обеспечивающие безошибочность (безотказность, бессбойность) функциональных технических, эргатических и программных звеньев ИС, то есть, в конечном счете, повышающие их надежность. Другой — методы, обеспечивающие обнаружение и исправление ошибок, возникающих в информации, то есть методы контроля достоверности информации и ее коррекции, косвенно также повышающие функциональную надежность системы.
Названные классы не исключают, а взаимно дополняют друг друга, поскольку в такой сложной системе, как информационная, обеспечить высокую надежность и достоверность функционирования можно, только сочетая методы обоих классов.
Обеспечение надежности технических компонентов информационных систем чаще всего реализуется аппаратным и программным способами.
В первом случае ИС использует аппаратную избыточность:
· все операции выполняются параллельно на одинаковых компонентах системы, а результаты их работы затем сравниваются, что позволяет выявить ошибки;
· в случае выхода из строя какого-либо компонента его резервные аналоги продолжают работу без остановки, а отказавший компонент заменяется на работоспособный.
Программный способ предусматривает:
· последовательное во времени выполнение одних и тех же информационных процессов и дублирование данных;
· автоматическое восстановление отказавших операционных систем, приложений и искаженных данных.
На сегодняшний день разработано много конкретных практических способов повышения надежности информационных систем.
Для обеспечения надежности технических средств чаще всего производится:
· резервирование (дублирование) технических средств (компьютеров и их компонентов, сегментов сетей и т. д.);
· использование стандартных протоколов работы устройств ИС;
· применение специализированных технических средств защиты информации.
Для обеспечения надежности функционирования программного комплекса И С требуется:
· тщательное тестирование программ, опытное исполнение программы с целью обнаружения в ней ошибок (обязательное условие эффективного тестирования — по крайней мере один раз выполнить все разветвления программы в каждом из возможных направлений);
· использование стандартных протоколов, интерфейсов, библиотек процедур, лицензионных программных продуктов;
· использование структурных методов для обеспечения надежной работы программных комплексов (иерархическое построение программ, разбиение программ на сравнительно независимые модули и т. д.);
· изоляция параллельно работающих процессов, в результате чего ошибки в работе одной программы не влияют на работу операционной системы и других программ.
Контрольные точки (точки рестарта, точки отката) — место повторного запуска программы при
аварийном ее завершении. В контрольных точках обычно выполняются: внесение изменений в БД (в том числе всех изменений, ожидающих своей очереди — неоперативные файлы), разблокирование всех файлов, на обращение к которым был наложен запрет, запись информации о контрольной точке в системный журнал.
Использование массивов RAID существенно уменьшает риск простоя системы из-за отказов накопителей на магнитных дисках, которые являются одним из наименее надежных компонентов современных
компьютеров.
В качестве наиболее эффективных мер комплексного обеспечения надежности ИС можно назвать кластеризацию компьютеров и использование отказоустойчивых компьютеров.
Кластер — это несколько компьютеров (узлов кластера), соединенных коммуникационными каналами и разделяющих общие ресурсы. Отличительной особенностью кластера является то, что каждый его работающий компьютер может взять на себя дополнительную нагрузку отказавшего узла.
8. Модели жизненного цикла ИС. Каскадная модель ЖЦ.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
- каскадная модель (70-85 г.г.);
- спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
- на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная схема разработки ПО Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных, прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид (рис. 1.2).
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
9. Технические особенности разработки программных средств. Принципы модульности и адаптируемости.
Рост объёмов и сложности ПС и баз данных (БД) информационных систем (ИС), а также требований к их качеству привели к созданию программной индустрии с большими коллективами специалистов и применению технологий автоматизированного проектирования и сопровождения, базирующихся на стандартах и нормативных документах.
Комплекс таких документов должен регламентировать технологические процессы и объекты проектирования комплексов программ на всех этапах их жизненного цикла (ЖЦ). Жизненный цикл ПС – это непрерывный процесс с момента принятия решения о необходимости использования ПС до его полного изъятия из эксплуатации. Модель ЖЦ ПС представляет собой структуру, состоящую из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение, то есть всю жизнь ПС: от установления требований к нему до снятия с эксплуатации. Структура ЖЦ ПС базируется на трёх группах процессов:
1) основные (приобретение, поставка, разработка, эксплуатация, сопровождение);
2) вспомогательные, обеспечивающие выполнение основных (документирование, конфигурационное управление, обеспечение качества, верификация, аттестация, оценка, аудит);
3) организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и совершенствование ЖЦ ПС, обучение).
При этом особое внимание уделяется качеству документации, которое во многом определяет конкурентоспособность программ и БД. При создании сложных ПС и обеспечении их ЖЦ надо сделать выборку нужных стандартов, то есть сформировать весь комплект документов (профиль), обеспечивающий регламентирование всех этапов и работ. Это позволяет строить комплексы ПС из крупных функциональных модулей, отвечающих требованиям стандартов профиля, и применять отработанные проектные решения и методы, обеспечивающие повторное использование компонентов ПС и БД на иных аппаратных и операционных платформах, то есть эффективно решать проблему мобильности и адаптируемости ПС и БД на основе CASE-технологий. Для этого применяют стандартизацию структуры ПС и их интерфейсов с операционной и внешней средой и фиксируют показатели качества ПС, которые не должны снижаться при переносе программ на другие платформы.
10. Экономические особенности разработки программных средств.
Высокая стоимость и большие ресурсы, используемые при создании сложных ПС и БД, привели к необходимости детального технико-экономического анализа и обоснования проектов ИС до начала их осуществления. Поэтому в данной дисциплине большое внимание уделено анализу ПС и методикам оценки трудоёмкости их разработки и сопровождения. Создание ПС и БД не завершается после первичных испытаний и сертификации 1-й версии, и длительное время они развиваются и модифицируются в серию версий в ходе сопровождения разработки и эксплуатации ПС.
Программы и данные в ИС являются наиболее гибкими компонентами, подверженными изменению в течение всего их жизненного цикла. Поэтому они должны контролироваться и упорядочиваться участниками проекта. Для координации их действий применяют специальные методы, методики и средства автоматизации конфигурационного управления. Они позволяют на основе отслеживания динамики изменения ПС и БД представить специалистам и руководителям состояние проекта и его компонентов в любой момент времени и не допускать хаоса при модификации программ и данных. Процессы документирования и конфигурационного управления играют стабилизирующую роль во всём ЖЦ ПС. Поэтому они располагаются на первых позициях в стандартах и обеспечивают отражение состояния и динамики проектов. Их строгое выполнение определяет технико-экономические показатели (ТЭП) проекта, его качество, длительность применения и конкурентоспособность ПС и ИС в целом. Освоение основ экономики создания и применения ИС и их компонентов позволяет рационализировать капиталовложения в средства автоматизации, прогнозировать затраты и длительность разработки систем, научно планировать создание крупных ПС и БД. Так как их разработка требует больших затрат и происходит в условиях ограниченных ресурсов, надо осуществлять баланс между достигаемым их качеством и ресурсами для их реализации, поддерживая его на всём ЖЦ. При этом особенно остро стоит задача борьбы с ростом ошибок в сложных ПС и БД, угрожающим безопасности и надёжности ИС. Для их сокращения применяют типизацию проектов ИС в определённых проблемно ориентированных областях, сборочное программирование, процессы, средства и стандарты управления конфигурацией и качеством ПС и БД.
11. Вопросы оценки трудоемкости разработки программных средств в свете требований стандартизации: этап анализа разработки.
Современный подход к оценке трудоёмкости разработки ПС состоит в учёте особенностей ЖЦ ПС на различных этапах и влияния технологических факторов не только на трудозатраты, но и на уровень качества, надёжность и экономические показатели ПС.
Разработка ПС является важнейшим элементом основных процессов ЖЦ и состоит из следующих работ и задач, сгруппированных в 5 групп (этапов):
1. Анализ разработки:
а) подготовка процесса:
определение или выбор модели жизненного цикла ПС;
документальное оформление выходных результатов в соответствии с процессом документирования;
выполнение вспомогательных процессов в соответствии с условиями договора;
выбор стандартов, методов, инструментария, языков программмирования (если они не установлены в договоре);
разработка плана проведения процесса разработки.
б) анализ требований:
технические требования к системе должны включать: требования к функциям и возможностям системы; коммерческие и организационные требования; требования пользователя; требования безопасности и защиты; эргономические требования; требования к интерфейсам; эксплуатационные требования; требования к сопровождению и квалификационные требования. Технические требования к системе должны быть оформлены документально;
оценка и документальное оформление оценки требований к системе с учетом потребностей заказчика, соответствия потребностям заказчика, тестируемости, выполнимости проектирования системной архитектуры, возможности эксплуатации и сопровождения.
12. Вопросы оценки трудоемкости разработки программных средств в свете требований стандартизации: этап проектирования.
Проектирование:
а) проектирование программной архитектуры (применительно к каждому программному объекту):
трансформирование требований к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта; распределение требований к программному объекту между его компонентами; документальное оформление архитектуры программного объекта;
разработка и документальное оформление общего (эскизного) проекта внешних интерфейсов и интерфейсов между компонентами объектов;
разработка и документальное оформление общего (эскизного) проекта базы данных;
разработка и документальное оформление предварительной версии документации пользователя;
разработка и документальное оформление предварительных требований к тестированию программного объекта, разработка графика сборки программного продукта;
оценка и документальное оформление архитектуры программного объекта и эскизных проектов.
б) техническое проектирование ПС:
разработка и документальное оформление технического проекта для каждого программного объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать, компилировать и тестировать независимо. Распределение технических требований к компонентам между программными модулями;
разработка технического проекта внешних интерфейсов, интерфейсов между программными компонентами и программными модулями;
разработка технического проекта базы данных;
уточнение документации пользователя;
определение и документальное оформление требований к испытаниям и программе испытаний программных модулей;
оценка технического проекта и требований к тестированию, документальное оформление оценки.
13. Вопросы оценки трудоемкости разработки программных средств в свете требований стандартизации: этап программирования и этап квалификационных испытаний.
Программирование:
а) программирование и тестирование компонентов ПС:
разработка и документальное оформление каждого программного модуля и базы данных;
разработка и документальное оформление процедур испытаний и данных для тестирования каждого программного модуля и базы данных;
тестирование каждого программного модуля и базы данных;
уточнение документации пользователя;
уточнение программы сборки ПС;
оценка запрограммированных элементов программного объекта и документальное оформление оценки;
б) сборка ПС:
разработка плана сборки и тестирования, документальное оформление плана;
сборка и тестирование программных модулей и компонентов, документальное оформление результатов;
подготовка к квалификационным испытаниям: разработка и документальное оформление наборов тестов, контрольных примеров, процедур испытаний;
оценка и документальное оформление оценки плана сборки, проекта, запрограммированного программного объекта, проведенных испытаний, результатов тестирования, документации пользователя.
Квалификационные испытания (тестирование) ПС:
проведение квалификационных испытаний на соответствие квалификационным требованиям к программному объекту;
уточнение документации пользователя (при необходимости);
проведение аудиторской проверки и документальное оформление результатов;
доработка программного продукта по результатам аудиторской проверки (при необходимости);
подготовка ПС к вводу в действие.
14. Вопросы оценки трудоемкости разработки программных средств в свете требований стандартизации: этап внедрения.
Внедрение ПС:
а) ввод в действие ПС:
разработка и документальное оформление плана ввода в действие программного продукта в среде эксплуатации, определенной в договоре;
ввод в действие программного продукта в соответствии с планом и условиями договора; документальное оформление работ;
б) обеспечение приемки ПС:
обеспечение проведения заказчиком оценки готовности к приемке и приемочным испытаниям; документальное оформление результатов оценки готовности;
поставка программного продукта заказчику;
первоначальное и непрерывное обучение и поддержка персонала заказчика в соответствии с условиями договора.
15. Проблемы и задачи проектирования программных средств.
ПС современных ИС являются типичными сложными системами со всеми их особенностями (наличие общей задачи и единой цели функционирования, иерархическая система связей, сложность поведения системы и др.), обуславливающими проблемы их проектирования. К ним относятся:
1) проблемы рационального структурного построения ПС, включающие:
– оптимизацию структуры ПС по критерию максимального использования ресурсов ЭВМ;
– контроль вычислительного процесса и обеспечение надёжности ПС;
– обеспечение простой корректировки ПС и др.;
2) проблемы технологии разработки ПС, включающие:
– разработку моделей алгоритмов и др. компонентов ИС;
– автоматизацию программирования на основе унификации типовых компонент программ;
– обеспечение отладки и испытаний программ;
– автоматизацию изготовления документации и др.;
3) проблемы стандартизации и унификации ПС, включающие:
– стандартизацию структуры и правил сопряжения программ по передаче управления и по обменной информации;
– унификацию правил и методов построения ПС, общих правил иерархии и взаимодействия программ и методов организации вычислительного процесса;
– стандартизацию методов и требований к обеспечению и измерению качества ПС;
– стандартизацию языков программирования.
16. Этапы ЖЦ программных средств.
По длительности ЖЦ ПС можно разделить на 2 класса:
а) с малым, б) большим временем жизни.
ПС с малым временем ЖЦ (до 3 лет) и объёмом 1 – 10 тысяч команд разрабатываются обычно в НИИ и вузах одним специалистом.
ПС с большим временем ЖЦ (10 – 20 лет, из которых 70 – 90 % приходится на эксплуатацию и сопровождение), с объёмом 10 – 1000 команд разрабатываются большими коллективами специалистов и создаются на основе промышленного регламентированного проектирования. ЖЦ таких программ включает в себя этапы: системный анализ, проектирование, эксплуатацию, сопровождение. Наиболее специфическим, трудноформализуемым и тесно связанным с функциональным назначением является этап системного анализа, на котором формируются назначение и основные показатели качества ПС.
Этапы проектирования, эксплуатации и сопровождения сильно различаются целями, задачами, методами и средствами. Процесс эксплуатации идёт параллельно и независимо от этапа сопровождения и сводится к исполнению программ на ЭВМ и обеспечению достоверности и надёжности результатов.
Этап сопровождения состоит в эксплуатационном обслуживании, развитии функциональных возможностей и характеристик ПС, а также в тиражировании ПС и переносе их на различные типы ЭВМ.
Наиболее трудоёмким является этап проектирования, требующий методической, технологической, инструментальной и организационной поддержки.
17. Виды поддержки и стадии этапа проектирования.
Методическая поддержка включает в себя комплекс стандартов, инструкций и методик, определяющих правила создания программ и конкретизирующих языки проектирования, правила использования символов, структурного построения и другие методические основы процесса создания программ.
Технологическая поддержка является детализацией документов методической поддержки, регламентирующей конкретную технологию обеспечения ЖЦ программ. Эти документы определяют допустимую трудоёмкость и длительность каждого этапа и обеспечивают нужное качество при допустимых затратах ресурсов.
Инструментальная поддержка состоит из ПС и средств вычислительной техники, обеспечивающих автоматизацию создания ПС и определяющих её программную и аппаратную оснащённость.
Процесс разработки ПС делится на стадии: техническое проектирование и рабочее проектирование.
Первая стадия включает этапы: структурное проектирование, подготовка технических средств, разработка программ.
Вторая стадия включает этапы: завершение разработки программ, отладка программ в статике, комплексная динамическая отладка программ, выпуск машинных носителей, испытания ПС.
Все виды работ и задач, выполняемых на этих этапах, сгруппированы для оценки трудоёмкости разработки ПС в 5 групп:
анализ разработки, проектирование, программирование, тестирование, внедрение.
22. Основные факторы, влияющие на трудоемкость разработки программных средств.
Качество и эффективность технологии определяется прежде всего затратами на разработку:
Ср = С1р + С2р + С3р + С4р + С5р,
где С1р – затраты, связанные с непосредственной разработкой ПС;
С2р – затраты на изготовление опытного образца (5 – 10 %), часто не учитываемые из-за малости;
С3р – затраты на программные средства автоматизации технологии;
С4р – затраты на аппаратные средства автоматизации технологии (машинное время работы ЭВМ);
С5р – затраты на повышение квалификации специалистов (часто не учитываются из-за малого значения и трудностей формализации, но рассматриваются как один из важных факторов, влияющих на величину С1р).
В результате можно считать, что для практических целей проведения анализа можно пользоваться формулой
Cр = С1р + С3р + С4р.
В этой сумме при создании средних и крупных ПС все три составляющие примерно равны, но основное внимание при анализе следует обращать на С1р, так как на неё наиболее сильно влияет объём разработки ПС. Приближённо можно считать, что затраты на разработку должны быть прямо пропорциональны объёму создаваемых ПС (Пк) при одной и той же производительности труда разработчиков, измеряемой числом созданных команд за один человеко-день труда. При этом учитывается труд не только программистов, но и разработчиков алгоритмов, системных аналитиков и обслуживающего персонала.
18. Статический анализ программных средств.
Статический анализ (СА) – это процесс анализа исходного текста программы без её выполнения на ЭВМ.
СА программ проводится:
– для проверки модульной структуры программного средства, а также логической структуры отдельных модулей и сравнения этих структур с приведенными в программной документации;
– подготовки исходных данных для проведения динамического анализа ПС и разработки плана тестирования ПС;
– оценки конструктивных характеристик программы, степени простоты модификации и сопровождения программы;
– определения наличия несовершенства в программе, неиспользуемых участков программы, лишних переменных;
– оценки текстовой сложности программы, затрат на ее разработку и освоение;
– экспертизы идентичности программ при установлении авторства и разрешении правовых споров;
– определения количественных характеристик при оценке уровня качества программы.
Статический анализ начинается со стадии проектирования программы (укрупненный анализ) и продолжается на всех последующих фазах жизненного цикла программного средства.
Статический анализ программного средства предусматривает получение следующих характеристик (графических и метрических):
модульная структура ПС;
логическая структура отдельного программного модуля;
характеристика текста программы.
Модульная структура анализируемого ПС представляется в виде графа вызовов; списка путей вызовов; матрицы вызовов и достижимости; точек вызовов; метрик иерархии вызовов.
Логическая структура отдельного программного модуля представляется в виде графа управления; путей тестирования; метрик структуры управления.
Характеристики текста программ включают в себя: статистические данные о комментированности программы и текстовые метрики Холстеда.
Граф вызовов – это ориентированный граф, в котором вершины – модули ПС, а рёбра ориентированы от вызывающего модуля к вызываемому.
Граф управления −это ориентированный граф, вершинами которого являются логические блоки, а направленные ребра ориентированы в направлении передачи управления между блоками.
Логический блок программы – это участок программы, состоящий из одного или нескольких операторов и не имеющий разветвлений. Матрица вызовов и достижимости – это матрица, характеризующая отношение вызова и достижимости между произвольными парами программных компонент (модулей).
Путь вызовов – это последовательность соприкасающихся ребер из графа вызовов, где начальная вершина есть корень графа, а конечная − лист дерева.
Путь тестирования – это маршрут в графе управления программного модуля, начальная вершина которого является входной вершиной графа, а конечная вершина − выходной вершиной графа.
Точка вызовов – это местоположение вызова программной компоненты (модуля), задаваемое номером строки и столбца расположения оператора вызова.
Кроме этого СА предусматривает определение ряда количественных характеристик, таких как иерархическая и структурная сложность, тестируемость и др.
Иерархическая сложность: I = N / L, где N – количество вершин в графе вызовов модулей; L – количество уровней.
Иерархическая сложность характеризует среднюю ширину уровня в графе вызовов, т.е. количество проектных решений, принимаемых на отдельном шаге разработки программы.
Структурная сложность: S = D / N, где D – количество ребер в графе вызовов модулей; N – количество вершин.
Тестируемость – это свойство ПС, заключающееся в их приспособленности к эффективному применению контрольных тестов, зависящей от степени разветвления вычислительного процесса и
доступности модулей.
Доступность узла (модуля) характеризует структурную вероятность вызова этого модуля, зависящую от разветвленности дерева вызовов.
Если показатель тестируемости имеет малое значение, то затрудняется тестирование модулей нижних уровней иерархии, особенно при применении автоматизированных методов тестирования.
19. Критерии оценки технологий проектирования программных средств.
Эффективность (полезность) технологий характеризуется в основном трудоёмкостью и длительностью создания ПС, а также достигаемым качеством. Критерии оценки качества ПС и ТЭП позволяют осуществлять целевое управление их разработкой при применении конкретных технологий.
В процессе разработки ТЗ выявляются основные показатели, устанавливается относительная важность каждого из них и строится обобщённая целевая функция требуемого качества, а также устанавливаются допустимые затраты и длительность разработки ПС, которые должны обеспечить соответствующие технологии.
После завершения отладки и испытаний эти показатели и обобщённая функция уточняются на предмет их соответствия ТЗ.
Различают функциональные и конструктивные критерии качества ПС.
Первые отражают специфику применения и степень соответствия ПС их целевому назначению (номенклатуру исходных данных, достоверность результатов, разнообразие функций редактирования и т.д.). В ряде случаев их можно свести к показателям обобщённой экономической эффективности применения ПС в ЖЦ, характеризуемой величиной экономии труда, энергии, материалов и т.п.
Вторые критерии оценивают сложность программ, надёжность функционирования, ресурсы ЭВМ, корректность программ и др.
Особо следует выделить временные показатели ЖЦ программ (длительность проектирования, продолжительность эксплуатации и время проведения модификаций), которые в ряде случаев могут быть более важными, чем трудоёмкость. Поэтому для каждой разработки целесообразно проводить ранжирование критериев и влияющих характеристик на всех этапах ЖЦ.
20. Суть управления качеством программных средств.
Для управления качеством необходима формализация технологии проектирования, а также независимое измерение, контроль и анализ критериев качества ПС и влияющих на них факторов. Управление качеством ПС включает:
анализ системных требований к ПС и ранжирование критериев качества,
разработку методик и стандартов контроля выполнения правил модульно-иерархического построения ПС,
создание методов и технологии поэтапного контроля выполнения заданных требований к качеству ПС,
применение средств инструментальной, технологической поддержки автоматизации программирования, отладки и испытаний, обеспечивающих создание ПС с заданными значениями критериев качества.
Важнейшим для качества ПС является этап системного анализа и формирования ТЗ.
При этом необходимо учитывать 2 типа ограничений:
1) ограничения знаний о методах решения задач,
2) ограничения ресурсов, доступных для реализации ПС.
21.Составляющие затрат в жизненном цикле программных средств.
Почти всегда критерии качества связаны с экономическим эффектом от применения ПС. Его можно выразить доходом, повышением производительности труда или прибыли, снижением затрат, энергопотребления и др. экономическими показателями. Во многих случаях наиболее просто и обобщённо экономический эффект можно описать доходом Э от использования ПС в течение ЖЦ продолжительностью t:
Э = Эид – Cсум,
где Эид – идеальная эффективность применения программ;
Cсум – суммарные потери и затраты, снижающие предельный доход.
Это снижение происходит вследствие затрат на разработку Cр, сопровождение Cс, эксплуатацию Сэ и из-за потерь в результате недостаточной надёжности Сн. Тогда Э = Эид – Ср – Сс – Сэ – Сн.
Динамику совершенствования программ характеризует величина экономической эффективности, отнесенная к общим затратам, при которых она достигнута, что позволяет ограничивать качество при больших затратах.
24. Общие сведения о сертификации информационных систем и их программных средств.
Сертификация – это деятельность определённого органа (организации), независимого (ой) от изготовителя (продавца) и потребителя продукции, по подтверждению её соответствия установленным требованиям технических регламентов, положениям стандартов или условиям договоров. Сертификация ИС предполагает удостоверение достигнутого качества и надёжность функционирования созданных ИС.
С технической точки зрения, качество – это совокупность свойств продукции, обуславливающих её способность удовлетворять определённые потребности в соответствии с её назначением. Одним из важнейших компонентов ИС, определяющих ее качество, является программная продукция. Весь объём признаков и характеристик программной продукции, относящийся к её способности удовлетворять потребностям пользователей ИС, определяет качество программного обеспечения (ПО) ИС.
Такие признаки и характеристики определяют свойства ПО, по которым его качество описывается и оценивается. К ним относятся: функциональные возможности, надёжность, практичность, эффективность, сопровождаемость, мобильность. Каждая из этих характеристик может быть уточнена на множестве уровней комплексных показателей (подхарактеристик), определяемых с учётом разрабатываемых для этих целей метрик качества. Метрика качества – это количественный масштаб (мера) и метод, которые могут быть использованы для определения значений признаков или характеристик конкретного ПО и последующей оценки уровня качества ИС.
Уровень качества – это относительная характеристика, основанная на сравнении совокупности характеристик качества продукции с соответствующей совокупностью базовых характеристик, принимаемых за исходные (эталонные). Для осуществления такого сравнения используют ранжирование (действие по отнесению измеренного значения характеристики к соответствующему уровню ранжирования).
Уровень ранжирования – это диапазон значений характеристики в масштабе, позволяющем классифицировать (ранжировать) ПО в соответствии с потребностями пользователей и принятыми критериями оценки качества ПО.
Критерии оценки качества ПО – это набор определённых и задокументированных правил и условий, которые используются для решения о приемлемости общего качества конкретного ПО, принимаемого в результате сертификации. При таком положительном решении выдаётся сертификат соответствия установленным требованиям.
Кроме этого сертифицированная продукция маркируется знаком соответствия, зарегистрированным в установленном порядке по правилам соответствующей системы сертификации, относящейся к данной группе продукции.
Орган, возглавляющий систему сертификации однородной продукции, называется центральным органом системы сертификации или центром по сертификации. В его подчинении находятся органы, проводящие сертификацию соответствия, и испытательные лаборатории, проводящие испытания определённой продукции. При объединении этих функций в одном юридическом лице используется термин «сертификационный центр». Эти органы подвергаются периодически аккредитации – процедуре официального признания (соответствующим уполномоченным органом) компетентности и возможности выполнения конкретных работ в заданной области.
Взаимоотношения между участниками – разработчиками (продавцами), пользователями (покупателями) и органами сертификации и аккредитации, а также их права и обязанности регулируются Законом № 184-ФЗ от 27.12.02 «О техническом регулировании
25. Особенности сертификации программного обеспечения.
Рекомендованные шесть характеристик качества ПО (функциональность, надежность, практичность, эффективность, сопровождаемость, мобильность) представляют основу для оценки и сертификации программ различных классов. Важность каждой характеристики качества меняется в зависимости от класса ПО, а также от различных точек зрения на их важность со стороны пользователя, разработчика и руководителя. В соответствии с этим разработчиками могут использоваться различные метрики для одних и тех же характеристик ПО, потому что одни и те же метрики не применимы для всех фаз ЖЦ ПО.
Считается общепринятым, что наиболее объективным путём определения важности характеристик является путь проведения экспертных оценок на предмет выявления свойств, определяющих качество ПО конкретного применения, включая и те, которые не вошли в шесть обязательных характеристик, и упорядочение их по предпочтительности.
Руководствуясь этим, в интересах оценки и сертификации ИС специального назначения одним из авторов при выполнении соответствующей НИР был проведен опрос, в основу которого была положена анкета с включённой в неё совокупностью характеристик (свойств), полученной в результате анализа требований к ПО данной ИС. Результаты обработки такой информации: Характеристики свойств ПО
Наименование свойств Коэффициент Ранг свойства важности
Функциональные возможности 0,35 1
Надёжность 0,25 2
Сопровождаемость 0,20 3
Эффективность 0,15 4
Мобильность 0,03 5
Практичность 0,02 6
С учётом полученных данных применительно к рассмотренному классу ПО можно выделить:
а) основные свойства – функциональные возможности, надёжность, сопровождаемость, эффективность;
б) дополнительные свойства – мобильность, практичность.
Для таких сложных систем, как ПО ИС, нет возможности описать все свойства количественными показателями. Поэтому при разработке, испытаниях, сертификации и эксплуатации ПО приходится использовать две группы показателей качества (ПК):
1) объективные (количественные) ПК, характеризуемые реально измеряемыми физическими величинами;
2) субъективные (качественные) ПК, характеризуемые, как правило, фактом практического наличия или отсутствия того или иного свойства у ПО и оцениваемые соответственно 1 или 0.
Модель процесса оценивания качества и сертификации ПО должна отражать основные этапы, требуемые для оценивания по характеристикам, рекомендуемым стандартом, в соответствии с которым процесс состоит из трёх стадий:
1) установление (определение) требований к качеству,
2) подготовка к оцениванию,
3) процедура оценивания.
Требования должны формулироваться в установленных ГОСТом терминах характеристик качества и комплексных показателей.
Подготовка к оцениванию включает в себя:
а) выбор метрик (показателей), сводящийся к установлению количественного масштаба и метода для определения значения того или иного признака свойств ПО;
б) определение уровней ранжирования, представляющее собой разделение всей шкалы выбранных метрик на диапазоны, соответствующие различным степеням удовлетворения требований по конкретным показателям;
в) определение критериев оценки, позволяющих подытоживать результаты оценивания различных характеристик с помощью специальных таблиц решений, среднего взвешивания или других приёмов, для получения вывода о приемлемости результатов оценки отдельных признаков свойств и качества ПО в целом, о приёмке или отбраковке программной продукции.
Процедура оценивания включает:
а) измерение, результатом которого является получение измеренного признака свойств в масштабе выбранной метрики;
б) ранжирование, устанавливающее отнесение измеренного признака к тому или иному уровню;
в) оценка, являющаяся последним этапом процесса оценивания ПО, на котором обобщается множество установленных уровней и результатом которого является заключение о качестве ПО, по которому после сравнения с другими факторами, такими как время и стоимость, принимается решение о выпуске (или невыпуске) программной продукции и её сертификации.
23. Длительность разработки программных средств, распределение затрат по этапам разработки.
Диапазон приемлемых длительностей разработок Tр ограничен сверху 10 годами (рациональными сроками создания самых сложных ИС), а снизу – 1 – 3,5 года (сроками естественного технологического процесса).
Среднюю длительность разработки можно аппроксимировать зависимостью
Тр = 0,8 Пк1/3, или Тр = 1,4 Пк¼ лет, где Пк – объём ПС в тысячах команд.
По опыту эксплуатации трудоёмкость отдельных этапов разработки различается в 2 – 4 раза, а загрузка отдельных категорий специалистов на них – в 3 – 5 раз. Это надо учитывать при планировании и организации проектирования ПС, а также при прогнозировании затрат на непосредственную разработку программ. Так же неравномерно в зависимости от этапов изменяется и потребность в машинном времени С4р, причём для разных ЭВМ (моделирующих, технологических, реализующих) эта потребность находится в широком диапазоне и является максимальной для этапа динамической отладки. Такие оценки затрат машинного времени позволяют рационально планировать и прогнозировать необходимую аппаратную оснащённость разработок по этапам и в целом на весь ЖЦ. Упорядоченный подход к организации проектирования сложных ПС с учётом вышеизложенного позволяет создавать ПС с высоким качеством и допустимыми затратами, если использовать современные технологии, методы и системы автоматизации проектирования, выбирая их на основе системного и технико-экономического анализа достигаемого эффекта и ресурсов на весь ЖЦ.
27.Показатели качества ПО.
Качество программного обеспечения (software quality) - совокупность свойств ПО, которые обусловливают его пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с его назначением.
Качество программного обеспечения может быть оценено следующими характеристиками;
1. Функциональность (functionality) - совокупность свойств ПО, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности качества наряду с ее надежностью как технической системы (пригодность, правильность, способность к взаимодействию, защищенность, согласованность).
2. Надежность (reliability)- совокупность свойств, характеризующая способность программного средства сохранять заданный уровень пригодности в заданных условиях в течение заданного интервала времени (завершенность, устойчивость к ошибкам, восстанавливаемость, согласованность).
3. Практичность (usability)- совокупность свойств ПО, характеризующая усилия, необходимые для его использования, и оценку результатов его использования заданным кругом пользователей ПО (понятность, обучаемость, простота использования, привлекательность, согласованность).
4. Эффективность (efficiency)- совокупность свойств ПО, характеризующая аспекты его уровня пригодности, которые связаны с характером и временем использования ресурсов, необходимых при заданных условиях функционирования.
Примечание: правильнее эту характеристику называть производительностью (performance); тогда как эффективность должна также зависеть от затрат на создание и внедрение ПО.
5. Сопровождаемость (maintainability)- совокупность свойств ПО, характеризующая усилия, которые необходимы для его модификации. Модификация, может осуществляться для устранения дефектов, усовершенствования ПО или его адаптации к изменениям в условиях функционирования, a также в составе и особенностях требуемых функций.
6. Мобильность (portability) - совокупность свойств ПО, характеризующая приспособленность для переноса из одной среды функционирования в другие (адаптируемость, простота установки, сосуществование, взаимозаменяемость).
26. Порядок и методология проведения статического анализа программных средств.
Статический анализ проводится в соответствии со стандартом, все положения которого подлежат обязательному применению в испытательных центрах (лабораториях), аккредитованных в системе РОСИНФОСЕРТ. Данный стандарт распространяется на все программные средства независимо от их назначения и области применения. Проведение СА начинается обычно с построения графа вызовов, который отражает модульную структуру ПС. Вершины графа изображаются в виде прямоугольников, содержащих имена компонент (модулей), ребра – в виде стрелок. Затем формируется список путей вызовов.
Путь вызова представляет собой последовательность соприкасающихся ребер из графа вызовов (конечная вершина ребра является начальной вершиной следующего ребра), где начальная вершина первого ребра есть корень графа, а конечная вершина всегда представляет собой компоненту, которая не содержит последующих вызовов, т.е. если иерархия вызовов является древовидной структурой, то это лист дерева.
Обычно в списке путей вызовов представлены все пути, которые подлежат тестированию.
Более наглядное и удобное представление о логической структуре даёт матрица вызовов и достижимости, которая содержит информацию о двух основных типах структур вызова между произвольными парами компонент. Элементы в иерархии вызовов могут находиться в одной из взаимосвязей:
одна из них непосредственно вызывает другую;
в графе вызовов существует путь, начинающийся на одном из элементов данной пары и заканчивающийся на другом, т.е. элементы рассматриваемой пары не могут быть вызваны друг из друга непосредственно, а лишь через цепочку последовательных вызовов.
Строки и столбцы матрицы содержат имена компонент в иерархии вызовов и упорядочены по иерархическим уровням сверху вниз.
Путь тестирования определяется как маршрут в графе управления, начальная вершина которого является входной вершиной графа, а конечная вершина – выходной вершиной графа. Программа может иметь бесконечно большое число возможных путей тестирования. В этом случае тестирование сводится к исполнению некоторого набора маршрутов, покрывающего каждую ветвь хотя бы один раз.
Оценка тестируемости ПС–(T) может быть проведена с использованием формул
Nв
Т = [(1 / Nв) · (∑1 / Pi)]-1,
i=1
где NВ – количество путей вызовов в графе вызовов модулей;
Pi – тестируемость i-го пути вызовов, равная
k
Pj = [∑1 / A(Mj)]-1,
j=1
где k – количество модулей в пути вызовов; А (Мj) – доступность модуля
Мj, принадлежащего пути Рi, определяется следующим образом:
n
А (Мj) = ∑ А (Мx) / C (Мx),
x=1
где А (Мx) – доступность x-го модуля, вызывающего Мj;
C (Мx) – количество всех модулей, которые вызывает Мx;
n – количество модулей, которые вызывают Mj;
А(М) = 1, если модуль М является самым верхним (головным) модулем.
Рассмотренный выше ручной метод статического анализа, заключающийся в детальном просмотре исходного текста программ специальным экспертом, имеет следующие недостатки:
приводит к большим затратам времени и человеческих ресурсов;
требует привлечения эксперта высокой квалификации (как программиста и как эксперта качества);
точность результатов не всегда удовлетворительна из-за больших объемов и сложности программ (в ряде случаев человеческие возможности не позволяют применить ручной анализ).
Автоматизированные средства способны вычислить или помочь в определении самых трудоемких характеристик, позволяя таким образом эксперту сосредоточить внимание на интерпретации полученных характеристик и уровне качества программы.
Независимо от способа проведения СА (автоматизированного или ручного) следует учитывать особенности СА на различных этапах.
1) Анализ и проектирование
Применение статического анализа на этих этапах требует прежде всего наличия инструментального средства формальной спецификации, обеспечивающего хранение результатов в машинообрабатываемой форме.
Статический анализ на этих этапах применяется прежде всего для выявления ошибок и аномалий, т.е. является средством управления качеством в отличие от этапа программирования, где имеет оценочный характер.
Применение статического анализа на этапах анализа и проектирования, несмотря на ограниченность измеряемых характеристик, способствует раннему обнаружению ошибок, трудноисправимых на последующих этапах.
2) Программирование
На этом этапе статический анализ используется для оценки качества программы, а также для документирования (при разработке документов сопровождения).
3) Тестирование и отладка
На этом этапе статический анализ применяется для получения исходной информации при подготовке и оценки полноты тестов.
