CC BY
46
шихся дефектов на 1000 строк исходного кода). Иногда требования по качеству достигают 6 Сигма (0.00339 оставшихся дефектов на 1000 строк исходного кода). Для обеспечения заданного уровня качества рекомендуется применять технику независимого системного тестирования программных изделий [7].
Тестирование рекомендуется выполнять группой независимого системного тестирования на основании формальных требований к системному загрузчику и плана системного тестирования. Применение техники системного тестирования к коду системного загрузчика позволяет обеспечить достижение запланированного уровня качества программного изделия. Таким образом, отпадает необходимость затраты дополнительных средств и усилий на этапе промышленной эксплуатации программно-аппаратного комплекса для устранения сбоев, связанных с дефектами в коде системного загрузчика.
Данная статья может быть использована для получения общего представления о круге задач и проблемах, стоящих при разработке загрузчиков
ПО встроенных систем управления. В статье рассмотрены основные функции системных загрузчиков и кратко освещен вопрос организации процесса разработки и тестирования кода системного загрузчика. Наиболее трудоемким и интересным является вопрос совместной отладки системного загрузчика и целевой аппаратной платформы, но это - тема отдельной статьи.
Список литературы
1. Get by Without an RTOS, Michael Melkonian, Embedded Systems Programming Magazine, vol. 13 no. 10 September, 2000.
2. Никифоров В.В., Домарацкий Я.А.. Построение тестов для базовых функций встраиваемых операционных систем, // Программные продукты и системы. - 1998. - № 4.
3. If the RedBoot Fits, Anthony J. Massa, Embedded Systems Programming Magazine, vol. 15 no. 8, August 2002.
4. Booting Linux: The History and the Future, Werner Al-mesberger, June 25, 2000.
5. MPC7450 RISC Microprocessor Family User's Manual, MPC7450UM/D 2/2003 Rev. 3.
6. DINK32 PowerPC Debugger User's Manual, DINK_UM/D 4/2003 Rev.13.1.
7. Никифоров В.В., Домарацкий Я.А.. Системное тестирование программных изделий. // Программные продукты и системы. - 1998. - № 4.
ЗАДАЧИ УЛУЧШЕНИЯ КАЧЕСТВА ПРОГРАММНЫХ ПРОДУКТОВ
О.Ю. Берг, С.В. Максюта, В.С. Пилидии
Индустрия программных продуктов (ПП) является одной из наиболее интенсивно развивающихся и прибыльных. В России же рынок собственных ПП практически отсутствует. Единичные образцы ПП, пользующихся спросом пользователей, лишены рыночной конкуренции как фактора самосовершенствования. Доля ПП России в объеме мирового рынка составляет менее 1 %.
При этом программная индустрия является одним из основных компонентов национальных информационных инфраструктур, без которых в современных условиях немыслимо ни социальное, ни экономическое, ни научное, ни оборонное развитие страны. Таким образом, возникает необходимость освоения современных методов и средств программной инженерии, особенно инженерии качества ПП, обобщаемых в международных и национальных стандартах.
В условиях рыночной экономики успешная деятельность любой организации возможна в том случае, если производимые ею продукция или услуги конкурентоспособны, соответствуют потребительскому спросу, действующим нормативным документам. Иными словами, продукция и услуги
должны быть высококачественными. При этом возникают вопросы: Как оценить качество ПП? чем его измерить? В данной работе рассмотрены основные задачи, решение которых позволяет улучшить качество выпускаемых ПП.
Одним из основных условий повышения качества ПП является совершенствование процесса их создания. За последние десять лет разработано множество концепций совершенствования указанных процессов. В качестве примеров можно привести концепцию «Улучшение процессов создания ПО» (Software Process Improvement, SPI) американского Software Engineering Institute (SEI), которая опирается на статистические методы контроля технологических процессов [1], «Сквозной контроль качества» (Total Quality Management, TQM) [2], «Реинжиниринг деловых процессов» (Business Process Reengineering, BPR) [3], «Постепенное совершенствование деловых процессов» (Business Process Improvement, BPI) [4].
В основе всех этих концепций лежит понимание жизненного цикла ПП как совокупности фаз, которые проходит ПП в процессе своего развития [5]:
- выработка исходных требований к ПП со стороны пользователя;
- формулирование общих требований к ПП со стороны разработчика;
- проектирование архитектуры;
- детальная реализация ПП;
- инсталляция ПП в организации заказчика;
- эксплуатация.
Для поддержания жизненного цикла ПП фирмы-разработчики организуют свою деятельность по нескольким ключевым направлениям:
• управление проектом (планирование, распределение ресурсов, контроль исполнения и сроков);
• тестирование (проверка соответствия качества готового продукта исходным требованиям и проверка функционирования);
• конфигурационный менеджмент (поддержка версий, редакций, вариантов ПП на уровне исходного кода, дистрибутивов, документации);
• сопровождение (установка продукта, обучение пользователей, устранение ошибок, развитие функциональных возможностей, поставка upgrade-версий, техническая поддержка).
Для определения общего уровня развития технологических процессов в организациях, специализирующихся на выпуске ПП, разработана специальная система оценки зрелости этих процессов - Capability Maturity Model (CMM) [6]. Предложенная модель основана на так называемых уровнях зрелости (maturity levels). Всего их пять, и каждый из них характеризует определенную степень качества выпускаемых изделий. Таким образом, чем выше уровень зрелости компании, тем выше ее статус и авторитет в компьютерных кругах и в глазах пользователей.
Программы приобретают высокое качество не столько в результате комплексного тестирования конечного продукта, сколько в процессе его разработки. Если методология создания ПП такова, что ошибки обнаруживаются на регулярной основе и на всех стадиях выполнения проекта, то на выходе предстает продукт, в котором практически нет ошибок. Реализация данной методологии возможна при наличии нормативных документов в области документирования ПП.
Основу отечественной нормативной базы в области документирования ПП составляет комплекс стандартов Единой системы программной документации (ЕСПД), который был разработан в 70-е и 80-е годы. Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПП, и связаны, по большей части, с документированием функциональных характеристик ПП. Следует отметить, что стандарты ЕСПД носят рекомендательный характер. Дело в том, что в соответствии с Законом РФ «О стандартизации» они становятся обяза-
тельными при ссылке на них в договоре на разработку ПП.
Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела. К числу основных недостатков ЕСПД можно отнести:
- ориентацию на единственную, «каскадную» модель жизненного цикла ПП;
- отсутствие четких рекомендаций по документированию характеристик качества ПП;
- отсутствие системной увязки с другими действующими отечественными системами стандартов по жизненному циклу и документированию продукции в целом (например ЕСКД);
- нечетко выраженный подход к документированию ПП как товарной продукции;
- отсутствие рекомендаций по самодокументированию ПП, например, в виде экранных меню и средств оперативной помощи пользователю (help);
- отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПП, согласованных с рекомендациями международных и региональных стандартов.
Тем не менее до пересмотра всего комплекса многие стандарты могут с пользой применяться в практике документирования ПП [7-9]. Кроме этого, в РФ действует ряд стандартов в части документирования ПП, разработанных на основе прямого применения международных стандартов ИСО [10-13]. Следует отметить, что стандарты ИСО серии 9000 ориентированы не на проверку качества готового продукта, а на принятие мер по предотвращению, оперативному выявлению и устранению дефектов в продукте, начиная с самых ранних этапов его жизненного цикла. Данные стандарты являются общими для всех видов продукции и услуг.
Таким образом, возникла потребность во введении в отечественные стандарты на документирование ПП норм, правил, требований и рекомендаций, которые установлены на международном уровне. Но при проведении этих работ нельзя ограничиваться прямым переводом отдельных международных стандартов. Важно, чтобы новые стандарты правильно стыковались со всем имеющимся и будущим множеством нормативных документов.
Одной из важнейших задач обеспечения качества ПП является формализация характеристик качества и методология их оценки. Исходными данными при выборе показателей качества в большинстве случаев являются назначение, функции и функциональная пригодность соответствующего ПП. Достаточно полное и корректное описание этих свойств должно служить базой для определения значений большинства остальных характеристик и атрибутов качества. Принципиальные и технические возможности, точность из-
мерения значений атрибутов характеристик качества всегда ограничены в соответствии с их содержанием. Это определяет рациональные диапазоны значений каждого атрибута, которые могут быть выбраны на основе здравого смысла, а также путем анализа прецедентов в спецификациях требований реальных проектов.
Процессы выбора и установления метрик и шкал для описания характеристик качества ПП можно разделить на два этапа [14]:
- выбор и обоснование набора исходных данных, отражающих общие особенности и этапы жизненного цикла проекта ПП и его потребителей, каждый из которых влияет на определенные характеристики качества комплекса программ;
- выбор, установление и утверждение конкретных метрик и шкал измерения характеристик и атрибутов качества проекта для их последующей оценки и сопоставления с требованиями спецификаций в процессе квалификационных испытаний или сертификации на определенных этапах жизненного цикла ПП.
На первом этапе за основу целесообразно брать всю базовую номенклатуру характеристик и атрибутов [15]. Их описания желательно предварительно упорядочить по приоритетам с учетом назначения и сферы применения конкретного проекта ПП. Далее необходимо выделить и ранжировать по приоритетам потребителей, которым необходимы определенные показатели качества проекта ПП с учетом их специализации и профессиональных интересов. Подготовка исходных данных завершается выделением номенклатуры приоритетных показателей качества, определяющих функциональную пригодность ПП для определенных потребителей.
На втором этапе, после фиксирования исходных данных, которое должен выполнить потребитель оценок качества, процессы выбора номенклатуры и метрик начинаются с ранжирования характеристик и субхарактеристик для конкретного проекта и их потребителя. Далее для каждого из отобранных показателей должна быть установлена и согласована метрика и шкала оценок субхарактеристик и их атрибутов. Для показателей, представляемых качественными признаками, желательно определить и зафиксировать в спецификациях описания условий, при которых следует считать, что данная характеристика реализуется в ПП. Выбранные значения характеристик качества и их атрибутов должны быть предварительно проверены разработчиками на их реализуемость с учетом доступных ресурсов конкретного проекта и при необходимости откорректированы.
Для каждой характеристики необходимо сформировать меры и шкалу измерений с выделением требуемых, допустимых и неудовлетворительных значений. Реализация процессов оценки должна коррелировать с этапами жизненного
цикла конкретного проекта программного средства [16].
Функциональная пригодность - наиболее неопределенная и объективно трудно оцениваемая субхарактеристика ПП. Области применения, номенклатура и функции комплексов программ охватывают столь разнообразные сферы деятельности человека, что невозможно выделить и унифицировать небольшое число атрибутов для оценки и сравнения этой субхарактеристики в различных комплексах программ.
Оценка корректности ПП состоит в формальном определении степени соответствия комплекса реализованных программ исходным требованиям контракта, технического задания и спецификаций на ПП и его компоненты. Путем верификации должно быть определено соответствие исходным требованиям всей совокупности компонентов комплекса программ, вплоть до модулей и текстов программ и описаний данных.
Оценка способности к взаимодействию состоит в определении качества совместной работы компонентов ПП и баз данных с другими прикладными системами и компонентами на различных вычислительных платформах, а также взаимодействия с пользователями в стиле, удобном для перехода от одной вычислительной системы к другой с подобными функциями.
Оценка защищенности ПП включает определение полноты использования доступных методов и средств защиты ПП от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы.
Оценка надежности - измерение количественных метрик атрибутов субхарактеристик в использовании: завершенности, устойчивости к дефектам, восстанавливаемости и доступности/готовности.
Потребность в ресурсах памяти и производительности компьютера в процессе решения задач значительно изменяется в зависимости от состава и объема исходных данных. Для корректного определения предельной пропускной способности информационной системы с данным ПП нужно измерить экстремальные и средние значения длительностей исполнения функциональных групп программ и маршруты, на которых они достигаются.
Оценка практичности проводится экспертами и включает определение понятности, простоты использования, изучаемости и привлекательности ПП. В основном это качественная (и субъективная) оценка в баллах, однако некоторые атрибуты можно оценить количественно по трудоемкости и длительности выполнения операций при использовании ПП, а также по объему документации, необходимой для их изучения.
Сопровождаемость можно оценивать полнотой и достоверностью документации о состояниях
ПП и его компонентов, обо всех предполагаемых и выполненных изменениях, позволяющих установить текущее состояние версий программ в любой момент времени и историю их развития. Со-провождаемость должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные.
Оценка мобильности - качественное определение экспертами адаптируемости, простоты установки, совместимости и замещаемости программ, выражаемое в баллах. Количественно эту характеристику ПП и совокупность ее атрибутов можно (и целесообразно) оценить в экономических показателях: стоимости, трудоемкости и длительности реализации процедур переноса на иные платформы определенной совокупности программ и данных.
Последний вопрос, на который необходимо обратить внимание с точки зрения улучшения качества разрабатываемых ПП, - оформление авторских прав.
В соответствии с Законом РФ «Об авторском праве и смежных правах» [17] правовая защита программ для ЭВМ осуществляется на тех же основаниях, что и правовая защита литературных произведений. В то же время, остальные компоненты информационных технологий защищаются правами частной собственности или правами на интеллектуальную собственность. Таким образом, существует неоднозначность в правовом подходе к информационным технологиям и их компонентам, существующий юридический подход к ПП является менее эффективным и полезным, чем защита прав авторства при помощи механизма патентов. Используемый механизм оформления авторства на ПП не учитывает такие отличительные черты ПП, как их динамический характер, функциональность, целенаправленность, развитие во времени и изменчивость, наличие внутренних алгоритмов и технических решений и др. С другой стороны, литературное произведение является средством потребления, а ПП является средством производства, обработки различных данных. Несмотря на принципиальную разницу, для обеих категорий используется единая правовая база. При данном подходе существование таких понятий, как качество, надежность и безопасность ПП вступает в противоречие с понятием продукта творчества, что является причиной практически полного отсутствия обязательного контроля качества ПП.
ПП целесообразно классифицировать как продукт технического творчества, подчиняющийся законам развития технических систем, для которых разработана система патентной защиты прав на интеллектуальную собственность. Таким образом, патентная защита прав авторства на ПП является более естественной для данного класса тех-
нических систем. Механизм авторского права не защищает идей, методов, принципов и алгоритмов, положенных в основу конкретных программных реализаций. То есть если автор программы применил при ее составлении принципиально новые приемы, с помощью придуманного им алгоритма обеспечил отличное функционирование созданной программы, он, тем не менее, не может помешать другим программистам воспользоваться теми же алгоритмом, принципами и приемами. Это, пожалуй, один из основных недостатков в авторском праве России применительно к компьютерным программам. Производителям выгоднее не афишировать предложенные новшества, чем предлагать такие продукты без возможности защитить свои права на интеллектуальную собственность. Такая ситуация стимулирует развитие компьютерного пиратства, замедляет решение ряда важных задач в области информационных технологий (например, коммерческой тайной являются практически все технологии распознавания речи и текста).
Наиболее существенным моментом, определяющим специфику правового положения программ для ЭВМ, является предусмотренная законом возможность их официальной регистрации в Российском агентстве по правовой охране программ для ЭВМ, баз данных и топологий интегральных микросхем. Необходимо подчеркнуть, что регистрация программы - не обязанность ее создателя, а его право, которая осуществляется только по его желанию. При этом даже государственная регистрация не является презумпцией авторства. В принятой системе авторского права отсутствует контроль новизны и качества создаваемых ПП, что является причиной выпуска многочисленных версий ПП, отличающихся лишь количеством исправленных ошибок.
Механизм патентной защиты более гибок, чем механизм авторских прав, так как позволяет защищать разработки различного технологического уровня разными документами (методики и технологии - патентами, внедренные технические решения и доработки - авторскими свидетельствами и сертификатами). Таким образом, обеспечивается индивидуальный подход к разработкам в области информационных технологий, что позволяет более адекватно регулировать правовую ситуацию на рынке ПП.
Использование механизма патентной защиты для ПП может позволить:
- уменьшить ассортимент ПП на рынке до минимально необходимого;
- уменьшить число версий продаваемых ПП;
- повысить качество и надежность ПП;
- повысить информированность пользователей ПП;
- обеспечить государственный контроль деятельности производителей ПП.
Таким образом, для успешной реализации программных проектов недостаточно основываться только на методах стандартизации процесса разработки и эксплуатации ПП. Необходимо комплексное рассмотрение вопросов и правил разработки, документирования, защиты и оценки соответствия разрабатываемых ПП предъявляемым требованиям.
Список литературы
1. Robert McFeeley «A User's Guide for Software Process Improvement», Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213.
2. Всеобщее управление качеством (Total Quality Management) / Под ред. О.П. Глудкина. - М.: Радио и связь, 1999.
3. Робсон М, Уллах Ф. Практическое руководство по реинжинирингу бизнес-процессов. - М.: Аудит, ЮНИТИ, 1997.
4. James H. Harrington Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, McGraw-Hill Trade, 1991.
5. Буч Гради, Рамбо Дж., Якобсон А. Унифицированный процесс разработки программного обеспечения. - Изд.-во Питер, 2002.
6. Paulk M.C., Weber C.V., Curtis B., Chrissis M.B. et al. «The Capability Maturity Model: Guidelines for Improving the Software Process», Addison-Wesley, 1995.
7. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требование к содержанию и оформлению.
8. ГОСТ 19.402-78 ЕСПД. Описание программы.
9. ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний.
10. ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения.
11. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
12. ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.
13. ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления.
14. Липаев В. Оценка качества программных средств // Сетевой журнал. - 2002. - №3.
15. ГОСТ Р ИСО/MEK 9126-93. Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению.
16. ISO 12207:1995. Информационная технология. Процессы жизненного цикла программного обеспечения.
17. Соловьев Р.В. Авторское право: Комментарий к Закону Российской Федерации "Об авторском праве и смежных правах". - Изд-во Ось-89, 2001.
ОТЛАДКА ПОДСИСТЕМ ПОДДЕРЖКИ BLUETOOTH ВО ВСТРОЕННЫХ ПРИЛОЖЕНИЯХ
А.Е. Знамеровский, К.А. Хайт
Motorola Global Software Group, Russia
Технология Bluetooth была создана всего несколько лет назад, но уже успела найти широкое применение. Сегодня большинство выпускаемых сотовых телефонов и карманных компьютеров поддерживают Bluetooth. Выпускаются BT-модемы для ноутбуков, гарнитуры для мобильных телефонов. По прогнозам, в ближайшее время множество бытовых приборов будут оснащены Bluetooth, что, по замыслу разработчиков, позволит лучше координировать их работу.
Целью появления Bluetooth было создание дешевого протокола беспроводного обмена данными, поддерживаемого маломощными передатчиками и доступного по всему миру. Эти протоколы обеспечивают надежную передачу данных и речи в радиусе примерно 10 метров.
Максимально допустимая скорость обмена между двумя BT-устройствами составляет 721 Кбит/с, или три речевых канала. Bluetooth обеспечивает как соединение точка-точка, так и режим сетевого обмена. В одной BT-сети может одно-
временно находиться до 8 активных узлов и до 256 неактивных. Возможно взаимодействие между BT-сетями, когда одно устройство является элементом двух сетей.
Существуют два вида BT-каналов:
- асинхронный (ACL) - нет резервирования слотов времени, в любой момент master может начать обмен с любым из slaves и в любой последовательности;
- синхронный (SCO) - используется обычно для речевого обмена, master сети устанавливает полнодуплексное соединение со slave-устрой-ством и резервирует соответствующие временные слоты.
На нижнем уровне стека протоколов Bluetooth находятся так называемые базовые протоколы, над которыми располагаются «адаптированные». Поскольку BT является открытым стандартом, различные производители могут реализовывать свои собственные или общие пользовательские протоколы.
