Разработка методики количественной оценки "анализируемости" программных продуктов

• Автор: Стружков, Сергей Александрович
• Шифр специальности: 05.13.17
• Научная степень: Кандидатская
• Год защиты: 2009
• Место защиты: Москва
• Количество страниц: 166 с.

Введение.

Глава 1. Анализ проблемы оценки качества программного обеспечения

Основные понятия и определения предметной области

Состояние проблемы.

Определение понятия качества.

Международные стандарты оценки качества ПС

Характеристики качества ПС

Метрики характеристик качества ПС.

Цена качества.

Постановка задачи диссертационного исследования.

Выводы по главе 1.

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


Процесс создания требует от пользователя и разработчика использования одних и тех же характеристик качества программного обеспечения, так как они применяются для установления требований и приемки. Когда разрабатывается программное обеспечение для продажи, в требованиях качества должны быть отражены предполагаемые потребности. Так как разработчики отвечают за создание программного обеспечения, которое должно удовлетворять требованиям качества, они заинтересованы в качестве промежуточной продукции так же, как и в качестве конечной продукции. Для того чтобы оценить качество промежуточной продукции на каждой фазе цикла разработки, разработчики должны использовать различные метрики для одних и тех же характеристик, потому что одни и те же метрики неприменимы для всех фаз жизненного цикла. Например, пользователь понимает эффективность в терминах времени реакции, тогда как разработчик использует в проектной спецификации термины длины маршрута и времени ожидания и доступа. Метрики, применяемые для внешнего интерфейса продукции, заменимы метриками, применяемыми для ее структуры. Руководитель может быть более заинтересован в общем качестве, чем в конкретной характеристике качества, и по этой причине будет нуждаться в определении важности значений, отражающих коммерческие требования для индивидуальных характеристик. Руководителю может также потребоваться сопоставление повышения, качества с критериями управляемости, такими как плановая задержка или перерасход стоимости, потому что он желает оптимизировать качество в пределах ограниченной стоимости, трудовых ресурсов и установленного времени. Как видно качество не абсолютная характеристика. Следовательно, невозможно установить один унифицированный показатель качества. Качество изменяется в течение ЖЦ ПС, т. ЖЦ почти всегда отличается от фактически достигнутого при завершении проекта и качества поставляемого продукта. Кроме того, оценки показателей качества могут быть субъективными и отражать различные точки зрения специалистов. Выделяют также такое понятие как многомерность качества. Общее качество ПС включает в себя на верхнем уровне ряд составляющих, которые должны быть приняты во внимание при управлении качеством. Качество инфраструктуры (infrastructure quality): качество аппаратного и поддерживающего программного обеспечения (например, качество операционных систем, компьютерных сетей и т. Качество программного обеспечения (software quality): качество программного обеспечения информационной системы. Качество данных (data quality): качество данных, использующихся информационной системой на входе. Качество информации (information quality): качество информации, продуцируемое информационной системой. Качество сервиса (service quality) - качество обучения, системной поддержки и т. Кроме перечисленных составляющих качества должно быть принято во внимание качество обслуживаемого бизнес процесса. Анализ всех составляющих качества должен проводиться с учетом сфер ответственности заинтересованных сторон, как внутренних участников исполняемого процесса (in-process stakeholder), так и пользователей процесса (end-of-process stakeholders). Управление качеством будет успешным, если под контролем находятся все измерения качества. Известно, что чем выше качество процесса разработки, тем выше качество разработанного в этом процессе качества программного обеспечения. Качество на каждой стадии проекта возрастает, во-первых, как прямое следствие зрелости процесса, во-вторых, вследствие использования промежуточного продукта более высокого качества, произведенного на предыдущей стадии. При этом подчеркивается, что значение второй причины обеспечивающей нарастание качества в процессе жизненного цикла для зрелых процессов оказывается гораздо более важным. Это подтверждается всей практикой программирования, например, известно, что недостатки проектирования систем не могут быть компенсированы высоким качеством кодирования. Извлечение данных о качестве, которое было заложено на ранних стадиях, может быть очень дорогим, при отсутствии полных результатов промежуточного продукта на предыдущих стадиях, например, при отсутствии логического дизайна системы, требований к продукту и т.