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

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

Когда-то более полусотни организаций предлагали свыше 300 стандартов программной инженерии [1]. Но по мере совершенствования стандартов и роста затрат на создание программных продуктов число разработчиков стандартов сокращается, а организации находят иные способы поддержки клиентов. Так, министерство обороны США теперь использует коммерческие стандарты, публикуемые Международной организацией по стандартизации (ISO), Международной электротехнической комиссией (IEC) и IEEE.

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

Текущее положение

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

  1. Располагает ли ИТ-отрасль признанным набором зрелых стандартов на процессы жизненного цикла ПО?
  2. Существуют ли стандарты, которые уточняют каждый из базовых процессов в этом наборе практических решений?
  3. Может ли ИТ-отрасль легко и эффективно адаптировать этот набор решений к конкретным условиям бизнеса и организации процессов?
  4. Существуют ли стандарты для оценки способности предприятия эффективно создавать программное обеспечение?
  5. Указывают ли эти стандарты, как точно оценить трудозатраты и сроки выполнения работ при создании ПО?
  6. Являются ли эти стандарты хорошо определенными и признанными стандартами качества?
  7. Располагает ли ИТ-отрасль необходимыми методиками и кадрами для периодического совершенствования набора стандартов?

Зрелые практические решения

ИТ-отрасль располагает набором общепризнанных стандартов на процессы жизненного цикла ПО, из которых можно выбирать подходящие для конкретной ситуации. Стандарты международные (ISO), профессиональные (IEEE), национальные (скажем, британские или австралийские) и относящиеся к конкретным сферам профессиональной деятельности (например, Международного агентства по атомной энергии) определяют 18 основных процессов жизненного цикла ПО. Они описывают наилучшие практические решения для создания и поддержки программного обеспечения на основе существующих технологий и накопленного опыта.

При подготовке каждого стандарта в семействе необходимо учитывать ответы на ряд вопросов.

  • Как он связан с другими стандартами в семействе?
  • Имеют ли все стандарты семейства согласованный формат представления?
  • Имеют ли все разделы стандарта одинаковый уровень детализации?
  • Каковы его наиболее важные элементы?
  • На основе каких признаков пользователь может убедиться в соответствии продукта данному стандарту?

Существуют четыре основных стандарта на процессы программной инженерии:

  • ISO/IEC 12207, Software Lifecycle Processes, 1995;
  • ISO/IEC 15504, Software Process Assessment (multipart), 1998;
  • ISO 9001, Quality Management Systems-Requirements, 2000.

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

Перечисленные спецификации поддерживаются другими международными стандартами (такими как ISO 10007, Quality Management Systems — Guidelines for Configuration Management, 2003), профессиональными стандартами (например, IEEE 1042, Software Configuration Management,1987) и стандартами конкретной сферы бизнеса (скажем, Европейское космическое агентство, ESA PSS-05-09, Guide to Software Configuration Management, 1992). Требуется серьезная дополнительная работа, чтобы гарантировать адекватность стандартов в условиях изменений технологии. При этом крайне важно, чтобы развивающийся набор стандартов оставался внутренне согласованным.

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

Стандарты на базовые процессы

В ISO/IEC 12207 и ISO/IEC 15939, Software Measurement Process (2002) определены 18 основных процессов, объединяющих в себе зрелые практические решения программной инженерии. Для каждого процесса из этого набора должны существовать один либо несколько уточняющих его международных, профессиональных или бизнес-стандартов. Однако далеко не все современные стандарты обладают одинаковой степенью детализации. Например, тестирование относится к указанным 18 процессам, но нет единого стандарта, который определял бы все его аспекты (такие как планирование, составляющие модули, систему, интеграцию, регрессию, подготовку сценариев и документации).

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

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

Адаптация

Пользователи могут адаптировать набор зрелых практических решений и уточняющие их стандарты к конкретным условиям бизнеса и организационной структуре, не искажая сути стандартов. Однако это вовсе не легко, поскольку правила адаптации не всегда согласованы. Скажем, ISO/IEC 12207 и ISO/IEC 15288 описывают адаптацию по-разному, причем в последний стандарт предлагает более детальный подход.

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

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

Стандарты оценки потенциала производителей

Известно немало неприятных ситуаций с программными проектами, не уложившимися в рамки отведенных бюджетов, не выполненными в срок или не оправдавшими ожиданий. В конце 80-х годов Министерство обороны США финансировало исследования с целью выработки критериев, по которым можно определять способность производителей создавать качественные программные продукты. Университет Карнеги-Меллона разработал модель Software Engineering Institute Capability Maturity Model (SEI CMM). Аналогичные модели создавали и другие организации по всему миру. Какое-то время имело хождение 25 таких моделей [1], предназначенных для различных сегментов бизнеса и компаний разного размера.

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

SEI CMM, его аналог Capability Maturity Mode Integration (CCMI) и ISO/IEC 15504 используют числовую шкалу для оценки способности компании выпускать программное обеспечение. Баллы по этой шкале выставляются с учетом эффективности применения производителем соответствующего набора процессов. Эти модели и стандарты также косвенно указывают на то, чего должна добиться компания для перехода на следующий уровень зрелости и получения более высокой оценки.

Стандарты для оценки способности компании выпускать качественное ПО только начинают внедряться. Очень немногие покупатели конечных продуктов интересуются выполнением требований этих стандартов, если вообще знают о них. Менее 5% из примерно 100 тыс. компаний, занимающихся программной инженерией, используют какую-либо модель зрелости, и лишь единицы из них могут претендовать на высший балл. Правда, подобные модели применяются все чаще, поскольку все больше организаций стремятся поставлять или приобретать программные решения, максимально соответствующие требованиям бизнеса.

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

Стандарты для оценки затрат и сроков

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

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

  • ISO/IEC 19761, Common Software Measurement International Consortium-Full Function Points (COSMIC-FFP)-A Functional Size Measurement Method, 2003;
  • ISO/IEC 20926, International Function Point Users Group (IFPUG) 4.1 Unadjusted Functional Size Measurement Method-Counting Practices Manual, 2003;
  • ISO/IEC 20968, Mark II Function Point Analysis Counting Manual, 2002.

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

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

Стандарты на качество систем

Разработчики программного обеспечения должны продемонстрировать способность предлагать продукты, отвечающие запросам пользователей и соответствующие требованиям законодательства. Для этого им необходимо выполнять требования стандарта качества. Зрелый и признанный стандарт качества ISO 9001 распространяет свое действие на системы, предназначенные для различных сфер бизнеса. С помощью руководства ISO (ISO/IEC 90003, Guidelines for the Application of ISO 9001:2000 to Computer Software, 2004) производители могут выяснить, как применять ISO 9001 к их предметной области.

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

Необходимые подходы и персонал

Стандарты создаются в рамках подхода, предусматривающего согласование мнений всех сторон с участием специалистов-волонтеров. Последние, как правило, являются сотрудниками государственных организаций или корпораций, которые могут финансировать подготовку стандартов и организовывать совещания в течение продолжительного периода. Хотя в мире более 50 организаций разрабатывают стандарты [1], их деятельность практически не координируется. Во все времена соперничество между ними едва скрывалось. В итоге многие стандарты почти не соотносятся с другими, потенциально связанными с ними, стандартами.

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

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

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

Сейчас во всем мире менее 500 человек имеют более чем двухгодичный опыт разработки стандартов и активно занимаются стандартами программной инженерии [1]. Они получили прекрасное образование и располагают необходимыми полномочиями для подобной деятельности, причем большинство из них является сотрудниками крупных фирм и госучреждений. Поскольку финансирование добровольцев зависит от многих моментов, текучесть кадров весьма высока. Соответственно, приходится тратить массу времени и средств на обучение новых участников, информирование их о достигнутых результатах и самой системе создания стандартов, возникают проблемы преемственности и согласованности. Все это заставляет небольшие компании отказываться от участия в разработке стандартов.

Таким образом, система должна отражать мнение множества заинтересованных сторон, быть более эффективной и располагать менее дорогостоящими механизмами создания стандартов. Одно из предложений заключается в том, чтобы издатель и распространитель стандартов (скажем, ISO, IEC или IEEE) брал на себя больше затрат на создание стандарта, предоставляя, например, для его анализа и обсуждения разделяемое электронное рабочее пространство.

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

Задачи на будущее

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

  1. Как усовершенствовать стандарты для предотвращения чрезмерные расходов и нарушения установленных сроков?
  2. Как определить качество покупаемого пользователями программного обеспечения?
  3. Как пользователям определить уровни целостности, конфиденциальности и безопасности программного обеспечения?
  4. Как подготовить ясные, точные и взаимно совместимые стандарты?
  5. Как обеспечить более эффективное использование времени и средств при создании и изменении стандартов программной инженерии, ориентированных на технологии?
  6. Что позволит разработчикам более оперативно внедрять стандарты и информировать пользователей?

Предотвращение перерасходов и невыполнения сроков

Заказчики все более нетерпимо относятся к превышению бюджетов при разработке и реализации программных проектов. При создании ряда основных национальных систем, таких как Система налогового управления США [2] и Канадская система контроля за вооружением [3], были значительно превышены бюджеты. Необходимы более качественные методики для оценки затрат на создание ПО, более эффективные процессы управления проектами, более совершенные стандарты на процессы жизненного цикла, качество и контроль.

Для того чтобы избежать проблем в собственных проектах, заказчик должен получить ответы на следующие основные вопросы. Используются ли в проекте зрелые стандарты на разработку ПО? Если да, то в чем состоят недостатки набора стандартов (то есть почему эти стандарты привели к неудачной реализации проекта)? Были ли эти стандарты должным образом адаптированы при реализации проекта для решения конкретных задач бизнеса?

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

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

Реализация такого подхода обеспечит совершенствование решений программной инженерии, что, в конечном счете, приведет к сокращению числа проектов, не уложившихся в срок или вышедших за рамки бюджета. Эффективность координации в рамках этого подхода будет зависеть от значимости проявляющихся ошибок и настойчивости пользователей в стремлении получать качественные продукты. Если организации станут создавать стандарты, хорошо представляя процесс послепродажного обслуживания и уделяя особое внимание корректной реализации своих стандартов, число «вышедших из-под контроля» программных проектов начнет сокращаться.

Качество программного обеспечения

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

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

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

Производители должны договориться о создании и применении единой, дружественной к пользователю схемы определения качества ПО. Один из подходов заключается в использовании схемы, аналогичной принятой в автомобилестроении ряда стран. В соответствии с ней сторонняя организация, опираясь на конкретные критерии, раз в год определяет рейтинг автомобилей. Разработчики могут использовать такой подход для оценки всевозможного ПО. Подобная служба составления рейтинга должна опираться на модель CMM определенного типа, но использовать развивающиеся стандарты оценки качества продуктов. Любая пользующаяся доверием рейтинговая система должна превратить специализированную терминологию сообщества в простую, понятную пользователям схему, которой они могли бы доверять.

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

Целостность, конфиденциальность и безопасность

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

ИТ-отрасль разработала системы, позволяющие определять рейтинг безопасности (с уровнями от 0 до 5) и указывающие методики, которым должны следовать разработчики. Сертификация, подтверждающая, что программный продукт отвечает определенному уровню безопасности, поможет пользователям сориентироваться в том, насколько он удовлетворяет их требованиям. В других областях, скорее всего, будут реализованы аналогичные методы и созданы стандарты, удовлетворяющие этому критерию.

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

Ясность, точность и совместимость

Стандарты на процессы программной инженерии создаются несколькими организациями, и они должны тесно взаимодействовать друг с другом. Только в этом случае они смогут предоставить ИТ-отрасли набор ясных, точных, совместимых стандартов. Единственный способ добиться этой цели — поддерживать открытое взаимодействие производителей ПО и использовать общепризнанные принципы и шаблоны для создания стандартов на процессы. Кроме того, производители должны договориться, кто именно будет отвечать за создание и поддержку конкретных стандартов, чтобы избежать дублирования и ненужной конкуренции. Согласованные совместимые стандарты разработчику ПО реализовывать значительно проще.

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

Эффективность стандартов, ориентированных на технологии

Разработчики стандартов должны опробовать новые методы и технологии взаимодействия, чтобы снизить временные и материальные затраты на создание и модификацию стандартов программной инженерии, ориентированных на технологии. Это позволит им оперативно реагировать на изменения в технологии создания ПО и требования пользователей, не снижая качества итогового стандарта. Тот факт, что стандарты всегда создаются определенным образом, не должен препятствовать реализации новых идей.

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

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

Для эффективного производства стандартов на ПО все разработчики должны быть готовы использовать новые способы создания таких решений, предлагать средства общения и совместного использования новых технологий.

Оперативность внедрения и информирования пользователей

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

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

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

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

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

Пусть наше сообщество сделает шаг вперед к решению этих задач!

Литература
  1. S. Magee, L.Tripp. Guide to Software Engineering Standards and Specifications. Artech House, 1997.
  2. Pittsburgh Tribune-Review, IRS Delays Switch to New Computer System until 2004, 30 July 2003.
  3. Canada News, Gun Registry Setback, 4 June 2003.

Стен Маги (StanMagee@compuserve.com) в 1999-2002 годах руководил рабочей группой WG 7 Life Cycle Management комитета по стандартам ISO/IEC JTC1 SC 7 Software and Systems Engineering. Более полутора десятилетий занимается разработкой стандартов на процессы программной инженерии. Даг Тиль (doug.thiele@ieee.org) — руководитель WG 7 Life Cycle Management и глава австралийской группы в комитете по стандартам ISO/IEC JTC1 SC 7 Software and Systems Engineering.

Stan Magee, Doug Thiele, Engineering Process Standards: State of the Art and Challenges, IEEE IT Pro, September/October 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.