Форум АСУ в Україні

форум з автоматизації для викладачів, студентів та спеціалістів
Сьогодні: 28 березня 2024, 20:13

Часовий пояс UTC + 2 годин [ DST ]




Створити нову тему Відповісти  [ 177 повідомлень ]  На сторінку Поперед.  1, 2, 3, 4, 5, 6, 7 ... 18  Далі
Автор Повідомлення
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:47 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.2.7. Инженерный менеджмент

Можно также думать, что маркетинг/стратегирование и операционный менеджмент в паре составляют инженерный менеджмент (engineering management) -- это дисциплина, занимающаяся менеджментом в инженерных организациях.
...
Тем не менее, возникает вопрос: является ли инженерный менеджмент отдельной полноценной дисциплиной с какими-то особыми практиками, или это просто такое "вечномодное" слово для обозначения произвольно сбалансированной учебным заведением смеси из инженерных дисциплин и дисциплин MBA? Переформулирую: есть ли в инженерном менеджменте что-то такое, чего не преподают ни чистым инженерам (в том числе системным инженерам), ни менеджерам (которые MBA или MSM, Masterof Science in Management)?!
...


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:47 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.2.8. Практики

Каждая поддисциплина может разбиваться на поддисциплины дальше, но может становиться практикой, если добавляются знания о том, какие в предпринятии используются технологии (инструменты и рабочие продукты).
Тем самым в простейшем варианте (пока мы не обращаем внимания на дела, процедуры, операции и т.д.):
  • Дисциплина = набор альф, уровень учебника ("дисциплина грузится в голову").
  • Технология = рабочие продукты (нотации моделей, формы документов, софт, станки, инструменты), по которым можно определять состояния альф. Технология разворачивается на предприятии, для этого менеджмент должен выделить необходимые ресурсы.
  • Практика = дисциплины + технология.

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

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

По русски чаще всего описание практики оформляют в виде "методических рекомендаций", "методики".


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:48 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.2.9. Метод

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

Практики, которые составляют (articulate, makes up, contained in) метод, должны удовлетворять свойствам:
● однородности (coherency): достижение цели каждой практики даёт вклад в достижение цели всего метода.
● связности (consistency): каждый вход (entry) и результат (result) взаимосвязаны и используются.
● полноты (completeness): достижение целей всех практик означает достижение цели метода и достигает ожидаемого результата.
Эти свойства в начале создания (authoring) метода почти никогда не присутствуют, любой проект начинает набирать практики своего метода по мере понимания ситуации.

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

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

В зарубежной практике слова method, methodology обычно считаются синонимами. По-русски описание метода иногда называется "методология" (не путать с "методикой", которая только часть методологии и означает обычно описание практики).


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:50 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.2.10. Методологическая действительность и действительность предпринятия

Когда мы обсуждаем деятельность, дисциплины, практики -- это обсуждение "вообще", не относимое к конкретному проекту, начинанию (предпринятию). Говорят о "методологической действительности/реальности" (не будем отвлекаться на тонкие философские нюансы отличия действительности от реальности), в которой идёт это "обсуждение вообще". Мы описываем деятельность, но пока ничего не делаем. Мы описываем, как оно бывает "вообще", говорим о типах и классах предметов, но не о самих предметах из реальной жизни. Эти типы и классы предметов в тачку не положишь, ногой не ударишь -- это абстрактные объекты.

В "реальности предпринятия" обсуждаются уже конкретные объекты и дела этого предпринятия (так называемые "индивиды", individual -- которые можно ударить ногой, или погрузить в тачку, т.е. которые имеют протяжённость в пространстве-времени).
Так что какая-нибудь "сборка газодинамического подшипника" может быть описана два раза: в методологической действительности (как вообще собирают такие подшипники) и в действительности предпринятия (как собирается конкретный подшипник с серийным номером №123456).


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:50 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.3. Семь основных альф инженерного проекта

2.3.1. Основы системной инженерии: альфы инженерного проекта

Основы (kernel из OMG Essence) включают в себя семь альф трёх дисциплин. Все эти альфы тесно связаны друг с другом, на диаграмме приведены лишь некоторые основные связи. Нужно чётко понимать, что представление инженерного проекта через эти основные альфы -- это существенное огрубление реальности. Но именно это огрубление реальности позволяет из "цветущей сложности" выделить главное, на чём нужно будет сосредоточить мышление -- какие-то детали при этом неизбежно потеряются, но ситуация "слона-то я и не заметил" будет встречаться реже. В каждом инженерном проекте минимально нужно отслеживать семь альф в трёх дисциплинах, меньше объектов внимания и дисциплин работы с ними иметь нельзя.
Это отслеживание и работа по изменению всех семи основных альф происходит в течение всего проекта. Когда в проекте происходит "пожар", люди работают по ночам и всё внимание уделяется провальной составляющей проекта, знание этого простого факта -- необходимости удержания во внимании всех семи альф на протяжении всего проекта -- позволяет уберечься от "глупых ошибок".


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:51 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.3.2. Стейкхолдеры

Никаких инженерных проектов не происходит, если нет их выполняющих людей. Инженерные проекты затрагиваются самыми разными людьми, и инженерные проекты затрагивают самых разных людей. Эти люди могут быть как "одиночками", так и организованными в группы, в том числе организованные в группы с известным им распределением полномочий (организации). Эти люди, группы и организациии, которые затрагивают проект, или которых затрагивает проект, называются стейхколдерами (stakeholders/заинтересованные стороны).
Перевод "заинтересованные лица" не так хорош, ибо этот термин закреплён в законодательстве за юридическими лицами и при общении с менеджерами-юристами и экономистами возможна путаница).
Стейкхолдеры -- это "действующие лица" (как в театре) проекта, а исполнители этих ролей -- конкретные люди и организации. Мы назовём это "театральной метафорой", при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: "действующие лица и исполнители". Нельзя путать "архитектора" и "Василия Петровича" -- так же нельзя, как нельзя путать "принца Гамлета" и исполняющего его роль "Василия Петровича".

Стейкхолдеры условно делятся на "внешних" и "членов команды". Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет -- разве что члены команды будут работать бесплатно, и будут исполнителями также и в других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).
Стейкхолдеры требуют согласовать с ними определение системы (прежде всего требования -- определение системы как "чёрного ящика", ибо как устроена система внутри интересует отнюдь не всех стейкхолдеров) и используют (стейкхолдеры-пользователи) воплощение системы, ради создания которого и затевается инженерный проект.
Простейший рабочий продукт, отражающий альфу "стейкхолдеры" -- это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM (customet relationship management).
Зображення


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:52 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.3.3. Возможности

Сам инженерный проект начинается с появления возможностей (opportunity) по его проведению -- это обстоятельства, которые делают возможным разработку (или доработку -- изменение уже имеющейся) системы. Наличие возможности существенно зависит от времени ("окно возможностей" -- период времени, в течение которого существует возможность выполнения проекта).
Возможности прежде всего характеризуют пользовательские потребности (пользовательские нужды, user needs -- то, что хотят пользователи такого, для чего им поможет наличие воплощения системы), но они также отражают и наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей .
Именно возможности мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.

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

Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:
● Маркетинг и продажи, стратегирование и предпринимательство -- для установления user needs);
● Управленческий (финансовый) учёт -- для обоснования прибыльности.
Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания/ и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы) -- это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:53 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.3.4. Определение системы

Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что "неопределено" (задача "пойди туда, не знаю куда, найди то, не знаю что" -- это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырехмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, "определить" её). Альфа "определение системы" (system definition) служит как раз для этой цели.

У альфы определения системы (system definition) главные подальфы (части) прежде всего:
  • Требования (описание назначения системы в её операционном окружении. Требования определяют систему как "чёрный ящик")
  • Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система -- описание "прозрачного ящика". Изменение каждого из архитектурных решений на поздних стадиях проектирования ведёт к существенному перепроектированию всей системы).
  • Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)

С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран соответствующий метод описания. Наука -- это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах -- описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию. Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии -- т.е. для записи определения системы как "мыслей по поводу системы, свойств системы" можно создать инженерный артефакт: нотацию.
Итого: определение системы -- это про биты, про информацию, про то, как мы говорим о системе.
Основные дисциплины работы над определением системы -- это проектирование и конструирование.
Альфой определения системы занимается системный инженер.
Зображення


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:54 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.3.5. Воплощение системы

Воплощение системы (system realization, буквально: вынос в реальность) -- это четырехмерное воплощение системы в нашем материалом мире, это про организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.
Конечно, воплощение системы будет называться везде по-разному:
  • У конструкторов это чаще всего "изделие" или "продукт" (product)
  • У проектантов это часто "установка" (plant)
  • У проектантов очень крупных объектов (например, атомных станций) это "сложный инженерный объект"
Мы принимаем, что когда мы пишем название системы ("насос"), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).
Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект.
Очень часто говорят об инженерном проекте по создании сервиса -- например, "сервис стрижки волос". Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, "парикмахерская", которая будет оказывать "сервис стрижки волос".

Воплощение системы в материальном мире есть и у программной системы: программа ведь не существует без носителя. Но в конкретном случае исполняемая программа в машинном коде, взятая в какой-то момент её существования подразумевает конкретное сочетание вещества и полей (магнитных доменов в флешках, заряженных ячеек в оперативной памяти, в регистрах процессора) -- каждому такту выполнения программы соответствует какое-то определённое состояние вещества, как и каждому такту работы какой-то другой "железной" системы. Конечно, при рассуждениях происходит абстрагирование от этой "физикализации" программы, но полезно помнить, что исходный код -- это рабочий продукт определения системы. Одно определение системы обычно может пригодиться при создании тысяч и тысяч воплощений системы. Так и в случае софта: воплощение программной системы -- это исполняющаяся (иногда в тысячах и миллионах экземплярах) программа, а не исходный её код.
Воплощение системы используется стейкхолдерами, оно реализует возможности. Воплощение системы удовлетворяет определению системы.
Основная дисциплина работы над воплощением системы -- это производство.
Альфой воплощения системы занимается системный инженер.


Догори
 Профіль  
 
 Тема повідомлення: Re: Системноинженерное мышление в управлении жизненным циклом
ПовідомленняДодано: 26 червня 2014, 10:55 
Офлайн
Викладач

З нами з: 29 листопада 2013, 17:11
Повідомлення: 5033
2.3.6. Команда

Команда (team) инженерного проекта -- это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами).

Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый человек занял своё место на логистическом "конвейере" (ибо если какие-то места на этом "конвейере" не будут заполнены людьми, то целевая система просто не сможет выпуститься -- необходимые на этом рабочем месте работы не будут произведены), нужно его "уговорить". Это функция "комиссара", пропагандиста, специалиста по менеджерской дисциплине "лидерство" (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать "личное" и "общественное").
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
Зображення


Догори
 Профіль  
 
Відображати повідомлення за:  Сортувати за  
Створити нову тему Відповісти  [ 177 повідомлень ]  На сторінку Поперед.  1, 2, 3, 4, 5, 6, 7 ... 18  Далі

Часовий пояс UTC + 2 годин [ DST ]



Хто зараз онлайн

Зараз переглядають цей форум: Немає зареєстрованих користувачів і 1 гість


Ви не можете створювати нові теми у цьому форумі
Ви не можете відповідати на теми у цьому форумі
Ви не можете редагувати ваші повідомлення у цьому форумі
Ви не можете видаляти ваші повідомлення у цьому форумі
Ви не можете додавати файли у цьому форумі

Знайти:
Вперед:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Вы можете бесплатно создать форум PHPBB2 на MyBB2.ru, Также возможно создать форум бесплатно PHPBB3 на Getbb.ru
Український переклад © 2005-2007 Українська підтримка phpBB