У вас вопросы?
У нас ответы:) SamZan.net

Лекция 7 Планирование жизненного цикла программных средств 7

Работа добавлена на сайт samzan.net: 2015-07-10

Поможем написать учебную работу

Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 6.4.2025

13

PAGE  1

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

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

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

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

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

стоимость реализации соответствующих процессов;

инфраструктуру обеспечения реализации процессов;

потребности в ресурсах, включая соответствующее управление и контроль;

оценку и контроль качества реализации процессов;

управление риском результатов процессов;

обеспечение среды программной инженерии проекта ПС;

задания, выполняемые в каждом процессе и (или) работе.

  Администраторы каждого программного проекта должны стремиться по возможности использовать существующую организационную инфраструктуру предприятия. Если существующая инфраструктура не удовлетворяет потребностям конкретного проекта, тогда она должна быть соответствующим образом адаптирована или дополнена. Для устранения несовершенства (неполноты) существующей инфраструктуры может потребоваться использование субподрядных работ.

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

В стандарте ISO 15504 расширены, детализированы задачи и виды деятельности, которые следует  отражать в плане управления проектом ПС:

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

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

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

роли и обязанностях соответствующих субъектов проекта;

подлежащие выполнению работы и задачи;

перечень всех проектных результатов (продуктов), подлежащих поставке и определенных в структуре классификации работ;

критерии завершения соответствующей деятельности, работ, задач;

состав окончательных отчетных документов;

отчетные документы по стоимости и графикам проведения работ;

содержание средств организации работ по управлению, выпуску продукта и/или синхронизации работ;

периодичность и средства выдачи отчетных документов;

отчетные материалы по проблемам-дефектам или выполнению деятельности;

требования к ресурсам и их наличие.

Стандартами ISO 16326 и ISO 90003   рекомендуется в процессе планирования ЖЦ ПС подготовить и утвердить содержание следующих планов (рис. 7.1):

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

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

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

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

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

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

План разработки компонентов и  ПС в целом (см. рис. 7.1) должен включать назначение, стандарты и описание фрагментов жизненного цикла, которые следует использовать в процессе разработки:

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

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

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

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

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

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

Кроме того, в составе перечисленных планов или автономно может быть полезной разработка ряда вспомогательных планов (см. рис. 7.1):

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

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

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

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

        

7.3. Планирование процессов управления качеством  сложных                          программных средств

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

Соответственно должны выделяться и применяться методы и средства автоматизации процессов планирования и управления качеством по этапам разработки компонентов и  ПС в условиях реальных ограниченных ресурсов. Следует учитывать глубокую взаимосвязь плана управления и применения процедур обеспечения качества ПС с планом управления непосредственной разработкой программ, с процессами тестирования, испытаний и сертификации ПС. Эта связь выражается в аналогичном поэтапном представлении планов и в наличии в них значительной части близких по содержанию процессов и документов. При планировании процессов обеспечения качества ПС, целесообразно учитывать и использовать совокупность рекомендаций ряда стандартов, в которые входят – ISO 10005, ISO 10006, ISO 10013, поддерживающие базовые стандарты менеджмента качества серии ISO 9000 (см. лекцию 3).  

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

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

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

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

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

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

  1.  анализ контракта и спецификаций требований заказчика к ПС, выделение и ранжирование приоритетов характеристик и атрибутов качества конечного продукта;

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

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

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

создание методов, методик и средств объективного измерения свойств и/или значений  атрибутов характеристик качества программных компонентов на этапах их создания и всего ЖЦ ПС для испытаний заказчиком и эксплуатации пользователями;

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

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

В стандарте ISO 15504 (раздел MAN.3) процесс планирования и управления качеством ПС концентрируется на мониторинге качества продуктов и процессов,  как проекта, так и предприятия в целом. В результате успешной реализации процессов в проекте должно быть обеспечено:

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

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

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

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




1. реферат дисертації на здобуття наукового ступеня кандидата біологічних наук Ки
2. Тема 11 Развитие системы народного образования в СССР План
3. Быкова рассказывается о двух партизанах которые попадают в плен к немцам во время второй мировой войны
4. Реферат- Исследование законов предельной производительности
5. Курсовая работа- Оперативно-тактичні плани та бюджети як інструменти реалізації стратегічних планів і програм
6. Некоторые проблемы подготовки специалистов на основе перспективных инфор-мационных технологий
7. ВСТУП Енергетика є однією з основних галузей суспільного виробництва і відіграє провідну роль у розвитку н
8. Александр Матросов жизнь за други своя
9. СТИЛІ СУЧАСНОЇ УКРАЇНСЬКОЇ ЛІТЕРАТУРНОЇ МОВИ
10. реферат дисертації на здобуття наукового ступеня кандидата технічних наук Одеса 2001