CC BY
28
К вопросу о достижении качества бортового программного обеспечения летательных аппаратов
Антипова А. С.
Кафедра ИТАС, МИЭМ Тел. +7 (926) 185-19-06, e-mail: a.s.antipova@mail.ru
В современном мире компьютерная программа используется практически в любом продукте, начиная от стиральной машины - программа интенсивности и времени стирки, заканчивая высоко сложным и многомодульным программным обеспечением военной техники, космических аппаратов, атомных электростанций. Но если в случае выхода из строя «программной» начинки бытовой техники, Вы всего лишь останетесь без помощника по дому, то другое дело, если «зависла» операционная система гражданского самолета - под опасности оказывается сразу несколько десятков жизни, или военного истребителя - то может сорваться выполнение полетного задания. Естественно, что сейчас без программного обеспечения, качественно и без ошибок выполняющего свои функции, авиационной отрасли не обойтись. Как получить надежный и качественный продукт? На этот вопрос поможет ответить раздел науки под названием «Управление качеством программного обеспечения (ПО)».
В настоящее время ОАО ОКБ Сухого ведет разработку бортового ПО для гражданских и военных своей марки. Не стоит объяснять, что компьютер, управляющий машиной, должен принимать правильные решение в реальном времени, при чем скорость принятия решения в минуту в несколько десятков раз больше, чем у обычного персонального компьютера. При поставке программного обеспечения на самолет все критические ошибки в программе должны быть исправлены, а не критические - либо исправлены либо предсказуемы. Для этого проводится в три этапа всевозможные тесты, от проверки правильности написания процедур и употребления конструкций на уровне языка (модульное тестирование) до наземной отработки на «Железной птице» - система с аппаратными и программными блоками, кабелями, индикаторами, полностью повторяющая в размерах и функциях самолет. К сожалению, тестирование не является гарантией получения качественного продукта.
К тому же, если результаты тестирования оказались плохими, то приходится переписывать весь код, а часто и спецификации требований к коду или даже спецификации требований к системе. Что в свою очередь ведет к увеличению стоимости продукта, отодвиганию сроков выпуска готового продукта на рынок. Дальше больше - неудовлетворенность потребителей, получение производителем рекламаций, отказ от приобретения продукта и, возможно, в конечном счете, несение компанией-производителем убытков и полного разорения. Этот принцип называется десятикратное увеличение затрат. Действительно, в вопросах разработки ПО обеспечения не должно быть глобальных промахов, слишком уже им высока цена. В практике мировых производителей есть такой лозунг «Надо сразу делать хорошо !».[1] Поэтому процесс разработки ПО должен быть спланирован, управляем, контролируем.
Так почему же так сложно сделать качественное программное обеспечение в современном высокотехнологичном обществе?
Сразу стоит отметить, что ПО - очень специфичный продукт, и производством его занялись относительно не давно.
Вот как звучит определение ПО в [3]: «Программное обеспечение - это совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ»
Под программным обеспечением (ПО) в [1] понимают как собственно компьютерные программы, так и соответствующие методики, документацию и данные, необходимые для функционирования вычислительных систем. Будучи исключительно интеллектуальным продуктом, ПО относится к числу наиболее трудоемких, сложных и подверженных ошибкам технологий в истории человечества. Создано много видов ПО, предназначенных для разных типов компьютеров и других физических устройств, на которых они устанавливаются. Различия между ними определяются деловыми приложениями (например, информационные системы) или применением в составе других устройств, расположенных между пользователем и управляющими компьютерами (например, программы, "зашитые" в микропроцессорах, применяемых для создания интеллектуальных устройств).
Для того чтобы выделить отличительные особенности ПО, полезно проанализировать основные отличия процессов их создания от обычных видов продукции:
• ПО представляет собой не физический, а интеллектуальный продукт. Поэтому при его создании действуют скорее человеческие и логические ограничения, а не физические закономерности.
• Технические требования к ПО нельзя считать стабильными. Наоборот, при разработке ПО более характерны постоянно меняющиеся требования к нему.
• Производительность труда при создании ПО может варьироваться в широких пределах, причем эти колебания выше для отдельных исполнителей, нежели для творческих коллективов.
• Дефекты ПО являются следствием человеческих ошибок и неграмотности, а не низкого качества материалов.
• Экономические аспекты качества ПО определяются преимущественно процессами согласования требований к ним. Цена ПО обычно в большей степени определяется этими процессами, нежели их соответствием установленным требованиям.
• Стоимость непосредственного изготовления ПО составляет незначительную часть их полной стоимости, определяемой в основном затратами на разработку, внедрение и испытания.
• Статистические методы не применимы к процессу тиражирования, поскольку все копии, как правило, являются однородными по качеству.
• Стоимость содержания ПО определяется иными методами, так как эти активы не поддаются капитализации и амортизации.
V-образная модель жизненного цикла разработки ПО
Рис 1.
На Рис. 1 приведена одна моделей ЖЦ разработки ПО. Она не обязательно к применению, есть инкрементная, каскадная, спиральная и многие другие.
В нормативной базе производства качественного продукта на первом месте стоят стандарты серии ИСО 9000. Общим термином "ИСО 9000" обозначают для краткости группу международных стандартов по управлению качеством и обеспечению качества, разработанных техническим комитетом ИСО/ТК 176 - независимой организацией ИСО [4].
ISO 9000 устанавливает единые международные стандарты на систему управления качеством в любой производственной или сервисной компании. В стандарте определяются те общие методы, которые должны быть использованы при построении системы качества, чтобы гарантировать полное удовлетворение потребностей заказчика. Стандарт применяется именно к системе качества ("система качества - совокупность организационной структуры, методик, процессов и ресурсов, необходимых для общего руководства качеством" - [4]) и не касается технических характеристик продукции и технических требований к процессу производства. Реализация системы качества должна определяться задачами, продукцией, процессами и индивидуальными особенностями конкретной организации. Отличительной чертой стандарта является то, что построенная на его основе система качества не является застывшей. В самом стандарте заложены требования постоянного улучшения в соответствии с предполагаемыми потребностями заказчика.
Внедряя на предприятиях систему качества в соответствии с ИСО 9000, оно получает выгоду:
• за счет перераспределения затрат сокращается та их доля, которая шла на обнаружение и исправление дефектов, общая сумма затрат снижается и появляется дополнительная прибыль;
• повышается исполнительская дисциплина на предприятии, улучшается мотивация сотрудников, снижаются потери, вызванные дефектами и несоответствиями;
• предприятие становится более "прозрачным" для руководства, в связи с этим повышается качество управленческих решений.
Основополагающая идея ИСО 9000: система качества предполагает построение такой структуры управления процессом производства, которая гарантирует выпуск качественного продукта в любой момент, пока система действует. Итак, функционально стандарты семейства ISO 9000 связаны с обеспечением качества системы управления производством изделия.
Хотя в настоящее время отсутствует общепринятое, единое, стандартизированное определение понятия "качество программного обеспечения", некоторые определения этого термина можно обнаружить в стандарте ИСО 9000-3, в стандартах IEEE на ПО, в различных книгах и учебниках. Ниже приведены определения некоторых терминов, рассматривающих качество ПО с разных точек зрения.
• Уровень удовлетворенности. Ощущаемая потребителем или пользователем мера соответствия продукта их нуждам и ожиданиям.
• Ценность продукта. Ценность продукта с точки зрения конкурентов и заинтересованных сторон.
• Основные свойства. Наличие у продукта полного набора желаемых свойств.
• Отсутствие дефектов. Правильность работы продукта в заданных условиях применения, отсутствие эксплуатационных ошибок.
Качество процесса создания. Определяется тем, насколько правильно и эффективно работают исполнители в процессе создания продукта.
Каждая область применения предъявляет свои, специфические требования к ПО, и поэтому содержание понятия качества должно определяться в каждом конкретном
случае с учетом этих требований. Например, к ПО, применяемому в жизненно важных областях, предъявляют очень жесткие эксплуатационные требования, а в оценке типовых информационных систем основное внимание следует уделять показателям удовлетворенности потребителей.
В рамках любого проекта создания ПО на этапе планирования должны быть установлены требования к его качеству, вытекающие из специфики назначения разрабатываемого продукта. Эти требования служат основой для практической оценки достигнутого прогресса в области качества разрабатываемого продукта и его готовности к поставке потребителям.
• Качество программного обеспечения можно улучшать на техническом уровне (основные свойства, отсутствие дефектов). Так на ведущем предприятии авиационной отрасли практикуют использование генераторов автоматического кода, такие как SOLID, SCADE, IMAGE. На основе спецификаций требований к программному обеспечению в графической части редактора рисуются логики взаимодействия и алгоритмы функционирования операторов. Для этих целей используется простой в обращении высокоуровневый язык UML (Unified Modeling Language). Следующие действия сводятся к выбору исходного языка JAVA, C, C++ и нажатию кнопки старта кодогенерации. Плюсы данного метода:
• Уменьшение времени кодирования, а также полное отсутствие модульного тестирования,
• Увеличение качества получаемого кода за счет отсутствия человеческого фактора при использовании конструкций и выражений языка на стадии непосредственно кодирования.
Все это позволяет уменьшить количество времени для выхода готово продукта, а также сократить количество задействованных человеческих ресурсов (человеко-дней), сократить издержки на производство некачественно продукта. Единственное, что необходимо учесть, - закупка лицензионных инструментов, так как для доверия коду необходимо получить документальное свидетельство.
Квалифицированные и мотивированные работники (разработчики, тестировщики, управленцы) являются немаловажным фактором получения качественного ПО. Вопросы набора на работу персонала, проведения постоянных
тренингов, плановая и равномерная загруженность персонала, экономическое и иное стимулирование будут головной болью руководителей среднего и высшего звена [2].
Теперь мы подошли к основному фактору - это грамотная и профессиональная организация процесса разработки ПО. Для оценки готовности и проведения работ Институтом программной инженерии Университета Карнеги-Меллона (Software Engineering Institute, SEI) была разработана в 1991 году модель СММ Capability Maturity Model. для разработки программных продуктов. С течением времени было выпущено целое семейство моделей: SW-CMM — для программных продуктов, SE-CMM — для системной инженерии, Acquisition CMM — для закупок, People CMM — для управления людскими ресурсами, ICMM —для интеграции продуктов.
Разнообразные модели оказались достаточно сложными для понимания и внедрения. Поскольку они были созданы разными группами специалистов, содержание этих моделей не всегда согласовывалось друг с другом, а также с требованиями международных стандартов. Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования международных стандартов.
Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов (основные проблемы в программных разработках — это проблемы управления, а не технические проблемы), обеспечить стабильно высокое качество разработок и освоить процессы, которые могут служить основой для повышения конкурентной способности и дальнейшего развития и расширения компании.
В основе CMM/CMMI лежит понятие процесса. Принятие этой концепции помогает избежать естественной для многих организаций тенденции винить в неудачах людей. Увольнение сотрудников — не решение проблемы. За последние десятилетия произошли революционные изменения в технологии, однако проблемы успешного выполнения проекта остались. В этом аспекте технология также не решение проблемы. Ценность процесса в том, что он помогает уловить и использовать наивысшие достижения в будущих проектах. Именно на этой предпосылке и базируется CMMI.
СММ/CMMI — это модели. И воспринимать их следует именно как модели, т.е. упрощенное представление мира. Модели СММ/CMMI содержат существенные
элементы процессов, обеспечивающих разные стороны деятельности, и могут быть использованы как руководство для разработки и улучшения производственных процессов. В официальных изданиях модели подчеркивается, что она не представляет собой процессы или их описание. Реальные процессы в любой организации зависят от множества факторов, включая специфику бизнеса, структуру и размер организации.
Использование СММ1 в качестве основы для улучшения процессов требует определенных организационных изменений[6]. Такие изменения могут включать разработку общей технологии и языка как для программной, так и для системной инженерии, коренное улучшение коммуникаций, тесную интеграцию процессов системной и программной инженерии.
Существует реальная опасность использования СММ1 для достижения кратковременных конъюнктурных целей. Мировой опыт доказывает, что успешными являются лишь те программы улучшений, которые привязаны к долгосрочным бизнес-целям организации.
Модель СММ1 выпущена в двух вариантах — непрерывное представление и стадийное представление.
В основе стадийного представления лежит концепция зрелости процессов организации в целом (5 уровней зрелости). В основе непрерывного представления лежит концепция возможностей процессов в определенной области (6 уровней).
Различие между двумя представлениями заключается в том, что концепция возможностей процессов рассматривает комплекс действий («практик»), связанных с одной областью процессов, в то время как концепция зрелости процессов рассматривает комплекс процессов в масштабах всей организации.
Стадийное представление СММ1 основано на том, что для достижения определенного уровня зрелости организация должна внедрить все без исключения процессы, относящиеся к данному и всем предыдущим уровням зрелости. Так, организация, ставящая целью достичь 4-го уровня зрелости должна освоить все процессы 2-го, 3-го и 4-го уровней. Если окажется, что данная организация освоила все процессы 3-го и 4-го уровней, но не освоила хотя бы одного процесса 2-го уровня зрелости, она не будет признана соответствующей даже 2-му уровню зрелости.
Непрерывное представление CMMI рассматривает четыре категории процессов: управление процессами, управление проектами, инженерия, поддержка. Организация может сосредоточиться на той области процессов, которая является для нее наиболее критической. В этом случае можно говорить об уровне потенциальных возможностей для выбранной области процессов. Это означает, например, что организация может достичь 5-го уровня потенциальной возможности по управлению проектами и оставаться ниже 2-го уровня потенциальной возможности по управлению процессами.
Как СММ, так и CMMI (стадийное представление) предусматривают пять уровней зрелости организации: начальный, управляемый, определенный, количественно управляемый, оптимизационный.
В стадийном представлении CMMI каждый уровень зрелости характеризуется совокупностью процессов, которые в модели обозначаются как «Области процессов» (Process Area).
В чем привлекательность CMM и CMMI для разработчиков программных продуктов и компаний, специализирующихся на предоставлении программных услугах? Это не только свидетельство принадлежности к «клубу избранных». Это еще и надежда сделать производственные процессы управляемыми, а результаты предсказуемыми. Считается, что при достижении уже 3-го уровня зрелости резко ослабляется зависимость деятельности компании от индивидуальных особенностей конкретных исполнителей. В этом аспекте ключевые практики CMMI можно использовать в качестве «рецепта» улучшения действующих процессов и основы для разработки новых процессов.
Модель CMMI предоставляет комплекс общедоступных критериев, описывающих характеристики организаций, которые успешно усовершенствовали свои процессы. Модель может быть использована как для установления производственных процессов, так и для усовершенствования существующих процессов.
Для полного понимания практик CMMI необходимо принять во внимание весь контекст их использования. Модель CMMI не предписывает, какие процессы являются правильными для организации или проекта, но устанавливает минимальные
критерии, необходимые для планирования и применения процессов, выбранных организацией в качестве основы для улучшений.
Основные компоненты CMMI включают в себя [5]:
• Область процессов (process area) — группа взаимосвязанных практик, выполнение которых позволяет достичь цели данной группы процессов.
• Цель (goal) представляет собой заявление на высшем уровне о том, что должно быть достигнуто при эффективном применении практик. Специальные цели применимы к данной области процессов.
• Практика (practice) — описание действий, которые следует предпринять, чтобы «привести в действие» ключевые элементы данной области процессов. Специальная практика — это активность, которая необходима для достижения специальной цели.
• Типичный рабочий продукт (typical work product) — пример того, что должно быть получено в результате выполнения специальной или общей практики. Эти примеры названы типичными рабочими продуктами, потому что могут существовать и другие, не менее эффективные, рабочие продукты.
• Субпрактика (subpractice) — детальное описание действий, которые могут служить руководством для интерпретации специальных и общих практик. Субпрактики могут восприниматься как предписывающие элементы, но в действительности они носят информативный характер и дают полезные идеи о том, что реально может принести пользу для улучшения процессов.
• Уточнение (discipline amplification) содержат информацию о конкретной инженерной дисциплине (например, программирование, системный инжиниринг) и связаны со специальными практиками.
• Общая цель (generic goal) называется общей потому, что одна и та же формулировка цели появляется в различных областях процессов. В стадийном представлении CMMI каждая область процессов имеет только одну общую цель.
• Общая практика (generic practice) — элемент институализации процессов, некоторого рода гарантия того, что процессы данной области будут эффективными, повторяемыми и стабильными.
• Уточнения общих практик (Generic practice elaborations) служат руководством по применению общих практик к конкретной области процессов.
Все выше изложенные методики являются разрозненными, общими рекомендациями для получения качественного продукта. Основной целью дальнейших исследований является создание модели обеспечения качества ПО на основе серии стандартов ISO 9000, IEEE, CMM\CMMI для предприятия авиационной отрасли.
Результаты работы могут принести экономическую выгоду за счет сокращения издержек и времени разработки современного ПО, поднятия конкурентоспособности на российском и мировом рынках, получения репутации стабильной и хорошо управляемой своими процессами организации.
Список использованной литературы
1. Фатрелл Р.Ф., Шафер Д.Ф. Управление программными продуктами. Достижение оптимального качества при минимуме затрат. - М..:Вильямс, 2004
2. Брукс Ф. Мифический человеко-месяц. - С-Пб.: Символ, 2000
3. ГОСТ Р 51904 - 2002 Программное обеспечение. Общие требования к разработка и документированию. - ИПК издательство стандартов, 2003
4. ИСО 8402-1994 Управление качеством и обеспечение качеством. Словарь, 1994
5. CMU/SEI - 2006 - TR - 008 CMMI for Development. Improving processes for better products.// http://www.sei.cmu.edu/publications/pubweb.html, 2006
6. Мильман К., Мильман С. CMMI - шаг в будущее, 2007
