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

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

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

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

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

В разделе 6 представлено около 70 технологических  работ, поддерживающих ЖЦ ПС. Процессы документирования ПС (6.1) охватывают планирование и регламентирование документирования, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комплекта документации на ПС. Конфигурационное управление (6.2) включает план реализации версий как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирования, методологии, процедур и стандартов качества в соответствии с контрактом и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в процессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Верификация ПС (6.4) включает организацию, планирование и техническое обеспечение. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов. Валидация (6.5) — удостоверение правильности (аттестация) — должна гарантировать полное соответствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее выполнение независимыми специалистами путем тестирования во всех возможных ситуациях исходных данных. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается.

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

Раздел 7 посвящен процессам организации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, производством и средствами для обеспечения прикладных процессов по созданию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструктуры (7.2) включают выбор и установление аппаратных и программных средств, технологии, стандартов и способов обслуживания, используемых для разработки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к проекту и подлежит конфигурационному управлению. Совершенствование ЖЦ ПС (7.3) подразумевает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходимые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответствующему плану.

В приложении А (нормативное) изложены основы преобразования и обобщения базовой структуры этого международного стандарта для конкретного проекта. Следует подчеркнуть необходимость реализации двух важнейших вариантов адаптации положений и рекомендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руководство по процессам адаптации и преобразования ЖЦ ПС для конкретного проекта, а также рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта.

ISO 9000-3: 1991

Технология обеспечения качества в ЖЦ ПС представлена в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Этой унификации предлагается добиваться, предотвращая отклонения от стандарта на всех этапах ЖЦ — от начала разработки до технического обслуживания и ремонта. Предполагается, что в контракте будут особо оговорены важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС, иначе это делается в процессе разработки. Поставщик должен документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Необходимо определить ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ. Обеспечение и проверка качества проводится персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ и создание изделий. Покупатель-заказчик назначает своего представителя, ответственного за сотрудничество с поставщиком в процесс создания ПС по данному контракту. В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает:

— анализ содержания контракта, поддержанного методиками, обеспечивающими качество ПС;

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

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

— планирование обеспечения качества компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведения разработки;

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

— измерения  характеристик продукции и процессов ее создания, а также регистрацию данных о достигнутом качестве ПС и их компонентов;

— испытания, которые включают планирование, реализацию, оценку результатов и документирование испытаний и сертификации;

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

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

— формализации состава, содержания и процессам  утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в программах и данных.

Адаптация процессов и работ  в стандартах жизненного цикла программных средств к характеристикам конкретных проектов.

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

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

Альтернативой является выбор и формирование комплекса инструментальных средств под технологию, формализованную на базе одного из адаптированных стандартов ЖЦ ПС. Для снижения затрат и обеспечения качества выбранный стандарт ЖЦ следует адаптировать к индивидуальному проекту ПС. Должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию. Этими характеристиками могут быть: функции ЖЦ информационной системы; требования системы и ПО; организационные основы коллективов специалистов, процедуры и стратегии их работы; размер, критичность и типы системы; число задействованного персонала и сторон-участников.

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

Выводы

На мой взгляд, проблема внедрения  в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для  производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:

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