Обсуждение

И кто за всю эту красоту будет платить? Полное описание системы могут позволить себе только работающие на военных. Да и то не всегда. В большинстве же случаев фактор "деньги" гораздо более значим. И архитектуры это тоже касается. Кстати, построение абстрактной архитектуры без привязки к конкретной реализации на моей памяти всегда приводило к краху. Единственное, что работает, это обобщение многих и многих протестированных прототипов. А так, автоматизация должна упрощать, а она усложняет, делая людей заложниками тулов и методологий. PS: Японцы мне нравятся тем, что основывают свои методики на тысячелетней истории и культурных традициях.

отличный текст! лучший so far, in my humble opinion. засуну-ка я его на delicious (надеюсь, ссылка immutable?) чтобы два раза не вставать: есть ли какие-нибудь книги, которые наибольший эффект на вас произвели? порекомендуйте, желательно на английском. например - на меня произвели впечатление: Design Patterns by GoF Object-Oriented Analysis and Design by Grady Booch

Ключевой вопрос - кто все это мог бы преподавать? Чтобы обучать системной инженерии, нужно быть системным инженером. А чтобы стать системным инженером, нужно воспринять подходы системной инженерии (самому научиться). Замкнутый круг, однако. Сколько всего в мире системных (хоть в каком-то приближении) инженеров, для которых родной язык - русский? А сколько из них готовы преподавать? Кстати, как я понимаю, рабочей группы по образованию даже в INCOSE нет?

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

Классный текст. Очень понравилось "сетевой график проекта много лучше отражает положение дел, нежели штатное расписание."

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

Анатолий, давно хотел спросить - а Вы работы Дага Энгельбарта читали? Вот эти "процессы, которые происходят в обеспечивающей системе для продвижения целевой системы по ее жизненному циклу, а не в целевой системе. Поэтому иногда уточняют, что речь идет о процессах управления жизненным циклом. " - прямо перекликаются с его моделью трех уровней деятельности организации (ABC): A - операционная деятельность; B - деятельность по улучшению деятельности A (всевозможные управления - ЖЦ, качеством, рисками и т.д.); и деятельность C - по улучшению деятельности B (самообучение организации). Я, может быть, плохо искал, но кажется на русский ничего из Энгельбарта не переводилось, а ABC-модель только изредка упоминают в статьях про управление знаниями, и то без ссылки на конкретную публикацию. А ведь дядька-то весьма идейный!

Тут похоже про D и E в основном :)

Я имею ввиду нормальный кондовый архитектор, который домики строит. Большие и красивые. Я видел. А за фразы типа "построение архитектуры должно быть" в приличных местах дают по башке канделябром.

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

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

Книжки на меня производили разный эффект самые разные, но потом как-то их выпирание на общем фоне нивелировалось полученными другими знаниями. Я писал последний раз о содержании общего образования вот тут: http://ailev.livejournal.com/625203.html -- может, когда-нибудь руки дойдут написать для каждого пункта правильных авторов. Дизайн паттерны -- о да, я некоторое время серьезно вопрос языков паттернов изучал. У меня тут много постингов на эту тему было. Но вот к объект ориентированности как таковой я всегда относился сдержанно, ибо всякие парадигмы важны, и одного бога нам не нужно: абсолютная власть даже одной идеи развращает абсолютно (к идеям ведь это тоже относится ;).

Мы сейчас обсуждаем как раз организацию курсов и обсуждаем ровно эти же вопросы :) Решение таково: нужно пытатся силами неинженеров-теоретиков обучить каким-то мыслительным азам инженеров-практиков. А потом уже те инженеры-практики, которые смогут что-то из этого выхолощенного обучения понять и освоить в своей деятельности, да еще и будут иметь вкус к преподавательской работе, смогут провести второй курс, уже "настоящий". Ежели берем для первого курса 100 человек, то можно надеяться получить бригаду преподавателей из 10 человек. А эти 10 человек уже смогу подготовить 1000 человек. С другой стороны, не нужно недооценивать потенциал "теоретиков" (к которым можно, вроде, отнести и меня). Во-первых у меня был довольно большой опыт софтовой инженерии, а сейчас уже пару десятков лет идет опыт организационной инженерии. Системная инженерия ведь и про это тоже: в своей деятельности я вполне применяю все эти практики -- ибо паттерны мышления системного инженера похожи при работе с разным материалом систем. Так что отсутствие опыта работы с системами из железок не означает еще отсутствие опыта системной инженерии. Группа по образованию в INCOSE как раз есть, есть ее рекомендации по ВУЗовскому образованию, есть в INCOSE учебник по системной инженерии, все это можно найти на www.incose.org

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

Ну да, знаком (в Сети это все есть -- например, http://www.abccommunity.org/engelbart.html). Кстати, буквально вчера или позавчера глядел где-то фотографии с "Mother of all presentations". Мужик мощный! Но я заметил бы, что его ABC-теория примерно соответствует давно и обильно обсуждаемым идеям СМД-методологов, у которых "деятельность над деятельностью" или "управлять можно только развитием, воспроизводством управлять нельзя" и прочие рассуждалки имеют более давнюю историю и большее число поклонников в России, нежели труды самого Энгельбарта. Так что я бы для этих своих высказываний в качестве вдохновителя приводил не Энгельбарта, а Г.Щедровицкого. И, думаю, тут примерно одинаково рассуждали не только эти двое, но еще и многие и многие последователи "процессного подхода" -- вероятно, не знающие работ ни первого, ни второго. Все эти "процесссы улучшения управления рабочими процессами" уже стали штампами. Ну, а слово "знание" (только без этого штампа "управление знаниями") у Г.Щедровицкого вообще центральное! Так что, увы, Энгельбарт не является тут каким-то источником особого вдохновения. Я бы заметил, что уже со времени расцвета Энгельбарта и Г.Щедровицкого довольно много нового и интересного появилось, поэтому все эти построения нужно потихонечку проблематизировать и двигаться дальше.

Мне известно две точки: в МИРЭА обучением системной инженерии профессионально занимается Батоврин, а еще есть наша активность (одним из результатов которой как раз и явился настоящий постинг). Мы действуем по классике: исследования и разработки, а также учебная активность должны быть рядышком. Ну, и с Батовриным мы сейчас тоже начинаем сотрудничать. Я думаю, через некоторое время мы сделаем что-то открытое по линии INCOSE.

абсолютно согласен про вред абсолютизации :) в частности, гораздо удобнее начинать анализ деятельности предприятия с процессной модели (я использовал IDEF0/BPWin), и только потом кристаллизовать неструктурированные входные и контрольные потоки в какую-то объектную модель.

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

Удерживаемость руководства на постах до завершения проекта крайне зависит от проекта. Опять идет гиперобобщение, это не разговор. Никакого отношения удерживаемость руководства на постах к сути не имеет, ибо в больших проектах обычно идет "наказание невиновных, награждение непричастных": это не про принципы мышления в системной инженерии, оффтоп. Интеллектуальный процесс не автоматизируешь, конечно. Но что делает САПР, как не помогает этому процессу? Или вы предлагаете продолжать чертить на кульманах? Но это все равно разговор сильно в сторону, потому как я пишу о принципах мышления, а не о софте. Другое дело, что софт должен этим новым принципам мышления соответствовать. Например, чертежи должны лежать в каком-нибудь сапровском репозитории, а не в Documentum. Насчет японцев и третьих рук: руки совсем не третьи, а разговор опять ушел от принципов мышления.

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