49897 (Проблемы совершенствования качества выпускаемого программного обеспечения), страница 2

Первая такая попытка обрела форму средств автоматизации разработки программ, получивших название CASE (computer aided software engineering). Идея CASE состояла в том, что программисты могли бы создавать более качественное программное обеспечение, если бы у них были вспомогательные программные средства. Каждому мастеру нужны определенные инструменты. Плотнику, к примеру, молотки. Попытайтесь забить гвоздь в доску с помощью ботинка.

Как и плотники, разработчики программного обеспечения имели свой набор основных, надежных инструментов: редактор, компилятор и отладчик. Подход CASE дал им возможность получить более совершенные инструменты, например, языки четвертого поколения (для них есть даже своя аббревиатура, 4GL). К сожалению, 4GL и большинство других высококачественных инструментальных средств не оправдали возложенные на них надежды. Возьмем, к примеру, Visual Basic. Все согласны, что это полезный, мощный и популярный 4GL-инструментарий, который позволяет увеличить производительность программистов и сократить число потенциальных ошибок. Однако до сих пор самую высокооплачиваемую работу предлагают программистам на Си, а подавляющее большинство крупных прикладных систем по-прежнему пишут на Си (Брайан Керниган, Деннис Ритчи, "Язык программирования Си" - Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice-Hall, 1978). По общему признанию, создание инструментария 4GL и CASE было вполне оправданно, но инструментальные средства общего назначения, такие как редакторы, компиляторы и отладчики, остаются главными в обиходе современных разработчиков программного обеспечения, несмотря на огромный интерес к CASE, возникший в начале 80-х.

Еще одна причина того, что этот инструментарий так и не завоевал широкой популярности, заключается в том, что их предназначение как средств, улучшающих качество программ, играет против них. Если инструментарий обещает значительное увеличение качества продукта, должен ли он сам быть высококачественным? Использовали ли его сами разработчики инструментария? Инструментальные средства, изобилующие ошибками, и при этом предназначенные для улучшения качества создаваемых программ, вряд ли понравятся разработчикам. Не менее важны и личные качества человека, который использует такой инструментарий. Утверждение "дурак с инструментом все равно дурак" остается верным и поныне.

Второе важное решение, предложенное в 80-х годах для создания более качественного кода, связано с использованием формальных методов. Как и в случае с CASE, многие рассматривали формальные методы как панацею (Richard Linger, "Cleanroom Process Model", IEEE Software, vol.11, no.2, Mar. 1994). И, как и в случае с CASE, это решение теоретически могло позволить решить проблему, но на практике все оказалось далеко не так.

Формальные методы представляли собой такие методики, как сокрытие информации, структурное программирование и поэтапное улучшение. Эти методики, появившиеся и ставшие популярными в 80-х годах, по-прежнему широко применяются современными программистами, что лишний раз подтверждает их успех. Структурное программирование и ориентация на объекты несомненно полезны для создания качественного кода. Они сейчас настолько широко применяются, что являются скорее правилом, нежели исключением.

Однако строгие формальные методы никогда не будут приняты в ведущих компаниях, специализирующихся на разработке программного обеспечения. Некоторые планируют внедрить тот или иной вариант строгих формальных методов (см. David P. Kelly, Robert S. Oshana, "Integrating Cleanroom Software Engineering Methods into an SEI Level 4-5 Program", Crosstalk, Nov. 1996), но подавляющее большинство современных разработчиков считают их узкоспециализированными. Причины - несоответствие затрат и возврата от инвестиций. Формальные методы сложно использовать, они весьма ресурсоемки и часто предполагают, что программист, применяющий их, должен был иметь чуть ли не кандидатскую степень. И что самое главное, как и в 80-х годах, по-прежнему не хватает инструментальных средств, которые могли бы помочь разработчикам в реализации формальных методов.

Тем не менее, десятилетие возрождения принесло ценные идеи, касающиеся увеличения производительности разработчика. Кроме того, ученые, неутомимо создающие формальные методы, дали научному сообществу методики, которые позволяют систематизировать руководство разработкой. К концу 80-х все осознали важность практических методов программирования, и в целом изменилось отношение к требованиям, гарантирующим более высокое качество.

1990-1999 гг.

Следующее "решение" проблемы качества программного обеспечения появилось в 90-х годах под названием "совершенствование процесса разработки программ". Основой этого движения была теперь популярная и часто критикуемая модель Capability Maturity Model. Для краткости упростим формулировку основного принципа совершенствования процесса разработки программ: создание программного обеспечения - это задача управления, к которой можно применять соответствующие процедуры управления данными, процессами и практическими методами, с целью создания максимально оптимального решения. Управление разработкой программного обеспечения гарантирует получение более качественного продукта.

Другими словами, поскольку разработчики не могли должным образом управлять своими проектами (что исторически подтверждается весьма низким уровнем качества программного обеспечения), менеджеры должны ввести организационный контроль. Впрочем, даже самые лучшие в мире процессы можно неправильно реализовать.

Несмотря на кажущуюся легкость тона, речь идет об очень серьезных вещах. При всей неоспоримости того факта, что хорошие процессы разработки программного обеспечения, как правило, необходимы, идея совершенствования таких процессов предполагает формирование антагонистических отношений между руководством и техническими специалистами. Ситуацию усугубляет и тот факт, что многие менеджеры, которые ничего не знают о программном обеспечении, внезапно выясняют, что их опыт якобы весьма востребован в программных компаниях, где задача совершенствования процессов разработки ставится во главу угла.

Процесс разработки программ и их тестирования состоит из следующих этапов (рис.1).

Исследуя приведенные ниже фазы разработки и внедрения программных продуктов, а также порядок выполнения активностей на описанных этапах, можно увидеть следующие проблемы, возникающие при неправильной организации процесса разработки программного обеспечения:

При общении с заказчиком требования к программному продукту были оговорены неточно, что приводит к неправильному пониманию своей задачи программистом.

Проведени недоскональный анализ программной спецификации, что в дальнейшем ведет к огромному числу трудно исправимых ошибок.

Стадия дизайна отсутствует, что сказывается на написании кода.

Отсутствуют или существуют неясные процессы по разработки программного обеспечения.

Рис.1. Этапы разработки программ и их тестирование

Примечания:

Фазы разработки программного обеспечения:

Inception - Начальный этап;

Elaboration - Разработка программ, уточнение требований к продукту;

Construction - Написание кода;

Transition - Доработка программ, сдача и поддержка продукта.

Дисциплины, применяемые на этапах разработки:

Business Modeling - Бизнес-моделирование;

Requirements - Написание и анализ требований;

Analysis & Design - Анализ и дизайн кода;

Implementation - Написание кода;

Test - Тестирование программ;

Deployment - Ввод в действие программного продукта;

Configuration & Change Mgmt - Анализ конфигурации;

Project Management - Управление проектом;

Environment - Исследование и анализ среды внедрения.

Тестирование начинается на поздних стадиях разработки программ. В большинстве случаев такие программные продукты имеют большое число дефектов и др.

Как правило, все эти проблемы возникают из-за построенных ненадлежащим образом процессов разработки программных приложений в аутсорсинговых компаниях.

Однако разработка программного обеспечения в основе своей - это техническая задача. Хорошие разработчики могут создать хорошее программное обеспечение, несмотря на плохое руководство или даже его полное отсутствие. Однако обратное неверно: неквалифицированные технические специалисты вряд ли разработают хорошее программное обеспечение даже при блестящем руководстве. Описание другого исследования, но с аналогичными выводами, главным образом относительно роли руководства в решении проблемы 2000 года, можно найти в статье Роберта Гласса (Robert Glass, "Y2K and Other Software Noncrises," IEEE Software, vol.17, no.2, Mar. 2002). В силу вышесказанного, CMM внедряется медленно. Во многих программных компаниях разработчики по-прежнему не знают о ее существовании.

Модель CMM - это не только идея совершенствования процессов разработки, возникшая в 90-х годах. В последние годы этого десятилетия организации, специализирующиеся на разработке программного обеспечения, начали применять ту или иную популярную теорию к своим процессам. Пример тому - Six Sigma, метод первоначально предназначенный для сокращения ошибок при проектировании и производстве аппаратных систем.

"Шесть сигма" (Six Sigma) - это дисциплинарный, определяемый данными подход и методология ликвидации дефектов в любом процессе - от производства до транзакций, от продукта до службы. Чтобы добиться уровня "шести сигма", процесс не должен порождать более 3,4 дефектов на миллион случаев (http://www.isixsigma.com/sixsigma/six_sigma. asp).

Главный недостаток методики Six Sigma, состоит в том, что до сих пор не ясно, что означает миллион потенциальных случаев появления ошибок в программном продукте. Более того, как это вообще их можно корректно подсчитать?

Еще большему увеличению пропасти, разделяющей руководство и технических специалистов в процессе разработки программного обеспечения, способствовало то, что в 90-е годы достигнут значительный прогресс в развитии вычислительной инфраструктуры. Новые операционные платформы превзошли более старые операционные системы по функциональности. Знания, которые раньше были полезными, стали ненужными. Появились новые языки программирования, мгновенно завоевавшие популярность. Программированию приходилось учиться снова и снова. Новые API для коммуникаций, защиты, распределенных вычислений и, конечно, Web, полностью перевернули жизнь разработчиков. Поскольку разработчики постоянно находились в стрессовых условиях, так как были вынуждены без конца изучать все новые и новые технологии, у них не было времени на то, чтобы следовать конкретным стандартам на процесс разработки программного обеспечения.

В защиту идеи процессов разработки программ можно сказать, что это было абсолютно новое явление. Как и многие другие новшества, оно не было до конца понятным, и зачастую его использовали неверно. Нам кажется, что одна из особенностей 90-х годов состоит в том, что практика процесса разработки программ не позволяла с легкостью поддерживать новые технологии. То, что работало на мэйнфреймах или настольных приложениях, не обязательно работает на продуктах, которые быстро создаются и ежечасно развертываются в современном мире, где существует Internet.

Однако как это было и в случае с его удачными предшественниками, особое внимание к процессу разработки программ дало свой положительный эффект. Тот факт, что значительно больше разработчиков узнали о таких простых вещах, как управление конфигурированием, контроль ошибок и анализ с помощью коллег, безусловно, оказалось полезным.90-е годы начинались как революция процессов, а закончились осознанием того, что процесс разработки нельзя навязать людям, и вряд ли такой подход станет популярным в ближайшие годы. Более того, бессмысленно реализовывать процесс ради самого процесса. Улучшение процессов разработки программ возможно за счет их упрощения, увеличения конструктивности и использования более качественных технических решений.

Наконец, 1990-е годы ознаменовали первую реальную попытку превратить разработку программного обеспечения в инженерную дисциплину с помощью концепций CBSE (component-based software engineering - "компонентная разработка программного обеспечения") и COTS (commercial off-the-shelf - готовые коммерчески доступные компоненты). Идея состоит в создании небольших, высококачественных модулей и последующего их объединения. Проблема, безусловно, заключается в том, что объединенные вместе высококачественные модули не обязательно превратятся в высококачественную систему. Комбинированная система может оказаться никуда негодной из-за некорректного способа объединения, либо из-за ошибочных представлений о поведении компонентов или о среде, в которую они помещаются. Более того, COTS-компоненты, которые обычно лицензируются в виде исполняемых модулей, могут породить неприятные побочные эффекты, неизвестные получателю лицензии. Подобные побочные эффекты иногда проявляются только при объединении одних компонентов с другими, и их практически невозможно обнаружить при тестировании каждого модуля в отдельности. Парадигма "разделяй и властвуй", которая оправдывает себя в случае аппаратных и физических систем, может оказаться губительной для систем логических. Лишь время покажет, как CBSE повлияет на качество программного обеспечения в будущем.

2000-2009 гг.

В первые годы нового десятилетия мы гадаем, что нас ждет в будущем. Сможем ли мы именно в этом десятилетии решить проблему качества программного обеспечения? Будет ли это десятилетием, когда разработчики и пользователи начнут воспринимать ошибку в программном обеспечении как нечто исключительное? Или в конце этого десятилетия мы опять станем возлагать на будущее те же надежды, что и в 2000 году: "Все программное обеспечение содержит ошибки, и каждый должен с этим смириться" (Charles C. Mann, "Why Software Is So Bad, and What Is Being Done to Fix It?" MIT Technology Rev., 17 June 2002)?

По словам Леса Хеттона (Les Hatton, "Does OO Sync With How We Think?" IEEE Software, vol.15, no.3, May 1998), "отраслевой стандарт на хорошее коммерческое программное обеспечение предусматривает около 6 ошибок на тысячу строк кода при среднем показателе в 30 ошибок". Таким образом, уровень ошибок последние двадцать лет практически не меняется, несмотря на объектно-ориентированную технологию, автоматические отладчики, более качественные средства тестирования и более строгий контроль типов в таких языках, как Java и Ada. Есть ли основание считать, что в этом десятилетии ситуация изменится? Хотя технические трудности растут, но серьезный стимул дает тот факт, что расходы из-за некачественного программного обеспечения также увеличиваются. Согласно данным отчета, опубликованного в 2002 году Национальным институтом по стандартам и технологии, "объем экономических потерь из-за ошибочного программного обеспечения в США достигает миллиардов долларов в год и составляет, по некоторым оценкам, около 1% национального валового внутреннего продукта" (Research Triangle Institute, "The Economic Impacts of Inadequate Infrastructure for Software Testing," NIST Planning Report 02-3, May 2002).

Некоторые программисты уже отказываются от традиционных методов разработки программного обеспечения (как одномоментных, так и поэтапных) в пользу методов быстрого и экстремального программирования. В своем крайнем проявлении быстрая разработка - это абсолютно неструктурированный, хаотический процесс, который использует специализированные методы и в котором пропускаются многие этапы планирования и проектирования. Хотя быстрая разработка может сократить время выпуска продукции и увеличить скорость, с которой программист создает код, позволит ли такой подход увеличить качество, совершенно не известно.

Вопрос о том, что это десятилетие предложит, разделяет "кризисных специалистов" и тех, кто верит, что человеческая изобретательность и инженерные "ноу-хау" позволят решить проблему качества программного обеспечения. В конце концов, бухгалтеры разобрались с вопросами качества, самолетостроительные компании решили эту проблему, производители электроприборов справились с такой задачей, водопроводчики нашли выход и электрики добились успеха.