Системное мышление является общим навыком, необходимым всем специалистам, которые участвуют в коллективной работе по выполнению сложных проектов, оно лежит в основе деятельности системных инженеров, менеджеров и технологических предпринимателей. Знания и навыки системного мышления незаменимы для выстраивания междисциплинарной работы, и позволяют проектной команде эффективно общаться на общем для всех системном языке. Предыдущие поколения системного подхода в инженерии не учитывали важность стейкхолдеров, представления жизненного цикла не как последовательности стадий, а как набора практик. В данном курсе предлагается вариант, основанный на стандартах и публичных документах последних пяти лет, изложение строится на схемах и поддержано задачами по практическому использованию понятий системного подхода. Курс научит проводить системные размышления, определять целевую систему проекта (в том числе, для сложных случаев сервиса и программного обеспечения), различать проверочные и приёмочные тесты и испытания, осознанно подходить к организации междисциплинарных предпринимательских, инженерных и менеджерских работ для сложных проектов. Вы узнаете: − О различиях потребностей, требований и ограничений − О представлении деятельности в виде набора практик − Об архитектуре системы − Как пользоваться системной схемой проекта (возможности, стейкхолдеры, определение и воплощение системы, работы, технологии, команда) для уменьшения проектных рисков − Как отличать важные решения от менее важных − Как бороться со сложностью в самых разных проектах − Как определить свою систему среди чужих − Как объединять в мышлении продукт и деятельность по его созданию − Какие бывают виды жизненного цикла − Как объединить деятельности техпредпринимателя, инженера, менеджера Курс разработан компанией «еНано» (входит в группу РОСНАНО и является разработчиком дистанционных образовательных курсов и программ по нанотехнологиям и технологическому предпринимательству) - образовательным партнером МФТИ. Рекомендован Русским отделением международного совета по системной инженерии (INCOSE), http://incose.ru.
Описание систем: субъективно и требует метода
Loading...
From the course by Moscow Institute of Physics and Technology
Системное мышление
38 оценки
From the lesson
Определение и описание системы
На этой неделе вы научитесь минимально смотреть на систему три раза: как на состоящую из компонент, модулей и размещений. А ещё вы научитесь различать объекты-альфы, о которых вы думаете, и рабочие продукты, которые вы видите в реальной жизни. По окончании этой недели вы больше не будете путать требования (которые описывают систему как «чёрный ящик») и архитектуру (которая говорит о системе, как о «прозрачном ящике»). А ещё вы всегда-всегда будете после этой недели управлять конфигурацией ваших систем.
Meet the Instructors
Левенчук Анатолий Игоревич
Президент консалтинговой компании TechInvestLab, научный руководитель Школы системного менеджмента
[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА]
Мы сейчас разберемся, как описывать систему.
Мы должны понимать, что описание системы субъективно,
что описание системы всегда связано со стейкхолдерами.
Это главное, что вы вынесете из этого материала.
Но есть, как всегда, детали.
Итак, начинаем мы рассматривать всегда воплощение системы.
И воплощение системы всегда каким-то образом удовлетворяет определению системы.
Определение системы всегда есть,
но мы просто иногда не имеем его в виде рабочего продукта.
То есть есть логический объект, объект из учебника, мы не знаем, какой,
пока не посмотрели.
Какой-то рабочий продукт.
Рабочий продукт — это описание системы.
Итак, запомнили, что у нас есть определение системы, оно есть всегда,
оно соответствует воплощению системы, например,
у нас существует какая-то собачья будка,
и у нас есть определение собачьей будки.
Но у нас может в этот момент не быть описания собачьей будки,
то есть ни одного документа, ни одной фотографии, не будет требований,
не будет архитектуры, не будет какой-то документации,
которая позволит изготовить эту собачью будку с точностью,
достаточной, чтобы просто взять размеры и изготовить,
так называемая рабочая документация.
То не есть архитектурно важное решение, не требование описания функциональное
какое-то или описания качества, как черного ящика, а с достаточной точностью.
Вот ничего этого не будет, но объекты идеальные есть,
а документации не будет, описания не будет.
Итак, разделили.
Воплощение системы — сама собачья будка, то, как мы о ней говорим,
вот эти определения: это требования,
это разные другие виды описаний, архитектура,
рабочее описание для того, чтобы можно было изготовить,
какие-то другие виды описаний.
Но после этого у нас есть кроме definition, у нас есть description.
У нас есть описание, рабочие продукты.
А вот это уже совсем другие документы, например, может быть какая-то
функциональная диаграмма, которую можно подержать в руках,
которую можно найти в конструкторском бюро, которую можно найти на столе того
человека, который решил сделать собачью эту будку.
У нас есть архитектура — список трех или четырех важных решений,
плоская крыша или остроугольная крыша.
Делаем мы внутри будки вентилятор, или собака и так обойдется без вентилятора,
без проветривания принудительного.
Эти важные решения, они есть, они в определении системы,
system definition, но если мы их записали на бумажке или если
мы их записали хотя бы на магнитной ленте, они в рабочем продукте,
они документированы, они с этого момента становятся описанием системы.
Итак, разделили: альфа и рабочий продукт.
Альфа — definition, рабочий продукт — description.
Как же читать ту сложную диаграмму, которую вы сейчас видите?
Конечно, у нас есть стейкхолдер, которого как-то затрагивает воплощение системы.
У этого стейкхолдера всегда есть какой-то интерес.
Это мы уже проходили, мы подробно об этом сейчас говорить не будем.
И мы понимаем, что есть всегда какое-то описание,
которое отвечает на вот этот интерес,
описание, которое удовлетворяет этот интерес.
И это описание частное, оно тематическое, оно, если вы помните, что
интерес — это тема, оно отвечает только на этот интерес, но ни на какие другие.
И вот вместе такие описания,
которые все отвечают на интересы, то есть рабочие продукты,
они составляют общее полное описание системы.
Итак, мы понимаем, что для того чтобы получить полное описание системы,
надо ответить на все стейкхолдерские интересы.
Если нет интереса, то нам не нужно описание, его запрещено готовить.
Запрещено делать рабочие продукты, которые потом никакие стейкхолдеры не читают.
Просто запрещено.
И наоборот, если есть стейкхолдер и у него есть какой-то интерес, то вы обязаны
подготовить рабочий продукт, какое-то описание, которое прочтет стейкхолдер.
Но этого мало, потому что требуется стандартом
ISO 42010 — это первый стандарт, который это нашел и начал это требовать.
Стандарт 42010 говорит, что если вы готовите какое-то описание,
то у вас есть метод описания,
у вас есть то, что вы используете для того,
чтобы подготовить описание, тот мыслительный аппарат,
те определения, которые вы используете для того, чтобы подготовить описание.
И если у вас есть карта, например, карта полезных ископаемых,
то у вас есть понимание, что есть метод описания этих ископаемых и есть
специальные значки, которыми вы обозначаете руду, значки,
которыми вы обозначаете уголь, то есть у вас есть легенда карты.
И вы должны следовать этой легенде.
Если у вас не карта, а если у вас какой-то чертеж, плоскостной чертеж,
то у вас есть какой-то ГОСТ, который говорит, какие там типы линий, что вы
должны изображать на этом чертеже, а что вы не должны изображать на этом чертеже,
как вы обозначаете углы, как вы обозначаете размеры на этом чертеже,
то есть опять же есть какая-то легенда, какие-то правила построения этих чертежей.
Итак, каждый раз, когда у вас есть частное описание, то у вас есть метод описания.
И говорят так, что интерес оформляется frames, вот этим методом.
Итак, если у вас есть интерес, то сначала перед тем,
как вы описываете, вы должны понять, как именно вы описываете.
И выбрать соответствующий метод описания, частный, отвечающий на интерес.
В свою очередь, одно описание
частное у вас бьется на множество самых разных моделей.
А соответственно, метод описания бьется на то,
как вы описываете разные виды моделей.
Итак, есть модели, описывающие конкретный объект, и есть виды, моделей,
которые говорят, как именно описываются те или иные объекты.
У нас есть интерес финансовый,
у вас есть частная группа описаний финансовая, и у вас есть метод описания,
который вы берете, финансовые методы описаний, например, система российского
бухгалтерского учета, международная система бухгалтерского учета.
Там есть разные правила, поэтому перед тем, как отвечать вопросы про финансы,
вы должны выбрать соответствующий метод.
Следовать российским правилам бухучета,
следовать международным правилам либо правилам учета какой-то страны.
Либо проигнорировать то,
что у вас есть так называемые библиотечные методы описания, которые просто есть,
и вы тогда должны изобрести собственный метод описания.
Ежели мы посмотрим на то, из чего состоит этот набор описаний,
частные описания, то вы увидите модели: это баланс,
это отчет о прибылях и убытках, это cash flow.
И соответственно у вас в видах моделей будет описано,
какие именно правила у вас будут для вот этих моделей,
что там за объекты, как вы эти объекты определяете в жизни,
что вы с ним делаете, как соединяете, как проверяете.
Вот это то, что относится к видам моделей.
Итак, у вас полная структура.
У вас есть воплощение системы, стейкхолдера что-то интересует,
стейкхолдер заявляет свой интерес,
ему подбирают оформляющий этот интерес метод описания,
в нем разные виды моделей делают разные модели,
которые описывают объект не просто так, а теперь это будет как-то
соответствовать интересам, которые есть у стейкхолдера.
Эти все модели объединяются в частную группу описаний по какой-то тематике,
и все частные группы описаний объединяются в полную группу описаний,
в полное описание системы.
И в мыслительном пространстве у нас этому описанию
соответствует определение системы.
Вы видите не слайде две диаграммы: одна русскоязычная диаграмма,
другая англоязычная.
Они чуть-чуть различаются, потому что вы понимаете,
что эти диаграммы представляют собой просто выборку из довольно сложной
сети разных других альф, разных других рабочих продуктов.
Тут показаны отнюдь не все линии, а каждую из этих связей между
элементами диаграммы вы можете читать в разных направлениях.
Найдите, тут есть минимум два несоответствия.
И вы просто видите два разных варианта одной и той же диаграммы в
английской версии и в русской версии.
И вы должны понимать, что многие другие диаграммы этого курса — это просто либо
расширение этой диаграммы, либо, наоборот, кусочек этой диаграммы,
но к нему приписаны еще другие элементы, показаны другие связи.
Вы видите, что эта диаграмма ISO 42010 про архитектурное описание,
но мы просто обобщили ее с архитектурных описаний на другие виды
описаний: описание требований, описание рабочки так называемой,
то есть то, что используется для изготовления, конечно, архитектурное
описание и разные другие виды описания, которые вы встретите в жизни.
Но мы использовали значки из стандарта ESSENCE,
то есть разделили там рабочие продукты и альфы, то есть то,
что мы можем найти в жизни — рабочие продукты, и то, в терминах чего мы думаем,
те идеальные объекты — альфы, которые мы отслеживаем в проекте.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
