Анализ проектов сложных программных комплексов по характеристикам качества

1.

Анализ проектов сложных
программных комплексов
по характеристикам
качества
Выполнили:
Скворцов Владимир
Феглер Юлия

2.

Основные понятия
Программный комплекс – совокупность программных элементов,
предназначенных для выполнения конкретной функции или набора
функций.
Программное средство – программа или множество программ,
используемых для управления компьютером (ISO/IEC 26514:2008).
Риски - это события, которые могут негативно повлиять на продукт или
услугу: снизить эффективность, качество, способствовать расходам и т.
д.
Характеристики качества - совокупность свойств, определяющих
полезность изделия (программы) для пользователей в соответствии с
функциональным назначением и предъявленными требованиями.

3.

Отличия комплекса и программного
обеспечения
В отличие от программного комплекса, в котором объединены
программы, нацеленные на решение задачи (задач) в одной
предметной области, пакет прикладных программ (пакет
приложений) объединяет программы ("компоненты" в
терминологии ГОСТ 19.101-77), которые решают схожие задачи в
разных предметных областях.

4.

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

5.

Определение понятия качества ПО
Качество ПО — это относительное понятие, которое имеет смысл
только при учете реальных условий применения ПО. Поэтому
требования, предъявляемые к качеству ПО, ставятся в соответствии
с условиями и конкретной областью применения ПО.

6.

Модели качества ПО
Делится на уровни определения характеристик, делится по
уровням:
- Первый
- Второй
- Третий
- Четвертый

7.

Первый уровень качества
Первый уровень соответствует определению характеристик (показателей) качества
ПО, каждая из которых отражает отдельную точку зрения пользователя на качество.
Согласно стандартам ГОСТ Р ИСО/МЭК 9126—93, ГОСТ Р ИСО/МЭК 12119—2000, ГОСТ
28195—89, в модель качества входит шесть характеристик, или шесть основных
показателей качества, которые перечислим в порядке их значимости для большинства
пользователей:
• функциональные возможности;
• функциональная надежность;
• удобство применения;
• эффективность;
• сопровождаемость;
• переносимость.

8.

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

9.

Набор атрибутов
для показателей
качества

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

Как можно повысить качество ПС
Трудности и длительность освоения методологий подобных СММ
заставили МО США обратиться к поиску фрагментарных рецептов,
способных значительно повысить качество ПС, путем применения
ограниченной совокупности ключевых мероприятий по
обеспечению качества программ и эффективному управлению
проектами. Специальное подразделение экспертов SPMN (Software
Program Managers Network) разработало стратегию использования
критически важных практических приемов СВР (Critical Best
Practices), которая относительно быстро, за несколько месяцев,
позволяет предприятию достигнуть третьего - четвертого уровня
зрелости СММ.

18.

Стратегия использования практитческих
приемов CBP (Critical Best Practices)
Они предлагают:
• сосредоточиться на количественных параметрах завершения
проекта;
• регулярно измерять продвижение к цели и активность реализации
проекта;
• как можно раньше выявлять ошибки и логические неувязки;
• детально планировать работу;
• сводить к минимуму неконтролируемые изменения.

19.

Программа должна обладать:
• Устойчивость — свойство осуществлять требуемое
преобразование информации при сохранении выходных решений
программы в пределах допусков, установленных спецификацией.
• Восстанавливаемость — свойство программного обеспечения,
характеризующее возможность приспосабливаться к
обнаружению ошибок и их устранению.
• Надежность - характеризует как программу, так и ее "окружение"
(качество аппаратуры, квалификацию пользователя и т. п.)

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

Методика оценки программных
средств

31.

Определение целей оценки
Стоящая перед экспертами цель оценки влияет на разрабатываемую
модель качества ПС и, следовательно, на весь процесс оценки.
Положим в качестве соответствии со стандартом ISO/IEC 25 000, в
соответствии со стандартом ISO/IEC 25 000.

32.

Модели качества ПО
• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.