Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

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

Предисловие книга (1)

Главная > Книга
Сохрани ссылку в одной из сетей:

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

Типы планов

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

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

Формальные планы

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

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

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

Неформальные планы

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

В соответствии с документированной процедурой

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

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

Отнесенные к ПО системные требования

Установленные для ПО системные требования обычно называются в СММ «установленными требованиями». Они представляют собой подгруппу системных требований, которые необходимо реализовать в программных компонентах системы. Установленные требования являются исходными данными для плана разработки ПО. Анализ требований к ПО позволяет уточнить и документировать установленные требования.

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

Отношения типа «поставщик – заказчик»

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

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

Отслеживание процесса разработки ПО с принятием корректирующих мер в сравнении с управлением ходом работ

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

Контроль в сравнении с экспертной оценкой

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

Помещение в систему управления конфигурацией в сравнении с управлением и контролем

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

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

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

7.2.4. Измерения и анализ

Ключевые практики раздела «Измерения и анализ» описывают основные методы измерений, необходимых для определения статуса операций, относящихся к разделу «Выполняемые действия». Являясь неотъемлемой частью группы ключевых процессов, измерения приводятся сразу после раздела «Выполняемые действия».

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

7.2.5. Проверка внедрения

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

Регулярный надзор со стороны высшего руководства

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

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

Регулярный и событийный надзор со стороны руководства проекта

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

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

Действия по обеспечению качества ПО

Определенные действия по проводимым группой обеспечения качества (SQA – software quality assurance) проверкам и/или аудиту описываются в виде ключевой практики. В некоторых случаях контрольные мероприятия по обеспечению качества не описываются – примерами могут служить группы ключевых процессов «Программа обучения» и «Межгрупповая координация». Эти группы ключевых процессов находятся на границе сфер компетенции организации и отдельного проекта разработки и не попадают в предполагаемую область полномочий группы обеспечения качества.

7.3. Интерпретация определения производственного процесса

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

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

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

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

7.3.1. Концепции определения процесса

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

    требования, определяющие описываемый процесс;

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

    реализация спроектированного процесса в условиях отдельного проекта или в рамках всей организации;

    проверка описания процесса с помощью измерений;

    развертывание процесса в организации или проекте, для которых разрабатывался данный процесс.

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

Дополнительную информацию о концепциях определения процесса, разработанных внутри сообщества проектировщиков процессов, можно найти в статье «Software Process Development and Enactment: Concepts and Definitions» («Разработка и нормативы производственного процесса: концепции и определения»), [Фейлер, 92].

Рис. 7.1. Концептуальная структура производственного процесса, используемая в CMM

7.3.2. Концепции, касающиеся основных средств производственного процесса организации

Основные средства производственного процесса организации (ППО)

Организация устанавливает и сопровождает набор основных средств производственного процесса, как показано на рис. 4.1. К этим основным средствам относятся:

  •     СППО (включая элементы и архитектуру производственного процесса);

  •     утвержденные описания жизненных циклов ПО;

  •     инструкции и критерии для адаптации СППО;

  •     база данных ППО;

  •     библиотека документации по производственным процессам. Эти основные средства используются для разработки, сопровождения и внедрения производственных процессов, определенных для проектов.

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

Стандартный производственный процесс организации (СППО)

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

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

Отношения между элементами производственного процесса иногда называются «архитектурой производственного процесса».

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

Архитектура производственного процесса

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

Элемент производственного процесса

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

Утвержденное описание жизненных циклов ПО

Жизненный цикл программного обеспечения представляет собой период времени, который начинается с рождения программного продукта и завершается, когда этот продукт более не используется, включает в себя следующие стадии: разработка концепции, формулирование требований, проектирование, реализация, тестирование, установка и отладка, эксплуатация и сопровождение, иногда – вывод из эксплуатации [стандарт IEEE-STD-610].

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

Инструкции и критерии адаптации

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

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

База данных производственного процесса организации

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

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

Библиотека документации по производственному процессу

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

7.3.3. Концепции, связанные с производственным процессом проекта

Описание производственного процесса проекта

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

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

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

Стадии

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

Задачи

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

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

Операции

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

Промежуточные программные продукты (результаты проекта)


Скачать документ

Похожие документы:

  1. Предисловие книга (2)

    Книга
    Автор и составитель архива: ЧЕРНОБРОВ Вадим АлександровичПо состоянию на 2.09.2002."ХРОНИКИ ВИЗИТОВ НЛО"ПРЕДИСЛОВИЕКнига, в которой впервые раскрываются советские и российские архивы наблюдений НЛО.
  2. В. Х. Кандинского Л. Л. Рохлин предисловие книга

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

    Книга
    Книга «Теория и практика перевода с английского языка на русский» рассчитана на студентов языковых институтов, филоло­гических факультетов и курсов иностранных языков.
  4. Необходимое предисловие книга

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

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

Другие похожие документы..