Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

Введение

Информация (от лат. informatio, разъяснение, изложение, осведомлен-ность) -- сведения о чём-либо, независимо от формы их представления.

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

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

1. Распространение информации: Краткая информация

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

1.1 Метод коммуникаций и метод распространение информации

Методы коммуникаций

Метод распространение информации

Эффективное распространение информации включает в себя ряд методов, в том числе:

* модели «отправитель-получатель». Петли обратной связи и барьеры коммуникаций.

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

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

* методы ведения собраний. Подготовка повестки дня и разрешение конфликтов.

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

*методы организации групповой работы. Достижение консенсуса и преодоление препятствий.

1.2 Способ распространения информации

*электронные средства общения и проведения конференций (например, электронная почта, факс, голосовая почта, телефон, видеоконфереции и интернет-конференции, веб-сайты и Интернет-публикации); и

ь Электро м нная по м чта (англ. email, e-mail, от англ. electronic mail) -- технология и предоставляемые ею услуги по пересылке и получению электронных сообщений (называемых «письма» или «электронные письма») по распределённой (в том числе глобальной) компьютерной сети. Электронная почта по составу элементов и принципу работы практически повторяет систему обычной (бумажной) почты, заимствуя как термины (почта, письмо, конверт, вложение, ящик, доставка и другие), так и характерные особенности -- простоту использования, задержки передачи сообщений, достаточную надёжность и в то же время отсутствие гарантии доставки.

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

Факсимильная связь включает в себя основные операции:

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

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

· трансляция сигнала по линии связи;

· преобразование полученного сигнала, как правило, синхронное и синфазное процессу передачи, запись в приёмном устройстве полученной информации.

· Возможность для абонента телефонной сети оставить адресату голосовое сообщение, которое тот сможет прослушать позже.

· Возможность прослушать по телефону хранящиеся на сервере электронной почты сообщения, читаемые роботом.

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

Прослушивание сообщений абонентом производится с телефонного аппарата при звонке на определенный телефонный номер.

Некоторые системные телефонные аппараты имеют индикатор (лампочку), информирующую о появлении новых сообщений в почтовом ящике.

· плату расширения офисной АТС (такие платы выпускают производители офисных АТС)

· самостоятельное устройство для настольной установки (выпускаются массой сторонних производителей, используется компаниями малого и среднего бизнеса)

· функционально законченный блок для установки в 19" стойку (также выпускается сторонними производителями, используется на крупных и средних предприятиях)

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

Телефо м н (др.-греч. ф?ле «далеко» и цщнЮ «голос», «звук») -- устройство для передачи и приёма звука на расстоянии. Современные телефоны осуществляют передачу посредством электрических сигналов. В целом, телефон -- это любое устройство, способное передавать звук на большое расстояние. Самые первые телефоны были механическими приборами, которые базировались на распространении звука в сплошных средах (воздух и др.), в отличие от электрических приборов, использующих электромагнитные сигналы.

Согласно письму в «Peking Gazette», в 968 году китайский изобретатель Кунг-фу-винг создал thumtsein, который, вероятно, передавал звук через трубы. Разговоры через трубы используются и сегодня при передаче звука на небольшие расстояния между фиксированными точками (на судах, предприятиях и т. д.).

«Верёвочный телефон» также известен много веков. В нём две мембраны соединялись бечёвкой или проволокой.

2 Распространение информации: по стандарту PMBoK

2.1 Распространение информации: входы

План управления проектом

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

В плане управления коммуникациями обычно указывается следующее:

*требования заинтересованных сторон проекта к коммуникациям;

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

*причина распространения данной информации;

*сроки и периодичность распространения требуемой информации;

*лицо, отвечающее за передачу информации;

*лицо, выдающее разрешение на раскрытие конфиденциальной информации;

*лицо или группы лиц, которые будут получать информацию;

*методы или технологии, используемые для передачи информации (например, служебные записки, сообщения по электронной почте и/или пресс-релизы);

*ресурсы, выделенные на коммуникационные действия, включая время и бюджет;

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

*метод обновления и уточнения плана управления коммуникациями по мере продвижения и развития проекта;

*глоссарий общепринятой терминологии;

*блок-схемы информации проекта, работ по проекту с указанием возможной последовательности разрешений, списка отчетов, планов совещаний и т. д.; и

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

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

Отчеты об исполнении

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

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

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

Активы процессов организации

Активы процессов организации, которые могут оказывать влияние на процесс распространения информации, включают в себя, среди прочего:

*правила, процедуры и руководящие указания относительно распространения информации;

*шаблоны; и

*историческую информацию и накопленные знания.

2.2 Распространение информации: инструменты и методы

Методы коммуникаций

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

Инструменты распространения информации

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

*распространение печатной документации, регистрационные картотеки, пресс-релизы и электронные базы данных с общим доступом;

*электронные средства общения и проведения конференций (например, электронная почта, факс, голосовая почта, телефон, видео- и Интернет-конференции, веб-сайты и Интернет-публикации); и

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

2.3 Распространение информации: выходы

Обновления активов процессов организации

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

* извещения заинтересованных сторон проекта. Заинтересованным сторонам проекта может предоставляться информация о решенных проблемах, одобренных изменениях и общем состоянии проекта.

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

* представление проекта. Команда проекта формально или неформально предоставляет информацию некоторым или всем заинтересованным сторонам проекта. Информация и метод представления должны соответствовать потребностям аудитории.

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

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

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

Заключение

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

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

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

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

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

С писок литературы

1. «Основы менеджмента». М. Мескон, М. Альберт, Ф. Хедоури. Copyright © 1988 by Harper & Row, Publishers, Inc. © Перевод на русский язык, вступительная статья, оформление Издательство «Дело», 1992

2. http://pm-in-ua.com/

3. http://pm-in-ua.com/content/category/12/38/147/

4. Руководство к своду знаний по управлению проектами (Четвертое издание). Стандарт PMBoK.

Размещено на Allbest.ru

Подобные документы

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

реферат , добавлен 09.11.2011


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

реферат , добавлен 17.08.2009


Составление проекта по методологии Oracle (комплекс методологий "Oracle Method") и по стандарту PMBOK (Project Management Body of Knowledge). Сравнение проектов, выявление их достоинств и недостатков, преимущественные сферы использования каждого.

контрольная работа , добавлен 28.05.2014


История развития и основные средства внутренних организационных коммуникаций и способов распространения информации. Средства передачи и получения управленческой информации. Обзор и анализ практики внутренних коммуникаций в США, Великобритании и Франции.

реферат , добавлен 21.11.2010


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

реферат , добавлен 10.06.2010


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

контрольная работа , добавлен 24.01.2012


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

практическая работа , добавлен 06.03.2008


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

курсовая работа , добавлен 16.09.2015


Структура базы данных системы управления проектами (БД СУП). Пользовательский интерфейс (представление информации о проекте, панели инструментов). Настройка интерфейса (таблиц, форм). Состав компонентов, назначение шаблонов проектов Micrisoft Progect.

контрольная работа , добавлен 27.05.2008


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

Управление конфигурацией

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

Управление конфигурацией (УК – Configuration Management) – управленческая технология, связанная с разработкой, выпуском и поддержкой ЖЦ сложных изделий, производимых во многих вариантах, в том числе – по конкретным требованиям заказчика.

При электронном проектировании средствами систем CAE/CAD/CAM должны использоваться и электронные средства управления конфигурацией, отвечающие, в частности, требованиям стандарта ИСО 10303-203.

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

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

Технология УК призвана решать противоречивые по своей сути задачи: с одной стороны, обеспечивать максимальное удовлетворение требований заказчика к изделию в течение всего ЖЦ, а с другой – обеспечивать максимально возможный в этих условиях уровень унификации компонентов выпускаемых изделий. УК актуально также тогда, когда на основе некоторой базовой модели (конструкции) изделия создаются его различные модификации.

Эта технология предполагает выполнение следующих операций (по ИСО 10007):

· идентификацию конфигурации, т. е. присвоение ее текущей версии определенного «имени» (кодового обозначения);

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

· учет статуса конфигурации;

· проверку (аудит) конфигурации.

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

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

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

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

Документация конфигурации (ДК, configuration documentation – CD): документация, позволяющая определить и идентифицировать функциональные, физические и эксплуатационные характеристики изделия. В качестве документации конфигурации (ДК) принято рассматривать технические требования (условия), чертежи изделия или электронные данные аналогичного назначения.

Базовая конфигурация (baseline): утвержденная в установленном порядке документация конфигурации.

Концепция изделия (КИ, Product Concept – PC): понятие, описывающее класс подобных изделий, которые предприятие предлагает заказчикам. КИ – идея изделия, отвечающая заданному набору технических требований (Specification), требованиям заказчиков («Облик изделия» или «Лицо изделия»). С точки зрения заказчика концепция изделия представляет обозначение формализованного набора требований (Specification), отражающих потребности заказчика. С точки зрения производителя концепция изделия – это обозначение семейства модификаций изделия, поставляемых на рынок.

В стандарте ИСО 10303, спецификации SPS и модели NPDM понятию объект управления конфигурацией (Объект конфигурации (ОК) – Configuration Item – CI) соответствует любое техническое или программное средство (или их комбинация), выполняющее конечную функцию (или некоторую функцию конечного изделия), выделенное для целей управления конфигурацией и обладающее определенным набором свойств (характеристик). Один объект конфигурации может входить в другой и, в свою очередь, включать в себя другие объекты конфигурации. Конфигурация в целом и составляющие ее ОК могут быть соответствующим образом документированы и утверждены. ОК обычно обозначают уникальным буквенно-цифровым идентификатором (кодом), который используется также в качестве неизменяемой части для серийных номеров и уникальной идентификации отдельных компонентов (блоков) этого ОК.

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

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

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

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

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

· формализацию требований;

· структурирование требований;

· проверку требований на выполнимость и непротиворечивость;

· управление изменениями в требованиях.

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

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

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

Что такое конфигурационное управление

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

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

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

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

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

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

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

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

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

Так что же такое SCM? Наиболее простое и в то же время достаточно полное определение того, что такое конфигурационное управление, содержится в документации к PVCS.

“Конфигурационное управление, - считает фирма Intersolv (разработчик PVCS), - это организация изменений и управления изменением компонентов в процессе разработки программного обеспечения”.

Это некоторая сквозная деятельность (активность, “вспомогательный процесс” в терминологии стандарта ISO 12207-1), выполняемая в течение всего производственного процесса. Определение не учитывает конфигурационного управления на этапе поддержки информационной системы, но оно вполне достаточно для выявления характерных черт SCM.

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

Проблема автоматизации конфигурационного управления

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

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

Стандарт IEEE Std-828 и заменивший его IEEE Std-1042;

Стандарт ANSI, основанный на IEEE Std-828.

Стандарт ISO 12207, основанный на IEEE Std-828.

На основании упомянутых (или иных - например, корпоративных) стандартов для каждого проекта разрабатываются документы, содержащие в себе методику конфигурационного управления. Эти стандарты и методики учитывают сложный характер современной групповой разработки программных проектов. В SCMP (SoftWare Configuration Management Plan) детально расписываются все действия, обязанности и ответственность участников проекта по отношению к SCM.

Действующие в России стандарты (19-я и 34-я серии ГОСТов) не содержат предписаний, касающихся конфигурационного управления, хотя советская программная инженерия выработала оригинальные подходы - достаточно упомянуть сборочное программирование, представляющее собой систему как проектирования, так и конфигурационного управления. В отсутствие национальных стандартов должны применяться стандарты международные, в частности, по отношению к конфигурационному управлению документом прямого действия является ISO 12207-2.

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

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

Это разделение процесса разработки на “действия” (терминология ISO 12207-1), соответствующее этапам жизненного цикла, дополняется распределением задач по отдельным исполнителям и группам. Разнообразие действий, задач и исполнителей образует среду современной организации разработки.

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

Ниже мы будем рассматривать почти исключительно PVCS. Средства PVCS очень широко распространены и фактически стали стандартом в области конфигурационного управления. Мне даже приходилось слышать, как SourceSafe (средство версионного хранения фирмы Microsoft) называли PVCS’ом.

ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПО И КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ

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

Куда вносятся изменения?

Кто вносит изменения?

Какова процедура внесения изменений?

Как процедура внесения изменений связана с объектом изменения, этапом разработки, лицом, вносящим изменения?

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

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

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

Проектирование (на этом этапе создается и/или изменяется представление о создаваемой программной системе в виде тех или иных методик проектирования; также на этапе детального проектирования (дизайна) могут создаваться первоначальные версии исходных текстов;

Кодирование (на этом этапе создаются и изменяются исходные тексты, а также исполняемые, т. е. коды, непосредственно используемые для исполнения машиной [если они отличны от исходных кодов]);

Тестирование (на этом этапе создаются тестовые процедуры, включая тестовые данные, а также результаты их выполнения);

Сопровождение (на этом этапе изменения как таковые не вносятся [внесение изменений здесь можно рассматривать как кратковременный откат к предшествующим этапам], основной рассматриваемый объект - выпускаемые версии).

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

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

Изменения. На каждом этапе жизненного цикла могут возникать запросы на изменения. Обычно считается, что эти запросы не формализуются в отношении тех объектов, которые массово изменяются на этом этапе (за одним исключением, которое будет описано в разделе “Метрики и управление проектом”). Так, изменения в исходном коде на этапе кодирования будут вноситься непосредственно. Если же на этапе кодирования возникнет запрос на изменение в дизайне, то этот запрос оформляется принятой процедурой регистрации и прохождения изменения.

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

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

Организация хранения объектов конфигурационного управления - один из важнейших вопросов конфигурационного управления. Исторически именно его решали методики конфигурационного управления. Ядром большинства средств SCM являются средства хранения версий.

Георгий Серяков

(Окончание следует)

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

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

Конфигурационная единица (Configuration Item или CI) - любой компонент , который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение , здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг ( SLA ).

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

• СI жизненного цикла - бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза.
• CI услуг:
  • возможности услуг - управление, организация, процессы, знания, люди;
  • ресурсы услуг - капитал, системы, приложения, информация, данные, инфраструктуры и т.п.;
  • модель услуг;
  • пакет услуг;
  • пакет релизов;
  • критерии приемки услуг.
• CI организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации;
• внутренние СI - материальные и нематериальные активы, которые необходимы для предоставления и управления услугами;
• внешние CI - требования заказчиков, соглашения, релизы поставщиков и внешние услуги;
• CI интерфейсов - активы, необходимые для предоставления услуг "от начала до конца" в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами.

Рассмотрим подробнее деятельности, представленные на рис. 8.4 .

Управление и планирование

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

Идентификация конфигураций

Для идентификации конфигураций важно:

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

Деятельность в рамках идентификации конфигураций включает в себя:

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

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

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

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

• уникальный идентификатор;
• тип CI;
• имя/описание;
• версия;
• расположение;
• дата поставки;
• детали лицензии (в частности, дата ее истечения);
• владелец/куратор;
• статус;
• поставщик/источник;
• документация;
• данные истории, например, аудиторские отчеты;
• тип связей;
• соответствующий SLA.

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

Основные связи между CI:

• CI является частью другой CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок";
• CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью;
• CI использует другой CI. Например, программа использует модуль другой программы;
• CI установлена на другую CI, например, Microsoft Excel на персональный компьютер.

CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI.

Контроль конфигураций

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

• лицензионный контроль - проверяет количество людей, которые используют лицензионный продукт, следит за тем, чтобы в организации не использовались нелицензионные продукты, следит за сроками истечения лицензий и т.п.;
• управление изменениями;
• контроль версий активов, программного и аппаратного обеспечения, релизов, сборок и т.п.;
• контроль активов - возможности, место хранения, CMS;
• контроль сборки с использованием документации от CMS;
• поддержка и миграция электронных данных и информации;
• формирование базы активов и конфигурационных единиц перед релизом;
• контроль развертывания;
• инсталляция;
• управление целостностью Библиотеки эталонного ПО. Библиотека эталонного ПО (Definitive Media Library (DML) - одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе управления конфигурациями. В релизе может быть использовано только программное обеспечение из DML[

Аннотация: Понятие конфигурационного управления. Управление версиями. Понятие "ветки" проекта. Управление сборками. Средства версионного контроля. Единицы конфигурационного управления. Понятие baseline.

Проблема

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

Рассмотрим теперь проект по разработке программного обеспечения . Что в нем является аналогом материальных активов на обычном производстве? Определенно, не столы и стулья, которыми пользуются разработчики. И даже не компьютеры, запчасти к ним и прочее оборудование. Учета и контроля, сродни складскому, требуют файлы проекта. В программном проекте их очень много – сотни и тысячи даже для относительно небольших проектов. Ведь создать новый файл очень легко. Многие технологии программирования поддерживают стиль, когда, например, для каждого класса создается свой отдельный файл.

Файл – это виртуальная информационная единица. В чем главное отличие файла от материальных единиц учета? В том, что у файла может быть версия , и не одна, и породить эти версии очень легко – достаточно скопировать данный файл в другое место на диске. В то время как материальные предметы существуют на складе сами по себе, и для них нет понятия версии. Да, может быть несколько однотипных предметов, разных заготовок изделия различной степени готовности. Но все это не то….. А версия файла – это очень непростой объект. Чем одна версия отличается от другой? Несколькими строчками текста или полностью обновленным содержанием? И какая из двух и более версий главнее, лучше? К этому добавляется еще и то, что многие рабочие продукты могут состоять из набора файлов, и каждый из них может иметь по несколько версий. Как собрать корректную версию продукта ?

В итоге в программном проекте начинают происходить мистические и загадочные события.

• Тщательно оттестированная программа на показательных испытаниях не работает
• Функциональность, о которой долго просил заказчик и которая была, наконец, добавлена в продукт, и новая версия торжественно отослана заказчику, таинственным образом исчезла из продукта.
• На компьютере разработчика программа работает, а у заказчика – нет….

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

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

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

Выделим две основные задачи в конфигурационном управлении – управление версиями и управление сборками . Первое отвечает за управление версиями файлов и выполняется в проекте на основе специальных программных пакетов – средств версионного контроля . Существует большое количество таких средств – Microsoft Visual SourceSafe, IBM ClearCase, cvn, subversion и др. Управление сборками – это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции , и интегрируемый с процессом автоматического тестирования . Эта процедура является мощным средством интеграции проекта, основой итеративной разработки.

Единицы конфигурационного управления

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

Итак, конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления ( configuration management items ). Вот примеры:

1. пользовательская документация;
2. проектная документация;
3. исходные тексты ПО;
4. пакеты тестов;
5. инсталляционные пакеты ПО;
6. тестовые отчеты .

У каждой единицы конфигурационного управления должно быть следующее.

1. Структура – набор файлов. Например, пользовательская документация в html должна включать индекс-файл и набор html -файлов, а также набор вынесенных картинок ( gif или jpeg -файлы). Эта структура должна быть хорошо определена и отслеживаться при конфигурационном управлении – что все файлы не потеряны и присутствуют, имеют одинаковую версию, корректные ссылки друг на друга и т.д.
2. Ответственное лицо и, возможно, группу тех, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией. Например, определенной программной компонентой могут в проекте пользоваться многие разработчики, но отвечать за ее разработку, исправление ошибок и пр. должен кто-то один.
3. Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые правила, связанные, например, с правилами изменения тестов и тестовых пакетов при изменении кода. Однако, где-то здесь лежит водораздел между конфигурационным управлением и иными видами деятельности в проекте
4. Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов.

Элементы конфигурационного управления могут образовывать иерархию . Пример представлен на рис. 6.1 .

Рис. 6.1.

Управление версиями

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

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

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

• V1.0 – ветвь, соответствующая выпущенному релизу . Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза.
• Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от основной ветви и замораживаются сразу после выхода пакета исправлений.
• Upcoming (V1.1) – ветвь, соответствующая релизу , готовящемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило, действуют более строгие правила и работа в них ведется более формально.
• Mainline – ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов.
• WCF Experiment – ветвь, созданная для проверки некоторого технического решения, перехода на новую технологию, или внесения большого пакета изменений, потенциально нарушающих работоспособность кода на длительное время. Такие ветви, как правило, делаются доступными только для определенного круга разработчиков и убиваются по завершению работ после интеграции с основной веткой.

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

Итак, почему же процедура компиляции и создания exe dll файлов по исходникам проекта – такая важная процедура? Потому что она многократно в день выполняется каждым разработчиком на его собственном компьютере, с его собственной версией проекта. При этом отличается:

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

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

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