Системное мышление является общим навыком, необходимым всем специалистам, которые участвуют в коллективной работе по выполнению сложных проектов, оно лежит в основе деятельности системных инженеров, менеджеров и технологических предпринимателей. Знания и навыки системного мышления незаменимы для выстраивания междисциплинарной работы, и позволяют проектной команде эффективно общаться на общем для всех системном языке. Предыдущие поколения системного подхода в инженерии не учитывали важность стейкхолдеров, представления жизненного цикла не как последовательности стадий, а как набора практик. В данном курсе предлагается вариант, основанный на стандартах и публичных документах последних пяти лет, изложение строится на схемах и поддержано задачами по практическому использованию понятий системного подхода. Курс научит проводить системные размышления, определять целевую систему проекта (в том числе, для сложных случаев сервиса и программного обеспечения), различать проверочные и приёмочные тесты и испытания, осознанно подходить к организации междисциплинарных предпринимательских, инженерных и менеджерских работ для сложных проектов. Вы узнаете: − О различиях потребностей, требований и ограничений − О представлении деятельности в виде набора практик − Об архитектуре системы − Как пользоваться системной схемой проекта (возможности, стейкхолдеры, определение и воплощение системы, работы, технологии, команда) для уменьшения проектных рисков − Как отличать важные решения от менее важных − Как бороться со сложностью в самых разных проектах − Как определить свою систему среди чужих − Как объединять в мышлении продукт и деятельность по его созданию − Какие бывают виды жизненного цикла − Как объединить деятельности техпредпринимателя, инженера, менеджера Курс разработан компанией «еНано» (входит в группу РОСНАНО и является разработчиком дистанционных образовательных курсов и программ по нанотехнологиям и технологическому предпринимательству) - образовательным партнером МФТИ. Рекомендован Русским отделением международного совета по системной инженерии (INCOSE), http://incose.ru.
Конфигурация
Loading...
From the course by Moscow Institute of Physics and Technology
Системное мышление
34 ratings
From the lesson
Определение и описание системы
На этой неделе вы научитесь минимально смотреть на систему три раза: как на состоящую из компонент, модулей и размещений. А ещё вы научитесь различать объекты-альфы, о которых вы думаете, и рабочие продукты, которые вы видите в реальной жизни. По окончании этой недели вы больше не будете путать требования (которые описывают систему как «чёрный ящик») и архитектуру (которая говорит о системе, как о «прозрачном ящике»). А ещё вы всегда-всегда будете после этой недели управлять конфигурацией ваших систем.
Meet the Instructors
Левенчук Анатолий Игоревич
Президент консалтинговой компании TechInvestLab, научный руководитель Школы системного менеджмента
[БЕЗ_ЗВУКА] Важнейшее понятие
в системном мышлении — это конфигурация, configuration.
Это обычно текущее состояние холархии системы,
причем взятое как as is, то есть «как есть», то,
что мы видим сейчас, так и to be, то есть то,
что мы только планируем, то, что должно быть.
В принципе, конфигурации бывают самые разные,
и под конфигурацией мы понимаем то,
что мы знаем абсолютно все о том, какие части системы у нас наличествуют,
мы буквально перечисляем все части системы на много уровней вниз.
Может быть, не до самого конца.
Почему?
В принципе, конфигурационная единица определяется как
единица передачи части системы от одного человека в команде
другому человеку в команде, от одного стейкхолдера другому стейкхолдеру.
Некоторые стейкхолдеры, например, инженеры,
им требуется учесть более глубоко деление системы, но им ничего передавать не надо.
Например, какой-нибудь гейт из 15 миллиардов гейтов в микросхеме.
То есть у нас есть какой-то транзистор, он выполняет индивидуальную функцию,
инженер его учитывает.
Но, в принципе, даже инженер его не учитывает,
потому что это учитывается в ТО.
Ни один инженер в голове не будет держать 15 абсолютно
уникальных единиц какого-то конструктива.
А какие же единицы конфигурационные?
Те, которые участвуют в разделении труда, то есть то, что нам надо передать.
Сам этот чип обязательно будет конфигурационной единицей.
Сама пластинка, которая будет сделана одним станком и будет передаваться
другому станку, и там будут выполняться операции литографии, операции травления,
потом это все будет запечатано в корпус с выводными какими-то ножками.
Вот это все обязательно будет конфигурационной единицей.
Еще раз, в системном мышлении мы учитываем тот факт, что у нас есть система целевая,
и у нас есть система деятельности, обеспечивающая система,
которая занимается этой самой целевой системой.
И мы понимаем, что понятие конфигурации, оно живет где-то посередине.
С одной стороны,
эти конфигурационные единицы определяются инженерами в составе целевой системы.
С другой стороны, мы понимаем,
что это делается в целях того, чтобы существовала система деятельности.
То есть эти единицы, для того чтобы их изготовить, собрать потом как-то...
Помните, что это отношение часть/целое?
Следовательно, надо собирать, отношение composition, compose.
Они должны, эти части, быть сделаны какими-то людьми,
как-то путешествовать друг от друга.
Это надо отслеживать.
Для отслеживания вводится понятие конфигурационной единицы,
configuration item.
И конфигурация — это просто совокупность всех
известных нам конфигурационных единиц.
Итак, у нас есть конфигурационные единицы, и они бывают двух сортов.
Собственно, это части самой системы, и второе — это могут быть какие-то описания,
какие-то рабочие продукты, которые соответствуют частям системы.
Это обычно очень трудно понимать, что если у вас есть документ,
если есть какое-то описание, если есть какая-то база данных,
то обычно существует система или часть системы...
Часть системы — это, конечно, тоже система.
Вы помните, это холархия, часть состоит из частей, которые тоже части.
Или конфигурационная единица.
Роль такая — конфигурационная единица, с точки зрения учета: есть,
нет, как меняется, в каком состоянии и где находится.
И мы понимаем, что эта конфигурационная единица описывается другой
конфигурационной единицей, а именно описанием, и один в один соотношение.
Если у вас случился какой-то документ, и вы не знаете,
какую часть системы описывает этот документ, это означает,
что что-то не то либо с системой, либо с документом.
Это дополнительное средство проверки вашего системного мышления.
И мы в учете конфигурации, а конфигурацию учитывают,
иногда говорят «ей управляют»,
вы в этом учитываете то, что у вас есть версия конфигурации.
Итак, разные состояния на разные моменты времени у вас называются версиями.
А еще у вас бывает базис, или baseline.
Если вы проверяете, что все части системы соответствуют друг другу,
то есть из них можно собрать целую систему,
или все части описания соответствуют какому-то одному состоянию системы,
вы удостоверяетесь как можете, иногда трудно удостовериться, а иногда легко,
и вы говорите, что вот это описание — правильное, возможно, его несколько
человек административно подписывают при этом, то вы называете это базисом.
И далее вы всем показываете не любое рабочее состояние, когда вы
разрабатываете, и непрерывно меняются описания, непрерывно меняется система,
потому что разные люди работают с разными частями системы,
а показываете только вот эти соответствующие друг другу состояния самой
системы и состояния описаний системы, которые называются baseline.
Например, вы не всем показываете требования, всем желающим посмотреть,
что у вас будет за система, как она описывается своими функциональными,
со своей функциональной стороны, со стороны требований качества.
Нет, вы предоставляете всем,
как особо отмечается в стандарте ISO 15288,
исключительно базис требований requirements baseline, то есть
только те требования, которые целостны, которые соответствуют друг другу,
которые соответствуют состоянию системы на «сейчас» либо на «потом»,
но не такому состоянию, когда мы половину системы поменяли, по состоянию на решение,
принятое вчерашним совещанием, а половину еще не успели поменять,
и поэтому у нас просто есть какая-то версия системы,
но она не является утвержденной версией, она является только базисом.
Итак, управление конфигурацией.
Мы управляем конфигурацией.
Слово management, как всегда, означает, что мы отслеживаем,
что конфигурация и ее описание известны, и они соответствуют друг другу.
Проверяется, что все части системы соответствуют друг другу, они из одной
версии или тем более из одного базиса — это еще более жесткое утверждение.
С другой стороны, мы проверяем, что все описания соответствуют друг другу,
а не часть описаний взята трехмесячной давности, а часть описаний
взята — сегодня мы их поменяли, и мы не знаем как они соответствуют друг другу.
С одной стороны.
И мы проверяем, насколько сами описания эти соответствуют той системе,
которая у нас есть.
Это не управление версиями, это управление конфигурацией,
потому что кроме версий много чего входит.
Мы управляем данными, мы выпускаем рабочие продукты.
Как ни странно, выпуск проектно-конструкторской документации,
он относится к практике управления конфигурацией.
А управление изменениями часто включают в состав управления конфигурацией.
Почему?
Потому что мы не просто меняем нашу систему,
в произвольные моменты произвольные люди проходят мимо и меняют, что хотят.
И мы не меняем наши описания, опять же произвольные люди проходят и меняют,
например, архитектуру системы, принимают важные решения.
Нет, мы делаем запрос на изменения, мы изменяем систему,
мы проверяем эти изменения, после чего объявляем новое состояние базисом.
То есть это некоторая другая дисциплина, это не управление конфигурацией,
как вы понимаете, это управление какими-то работами.
Но чаще всего так и говорят: «управление конфигурацией и изменением»,
потому что изменение в чем?
Изменение в конфигурации.
Вы должны одновременно работать с данными, которые представляют конфигурацию
описаний, самой железной системой или системой в реальном мире,
необязательно она железная, программная система.
И вы должны работать с той системой деятельности, которая вносит изменения.
Работа с системой деятельности — это как раз управление конфигурацией.
Часто управление конфигурацией еще называют «управление жизненным циклом»,
иногда это называют product lifecycle management,
иногда еще и синоним такой, как «управление инженерной документацией».
Почему?
Потому что в конфигурацию выделяют эту конфигурацию всех описаний системы,
и конфигурация описаний системы, или документация,
или сегодня это в базах данных и информационных моделях,
чуть ли не имеет вперед разработки примат над железной частью системы.
Самая частая ошибка в конструкторских бюро, что управление
конфигурацией описаний считается полным управлением конфигурацией.
То же самое в программной инженерии: управление конфигурацией
там считается часто управлением только конфигурацией исходных кодов.
Фактически это инженерная документация — исходные коды.
Нет, в полную дисциплину управления конфигурацией включается и управление
реальной частью системы.
Это означает, что если у нас есть исходные коды какой-то программы,
мы в любой момент времени понимаем, как эти исходные коды породили какие
программы на серверах, те программы, которые работают: какие модули,
какие блоки, в облаках они или на каком-то смартфоне,
в каком-то промежуточном уровне вычислительного тумана,
как сейчас говорят, у нас распределенная вычислительная среда.
Вот где проходят эти вычисления — это как раз управление
конфигурацией целевой системы, а не описаниями целевой системы.
Мы понимаем, что «управление инженерной документацией» — это хорошо звучит,
но не совсем верно, потому что кроме документации нам надо управлять еще
и конфигурацией самой системы.
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2018 Coursera Inc. All rights reserved.
