Номенклатура показателей качества 6 страница
Известны некоторые типовые модели ЖЦ ПО, которые проявили себя в определенных условиях, имеют определенные преимущества, недостатки и условия применимости.
2.8.2. Каскадная модель
 |
Каскадная модель (водопад – waterfall) включает выполнение следующих фаз (рис.2.4).
Рис.2.4. Схема каскадной модели ЖЦ ПО
1. Исследование концепции – происходит исследование требований, разрабатывается видение продукта и оценивается возможность его реализации.
2. Определение требований – определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейсы.
3. Разработка проекта – разрабатывается и формулируется логически последовательная техническая характеристика программной системы, включая структуры данных, архитектуру ПО, интерфейсные представления и процессуальную (алгоритмическую) детализацию.
4. Реализация – эскизное описание ПО превращается в полноценный программный продукт. Результат: исходный код, база данных и документация. В реализации обычно выделяют два этапа: реализацию компонент ПО и интеграцию компонент в готовый продукт. На обоих этапах выполняется кодирование и тестирование, которые тоже иногда рассматривают как два подэтапа.
5. Эксплуатация и поддержка – подразумевает запуск и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректировку или устранение ошибок.
6. Сопровождение – устранение программных ошибок, неисправностей, сбоев, модернизация и внесение изменений. Состоит из итераций разработки.
Основными принципами каскадной модели являются:
· строго последовательное выполнение фаз:
· каждая последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы;
· каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные;
· каждая фаза полностью документируется
· переход от одной фазы к другой осуществляется посредством формального обзора с участием заказчика
· основа модели – сформулированные требования (ТЗ), которые меняться не должны;
· критерий качества результата – соответствие продукта установленным требованиям.
Каскадная модель имеет следующие преимущества:
· проста и понятна заказчикам;
· проста и удобна в применении:
¨ процесс разработки выполняется поэтапно;
¨ ее структурой может руководствоваться даже слабо подготовленный в техническом плане или неопытный персонал;
¨ она способствует осуществлению строгого контроля менеджмента проекта;
· каждую стадию могут выполнять независимые команды (все документировано);
· позволяет достаточно точно планировать сроки и затраты.
При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки:
· попытка вернуться на одну или две фазы назад, чтобы исправить какую–либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;
· интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок;
· запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат.
Недостатки каскадной модели особо остро проявляются в случае, когда трудно или невозможно сформулировать требования или требования могут меняться в процессе выполнения проекта. В этом случае разработка ПО имеет принципиально циклический характер.
Каскадная модель не утратила своей актуальности при решении задач, для которых требования и их реализация максимально четко определены и понятны или используется неизменяемое определение продукта и вполне понятные технические методики. Это задачи типа:
· научно–вычислительного характера (пакеты и библиотеки научных программ типа расчета несущих конструкций зданий, мостов, деталей машин и т.п.);
· операционные системы и компиляторы;
· системы реального времени управления конкретными объектами.
Кроме того, каскадная модель применима в условиях:
· повторной разработки типового продукта (автоматизированного бухгалтерского учета, расчета зарплаты и т.п.);
· выпуска новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (перенос уже существующего продукта на новую платформу).
И, наконец, принципы каскадной модели находят применение как элементы моделей других типов.
2.8.3. Спиральная модель
На практике разработка ПО имеет циклический характер, когда после выполнения некоторых стадий приходится возвращаться на предыдущие. Можно указать две основные причины таких возвратов:
· Ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях – ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования.
· Изменение требований в процессе разработки («ошибки» заказчиков). Это или неготовность заказчиков сформулировать требования, или изменения требований, вызванные изменениями ситуации в процессе разработки (изменения рынка, новые технологии и т.п.).
Основные принципы спиральной модели можно сформулировать следующим образом:
· разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам;
· создание прототипов ПО как средства общения с заказчиком для уточнения и выявления требований;
· планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту;
· переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок;
· использование каскадной модели как схемы разработки очередного варианта;
· активное привлечение заказчика к работе над проектом; заказчик участвует в оценке очередного прототипа ПО, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков.
Схема работы спиральной модели выглядит следующим образом (рис.2.5). Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом, начальные стадии, связанные с анализом и планированием представлены более подробно с добавлением новых элементов.
В каждом цикле выделяются четыре базовые фазы:
· определение целей, альтернативных вариантов и ограничений;
· оценка альтернативных вариантов, идентификация и разрешение рисков;
· разработка продукта следующего уровня;
· планирование следующей фазы.
«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку ПО. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На фазе разработки создается концепция (видение) продукта и путей его создания.
 |
Рис.2.5. Схема спиральной модели ЖЦ ПО
Следующий цикл начинается с планирования требований и деталей ЖЦ продукта для оценки затрат. На фазе определения целей устанавливаются альтернативные варианты требований, связанные с ранжированием требований по важности и стоимости их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки – спецификация требований (с указанием рисков и стоимости), готовится демоверсия ПО для анализа требований заказчиком.
Следующий цикл – разработка проекта – начинается с планирования разработки. На фазе определения целей устанавливаются ограничения проекта (по срокам, объему финансирования, ресурсам, …), определяются альтернативы проектирования, связанные с альтернативами требований, применяемыми технологиями проектирования, привлечением субподрядчиков. На фазе оценки альтернатив устанавливаются риски вариантов и делается выбор варианта для дальнейшей реализации. На фазе разработки выполняется проектирование и создается демоверсия, отражающая основные проектные решения.
Следующий цикл – реализация ПО – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов. Фаза разработки выполняется по каскадной модели с получением действующего варианта (прототипа) продукта.
Отметим некоторые особенности спиральной модели:
· до начала разработки ПО есть несколько полных циклов анализа требований и проектирования;
· количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи;
· в модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.
Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества:
· более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях;
· поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика;
· участие заказчика в выполнении проекта с использованием прототипов программы; заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования;
· планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ;
· возможность разработки сложного проекта по частям, выделяя на первых этапах наиболее значимые требования.
Основные недостатки спиральной модели связаны с ее сложностью:
· сложность анализа и оценки рисков при выборе вариантов;
· сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий);
· сложность оценки точки перехода на следующий цикл;
· бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки.
Спиральную модель целесообразно применять при следующих условиях:
· проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения;
· пользователи не уверены в своих потребностях или требования слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований;
· достижение успеха не гарантировано и необходима оценка рисков продолжения проекта;
· речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата;
· при выполнении очень больших проектов, которые в силу ограниченности ресурсов можно делать только по частям.
2.8.4. Другие типы моделей
Существуют некоторые другие типы моделей, которое можно рассматривать как промежуточные между каскадной и спиральной моделями. Эти модели используют отдельные преимущества каскадной и спиральной моделей и достигают успеха для определенных типов задач.
 |
Итерационная модель ЖЦ (рис.2.6) является развитием классической каскадной модели и предполагает возможность возвратов на ранее выполненные этапы.
Рис.2.6. Схема итерационной модели ЖЦ ПО
Причинами возвратов в классической итерационной модели являются выявленные ошибки, устранение которых и требует возврата на предыдущие этапы в зависимости от типа ошибки – ошибки кодирования, проектирования, спецификации или определения требований. Реально итерационная модель является более жизненной, чем классическая каскадная модель, т.к. создание ПО всегда связано с устранением ошибок. Практически все применяемые модели ЖЦ имеют итерационный характер, но цели итераций могут быть разными.
 |
V-образная модель (рис.2.7) была создана как итерационная разновидность каскадной модели. Целями итераций в этой модели является обеспечение процесса тестирования. Тестирование продукта обсуждается, проектируется и планируется на ранних этапах ЖЦ разработки. План испытания приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы – на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели. Помимо планов на ранних этапах разрабатываются также и тесты, которые будут выполняться при завершении параллельных этапов.
Рис.2.7. Схема V-образной модели ЖЦ ПО
Инкрементная (пошаговая) модель (рис.2.8) представляет собой процесс поэтапной реализации всей системы и поэтапного наращивания функциональных возможностей. На первом шаге необходим полный заранее сформулированный набор требований, которые делятся по некоторому признаку на части. Далее выбирается первая группа требований и выполняется полный проход по каскадной модели.
После того, как первый вариант системы, выполняющий первую группу требований, сдан заказчику, разработчики переходят к следующему шагу (второму инкременту) по разработке варианта, выполняющего вторую группу требований. Особенностью инкрементной модели является разработка приемочных тестов на этапе анализа требований, что упрощает приемку варианта заказчиком и устанавливает четкие цели разработки очередного варианта системы. Кроме того, инкрементная модель для внутренней итерации может использовать не только каскадную, но и другие типы моделей.
 |
Рис.2.8. Схема инкрементной модели ЖЦ ПО
Инкрементная модель особенно эффективна в случае, когда задача разбивается на несколько относительно независимых подзадач (разработка подсистем «Зарплата», «Бухгалтерия», «Склад», «Поставщики»).
Модель быстрого протитипирования (рис.2.9) предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.
Начало ЖЦ разработки помещено в центре эллипса. Совместно с пользователем разрабатывается предварительный план проекта на основе предварительных требований. Результат начального планирования – документ, описывающий в общих чертах примерные графики и результативные данные.
Следующий уровень – создание исходного прототипа на основе быстрого анализа, проекта база данных, пользовательского интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует очередной прототип, пользователь оценивает его функционирование, совместно определяются проблемы и пути их преодоления для перехода к следующему прототипу. Этот процесс продолжается до тех пор, пока пользователь не согласится, что очередной прототип в точности отображает все требования. Получив одобрение пользователя, быстрый прототип преобразуют в детальный проект и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой.
 |
Рис.2.9. Схема модели быстрого прототипирования
При разработке производственной версии программы может понадобиться более высокий уровень функциональных возможностей, различные системные ресурсы, необходимые для обеспечения полной рабочей нагрузки или ограничения во времени. После этого следуют тестирование в предельных режимах, определение измерительных критериев и настройка, а затем, как обычно, функциональное сопровождение.
В настоящее время широкое применение получают так называемые промышленные технологии создания программного продукта. Эти технологии были разработаны фирмами, накопившими большой опыт создания ПО. Такие технологии, как правило, поддерживаются набором CASE–средств, охватывают все этапы жизненного цикла продукта и успешно применяются для решения практических задач. Эти технологии подробно рассматриваются в курах «Технологии разработки программного обеспечения», «САПР программного обеспечения».
Вопросы по теме
1. Назначение базового профиля жизненного цикла программных средств.
2. Что такое жизненный цикл программного продукта?
3. Какие особенности имеют стандарты жизненного цикла программных средств по сравнению с другими техническими объектами?
4. Какие особенности имеют сложные комплексы программ по сравнению с относительно небольшими программами?
5. Какие специалисты участвуют в жизненном цикле сложных комплексов программ? Какие функции они выполняют?
6. Что является методической основой технологии жизненного цикла программных средств?
7. На каких принципах основывается административное управление жизненным циклом и качеством программных средств? Охарактеризуйте их.
8. Основные цели регламентирования процессов и применения стандартов в жизненном цикле программных средств.
9. Назовите основные общесистемные стандарты жизненного цикла программных средств. Какие функции они выполняют?
10. Что такое программный продукт, процесс, задача?
11. Какие типы процессов и конкретные процессы вы запомнили?
12. Что такое модель жизненного цикла ПО?
13. Какие типы моделей вы знаете? В чем их преимущества, недостатки, область применимости?
3. основные понятия и характеристики качества программных средств
3.1. Основные факторы, определяющие качество программных средств
Выбор и формирование требований к ПС состоит в анализе необходимых свойств, характеризующих качество его функционирования и применения с учетом ресурсных возможностей разработчиков. При этом под качеством функционирования понимается множество свойств, обуславливающих пригодность ПС обеспечивать надежное и своевременное представление требуемой информации потребителю для ее дальнейшего использования по назначению.
В соответствии с принципиальными особенностями, назначением и свойствами каждого ПС при проектировании должны выбираться номенклатура и значения характеристик качества, которые впоследствии отражаются в ТЗ и в технической документации на конечный продукт. Каждая характеристика качества может эффективно использоваться, если определена ее метрика, мера и шкала и может быть указан способ ее измерения или оценивания, а также сопоставления с требующимся значением. Они должны, прежде всего, отражать функциональную пригодность для применения ПС с заданными целями.
Качество изменяется в течение ЖЦ ПС, то есть его требуемое и реальное значение в начале ЖЦ почти всегда отличается от фактически достигнутого при завершении проекта. На практике важно оценивать качество программ не только в завершенном виде, но и в процессе их проектирования, разработки и сопровождения. Кроме того, оценки показателя качества могут быть субъективными и отражать различные точки зрения и потребности разных специалистов. Чтобы эффективно управлять качеством на каждом этапе ЖЦ, необходимо уметь определять и примирять эти различные представления требуемого качества и его изменения.
При системном анализе и проектировании ПС необходимо определять и учитывать связи, влияние и взаимодействие следующих основных факторов, которые отражаются на их качестве (рис.3.1):
· назначение, содержание и описание функциональных и конструктивных характеристик, субхарактеристик и атрибутов, определяющих специфические особенности свойств и качества конкретного ПС;
· метрики, меры и шкалы, выбранные и пригодные для измерения и оценивания конкретных характеристик и атрибутов качества ПС;
· внешние и внутренние негативные факторы, влияющие на достигаемое качество ПС;
·
 |
доступные ресурсы, ограничивающие возможные величины реальных характеристик качества ПС.
Рис.3.1. Основные факторы, влияющие на качество ПС
Влияние перечисленных компонентов зависит от назначения ПС и требований к функциям. Множество характеристик качества ПС можно разделить на две принципиально различающиеся группы (рис.3.1):
· функциональные характеристики (функциональность) – определяющее назначение, свойства и задачи, решаемые комплексом программ для основных пользователей, отличающиеся очень широким спектром и разнообразием, состав и специфику которых трудно унифицировать и можно категоризировать только по большому количеству классов и свойств ПС;
· конструктивные характеристики качества, номенклатура которых может быть унифицирована, адаптирована и использована для описания внутренних и внешних стандартизуемых характеристик качества, поддерживающих реализацию основных функциональных требований к качеству объектов и процессов ЖЦ ПС.
Определение и сравнение функционального качества программ целесообразно рассматривать в пределах ограниченных классов ПС, выполняющих подобные функции. Такие классы функций могут выделяться в пределах проблемно–ориентированных сфер применения (административные, банковские, медицинские, машиностроительные и т.п.) и для решения более мелких специализированных функциональных задач в этих областях. Функциональные характеристики могут подвергаться значительным модификациям в течение всего ЖЦ ПС.
Функциональная пригодность (ISO 9126) непосредственно определяет основное назначение и функции ПС для пользователей. В контракте и ТЗ для каждого проекта функциональная пригодность должна быть выделена и формализована для однозначного понимания и оценивания всеми участниками ЖЦ ПС на каждом его этапе.
Конструктивные характеристики (рис.3.1) играют подчиненную роль и должны поддерживать и обеспечивать высокое качество реализации функций ПС и его применения по основному назначению. Их выбор и значения определяются требованиями к функциональной пригодности ПС.
3.2. Стандарты, регламентирующие характеристики качества
Основой формального регламентирования показателей качества ПС является стандарт «ISO 9126:1991 – Информационная технология. Оценка программного продукта. Характеристики качества и руководство по применению». Развитие этого стандарта проводится в направлении уточнения, детализации и расширения описаний, характеристик качества комплексов программ. Для замены редакции 1991 года завершается разработка и формализован проект стандарта, состоящего из четырех частей ISO 9126–1–4. Стандарт ISO 9126:1991 предполагается заменить на две взаимосвязанные серии стандартов: ISO 9126–1–4 (см. гл.4) и утвержденный стандарт ISO 14598–1–6:1998-2000 – Оценивание программного продукта (см. п.6.3).
Проект нового стандарта ISO 9126 состоит из следующих частей под общим заголовком – Технический отчет – Информационная технология – Качество программных средств:
· Часть 1: Модель качества;
· Часть 2: Внешние метрики качества;
· Часть 3: Внутренние метрики качества;
· Часть 4: Метрики качества в использовании.
 |
ISO 9126–1 определяет модель характеристик качества ПС (рис.3.2) и ее связи с ЖЦ комплексов программ. Требования пользователя к качеству в спецификациях должны в процессе верификации преобразовываться в требования к внешнему качеству, а затем в требования к внутреннему качеству. Процессы реализации требований к внутреннему качеству должны обеспечивать внешнее качество, а внешнее качество воплощаться в качество для пользователей.
Рис.3.2. Модель характеристик качества ПС
Модель внутренних и внешних характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками.
Функциональная пригодность детализируется:
· пригодностью для применения;
· корректностью (правильностью, точностью);
· способностью к взаимодействию;
· защищенностью.
Надежность характеризуется:
· уровнем завершенности (отсутствия ошибок);
· устойчивостью к дефектам;
· восстанавливаемостью;
· доступностью – готовностью.
Эффективность рекомендуется отражать:
· временной эффективностью;
· используемостью ресурсов.
Применимость (практичность) предлагается описывать:
· понятностью;
· простотой использования;
· изучаемостью;
· привлекательностью.
Сопровождаемость представляется:
· удобством для анализа;
· изменяемостью;
· стабильностью;
· тестируемостью.
Мобильность (переносимость) предлагается отражать:
· адаптируемостью;
· простотой установки – инсталляции;
· сосуществованием – соответствием;
· замещаемостью.
Дополнительно каждая характеристика сопровождается субхарактеристикой согласованность, которая должна отражать отсутствие противоречий со стандартами и нормативными документами, а также с другими показателями в данном стандарте.
Вторая и третья части стандарта ISO 9126–2,3 посвящены формализации соответственно внешних и внутренних характеристик качества сложных ПС. Показано, что внутреннее и внешнее качества относятся непосредственно к самому программному продукту, а метрики качества в использовании проявляются в эффекте от его применения и зависят от внешней среды. Между тремя типами метрик и характеристик качества существует взаимовлияние сверху вниз и зависимость снизу вверх.
Четвертая часть стандарта ISO 9126–4 – метрики качества в использовании – предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. Перечислены желательные свойства процессов измерения:
· надежность (повторяемость, восстанавливаемость);
· ресурсная эффективность;
· корректность;
· беспристрастность;
·
 |
выразительность результатов.
Предложена модель качества в использовании (рис.3.3).
Рис.3.3. Модель качества в использовании
Для оценивания качества в использовании рекомендуется применять четыре характеристики:
· эффективность;
· продуктивность;
· удовлетворение требований;
· защищенность.
3.3. Метрики характеристик качества программных средств
Общее представление о качестве ПС стандартом ISO 9126:1–4 рекомендуется отражать тремя взаимодействующими и взаимозависимыми метриками характеристик качества (рис.3.2). Качество ПС можно измерять внутренне – статическим анализом мер программного кода или внешне – измерением поведения программного кода при его исполнении. Эти типы метрик применимы при определении целей проекта и требований к качеству ПС, включая промежуточные компоненты и продукты. Подходящие внутренние атрибуты качества ПС являются предпосылкой достижения требуемого внешнего поведения, а приемлемое внешнее поведение – предпосылка достижения качества в использовании (табл.3.1).
Таблица 3.1
Модель процесса конкретизации метрик качества в ЖЦ ПС (ISO 9126)
| Этапы ЖЦ | Рекомендации модели качества | Основные результаты этапа |
| 1. Анализ требований к программам и системе | Разработка требования к качеству в использовании, к внешнему и внутреннему качеству | Требования к качеству в использовании, к внешнему и внутреннему качеству |
| 2. Архитектурное проектирование программ и системы | Проектирование качества в использовании и внешнего. Измерение внутреннего качества | Архитектурный проект ПС и системы |
| 3. Детальное проектирование ПС | Прогнозирование качества в использовании и внешнего. Измерение внутреннего качества | Детальный проект ПС |
| 4. Кодирование и тестирование ПС | Прогнозирование качества в использовании и внешнего. Измерение внутреннего качества | Тексты программных компонентов и результаты их тестирования |
| 5. Интеграция программ и их квалификационное тестирование | Прогнозирование качества в использовании. Измерения внешнего и внутреннего качества | Программный продукт и результаты его квалификационного тестирования |
| 6. Интеграция и квалификационное тестирование системы | Прогнозирование качества в использовании. Измерения внешнего и внутреннего качества | Интегрированные в систему программы и ее квалификационное тестирование |
| 7. Инсталляция ПС | Прогнозирование | Инсталлированная система |
| 8. Приемка программного продукта на обслуживание | Измерения качества в использовании, внешнего и внутреннего качества | Поставляемый программный продукт |