Книга: Сумма стратегии — ЛитВек — Читать онлайн — читать полностью — Страница 88

Книга: Сумма стратегии - ЛитВек - Читать онлайн - читать полностью - Страница 88 Реферат

Почему моделирование не повсеместно

  1. Полезность моделирования неочевидна. Опыт показывает, что множество решений вполне можно выполнить без моделирования. Никто не может предъявить конкретных цифр, что с моделированием эти проекты были бы выполнены быстрее (решения бы по ним принимались быстрее плюс экономия от меньшего количества ошибок). Кроме того, использование моделирования связано с затратами (закупка софта моделеров, обучение людей), и на одном проекте эти затраты могут не окупиться.
  2. Существующий софт моделирования (моделеры) и поддерживаемые им языки моделирования плохи: неточно отражают моделируемые объекты. Да, каждые пять- десять лет появляются новые языки моделирования и новое поколение программного обеспечения, но по-настоящему хороших и универсальных до сих пор нет. Без языков же и софта моделировать невозможно.
  3. Модели (и результаты моделирования, например, расчёт по модели) оказываются непонятными людям. Решение об использовании моделирования принимают часто не непосредственные пользователи модели, а совсем другие люди — менеджеры и финансисты, которые ничего сами в моделировании не понимают, но знают, что в моделях есть ответ на нужные им вопросы.
  4. Модели являются хорошим средством накопления знаний в организации. Если никто не заинтересован в накоплении знаний, то и интерес к моделированию слабый: зачем спрашивать модель, если всегда можно спросить Иван Иваныча? Мысль же о том, что эти знания можно отделить от Ивана Ивановича в виде модели — эта мысль обычно не обсуждается. Тем не менее, если посмотреть на происходящее в менеджменте и инженерии за последние пятнадцать лет, то из состояния “почти нигде, кроме самых развитых компаний” моделирование перешло в состояние “почти везде, кроме самых отсталых компаний”.

Что такое системная инженерия по?

Термин «системная инженерия программного обеспечения» появился в начале 80-х годов, и его приписывают Уинстону Ройсу [5]. SwSE отвечает за общее техническое управление системой и подтверждение корректности окончательных системных продуктов.

SwSE начинается, когда системные требования разделены на аппаратные и программные подсистемы. SwSE формирует основу для всей разработки программного обеспечения в проекте и, как и SwE, представляет собой одновременно и технический и управленческий процесс. Технический процесс SwSE — аналитическая работа, необходимая для преобразования операционных требований в:

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

SwSE не является описанием работ. Это процесс, который выполняют многие люди и организации: системные инженеры, менеджеры, программные инженеры, программисты и, не стоит забывать пользователи.


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

Впрочем, разработчики программного обеспечения часто игнорируют эти методы. Они считают, что чисто программные системы или системы, работающие на массовых компьютерах, — всего лишь программные, а не системные проекты. Игнорирование системных аспектов разработки программного обеспечения и ведет к кризису.

Системная инженерия лекция 1 — введение в системную инженерию


Подборка по базе: Науменко А. П. Введение…2021-06-04_5.pdf, 2. Введение в фармацевтическую экономику 2 часть.doc, 1. Введение в фармацевтическую экономику..doc, МУРеферат Введение в профессию.pdf, Kontrolnaya введение (2).docx, Образец Введение.doc, 2021.01.16 П-к Введение в курс ПиАСТ —1111.docx, 3 Введение.docx, 1. Введение в фармацевтическую экономику..doc, хорошее введение.docx


ЛЕКЦИЯ 1

ТЕМА1

ВВЕДЕНИЕ В СИСТЕМНУЮ ИНЖЕНЕРИЮ
Содержание лекции:

    1. Появление потребности в системной инженерии.
    2. Цель системной инженерии.
    3. Задачи системной инженерии.
    4. История термина СИ.
    5. Определение СИ.
    6. Требования к системному инженеру.
    7. Понятие «Система».

1.1. Появление потребности в СИ

Исходные  положения  (Батоврин)

Создание систем является одним из основных видов человеческой деятельности.

Создаваемые людьми системы постоянно усложняются.

Появление новых технологий дает толчок к развитию уже существующих систем и требует создания новых классов систем.

В XXI веке ИКТ стали ключевым фактором, оказывающим влияние на создание систем, который во многом заставляет пересмотреть сложившиеся подходы к созданию систем
Инженерное дело – инженерия 

Инженерия (engineering)- область человеческой деятельности, связанная с творческим применением научных принципов для проектирования и разработки конструкций, машин, аппаратов и производственных процессов, с работами по их индивидуальному или комплексному использованию, с их конструированием и применением на основе исчерпывающего представления об устройстве, с предсказанием их поведения в определенных условиях эксплуатации (American Engineers’ Council for Professional Development).

Термин инженерия происходит от лат. ingeniosus — «искусный»

Инженерия это наука, искусство, техническая дисциплина и другие аспекты, относящиеся к реализации изобретений и проблемам достижения поставленных целей.
Важные особенности системной инженерии 

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

Несмотря на важную роль управления при создании продукции и предоставлении услуг системная инженерия это более техническая, нежели управленческая дисциплина

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

За прошедшие 50 лет сложность технических систем существенно увеличилась. Для современных систем характерны:

  • Сложность: до 10 млн. деталей (нефтяная платформа), проект существует до 100 лет;
  • До 1000 контракторов на один проект, у каждого контрактора свой язык;
  • Мультидисциплинарность;
  • Требования и спецификации проекта приходят с самых разных сторон и непрерывно меняются;

Каждый проект стал «вавилонской башней». Так, например, для авианосца только полный набор требований в печатном виде может занимать несколько полностью набитых шкафов. Для того, чтобы доставить такой объем документов от поставщика к заказчику, потребуется даже не один грузовик. А что говорить о проектной документации и самом производстве такой системы, как авианосец! Там, где сложность возрастает «на порядки», на  помощь приходит системная инженерия, которая упорядочивает все процессы и предлагает лучшие практики в виде международных стандартов и методик.

 Книга: Сумма стратегии - ЛитВек - Читать онлайн - читать полностью - Страница 88
Основная роль системной инженерии — объединить смежные дисциплины и специальности (Рис. 2) и обеспечить возможность для коллективной работы по формированию и осуществлению совокупности
Рис 2. Связь системной инженерии с другими науками
процессов, необходимых для построения системы в ее развитии, включая замысел, реализацию, эксплуатацию и утилизации.
Связь системной инженерии с другими дисциплинами (1) 

Сегодня системная инженерия объединяет в себе многие дисциплины, в частности:

моделирование систем

теорию принятия решений

операционное исчисление

программную инженерию

управление проектами

управление требованиями

управление рисками

промышленное проектирование, включая систему конструкторской и проектной документации

оценку затрат

Если кратко сказать, то СИ необходима для наведения порядка в действиях людей. Она предписывает следовать определенной апробированной методологии при проведении работ, не упуская тех моментов, которые, на первый взгляд, кажутся незначительными, и позволяет акцентировать усилия на наиболее критических направлениях работ. По сути это наука, как надо эффективно и оптимально управлять сложными проектами и предприятиями, повышая их конкурентоспособность
1.2. ЦЕЛЬ СИСТЕМНОЙ ИНЖЕНЕРИИ

Системная инженерия на основе объединения достижений различных дисциплин и групп специальностей имеет целью предоставление методологического базиса и средств для успешной реализации согласованных, командных усилий по формированию и реализации хорошо структурированной деятельности по созданию систем, которая охватывает все стадии ЖЦ системы от замысла до изготовления и последующей эксплуатации и прекращения использования.

1.3. ЗАДАЧИ СИСТЕМНОЙ ИНЖЕНЕРИИ

(Батоврин  В.К. Молодежная научная школа. Магнитогорск, октябрь 2009) 

Системная инженерия сосредоточена на:

  • технических усилиях, направленных на проектирование, изготовление, проверку соответствия, ввод в эксплуатацию, использование, сопровождение, утилизацию системных продуктов и процессов, а также на обучение персонала работе с ними
  • определении конфигурации и управление конфигурацией системы
  • преобразовании описания системы в иерархическую структуру работ по её созданию
  • обеспечении заявленных проектных затрат  и графиков работ
  • подготовке информации для принятия управленческих решений

1.4 ИСТОРИЯ ТЕРМИНА СИ
Рост масштабов и усложнение способов организации человеческой деятельности по созданию систем, повышение степени ответственности за ее результаты, быстрое возрастание сложности возникающих при этом научных, технических и управленческих проблем привели к появлению в середине ХХ века новой прикладной системной методологии – системной инженерии [GoodH., MacholR. System Engineering. An introduction to the design of large-scale systems. – N.Y.: McGraw-Hill Book Company, 1957. (Гуд Г. Х., Макол Р. Э. Системотехника. Введение в проектирование больших систем. – М.: Сов. радио, 1962.)

HallA. Methodology for System Engineering. – D. van Nostrand Company, 1962. (Холл А. Опыт методологии для системотехники. – М.: Сов. радио, 1975.)].

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

Так что же это такое Systems Engineering — системная инженерия (СИ)? Идея зародилась в пятидесятых годах прошлого столетия.

В 1961 г. при переводе монографии Г.Гуда и Р.Макола «System Engineering: An introduction to the Design of Large-scale Systems», Ф.Е.Темников предложил термин «системотехника». Редакции издательства «Советское радио» (в последующем «Радио и связь») не нравился буквальный перевод «системная инженерия» или «инженерия систем», и Федор Евгеньевич предложил обобщающее понятие, имея в виду не системотехнику в точном смысле, а системотехнологию.

Рефераты:  Книга: Закат Америки - ЛитВек - Читать онлайн - читать полностью - Страница 25

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

Если бы термин «System Engineering» был принят редакцией «Советское радио» в более точном переводе «инженерия систем», «системная инженерия» или хотя бы «системотехнология», то, возможно, не потребовалось бы поиска новых терминов для прикладных направлений теории систем. Но поскольку в термине в явном виде звучала «техника», термин «системотехника» довольно быстро стал использоваться в основном в приложениях системных методов только к техническим направлениям.

Так оно и пошло дальше: книжка А.Холла «A Methodology for System Engineering» вышла в 1975г. под названием «Опыт методологии для системотехники»

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

В июле 2009 г. произошло знаковое событие — официально было зарегистрировано Русское отделение INCOSE (International Council on SystemsEngineering) (http://community.livejournal.com/incose_ru). INCOSE — это международная организация, объединяющая системных инженеров всего мира. И, если число членов этой организации в США исчисляется тысячами, а в каждой европейской стране сотнями, то на сегодняшний день Русское отделение INCOSE насчитывает не более 30 человек (Анатолий Левенчук -президент Русского отделения INCOSE).

INCOSE — интернациональная организация, сосредоточенная на развитии методологии и практики системной инженерии в интересах промышленности, науки и образования, а также государственных структур. В составе INCOSE более 6000 индивидуальных членов, 60 коллективных членов из различных стран, 20 рабочих групп, более 60 отделений, действующих по всему миру. INCOSE поддерживает сеть обучения, повышения квалификации и сертификации в области системной инженерии, которая оказывает существенное влияние на стандарты, государственную политику и университетские образовательные программы.

Ежегодно INCOSE проводит симпозиумы, на которых собираются представители практически всех стран, членов этой организации. В этом году симпозиум был проведен в Сингапуре, где впервые в 2009 году была представлена и Россия (два сотрудника ОАО «ВНИИАЭС»). При общей численности участников симпозиума в 600 человек добрая половина была из США. Большая часть участников симпозиума представляла организации, профессионально занимающиеся системной инженерией (консультации, обучение, оказание услуг по применению СИ на конкретном проекте или предприятии).

К сожалению, у нас все держится на голом энтузиазме отдельных специалистов. Например, вот уже несколько лет по собственной инициативе курс системной инженерии в Московском государственном институте радиотехники, электроники и автоматики (МИРЭА) и Московском физико-техническом институте (МФТИ) читает заведующий кафедрой информационных систем МИРЭА, профессор кафедры информационных бизнес-систем МФТИ Батоврин Виктор Константинович.
1.5. ОПРЕДЕЛЕНИЕ СИ
Из Википедии:

(Международная организация по стандартизации, ИСО (International Organization for Standardization, ISO) — международная организация, занимающаяся выпуском стандартов.

Международная организация по стандартизации создана в 1946 году двадцатью пятью национальными организациями по стандартизации, на основе двух организаций: ISA (International Federation of the National Standardizing Associations), учреждённой в Нью-Йорке в 1926 году (расформирована в 1942) и UNSCC (United Nations Standards Coordinating Committee), учреждённой в 1944 году. Фактически её работа началась с 1947 года.[ СССР был одним из основателей организации, постоянным членом руководящих органов, дважды представитель Госстандарта избирался председателем организации. Россия стала членом ИСО как правопреемник СССР. 23 сентября2005 года Россия вошла в Совет ИСО.)

 Международная электротехническая комиссия (International Electrotechnical Commission, IEC) — это международная организация, которая занимается разработкой стандартов для электрических, электронных и смежных областей. Многие стандарты МЭК разрабатываются совместно с Международной организацией по стандартизации. Организация IEC, образованная в 1906 г., также как и ISO является добровольной неправительственной организацией. Ее деятельность в основном связана со стандартизацией физических характеристик электротехнического и электронного оборудования. Основное внимание IEC уделяет таким вопросам, как, например, электроизмерения, тестирование, утилизация, безопасность электротехнического и электронного оборудования. Как и в ISO, членами IEC являются национальные организации (комитеты) стандартизации технологий в соответствующих отраслях, представляющие интересы своих стран в деле международной стандартизации. В настоящее время в состав IEC входит более 50 таких членов.

Определение стандарта ISO/IEC IEEE 24765:2021 Разработка программного обеспечения и проектирование систем:
СИ – междисциплинарный подход, определяющий полный набор технических и управленческих усилий, которые требуются для того, чтобы преобразовать совокупность потребностей и ожиданий заказчика и имеющихся ограничений в эффективные решения и поддержать эти решения в течение их ЖЗ.
По поводу термина СИ в настоящее время ведется активная дискуссия.

Алиев [http://ailev.livejournal.com/757223.html] в своей лекции по СИ приводит несколько определений понятия СИ.
Определение 1 (интуитивное)
СИ- это деятельность, направленная на создание какой-либо системы в соответствии с требованиями заинтересованных сторон в определенное время и в рамках выделенных средств.

Это очень простое и в то же время емкое определение, в нем можно выделить следующие ключевые положения:

  • CИ – прежде всего деятельность;
  • В деятельности участвуют много сторон;
  • У заинтересованных сторон есть требования;
  • В процессе деятельности следует уложиться в заданные бюджет и время.

Но выделенные положения присутствуют в любой деятельности. Деятельностью люди занимаются давно, а СИ появилась в 50-х годах прошлого века. СИ появляется тогда, когда сложность систем значительно возросла. Чем больше проект, тем больше вероятность не вписаться в бюджет, время, тем сложнее проблемы организации людей.
ИТАК, СИ – ЭТО ДЕЯТЕЛЬНОСТЬ.
Определение 2
Си – это когда раньше думаешь, а потом делаешь!
Значительная часть докладов на ежегодных симпозиумах INCOSE посвящается «моделеориентированной» системной инженерии. Ее суть в том, что прежде, чем что-то построить или создать реальное, создай виртуальную систему, то есть разработай разнообразные модели: функциональную модель, модель поведения системы, модель организации, модель требований, модель процессов и т. д., затем «проиграй» на моделях варианты архитектуры системы и способов ее создания с поиском оптимального набора процессов и моделей, «верифицируй и валидируй» виртуальную систему на моделях до начала ее воплощения в металле и бетоне.

Для крупных проектов процесс «думания» занимает до 39% времени.

Без СИ до 70% проектов заканчиваются неудачами, выполняется много лишней и ненужной работы. СИ борется с переделками, она их убирает.

СИ трудно продавать, так как люди думают, что они все сделают и без ее методов, но это ведет к переделкам

По данным INCOSE:

  • 8% затрат на внедрение сиcтемной инженерии дают выигрыш в 20% стоимости проектов, и на 50% увеличивают вероятность окончания проекта в срок. Это достигается через
    • введение общего языка, описывающего проект
    • сознательный сдвиг усилий на ранние стадии проекта, где цена ошибки экспоненциально меньше;

Книга: Сумма стратегии - ЛитВек - Читать онлайн - читать полностью - Страница 88

СИ борется с переделками, она их убирает.

СИ — НЕТ ПЕРЕДЕЛОК!!!
Определение 3
(сформулировал президент Incose)

СИ – это способ помочь людям делать большие системы за счет правильных описаний.
СИ – это работа с описаниями, это понимание того, что описаний много, что это – моделирование.

Системный инженер большую часть времени работает с описаниями, а не с самой системой.
Определение 4

СИ – это бюрократическая деятельность.
Системные инженеры работают с бумагами, они для каждой заинтересованной стороны составляют свой набор документов.
Определение 5

СИ – это специалист, который поддерживает целостность системы (целокупность системы).
Системный инженер отвечает за то, чтобы ни один аспект системы не был опущен и ни чьи интересы не были пропущены. Нет другого ответственного за все (допустим, менеджер отвечает только за то, чтобы проект финансировася)системы. Без СИ начинается ReWork системы.

Swse и программная инженерия

И SwSE, и SwE — это технические и управленческие процессы, однако SwE порождает программные компоненты и описывающую их документацию. Более строго, программная инженерия включает в себя следующее.

  • Практическое применение компьютерных дисциплин, менеджмента и других наук к анализу, проектированию, конструированию и обслуживанию программного обеспечения и связанной с ним документации.
  • Наука инженерии, применяющая методы анализа, проектирования, кодирования, тестирования, документирования и управления с целью создания крупных, удовлетворяющих специфическим требованиям программ в определенное время и с определенными затратами.
  • Систематическое применение методов, инструментов и методик, которые позволяют выполнить оговоренные требования и добиться цели, создав эффективную и полезную программную систему.


Рис. 1 иллюстрирует связи между системной инженерией, SwSE и SwE. Традиционная системная инженерия выполняет первоначальный анализ и проектирование, а также интеграцию и тестирование окончательной системы.

Рис. 1. Инженерные связи между системной инженерией, системной инженерией программного обеспечения (SwSE) и программной инженерией

Во время первой стадии разработки SwSE отвечает за анализ требований к программному обеспечению и архитектурный дизайн. SwSE также управляет окончательным тестированием программных систем. Наконец, SwE управляет тем, что системные инженеры называют инженерией компонентов.

Анализ требований

Первый шаг в любой активности, связанной с разработкой программного обеспечения, — определение и документирование требований системного уровня в виде спецификации системных требований или в виде спецификации программных требований. Программные требования включают в себя свойства, которые необходимы пользователю для решения тех или иных задач, а также свойства, которые нужны системе или компоненту для выполнения тех или иных формально представленных документов [7].

Рефераты:  Реферат на тему :"закаливание"


Программные требования можно классифицировать следующим образом [8].

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

Анализ программных требований начинается после того, как системная инженерия определила системные требования заказчика. В его функции входят указание всех (или максимального числа) требований к программной системе, и завершение анализа означает формирование утвержденных базовых требований [2].

Верификация, подтверждение и тестирование

Процесс верификации, подтверждения и тестирования (verification, validation and testing — VV&T) определяет, корректен ли процесс инженерии, и соответствуют ли продукты предъявляемым требованиям [10].

  • Верификация определяет, соответствуют ли продукты на данном этапе цикла разработки программного обеспечения требованиям, утвержденным во время предыдущего этапа. Дает ответ на вопрос: «Так ли я создаю продукт?»
  • Подтверждение определяет соответствие окончательной программы или программного обеспечения требованиям и нуждам пользователя. Дает ответ на вопрос: «Тот ли я создаю продукт?»
  • Тестирование — это выполнение программы или части программы с известными входными и выходными данными, которые известны заранее и которые можно проверить, что позволяет обнаружить ошибки. Тестирование часто считается частью верификации.

VV&T — это непрерывный процесс мониторинга операций системной инженерии, SwSE, SwE и проектного менеджмента с целью убедиться, что они следуют техническим и управленческим планам, спецификациям, стандартам и процедурам. Кроме того, VV&T оценивает промежуточные и окончательные продукты проекта SwE.

SwSE использует методы и инструментарий VV&T для оценки требований спецификаций, описания архитектуры и других промежуточных продуктов. Тестирование выполняется для того, чтобы определить, соответствует ли окончательный продукт спецификациям требований данного проекта.

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

Системная инженерия и SwSE — дисциплины, используемые в первую очередь для технического планирования «на входе» жизненного цикла системы и для проверки того, что к окончанию проекта все планы были выполнены. К сожалению, в реальных проектах эти дисциплины часто игнорируются.

Игнорирование системных аспектов программного проекта может привести к созданию программного обеспечения, которое не будет работать на выбранной аппаратной платформе или не будет интегрироваться с другими программными системами.

Литература

1. W.W. Gibbs, «Software’s Chronic Crisis», Scientific Am., 1994, Sept.

2. IEEE, Software Engineering Standards Collection, vols. 1-4, IEEE Press, Piscataway, N.J., 1999

3. R.H. Thayer, «Software System Engineering: A Tutorial», Software Engineering Volume 1: The Development Process, 2nd ed., R.H. Thayer and M. Dorfman, eds., IEEE CS Press, Los Alamitos, Calif., 2002

4. IEEE Std. 1220-1998, Standard for Application and Management of the System Engineering Process, IEEE Press, Piscataway, N.J., 1998

5. W.W. Royce, «Software Systems Engineering», seminar presented as part of the course titled Management of Software Acquisition, Defense Systems Management College, Fort Belvoir, Va., 1981-1988

6. IEEE Std. 1058-1998, Standard for Software Project Management Plans, IEEE Press, Piscataway, N.J., 1998

7. IEEE Std. 610.12-1990, Standard Glossary of Software Engineering Terminology, IEEE Press, Piscataway, N.J., 1990

8. IEEE Std. 830-1998, Recommended Practice for Software Requirements Specifications, IEEE Press, Piscataway, N.J., 1998

9. IEEE Std. 1016-1998, Recommended Practice for Software Design Descriptions, IEEE Press, Piscataway, N.J., 1998

10. IEEE Std. 1012-1998, Standard for Software Verification and Validation, IEEE Press, Piscataway, N.J., 1998

Ричард Тэйер (r.thayer@computer.org) — почетный профессор программной инженерии Калифорнийского университета в Сакраменто, консультирует по программной инженерии и управлению проектами, ведет исследования и читает лекции в Университете Стречклайда (Глазго, Шотландия).

Контроль процессов

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

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

Контроль должен порождать корректирующие действия — либо приводить состояние проекта в соответствие с планом, либо изменять план, либо прекращать проект. Контроль проекта также состоит из двух отдельных компонентов: контроль, который предусмотрен проектным менеджментом и контроль, который выполняется в рамках инженерии программных систем. В таблице 3 содержится пример разделения функций контроля для проекта программной системы.


Таблица 3. Контроль процессов и контроль проекта

Моделеориентированная инженерия (model-driven engineering)

Как -based, так и -driven оба переводятся как -ориентированная, но имеют разный смысл.

-Based означает, что для решения каких-то задач выполняется моделирование. Далее человек смотрит на результаты моделирования (расчёт, текст, чертёж, диаграмму) и делает очередную модель (расчёт, текст, чертёж, диаграмму). См. MBSE.
-Driven означает, что модель является основным, что работает — на неё не “глядят для осмысления, и сочиняют другую модель”, а она компьютерно преобразуется с добавлением новых данных в другую необходимую модель.

Часто про model-driven подход говорят как о преобразованиях (transformation) моделей. Десять принципов model-driven engineering, сформулированные Jean Bezivin:

  1. Принцип представления: любая модель M представляет объект S.
  2. Принцип множества групп описаний (view): объект S может быть представлен несколькими моделями (мульти-моделирование).
  3. Принцип соответствия: любая модель соответствует мета-модели (моделирование одного логического уровня ведётся с использованием знаний, определённых на другом логическом уровне).
  4. Трёхуровневая организация: любая метамодель MM соответствует общей для них метамодели MMM). Впрочем, это Jean Besivin и AtlanMod настаивают именно на 3 уровнях моделирования, в общем случае логических уровней может быть много.
  5. Принцип трансформации: наиболее важная операция, применимая к модели (группа AtlanMod занимается главным образом переходом от Model-Based engineering к Model-Driven Engineering: их волнует порождение/генерирование по моделям инженерных рабочих продуктов, а не, например, имитационное моделирование или использование моделей для налаживания взаимопонимания между менеджерами, инженерами, клиентами).
  6. Принцип HOT (High-Order Transformation): трансформация (код, описывающий преобразование модели) это тоже модель.
  7. Принцип переплетения (weaving): отношения между несколькими моделями могут быть представлены тоже как модели.
  8. Мегамодель: важна модель, чьи элементы модели и мета-модели плюс отношения между моделями. В мега-модели мы представляем информацию нескольких логических уровней.
  9. Принцип унификации: все упомянутые модели специализируют общую абстрактную (математическую, алгебраическую) модель — высший уровень мета-мета-моделирования.
  10. Подход технического пространства (Technical Space Framework): любая модель имеет внешнее техническое представление (больше нет ограничений на выбор одного языка моделирования для какого-то вида моделей: нотации могут быть разными, модель одна).

Об этой книге

Год назад Сергей Переслегин вместе с другими участниками Группы КБ решил написать книгу, посвященную стратегическому знанию. То есть о стратегии, ее применении, ее будущем и всем, что с ней связано. В современном мире для владения стратегическим знанием нужно знать и понимать много других вещей, поэтому мы решили, что книга будет не только и не столько о военной стратегии.

Мы рассчитываем, что книга «Стратегическое знание» будет полезна и интересна всем читателям. Для кого-то она станет учебником или подспорьем в работе (в ней есть конспекты и схемы). Для кого-то – просто интересным чтением на любимую тематику (в книге много исторических и злободневных примеров успехов и провалов, стратегий и «стратегий»).

Теперь о главном: мы принципиально не хотели связываться с издательствами и публиковать книгу в традиционном бумажном виде. Прошлая книга С.Б. Переслегина, «Дикие карты будущего», уже который год лежит на пыльных складах издательских холдингов. Когда она увидит свет – неизвестно, в издательском бизнесе кризис.

Больше такой ошибки мы повторять не будем.

Наш план:

Пункт 1. Книгу «Стратегическое знание» сразу делать в электронном виде.

Пункт 2. Книга будет выложена на наш сайт и в бесплатные библиотеки Рунета в открытый, свободный, бесплатный доступ.

Рефераты:  Как узнать свой процент жира и изменить его - Лайфхакер

Пункт 3. А как вам нравятся первые два?

На подготовку электронной версии книги нам потребовались деньги – корректоры и верстальщики не работают за бесплатно. Тогда мы объявили среди наших будущих читателей складчину или, как сейчас модно говорить, «краудфондинг». Задача была не только собрать деньги, но и обкатать новую для нас модель издания книг.

Эксперимент продолжался год. По его итогам, мы можем с уверенностью сказать, что результат превзошел все наши ожидания. Мы бы хотели поблагодарить всех наших читателей, благодаря которым эта книга стала возможной. В сборе средств так или иначе приняло участие более 50 человек; в общей сложности удалось собрать 90 тысяч рублей.

Отдельную благодарность мы бы хотели выразить Виталию Федько и Андрею и Дмитрию Белоусовым. С выходом книги, мы по-прежнему не будем распространять ее по подписке, делать к ней платный доступ, страдать из-за копеечных гонораров и заниматься прочей подобной ерундой.

Вместо этого мы публикуем реквизиты наших кошельков Webmoney и Яндекс-деньги. Если вам понравится наша книга и появится желание сказать авторам спасибо и дать денег, у вас будет такая возможность.

Номер кошелька Webmoney: R294655434315

Номер кошелька Яндекс: 410011269637143

Поколения системной инженерии

  1. Классическая системная инженерия использует диаграммную технику — это уже не вольные поэтические метафоры, как в алхинженерии, но много более строгие определения системы: чертежи, диаграммы, таблицы и т.д. Но это не полностью формальное описание: его нельзя как-то формально проверить, оно предназначено для чтения и интерпретации только людьми.
  2. Системная инженерия на основе моделей (model-based systems engineering) предусматривает использование логических (структурных) и физических (числовых) формальных моделей, которые могут непосредственно быть обработаны (проверены, оптимизированы) компьютером. Это позволяет достигать принципиально другой сложности целевых систем: компьютеры проверяют модели на отсутствие разного рода ошибок в разы более производительно и точно, чем это может сделать человек. Основной особенностью MBSE является то, что используются не только численные физические модели, но и “логические” модели, использующие аппарат дискретной математики, плюс алгоритмические модели на языках программирования.
  3. Системная инженерия на основе поиска (search-based systems engineering). Сейчас существует только search-based software engineering (SBSE, термин появился в 2001 году)
  4. Вычисление оптимальных технических решений
  5. Компьютерный поиск (порождение, вывод, вычисление) требований, архитектуры, тестов — это и есть следующее поколение системной инженерии, непосредственно следующее за переходом к моделеориентированности. Для этого нужно искусственное инженерное воображение (экономная генерация всё более и более подходящих вариантов инженерных решений) и искусственный инженерный вкус (умение оценить эти варианты). Во всех случаях для инженерии необходимо использовать гибридные (численные логические) выводы/вычисления, целевая система описывается в терминах структур системы (компонент, модулей, размещений в их иерархиях) и численных параметров (физических свойств), и нужно работать не только с логическими и не только с мультифизическими моделями, но и с их гибридами. В конце концов, архитектура системы получается путём нахождения (поиска, воображения, хоть и искусственного) совмещения логической/функциональной и физической архитектур, то есть логического идеального структурного мира с грубым материальным численно описываемым физическим миром.

Предмет системной инженерии

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

  • разработке архитектуры систем, проектированию систем и их элементов;
  • системному анализу и исследованию операций;
  • управлению инженерной деятельностью;
  • выбору технологий и методик;
  • эффективному управлению жизненным циклом системы.

Профиль современной системной инженерии включает следующие основные области деятельности:

  1. Управление организацией (организационно-управленческая деятельность).
  2. Управление проектами (проектно-управленческая деятельность).
  3. Управление инженерными решениями (проектно-инженерная деятельность).
  4. Специальные инженерные дисциплины (технологическая деятельность).

Системы и системная инженерия

Системная инженерия — это практическое применение научных, инженерных и управленческих навыков, необходимых для преобразования операционных требований в описание конфигурации системы, которая наилучшим образом удовлетворяет этим требованиям. Это общий процесс решения проблем, который применяется ко всему техническому управлению в проекте, посвященном разработке системы, предоставляя механизм формулирования и совершенствования определений изделий и процессов системы.

Стандарт IEEE Std. 1220-1998 описывает процесс системной инженерии и ее применение на протяжении всего цикла жизни изделия [4]. Системная инженерия порождает документы, а не оборудование. Документы связывают процессы разработки с циклом жизни проекта. Они определяют предполагаемые окружения процессов, интерфейсы и инструменты управления рисками в рамках всего проекта.

Системная инженерия включает в себя пять функций.

  • Определение проблемы — указание потребностей и ограничений путем анализа требований и взаимодействия с заказчиком.
  • Анализ решений — выделение набора возможных способов удовлетворения потребностей и ограничений, их анализ и выбор оптимального.
  • Планирование процессов — определение задач, которые должны быть выполнены, объема ресурсов и затрат, необходимых для создания изделия, очередности задач и потенциальных рисков.
  • Контроль процессов — определение методов мониторинга проекта и процессов, измерение прогресса, оценка промежуточных изделий и принятие по мере необходимости корректирующих действий.
  • Оценка изделий — определение качества и количества создаваемых изделий путем оценочного планирования, тестирования, демонстрации, анализа, верификации и контроля.

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

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

Уровни обобщения

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

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

В книге «Системноинженерное мышление» используются следующие уровни обсуждения (сверху вниз):

  1. Философско-логический: выбрать предельные онтологии (об общей природе мира, природе описаний, природе интерпретирующего эти описания сознания).
  2. Формально-математический: выбрать математический аппарат теории множеств, математической логики, теории графов, теории категорий, или какой-то ещё. К этому же уровню относится выбор того или иного языка программирования или языка моделирования.
  3. Онтологический: договориться, что мы видим в мире, какие индивиды, классы и отношения (А ещё мы можем видеть объекты и атрибуты, трансформации, прототипы, или теории — в зависимости от решений, принятых на предыдущих уровнях.) Это уже не предельная онтология с первого уровня, тут нам надо договориться о том, что нужно именно для нашей деятельности. Именно на этом уровне определяется системное мышление, выясняется, в чём суть системного подхода, определяется, что такое “система” или “процесс”. Онтологический уровень тесно связан с уровнем математического формализма, но отличается от него. Если в мире есть “системы”, то на более высоком уровне можно использовать теории категорий (и записывать знание теоркатегорными уравнениями) или теорию множеств (и записывать логические предикаты). Примером совместной работы специалистов одновременно на формально-математическом и онтологическом уровнях являются различные стандарты представления данных, такие, как ISO 15926.
  4. Деятельностный: научиться описывать человеческую деятельность, описывать дисциплины с их основными понятиями. Для этого нужно задать язык описания практик работы, язык планирования и организации работы, междисциплинарного взаимодействия, работы конкретного предприятия. На этом уровне определяются стандарты ситуационной инженерии методов, архитектуры предприятия, описания бизнес-процессов, органиграмм и т.д. С использованием понятий онтологического уровня на языке математического аппарата описываются стандартные классы и отношения, создаются справочные данные, специфичные для деятельности.
  5. Профессиональный: на этом уровне описываются конкретные виды менеджмента, инженерии, научных исследований и прочих профессиональных видов деятельности. Иногда этот уровень называют “методологическим” — на нём описываются методы профессиональной работы, достаточные для решения каких-то узких классов задач. Именно тут задаются основные понятия разных менеджерских и инженерных дисциплин (например, “value proposition” для менеджмента, “архитектура” для системной инженерии, «здание» для гражданского строительства). Занимаются этим профессиональные методологи и “рефлексирующие” инженеры и менеджеры, и делают они это в организациях по стандартизации, профессиональных ассоциациях, университетах. На этом уровне продолжается развитие стандартных справочных данных, уже для отдельных специальностей и профессий.
  6. Предпринятия: на этом уровне описывается происходящее в конкретном предпринятии. (Это не опечатка: “предпринятие” — от слова “предпринять”, но вовсе не “предприятие” как юридическое лицо. “Проект” в смысле проектного управления – это тоже ”предпринятие”). Тут с использованием профессиональных понятий моделируется (уже не мета-моделируется!) то, что происходит “в жизни”, в привязке к конкретным условиям работы в ООО “Незабудка” по проекту ремонта лифта «к празднику». Занимаются этими описаниями люди конкретного предпринятия, используя понятия и методы, созданные на всех верхних уровнях.
Оцените статью
Реферат Зона
Добавить комментарий