CC BY
59ТЕХНИЧЕСКИЕ НАУКИ
Процессы управления качеством программного обеспечения
Мейрманова Д. М.
Мейрманова Диана Махмутовна /Meirmanova Diana Makhmutovna - студент магистратуры,
специальность: информатика, Евразийский национальный университет им. Л. Н. Гумилева, г. Астана, Республика Казахстан
Аннотация: программное средство является неотъемлемой частью информационных технологий и традиционных систем, таких как транспортные, военные, здравоохранение и финансовые. При этом подразумевается усиление роли стандартов, процедур, методов, средств (инструментария) и внешних условий для разработки и сопровождения программных средств (программного обеспечения). В статье поэтапно описаны процессы оценивания качества программного обеспечения, а также дается определение стандартам качества. Ключевые слова: стандарт, поставщик, разработчик, аудитор, верификация, метрика, ранжирование.
Стандарт качества программной продукции не имеет противоречий с существующими в организациях стратегиями и процедурами. Однако любые возникающие конфликтные ситуации должны быть разрешены, а любые противоречащие условия и ситуации должны быть упомянуты в примечаниях как исключения при применении стандарта.
Прежде чем рассмотреть основы стандарта качества, необходимо определить что такое «качество» и почему оно должно быть столь глубоко представлено в виде самостоятельной области знаний на сегодняшний день. Качество программного обеспечения является постоянным объектом заботы программного обеспечения и обсуждается во многих областях знаний, что вполне обосновано, если учесть поистине катастрофический уровень проваленных проектов и неудовлетворенность пользователей программных продуктов. На протяжении многих лет отдельные авторы и целые организации определяли термин «качество» по-разному. Фил Кросби в 1979 году дал определение качеству как «соответствие пользовательским требованиям». Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP - People Software Process и Team Software Process, примечание автора) описывает качество как «достижение отличного уровня пригодности к использованию». Критерий Бэлдриджа (Baldrige National Quality Program, примечание автора) для организационного качества использует похожую фразу - «качество, задаваемое потребителем» («customer - driven quality»), рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ISO 9001 как «степень соответствия присущих характеристик требованиям».
На сегодня существует два важнейших стандарта в области качества программного обеспечения. TickIT - касается рассмотрения общей системы менеджмента качества ISO 9001 - 00 в приложении к программным проектам и представленный также в виде специальных рекомендаций ISO 90003 -04 "Software and Systems Engineering - Guidelines for the Application of ISO 9001:2000 to Computer Software". Другой важный стандарт - CMMI, обсуждаемый в области знаний «Процесс программной инженерии», предоставляет рекомендации по совершенствованию процесса, а также стандарт ISO 15504 "Information Technology - Software Process Assessment", известный как SPICE - Software
Process Improvement and Capability dEtermination, который также рассматривается в упомянутой области знаний.
Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения - CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и что сертификация по ISO 9001 помогает в достижении старших уровней зрелости по CMMI.
В первую очередь стандарт качества применяется для установления требований к качеству программного обеспечения и оценивания (измерения, ранжирования и оценки) программных продуктов, включая:
а) определение требований к качеству программной продукции;
б) оценивание технических требований к программному обеспечению при контроле за тем, чтобы требования качества были удовлетворены в процессе разработки;
в) описание признаков и свойств (атрибутов) внедренного программного обеспечения (например, в руководствах пользователя);
г) оценивание разработанного программного обеспечения перед его поставкой;
д) оценивание программного обеспечения перед приемкой.
Хотя отсутствует общепринятая система классификации программного обеспечения, имеется несколько общепринятых классов программного обеспечения. Важность каждой характеристики меняется в зависимости от класса программного обеспечения. Например, «надежность» наиболее важна для программного обеспечения «боевых» критичных систем, «эффективность» наиболее важна для программного обеспечения критичных по времени систем реального времени, а «практичность» наиболее важна для программного обеспечения диалога конечного пользователя.
Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения непосредственных участников проекта программного обеспечения.
1. Представление пользователя программного обеспечения.
Пользователей в основном интересует возможность применения программного обеспечения, его производительность и результаты использования. Пользователи оценивают программное обеспечение без изучения его внутренних аспектов или того, как программное обеспечение создавалось.
Пользователей могут интересовать следующие вопросы:
а) имеются ли требуемые функции в программном обеспечении;
б) насколько надежно программное обеспечение;
в) насколько эффективно программное обеспечение;
г) является ли программное обеспечение удобным для использования;
д) насколько просто переносится программное обеспечение в другую среду.
2. Представление разработчика.
Процесс создания требует от пользователя и разработчика использования одних и тех же характеристик качеств программного обеспечения, так как они применяются для установления требований и приемки. Когда разрабатывается программное обеспечение для продажи в требованиях качества должны быть отражены предполагаемые потребности.
Так как разработчики отвечают за создание программного обеспечения, которое должно удовлетворять требованиям качества, они заинтересованы в качестве промежуточной продукции так же, как и в качестве конечной продукции. Для того чтобы оценить качество промежуточной продукции на каждой фазе цикла разработки, разработчики должны использовать различные метрики для одних и тех же характеристик, потому что одни и те же метрики неприменимы для всех фаз жизненного цикла. Например, пользователь понимает эффективность в терминах времени реакции, тогда как разработчик в проектной спецификации термины длины
12
маршрута и времени ожидания и доступа. Метрики, применяемые для внешнего интерфейса продукции, заменимы метриками, применяемыми для ее структуры.
Предоставление пользователя должно также включать предоставление о характеристиках качества, требуемые тем, кто сопровождает программное обеспечение.
3. Предоставление руководителя.
Руководитель может быть более заинтересован в общем качестве, чем в конкретной характеристике качества, и по этой причине будет нуждаться в определении важности значений, отражающих коммерческие требования для индивидуальных характеристик.
Руководителю может также потребоваться сопоставление повышения качества с критериями управляемости, такими как плановая задержка или перерасход стоимости, потому что он желает оптимизировать качество в пределах ограничений стоимости, трудовых ресурсов и установленного времени [1, с. 30-40].
На сегодняшний день существует единый модель процесса оценивания, которая отражает основные этапы, требуемые для оценивания качества программного обеспечения начиная с характеристик качества, определенных в действующих стандартах оценки качества.
Процесс состоит из трех стадий: установление (определение) требований к качеству, подготовка к оцениванию и процедура оценивания. Данный процесс может применяться в любой подходящей фазе жизненного цикла для каждого компонента программной продукции.
1. Установление требований к качеству
Целью начальной стадии является установление требований в терминах характеристик качества и возможных комплексных показателей. Требования выражают потребности внешнего окружения для рассматриваемой программной продукции и должны быть определены до начала разработки. Так как программная продукция разделяется на основные компоненты, требования для продукции могут отличаться от требований для отдельных компонентов.
2. Подготовка к оцениванию.
Целью второй стадии является подготовка основы для оценивания.
2.1 Выбор метрик (показателей) качества
Способ, которым определялись характеристики качества, не допускает их непосредственного измерения. Существует потребность в установлении метрик, которые соотносятся с характеристиками программной продукции. Каждый количественный признак и каждое количественно оцениваемое взаимодействие программного обеспечения с его окружением, которые соотносятся с характеристикой, могут быть приняты в качестве метрики. Метрики могут по-разному зависеть от окружения и фаз процесса разработки, в которых они используются. Метрики, используемые в процессе разработки, должны быть соотнесены с соответствующими метриками пользователя, потому что метрики из представления пользователя являются решающими.
2.2 Определение уровней ранжирования.
Количественные признаки могут быть измерены, используя метрики качества. Результат, т.е. измеренное значение, отображается в масштабе. Данное значение не показывает уровень удовлетворения требований. Для этой цели данные шкалы должны быть разделены на диапазоны, соответствующие различным степеням удовлетворения требований. Общие уровни ранжирования невозможны, так как качество относится к конкретным потребностям. Они должны определяться для каждого конкретного оценивания.
2.3 Определение критерия оценки.
Для определения качества продукции результаты оценивания различных характеристик должны быть подытожены. Аудитор должен подготовить для этого процедуры, используя, например, таблицы решений или средние взвешенные
13
характеристики. Процедура обычно включает другие аспекты, такие как время и стоимость, которые способствуют оценке качества программной продукции в конкретных условиях эксплуатации.
3. Процедура оценивания.
Последняя стадия модели процесса оценивания, уточняется по трем этапам, называемым «измерение», «ранжирование», «оценка».
3.1 Измерение.
Для измерения выбранные метрики применяются к программной продукции. Результатом являются значения масштаба метрик.
3.2 Ранжирование
На этапе ранжирования устанавливается уровень ранжирования для измеренного значения [2, а 228].
На сегодняшний день существует несколько общепринятых метрик для характеристик к программному обеспечению. Организации и группы по стандартизации устанавливают свои собственные модели процесса оценивания и методы формирования и проверки метрик, связанных с этими характеристиками, для охвата различных областей применения и стадий жизненного цикла. В тех случаях, когда соответствующие метрики отсутствуют и не могут быть разработаны, иногда пользуются словесными описаниями или вспомогательными методами. Подобная неопределенность подходов создает значительные трудности при оценке программных продуктов. Требуется определенное упорядочение вопросов оценки программных продуктов при переходе от такой многоплановости к общей структуре, которая может быть использована профессионалами для «разговора на одном языке» при оценке и управлении программными средствами.
В ряде стандартов и публикации большое внимание уделяется процессам обеспечения качества продукции, технологий и услуг, в частности, в жизненном цикле сложных программных средств. Однако во многих случаях умалчивается, что означает высокое качество, какими характеристиками оно описывается, как его следует измерять и сравнивать с требованиями, формализованными в контракте, техническом задании или спецификациях. Кроме того, некоторые из характеристик частично отсутствуют в согласованных документах, что приводит к разному их учету или к пропуску при испытаниях. Отсутствие четкого представления и описания в документах понятий и значений характеристик качества программных средств приводит к конфликтам между заказчиками - пользователями и разработчиками -поставщиками из-за разной трактовки одних и тех же характеристик.
Неопределенности и пробелы в формализации характеристик качества комплексов программ оставляют широкое поле для произвола при оценивании их качества и к проявлению дефектов и ошибок при применении программных средств пользователями. Возрастание сложности и ответственности задач, решаемых программами, а также возможного ущерба от недостаточного качества их результатов, значительно повысило актуальность проблемы точного описания требований к характеристикам качества и их измерения на различных этапах жизненного цикла программных средств.
Разработчикам, поставщикам, заказчикам и пользователям необходимо усвоить, что тщательное и корректное определение, выбор номенклатуры и оценивание стандартизированных характеристик качества программных средств, существенно, а иногда критически, влияет на последующее качество функционирования информационных систем. Типовой набор характеристик, субхарактеристик и атрибутов качества комплексов программ, представленных в базовых стандартах, следует использовать как исходные данные и шаблоны при подготовке технических заданий и спецификаций требований к качеству программных средств. Корректировка состава и значений параметров позволяет уточнять и адаптировать этот набор характеристик программных средств для конкретных проектов и потребителей и
14
сокращать дефекты вследствие неоднозначности и некорректности описания требований к качеству. Методы стандартизированного оценивания и измерения различных характеристик качества следует использовать при подготовке конкретных методик испытаний качества проектов программных средств. Целеустремленный выбор и оценивание стандартизированных характеристик следует применять как основу для сравнения качества программных средств разных поставщиков и выявления среди них предпочтительных [3, с. 240].
Модель внутренних и внешних характеристик качества программных средств состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:
Функциональная пригодность детализируется:
- пригодностью для применения;
- корректностью (правильность, точность);
- способностью к взаимодействию;
- защищенностью.
Надежность рекомендуется характеризовать:
- уровнем завершенности (отсутствия ошибок);
- устойчивостью к дефектам;
- восстанавливаемостью;
- доступностью - готовностью.
Эффективность рекомендуется отражать:
- временной эффективностью;
- пользованием ресурсов.
Применимость (практичность) предлагается описывать:
- понятностью;
- простотой пользования;
- изучаемостью;
- привлекательностью.
Сопровождаемость предлагается представлять:
- удобством для анализа;
- изменяемостью;
- стабильностью;
- тестируемостью.
Переносимость (мобильность) предлагается отражать:
- адаптируемостью;
- простотой установки - инсталляции;
- сосуществованием - соответствием;
- замещаемостью.
Стандарты позволят разработчикам и заказчикам программного средства более корректно взаимодействовать при определении и реализации требований контракта, технического задания и спецификаций. Применение стандартов при разработке программ поддерживает и конкретизирует технологический процесс возможностью отслеживания значений качества компонентов программных средств на промежуточных этапах жизненного цикла. При испытаниях и сертификации программных продуктов появилась основа для выбора и формализации номенклатуры и значений характеристик качества, однозначно отражающих степень удовлетворения исходных требований заказчика и пользователей. Тем самым, обеспечена возможность, объективно определять и сравнивать качество программного средства различных поставщиков.
Литература
1. Липаев В. В. Обеспечение качества программных средств. Методы и стандарты. М.:СИНТЕГ, 2001. С. 30-40.
2. Липаев В. В. Выбор и оценивание характеристик качества программных средств. Методы и стандарты. М.:СИНТЕГ, 2001. 228 с.
3. Черников Б. В., Поклонов Б. Е. Управление качеством программного обеспечения. Практикум. М.:ИД «Форум», 2012. 240 с.
Практическая реализация активного полосового фильтра второго порядка. Схема Саллена-Ки Грошков П. В.
Грошков Павел Викторович / Groshkov Pavel Viktorovich - студент, кафедра системы автоматического управления и контроля, факультет интеллектуальных технических систем, Национальный исследовательский университет Московский государственный институт электронной техники, г. Зеленоград
Аннотация: в данной статье я расскажу про одну из наиболее часто встречающихся реализаций активного полосового фильтра, а именно схемы Саллена-Ки. Ключевые слова: фильтр, частотный фильтр, пассивный и активный фильтры, операционный усилитель, частота среза, амплитудно-частотная характеристика.
Частотные фильтры - устройства, позволяющие выделить из смеси сигналов, занимающих в совокупности широкую полосу частот, те или иные узкополосные составляющие или их определенные комбинации, другими словами - эти устройства позволяют нам при необходимости пропускать или задерживать сигналы с определенной частотой, что широко применяется в электрических, телекоммуникационных, радиотехнических и телеметрических системах, а также устройствах, работающих на принципе частотного разделения сигналов [1, с. 33].
До второй половины XX века для реализации всевозможных фильтров в основном использовались пассивные элементы: катушки, конденсаторы, резисторы, отсюда и возникло их название «пассивные фильтры». Но у этих фильтров имелся один очень большой недостаток, для реализации пассивных ФНЧ уж слишком сильно выделялся размер катушек индуктивности, они получались очень большими, что часто сказывалось на области применения фильтра. Но с развитием технологий, а именно интегральных схем, в фильтрах стали широко использоваться операционные усилители, они и стали заменой уже надоевшим и замучившим изобретателей катушкам индуктивности. Вследствие этих изменений появился и новый вид фильтров - активные.
Активные фильтры строились из тех же сопротивлений, конденсаторов, а вместо катушек теперь устанавливали ОУ. Активные фильтры почти полностью вытеснили пассивные из области применения, в основном же пассивные фильтры стали использовать на высоких частотах работы свыше 1МГц.
Основной сферой применения активных фильтров стали: звуковая аппаратура, генераторы электромузыкальных инструментов, линии связи, сейсмические приборы, а также всевозможные вибрации, иными словами активные фильтры легко найдут себе место почти в любой области электротехники и электроники и в данной статье мы подробно рассмотрим одно из таких устройств.
Рассмотрим на примере фильтра простейшую цепь RC.
