Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия» / forpes.ru

Главная
Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия»

Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия» +11

14.01.2018 13:38

bipiem 80 3700 Источник

Попытался прокомментировать статью Ричард Хэмминг: Глава 28. Системная Инженерия» через свое понимание проблем «системной инженерии» и с учетом «современности», а также связанных или даже частично дублирующих ее EA \ BPM.

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

Системная инженерия или Systems engineering (SE) – также давно известное направление, как и BPM (Business Process Management) и EA (Enterprise Architecture). Найти, где заканчивается SE и начинаются ЕА и ВРМ – сложно. Уж очень все эти три направления «по-развивались», особенно в маркетинговой плоскости.

Любое проектирование «большого и сложного» — должно базироваться на SE. Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)

Есть рассказы (байки) КАК АРХИТЕКТУРА ПРЕДПРИЯТИЯ ДОПОЛНЯЕТ СИСТЕМНУЮ ИНЖЕНЕРИЮ

Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE, а в стандартах SE – постоянно говорится о «моделировании» и «процессах».
Таким образом, сложно представить ЕА или BPM без «довеска» SE: итого получаем троицу ЕА-BPM- SE.

Так как SE — это проектирование всего «большого и сложного», то по «определению» оно пересекается практически со всем известным из «Best Practice» & ххBOK, включая «SE & PMBOK», «SE & ITSM», но ограничимся указанной «тройкой», причем с учетом изложенного в моих циклах с критикой ЕА и ВРМ:

Enterprise Architecture vs алхимия предприятия
Бизнес-процессы: Как все запущено и запутано (ВРМ)

Ключевой вывод: Если ЕА и ВРМ считаем алхимией, а SE не опровергает их подходы, а наоборот «дополняет», а зачастую «дублирует и повторяет», то можно поставить под сомнение утверждение, что SE – это инженерная дисциплина.

Проблема современных SE – такая же, как и для ЕА и ВРМ – нет детальных опубликованных примеров их апробации. Почти все проекты закрыты через NDA, ДСП и «военная тайна», нет пошаговых примеров по реализации проекта. Зато много зарабатывающих на SE ассоциаций, много маркетинга, курсов, продаж и т.п.

Немного про SE

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

Из книжки «Системная инженерия для чайников» от IBM

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

Wiki Systems engineering
— совсем скупо.

Впрочем, как и Wiki Системотехника

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

Почему-то первенство SE отдают США (вопрос дискуссионный):
Согласно легенде системная инженерия впервые появилась как метод ведения работ в военной отрасли США, когда нужно было скрестить два сверхсложных инженерных проекта: атомный проект по созданию ядерного оружия и проект создания баллистических ракет, необходимых для доставки этого оружия. Не было никаких голов “генеральных конструкторов”, которые могли были бы справиться с решением этой задачи, и пришлось изобретать методы совладания со сложностью подобного сверхпроекта.
Системноинженерное мышление

Сомневаюсь, что советские аналогичные проекты не использовали такие же SE-подходы.

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

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

Стандарты системной инженерии

Наглядным отражением задач SE можно считать (условно) картинку (впрочем, как и задач PMBOK): Проект «Тарзанка»

1. Начало

В первых трех абзацах «Глава 28. Системная Инженерия» через «Человек смотрел, как строят собор» говорится о простой истине: «За деревьями не видеть леса». Это типовая ситуация, когда люди концентрируются на частностях и не видят «целого». Об этом очень много написано. Кое-что есть у меня:
3.5 Леса, деревья, листья
можно разделить на две задачи (категории): задачу описания «леса» (процессы в «крупную клетку», взгляд с высоты «птичьего полета») и достаточно детальных «процессов — деревьев»

Они демонстрируют узость взглядов в своей работе и редко, если вообще когда-либо, связывают её с более общими целями системы.

Такая узость взглядов является основной характеристикой бюрократа.

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

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

Т.е. умение видеть и «лес» и «деревья», понимать законы развития (жизнь) «леса» и совсем другие законы (жизнь) «деревьев», причем у каждого «дерева» – свои собственные законы.

Собственно это механизм перехода от крупного масштаба рассмотрения к мелкому и обратно.

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

Я проецирую эту мысль на наше время, как необходимость привлечения самих бизнес-пользователей «напрямую» к описанию и оптимизации своих бизнес-процессов без использования ИТ-специалистов (BPM-специалистов, ЕА-архитекторов и прочих алхимиков) и программистов.

Об этом рассказывал в статье Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
На протяжении долгих лет не угасает стремление (мечта №2) — найти простой путь моделирования процессов непосредственно их участниками (задействованными в процессе) без привлечения BPM-специалистов «по отрисовке квадратиков и кружков», а также выполнение построенных таким образом процессов. Отсюда и сильная тяга (надежда) к формату BPMS

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

Это же я пытаюсь донести в цикле ЕА «Enterprise Architecture vs алхимия предприятия», т.е. показать, что трансформация существующих подходов к ЕА и ВРМ должна быть направлена на:

не столько решением существующих проблем …

т.е. не разработка сиюминутного описания ЕА, к тому же закрытого по NDA и ДСП, т.е. чисто монетаризацией этого направления. Причем очень спорно, что проблемы действительно «решены», т.к. часто неудачный (провальный) проект ВРМ \ ЕА \ SE выдается за удачный, но узнать истину – нельзя.

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

это возможно только путем открытого обсуждения и не столько самих «методов решения проблем» — методологий и загадочных фреймворков, сколько демонстрации на конкретных примерах, апробации теоретических «Best Practice» и публикации практических «Best Practice». К сожалению, этого в современных ЕА и ВРМ и SE — нет.

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

Многих практиков ЕА и ВРМ и SE интересует только личная выгода, но вот развитие направления в целом, точнее переход от «алхимии» к «химии» — мало кого. Бизнес по ЕА и ВРМ и SE – процветающий: консалтинг, коучинг, инструменты и т.п., но что касательно практики и «теории по Ленину» – имеем ноль: «Нет ничего практичнее хорошей теории». Нет никаких доказательств в открытом доступе практичности, вообще ничего из практики по ЕА и ВРМ и SE — нет.

Всё «практическое», т.е. все примеры — или коммерческая или государственная тайна. Кто сказал, что методологии и выполненные по ним проекты – успешные? На основе чего? И с какой выгодой?

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

Потом это был AT&T, Страна за пределами AT&T, научные сообщества и сообщества инженеров, и, в итоге, весь мир. Таким образом, у меня появились обязательства перед самим собой, моим отделом, подразделением, компанией, родительской компанией, страной, миром ученых и инженеров и каждым жителем планеты.

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

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

Это все — к вопросам: стандартизация, унификация, типизация, свободный обмен лучшими практиками. Отечественная SE – это ГОСТы серий 34.ххх и многие из 15.ххх и 2.ххх.

Обязательность их исполнения осталась в прошлом, но это обеспечило на то время мощный потенциал, прежде всего, при производстве военных систем (ГОСТ РВ 15.ххх и 2.ххх.).
Максимум, что сейчас делается – это переводы зарубежных ГОСТов.

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

Правильно – не нужно нам это, т.к. у нас:

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

Я убежден, что ЕА и ВРМ и SE могут быть также представлены и досконально формализованы как подходы к кодированию информации. И эти направления когда-нибудь станут настоящими научными и инженерными дисциплинами.

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

Я бы развил мысль далее — «системных инженеров стоит судить не по тому, что они говорят, а» по результату.
И где отечественный авиа, авто – пром, где отечественный «SE-пром» (развитие 34.ххх), где хоть что-то отечественное из инженерии, системной инженерии? Умеем лишь переводить «западную алхимию», перепродавать западную «комплектуху» и из нее лепить системы (комплексировать), что в ИТ, что везде: 80% от суперджета и современных жигулей – импортные детали и технологии.

Конечно, по этому критерию нужно судить не только инженеров, но и вождей и всех граждан (с молчаливого согласия которых все это), но вот — инженеров, причем ответственных за «большие системы» и за отечественную «системную инженерию», — в первую очередь. Не хотел о политике, но это вытекает из цитат из Хэмминга: «судить, что они в итоге делают и производят». А что реально производят? Производят в основном их западные коллеги.

Первое правило системной инженерии

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

Проблема с заземлением дифференциального анализатора – как то не совсем мне очевидна. Это скорее технический дефект.

Я бы привел другой пример, не особо показательный, но в ином направлении: помним старую игрушку — Диггер. Играли – играли, все было хорошо.

Потом появились новые компьютеры и … на них играть стало невозможно, хотя их архитектура была совместимой. Из-за значительно прироста скорости – «бедного Диггера» мгновенно «съедали»: очень быстро работала новая система, т.к. уж очень «хорошо» оптимизировали вычислительную мощность компьютера.

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

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

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

Это примеры когда не работает принцип: «кашу маслом не испортить»: в сложных системах он не всегда работает.

Зубрение перед экзаменом — пустая трата времени.

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

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

Кстати к вопросу обучения в отечественных ВУЗах, часто наблюдается парадокс: двоечники добиваются блестящей карьеры (уходят в топы), а отличники «протирают штаны» инженерами (рядовыми сотрудниками).

Системная инженерия — это процесс, которому трудно следовать, так легко потеряться в деталях!

Да, верно, но только — пока эти направления: SE, ЕА, ВРМ — находятся на уровне развития «алхимия». Когда это станет реальной наукой и будут детальные и обоснованные (доказанные) и апробированные походы, то «следовать будет просто», даже начинающему.

По «букварю» — уж не знаю какому: букварю SE, ЕА или ВРМ (или все это схлопнется в одно направление) можно будет пошагово построить любую АСУ или предприятие. Сравнение с алхимией относится более явно к ЕА и ВРМ, чем к SE, SE – все-таки более продвинулась по сравнению с ними, в первую очередь, благодаря стандартизации.

Хотя и на SE уже наложена «лапа маркетинга». Ключевая проблема SE (повторюсь) – это отсутствие, также как и для ЕА и ВРМ, – публикуемых примеров реализации методик SE (проектов).

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

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

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

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

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

На инженерных специальностях вместо научных дисциплин часто преподается откровенная алхимия. Про преподавание алхимии:
«Со временем, на обложках подобных учебных пособий и книг внезапно проявится надпись «Пособие по алхимии», а некоторые уже сейчас способны разглядеть пока еще расплывчатые контуры такой надписи». habrahabr.ru/post/345948

Как раз поэтому:

… многие люди знают, что сказать, но не многие могут фактически применить это на практике, когда придет время действовать в реальном мире. Большинство из вас не может!

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

Упоминания про «У них была производственная линия, …» — это про промышленный конвейер и т.п. (Г. Форд), напрямую к SE отношения, видимо, не имеет. Хотя любое проектирование – это фактически такой же проектный конвейер.

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

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

Большая ошибка в акте приемочных испытаний большой системы сделать запись: «Ошибок нет». Правильно указать: «на этапе испытаний ошибок не выявлено», потому что они обязательно есть, только их еще не нашли и не устранили.

Даже наличие литеры Э1 и последующих литер Оn (ГОСТ 2.103—2013) на опытные образцы системы не гарантирует отсутствие ошибок. Оперативное внесение изменений параллельно в конструкцию и документацию (Гибкость в проектировании) – это норма при каскадном проектировании (хотя это почему-то приписывают только «гибким» agile), что при строительстве, что при производстве.

Второе правило

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

Этот тезис развился в отдельные современные направления «Управление изменениями», «Управление требованиями», в некоторых частных случаях, например, ITIL — «управлениями релизами» и т.п.

Как я писал ранее, период полураспада подходов к проектированию составляет 15 лет — половина идей, которые вы узнаете сейчас, будут бесполезны через 15 лет.

Сомнительный тезис. Проецируя на себя: мне намного больше дало изучение подходов к разработке военных систем (АСУ) и строительных ГОСТ и СНИП, которые я изучал 20 лет назад, чем современная литература примерно о том же, только в обертке «ЕА \ ВРМ» и с «маркетинговыми фишками», «цели бизнеса» и т.п.

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

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

Вообще, с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
Если будет разработана качественная теория, то она будет «бессмертна» и востребована.
Хотя она может (должна) развиваться, но не со сменой курса на 180 градусов.

Кстати, тогда же я сравнивал стадии проектирования в ГОСТах на АСУ (24.ххх, 34.ххх) и в строительных (21.ххх) и других (ЕСКД-ЕСПД), стадии в методологии АРИС и еще в чем-то (не помню уже). И все сводилось к одному:

1) предпроект (аванпроект, концепция и т.п.)
2) эскизный проект, технический проект, рабочий проект
3) испытания, приемка, внедрение

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

Этот «классический каскад» — фактически основа «системного подхода» к проектированию сложных систем.

Интересно, что эти самые «разные методологии», в которых указаны одни и те же SE-принципы, могут относиться как непосредственно к SE, так и ЕА и ВРМ. Например, стадии проектирования ТОГАФа обсуждаем в комментариях к Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие

Так зачем такой зоопарк методологий?
Мы говорим о «серьезных изделиях», полагаю, что использование agile (как альтернатива каскаду) и т.п. «как основы» при разработке что танка или самолета, что ядерного реактора или систем типа «мертвая рука» — никому в голову не придет.

Третье правило

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

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

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

… я верил, что маленькие задачи были относительно более важными, чем большие.

Это продолжение тезиса «За деревьями леса не видеть леса». Вообще, этот тезис – один из основных в SE и часто повторяется, см. в том числе, книжку «Системная инженерия для чайников» от IBM.

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

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

Это вылилось в различные ветки, например, в ITSM: «Управление обращениями», «Управление инцидентами», «Управление проблемами» и т.п. Это методы связывания разных следствий (инцидентов) к одной причине (проблеме).

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

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

И я про это же: достаточно опубликовать конкретные проекты по SE, ЕА, ВРМ и показать, откуда были взяты направляющие «что и как сделать» (стандарты, фремворки) и как были применены эти самые стандарты и фреймворки, какие проблемы возникли и как были решены. Всего лишь «только рассказать» и показать на конкретном подробном реальном или вымышленном примере.

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

«Врага нужно бить поодиночке», а сложную задачу решать по частям (т.е. декомпозировать, упрощать) и т.п. – это все заповеди SE, такие же, как про «лес и деревья».
Какой на Ваш взгляд ключевой документ по SE? Не методология типа ГОСТ или ISO/IEC 15288
или даже Systems Engineering Body of Knowledge (SEBoK)
а практический документ для конкретной системы (артефакт проекта).

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

Это Схема деления изделия на составные части (ГОСТ 2.711-82). В этом и заключена детализация системы на элементы: изделия на отдельные под-изделия – составные части, которые в свою очередь являются изделиями (возможно даже изделиями типа «сложная система», некоторые покупные и т.п.).

Заходишь в кабинет главного конструктора, а у него почти во всю стену 6х3 весит всего одна «Схема деления» и с достаточно мелкими элементами (несколько сотен). Это к высказыванию Хэмминга:

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

Это и есть «одна конкретная большая картинка», да еще и с децимальными номерами и пояснениями типа «разрабатываемое» или «покупное» изделие.

Аналог «нашей» Схемы деления по ГОСТ — это «D.1.3 Структура системы» из «ихнего» ISO/IEC 15288, только «наша» оформлена в виде стандарта еще в 1982 и с более детальной нотацией. Вообще, при чтении «современных» западных стандартов на SE, вспоминается аналогии из ГОСТ 2.ххх, 34.ххх, а также из ГОСТ РВ 15.ххх.

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

Я уже упоминал об этом, но позвольте заметить еще раз: решение, которое не дает более глубокого понимания — плохое решение, но, возможно, что это всё, что возможно сделать в текущем временном ограничении. Целью системной инженерии должно быть более глубокое и долгосрочное понимание сущности проблемы, в то время как клиент всегда хочет увидеть оперативное избавление от текущих симптомов. Опять же, конфликт, ведущий к мета-системной инженерии!

В идеале пользователь (клиент) всегда ждет от ERP, АСУ и т.п. режим: «пришел на работу, нажал Большую красную кнопку и ничего более делать не нужно: система сама поработает. Главное не забыть при завершении рабочей смены отжать Большую красную кнопку».

Видимо – это несбыточная мечта или порог, после которого последует SkyNet.

Как пример углубленного понимания системы и её проблем, я хочу рассмотреть проект управляемых ракет Nike.

У меня сложилась уверенность, что рассвет системной инженерии «там» (США) и системотехники «здесь» (СССР) пришелся на период холодной войны. После «потепления» у нас оно вообще оно погибло и исчезло как отечественная «Best Practice», а там трансформировалось в некий инструмент маркетинга (вообще, лидер в этой номинации ISO 9000). Видимо ничто так не мобилизует человека, как угроза его выживанию.

Системная инженерия — это безусловно увлекательная профессия, которую трудно практиковать.

Проектирование АСУ и предприятия, процессов организации – всегда подразумевают практику SE. Почитать по SE много чего есть, на мой взгляд, это еще не наука, но через фильтр «маркетинга» можно фильтровать полезность.

Поэтому читать книжки (тем более статьи) по ЕА и ВРМ и SE нужно прошептав: «Осторожно маркетинг», исключения составляют книжки (включая, западные) и отечественные ГОСТы советского периода. Отфильтрованное от маркетинга можно применять, но непонятно где: отечественная наука и промышленность «на коленях», вся идеология, методология и вся «комплектуха» — западные.

Неплохая практическая книжка по SE применительно к АСУТП: «Проектирование АСУТП», Нестеров.

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

Что такое SE

Systems engineering в понимании Хемминга – это то же самое, что «системная инженерия 2018» и системотехника сегодня? Скорее всего «да».

SE — это подходы к проектированию систем. Каких систем? Любых, но сложных. Точнее земных. Солнечную систему проектировать видимо нужно по другим методологиям. В идеале SE должны объясняить как строить не только технические системы, но и экономические, социальные (включая коммунизм, почему бы и нет? To be «светлое будущее», roadmap №2 на основе framework «1917»).

Простые системы также можно проектировать по SE, но это будет «не оптимально».

Универсальность SE обусловлена «взятием на вооружение» принципа «системного подхода», комплексного взгляда на разрабатываемое (модернизируемое) изделие – как на «сложную систему».

Как правило, «деталь» и «программа» – не включаются в категорию «система». В такую категорию выделяют нечто сложное, например, «самолет» или «большая программа» (ERP), тем более — объекты типа АСУ и «предприятие» — это настоящие «системы».

Точно также, как PMBOKу — все равно какие проекты по нему реализовывать, то и для SE – собственно не так важно какие изделия типа «система» по нему строить и внедрять.
Хотя системы типа «самолет», «АСУ» и «предприятие» — должны проектироваться по разным ответвлениям SE (принцип общий, но есть специфика).

Вследствие общности проектирования любых АСУ и произошло объединение в рамках одного ГОСТ 34.ххх подходов к проектированию АСУ разных классов и просто «автоматизированных систем».

Вообще, когда я читаю многие современные статьи и «открытия» по теме SE, ЕА, ВРМ, то часто возникает ощущение, что это уже ДАВНО читал, причем не в ГОСТах. Вспоминаются статьи двадцатилетней давности, типа «Сага о корпоративных информационных системах и их пользователях», см. ее начало
Интересно, у кого-нибудь есть подобное Дежавю?
Тогда все книжки на тему «Корпоративные информационные системы» были про ЕА, ВРМ вперемешку с SE. Понятия КИС, АСУ, ИТКС сегодня «постарели», но проблемы остались точно такие же.

Заключение

Системная инженерия \ системотехника, ЕА, ВРМ – в целом если не «одно и то же», то родственные понятия. Основные различия в их позиционировании и в маркетинге. Впрочем, как и понятия: ERP, CRM, Системы документооборота и т.п. Например, идентичный модуль «обработка клиентской заявки» может быть основным элементом любой из указанных программных систем.

Системная инженерия, ЕА, ВРМ – должны когда-нибудь стать настоящей наукой и инженерией, точно также как и «коды Хэмминга». Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»), проектирование, проверку качества и точности исполнения изделий класса «система».

Неважно, какая это «система»: АСУ, включая, АСУ войсками, АСУТП или государственные информационные системы, «электронное правительство», или целое «предприятие» (ЕА), включая, домохозяйство, бизнес (ИП, МСБ, «корпорат»), государство.

В этом случае любой начинающий проектировщик мог бы с легкостью, аналогичной описанию «кода Хэмминга», использовать SE, ЕА и ВРМ в своей практике.

Основной мотив SE и вообще автоматизации

Все сводится к тому, что есть механизм и система управления (СУ) этим механизмом. Механизм – это автомобиль или аппаратно-программный комплекс и т.п. Управляет механизмом человек или робот (автомат, демон) или совместно.

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

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

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

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

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

На сегодня SE не позволяет полноценного проектированная ни в области ЕА (проектирование предприятия или его АСУ), ни проектирования процессов (BPM). Можно конечно сказать, что это не является задачей SE, но это лишь отговорка.

Тем не менее, стандарты SE более понятны, чем ЕА и BPM, и более полезны, но насколько я понимаю, с каждым годом происходит сокращение проектов, реализуемых по ним. Во всяком случае, (по субъективным ощущениям и публикациям) 20 лет назад их было больше, чем 10 лет назад, а сегодня их меньшее, чем 10 лет назад.

Будущее SE

Меня удивляют современные подходы абсолютной закрытости проектирования гражданских систем, тем более государственных за бюджетные средства. Когда эта «стена рухнет» и будет проектирование «не вслепую», а с учетом огромной базы примеров и прототипов, то будет совсем другой подход к SE, а также, соответственно, и к ЕА и ВРМ и другим направлениям проектирования.

Разрабатывать ТЗ на систему, у которой тысячи аналогов – какой смысл? SE необходимо только для уникальных систем, которых еще ни у кого не было, т.к. они разрабатываются впервые. Таких систем, не более 0,1% из всей массы. Разговоры, что все системы и все предприятия – уникальны и их нужно проектировать «с нуля» через ТЗ и RFP, — это «маркетинговый трюк».

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

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

Статью подготовил «на скорую руку» за день, так чтобы ее читали прямо «вдогонку» к переводу «Ричард Хэмминг: Глава 28. Системная Инженерия», поэтому где-то неточно выразил мысль и, возможно, где-то «погорячился» (не особо подбирал «смягчающих» глаголов, «рубил правду-матку»), допустил неточности и опечатки.

Ваш, bipiem

Комментарии (80)

lair
14.01.2018 18:11
#10615788
Любое проектирование «большого и сложного» — должно базироваться на SE
Нет.

Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE?
Нет.

Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE
Нет.

Так как SE — это проектирование всего «большого и сложного», то по «определению» оно пересекается практически со всем известным из «Best Practice» & ххBOK, включая «SE & PMBOK», «SE & ITSM»
И тоже нет.

Если ЕА и ВРМ считаем алхимией, а SE не опровергает их подходы, а наоборот «дополняет», а зачастую «дублирует и повторяет»,
А из чего вы взяли, что системная инженерия "дополняет", "дублирует и повторяет" методы enterprise architecture и BPM?

то можно поставить под сомнение утверждение, что SE – это инженерная дисциплина.
А где это утверждение было сделано? Открываем первую попавшуюся википедию, читаем: "Systems engineering is an interdisciplinary field of engineering and engineering management". Все ровно как в ваших цитатах — междисциплинарный подход. В SEBoK то же самое, и делается упор на междисциплинарность. Вроде, никто не говорит, что это инженерная дисциплина. Так что вы ставите под сомнение утверждение, которого никто не делает.

Я проецирую эту мысль на наше время, как необходимость привлечения самих бизнес-пользователей «напрямую» к описанию и оптимизации своих бизнес-процессов без использования ИТ-специалистов (BPM-специалистов, ЕА-архитекторов и прочих алхимиков) и программистов.
К сожалению, опыт показывает, что большая часть бизнес-пользователей не обладает достаточной квалификацией. Причем я не говорю о BPM, EA или SE — существенная часть пользователей не способна самостоятельно корректно описать существующие процессы. Аналитика совершенно не зря является отдельным этапом.

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

Да, верно, но только — пока эти направления: SE, ЕА, ВРМ — находятся на уровне развития «алхимия». Когда это станет реальной наукой и будут детальные и обоснованные (доказанные) и апробированные походы, то «следовать будет просто», даже начинающему.
Недоказуемое утверждение. Вы знакомы со спецификой гуманитарного знания? (и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами) Так вот, многие люди вообще не считают, что к гуманитарному знанию применим научный подход (та его часть, которая с экспериментами и доказательством). Есть множество устоявшихся и признанных отраслей гуманитарного знания, в которых непросто следовать начинающему. Да даже и в STEM есть куча таких отраслей, чего уж.

Проецируя на себя: мне намного больше дало изучение подходов к разработке военных систем (АСУ) и строительных ГОСТ и СНИП, которые я изучал 20 лет назад, чем современная литература примерно о том же, только в обертке «ЕА \ ВРМ» и с «маркетинговыми фишками», «цели бизнеса» и т.п.
Откройте оригинал, в котором написано следующее:

I cited earlier the half-life time of engineering details as being 15 years — half of the details you learn now will probably be useless to you in 15 years.
Так вот, в программировании, и вообще в IT это более чем верно; более того, я склонен думать, что сроки сейчас еще меньше.

Какой на Ваш взгляд ключевой документ по SE? [...] Это Схема деления изделия на составные части (ГОСТ 2.711-82). В этом и заключена детализация системы на элементы: изделия на отдельные под-изделия – составные части, которые в свою очередь являются изделиями (возможно даже изделиями типа «сложная система», некоторые покупные и т.п.).
И как этот "ключевой документ" отвечает на (а) вопросы управления жизненным циклом и (б) вопросы о целях и задачах?

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

Разрабатывать ТЗ на систему, у которой тысячи аналогов – какой смысл?
Гигантский, очевидно. Как вы предлагаете разрабатывать систему без ТЗ?

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

Со временем (видимо при коммунизме) основой построения систем будет заимствование действительно лучших решений
Осталось всего ничего — придумать критерий "лучшего решения".
1. lair
  14.01.2018 18:24
  #10615794
  +1
  SE необходима для всех (достаточно сложных) систем, потому что иначе вы не справитесь с реализацией
  … я сам себе противоречу, конечно же. Нет, SE не необходима, потому что есть люди, которые справляются с проектами без всякой SE. Но все равно, необходимость SE на проекте определяется не уникальностью системы, а ее сложностью и навыками людей, участвующих в реализации.
  1. bipiem Автор
    14.01.2018 21:59
    #10615966
    Но все равно, необходимость SE на проекте определяется не уникальностью системы, а ее сложностью и навыками людей, участвующих в реализации.
    
    Зачем SE, если нужно просто тупо повторить уже имеющийся прототип. Типовая система, понятно как она работает, проектные риски минимальные, есть на нее описание и т.п.
    Фактически «серийное производство». Даже если завод-изготовитель (компания – разработчик) будет другой, то к чему ТЗ, проекты (эскиз, тех., раб.) и т.п.? Какой бы сложной система не была.
    Типовые системы нужно тиражировать, а не «изобретать велосипед» в придачу с SE. Только уникальные нужно проектировать.
    
    навыками людей, участвующих в реализации.
    
    Это не причем. Промышленная разработка (конструкторское бюро, КБ, «фабрика» программистов и т.п.) даже высокотехнологичных изделий должна опираться не на «гениев», а на базовый уровень разработчиков.
    Поэтому и предельно регламентируются все этапы конвейера разработки, чтобы получить гарантированное качество вне зависимости присутствия на конвейере (в КБ) «гения».
    
    lair
    15.01.2018 11:26
    #10616452
    Зачем SE, если нужно просто тупо повторить уже имеющийся прототип.
    Чтобы понять, что этот прототип применим к задаче. Чтобы понять, как его повторять. Чтобы внедрить и поддерживать.
    
    Это не причем. Промышленная разработка (конструкторское бюро, КБ, «фабрика» программистов и т.п.) даже высокотехнологичных изделий должна опираться не на «гениев», а на базовый уровень разработчиков.
    Вот именно поэтому "причем". Гениям не нужна системная инженерия, им не нужно планирование, им много что не нужно. Все эти вещи придумываются для того, чтобы декомпоновать задачу до уровня, доступного не-гениям.
1. bipiem Автор
  14.01.2018 19:40
  #10615874
  Часть 1
  Уважаемый lair, благодарю Вас за внимание к моей статье, однако позволю себе ответить только на те Ваши замечания, которые содержат ненулевую аргументацию.
  
  А из чего вы взяли, что системная инженерия «дополняет», «дублирует и повторяет» методы enterprise architecture и BPM?
  
  Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?
  
  А где это утверждение было сделано? Открываем первую попавшуюся википедию, читаем: «Systems engineering is an interdisciplinary field of engineering and engineering management». Все ровно как в ваших цитатах — междисциплинарный подход. В SEBoK то же самое, и делается упор на междисциплинарность. Вроде, никто не говорит, что это инженерная дисциплина. Так что вы ставите под сомнение утверждение, которого никто не делает.
  
  Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?
  Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями? При этом она остается инженерной дисциплиной. А какой по-Вашему?
  
  К сожалению, опыт показывает, что большая часть бизнес-пользователей не обладает достаточной квалификацией.
  
  Конечно, только внешние консалтеры ей обладают. Мне это напоминает анекдот:
  Про исследовательский бизнес есть анекдот. Около стада овец приземляется вертолет. Из вертолета выходит человек в костюме от Kiton и предлагает пастуху сделку: овца в обмен на точную информацию о поголовье стада. Пастух соглашается, человек подключает ноутбук к серверу NASA, получает необходимое спутниковое фото и печатает отчет на 150 страницах, из которого следует, что в стаде 3141 овца.
  Забирает гонорар, но тут пастух делает ответное предложение: «Я точно называю твой бизнес, а ты отдаешь овцу назад».— «Идет».— «Ты — консультант».— «Как узнал?» — «Ты пришел, когда не звали, взял плату за то, что я и без тебя знаю, да и в моем деле ты ноль — отдавай мою собаку!»
  Вы про такую аналитику?
  
  Я в этом году как двадцать лет разрабатываю программные системы, и часть из них успешно применяется зарубежом. Так что я не знаю, как вы, а я вполне успешно имею дело с отечественной ИТ-индустрией, включая экспортную.
  
  За Вас я рад. Однако почти все мои соотечественники и я юзают западное ПО. Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.
  
  Есть наверно отдельные спец-форумы, где более точно покажут, что вокруг происходит, но мне казалось, что «невооруженным» глазом ХОРОШО видно окружающие нас отечественные программы, компьютеры и гаджеты.
  
  Один и свежий пример. Купили телефончик Хонор, две недели поработал (настройки заводские, ничего не меняли), потом он перестал принимать пароль. Далее recovery boot. И всё: Game Over.
  Далее — запрос аккаунта гугл (FRP) – который не принимается (типовая ситуация, судя по отзывам в инете). Про блокировку запроса аккаунта гугл (FRP) написано сотни статей, Прочитал 20 статей, попробовал 20 способов (перебор secret code – это только один из них) не сработали.
  Случайно подошел пример, размещенный на совсем не ИТ-форуме.
  Каждый из нас – потенциальная жертва подобной политики гугл. Все андороиды подвержены такой фитчи или багу или как еще это назвать. Уверен, что нечто подобное случается и с «огрызками».
  
  Это что «технологическая независимость»? Отечественный софт? Это игла, на которой сидит каждый обладатель смартфона с андроид начиная с такой – то версии.
  Кстати это тема как для «прокачки» в терминах SE, так и ЕА\НА (подсистемы home office, системная архитектура в НА).
  Продолжение по второй части.
  1. lair
    14.01.2018 20:03
    #10615896
    те Ваши замечания, которые содержат ненулевую аргументацию.
    Бремя доказательства лежит на утверждающем.
    
    Из прочтения литературы (и макулатуры тоже) по SE, ЕА, ВРМ и сопоставления сведений оттуда вычитанных. А у Вас откуда иные предположения?
    Из отсутствия подтверждающих цитат.
    
    Т.е. Вы утверждаете, что системная ИНЖЕНЕРИЯ – это не инженерная дисциплина?
    Да, именно так.
    
    Может быть «Междисциплинарный подход» — это когда системная инженерия претендует на то, что она работает со всеми инженерными специальностями?
    Нет. Открываем SEBoK: "Interdisciplinary approach governing the total technical and managerial effort required to" (выделение мое). Управленческие усилия — не инженерная дисциплина.
    
    (С другой стороны, будем честными, я вот пошел искать определение инженерной дисциплины — и не нашел. Bad for me. Каким определением пользуетесь вы, говоря, что SE — не инженерная дисциплина?)
    
    Конечно, только внешние консалтеры ей обладают.
    Нет, ей обладают люди, которые занимаются анализом как дисциплиной, не важно, внешние они или внутренние.
    
    Вы про такую аналитику?
    Нет, я про качественно проведенный бизнес-анализ.
    
    Даже не смотря на огромные преференции, которые дало правительство отечественным разработчикам.
    … а это какие, если не секрет?
    
    Каждый из нас – потенциальная жертва подобной политики гугл.
    Не используйте продукты гугл.
    
    Это что «технологическая независимость»?
    А я нигде не говорил про технологическую независимость. Я в нее и не верю, собственно говоря.
    
    bipiem Автор
    14.01.2018 22:29
    #10615998
    Бремя доказательства лежит на утверждающем.
    
    В данной ситуации: в статье приведены аргументы, Вы же на них просто заявили: «Нет», «И тоже нет», не представив аргументацию по этим «нет». Поэтому бремя переложено на Вас.
    
    Из отсутствия подтверждающих цитат.
    
    В самом начале:
    Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» – это тоже про SE, а в стандартах SE – постоянно говорится о «моделировании» и «процессах».
    Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
    Это не цитаты, но смысл дают ясный.
    Вы действительно считаете, что в SE нет про моделирование процессов и архитектуру? В том же: ISO/IEC 15288 про это говорится.
    
    Управленческие усилия — не инженерная дисциплина.
    
    Они есть во всех процессах, системах и т.п. Это очень общий термин. Управление – это вообще нечто, присутствующее во всем и везде (типа «святого духа»). В любой «Best Practice» — о нем много и разного сказано.
    
    Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина».
    
    … а это какие, если не секрет?
    
    На память не помню, но много попадалось в заголовках новостей: всякие там реестры отечественных разработчиков софта, гранты куда-то и т.п. Если не найдете, скажите – погуглю.
    
    Не используйте продукты гугл.
    
    Ну очень смешно. Рад бы не использовать. Я же говорю, что гугл и механизм запроса аккаунта гугл (FRP) – зашиты в КАЖДЫЙ телефон с андроид:
    С появлением системы Android 5.1 Lollipop у пользователей появились не только новые полезные функции, но и откровенно тупящие «фичи». К примеру, Google FRP Lock, он же «защита от сброса настроек», суть которой заключается в защите телефона от злоумышленников, которые решили обойти блокировку смартфона путём сброса настроек.
    
    После сброса настроек пользователь обязан войти в Google аккаунт, к которому был привязан этот телефон, но очень часто бывает, что телефон просто не принимает правильный аккаунт и пароль.
    
    А я нигде не говорил про технологическую независимость. Я в нее и не верю, собственно говоря.
    
    А вот наши предки не только верили, но и добились этой независимости. И всё в стране было отечественное, т.е. сделанное «собственными руками». Сейчас это в прошлом. Прежде всего, потому, что давно нет веры. Но одной веры (если она и вернется) будет явно не достаточно.
    
    lair
    15.01.2018 11:31
    #10616474
    В данной ситуации: в статье приведены аргументы
    Да нет же. В статье приведены утверждения, которые ничем не подтверждены. Возьмем первое же:
    
    Любое проектирование «большого и сложного» — должно базироваться на SE
    Это просто ваше высказывание, чем оно обосновано?
    
    Это не цитаты, но смысл дают ясный.
    Благодаря тому, что это не цитаты, они дают смысл того, что вы думаете, но нет никакого подтверждения, что так же думают методологи.
    
    Вы действительно считаете, что в SE нет про моделирование процессов и архитектуру?
    То, что в SE есть что-то про архитектуру и модели, не означает, что SE занимается тем же, что BPM и EA.
    
    управление – это вообще нечто, присутствующее во всем и везде (типа «святого духа»).
    Нет. В расчете подъемной силы крыла нет никакого управления.
    
    Когда говорят «системная инженерия» — впрочем, как и любая «инженерия» — я это отношу «автоматом» к «инженерная дисциплина».
    … и начинаете спорить с собственным же утверждением.
    
    Но вернемся к вопросу: что такое "инженерная дисциплина"? Каково ее определение? Какими свойствами она обладает?
    
    На память не помню, но много попадалось в заголовках новостей: всякие там реестры отечественных разработчиков софта, гранты куда-то и т.п. Если не найдете, скажите – погуглю.
    Не нашел.
    
    Ну очень смешно. Рад бы не использовать. Я же говорю, что гугл и механизм запроса аккаунта гугл (FRP) – зашиты в КАЖДЫЙ телефон с андроид:
    Не используйте андроид.
    
    А вот наши предки не только верили, но и добились этой независимости. И всё в стране было отечественное, т.е. сделанное «собственными руками». Сейчас это в прошлом.
    Не вижу смысла спорить о прошлом; а в настоящем этой независимости нет. И это одна из причин, почему я не верю в ее достижимость.
    
    bipiem Автор
    15.01.2018 14:14
    #10616874
    «Любое проектирование «большого и сложного» — должно базироваться на SE»
    Это просто ваше высказывание, чем оно обосновано?
    
    Например, также думают Авторы: В. К. Батоврин. Ф. И. Голдберг. А. В. Александров.
    Системная инженерия, или системотехника — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем
    Множество других авторов также подчеркивает, что по SE хоть и можно строить простые системы, но задумалась она именно под проектирование «сложных» и «больших».
    Странно, что это вызывает у Вас вопросы.
    
    То, что в SE есть что-то про архитектуру и модели, не означает, что SE занимается тем же, что BPM и EA.
    
    Приводил несколько ссылок:
    Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
    Есть рассказы (байки) КАК АРХИТЕКТУРА ПРЕДПРИЯТИЯ ДОПОЛНЯЕТ СИСТЕМНУЮ ИНЖЕНЕРИЮ
    Пересечение SE с ЕА выделяют в отдельное направление: ESE
    Если недостаточно, то набираем в гугл: «Systems Engineering» «Enterprise Architecture».
    
    Нет. В расчете подъемной силы крыла нет никакого управления.
    
    Сам расчет уже предполагает, что нужен для управления.
    
    … и начинаете спорить с собственным же утверждением.
    Но вернемся к вопросу: что такое «инженерная дисциплина»? Каково ее определение? Какими свойствами она обладает?
    
    БСЭ: www.ngpedia.ru/id6004p1.html
    studopedia.ru/4_14767_programmnaya-inzheneriya-kak-inzhenernaya-distsiplina.html
    
    Не используйте андроид.
    
    Снова смеетесь? Вы в магазин телефонов заходили? На полке лежат только телефоны с андроид и пара «огрызков».
    У покупателя нет выбора. Точнее есть из «плохо» и «очень плохо».
    
    Я не против ОС андроид — я против того, чтобы гугл ставил обязательным условием использования телефона (причем как «звонилка») — условие использования сервисов гугл.
    
    Если завтра огрызок и гугл попадут в список запретных в стране организаций, то мобильная связь в стране рухнет. Хотя гугл и не производит телефоны.
    Даже без такого списка ситуация уже доведена до абсурда: гугл заблокирует Вашу учетку и не даст создать новую и Вы останетесь не только без приложений, но теперь уже и без связи: телефон даже не звонит, т.к. требует для этого учетку гугл.
    
    Завтра каждый кран подачи воды в квартиру будет содержать «клапан гугл», требующий «активную учетку», и когда учетку заблокируют, то все погибнут от жажды. Это тем, кто «не верит в технологическую независимость».
    
    lair
    15.01.2018 14:25
    #10616916
    Например, также думают Авторы: В. К. Батоврин. Ф. И. Голдберг. А. В. Александров.
    Системная инженерия, или системотехника — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем
    Не же, не думают. В определении написано: "дисциплина, которая изучает". Это не значит, что изучаемое должно строиться на этой дисциплине.
    
    Множество других авторов также подчеркивает, что по SE хоть и можно строить простые системы, но задумалась она именно под проектирование «сложных» и «больших».
    То, что SE задумывалась под проектирование A, не означает, что для проектирования A обязательно использовать SE.
    
    Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
    Это отдельное направление. И там все еще не сказано, что это то же самое, что BPM или EA. Это просто применение принципов SE к предприятию.
    
    Сам расчет уже предполагает, что нужен для управления.
    Это не отменяет того, что в расчет управление не входит.
    
    www.ngpedia.ru/id6004p1.html
    Эта ссылка у меня не открывается.
    
    studopedia.ru/4_14767_programmnaya-inzheneriya-kak-inzhenernaya-distsiplina.html
    По этой ссылке сказано, что программная инженерия — это инженерная дисциплина, но нет определения инженерной дисциплины.
    
    На полке лежат только телефоны с андроид и пара «огрызков».
    Это немножко неправда.
    
    Я не против ОС андроид — я против того, чтобы гугл ставил обязательным условием использования телефона (причем как «звонилка») — условие использования сервисов гугл.
    Против — не используйте телефоны с ОС Андроид. Вот вам звонилка.
    
    Завтра каждый кран подачи воды в квартиру будет содержать «клапан гугл», требующий «активную учетку», и когда учетку заблокируют, то все погибнут от жажды.
    Нет, не будет.
    
    Это тем, кто «не верит в технологическую независимость».
    А технологическая независимость ничего не изменит. Просто блокировка учетки будет не у Гугла, а у Яндекса.
    
    bipiem Автор
    16.01.2018 01:56
    #10617908
    Эта ссылка у меня не открывается.
    
    Да, перестала работать. Вот такие wiki.
    Это была: Большая энциклопедия нефти и газа, а уже там «инженерная дисциплина».
    
    Просто блокировка учетки будет не у Гугла, а у Яндекса
    
    Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».
    Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.
    Остальные ответы позже.
    
    lair
    16.01.2018 11:25
    #10618348
    Да, перестала работать. Вот такие wiki.
    Лишний пример, почему надо не просто кидать ссылки, а приводить атрибутированные цитаты.
    
    (на StackOverflow, скажем, просто не пропускают ответы, состоящие только из ссылки)
    
    Я бы законом запретил подобную привязку «телефона», но видимо без нее «никак».
    Еще один любитель законно введенных монополий.
    
    Точнее блокировка учетки будет не у гугла или яндекса, а у соответствующего правительства, которое их контролирует.
    Спасибо, я как-нибудь без этого обойдусь.
1. bipiem Автор
  14.01.2018 21:43
  #10615954
  Часть 2
  
  и SE, и EA, и BPM неизбежно частью своей являются гуманитарными дисциплинами)
  
  Для меня это новость.
  
  Так вот, многие люди вообще не считают, что к гуманитарному знанию применим научный подход (та его часть, которая с экспериментами и доказательством).
  
  я все же про то, что можно проверить опытным путем и мне казалось, что все законы и утверждения SE, EA, BPM могут (должны) быть апробированы. При условии, что SE, EA, BPM — устойчиво «встанут» на путь науки и инженерии.
  
  Так вот, в программировании, и вообще в IT это более чем верно; более того, я склонен думать, что сроки сейчас еще меньше.
  
  Я привел личный опыт. Для меня именно те сведения были более значимыми, чем «современная литература». Правда, читал избирательно — далеко не все, но ее появилось «очень много», как стог сена (может иголки не заметил).
  
  Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
  А им намного больше 15 лет.
  
  И как этот «ключевой документ» отвечает на (а) вопросы управления жизненным циклом и (б) вопросы о целях и задачах?
  
  На эти вопросы – никак, но это все равно ключевой «документ – артефакт» в SE.
  Хорошо, а Ваше мнение – какой документ самый ключевой?
  
  Гигантский, очевидно. Как вы предлагаете разрабатывать систему без ТЗ?
  
  Да, большинство систем должны просто тиражироваться. Даже если есть особенность, то не нужно составлять 50 страниц абстрактных требований, а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.
  
  ОЧЕНЬ мало людей, кто может составить качественное ТЗ. Почти все ТЗ – это «филькина грамота» и они «работают» в интересах поставщика, а не заказчика: лишь на том принципе, что заказчик никогда грамотное ТЗ не составит. Тогда разработчик говорит «сам дурак» и требует деньги на доработку. Хотя изначально понимает, что нельзя никак сделать качественное ТЗ.
  
  Чтобы составить грамотное ТЗ – нужно большие трудозатраты (причем периодические и поэтапные уточнения). Мне попадались оценки, что грамотное ТЗ «стоит» не менее 30% общих трудозатрат на проект.
  Иначе получается типовой сценарий, смотрите картинку Проект «Тарзанка»
  Мне казалось, что это уже понятно многим. Сейчас иногда встречается договоренность, что договор предусматривает 30% доработок по уточнению ТЗ при фиксированной стоимости работ.
  
  ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем. Но это видимо лишь в будущем, пока такие простые истины еще не очевидны и победа за «управленческими уловками» подрядчиков.
  Отвечать лучше отдельным постом, уверен, что это будет отдельная дискуссия.
  
  Осталось всего ничего — придумать критерий «лучшего решения».
  
  Вот именно. Я уже про этот «трюк» указывал в статье.
  Под вывеской «Best Practice» — часто «подсовывают» совсем не практику (не публикуют ее, все NDA и ДСП), и совсем не понятно почему она «лучшая». Это вопрос к SE, ЕА, ВРМ.
  1. lair
    15.01.2018 11:24
    #10616450
    Для меня это новость.
    Я заметил.
    
    я все же про то, что можно проверить опытным путем
    Ну вот часть гуманитарного знания нельзя проверить опытным путем.
    
    Повторюсь: с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
    А им намного больше 15 лет.
    А это engineering details? Не думаю.
    
    Я привел личный опыт.
    Опыт против опыта. 20 лет назад я сидел на платформе, которой сейчас не существует, разрабатывая программы на языке, который сейчас развивается совсем в другую сторону. Никакие детали моего тогдашнего опыта (в отличие от принципов) для меня сейчас неприменимы.
    
    Да, большинство систем должны просто тиражироваться.
    Чтобы тиражироваться, все равно нужно ТЗ.
    
    а нужно указать два предложения, в которых будет сказано: чем система должна отличаться от существующего аналога или типовой конфигурации.
    … и потом 50 страниц анализа, как эти отличия не конфликтуют с существующей системой.
    
    Чтобы составить грамотное ТЗ – нужно большие трудозатраты
    Да, это так. Но это никак не значит, что ТЗ не нужно.
    
    ТЗ – это исключительная ситуация, оно только для проектирования принципиально новых систем
    Вы не можете внедрить систему без ТЗ. Ну заменится у вас ТЗ на разработку на ТЗ на внедрение — что, легче станет?
    
    Вот именно. Я уже про этот «трюк» указывал в статье.
    И сам же его и применил.
    
    bipiem Автор
    15.01.2018 14:34
    #10616936
    Вы не можете внедрить систему без ТЗ.
    
    Можно сослаться ровно также: внедрить «точно также» как «там — то» (конкретно где, например, в своей дочерней компании).
    Обсуждение подходов к ТЗ и проблем «управления требованиями» — заслуживает отдельной статьи.
    
    И сам же его и применил.
    
    Я критиковал подмену «Лучших практик» (псевдо-лучшие практики), т.е. когда сегодня это крылатое выражение применяется к «непрактикам» (не опубликованным и вообще неизвестно внедренным ли) и «нелучшим» или «лучшим», но с позиций «управленческая уловка», «маркетинговый обман», «лживый пиар» и т.п.
    Когда я говорю о правильных «Best Practice», то я и подчеркиваю, что первый критерий — это опубликованность: содержание рабочего проекта или возможность доступа к самой конечной системе или другие доказательства «практики». Иначе разговоры уходят в плоскость мифологии.
    Разобраться бы вначале с первым, а то приходится сравнивать «нули с нулями».
    
    lair
    15.01.2018 14:36
    #10616946
    Можно сослаться ровно также:
    Это означает, что вы будете использовать ТЗ, написанно "там-то". А перед этим вам надо доказать его применимость (это я говорю как человек, который несколько раз делал реализации "точно так же, как", а потом выяснялось, что они неприменимы).
    
    Когда я говорю о правильных «Best Practice», то я и подчеркиваю, что первый критерий — это опубликованность: содержание рабочего проекта или возможность доступа к самой конечной системе или другие доказательства «практики». Иначе разговоры уходят в плоскость мифологии.
    Разобраться бы вначале с первым, а то приходится сравнивать «нули с нулями».
    Нет смысла разбираться с первым, если нет второго. Вот опубликуют люди десять практик — как вы будете их сравнивать на лучшесть? Пока нет этого ответа, непонятно, зачем публиковаться.
    
    bipiem Автор
    15.01.2018 22:15
    #10617712
    Это означает, что вы будете использовать ТЗ, написанно «там-то». А перед этим вам надо доказать его применимость (это я говорю как человек, который несколько раз делал реализации «точно так же, как», а потом выяснялось, что они неприменимы).
    
    Одна из ключевых мыслей, которую пытаюсь донести через «ТЗ»: не нужно перекладывать внутренние риски подрядчика на заказчика.
    Если заказчик ткнул на аналог и сказал «хочу такую же», то это уже риск подрядчика, что две системы не совпадут.
    Здесь еще будет играть фактор, что все стандартное и типовое будет на порядок дешевле и надежнее нетипового и уникального.
    
    Нет смысла разбираться с первым, если нет второго. Вот опубликуют люди десять практик — как вы будете их сравнивать на лучшесть? Пока нет этого ответа, непонятно, зачем публиковаться.
    
    Когда опубликуют, то желающие сами найдут критерии «хорошо» и «плохо» и выберут исходя из них «свою Best Practice». Главное, чтобы было из чего выбирать и возможность выбора.
    
    Самый простой из критериев: функционал \ стоимость.
    При публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок — и это норма для нашего рынка, некоторые скандалы даже дошли о печати.
    Дельта будет означать размер маржи подрядчика и откатов. Собственно, во многом из-за этого и не публикуют ни проекты, ни их стоимость. Это же «страшная тайна».
    
    lair
    15.01.2018 23:00
    #10617760
    Если заказчик ткнул на аналог и сказал «хочу такую же», то это уже риск подрядчика, что две системы не совпадут.
    Наоборот, подрядчик ничем не рискует: дали ТЗ — сделал по ТЗ. Это заказчику рискует тем, что полученное по его ТЗ его же не устроит.
    
    Здесь еще будет играть фактор, что все стандартное и типовое будет на порядок дешевле и надежнее нетипового и уникального.
    Ну да, будет дешевле. Но будет ли решать нужные задачи?
    
    Когда опубликуют, то желающие сами найдут критерии «хорошо» и «плохо» и выберут исходя из них «свою Best Practice».
    Тогда можно и не публиковать ничего. Люди, которые заказывают работу, уже так делают.
    
    Самый простой из критериев: функционал \ стоимость.
    Теперь давайте найдем способ объективно оценить функциональность.
    
    При публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок
    Нет, не выяснится, потому что вы не системы предлагаете публиковать.
    
    bipiem Автор
    16.01.2018 01:20
    #10617892
    ТЗ его же не устроит.
    
    Мы же говорили, что в любом случае «обычное ТЗ» его «не устроит», потому что, это «филькина грамота», т.к. за «правильное ТЗ», стоимостью 30% работ по проекту — никто платить не готов.
    
    Теперь давайте найдем способ объективно оценить функциональность.
    
    Вы считаете, что два технических устройства или два программных изделия нельзя сравнивать (оценивать) по функциональности?
    Железку с железкой, программу с программой?
    
    Нет, не выяснится, потому что вы не системы предлагаете публиковать.
    
    Я предлагаю
    для ЕА – публиковать: корпоративную архитектуру (рабочую) + библиотеку эталонных архитектур (по типам предприятий);
    для ВРМ – публиковать: рабочие бизнес-процессы (а также всё к ним привязанное, типа RACI, метрики и т.п.) + каталоги типовых процессов (APQC PCF и т.п.);
    для SE публиковать: эскизный, технический и рабочий проект + исходное типовое решение (по видам изделий).
    
    Знак «+» отделяет «рабочую часть» (реализацию) от «эталонной»,
    т.е. «реальный проектный мир» от «эталонного проектного мира»,
    примерно как у Канта: «мир вещей» и «мир идей».
    А Ваша была какая версия?
    
    lair
    16.01.2018 11:23
    #10618332
    Мы же говорили, что в любом случае «обычное ТЗ» его «не устроит»
    Это вы говорили. Я с этим не соглашался.
    
    И да, речь-то не об этом, а о том, чьи риски.
    
    Вы считаете, что два технических устройства или два программных изделия нельзя сравнивать (оценивать) по функциональности?
    Я считаю, что это сложно делать объективно в общем случае. Вот есть два фотоаппарата, в одном только матричный замер экспозиции, в другом — только точечный. Как должны соотноситься их цены?
    
    И это мы еще не перешли к надежности.
    
    Я предлагаю
    И ничто из этого — не система. Между проектом и реализацией — пропасть.
    
    bipiem Автор
    16.01.2018 15:04
    #10618860
    И ничто из этого — не система. Между проектом и реализацией — пропасть.
    
    Подскажите тогда, в чем Вы видите различие между «проектом», один из документов (обложка) которого показан на рисунке ниже, и «реализацией»?
    
    В помощь: Книга Методы инженерного творчества, Шипинский
    
    Что вообще по-Вашему возможно публиковать «в принципе»? Какие артефакты? Публиковать «реализацию»?
    
    lair
    16.01.2018 15:08
    #10618872
    Подскажите тогда, в чем Вы видите различие между «проектом», один из документов (обложка) которого показан на рисунке ниже, и «реализацией»?
    Я могу взять это "описание программы", пойти и запустить? Нет? Тогда оно для меня бесполезно.
    
    Что вообще по-Вашему возможно публиковать «в принципе»? Какие артефакты?
    Зависит от целей публикации, очевидно же.
    
    bipiem Автор
    16.01.2018 18:37
    #10619448
    Я могу взять это «описание программы», пойти и запустить? Нет? Тогда оно для меня бесполезно.
    
    Такие понятия как «документация на программу» (точнее «программное изделие») Вы как себе представляете?
    Указанная документация по-Вашему «бесполезна»? Для чего тогда подобную документацию изготавливают? Ей литеры присваивают?
    
    Зависит от целей публикации, очевидно же.
    
    Пытаюсь от Вас получить прямой ответ, и все никак.
    Какие могут быть тогда вообще «цели публикации» и «что» под конкретную цель нужно публиковать?
    
    lair
    16.01.2018 18:41
    #10619456
    Указанная документация по-Вашему «бесполезна»?
    Она бесполезна для конечного заказчика в отрыве от программы.
    
    Какие могут быть тогда вообще «цели публикации» и «что» под конкретную цель нужно публиковать?
    А это вы предлагаете публиковать, а не я. И вы пишете "при публикации выяснится, что две идентичные по всем характеристикам, а может и по составу, вплоть «до винтика и битика», системы будут отличаться по стоимости на порядок — и это норма для нашего рынка, некоторые скандалы даже дошли о печати". Если это ваша цель, то вам придется выкладывать (а) сами "изделия" и (б) методику и результаты их испытаний. Иначе ваша цель достигнута не будет.
    
    Я-то просто публикую свои разработки в open-source, и мои цели это прекрасно решает.
    
    bipiem Автор
    16.01.2018 19:16
    #10619534
    Если это ваша цель, то вам придется выкладывать (а) сами «изделия» и (б) методику и результаты их испытаний. Иначе ваша цель достигнута не будет.
    
    Более точно было бы так:
    — изделие (система), результат SE, его вообще-то выложить сложно, т.к. в общем случае это «Большая система», включая территориальную сеть, объекты, средства автоматизации и может быть программы (причем не обязательно);
    — документация на разработку (конструкторская, программная)
    — документация на эксплуатацию (эксплуатационная)
    — прочая документация (ПМИ, ТУ и т.п.). Есть еще направления «технологическая док.», «ремонтная док.» и т.д.
    Это взгляд со стороны «отечественной SE».
    
    Я-то просто публикую свои разработки в open-source, и мои цели это прекрасно решает.
    
    Что конкретно Вы публикуете? И какие цели это решает?
    
    lair
    16.01.2018 20:55
    #10619756
    изделие (система), результат SE, его вообще-то выложить сложно
    Это повод задуматься о реализуемости идеи целиком.
    
    Что конкретно Вы публикуете?
    Свои разработки как программиста.
    
    Что конкретно Вы публикуете?
    Во-первых, самореализация. Во-вторых, вклад в Open Source.

lair
14.01.2018 20:03
#10615892
(del, ошибся уровнем)

sufferingluck
15.01.2018 14:16
#10616884
По своему опыту SE могу сказать, что оно всегда начинается в оборонных отраслях, затем полезный выхлоп переносится на технологии и бизнес-процессы, необходимые для реализации принятой большой или даже сверхбольшой системы и ее элементов (тут уже речь о BPM+EA), и, наконец (но не в нашей стране), желание подзаработать денег на супердостижениях в ходе реализации такого сложного и передового проекта, который был затеян, приводят к «Best Practice» & ххBOK, а они, в свою очередь, рождают новое поколение прикладных гаджетов, полезняшек и протчая и протчая, в итоге за ту же себестоимость появляется принципиально новый продукт, новое поколение «поющих утюгов» и прочей утвари.
1. bipiem Автор
  15.01.2018 21:19
  #10617642
  Можете конкретизировать? «по своему опыту SE» какой-нибудь пример?
  1. sufferingluck
    15.01.2018 22:02
    #10617690
    Возьмем отрасль, в которой мы впереди планеты всей в настоящее время. Системы ПВО/ПРО. Всеобъемлющие по своей структуре, природе элементов, протоколам информационного взаимодействия, всегда построенные на базе разумного компромисса между идеальным представлением заказчика и достижимым уровнем технологий. Для реализации оптимального SE-проекта всегда требуются доработки существующих технологий, поиски новых способов организации взаимодействия как внутри кооперации исполнителей, так и внутри каждого предприятия такой кооперации — ВРМ+ЕА во всей красе и полноте; затем обучить непосредственно персонал этих предприятий, а также персонал, эксплуатирующий систему с учетом и использованием достижений «Best Practice» & ххBOK в этой отрасли. Получаем на выходе конфетку типа С-Х00, плюс новейшие технологии изготовления ее элементов, как правило, поддерживающие масштабирование и тиражирование, плюс новый уровень бизнес-процессов как внутри предприятий-изготовителей, так и по их взаимодействию, плюс новый уровень руководства персоналом, обеспечивающий осознанное выполнение им своих задач. Детализировать далее невозможно. Беда наша в том, что никакого выхлопа в обычную экономику данные достижения не привносят. Хотя… Люди перетекают иногда, что в общем-то, определенную ценность тоже имеет
    
    bipiem Автор
    16.01.2018 01:27
    #10617894
    Возьмем отрасль, в которой мы впереди планеты всей в настоящее время. Системы ПВО/ПРО.
    
    Вам об этом из зомбоящика рассказали?
    Лучше ему не верить, обычно в чем «мы впереди планеты всей в настоящее время» там не говорят: коррупция, особенно в оборонке (самая закрытая и коррумпированная структура – это первая военная тайна).
    
    Но даже если у нас еще и развивается ПРО (благодаря советскому заделу), то все равно это уже не так критично.
    Разговоры «про ПРО» (нераспространение ЕвроПРО, надежда на наше ПРО – не важно) – это «газетные байки», политическая пропаганда, примерно то же самое, что я рассказываю по теме ЕА\ВРМ\SE: «управленческие уловки» (management fad), пропаганда, fake news – причем с обеих сторон (мы и США).
    Нет защиты от МБР, ни у нас, ни у них, и – это вторая военная тайна.
    Пара ссылок:
    Межконтинентальная баллистическая ракета — абсолютное оружие. И это не преувеличение.
    …созданные ещё в 1970–80-е годы средства до сих пор легко преодолевают ПРО.
    
    … начинается создание сложных баллистических целей с сотнями и тысячами ложных элементов, и никаких противоракет для всего этого многообразия просто нет.
    
    Детализировать далее невозможно.
    
    Откуда такой вывод?
    делением атомного ядра управлять научились, а вот какую-то «детализацию» выполнить не сможем?
    
    плюс новый уровень бизнес-процессов как внутри предприятий-изготовителей, так и по их взаимодействию,
    
    Операционная модель коррупционных схем? В какой нотации?
    (шутка,… а может и нет, — для СКР может пригодиться)
    
    плюс новый уровень руководства персоналом, обеспечивающий осознанное выполнение им своих задач.
    
    Это про что? Про коммунизм? Про В. Губанова и П. Корчагина? Иначе, какое оно «осознанное» — работать, понимая что «результаты труда, так или иначе, присваиваются владельцами капитала»?
    
    Беда наша в том, что никакого выхлопа в обычную экономику данные достижения не привносят.
    
    А почему у них оборонка «привносит» в гражданку?
    ТСР\IP, тот же IDEF и масса всего остального IT-шного и даже BPM-ного.
    В чем сложности «у нас»?
    Поясните, «не жалея букв». Хотелось бы Ваше «развернутое пояснение», учитывая, что «родина» SE – все же оборонка.
    
    sufferingluck
    16.01.2018 09:13
    #10618108
    К сожалению, безапелляционность утверждений не оставляет мне пространства на развернутый ответ. Не смею детализировать, так как некоторая информация не теряет своей значимости в течение десятилетий. Смею лишь заметить, что реальность, а не фейковость возможностей ПВО/ПРО России подтверждается практически (читайте не геополитические обзоры, а просто информацию из Сирии, а также о результатах испытаний наших систем от С-Х00 до А-Х35). При том, что именно уровень системных проработок обеспечивает не только паритет, но и несомненное преимущество отечественных систем вооружений над уровнем наших «партнеров».
    А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.
    
    bipiem Автор
    16.01.2018 09:27
    #10618132
    безапелляционность утверждений не оставляет ...
    
    утверждений моих или конструктора Соломатина?
    В любом случае, мы оба можем ошибаться.
    
    А насчет выхлопа в гражданку — ответ на поверхности. Почему у нас нет малого и среднего бизнеса? Потому же нет и выхлопа в гражданку.
    
    У нас нет МСБ? Мне казалось его давно «как грязи». «На поверхности» ничего не увидел.
    
    Не теряю надежды на «Ваше развернутое пояснение, которое очень ценно, учитывая, что «родина» SE – все же оборонка».
    
    sufferingluck
    16.01.2018 10:14
    #10618192
    Соломатина, к сожалению, не знаю в проблематике ПВО/ПРО. Знаю Соломонова (который с другой стороны баррикад :) ), Басистова, Бункина, Ефремова, много можно назвать фамилий. Только зачем? Вопрос ведь заключается в другом. Вопрос в том, что локомотив SE — оборонка. Оно так и есть, здесь мы не спорим. И уровень развития данной отрасли инженерного искусства (знания либо технологии — слишком узко будет сказано) в СССР, а затем России пока еще достаточно высок. Базируется это на универсальной подготовке по программам еще советской средней и высшей школы, учившим не только набору знаний, но и методам самостоятельного их применения и дальнейшего самообразования. Что касается МСБ — его вклад в ВВП России составляет менее 20%. В то же время для Китая это более 60%. И при этих наших жалких 20% не менее половины предприятий МСБ являются инструментами для обнала, к сожалению. Хорошо знаю это, имея опыт работы и в банковской сфере. А почему не перетекает выхлоп из оборонки? Вот недавно была иллюстрация, когда штрафовали предпринимателя на Дальнем Востоке, фермера, который одел на свою буренку приемопередатчик GPS. Незаконно, ёшкин кот! Какие уж тут условия для МСБ вообще и для перетока в него передовых технологий и прочих достижений из оборонки, в частности? Дорога тут предстоит большая и тернистая. Но идти надо!
    
    bipiem Автор
    16.01.2018 21:40
    #10619822
    Вопрос в том, что локомотив SE — оборонка. Оно так и есть, здесь мы не спорим. И уровень развития данной отрасли инженерного искусства (знания либо технологии — слишком узко будет сказано) в СССР, а затем России пока еще достаточно высок. Базируется это на универсальной подготовке по программам еще советской средней и высшей школы, учившим не только набору знаний, но и методам самостоятельного их применения и дальнейшего самообразования.
    
    Хотелось бы поподробней. Я помогу вопросами:
    Отечественные SE-ГОСТы, включая РВ 15.ххх устаревают, не развиваются. Что делать оборонке?
    Использовать их «до последнего» или «садиться» на западные SE?
    Переходить на SEBOK, BKCASE (МО США там участвует) и т.п.?
    
    Ниже обсуждаем профстандарт «Инжнер-Системотехник», «Инженер по SE».
    Что должно войти в него? Желательно дать предложения в той же ветке.
    
    По rusEA что предложите? Внедряем DoDAF или отечественный фреймворк?
    BPM как используете? Какие другие проблемы отечественного оборон-SE? Как их решать?
    
    System12
    16.01.2018 10:26
    #10618212
    Операционная модель коррупционных схем? В какой нотации?
    (шутка,… а может и нет, — для СКР может пригодиться)
    
    Встречал попытку от одного украинского консультанта на уровне «рисовалки» с нестандартной нотацией.
    
    bipiem Автор
    16.01.2018 18:27
    #10619426
    Как это хоть примерно выглядело?
    
    System12
    16.01.2018 18:38
    #10619450
    Кружки со стрелочками. Точно не помню, не сохранял, где видел не помню. Но заявка была крутая на анализ системы коррупции. По мне не более чем один из вариантов анализа рисков на уровне определения угроз.

lotse8
15.01.2018 18:25
#10617450
Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку». Не может быть одного универсального ТЗ или «архитектуры» или еще чего в этом роде на все случаи жизни и для всех проектов. Для всех могут быть общие требования, которые потом в любом случае необходимо детализировать и творчески применять для каждого конкретного более или менее сложного проекта. Это только болты можно точить по единому стандарту, да и то разный металл для разных областей применения. Даже в бывшем СССР, на опыт которого Вы ссылаетесь, были ГОСТы — общие требования, и потом для каждого изделия уже конкретно своя документация и свои требования.

Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода? Я могу представить только так: для всех — общие требования, для каждого свой проект в зависимости от климатической зоны, вида грунтов и сейсмоактивности. Да, могут быть и типовые проекты для постройки одинаковых строений, но только в одном и том же регионе.

Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику. Да, не полностью переделывать, что-то можно использовать и оставить как есть, но не полностью 100% это будет применимо.

Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
1. bipiem Автор
  15.01.2018 22:10
  #10617702
  Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».
  
  Смотря, что под ними понимать.
  
  Под «серебряной пулей» я понимаю НОТ и подобные научные подходы (СОВНОТ во главе с Куйбышевым был образован еще в 1923).
  Про научный подход, унификация, стандартизация, Global BPM, развитие «Open Source» до «Открытый процесс» и т.п. обсуждали в
  Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
  
  Эволюционируя от «Кадры решают всё» к «Процессы решают всё» советская научная мысль пришла бы к этому и сегодняшние павильоны ВДНХ трансформировались бы в выставку Хороших Процессов народного хозяйства (e-выставка ХПНХ). А принцип «Open Process» был бы принудительно инкорпорирован во все отрасли народного хозяйства
  
  Не только само производство товаров и услуг, но и инженерия и даже наука может быть организована в виде «промышленного конвейера» (почти по Г. Форду). По открытиям и изобретениям:
  
  • Мы не столько изобретаем решения, сколько открываем их. Соболезнования творческим натурам: это всего лишь обрабатывающий информацию голем, начищающий свое собственное эго и озабоченный поднятием кармы.
  • Интеллект — это социальный эффект, хотя он и ощущается как что-то личное. Человек, отрезанный от других, перестает думать. Мы не можем ни определить проблемы, ни оценить их решения без других людей.
  
  и как реализация этого:
  должен быть всего лишь налажен «промышленный конвейер изобретений», нечто подобное «Системной Инженерии», — как технология «Научной инженерии».
  Т.е. свод знаний «по проектированию \ производству открытий и инноваций».
  Подробнее здесь «Социальная архитектура»
  
  Я полагаю, что, не смотря на наличие «гениальности», — как важного фактора развитие науки, эволюция науки в целом — идет вне зависимости он него.
  …
  Лучший пример подобного конвейера, организованного Сталиным и Берия, – это Советский атомный проект.
  
  «Волшебные таблетки» это:
  Это подходы к типовому проектированию — как методологии «Best Practice» типа SE (но очищенного от болтовни, маркетинга и пиара),
  это реальные и практические «Best Practice» (не псевдо, как сегодня), публикуемые типовые проекты, «полнометражные» примеры, архитектуры, референтные (эталонные) модели, отраслевые подробные классификаторы бизнес-процессов, ЧаВо по их развертыванию (внедрению), регламенты (графические, табличные, текстовые) и т.п.
  
  Главное создать среду (инфраструктуру) для обмена опытом путем публикации успешных и неуспешных (это тоже очень важно) реализаций, их артефактов. А эти реализации сами покажут, какие практики «Лучшие», а какие не очень.
  
  Вы думаете, что проекты разных системных интеграторов сильно отличаются друг от друга?
  Да – отличаются.
  Одни изобретая один и тот же «велосипед», наступили «вслепую» на 50 «граблей», другие при таком же «велосипеде» также «вслепую» на 150 граблей.
  А если бы им все эти грабли заранее «подсветили» (типовые проекты, эталонные модели и т.п.), то не только легче было бы пройти «инженерной тропкой», но и «изобретать велосипед» вообще не пришлось бы – а лишь его заимствовать (типовое проектное решение).
  
  Это как раз позволит: «чтобы не тратить лишние ресурсы»
  Если мысль не донес, — скажите, я по Вашему тексту отвечу что-нибудь на примерах.
1. System12
  16.01.2018 09:35
  #10618150
  Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».
  
  Скорее здравый опенсорс по связи теории и практики.
  
  Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода?
  
  Технический регламент по общим требованиям вполне возможен.
  
  Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику.
  
  Самое забавное в том, что в обеих случаях главный бизнес-процесс абсолютно одинаков — Оказание услуг (торговли).
  
  Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
  
  Помнится меня когда-то учили тому, что решением задачи является сумма общего рещения и решения при заданных начальных условиях.

lingvo
16.01.2018 09:53
#10618166
Могу сказать, что в принципе считаю себя Системотехником, так как контролировал разработку достаточно сложной и ответственной системы управления в энергетической сфере.
По дисциплинам — да это требует знаний и опыта в достаточно разных сферах — механики, электроники, софта, измерений, стандартизации, тестирования и еще кучи других, так как даже простые решения о том, реализовать ту или иную функциональность в программе, железе, ПЛИС или микроконтроллере с учетом всех факторов, включая ресурсы и наличие/наем нужных разработчиков, даются не так легко.
Большим подспорьем в конкретном случае с АСУ является моделирование — потому что дает возможность хоть на раннем этапе оценить требования к системе и прикинуть, как может быть решена основная задача. Но к сожалению тут универсальных средств нет и промоделировать систему управления предприятием на той же системе уже невозможно.
1. bipiem Автор
  16.01.2018 14:55
  #10618846
  Могу сказать, что в принципе считаю себя Системотехником
  
  Тогда как по-Вашему, что должно войти в профстандарт «Инжнер-Системотехник», «Инженер по SE»?
  Насколько понимаю, такого ПрофСтандарта пока нет, но есть, например,
  Специалист в области проектирования автоматизированных систем управления технологическими процессами
  1. System12
    16.01.2018 15:59
    #10619078
    Самое забавное в такой профессии это то, что по некоторым исследованиям только 15% людей обладают системным мышлением.
  1. lingvo
    16.01.2018 16:54
    #10619222
    Из того, что мне пригодилось и в принципе самое главное:
    
    Умение гуглить и находить информацию в сети Интернет в том числе общение на тематических форумах
    
    Основы электроники и схемотехники
    
    Основы программирование микроконтроллеров
    
    Основы и устройство DSP, цифровой обработки сигналов, цифровых фильтров
    
    Основы ПЛИС
    
    Языки программирования Си, Java(сегодня может быть Питон)
    
    Cтандартизация и сертификация
    
    Основы проведения экспериментов, измерений и анализ их результатов
    
    Метрология
    
    Английский язык
    
    Моделирование — Matlab/Simulink, Pspice
    
    Основы 3D проектирования и моделирования — Solidworks, Comsol Multiphisics.
    
    Менеджмент требований
    
    Основы систем контроля версий, баг-трекеров.
    
    Теория автоматического управления
    
    IoT
    
    Локальные Сети (CAN, RS482, Modbus, Ethernet и т.д.)
    
    Оформление схем и документации по Госту — Спецификаций, Паспортов, Инструкций и т.д.
    
    По практике — как минимум 2-3 + дипломник реальных проекта на микроконтроллерах/ПЛИС c использованием отладочных плат от начала и до конца с документацией.
    
    Это из того, что вспомнил специфического.
    
    System12
    16.01.2018 17:09
    #10619240
    Это не системщик в понимании темы.
    
    lingvo
    16.01.2018 17:33
    #10619300
    А кто?
    
    ПС. Забыл еще основы теории надежности
    
    System12
    16.01.2018 17:51
    #10619340
    Инженер по АСУ.
    Для системщика по теме обсуждения нужны менеджмент, маркетинг, логистика, кибернетика, теория систем и много еще разной зауми, включая основы бухучета.
    Не говоря уже о базовых матстатистике и теории вероятности. ПЛИС и многое прочее в реальности всего лишь практическое приложение к алгебре логики и прочему подобному.
    
    bipiem Автор
    16.01.2018 18:44
    #10619460
    Для системщика по теме обсуждения нужны менеджмент, маркетинг,
    
    Я тут ругаю маркетинг и менеджмент (точнее их уловки): «управленческие уловки» (management fad), пропаганду, манипуляцию терминами и т.п.
    а Вы их системщикам …
    Зачем маркетинг — то системщику? Продать свой проект?
    
    System12
    16.01.2018 18:51
    #10619478
    Я еще про психологию забыл! :))
    Что изучает маркетинг? — Внешнюю среду. Внешняя среда тоже система. От SWOT анализа Вы отказываетесь? От стратегического планирования тоже? И многих прочих критических элементах систем тоже?
    Что есть менеджмент без пены? Это наука об управлении человеческими организациями. Как без него строить социотехническую систему?
    
    bipiem Автор
    17.01.2018 00:41
    #10620056
    С таким подходом, Вы сюда все запихнете:
    А куда же без физики? А куда без сопромата? А куда без…
    
    System12
    17.01.2018 06:54
    #10620210
    Все зависит от того какое предприятие и какую систему Вы рассматриваете. Для ларька по продаже сигарет можно обойтись без них, а если рассматривать атомную электростанцию, то кроме физики и сопромата Вам понадобится еще много чего.
    
    lingvo
    16.01.2018 19:19
    #10619550
    Но без тех дисциплин, что я привел, системщик тоже будет неспособен разбить задачу на блоки и решить ее наиболее технически оптимальным способом. Не зная, что умеют ПЛИС, например, вы не сможете их правильно применить.
    Насчет ваших согласен. Из нетехнических специальностей мне пригодилось:
    
    основы логистики
    
    основы бухучета,
    
    определение себестоимости продукта/системы — калькуляции ROI/RORE
    
    основы ведения НИР, НИОКР, основные этапы разработки и исследований
    
    маркетинг, это в принципе для системщика управление требованиями — нет смысла туда углубляться глубже.
    
    System12
    16.01.2018 19:37
    #10619580
    Начнем сначала. Рассмотрим человека. Любой человек — система. Внутри него можно выделить еще ряд систем: пищеварения, дыхания, кровообращения и далее по списку. Вместе с тем человек входи в системы семья, работа, государство и далее по списку.
    С моей точки зрения Вы считаете системщиком специалиста по системе автоматизации организации. Но для меня это только одна из подсистем организации. Вспомнилась одна работа. Нужно было автоматизировать один процесс. Чтобы я не отвлекался на мелочи, мне в помощь дали программиста. Мы сделали эскиз и показали его заказчику. Ему очень понравилось и он начал плотно контролировать ход работы. Через некоторое время он потребовал убрать меня из проекта потому что программист сидел целыми днями, а я забегал к нему на пару минут, смотрел и говорил что доделать, а что переделать. Мол мне не за что платить. Я ушел из проекта и он рассыпался. Сам программист сказал что его можно заменить на любого, а меня заменить в этом проекте некем, потому что я детально знаю не только сам процесс, но и потребности с возможностями всего его окружения. С точки зрения многих участников этого форума заказчик скорее всего был прав, ведь за что платить мне больше программиста если я не написал ни строчки кода, только мешал работать. А с моей точки зрения я работал системщиком, которым может работать не каждый программист. :))
    
    System12
    16.01.2018 19:44
    #10619590
    Не зная, что умеют ПЛИС, например, вы не сможете их правильно применить.
    
    Помнится в одном старом американском учебнике по программированию была глава типа «А всегда ли нужно программировать микроконтроллер?»
    Идея проста. Одно и тоже устройство можно реализовать в жестком железе (начиная с логических микросхем малой или большой интеграции, одной из которых является ПЛИС) или на универсальный блок запрограммировать специальный софт. Далее никакой техники, одна экономика, демонстрирующая случаи, когда можно все сделать на ПЛИС, а когда лучше микроконтроллер с программой. Оплата программиста в нем считалась значительно больше стоимости железа. :))
    
    lingvo
    16.01.2018 19:57
    #10619620
    Я вам больше скажу. Одну и ту же систему можно сделать на ПЛИС или DSP, микроконтроллерах ARM или процессорах Intel, материнках в формате ATX, ноутбуке или стойках cPCI,VPX, с использованием интерфейсов Ethernet или CAN или RS485 или своего доморощенного протокола, с использованием PCIexpress или без. И в итоге получить решение, которое функционально делает то же самое, но будет иметь абсолютно разные затраты на разработку и ее длительность, стоимость железа, возможность серийного производства, имеет разные требования к экспертизе разработчиков и еще множество отличий.
    Чистая экономика, конечно...
    
    System12
    16.01.2018 20:00
    #10619634
    Я про это и говорю.
    
    bipiem Автор
    17.01.2018 00:43
    #10620058
    А «бухучет» — то зачем инженеру?
    Управленческий и налоговый учет тоже нужен?
    
    System12
    17.01.2018 06:57
    #10620212
    Мы говорим об инженерах или о специалистах по системе всего предприятия? Система управления без учета неработоспособна. Управлять можно только тем, что можно измерить. В том числе инструментами бухгалтерского и управленческого учета.
    
    bipiem Автор
    17.01.2018 15:07
    #10621076
    Мы говорим об инженерах или о специалистах по системе всего предприятия?
    
    Ветка называется:
    что должно войти в профстандарт «Инжнер-Системотехник», «Инженер по SE»?
    Инженер — это точно не бизнесмен и бизнес-навыки «для профессии» вряд ли нужны. Знание предметной области (отрасли) нужно, но при этом достаточно что «бухучет есть» и очень примерно «что это такое».
    
    Если мы говорим об ЕА, то разработчик и администратор ЕА (архитектор) должен находиться в треугольнике «бизнес» — «технология» — «инфраструктура, включая ИТ» — точнее в середине этого треугольника, такой «корпоративный архитектор» (не системный архитектор) должен знать по «соответствующей» выжимке с каждой стороны треугольника.
    
    У системного архитектора уже свой, и другой «треугольник», и его навыки уже будут ближе к инженеру SE.
    Поэтому «системотехник» (SE) и «корпоративный архитектор» — это во многом разные направления.
    Об этом говорил здесь
    «Хочешь быть системным архитектором? Там только свет и чистота…»
    Хорошо бы конечно ролевую структуру всех этих SE\ВРМ\ЕА нарисовать.
    
    Есть проект профстандарта на специалиста ВРМ.
    
    System12
    17.01.2018 15:19
    #10621092
    Извините, но даже генеральный директор, его замы и другие специалисты, не имеющие акции предприятия, бизнесменами не являются. Вы для начала определитесь на каком уровне работают «системотехник» (SE) и «корпоративный архитектор». Если это рядовые специалисты-инженеры, то я тогда вообще ничего не понимаю. По моему скромному мнению вопросы архитектуры и прочие системные вопросы предприятия это вопросы исключительно топменеджмента, имеющего соответственную подготовку и возможности.
    Ну и разумеется разного калибра консалтеров. :))
    
    bipiem Автор
    17.01.2018 16:34
    #10621276
    Вы для начала определитесь на каком уровне работают «системотехник» (SE) и «корпоративный архитектор». Если это рядовые специалисты-инженеры, то я тогда вообще ничего не понимаю
    
    Ха-рооо-ший вопрос. Уверен, что «корпоративные архитекторы» — не топы, но вот целевые потребители описания ЕА — топы.
    
    «Классический» Системотехник — это вообще почти всегда внешний подрядчик, т.к. его задача «изо дня в день» разрабатывать что-то новое, сложное и большое.
    Они обычно «живут» в проектных организациях, хотя некоторые «операционные» (классические) компании могут и их себе позволить.
    
    Это проектная работа, фактически по проектированию предприятия и его «крупных» частей. Жизнь предприятия в условиях постоянных крупномасштабных" изменений — видимо не стоит считать «нормой».
    
    System12
    17.01.2018 16:41
    #10621304
    А я наоборот абсолютно уверен в том, что корпоративный архитектор это топ. В ряде компаний он называется «Директор по развитию». Кого он возьмет к себе в помощники это его проблема, имеет право советоваться хоть с уборщицей. А целевой потребитель — вся организация. Кто персонально определяет устав предприятия. Это может быть учредитель, совет директоров и т.д. Вопрос ведь не в описаниях, а в их реализациях. По простейшей архитектурной модели — штатному расписанию принимают на работу и устанавливают зарплату.
    
    bipiem Автор
    17.01.2018 17:54
    #10621484
    -1
    А я наоборот абсолютно уверен в том, что корпоративный архитектор это топ. В ряде компаний он называется «Директор по развитию».
    
    Уверен, что «Директор по развитию» и слов то таких не знает: The Enterprise Architecture Body of Knowledge (EABOK), Захман, ТОГАФ и т.п.
    
    Вы под ЕА понимаете то, что в этих книжках сказано?
    «Директор по развитию» даже в бизнес-архитекторы записывать не нужно.
    
    Попробуйте составьте framework своего домохозяйства, как я предлагал здесь:
    3 Конкурс на описание «household architecture»
    А Вы подобное хотите на топов «повесить»?
    
    А целевой потребитель — вся организация.
    
    Зачем описание ЕА уборщице и бухгалтеру?
    
    System12
    17.01.2018 18:02
    #10621506
    +1
    Уверен, что «Директор по развитию» и слов то таких не знает: The Enterprise Architecture Body of Knowledge (EABOK), Захман, ТОГАФ и т.п.
    
    Слов не знает, но ведь делает именно то, что в них написано! Когда-то в Росссии и слова бизнес не знали.
    
    Зачем описание ЕА уборщице и бухгалтеру?
    
    Ну если для Вас организация это уборщица и бухгалтер, то я тогда пас.
    
    bipiem Автор
    18.01.2018 00:45
    #10622080
    Слов не знает, но ведь делает именно то, что в них написано!
    
    Можно конкретику в терминах ТОГАФ или еще кого из ЕА, про деятельность «Директор по развитию» в роли корпоративного архитектора?
    
    System12
    18.01.2018 07:11
    #10622216
    Лениво переводить на «птичий язык».
    Читайте первое что нашел Великий Гугль и возможно увидите то, что роль архитектора предприятия написана несколькими фразами: www.rabota.ru/articles/hr/dolzhnostnaja_instruktsija_direktora_po_razvitiju_dolzhnostnye_objazannosti_direktora_po_razvitiju_obrazets_dolzhnostnoj_instruktsii_direktora_po_razvitiju-3999
    
    bipiem Автор
    18.01.2018 12:30
    #10622710
    Все равно, не понимаю.
    По Вашей ссылке приведена Должностная инструкция директора по развитию, должностные обязанности директора по развитию
    
    Описание ЕА может разрабатываться вообще без цели «развитие», просто для того чтобы зафиксировать «as is»:
    обычно «бардак в as is», но без надежды его упорядочить.
    
    System12
    18.01.2018 13:34
    #10622912
    +1
    Для Вас важнее описание чем работа? «Вам шашечки или ехать?» Описание того что есть в новой нотации ценности не имеет.
    
    bipiem Автор
    18.01.2018 13:56
    #10622986
    Я все равно не понял: когда делаем описание ЕА — только «as is» и вне любого развития, то при чем здесь директор по развитию «вообще», и тем более в роли корпоративного архитектора?
    
    System12
    18.01.2018 14:23
    #10623076
    Ответьте на простой вопрос: Зачем нужно это описание и именно в такой нотации?
    Чувствую скоро Вы скажете о том, что архитекторы (градостроительные) нужны только для того, чтобы работать экскурсоводами.
    Зачем новое проектировать? Нам лучше описать то что есть.
    
    lingvo
    17.01.2018 11:09
    #10620452
    В принципе основы бухучета требуются для того, чтобы корректно понимать себестоимость разработанного продукта и как он будет генерировать прибыль. Также чтобы понимать, что зарплату надо платить всем и вовремя, даже если работа есть только для одного — это поможет при планировании цикла разработки.

gimatdinov
16.01.2018 21:42
#10619826
bipiem не оставил выбора, придется применить магическое заклинание и открыть портал ACM.
1. bipiem Автор
  17.01.2018 00:28
  #10620036
  -1
  Да, верно: BPM-алхимики «плодовиты», у них мантр много, не меньше, чем у ЕА-алхимиков и SE. Напомню свои рассказы:
  Бизнес-процессы: Как все запущено и запутано. Глава Первая
  Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»
  Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
  по EA:
  Enterprise Architecture vs алхимия предприятия. Ключевые мифы
  Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие
  
  Первый «писк» моды «Adaptive Case Management» пришелся на 2010-11. Тогда он не позиционировался как «убийца BPM» и иногда назывался даже как: adaptive BPM, dynamic BPM, agile BPM и т.п.
  Это чтобы «плавно влиться» в рынок в составе раскрученного бренда «BPM».
  
  Потом пришло время «противопоставления»: не покупайте их «старый» BPM, берите наш «свежий» ACM!
  О подобном сценарии с BPM\BPMS – рассказывал в указанных статьях.
  
  Когда-то на «птичьем рынке» был классический прием (такой же management fad как в IT) по продаже щенков (BPM\BPMS\ACM etc):
  В коробке (Suite) продавца лежат несколько щенков – братьев от среднерослой дворняжки.
  
  Потенциальный покупатель: Какой милый у Вас щенок справа! Породистый? А большим или маленьким он вырастет?
  Находчивый продавец: Конечно породистый! Вы что сами не видите? А Вы любите больших или маленьких собак?
  — Очень люблю маленьких!
  — Как раз – то, что Вам нужно! Он только чуть-чуть подрастет и все!
  — Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!
  
  Следующий покупатель:
  — Какой милый щенок! Породистый? А большим или маленьким он вырастет?
  — А Вы любите больших или маленьких собак?
  — Люблю больших собак!
  — Как раз – то, что Вам нужно! Он, конечно же, вырастет огромным псом!
  — Как здорово! Как мне повезло, спасибо, покупаю, сдачи не нужно!
  
  Пойми своего клиента!
  
  Продавцы на «ИТ-рынке» также Вас спрашивают: «Вам что больше нравится: BPM или ACM»? И независимо от Вашего ответа Вашей покупкой окажется один и тот же «Management-щенок» (может с переклеенной этикеткой).
  
  Однако «высшим пилотажем» сейчас считается подход, когда их уже не противопоставляют друг другу, а говорят так:
  «и то и то — круто, поэтому у нас они оба – и в одном флаконе»!
  
  За примером ходить далеко не нужно:
  
  Адаптивный кейс-менеджмент сочетает в себе гибкость, социальную составляющую и возможность накопления опыта — то, чего не хватает традиционному BPM. Но на практике в одной организации могут быть и такие процессы, которые требуют строгой регламентации, и те, которые должны оставаться гибкими.
  
  Если для первых лучше использовать классический BPM-подход, то для вторых необходимо применять «Agile BPM» — то есть, АСМ.
  
  В продукте «ххххх» мы объединяем ACM и BPM-подходы, что позволяет перейти на новый уровень и значительно повысить эффективность в управлении процессами.
  
  Или другими словами:
  
  Покупайте в свой горем:
  ACM плюс BPM!
  Они — решенье всех проблем:
  И с ERP, и с CRM,
  А может и с BSDM.
  1. gimatdinov
    17.01.2018 08:52
    #10620262
    Во-первых, ACM это не BPM. Основа ACM — это обработка событий и ориентированность на Case (можно интерпретировать как «Дело»). Основа BPM — это в большей степени процессный подход.
    Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.
    
    bipiem Автор
    17.01.2018 14:13
    #10620956
    -1
    Во-вторых, использование анекдотов и рекламных выдержек не добавляет Вам никаких аргумент. Это может сработать только на людях до определенного возраста.
    
    Консалтерами все так сознательно запутано, что без упрощения — не разобраться с их «маркетинговой лапшой». А юмору «все возрасты покорны», поэтому не понял упрек на возраст.
    А что, на ком-то «шапка горит»?
    
    Пропущенные через «призму» юмора ультрамодные «аргументы консалтеров» позволяют лучше понимать: маркетинговый конвейер спекуляций, «управленческие уловки» (management fad), пропаганду, fake news.
    
    Бытовые аналогии понятным языком показывают «классические приемы» и техники продвижения универсальных волшебных «таблеток» с высокой стоимостью, но сомнительным составом.
    Очень многое, что пишут на эту тему и предлагают алхимики — не имеет никакого отношения ни к науке, ни к реальности (но ими позиционируется так).
    
    Основная причина популярности алхимии — это просто закрытие информации, «не публикация» реализаций, нет открытого обсуждения — как деталей самих проектов BPM\ЕА\SE, так и реального их «выхлопа» (восторженные речи на конференциях — не в счет).
    Есть позитивные движения, например, общенациональный конкурс «BPM-проект года», но хотелось бы развитие: больше деталей (проекты публиковать целиком) и шире охват (массовость).
    
    По решению задачи отделить «мух от котлет», а область «computer science & engineering» от «alchemy & voodoo» — делаются только первые робкие шаги. Пока алхимия одерживает одну за другой победы над здравым смыслом.
    На «Во-первых,» — напишу ответ отдельно.
    
    lair
    17.01.2018 14:21
    #10620982
    -1
    Бытовые аналогии понятным языком показывают «классические приемы» и техники продвижения универсальных волшебных «таблеток» с высокой стоимостью, но сомнительным составом.
    Аналогии обычно больше показывают того, кто их приводит.
1. bipiem Автор
  18.01.2018 00:34
  #10622070
  Ответ на habrahabr.ru/post/346610/#comment_10620262
  Удивляюсь, вначале красиво подрожали моей иронии:
  
  bipiem не оставил выбора, придется применить магическое заклинание и открыть портал ACM
  
  и даже создали прикольную картинку с АСМ: правда там слово ВРМ не нужно было затирать, — было бы «комплексней».
  Я уж обрадовался, понадеялся, что еще борец с алхимией появился.
  Потом, Ваша ирония «растворилась», видимо, из-за того, что иронизировать над ЕА, ВРМ и SE можно, но вот покушаться на «святыню»: АСМ – это «кощунство»! Верно?
  
  Во-первых, ACM это не BPM. Основа ACM — это обработка событий и ориентированность на Case (можно интерпретировать как «Дело»). Основа BPM — это в большей степени процессный подход
  
  «это не BPM» – уже Очень Смешно.
  Потому что: «что такое BPM» – никому не известно, смотрим указанную ранее статью «Как все запущено и запутано. Глава Первая»
  
  Неоднократно был свидетелем, когда на крупной конференции или семинаре по «управлению бизнес-процессами» (BPM, Business Process Management – так, на всякий случай), — часами обсуждают ВРМ и подробно рассказывают о ВРМ-проектах. Все чинно, с умным видом.
  
  Затем когда всем становится очевидно, что беседа идет на разных языках и совсем «о разных BPM» начинаются вопросы к докладчикам: так Ваша система – это же не ВРМ!
  
  Затем достопочтенная публика задается вопросом: Что такое BPM? Час приводят «книжные» термины (цитаты из BPM CBOK, других «процессных библий») – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу».
  Вы о каком BPM?
  
  «Как все запущено и запутано. Глава Первая»:
  
  … Для успешных продаж «взбрасываются» новые термины и подменяются прежние названия, выдумываются модные фишки, проводится ре-брендинг, вводится тавтология и путаница (см. выше «управление управлением»), а потом создается ореол «успешности» и необходимости внедрений т.п.
  Главное: воду сделать мутной, а остальное — «дело техники».
  
  В далеком 2000-ом, в основном употреблялся единственный термин: CASE. И его было достаточно. Когда при проектировании «системы» формализовывали бизнес-логику и укрупненные алгоритмы взаимодействия исполнителей (систем), то в слове CASE понимали S=System и использовали соответствующие инструменты, например, ARIS\EPC.
  
  Когда формализовывали детальные алгоритмы при проектировании ПО, то понимали S=Software и использовали, например, RUP\UML. Уже тогда Rational позволял генерировать код из моделей UML. При этом обходились без разных «BPM\BPMS» и «BPM-like» направлений.
  Напомню, что CASE-технология — это инструментарий для системных аналитиков, проектировщиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования систем и разработки ПО. Проблема в том, что этот термин был монетизирован, поэтому нужен «свежий», на котором «еще можно заработать».
  
  Вы про этот CASE?
  
  Основа BPM — это в большей степени процессный подход.
  
  Там же, первой главе:
  
  1.4 Процессное управление и автоматизация
  «Говорим BPM — подразумеваем процессное управление»: на протяжении десятилетий от ведущих BPM-консалтеров слышим дифирамбы по процессному управлению. До сих пор считается, что с BPM призван в организации заместить «древний и неэффективный» функциональный подход на «новый и прогрессивный» процессный. …
  
  Теперь к Вашему «священному АСМ»
  По Вашей ссылке:
  
  Одни эксперты считают, что ACM это «Pidgin-BPM», примитивная версия BPM, решающая те же проблемы, что и BPM. «Серьезные специалисты», отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти — это считать ACM опцией, дополнительным «бантиком» к BPM.
  
  И это в консервативной wiki! Только это уже говорит, что до практического инженерного понимания этой технологии (или алхимии) предстоит еще долгий путь.
  
  Хорошо. Давайте на паре примеров поймем, что такое АСМ.
  Маркетинг и рекламу читать не будем, определений тоже не нужно (алхимия же), только на простых примерах («на пальцах»).
  
  Пример первый, система документооборота.
  Я хочу согласовать договор. Есть стандартный конвейер согласования: Отдел 1, Отдел 2, Отдел 3 и т.д.
  Все это прошито в Workflow. Я захожу в систему DocFlow, ввожу договор, атрибуты, вызываю преднастроенный шаблон Workflow (с заданными маршрутами) и жму «поехали». Каждому согласанту в соответствии с логикой шаблона даются поручения, выскакивают окошки, требуют заполнения нужных полей и т.п. Потом, когда все отжали нужные кнопки, мне прилетает «Готово». Это в Вашем понимании ВРМ?
  
  Но вдруг в одном экземпляре процесса (согласования договора N) или «кейса» (как правильно?) что-то пошло не так, и договор отклонили, мне прилетает соответствующее сообщение с комментарием. Я читаю, сильно думаю и решаю, что это «нестандартная» ситуация и нужно отправить договор «Иванову», который вообще не участвует в штатном Workflow.
  Я жму кнопку: выбрать Иванова и отправить ему договор, а после получения правок от Иванова далее продолжается алгоритм «штатного конвейера».
  
  Это добавка уже реализует подход АСМ? Конечно, ведется архив кейсов, и любой «на моем месте» может вызвать базу знаний и посмотреть как в подобном случае (нештатной ситуации) кто-либо действовал.
  
  Иной Вариант первого примера, когда у меня вообще нет преднастроенного шаблона (т.е. «неструктурированный процесс») и я вручную в DocFlow создаю последовательность поручений (по произвольному списку), прикрепляя файл договора, – это тоже АСМ?
  
  Второй пример покажите на процессе «Управления инцидентами», как он работает в режиме ВРМ и как в режиме АСМ?
  
  Иногда употребляют «Adaptive Workflow Management System» (Pega, Papyrus и др.) — это тоже АСМ? В чем отличие?

lingvo
17.01.2018 11:17
#10620474
Системная инженерия, ЕА, ВРМ – должны когда-нибудь стать настоящей наукой и инженерией, точно также как и «коды Хэмминга». Это должен быть предельно формализованный аппарат, позволяющий формализацию требований («хотелок»), проектирование, проверку качества и точности исполнения изделий класса «система».
Неважно, какая это «система»: АСУ, включая, АСУ войсками, АСУТП или государственные информационные системы, «электронное правительство», или целое «предприятие» (ЕА), включая, домохозяйство, бизнес (ИП, МСБ, «корпорат»), государство.
Кстати насчет государства — иногда у меня, как системотехника, действительно руки чешутся бросить все и податься в президенты одного из государств — неудачниц, чтобы начать делать "Систему Управления Государством 2.0". Ведь даже с моим базовым набором знаний видно, когда какие-либо государственные процессы просто не функционируют, когда винтики тупо стоят не на своем месте и крутятся в разные стороны, когда сделано чересчур сложно или забюрократизировано.
Короче много чего с точки зрения построения систем можно было бы в государстве оптимизировать, перенять опыт, но, к сожалению, также с опыта системотехника видно, что Запорожец в Мерседес не переделать никак, а легче все разрушить и разработать полностью новое, но это к сожалению никак не провернуть.
1. bipiem Автор
  17.01.2018 13:58
  #10620920
  Кстати насчет государства — иногда у меня, как системотехника, действительно руки чешутся бросить все и податься в президенты одного из государств — неудачниц, чтобы начать делать «Систему Управления Государством 2.0».
  
  Вы не волнуйтесь, даже если и станете президентом, то Вам все равно в нашей стране (думаю и в других тоже) ничего не дадут сделать.
  Лучше давайте «снизу» вместе делать SE \ EA \ BPM высокоэффективным инструментом и добавим им «серебряную пулю и волшебную таблетку»
  
  Или хотя бы очистим их от управленческих и маркетинговых «причуд». Первый шаг — раскрытие тайн алхимиков и обзор «платья короля», т.е. публикация проектов SE \ EA \ BPM.
  
  Вместо своей президентской программы, лучше составьте framework своего домохозяйства, как я предлагал здесь:
  3 Конкурс на описание «household architecture»

Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия» +11

Немного про SE

1. Начало

Первое правило системной инженерии

Второе правило

Третье правило

Что такое SE

Заключение

Комментарии (80)

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор

bipiem Автор