Системное мышление является общим навыком, необходимым всем специалистам, которые участвуют в коллективной работе по выполнению сложных проектов, оно лежит в основе деятельности системных инженеров, менеджеров и технологических предпринимателей. Знания и навыки системного мышления незаменимы для выстраивания междисциплинарной работы, и позволяют проектной команде эффективно общаться на общем для всех системном языке. Предыдущие поколения системного подхода в инженерии не учитывали важность стейкхолдеров, представления жизненного цикла не как последовательности стадий, а как набора практик. В данном курсе предлагается вариант, основанный на стандартах и публичных документах последних пяти лет, изложение строится на схемах и поддержано задачами по практическому использованию понятий системного подхода. Курс научит проводить системные размышления, определять целевую систему проекта (в том числе, для сложных случаев сервиса и программного обеспечения), различать проверочные и приёмочные тесты и испытания, осознанно подходить к организации междисциплинарных предпринимательских, инженерных и менеджерских работ для сложных проектов. Вы узнаете: − О различиях потребностей, требований и ограничений − О представлении деятельности в виде набора практик − Об архитектуре системы − Как пользоваться системной схемой проекта (возможности, стейкхолдеры, определение и воплощение системы, работы, технологии, команда) для уменьшения проектных рисков − Как отличать важные решения от менее важных − Как бороться со сложностью в самых разных проектах − Как определить свою систему среди чужих − Как объединять в мышлении продукт и деятельность по его созданию − Какие бывают виды жизненного цикла − Как объединить деятельности техпредпринимателя, инженера, менеджера Курс разработан компанией «еНано» (входит в группу РОСНАНО и является разработчиком дистанционных образовательных курсов и программ по нанотехнологиям и технологическому предпринимательству) - образовательным партнером МФТИ. Рекомендован Русским отделением международного совета по системной инженерии (INCOSE), http://incose.ru.
Архитектура
Loading...
Из курса от партнера Moscow Institute of Physics and Technology
Системное мышление
89 оценки
Из урока
Определение и описание системы
На этой неделе вы научитесь минимально смотреть на систему три раза: как на состоящую из компонент, модулей и размещений. А ещё вы научитесь различать объекты-альфы, о которых вы думаете, и рабочие продукты, которые вы видите в реальной жизни. По окончании этой недели вы больше не будете путать требования (которые описывают систему как «чёрный ящик») и архитектуру (которая говорит о системе, как о «прозрачном ящике»). А ещё вы всегда-всегда будете после этой недели управлять конфигурацией ваших систем.
Познакомьтесь с преподавателями
Левенчук Анатолий Игоревич
Президент консалтинговой компании TechInvestLab, научный руководитель Школы системного менеджмента
[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА]
Центральной дисциплиной в системной инженерии,
да и, собственно, в инженерии предприятия, является архитектура.
Архитектурная деятельность.
Architecting.
И центральным описанием,
с которым работают разработчики, является архитектурное описание.
И тут мне, по идее, надо дать определение архитектуры, что это такое.
Я могу сказать какие-то слова формальные, например,
привести определение из ISO 42010, что архитектура (системы) —
это основные понятия или свойства системы в её среде, заключающиеся в её элементах,
их отношениях и принципах её проектирования и развития.
Но вам это ничего не скажет.
Я вам могу долго рассказывать, например, как люди считают, что архитектура —
это определение основных структур системы: функциональной структуры,
конструктивной структуры, структуры размещений.
Но это тоже ничего не скажет, тем более,
что слово «структуры» недаром было убрано из ISO 42010.
Потому что мы говорили, что определение системы,
а архитектура — это часть определения системы, оно есть всегда.
Это означает, что если у нас есть система такая, например, как Интернет,
то у Интернета есть структура.
Но мы же не знаем структуру Интернета.
В какой-то момент в Интернет пришло множество новых узлов,
и ушло, например, перерезали атлантический какой-нибудь кабель,
трансатлантический, ушло много новых узлов.
Появились новые пользователи, ушла старая аппаратура.
Вы же помните, что Интернет в какой-то момент включили,
и с тех пор человечество его не выключало, это одна из немногих систем,
которая работает, работает, самая надёжная, бесперебойная,
не выключалась ни разу с момента её создания десятки лет назад.
Ни на какие профилактические ремонты.
Беда — структуры нет.
Потому что всё это время структура менялась.
И мы поэтому не можем слово «структура»,
хотя мы все интересуемся структурой для создания наших систем,
мы не можем даже слово «структура» оставить в понятии «архитектура».
Более того, у нас дикие споры до сих пор идут о том, что такое архитектура.
Вы видите ссылку, в которой есть набор из более чем 150 определений архитектуры.
Эти споры, что такое настоящая архитектура, они до сих пор не погасли.
Итак, важно какие типы структур системы документируются, какие
принципы проектирования, конструирования и развития документируются, но,
вот что именно делать,
мы не можем сказать, на уровне определения мы это не можем вынести.
Поэтому победило в конечном итоге определение Ральфа Джонсона.
Оно неформальное, оно родилось в одной огромной интернет-дискуссии.
Архитектура — это обо всём важном.
Что бы это ни было.
Осталось только определить, что же у нас является важным.
Что важно в инженерной системе?
Мы считаем, что архитектура, которую многие представляют как
какую-то картинку, на которой нарисована какая-то структурка, ещё другая картинка,
на которой нарисована какая-то структурка, мы считаем, что эти картинки,
они просто отражают последовательность принятых архитектором решений.
Важных решений.
Важным мы считаем то решение, которое, если мы его приняли,
то после него все другие решения надо будет сделать какими-то одними,
а если мы приняли его по-другому, то надо будет сделать какими-нибудь другими.
Итак, что у нас важное, например, в самолёте?
Мы принимаем решение, что у нас будет биплан.
Всё.
Если у нас два крыла, то мы делаем одну конструкцию самолёта.
Если мы приняли решение об одном крыле,
то нам практически весь самолёт надо перепроектировать.
Но мы можем сказать, что там есть и другие важные решения.
Например, если мы приняли решение, что в самолёте есть двигатель реактивный.
Опять можно перепроектировать весь самолёт по сравнению с тем,
если мы приняли решение, что двигатель внутреннего сгорания,
и используется винт.
И вот таких решений набирается некоторое количество, они могут быть отображены на
диаграммах, высказаны словами, не отображены на диаграммах.
Вот эти решения, они принимаются последовательно друг за дружкой,
иногда независимо друг за дружкой, иногда не друг за дружкой.
В разные моменты проекта, например, в самом конце проекта мы принимаем
решение что-то поменять, и вынуждены буквально переделывать всю систему с нуля,
потому что это решение оказывается архитектурным.
Но вот эти решения мы и называем важными.
Мы делаем компрессор.
Винтовой компрессор против спирального, против турбокомпрессора.
Абсолютно разные конструкции, на разных заводах, на разных станках, разные
чертежи, разные принципы действия, разные физические модели для расчёта компрессора.
Хорошо, мы сказали турбокомпрессоры.
Следующее решение.
Масляные против безмасляных.
Мы смазываем или не смазываем ротор, когда он вращается.
А ротор турбокомпрессора вращается очень быстро.
Хорошо, мы говорим, безмасляный, нам не надо делать масляный насос и всё масляное
хозяйство, мы хотим, чтобы было попроще.
Нам тут же говорят: активная против пассивной подвески.
Мы говорим: активная подвеска — это очень сложно, потому что вы должны сделать
электромагниты, датчики, и вы должны на электромагнитах всё время
отслеживать положение ротора и делать так, чтобы ротор парил в магнитном поле.
Хорошо, мы не будем этого делать, мы будем говорить, что пассивная подвеска.
Дальше спрашивают: газостатическая подвеска против газодинамической.
В общем, вы меня поняли, что каждый раз, когда вы принимаете какое-то решение,
если вы решили его повернуть назад и принять другое решение,
вам придётся перепроектировать практически весь турбокомпрессор.
Начиная с того, что он может быть и не турбокомпрессором.
Это уже какое-то решение, если вы выбрали турбокомпрессор,
могли выбрать какое-то другое.
Итак, у вас есть важные решения, которые, если вы принимаете их в другую сторону,
иногда говорят, вы проходите развилки, в системной инженерии это trade of studies.
Прохождение развилок.
Если вы вот в этой развилке приняли одну сторону,
а не другую, то это означает, что все ваши решения дальше намного предопределены,
и вряд ли речь идёт о винтике, если вы приняли решение, что винтик будет другой,
то вы перепроектируете только винтик, но если вы приняли какое-то большое решение и
дальше надо всё перепроектировать, вы точно имеете дело с архитектурой.
И есть такие требования, которые говорят,
что вы должны принять то или иное архитектурное решение.
Эти требования, важнейшие требования,
будут называться архитектурными требованиями.
Например, если самолёт летит со скоростью, скажем,
900 км/ч, то это нормальный самолёт, нормальное требование.
Архитектурное, правда, требование.
Потому что если выяснится, что самолёт летит со скоростью, например,
3000 км/ч, то там уже число Маха поучаствовало,
это означает, что самолёт стал сверхзвуковым, и это означает,
что вы должны полностью поменять конструкцию, перепроектировать всё,
следовательно, скорость самолёта является архитектурным требованием к самолёту.
Архитектурные и неархитектурные решения абсолютно субъективны.
Что для одного архитектора является важным, для другого архитектора,
исходя из его опыта, из его понимания ситуации, будет казаться неважным.
Бывают такие архитектурные review, как говорят, или просмотры.
Архитектурные обсуждения, рассмотрения,
когда другие разные эксперты показывают архитектору,
что то или иное решение, которое он принял, является на самом деле важным.
Архитектор представляет список этих своих решений,
а ему помогают дополнить этот список теми решениями, которые он считает не важными,
а само собой разумеющимися, и говорят, что он мог принять другое решение,
тем самым хоть как-то уходя от вот этой субъективности.
Кроме того, мы понимаем, что архитектурные и неархитектурные решения,
они относительны.
Вот вы видите диаграммку, где кто-то ответственный за, например,
весь самолёт или за, например, всю собачью конуру.
И есть кто-то, кто ответственный за двигатель
самолёта или за одну досочку собачьей конуры.
И те решения, которые абсолютно неважны для того,
кто занимается самолётом в целом, например,
решения по топливному насосу для двигателя,
являются важными для того человека, который занимается этим двигателем.
То есть фактически неразличимо с уровня системного инженера,
кто занимается архитектурными решениями, неразличимо решение,
принятое в самом низу, архитектурное по топливному насосу,
и то это не самый низ, это архитектурное важное решение.
А внизу это решение будет вполне архитектурным.
То есть разные люди архитектурой будут называть абсолютно разные
решения в рамках разделения труда.
И критерий, где же остановиться.
Остановиться системному инженеру принимать свои архитектурные решения и
поручить всё дальше надо там, где он понимает,
что он разбил систему на достаточное число частей, чтобы обеспечить целостность,
чтобы люди могли дальше принимать свои архитектурные решения.
Это вот задача системного инженера.
Напомню я, что это только роль — системный инженер.
Инженер-архитектор, более того, узкая, частная роль.
Один человек может выполнять множество ролей, он может выполнять роли и всех
архитекторов на всех уровнях системы и всех инженеров по требованиям,
и, например, быть ещё не системным инженером, а,
например, инженером-электриком и любым другим инженером.
Но в данном случае мы понимаем, что речь идёт о ролевом разделении труда,
и эти решения по архитектуре субъективны и относительны.
Итак, мы понимаем архитектуру как функция и конструкция.
Это означает, что архитектура — это
функциональная структура и конструктивная структура
соответствия функций и конструкции в их самых важных чертах.
Или оно же как компоненты, плюс модули,
плюс размещение, опять же, только важные, верхнеуровневые.
Или оно же как принципиальная схема, то,
как связаны компоненты, заказная спецификация.
Те модули, которые у нас есть.
Плюс компоновка, где это всё находится во Вселенной.
Но только, опять же, важные, верхнеуровневые.
Или оно же как логическая архитектура.
Логическая, альфы, компоненты, функциональная структура.
Плюс физическая архитектура: модули и размещение.
Опять же, при учёте возражения, что нельзя говорить исключительно о частных,
вот только о логической архитектуре и физической архитектуре,
потому что архитектура — это все важные решения.
Помните, все важные решения.
Но исторически так уже говорят, что логическая архитектура,
физическая архитектура — это разные понятия.
Итак, логическая архитектура и физическая архитектура вместе — это архитектура,
и мы помним, что это, опять же, только всё важное.
Или оно же просто список, смотрите, даже без диаграмм, а просто список вот,
может, в Excel-табличке какой-то важнейших принятых конструкторских или проектных
решений по вашей целевой системе.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
