И. Соммервилл - Инженерия программного обеспечения (1133538), страница 132
Текст из файла (страница 132)
В табл. 24.4 представлены некоторые типы проверок. Инспектирование программ об. суждается в главе 19, Промежуточные проверки являются часгью процесса управления проектом, который описан в главе 4. В этой главе проверки рассматриваются как часть 24. Управление качествам БОБ процесса управления качеством. В процессах различных проверок есть много общего, а описание организации такой проверки приведено в главе 19. Таблица 24.4.
Типы проверок Тип проверки Основная цель проверки Инспекция структуры и про- граммного кода системы Выявить ошибки в требованиях, структуре и программном коде. Проверка проводится в соответствии с технологиче. ской картой возможных ошибок Предоставить руководству отчеты о ходе выполнения проекта. Это может быть проверка и процесса разработки, н создаваемого продукта, а также выполнения бюджета и графика проекта Провести технический анализ компонентов продукта и документации с тем, чтобы найти несоответствия между спецификацией и структурой системы, программным ко- дом и документацией, а также гарантировать выполнение определенных стандартов качества Промежуточные проверки Проверки качества Целью команды проверки качества является обнаружение ошибок и противоречий с тем, чтобы довести их до сведения разработчйка или автора документации.
Все проверки основаны на документации, однако они не ограничены только спецификацией, структурой системы или программным кодом. Проверке подвергаются н такие документы, как модель процесса разработки, планы тестирования, процедура управления конфигурацией, стандарты процесса рз.зработки и руководство пользователя. В команду проверки качества должны быть включены те специалисты, которые моП г принести наиболыпую пользу. Например, при проверке структуры подсистем в такую команду должны входить программисты, которые участвовали в разработке подобных подсистем. Благодаря таким специалистам может появиться, например, новый взгляд на интерфейсы подсистем, Ядром команды по проверке качества должно быть не более 3-4 человек, отобранных в качестве основных проверяющих.
Один из иих должен быть старшим, т.е. ответственным за принятие технический решений. Основные проверяющие могут приглашать других разработчиков проекта для участия в проверке. Им не обязательно принимать участие во всей проверке. Достаточно, чтобы оии проверяли тс части проекта, которые мокнут непосредственно повлиять на нх работу. Кроме того, команда проверки качества может раздать тестируемый документ, чтобы получить письменные комментарии от других членов проекта.
Документы должны быть розданы до начала проверки с тем, чтобы рецензенты могли озпакомитьсл с ними и понять их суть. Хотя такие задержки и затягивают иногда процесс разработки, но проверка не будет иметь смысла, егли команда не разберется в документа. ции перед проведением проверки. Сама проверка должна быть достаточно короткой (не более двух часов). Автор анализируемого документа должен "пройтись" по документу вместе с командой проверки.
Один из членов команды должен руководить процессом проверки, а другой — записывать все ее результаты. Во время проведения проверки возглавляющий ее специалист ответственен за то, чтобы были рассмотрены все письменныс замечания. По окончании проверки все действия проверяющих должны быть занесены в отчет, который подписывается проверяемым н лицом, возглавляющим проверку, В дальнейшем зтн отчеты составят официальную документацию по проекту. Если были обнаружены лишь незначительные недос- Ьбб з4асть 'Л. Управление татки, проводить следующую проверку нет необходимости. Возглавляющий проверку специалист также несет ответственность за выполнение необходимых изменений в проекте. При необходимости внесения больших изменений нужно провести еще одну проверку. 24.4.
Измерение показателей ПО Измерения в области программного обеспечения — это получение числовых значений определенных показателей программного продукта или процесса его разработки. Значения этих показателей сравнивают между собой и со стандартами, применяемыми в данной организации. Па основе этих сравнений можно сделать выводы о качестве продукта или процесса разработки. Например, органиэация планирует ввести новое программное средство для тестирования ПО. Перед тем как это средство будет введено в стандарт, нужно определить количество дефектов программной системы, обнаруженных эа определенный период времени др>тими средствами тестирования.
Затеи следует повторить процесс тестирования новым средством. Если при этом будет обнаружено большее количество ошибок за то же время, значит, это средство окажется действительно полезным для проведения проверки правильности программного кода. 1'яд крупных компаний, таких. как Незя!егг-Рас[гагб [135] и АТ8гТ [22], ввели свои системы измерения показателей ПО и используют нх в процессе управления качеством. Основнос внимание в этих системах уделяется определению показателей, указывающих на присутствие дефектов в ПО, а также показателям, нспольз1'емым в процессе проверки и аттестации программных продуктов. В работах [262, 1эО] рассмотрен вопрос введения таких систем в промышленное производство.
В руководстве компании АМ1 [285] дается подробное описание такой системы измерений и ее применения для усовершенствования процесса разработки ПО. Вместе с тем системы измерения показателей ПО пока не получилн широкого распространения. Основной причиной является отсутствие очевидной пользы от этих снстем— во многих организациях-разработчиках процесс создания программных продуктов все еще организован нс лучшим образом и недостаточно развит для ведения подобных систем измерений. Кроме того, нет четких стандартов показателей ПО, отсюда ограниченный уровень технической поддержки по сбору и анализу подобных данных.
Большинство компаний ие готовы к ввслению систем измерений показателей ПО, поскольку нс разработаны соответствующие стандарты и отсутствуют средства их поддержки. Показатели программного обеспечения — это количественные показатели, которые можно измерить и которые характеризуют программную систему, процесс разработки ПО или сопровождающую документацию. Например, это может быть размер программного пролукта, равный количеству строк кода, индекс непонятности [142], который является мерой читабельности письменного текста, количество зарегистрированных ошибок в программном продулте, а также количество человеко.
дней, требуюппгхся для создания системных компонентов. Показатели делятся на два вида: контрольные и прогнозируемые. Контрольныс показатели обычно соотносятся с процессом разработки ПО, а прогнозируемые — с готовым программным продуктом. Примером контрольного показателя (показателя процесса) может быть срсдпсс значение затрат и времени, расходуемых на исправление зарегистриро. ванных неполадок. В качестве примера прогнозируемого показателя можно привести 24. Управление качеством 502 цикломатическую сложность программных модулейэ, среднюю длину идентификаторов в программе, а также количество атрибутов и операторов, относящихся к объектами сис. темной структуры. На решения по управлению проектом могут оказать влилние как контрольные, так и прогнозируемые показатели (рис.
24.5). Подробнее показатели процесса создания ПО и их роль в совершенствовании этого процесса рассматриваются в главе 25. Здесь же внимание сосредоточено на показателях, прогнозирующих качество программного продукта. Рис 24 5. Конпгралыгьг и прогнозируем ые покпгптел и Часто невозможно провести прямое оцениваннс таких показателей качества программного продукта, как удобство сопровождения, сложность или понятность, поскольку онн слагаются из самых разных факторов.
Поэтому для их оценивании не существует прямой системы показателей. Отсюда следует вывод, что для начала необходимо измерить какой-либо внутренний показатель ПО (например, размер программы), а затем предположить, что существует взаимосвязь между тем, что мы можем изчсритгн и тем, что мы в действительности хотели бы узнать.
В идеале между внугрепними и внешними характеристиками программно. го продукта должна быть четкая прямая взаимосвязь, поддающаяся проверке. На рис. 24.6 показаны внешние показатели качества, которые нас заинтересуют, и вп)тренние показатели ПО, которые можно измерить н соотнести с внешними свойства. ми. Между внешними и внутренними показателями ПО предполагается определеннал взаимосвязгн однако неизвестно, какого вида эта взаииосвязь. Если необходимо определить внешние характеристики ПО путем измерения внутренних показателей, следует соблюсти три обязательных условия [198). 1. Точи ое и аккуратное проведение измерения внутренних показателей.
2. Наличие взаимосвязи между измеренными показателяин и внешними поведенче- скими характерисгикамн ПО. 3. Обязательное изучение этой взаимосвязи, ее проверка и выражение в виде форму- лы илн модели. Цнклпнппгнчгаспл слокгность ггрограммного мадуьт лпрактернгугтгсл внклачапосческнм чнстн графа, опгодрпмпнпэего структуугу много моду.т (когдп кпмдон точке еппаынгсл гугогргснны соогне пнлеоупп и/анана графа). Определенгге и фо)тулп гычпслгннл Энктмптнчешом числа прнесдгны е глпее 2у. — Прим рсж 508 траста У1. Управление Формулировка модели предусматривает определение вида функциональной зависимости между внешними и внутренними показателями (линейный, экспонеициальный или другой вид зависимости), что осуществляется путем анализа собранных данных, определения параметров, которые должны быть включены в модель, а также калибровки сущест. вующнх данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
