• Оценка производительности и анализ технических рисков.

• Оценка альтернатив создания/покупки и изучение применимости коммерческих продуктов.

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

• Анализ рисков, связанных с переходом к полномасштабной реализации.

• Разработка сценариев тестирования и инструментов анализа требований.

2.

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

3.

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

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

1.

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

2.

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

3.

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

4.

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

12.2.1 «Круговая» разработка.

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

На рис. 12.2 изображены некоторые важные преобразования между репозиториями. Автоматизированная трансляция проектных моделей в исходный код {как при прямом, так и при обратном проектировании) определяется довольно четко. Автоматизированная трансляция проектных моделей в модели процесса (распределенной среды) также постепенно упрощается за счет использования таких технологий, как ActiveX и Common Object Request Broker Architecture (CORBA).

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

Рис. 12.2. «Круговая» разработка.

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

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

Трансляция данных из одного источника в другой не всегда может быть выполнена на 100%. Например, перевод проектных моделей в исходный текст на C++ может касаться только структурного и декларативного аспектов представления исходного кода. Компоненты кода по-прежнему должны быть наполнены спецификой атрибутов или методов конкретного объекта.

12.2.2 Управление изменениями.

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

Запросы на внесение изменений.

Наименьшая неделимая единица программистской работы, в результате которой производится создание, изменение или отказ от устаревших компонентов в рамках базовой конфигурации, называется запросом на внесение изменений в ПО (SCO, Software Change Order). Запросы на внесение изменений — один из главных механизмов распределения и.

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

Определение уровня, на котором следует писать SCO, всегда является проблемой. Что такое отдельное изменение? Является оно изменением модуля программы или компонента, файла или подсистемы? Является ли оно новой возможностью, исправлением дефекта илй повышением производительности? Для большинства проектов неделимая единица измерения SCO принимается без особого труда. Вообще говоря, SCO должен быть написан для отдельного компонента, чтобы его выполнение можно было возложить на одного человека. Если исправления требуют труда двух человек из двух разных команд, необходимо писать два отдельных.

SCO.

Основными полями SCO являются название, описание, параметры, исправления, оценка и диспозиция.

■ Название. Название предлагается автором и окончательно утверждается советом по контролю за конфигурацией (ССВ, Configuration Control Board). В этом же поле должна содержаться ссылка на внешний отчет о проблеме, если это изменение было инициировано извне (например, пользователем).

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

■ Параметры. Параметры, собираемые по каждому запросу, важны для планирования, составления графика и оценки качества. Категория вносимых изменений может иметь тип 0 (критичная ошибка), 1 (ошибка), 2 (усовершенствование), 3 (новая возможность) и 4 (другое). При принятии запроса выполняются предварительные оценки дефектов в ПО и объема работ, необходимого для решения проблемы. Графа «Дефект» является количественным выражением объема требуемых изменений, «Переделка» дает количественное определение сложности вносимых изменений. По мере внесения исправлений фиксируется реальный объем дефектного ПО и уточняются реальные объемы работ, необходимые для переделок. В графе «Анализ» указывается число человеко-часов, затраченных на понимание требуемых изменений (воспроизведение проблемы, ее локализация и устранение, если тип изменений 0 или 1; анализ и создание прототипов альтернативных решений, если тип равен 2 или 3). Графа «Реализация» определяет количество человеко-часов, затраченных на проектирование и реализацию исправления. В графе «Тестирование» указывается количество часов, затраченных на тестирование исправлений, графа «Документация» определяет общий объем работ по обновлению других рабочих продуктов, таких как руководство пользователя или описание версии. Количество дефектного ПО задает глубину вносимых изменений и может выражаться в SLOC, функциональных точках, файлах, компонентах или классах. В случае выбора SLOC программа сравнения исходных файлов, которая выявляет количественные различия, может предоставить простую оценку объема дефектного ПО. Вообще говоря, точное значение числа дефектных строк не слишком важно. При изменении от 0 до 100 строк их количество следует округлять до ближайшего десятка, при изменении от 100 до 1000 строк — до ближайшей сотни и т.д.

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

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

■ Диспозиция. ССВ присваивает запросу одно из следующих значений статуса:.

• Предложен: запрос написан и ожидает рассмотрения ССВ.

• Принят: ССВ утвердил запрос.

• Отклонен: запрос закрыт с указанием причин — например, не является проблемой, повтор, устаревшие изменения, выполнено по другому запросу.

• На хранение: запрос принят, но отложен до более поздней версии.

• В работе: запрос передан, и по нему ведется активная работа в организации-разработчике.

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

• Закрыт: полностью выполнен, с чем согласны все члены ССВ.

ССВ может также присвоить приоритет и идентификатор версии для определения приоритетов и организации параллельной разработки.

Рис. 12.3. Элементарные составляющие, из которых состоит запрос на внесение изменений в ПО.

Базовая конфигурация.

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

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

В общем случае для большинства систем требуются три уровня базовых версий: основные, второстепенные и промежуточные. Каждому уровню соответствует число в идентификаторе вида N.M.X, где N — номер основной версии, М — номер второстепенной версии, а X — идентификатор промежуточной версии. Основная версия представляет собой новое поколение продукта или проекта, в то время как второстепенная версия — это тот же основной продукт, но с улучшенными возможностями, производительностью или качеством. Основные и второстепенные версии обычно являются внешними версиями продукта, которые остаются неизменными и поддерживаются в течение некоторого периода рремени. Промежуточная версия соответствует рабочей конфигурации, которую намереваются использовать как временную. Чем короче ее жизненный цикл, тем лучше. На рис. 12.4 показаны примеры историй некоторых версий для двух различных ситуаций.

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

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

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

Рис. 12.4. Примеры историй версий для типичного проекта и типичного продукта.

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

■ Тип 3: изменение, необходимость которого вызвана обновлением требований. Это могут быть новые свойства или функциональные возможности, находящиеся вне рамок текущей общей концепции и бизнес-плана.

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

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

Таблица 12.1.

Характерные примеры изменений для двух разных проектов

Совет по контролю за конфигурацией.

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

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

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

■ [Принят, на хранение, отклонен] ССВ присваивает уникальный идентификатор каждому предложенному изменению и либо.

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

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

ш [На оценке]. Независимая команда по тестированию оценивает, полностью ли выполнен запрос. Если это так, запрос передается в ССВ для окончательного закрытия.

■ [Закрыт]. Когда организация-разработчик, независимая тестирующая организация и ССВ соглашаются с тем, что запрос выполнен, он получает статус закрытого.

12.2.3 Различные виды инфраструктуры.

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

Организационная политика.

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

■ Что делается? (виды деятельности и рабочие продукты).

■ Когда это делается? (соответствие стадиям жизненного цикла и контрольным точкам).

■ Кем это делается? (распределение ролей и ответственности в команде).

■ Как убедиться в адекватности? (контрольные точки, параметры и стандарты).

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

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

■ Они облекают политику в реальные обязательства, а затем способствуют их выполнению.

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

■ Отказ от отдельных положений является не правилом, а исключением.

■ Соответствую щая политика пишется на соответствующем уровне.

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

■ Высший организационный уровень: стандарты, которые способствуют (1) стратегическим и долговременным улучшениям процесса, (2) использованию общей технологии и обучения, (3) сравнимости работы подразделения, осуществляющего проект, с работой подразделения, занимающегося бизнесом, и (4) обязательному контролю качества.

■ Средний уровень основной деятельности организации: стандарты, которые способствуют (1) тактическим и кратковременным улучшениям процесса, (2) внедрению и обучению специфической для данной области технологии, (3) повторному использованию компонентов, процессов, обучения, инструментов и опыта сотрудников и (4) соответствию стандартам, принятым в организации.

■ Низший уровень проекта: стандарты, которые способствуют (1) достижению поставленных целей по качеству, срокам и затратам, (2) специальному обучению для данного проекта, (3) соответствию требованиям заказчика и (4) соответствию стандартам, принятым в организации / подразделении.

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

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

I.

Определения элементарных составляющих процесса.

A.

Стадии жизненного цикла (начальная стадия,уточнение, конструирование, ввод в действие).

B.

Контрольные точки (основные и второстепенные, оценки состояния).

C.

Рабочие продукты (комплекты требований, проекта, реализации, внедрения, управления).

II.

Различные виды организационной политики в области создания ПО.

A.

Декомпозиция работ.

B.

План разработки ПО.

C.

Управление изменениями.

D.

Метрики ПО.

E.

Среда разработки.

F.

Критерии оценки и критерии приемки.

G.

Управление рисками.

H.

Тестирование и оценка.

III.

Политика отказа.

IV.

Приложения.

A.

Оценка текущего процесса.

B.

План усовершенствования процесса создания ПО.

Контуры организационной политики.

Организационная среда.

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

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

■ Стандартные нотации для рабочих продуктов, такие как UML для всех проектных моделей или Ada 95 для всех разрабатываемых на заказ критичных по надежности рабочих продуктов.

■ Дополнения к инструментам, например заранее разработанные или выполненные на заказ шаблоны (описание архитектуры, критерий оценки, описания версий, оценки состояния).

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

■ Другие компоненты организационной инфраструктуры, польза от которых является косвенной:.

• Библиотека ссылок на предшествующий опыт планирования, оценки и улучшения параметров процесса; ответы на вопросы «Насколькохорошо?», «Как много?», «Почему?».

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

• Библиотека примеров рабочих продуктов проекта, таких как планы разработки ПО, описания архитектуры и истории оценок состояния.

• Модели проведения аудита и способы сопоставления с внешними схемами оценки, такими как Software Engineering Institute’s Capability Maturity Model (SEI CMM).

12.2.4 Среда для других заинтересованных сторон.

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

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

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

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

■ Получать и использовать работающие продукты для выполнения оценок вручную.

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

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

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

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

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

■ Даже бумажные документы должны доставляться электронным способом для снижения стоимости продукции и времени оборота.

Рис. 12.6. Распространение среды на другие заинтересованные стороны.

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

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