Показаны записи 12631 - 12640 из 56266
Системное мышление (system thinking) -- это приложение системного подхода к решению практических задач. Так, системная инженерия -- это приложение системного подхода к решению инженерных задач. Этот вариант системного мышления мы будем называть системноинженерным мышлением.
Еесть и другие варианты системного мышления, ибо существует множество разновидностей системного подхода, значительное число этих разновидностей посвящено попыткам разбирательства с системами из людей
(см., например, обзоры http://www.situation.ru/app/j_art_1052.htm и
http://rudocs.exdat.com/docs/index-421147.html?page=8
-- при этом помним, что systems engineering до середины 80-х годов по-русски переводили словом "системотехника", которое и использовано в этих обзорах).
Сегодня системная инженерия представляет собой одну из самых бурно развивающихся ветвей системного движения, при этом она активно впитывает и идеи других направлений системного движения.
Еесть и другие варианты системного мышления, ибо существует множество разновидностей системного подхода, значительное число этих разновидностей посвящено попыткам разбирательства с системами из людей
(см., например, обзоры http://www.situation.ru/app/j_art_1052.htm и
http://rudocs.exdat.com/docs/index-421147.html?page=8
-- при этом помним, что systems engineering до середины 80-х годов по-русски переводили словом "системотехника", которое и использовано в этих обзорах).
Сегодня системная инженерия представляет собой одну из самых бурно развивающихся ветвей системного движения, при этом она активно впитывает и идеи других направлений системного движения.
Системный подход с его вниманием не только к частям, но и целому (холизм) противопоставляется прежде всего редукционистскому подходу. В редукционистском подходе (часто неявно) утверждается, что мы должны дать детальное "научное" (то есть в рамках определённого научного предмета) описание любого объекта, просто повышая уровень его детальности при любых встречающихся затруднениях, сводя изучение целого к изучению его отдельных частей.
Но почему представители системного мышления называют это"редукционистским" подходом? Потому как доктрина редукционизма полагала, что любое "высшее проявление" можно свести к "низшему, в частях системы", если постараться. Бег зайца можно свести к химическим реакциям в молекулах зайца, то есть заяц сводим к его химии. Или атомная электростанция сводима к набору атомов физических элементов, которые нужно только собрать в правильные места в пространстве.
Согласно редукционизму, инженерия вся сводится к правильному использованию физики, и только -- ибо инженерный объект это физический объект, и только. Никаких "систем", "жизненных циклов", "требований" и "архитектур", только законы физики!
Но почему представители системного мышления называют это"редукционистским" подходом? Потому как доктрина редукционизма полагала, что любое "высшее проявление" можно свести к "низшему, в частях системы", если постараться. Бег зайца можно свести к химическим реакциям в молекулах зайца, то есть заяц сводим к его химии. Или атомная электростанция сводима к набору атомов физических элементов, которые нужно только собрать в правильные места в пространстве.
Согласно редукционизму, инженерия вся сводится к правильному использованию физики, и только -- ибо инженерный объект это физический объект, и только. Никаких "систем", "жизненных циклов", "требований" и "архитектур", только законы физики!
Системный подход
Системный подход -- это когда наработанное где-то (в данном случае уже неважно где) системное мышление переносится в другие дисциплины -- например, в (системную) инженерию.
Есть много легенд, почему системная инженерия взяла на вооружение системный подход. Вот одна из них в вольном пересказе:
Когда два суперсложных проекта 20 века попытались объединить -- речь идёт об американских "Манхэттенском проекте" создания атомной бомбы и проекте разработки баллистических ракет как средства доставки получаемых бомб -- совокупная сложность проекта, подразумевающая учёт в одном проекте результатов работы множества дисциплин, перестала умещаться в одной голове "генерального конструктора".
В те далёкие времена, когда самолёты назывались по имени генерального конструктора-гения (все эти "мессершмиты" и "ильюшины"), встретились
задачи, которые по сложности выходили за возможности конкретного гения овладеть множеством разных дисциплин, и нужно было выработать какой-то отчуждаемый от гениального человека способ совладания с этой сложностью. Тогда вспомнили, что инженеры-иммигранты с заводов "Мерседес-Бенц" используют для своей работы "системный подход", который они позаимствовали у биологов, изучавших биогеоценозы -- сложнейшие биологические системы, затрагивающие уровень сложности выше, чем сложность отдельного организма. Этот "системный подход" -- использование мышления в терминах систем -- появился в инженерном деле и после этого уже было не сложно наращивать сложность разрабатываемых систем, не опасаясь выхода этой сложности за пределы одной гениальной головы.
Системный подход -- это когда наработанное где-то (в данном случае уже неважно где) системное мышление переносится в другие дисциплины -- например, в (системную) инженерию.
Есть много легенд, почему системная инженерия взяла на вооружение системный подход. Вот одна из них в вольном пересказе:
Когда два суперсложных проекта 20 века попытались объединить -- речь идёт об американских "Манхэттенском проекте" создания атомной бомбы и проекте разработки баллистических ракет как средства доставки получаемых бомб -- совокупная сложность проекта, подразумевающая учёт в одном проекте результатов работы множества дисциплин, перестала умещаться в одной голове "генерального конструктора".
В те далёкие времена, когда самолёты назывались по имени генерального конструктора-гения (все эти "мессершмиты" и "ильюшины"), встретились
задачи, которые по сложности выходили за возможности конкретного гения овладеть множеством разных дисциплин, и нужно было выработать какой-то отчуждаемый от гениального человека способ совладания с этой сложностью. Тогда вспомнили, что инженеры-иммигранты с заводов "Мерседес-Бенц" используют для своей работы "системный подход", который они позаимствовали у биологов, изучавших биогеоценозы -- сложнейшие биологические системы, затрагивающие уровень сложности выше, чем сложность отдельного организма. Этот "системный подход" -- использование мышления в терминах систем -- появился в инженерном деле и после этого уже было не сложно наращивать сложность разрабатываемых систем, не опасаясь выхода этой сложности за пределы одной гениальной головы.
3. Системный подход
Понятие "подхода"
"Подход" -- это когда разработанные в рамках одной дисциплины приёмы работы (в том числе приёмы мышления) переносят в какие-то другие области.
Очень часто "подход" является синонимом "практики" или даже "метода" (помним, что в разных речевых сообществах слова "практика" и "метод" отнюдь не используются в точных терминологических значениях, в отличие от нашего курса -- тем не менее, общее сходство в их значениях несомненно).
Слово "подход" означает обычно, что какие-то "практики" или даже целый "метод" работы были отработаны в какой-то одной предметной области, отрефлектированы (т.е. явно описаны в отрыве от предметной области, на объектах которой они отрабатывались), а затем перенесены туда, где раньше они не использовались. Так что использование слов "подход" или "метод" по большей части ситуативно: научный подход вы используете при описании какого-то фрагмента реальности или научный метод -- это не так важно.
Все поисковые системы подразумевают синонимичность подхода (approach) и метода (method). Если вы будете искать "научный подход", то вам покажут "научный метод": перенос методологического знания из одной предметной области в другую по мере развития ситуационной инженерии методов становится обыденным. Тем самым и саму системную инженерию можно считать "подходом", если мы придём с её практиками и методами в те области, в которых она раньше не использовалась -- например, будем использовать системную инженерию при создании искусственных живых организмов или наноботов.
Ну, или "подход системной инженерии" уместно говорить в ситуациях, когда мы пытаемся от советских инженерных методов перейти к методам системной инженерии.
В самой системной инженерии используется "системный подход", и можно найти множество других "подходов", например, архитектурный подход (где методы архитектурной работы распространились из традиционной архитектуры на работу со сложными техническими системами и даже программными системами).
Понятие "подхода"
"Подход" -- это когда разработанные в рамках одной дисциплины приёмы работы (в том числе приёмы мышления) переносят в какие-то другие области.
Очень часто "подход" является синонимом "практики" или даже "метода" (помним, что в разных речевых сообществах слова "практика" и "метод" отнюдь не используются в точных терминологических значениях, в отличие от нашего курса -- тем не менее, общее сходство в их значениях несомненно).
Слово "подход" означает обычно, что какие-то "практики" или даже целый "метод" работы были отработаны в какой-то одной предметной области, отрефлектированы (т.е. явно описаны в отрыве от предметной области, на объектах которой они отрабатывались), а затем перенесены туда, где раньше они не использовались. Так что использование слов "подход" или "метод" по большей части ситуативно: научный подход вы используете при описании какого-то фрагмента реальности или научный метод -- это не так важно.
Все поисковые системы подразумевают синонимичность подхода (approach) и метода (method). Если вы будете искать "научный подход", то вам покажут "научный метод": перенос методологического знания из одной предметной области в другую по мере развития ситуационной инженерии методов становится обыденным. Тем самым и саму системную инженерию можно считать "подходом", если мы придём с её практиками и методами в те области, в которых она раньше не использовалась -- например, будем использовать системную инженерию при создании искусственных живых организмов или наноботов.
Ну, или "подход системной инженерии" уместно говорить в ситуациях, когда мы пытаемся от советских инженерных методов перейти к методам системной инженерии.
В самой системной инженерии используется "системный подход", и можно найти множество других "подходов", например, архитектурный подход (где методы архитектурной работы распространились из традиционной архитектуры на работу со сложными техническими системами и даже программными системами).
*Технология
Дисциплина -- она в головах. Но в организации есть технология: поддержанный необходимыми рабочими продуктами и инструментами способ работы (way of working). Практика = дисциплина+технология (метод = полный набор дисциплин и технологий для выполнения какой-то работы).
Технология существенно зависит от состава выполняемых работ (технология пошива обуви не нужна при проектировании медицинской аппаратуры анализа крови, и наоборот), технология требуется для команды (компетенция проектирования в 2014 году не может быть реализована без компьютеров с установленными на них информационными системами САПР -- системами автоматизации проектирования, системами инженерных мультифизических расчётов, системами управления жизненным циклом PLM/product lifecycle management). Бессмысленно привлекать в команду человека и одновременно не
обеспечивать его технологией, и не давать фронта работ: все альфы предпринятия тесно зависят друг от друга. Если есть работа "копать траншею длиной 500 метров", то нужно озаботиться не только нужным количеством землекопов или экскаваторщиков, но и лопатами или экскаваторами. Этот пример также показывает, что для каждой работы могут быть использованы самые разные технологии, и тем самым выполнение инженерного проекта включает выбор (а иногда -- выбор, закупку и разворачивание) для его выполнения технологий.
Управление технологиями (каждая из которых имеет свои плюсы и минусы и требует для своего использования людей в команде с разными компетенциями) это отдельная дисциплина инженерного менеджмента. Удивительно, но люди часто не задумываются о тех технологиях, которые они используют. Что будет, если бригаде землекопов дать экскаватор?
*Они потратят целый день на то, чтобы отвинтить "лопату" от экскаватора, а потом попробуют организовать бригаду лопатодержателей, ибо одному человеку трудно будет управляться с такой большой лопатой! Ну, и затребуют пару сотен килограмм изоленты: обмотать неудобную ручку у этой огромной лопаты. А остальное (кабину, двигатель, систему тросов, гусеницы) выбросят: землекопы не знают, для чего все эти лишние детали, привинченные к лопате. Так что инструменты поддерживают те или иные дисциплины, а исполнители должны быть компетентны в использовани инструментов и дисциплинированы в своём мышлении.
Упражнение: Какие технологии используются в вашем проекте? Приведите три примера и для каждого дайте пару альтернативных технологий (например, 3D-моделирование с использованием Autodesk Inventor вместо 2D-моделирования в Autodesk AutoCAD или порождающего проектирования/generative design в специально написанном программном средстве).
Дисциплина -- она в головах. Но в организации есть технология: поддержанный необходимыми рабочими продуктами и инструментами способ работы (way of working). Практика = дисциплина+технология (метод = полный набор дисциплин и технологий для выполнения какой-то работы).
Технология существенно зависит от состава выполняемых работ (технология пошива обуви не нужна при проектировании медицинской аппаратуры анализа крови, и наоборот), технология требуется для команды (компетенция проектирования в 2014 году не может быть реализована без компьютеров с установленными на них информационными системами САПР -- системами автоматизации проектирования, системами инженерных мультифизических расчётов, системами управления жизненным циклом PLM/product lifecycle management). Бессмысленно привлекать в команду человека и одновременно не
обеспечивать его технологией, и не давать фронта работ: все альфы предпринятия тесно зависят друг от друга. Если есть работа "копать траншею длиной 500 метров", то нужно озаботиться не только нужным количеством землекопов или экскаваторщиков, но и лопатами или экскаваторами. Этот пример также показывает, что для каждой работы могут быть использованы самые разные технологии, и тем самым выполнение инженерного проекта включает выбор (а иногда -- выбор, закупку и разворачивание) для его выполнения технологий.
Управление технологиями (каждая из которых имеет свои плюсы и минусы и требует для своего использования людей в команде с разными компетенциями) это отдельная дисциплина инженерного менеджмента. Удивительно, но люди часто не задумываются о тех технологиях, которые они используют. Что будет, если бригаде землекопов дать экскаватор?
*Они потратят целый день на то, чтобы отвинтить "лопату" от экскаватора, а потом попробуют организовать бригаду лопатодержателей, ибо одному человеку трудно будет управляться с такой большой лопатой! Ну, и затребуют пару сотен килограмм изоленты: обмотать неудобную ручку у этой огромной лопаты. А остальное (кабину, двигатель, систему тросов, гусеницы) выбросят: землекопы не знают, для чего все эти лишние детали, привинченные к лопате. Так что инструменты поддерживают те или иные дисциплины, а исполнители должны быть компетентны в использовани инструментов и дисциплинированы в своём мышлении.
Упражнение: Какие технологии используются в вашем проекте? Приведите три примера и для каждого дайте пару альтернативных технологий (например, 3D-моделирование с использованием Autodesk Inventor вместо 2D-моделирования в Autodesk AutoCAD или порождающего проектирования/generative design в специально написанном программном средстве).
Работы
Для того, чтобы инженерный проект был успешен, команде проекта нужно провести работы (works) -- и отслеживать состояние этих работ в ходе всего инженерного проекта. Конечно, содержание этих работ определяется каждым из членов команды проекта -- но есть особая работа по проведению работ (operations management), это работа операционного менеджера. Прежде всего, требуемые работы нужно:
● учитывать во всём их содержательном разнообразии, чтобы ответить на вопрос "что делать"
● Планировать (schedule), т.е. предлагать распределение этих работ во времени и приписывание этих работ исполнителям.
● Определять достаточность ресурсов и контролировать выполнение плана работ для понимания того, вовремя ли работы будут закончены (т.е. не закроется ли окно возможностей раньше того момента, когда эти возможности будут удовлетворены результатом проекта) С точки зрения операционного менеджера вся организация представляет собой набор рабочих мест/станций, на которых требуемые проектом различные ресурсы (люди, инструменты, расходные материалы) задействованы для выполнения содержательных работ, а также продукты работ движутся между этими рабочими
местами/станциями.
У того, кто занимается работой, мышление представляет проект как некоторую трубопроводную сеть, по которой текут (flow, но по-русски тут будет "идут", "проходят") работы, материалы, люди, информация так, что из "входного" информационного, человеческого, материального сырья получаются "выходные" воплощения системы -- а обратным ходом текут/идут/проходят вырученные за воплощения системы деньги. Это логистическое, операционное мышление.
Из дисциплин, которые работают над альфой "работа", можно указать:
● Операционный менеджмент (из Lingvo: operations management -- управление операциями [производством]. Управление производственным процессом фирмы, в отличие от стратегического менеджмента, управления персоналом и других составных частей управления организацией; исторически первое название этой деятельности production management было изменено на operations management, т.к. по сути "производство" существует практически во всех организациях, и в том числе в сфере услуг, страховании, банковском деле и т. д., а слово production ассоциируется лишь с материальным производством).
На английском языке общепринятое определение проще -- Operations Management is the process by which an organization converts inputs (e.g. labor, material, knowledge, equipment) into outputs (goods and services).
На русском языке наиболее часто используется до сих пор старая форма "управление производством" и много реже "управление операциями" или прямая калька "операционный менеджмент".
"Исследование операций" и даже "теория массового обслуживания" также довольно частый термины, хотя под ними чаще имеется ввиду использование специального математического аппарата для расчёта времени работы.
● управление цепочками поставок (supply chain management)
● управление проектами (project management), управление процессами (process management), ведение дел (case management)
● планирование и управление производством (planning and production management)
● логистика (logistics)
● операционная стратегия (operation strategy)
● управление сервисными операциями (management of service operations)
● улучшение производительности (performans improvement)
● планирование ресурсов предприятия (enterprise resource planning) и управление ресурсами (resource management)
● get things done (GTD) -- система персонального планирования, "как доводить дела до конца"
Вот один из видов рабочих продуктов, отражающих альфу "работы" (это простейший issue tracker):
Для того, чтобы инженерный проект был успешен, команде проекта нужно провести работы (works) -- и отслеживать состояние этих работ в ходе всего инженерного проекта. Конечно, содержание этих работ определяется каждым из членов команды проекта -- но есть особая работа по проведению работ (operations management), это работа операционного менеджера. Прежде всего, требуемые работы нужно:
● учитывать во всём их содержательном разнообразии, чтобы ответить на вопрос "что делать"
● Планировать (schedule), т.е. предлагать распределение этих работ во времени и приписывание этих работ исполнителям.
● Определять достаточность ресурсов и контролировать выполнение плана работ для понимания того, вовремя ли работы будут закончены (т.е. не закроется ли окно возможностей раньше того момента, когда эти возможности будут удовлетворены результатом проекта) С точки зрения операционного менеджера вся организация представляет собой набор рабочих мест/станций, на которых требуемые проектом различные ресурсы (люди, инструменты, расходные материалы) задействованы для выполнения содержательных работ, а также продукты работ движутся между этими рабочими
местами/станциями.
У того, кто занимается работой, мышление представляет проект как некоторую трубопроводную сеть, по которой текут (flow, но по-русски тут будет "идут", "проходят") работы, материалы, люди, информация так, что из "входного" информационного, человеческого, материального сырья получаются "выходные" воплощения системы -- а обратным ходом текут/идут/проходят вырученные за воплощения системы деньги. Это логистическое, операционное мышление.
Из дисциплин, которые работают над альфой "работа", можно указать:
● Операционный менеджмент (из Lingvo: operations management -- управление операциями [производством]. Управление производственным процессом фирмы, в отличие от стратегического менеджмента, управления персоналом и других составных частей управления организацией; исторически первое название этой деятельности production management было изменено на operations management, т.к. по сути "производство" существует практически во всех организациях, и в том числе в сфере услуг, страховании, банковском деле и т. д., а слово production ассоциируется лишь с материальным производством).
На английском языке общепринятое определение проще -- Operations Management is the process by which an organization converts inputs (e.g. labor, material, knowledge, equipment) into outputs (goods and services).
На русском языке наиболее часто используется до сих пор старая форма "управление производством" и много реже "управление операциями" или прямая калька "операционный менеджмент".
"Исследование операций" и даже "теория массового обслуживания" также довольно частый термины, хотя под ними чаще имеется ввиду использование специального математического аппарата для расчёта времени работы.
● управление цепочками поставок (supply chain management)
● управление проектами (project management), управление процессами (process management), ведение дел (case management)
● планирование и управление производством (planning and production management)
● логистика (logistics)
● операционная стратегия (operation strategy)
● управление сервисными операциями (management of service operations)
● улучшение производительности (performans improvement)
● планирование ресурсов предприятия (enterprise resource planning) и управление ресурсами (resource management)
● get things done (GTD) -- система персонального планирования, "как доводить дела до конца"
Вот один из видов рабочих продуктов, отражающих альфу "работы" (это простейший issue tracker):
Команда
Команда (team) инженерного проекта -- это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением
полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами).
Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый
человек занял своё место на логистическом "конвейере" (ибо если какие-то места на этом "конвейере" не будут заполнены людьми, то целевая система просто не
сможет выпуститься -- необходимые на этом рабочем месте работы не будут произведены), нужно его "уговорить". Это функция "комиссара", пропагандиста, специалиста по менеджерской дисциплине "лидерство" (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать "личное" и "общественное").
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
Команда (team) инженерного проекта -- это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением
полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами).
Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый
человек занял своё место на логистическом "конвейере" (ибо если какие-то места на этом "конвейере" не будут заполнены людьми, то целевая система просто не
сможет выпуститься -- необходимые на этом рабочем месте работы не будут произведены), нужно его "уговорить". Это функция "комиссара", пропагандиста, специалиста по менеджерской дисциплине "лидерство" (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать "личное" и "общественное").
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
Воплощение системы
Воплощение системы (system realization, буквально: вынос в реальность) -- это четырехмерное воплощение системы в нашем материалом мире, это про
организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.
Конечно, воплощение системы будет называться везде по-разному:
● У конструкторов это чаще всего "изделие" или "продукт" (product)
● У проектантов это часто "установка" (plant)
● У проектантов очень крупных объектов (например, атомных станций) это "сложный инженерный объект"
Мы принимаем, что когда мы пишем название системы ("насос"), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).
Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект. Очень часто говорят об инженерном проекте по создании сервиса -- например, "сервис стрижки волос". Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, "парикмахерская", которая будет оказывать "сервис стрижки волос".
Воплощение системы в материальном мире есть и у программной системы: программа ведь не существует без носителя. Но в конкретном случае исполняемая программа в машинном коде, взятая в какой-то момент её существования подразумевает конкретное сочетание вещества и полей (магнитных доменов в флешках, заряженных ячеек в оперативной памяти, в регистрах процессора) -- каждому такту выполнения программы соответствует какое-то определённое состояние вещества, как и каждому такту работы какой-то другой "железной" системы. Конечно, при рассуждениях происходит абстрагирование от этой "физикализации" программы, но полезно помнить, что исходный код -- это рабочий продукт определения системы.
Одно определение системы обычно может пригодиться при создании тысяч и тысяч воплощений системы. Так и в случае софта: воплощение программной системы -- это исполняющаяся (иногда в тысячах и миллионах экземплярах) программа, а не исходный её код. Воплощение системы используется стейкхолдерами, оно реализует возможности.
Воплощение системы удовлетворяет определению системы. Основная дисциплина работы над воплощением системы -- это производство. Альфой воплощения системы занимается системный инженер.
Воплощение системы (system realization, буквально: вынос в реальность) -- это четырехмерное воплощение системы в нашем материалом мире, это про
организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.
Конечно, воплощение системы будет называться везде по-разному:
● У конструкторов это чаще всего "изделие" или "продукт" (product)
● У проектантов это часто "установка" (plant)
● У проектантов очень крупных объектов (например, атомных станций) это "сложный инженерный объект"
Мы принимаем, что когда мы пишем название системы ("насос"), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).
Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект. Очень часто говорят об инженерном проекте по создании сервиса -- например, "сервис стрижки волос". Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, "парикмахерская", которая будет оказывать "сервис стрижки волос".
Воплощение системы в материальном мире есть и у программной системы: программа ведь не существует без носителя. Но в конкретном случае исполняемая программа в машинном коде, взятая в какой-то момент её существования подразумевает конкретное сочетание вещества и полей (магнитных доменов в флешках, заряженных ячеек в оперативной памяти, в регистрах процессора) -- каждому такту выполнения программы соответствует какое-то определённое состояние вещества, как и каждому такту работы какой-то другой "железной" системы. Конечно, при рассуждениях происходит абстрагирование от этой "физикализации" программы, но полезно помнить, что исходный код -- это рабочий продукт определения системы.
Одно определение системы обычно может пригодиться при создании тысяч и тысяч воплощений системы. Так и в случае софта: воплощение программной системы -- это исполняющаяся (иногда в тысячах и миллионах экземплярах) программа, а не исходный её код. Воплощение системы используется стейкхолдерами, оно реализует возможности.
Воплощение системы удовлетворяет определению системы. Основная дисциплина работы над воплощением системы -- это производство. Альфой воплощения системы занимается системный инженер.
Определение системы
Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что "неопределено" (задача "пойди туда, не знаю куда, найди то, не
знаю что" -- это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырехмерном пространстве-времени какую-то систему,
нужно как минимум иметь представление об этой системе, "определить" её). Альфа "определение системы" (system definition) служит как раз для этой цели. У альфы определения системы (system definition) главные подальфы (части) прежде всего:
● Требования (описание назначения системы в её операционном окружении. Требования определяют систему как "чёрный ящик")
● Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система -- описание "прозрачного ящика". Изменение каждого из архитектурных решений на поздних стадиях проектирования ведёт к существенному перепроектированию всей системы).
● Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)
С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран
соответствующий метод описания. Наука -- это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах -- описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию.
Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии -- т.е. для записи определения системы как "мыслей по поводу системы, свойств системы" можно создать инженерный артефакт: нотацию.
Итого: определение системы -- это про биты, про информацию, про то, как мы говорим о системе. Основные дисциплины работы над определением системы -- это проектирование и конструирование. Альфой определения системы занимается системный инженер.
Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что "неопределено" (задача "пойди туда, не знаю куда, найди то, не
знаю что" -- это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырехмерном пространстве-времени какую-то систему,
нужно как минимум иметь представление об этой системе, "определить" её). Альфа "определение системы" (system definition) служит как раз для этой цели. У альфы определения системы (system definition) главные подальфы (части) прежде всего:
● Требования (описание назначения системы в её операционном окружении. Требования определяют систему как "чёрный ящик")
● Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система -- описание "прозрачного ящика". Изменение каждого из архитектурных решений на поздних стадиях проектирования ведёт к существенному перепроектированию всей системы).
● Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)
С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран
соответствующий метод описания. Наука -- это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах -- описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию.
Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии -- т.е. для записи определения системы как "мыслей по поводу системы, свойств системы" можно создать инженерный артефакт: нотацию.
Итого: определение системы -- это про биты, про информацию, про то, как мы говорим о системе. Основные дисциплины работы над определением системы -- это проектирование и конструирование. Альфой определения системы занимается системный инженер.
Возможности
Сам инженерный проект начинается с появления возможностей (opportunity) по его проведению -- это обстоятельства, которые делают возможным разработку (или доработку -- изменение уже имеющейся) системы. Наличие возможности существенно зависит от времени ("окно возможностей" -- период времени, в течение которого существует возможность выполнения проекта).
Возможности прежде всего характеризуют пользовательские потребности (пользовательские нужды, user needs -- то, что хотят пользователи такого, для
чего им поможет наличие воплощения системы), но они также отражают и наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей.
Именно возможности мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Эти возможности описываются целым рядом возможных рабочих продуктов: "бизнес-планом", "концепцией", "интервью пользователей", "обоснованием
инвестиций" и т.д.. -- в этих рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерный проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:
● Маркетинг и продажи, стратегирование и предпринимательство -- для установления user needs);
● Управленческий (финансовый) учёт -- для обоснования прибыльности. Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания/ и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы) -- это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.
Сам инженерный проект начинается с появления возможностей (opportunity) по его проведению -- это обстоятельства, которые делают возможным разработку (или доработку -- изменение уже имеющейся) системы. Наличие возможности существенно зависит от времени ("окно возможностей" -- период времени, в течение которого существует возможность выполнения проекта).
Возможности прежде всего характеризуют пользовательские потребности (пользовательские нужды, user needs -- то, что хотят пользователи такого, для
чего им поможет наличие воплощения системы), но они также отражают и наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей.
Именно возможности мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Эти возможности описываются целым рядом возможных рабочих продуктов: "бизнес-планом", "концепцией", "интервью пользователей", "обоснованием
инвестиций" и т.д.. -- в этих рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерный проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:
● Маркетинг и продажи, стратегирование и предпринимательство -- для установления user needs);
● Управленческий (финансовый) учёт -- для обоснования прибыльности. Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания/ и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы) -- это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.
Дочитали до конца.