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

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

Подписываем
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
13
PAGE 1
Должны быть определены обязанности специалистов по подготовке и утверждению (согласованию) планов. Следует установить модель жизненного цикла программного средства, задачи, распределение задач, их блокировку и соответствующие ресурсы. В программном проекте должен быть определен один основной график работ, а все вспомогательные графики должны быть связаны и согласованы с основным графиком. С помощью структуры классификации работ можно эффективно проверять ход процессов и обеспечивать контроль этих процессов и продуктов. План должен быть применен так, чтобы обеспечить управление программным проектом на всех уровнях его детализации с использованием соответствующих технологий в зависимости от объема, сложности, критичности и риска проекта. Оценки проекта, используемые при планировании, должны охватывать:
стоимость реализации соответствующих процессов;
инфраструктуру обеспечения реализации процессов;
потребности в ресурсах, включая соответствующее управление и контроль;
оценку и контроль качества реализации процессов;
управление риском результатов процессов;
обеспечение среды программной инженерии проекта ПС;
задания, выполняемые в каждом процессе и (или) работе.
Администраторы каждого программного проекта должны стремиться по возможности использовать существующую организационную инфраструктуру предприятия. Если существующая инфраструктура не удовлетворяет потребностям конкретного проекта, тогда она должна быть соответствующим образом адаптирована или дополнена. Для устранения несовершенства (неполноты) существующей инфраструктуры может потребоваться использование субподрядных работ.
Планирование является постоянной, повторяющейся работой, при выполнении которой оценивают, уточняют и, при необходимости, корректируют ход проекта. Администраторы программного проекта должны использовать соответствующие процессы, способствующие проведению перепланирования и уточненных оценок в жизненном цикле программного проекта. В каждом программном проекте имеется множество взаимосвязей, поэтому для уточнения исходного плана управления проектом обычно требуется несколько итераций. При необходимости внесения в план управления информации, содержащейся в других планах, в данном плане может быть приведена ссылка на эти планы.
Поставщик-разработчик ПС должен подготовить планы по каждому виду деятельности. Следует установить и поддерживать в рабочем состоянии документированные процедуры, гарантирующие разработку программного продукта в соответствии с заданными требованиями и согласно плану развития ЖЦ. Такие планы должны описывать виды деятельности или содержать ссылки на разделы стандартов и определять ответственность за их осуществление.
Планирование жизненного цикла ПС должно определить действия по анализу требований, проектированию, программированию, интегрированию, тестированию, установке и поддержке программных средств с целью их принятия и применения заказчиком. Жизненный цикл следует оформить документами, которые необходимо проанализировать на реализуемость и утвердить. Они должны актуализироваться по мере развития проекта. В планах необходимо определить, каким образом следует управлять проектом, контролировать и анализировать выполнение работ, а также установить вид и частоту отчетов для руководства, заказчика и других заинтересованных сторон, принимая во внимание все конкретные требования заказчика. В планах должны определяться организационные подразделения и специалисты, которые будут исполнять различные виды работ. Для этого планы должны содержать следующую информацию:
роли и обязанностях соответствующих субъектов проекта;
подлежащие выполнению работы и задачи;
перечень всех проектных результатов (продуктов), подлежащих поставке и определенных в структуре классификации работ;
критерии завершения соответствующей деятельности, работ, задач;
состав окончательных отчетных документов;
отчетные документы по стоимости и графикам проведения работ;
содержание средств организации работ по управлению, выпуску продукта и/или синхронизации работ;
периодичность и средства выдачи отчетных документов;
отчетные материалы по проблемам-дефектам или выполнению деятельности;
требования к ресурсам и их наличие.
Стандартами ISO 16326 и ISO 90003 рекомендуется в процессе планирования ЖЦ ПС подготовить и утвердить содержание следующих планов (рис. 7.1):
Соответствующие планы должны быть разработаны администраторами вспомогательных процессов, так как эти процессы обычно являются частью проекта. Данные планы должны быть привязаны к базовому плану управления жизненным циклом программного проекта и обеспечивать его реализацию; они могут быть оформлены в виде отдельных планов или включены в общий план. Планы должны быть согласованы (утверждены) менеджером проекта программного средства и подлежат контролю при внесении изменений в проект. Менеджером администратором планирования программного средства должна быть определена отчетность по вспомогательным процессам (либо непосредственная, либо через управление организацией). Должны быть представлены отчеты о проблемах-дефектах и исключительных ситуациях для анализа их влияния на стоимость проекта, график работ по нему, область управления проектом и его качество. Должен быть определен механизм для разрешения или преодоления конфликтных ситуаций между администратором планирования ЖЦ программного средства и администраторами вспомогательных процессов на соответствующем уровне их полномочий по организационному управлению.
Когда определенные контрольные точки проекта и результаты, установленные требованиями для этих точек, зависят от выходных результатов вспомогательного процесса, важно, чтобы отчетные материалы по ним были представлены точно и своевременно в соответствии с установленными планами. Это положение является общим для всех контрольных точек, связанных с выполнением договорных обязательств по вспомогательным процессам, поэтому необходимы синхронизация соответствующих планов и своевременное уведомление администратора программного средства о всех затруднениях, возникающих при выполнении соответствующих задач вспомогательных процессов. Синхронизация всех планов может быть затруднена при наличии субподрядных соглашений и заданий, но упрощена при наличии единого базового плана.
План управления жизненным циклом ПС включает регламентированные стандартами, процедуры анализа, проверки и оценки состояния проекта для реализации организационных и управляющих воздействий на компоненты и ПС в целом. При этом должны использоваться техническое задание и спецификации требований, в которых определяющую роль играют согласованные с заказчиком входные и выходные данные проекта ПС. Потребитель-заказчик может иметь определенные обязанности согласно контракту при формировании ЖЦ ПС. Особого внимания потребителя требует сотрудничество с разработчиком-поставщиком, своевременное предоставление ему нужной информации и решение оперативных вопросов для обеспечения качества ПС. Если представитель заказчика обладает соответствующей компетентностью, то он может представлять конечного пользователя продукта, а также административное руководство проектом и иметь полномочия заниматься контрактными вопросами. К ним относятся определение и уточнение требований спецификаций потребителя к поставщику и к показателям качества ПС, одобрение и утверждение предложений разработчика, а также заключение дополнительных соглашений с поставщиком. Целесообразно планировать либо регулярно проводить разработчиком и заказчиком совместные анализы состояния проекта, либо такие анализы в случае значительных проектных событий, чтобы охватить:
План разработки компонентов и ПС в целом (см. рис. 7.1) должен включать назначение, стандарты и описание фрагментов жизненного цикла, которые следует использовать в процессе разработки:
План верификации и тестирования ПС является предварительным описанием организации процедур тестирования, удовлетворяющих цели достижения заданной корректности программ. Данный план должен включать:
План сопровождения и управления конфигурацией ПС устанавливает методы, используемые для сопровождения программных средств и их компонентов в течение всего жизненного цикла. Этот план должен включать:
Цель планирования технологической среды жизненного цикла ПС состоит в том, чтобы определить методы, инструментальные средства, процедуры, языки программирования и аппаратные средства, которые будут использоваться и совершенствоваться для разработки, верификации, управления и подготовки документации программного средства. План должен включать стандарты, методы предотвращения ошибок и обеспечения отказоустойчивости, которые ограничивают возможность внесения ошибок, и такие методы тестирования, которые гарантируют их обнаружение. Цель методов обеспечения отказоустойчивости состоит в том, чтобы включить в проект такие средства обеспечения качества и безопасности применения ПС, которые могут гарантировать, что программное средство будет адекватно реагировать на ошибки входных данных, предотвращать выдачу ошибочных данных и контролировать возможность проявления ошибок.
Кроме того, в составе перечисленных планов или автономно может быть полезной разработка ряда вспомогательных планов (см. рис. 7.1):
Все перечисленные планы должны иметь в своем составе предварительные графики, идентифицирующие: этапы работ; входные, выходные данные и описания решаемых задач; необходимые ресурсы, длительность и сроки выполнения; взаимосвязи этапов и работ. Должно быть установлено организационно-техническое взаимодействие между различными группами специалистов, которые вносят свой вклад в процессы и обеспечение качества ЖЦ ПС, а необходимая информация должна документироваться и регулярно анализироваться. В планах работ поставщиков и субподрядчиков при проектировании следует четко определить границы ответственности за каждую часть программного средства и за способ обмена технической информацией между всеми сторонами проекта. При установлении этого взаимодействия следует обратить внимание на вспомогательных специалистов, помимо потребителя и поставщика, которым необходимы входные данные для проектирования, установки, обслуживания и подготовки программ и данных.
Анализ состояния и результатов проекта следует официально планировать и регулярно проводить на соответствующих этапах ЖЦ ПС. В состав участников каждого анализа должны включаться представители всех служб, заинтересованных в результатах анализируемого этапа проектирования. Степень формальности и жесткости действий по осуществлению анализа должна соответствовать сложности ПС и степени риска, связанного с областью применения и использованием программного средства. В процедуры анализа проекта могут входить действия, которые необходимо предпринять до и во время его проведения, включая используемые методики и руководящие указания для всех участников проверок. Если оговорено в контракте, поставщик должен проводить совещания по анализу результатов и состояния проекта вместе с заказчиком. Обе стороны должны согласовать результаты подобных анализов. Проверку проекта на соответствующих этапах ЖЦ ПС надо проводить, чтобы удостовериться, что выходные данные на этих этапах соответствуют входным требованиям.
В проверку проекта могут входить: анализ выходных проектных данных; демонстрации прототипов и моделей, а также результатов их тестирования. Эти проверки следует проводить согласно документированным процедурам и планам. Перед тем, как предложить продукт потребителю на испытания и приемку, поставщик должен оценить его качество согласно назначению и спецификациям требований, например, на этапе окончательного внутреннего контроля и испытаний разработчиком. При разработке программного средства важно, чтобы результаты оценки и любые последующие действия, необходимые для выполнения заданных требований, были зафиксированы и проверены по завершении этих работ.
7.3. Планирование процессов управления качеством сложных программных средств
При проектировании ПС, планирование процессов управления качеством ПС целесообразно отделять от непосредственного планирования и управления процессами создания и совершенствования крупных комплексов программ. Это позволяет сосредоточить внимание выделенных специалистов на совокупности мероприятий, гарантирующих качество конечного продукта. Чтобы такие гарантии достигались при минимальных затратах, необходимы целенаправленное, координируемое планирование и управление для предотвращения ошибок проектирования, а также для выявления и устранения дефектов проекта на самых ранних этапах разработки. Поэтому мероприятия планирования, обеспечивающие качество программ, должны охватывать не только завершающие испытания, но и весь жизненный цикл ПС.
Соответственно должны выделяться и применяться методы и средства автоматизации процессов планирования и управления качеством по этапам разработки компонентов и ПС в условиях реальных ограниченных ресурсов. Следует учитывать глубокую взаимосвязь плана управления и применения процедур обеспечения качества ПС с планом управления непосредственной разработкой программ, с процессами тестирования, испытаний и сертификации ПС. Эта связь выражается в аналогичном поэтапном представлении планов и в наличии в них значительной части близких по содержанию процессов и документов. При планировании процессов обеспечения качества ПС, целесообразно учитывать и использовать совокупность рекомендаций ряда стандартов, в которые входят ISO 10005, ISO 10006, ISO 10013, поддерживающие базовые стандарты менеджмента качества серии ISO 9000 (см. лекцию 3).
В соответствии со стандартами процедуры управления качеством должны применяться к различным документам и данным, включая: контрактные документы; процедурные документы, описывающие процессы системы качества; состояние работ поставщика-разработчика; взаимодействие поставщика и заказчика; документы и данные, которые описывают конкретный программный продукт. В составе документов должны содержаться методики, инструкции и описания по использованию конкретных инструментальных средств и выполнению частных работ и операций в ЖЦ ПС. Для этого в общем случае должны быть выделены руководители и коллектив специалистов, которые должны планировать, создавать, утверждать и сопровождать комплекты документов. Они должны стимулировать разработчиков ПС осуществлять непрерывное, регламентированное документирование процессов и результатов своей деятельности, а также контролировать полноту и качество результирующих и отчетных документов. Стандарты и базовые нормативные документы ЖЦ ПС должны служить верхним уровнем иерархической системы технологических документов, регламентирующих и конкретизирующих все этапы, работы и документы проекта.
Организационной основой управления качеством ПС на базе стандартов ЖЦ является план обеспечения заданных характеристик качества на всех этапах жизненного цикла комплекса программ (см. лекцию 11). Для этого до начала разработки в процессе формирования требований технического задания следует сформулировать основные положения методики обеспечения качества, поэтапных испытаний компонентов и определения достигнутых значений характеристик, допустимых для продолжения работ на следующих этапах. Такой план целесообразно создавать для сложных проектов ПС на этапах системного анализа, разработки требований технического задания и проектирования. На этих этапах оформляются первичные требования к характеристикам и качеству ПС и, соответственно, должна планироваться совокупность мероприятий, обеспечивающих их достижение в процессе последующего проектирования. В плане управления качеством ПС должны быть отражены:
Реальные ограничения ресурсов, используемых в процессе разработки, квалификация специалистов, изменения внешней среды и требований заказчика объективно приводят к отклонениям процессов и реализации плана от предполагавшегося. Величина таких отклонений в значительной степени зависит от принятой технологии разработки, от уровня и характеристик средств автоматизации создания программ. Для своевременного обнаружения отклонений от плана необходимо регулярно регистрировать результаты выполненных работ и их качество. Для реализации таких изменений целесообразно предусмотреть и согласовать с заказчиком специальный документ, регламентирующий правила корректировки плана обеспечения качества ПС, а также состав и содержание поддерживающей его документации. Подобные изменения должны оформляться протоколами и доводиться до сведения всех специалистов, к которым они относятся.
Одна из трудностей достижения высокого качества ПС состоит обычно в отсутствии полной совокупности достоверных требований к значениям характеристик качества на начальных этапах проектирования и разработки, а также итерационный процесс их конкретизации в течение всего жизненного цикла ПС. В результате первично сформулированные требования к характеристикам качества сложных ПС, последовательно уточняются и корректируются в процессе взаимодействия заказчика и разработчика с учетом объективно изменяющихся особенностей развивающегося проекта ПС. Для этого необходимо контролировать требуемые характеристики в процессе разработки, анализировать их адекватность целям проекта и управлять их изменениями в нужном направлении. Активное взаимодействие разработчиков с заказчиком или потенциальными пользователями на всех этапах разработки позволяет уточнять, корректировать и детализировать совокупность спецификаций требований и атрибуты качества в соответствии с развитием концепции и возрастанием понимания задач проекта, как заказчиком, так и разработчиком.
Управление качеством комплексов программ предполагает формализацию технологии обеспечения их жизненного цикла, а также выделение в специальный процесс поэтапное измерение и анализ текущего качества программных компонентов и проекта в целом. В общем случае в процессе планирования и управления качеством ПС следует учитывать:
декомпозицию требований к характеристикам качества по контролируемым этапам и компонентам разработки и создание разделов по детальным требованиям к атрибутам качества в спецификациях на программные компоненты и ПС в целом;
выбор или создание методов, технологии и инструментальных средств автоматизации разработки, обеспечивающих создание ПС и его компонентов с требуемыми характеристиками качества;
разработку методик контроля соблюдения стандартов, правил технологии проектирования и системы обеспечения качества жизненного цикла программных средств;
создание методов, методик и средств объективного измерения свойств и/или значений атрибутов характеристик качества программных компонентов на этапах их создания и всего ЖЦ ПС для испытаний заказчиком и эксплуатации пользователями;
организацию, обучение и стимулирование коллектива специалистов на создание компонентов и ПС в целом, в максимальной степени удовлетворяющих требования заказчиков и пользователей к характеристикам качества.
Чтобы решать эти задачи, коллективы специалистов в процессе планирования проекта, должны играть активную роль и осуществлять их выполнение для обеспечения качества на последующих этапах жизненного цикла. Они должны действовать в соответствии с полномочиями, ответственностью и независимостью, чтобы гарантировать удовлетворение целей и требований к качеству ПС. Качество объектов формируется и документируется при выполнении частных работ каждого этапа ЖЦ и окончательно удостоверяется при их завершении. Измерения объектов разработки сводятся к регулярной, поэтапной регистрации и документированию характерных для данного объекта показателей качества, а также к сопоставлению их с заданными требованиями.
В стандарте ISO 15504 (раздел MAN.3) процесс планирования и управления качеством ПС концентрируется на мониторинге качества продуктов и процессов, как проекта, так и предприятия в целом. В результате успешной реализации процессов в проекте должно быть обеспечено:
Утверждение и выпуск документации о качестве должны планироваться и контролироваться уполномоченным персоналом на предмет их адекватности. Следует планировать и поддерживать в актуальном состоянии процедуры управления документами, которые идентифицируют текущий статус корректировки и пересмотра документов, с тем, чтобы предотвратить использование недействующих и/или устаревших документов:
Изменения документов должны планироваться и утверждаться теми же службами и/или организациями, которые проводили первоначальный анализ и утверждали эту документацию. Архивные данные по проекту являются основным источником для анализа и осмысления возможностей и эффективности процесса планирования в организации, рабочих характеристик данного проекта и обобщения полученного опыта. Эти архивные данные, образующие общую базу данных предприятия, следует постоянно использовать для усовершенствования процессов жизненного цикла ПС. Та же самая база данных должна обеспечивать реализацию процесса управления по отдельным программным проектам.