Надежность АСОИУ (1088455), страница 51
Текст из файла (страница 51)
Цена контролясостоит из затрат на измерение, оценивание или ревизию программногопродукта для обеспечения соответствия между требованиями, стандартамикачества и результатом. При разработке ПО, например, затраты оценки включают затраты на инспекцию программ, тестирование и измерение программныхпоказателей.Несогласованная цена качества включает все издержки, понесенныевследствие выявления недостатков, возникновения ошибок и выхода из строяпрограммногоизделия.Различаютвнутренниеивнешниеиздержки.Внутренние издержки связаны с проблемами, выявленными до того, какпрограммный продукт отправлен заказчику.
При разработке ПО сюда входятзатраты на переработку программ, повторную инспекцию и тестирование.Затраты, связанные с ошибками, проявившимися при эксплуатации продукта узаказчика, относятся к внешним издержкам. Для программного обеспеченияэто, например, затраты на сопровождение и поддержку, убытки от простоев инекорректного функционирования программного изделия.Статистические исследования влияния процессов разработки на качестворезультирующегопродуктапоказали,чтосовершенствованиепроцессаразработки и внедрения программного обеспечения значительно уменьшаютотносительную (в пересчете на единицу объема программного продукта ввыбранной метрике) несогласованную стоимость качества при сохранениисогласованной стоимости качества на прежнем уровне.Качество программного кода системы. Как правило, единственным доступныммеханизмом определения «ожиданий заказчика» являются требования. В ТЗустанавливаются функции программного обеспечения и нефункциональныетребования — производительность, надежность и т.
п. Нетехническиетребования, такие как цена, сроки поставки, утверждаются в контрактныхдокументах.Качество процесса разработки. Исследования показывают: чем вышекачество процесса разработки, тем выше качество созданного в результатепрограммного обеспечения. Считается, что качество на каждой стадии проектавозрастает, во-первых, как прямое следствие зрелости процесса, во-вторых, всвязи с использованием промежуточного продукта более высокого качества,произведенного на предшествующей стадии.Наиболее широко известным и используемым стандартом для организациипроцессов контроля качества является серия стандартов, начиная с ISO 9000.Эти стандарты были ориентированы на разработку промышленных изделий.Специально для обеспечения процессов разработки программных системорганизацией ISO предложено руководство ISO 9000-3, которое формулируеттребования модели качества ISO 9001 к организации процесса разработкипрограммного обеспечения.
Недостатком этого стандарта является трудностьизмерения уровня качества процесса разработки программного обеспечения всоответствии с предложенной моделью качества.Видимо, поэтому среди разработчиков программного обеспечения,особенно за рубежом (в первую очередь в США), большой популярностьюпользуется альтернативная модель качества CMM-SEI. В настоящее время онаносит название CMMI.Особенностью модели CMMI является иерархическая вложенностьмоделей качества, которая позволяет измерять и сравнивать уровни качествапроцессоввразличныхорганизацияхиобеспечиватьэффективноесовершенствование качества процессов.Качество программных компонентов. При проектировании современныхпрограммныхсистемиспользуютпринципыкомпонентнойразработки(Component Base System — CBS).
Считается, что технология построения CBSпозволяет значительно снизить стоимость и время разработки. В то же времявозрастаетриск,связанныйсприменениемвсистемепрограммныхкомпонентов, разработанных различными производителями.Одним из способов решения данной проблемы является использованиеметрик для управления качеством и рисками при построении CBS с цельюизмерения различных факторов, влияющих на конечное качество программногопродукта и устранение источников риска. Метрики качества при этом служатосновой для принятия решений на различных этапах жизненного циклапрограммнойразработки,касающихсяэкономическойцелесообразностииспользования подобных компонентов.Качество технического проекта. Измерение качества проектирования являетсяважной составляющей частью в процессе обеспечения качества программногопродукта.
Особую важность это приобретает при объектно-ориентированномпроектировании программных систем. Объектно-ориентированная разработкапрограммвводитновыефакторыкачества,связанныесповторнымиспользованием наработок и выполнением модификаций.Повторное использование и модификация возможны на несколькихуровнях: уровне исходного кода, физического дизайна, логического дизайна,технических требований и т. д. Причем повторное использование имодификациямогутпроизводитьсяврамкахсистемы,проекта,разрабатывающей компании и т. д.Поэтому в дополнение к классическим метрикам оказывается целесообразным включение в число наиболее важных таких метрик качестваобъектно-ориентированного проектирования (ООП), как:сложностьООП—фактор,отражающийтрудностьпонимания,реализации и модификации классов и объектов;возможность повторного использования в ООП — фактор, отражающийстепень применимости проектных решений в различных контекстах.Приведем примеры других возможных метрик:• метрики управления (время и среда разработки, использованиесистемных ресурсов);• метрики требований дают возможность контролировать спецификации,изменение требований, а также степень их удовлетворения;• метрики качества кода программного модуля (адаптируемость, сложность интерфейсов и интеграции, тестовое покрытие, надежность, профилиошибок, степень удовлетворения потребностей заказчика);• гибкость (модульность, изменяемость, сопровождаемость);• адаптивность(настраиваемость,переносимость,способностьквзаимодействию) и др.В ходе приемосдаточных испытаний проверяется качество программногообеспечения,связанноесфункциональностью,надежностьюипроизводительностью, в соответствии с документами, которые были принятына начальных этапах проекта.
При этом опыт внедрения и использованиякрупных программных систем показывает, что стоимость эксплуатации исопровождения в составе общей стоимости системы (Total Cost Ownership —TCO) увеличивается с возрастанием сложности системы опережающимитемпами. В связи с этим повышается роль учета метрик, характеризующихпоказатели качества программного обеспечения. Ключевым для управлениякачеством является выбор метрик качества (втом числе и метрик для CBS),применимых на всех этапах жизненного цикла и оценивающих как качествопроцесса, так и качество продукта.Опыт ведущих разработчиков программного обеспечения показывает, чтофинансовые затраты, произведенные для улучшения качества программнойпродукции, являются целесообразными и дают в итоге определенныйэкономическийэффект.Причина,покотороймногиеорганизациивоздерживаются от таких расходов, состоит, прежде всего, в трудностях,связанных с планированием и оценкой результатов повышения качества.Нередкорешениеоповышениикачествареализуетсянеформальных, интуитивных способов оценки качества.спомощьюИзвестный подход к анализу качества ПО в соответствии с целямиразработки и на основе специфических для данного проекта методов создаетпредпосылки для корректного планирования и контроля затрат, для достижениятребуемых показателей и эффективности использования ресурсов.Вместе с тем детальная разработка системы качества требует времени исредств.
Поэтому она используется при создании и внедрении программныхсистемсвысокойстоимостьюразработки,впервуюочередьприпроектировании программных комплексов систем реального времени (системыуправления динамическими объектами, так называемый рабочий поток и т. д.).3.2. Тестирование программного обеспеченияПри создании программного продукта выделяют процессы, связанные стестированием, отладкой, доказательствами, контролем, испытаниями идругими действиями с программным изделием. Назначение и содержательнаясторонакаждогоизтакихпроцессовразработчикамиПОчастовоспринимаются по-разному.
Поэтому введем понятия и термины, которыебудут использоваться в этом и последующих параграфах.Под тестированием (testing) понимается процесс выполнения программы(или части программы) с намерением (или целью) найти ошибки. Нередкотестирование рассматривается как измерение качества программного продукта.При этом под качеством понимается степень, с которой совокупностьхарактеристикпрограммногопродуктаотвечаеттребованиямкнему.Различают требования функциональные и нефункциональные.
Функциональноетребование — это свойство, которое система должна иметь, или требование,которому система должна удовлетворять.Тестирование модуля или автономное тестирование (module testing unit testing) —это контроль отдельного программного модуля, обычно в изолированной среде(т. е.
изолированно от всех остальных модулей). Тестирование модуля иногдавключает также математическое доказательство. Тестирование сопряжений(integration testing) предусматривает контроль сопряжений между частямипрограммной системы (модулями, компонентами, подсистемами).Тестирование внешних функций (external function testing) подразумеваетконтроль поведения системы, определенного внешними спецификациями.Комплексное тестирование (system testing) включает контроль и (или)испытание системы по отношению к исходным целям. Комплексноетестирование является процессом контроля, если оно выполняется вмоделируемой среде, и процессом испытания, если выполняется в реальныхусловиях функционирования программной системы.Тестирование приемлемости (acceptance testing) проводится в целяхпроверки соответствия программы требованиям пользователя.Тестирование настройки (installation testing) заключается в проверкекаждого конкретного варианта установки программной системы с цельювыявления ошибок, возникших в процессе настройки системы.Отношения между этими типами тестов и проектной документацией, накоторой основывается тест, показаны на рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
