Обсуждение

будучи софтверщиком небольшого масштаба прокомментирую пункт 3: контроль версий. В моём опыте разработок, системы контроля ревизий/версий (исходного кода) имели/имеют очень маленькое значение для менеджмента конфигурации и обеспечения целостности системы. Только в случае, когда команда поддерживает (развивает) несколько разных версий продукта параллельно, svn vs. git становится актуально -- потому что разные версии становятся разными ветками и система должна уметь объединять правки, сделанные в разных ветках. Ну и случай, когда надо исправить старую версию системы -- там тоже. А так контроль конфигурации в своём худом-бедном варианте технически поддерживается системой отслеживания задач (trac, fogbugz, bugzilla, etc.), ибо именно там задачи привязываются (должны привязываться) к утверждённым дизайнам (архитектурам), а дизайны -- к эскизам, а эскизы к требованиям (заинтересованных сторон). Часто эти базисы вообще не попадают в систему контроля ревизий, оставаясь в системе управления задачами.

Cложнее (тот же trac недаром задом плотно садится на SVN), плюс я не имею ввиду контроль конфиругации в случае, когда все разработчики сидят в одной комнате и нужно просто "средство письменной фиксации кто что кому сказал". При collaborative engineering и concurrent engineering много всякого быывает. Плюс в софте граница между рабочей документацией и системой в железе и бетоне чуть покруче будет, и более влияет на управление конфигурацией, нежели чем в софте. Так, софтовый вариант полёта на Марс можно пару раз отладочно повторить, а вот железный вариант -- денег не хватит, отсюда совсем другие требования к несовпадению версий...

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

Сорри, но куча у вас. "Управление изменениями" имеет много разных смыслов (словарных значений). Есть совершенно разные дисциплины "управления изменениями" в крупных проектах, особенно путаница с "управлением организационными изменениями". Заодно, замечу, есть абсолютно разные понимания и "управления конфигурацией", как дисциплины. Более того, в обсуждаемом вопросе этих "дисциплин" явно больше обсуждаемых двух, и они представляют довольно сложную мереологию. Так что не будем про путаницу. Я напрямую адресуюсь, например, к терминологии конкретных САПР (разделам документации и названиям поставляемых модулей). Я тут больше говорю про инженерию, а не "управление проектами". Не удивлюсь, если где-нибудь у мичуринцев будет термин "управление изменениями", и кто-нибудь приплетет к этому разговору и его значение, заявив, что я путаю инженерию и мичуринство...

1.Смысл - это не словарные значения, и не значения вообще. Смысл это одно, а значение - это другое, не смешивайте. 2. Мое замечание было направлено на одно: если пишете про управление конфигурацией системы, то не пишите про все подряд. Будьте более фокусированы. У тех, кто работает с информационными системами, под конфигурацией системы понимается настройка системы. Ваши: "идентификацию", "регламент учёта","версионирование", - это все для нас вторичные процедуры при настройке. Вы приводите формальные моменты, как главные, а они на 10 - месте.

А давайте вы сфокусируетесь? Мне ваши вторичные или первичные процедуры при вашей настройке неинтересны. Я тут про свои проекты пишу. Про смысл и значение -- это уже совсем метадискуссия пошла. Неужели вы думаете, что я с этой дискуссией не знаком? Еще раз: в чужой храм со своим словарём не ходят.

Вы, там, на своих проектах собираетесь "по фене ботать" или учитывать языки других людей, работающих в других проектах? Вам говорю, что управление конфигурацией и конфигурирование - это настройка системы с учетом морфологических особенностей среды ее работы узаказчика/пользователя. Т. е. задание конструкции системы, такой, какой ее видит заказчик/пользователь системы. Например, берется ненастроенная система (параметрическая структура системы) и в ней создается система классификации материалов и на ней задается справочник материалов заказчика/пользователя,задается план счетов и все счета в нем, задается справочник видов затрат и их перечень, задаются места возникновения затрат, задается перечень видов документов и диапазоны их нумерации и прочее, - вот эта работа и называется конфигурированием системы. А вы, о чем?

"Вы, там, на своих проектах собираетесь "по фене ботать" или учитывать языки других людей, работающих в других проектах?" -- это как раз мой вопрос вам. Конфигурирование системы в проектах типа "внедрение ERP-системы" и управление конфигурацией как дисциплина относятся друг ко другу примерно так же, как кресты металлические к крестам католическим. Поглядите хотя бы http://en.wikipedia.org/wiki/Configuration_management -- текст там по сути ужасный, но смысл более-менее понятен (особое внимание обратите на последний фрагмент текста, про construction industry).

увы, я до сих пор не понимаю, какую же роль средство отслеживания версий исходников помогает в обеспечении целостности системы и -- в частности -- в управлении конфигурацией. будьто маленький и чисто софтверный проект, или большой, где софт+железо в связке. Кроме одного сценария. Вы пишете: > обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается > из взаимно соответствующих версий частей системы (будь то версии проектной или > исполнительной документации, или же версии самой системы "в железе и бетоне") например, несколько групп работает над текстом спецификации (плюс, например, prototype implementation, для полноты примера) и у каждой -- своя ветка в том же git'е или svn'е, и как-только какой-то вариант победил (у заинтересованых сторон) и был утверждён, именно эта ветка вливается в основную версию и становится базисом, остальные игнорируются. Это вы имели в виду?

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

ок, спасибо.

Конфигурирование, оно и в "Африке" конфигурирование. Я же выступаю против навязывания ваших смыслов этому понятию, указывая, что нету их там. "Управление конфигурацией очень просто, когда есть один административный центр, который вводит а) обязательную идентификацию б) обязательный регламент учёта в) централизованное версионирование", - под это ваше понимание конфигурирования можно подвести очень многое: и управление проектами, и управление документооборотом, и управление задачами, и регламентацию, и учет. По содержанию вы не нговорите ничего про конфигурирование, все очень формально. Я вам и говорю, - сфокусируйтесь на содержании того, о чем говорите, не размазывайте. Используя ваше различение, я вам говорю, что не понятно про что вы говорите, то ли про кресты, то ли про кладбище, то ли про церковь. А различение крестов на такие и сякие - это следубщий шаг. Кстати, в определенном содержательном контексте крест католический может быть металлическим. Это в вашей формальной логике они не совместимы, я вам уже говорил об этом. Не строятся современные понятия только в формальной логике, в какие бы современные одежды она не рядилась.

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

Если вы системный инженер и работаете в системном подходе, то вы не можете говорить, что это вас не волнует "не волнуют эти "настройки коробочного софта"." (кстати, с чего вы взяли, что я занимаюсь им, SAP R/3, продукт коробочный?). Или, что это ваш устав и терминология только для ваших проектов. Системный инженер должен уметь работать со всеми инженерами и показывать место смысла понятия конфигурации, используемый "коробочными инженерами" в более широкой системе смыслов этого понятия. А, вы что делаете? Говорите, "пшли все в сад"?

Ага. За один раз я обсуждаю одну проблему, остальные идут в сад. За второй раз -- вторую проблему, остальные (включая первую) идут в сад. Separation of concerns, основной принцип. Ну, и работа с ситуациями -- чтобы разбираться со смыслами. Вне ситуаций обсуждения бессмыслены. Я хорошо понимаю, когда нужно будет разобраться одновременно с конфигурированием коробочного софта (sic!) типа SAP R/3 с его бесконечно долгой "настройкой", и с управлением конфигурацией какой-то программоёмкой системы. Но и тогда я предпочёл бы мух конфигурирования иметь отдельно, а управление конфигурацией рассматривать отдельно. Вы, например, разницу между управлением требованиями, управлением конфигурацией требований, инженерией требований представляете? Все слова похожи, а суть в них совершенно разная...

Как только вы обсуждая проблему кого то отправляете в сад, так сразу проблема превращается в задачу. Я не сторонник подхода, когда "нет человека - нет проблемы". Так уходят от проблем. А ситуация возникает, когда люди приходят из сада и возражают вам, как "системному инженеру", а иначе нет у вас никакой ситуации. Вы ее подгоняете под "решение проблемы". Если вы столкнетесь с людьми из реального проекта внедрения SAP R/3 (например на Росатоме) и они вас возьмут за одно место, тогда и продолжим разговор о конфигурировании систем, может быть. Я, когда говорю о конфигурировании, говорю о конфигурировании системы, которое невозможно осуществлять вне управления этим конфигурированием. И все ваши термины "управлением требованиями, управлением конфигурацией требований, инженерией требований", - они внутри понятия конфигурирования системы.

Жду с нетерпением, когда встречусь с людьми из реального проекта внедрения SAP R/3. Много лет моей консалтинговой практики такие встречи меня только разочаровывали (в отличие от встреч с людьми, конфигурирующими системы С1). Но дело не в этом. Ситуация с вашим пониманием конфигурирования -- это ваша ситуация, не моя. У меня задача архитектурная, которая задолго до "конфигурирования" возникает. В момент определения архитектуры системы еще нет никакого "конфигурирования", ибо непонятно какую систему конфигурировать. Но уже нужно думать о разных вопросах, например об управлении конфигурацией. Да, систему SAP R/3 можно приспособить для управления конфигурацией, а также управлять конфигурацией этой системы. Но ваше "управление конфигурированием" это совсем другое, нежели обсуждаемое мной "управлени конфигурацией". Вас интересуют другие проблемы (конфигурирование, SAP R/3), я их в этом постинге не обсуждаю. Конечно, я ухожу от ваших проблем. Я предпочитаю в эти проблемы не вляпываться, у меня ведь и других проблем хватает.

1. Не надо ждать, вы же не девушка на выданье. Ищите сами, идите в эти реальные проекты и попробуйте там поработать на ваших понятиях конфигурирования и архитектурирования, например. И проблем не бывает моих и ваших, они общие, иначе это не проблемы. 2. Согласен, что мое понимание и ваше понимание – это два разных понимания, и что? Ведь, понятие на то и нужно, чтобы вбирать в себя все понимания и объяснять их, и не важно, что эти понимания формировались при решении разных задач. Важно же вычленить ту проблему, которая разбита на эти задачи. Я вижу и обсуждаю проблему конфигурирования системы. А вы, какую? 3. В нашем разговоре нас сбивает слово система, понятие за ним стоящее и система как «объект», с которыми мы имеем дело в реальности. Я же согласен, что с разных позиций системой называется разное: вы, как архитектор системы видите ее по своему, я как настройщик/внедренец вижу ее по своему. Вот смотрите, как у вас используется здесь слово система «В момент определения архитектуры системы еще нет никакого "конфигурирования", ибо непонятно какую систему конфигурировать.». Первый раз система как бы есть, а во второй раз ее как бы нет. Конечно, встает вопрос: для кого она есть, а для кого ее нет. И встает другой вопрос существования системы: на каком материале, на каких материалах она существует в тот или иной момент. Например, если система существует в материале знаков, то ее можно сконфигурировать? Или под конфигурированием понимается работа, когда идет настройка параметров системы на определенном проекте под определенные требования пользователей на конкретных рабочих местах? Что мы называем системой, когда говорим о ее архитектуре и ее конфигурации? Система в нашей мысли, нашем мышлении – это система? Или системой будет только то, когда ее из мышления переведут в знаки, например в чертежи (схемы, модели). Или системой будет только то, что уже будет переведено в программный код компьютерной программы? В какой момент система обретает архитектуру и конфигурацию? Вы о существовании какой системы говорите? Почему «В момент определения архитектуры системы еще нет..»? Для кого нет, для архитектора или для конфигуратора? И где ее нет? В каком материале ее нет? 4. И потом, ответ на вопрос, что есть, а чего нет, зависит от того как вы движетесь или с чего начинаете. Если вы создаете систему «с нуля», то это одна логика движения. А если вы переделываете уже существующую систему, у которой «есть и конфигурация и архитектура», а вы хотите их поменять на другие, то это другая логика и ситуация. В ситуации реинжиниринга или реорганизации системы архитектор работает с учетом имеющейся уже конфигурации и свою новую архитектуру он не может построить любой, у него есть ограничение от конфигурации и от того, что ему говорит конфигуратор. Если вы при нашем разговоре мысленно имеете ввиду виртуальные системы «живущие» в компьютерных программах и более нигде, которые можно полностью ломать и создавать заново по сотне в день, то для меня это абстрактный «разговор ни о чем». Я в игрушки играть не хочу. Я разговариваю о конфигурировании и архитектонике/архитектурировании в реальных проектах, как это делается для реальных систем.

1. Да, я совсем не девушка, и даже уже не мальчик (увы!). Я уже давно нашёл реальные проекты, и по уши в них сижу. И работаю на понятиях архитектурирования (architecting) и управления конфигурацией (configuration managment), но не конфигурирования (ибо мне другое нужно). 2. Вы видите проблему конфигурирования системы, а я из обозначаемых похожими словами -- управления конфигурацией, причем не информационной системы, а целевой системы инженерного проекта. А уж обеспечивающая информационная система должна это управление конфигурацией поддержать. Поэтому основная проблема -- синтез архитектуры информационной системы, которая поддержит функцию управления конфигурацией своей конструкцией, механизмом, структурой и т.д.. Всё это не изобретенные мной понятия, а из дисциплины системной инженерии, из учебников. 3. Всё есть системы, меня понятие системы не сбивает -- просто в одном и том же проекте рассматривается много разных систем: целевая, обеспечивающая, в операционном окружении и т.д.. А также есть системы в составе системы и еще системы систем. Это, опять таки, из учебников и стандартов, ничего лично придуманного. Система появляется (evolve) постепенно, в ходе жизненного цикла системы, у неё есть разные темпоральные части -- вполне можно рассматривать эти темпоральные части как отдельные системы. Модели системы -- это тоже темпоральные части системы. Опять же, вы обсуждаете конфигурирование. У меня предмет обсуждения другой, поэтому тут без комментов. 4. Системы рассматриваются и в greenfield и в brownfield проектах. Я пока этого не касаюсь. Ежели речь идет о greenfield, то технология управления конфигурацией должна быть развёрнута. Если brownfield -- задействована и адаптирована. У меня нет профессиональной позиции "конфигуратор", поэтому в моих проектах конфигуратор ничего не говорит. Я говорю об управлении конфигурацией в системах типа АЭС, подводной лодки, ледяной буровой платформы, космического корабля. Причем не только говорю, но и принимаю участие в реальных проектах.

Давайте по понятием немного пройдемся: 1. что у вас в системе определяется через конфигурирование/конфигурацию? 2. что у вас в системе определяется через архитектурирование/архитектуру? При условии, что и та и другая работа выполняются управляемым, а не случайным образом.