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

Обновлено: 05.07.2024

Успешные системы — это то, чем занимается системная инженерия. Слово “успешные” тут крайне важно и означает, что система должна удовлетворить нужды заказчиков, пользователей и других стейкхолдеров (стейкхолдеры — это те, кто затрагивается системой, или кто затрагивает систему). Успех — это когда системой все довольны.
Слово “системы” используется в очень специальном значении: это “системы” из системного подхода. Для системной инженерии слово “система” примерно то же, что “физическое тело” для ньютоновской механики — если вы сказали про компьютер “физическое тело”, то это автоматически влечёт за собой разговор про массу, потенциальную энергию, модуль упругости, температуру и т.д.. Если вы сказали “система” про компьютер, то это автоматически влечёт за собой разговор про стейкхолдеров и их интересы, требования и архитектуру, жизненный цикл и т.д..
Междисциплинарный подход — системная инженерия претендует на то, что она работает со всеми остальными инженерными специальностями (впрочем, не только инженерными). “Подход” обычно означает какие-то наработки в одной предметной области, которые можно перенести на другие предметные области. Междисциплинарность — это очень сильное заявление, оно означает, что системная инженерия может в одну упряжку впрячь коня и трепетную лань (например, инженеров-механиков, баллистиков, криогенщиков, психологов, медиков, астрономов, программистов и т.д. в проектах пилотируемой космонавтики).
Слово “воплощение” (realization, “перевод в реальность”) означает буквально это: создание материальной (из вещества и полей) успешной системы.

Почитайте, в тексте по ссылке рассказана очень любопытная история, включая экскурс в английскую грамматику для данного случая. Грубо говоря, под "инженерией систем" (например, control systems engineering, manufacturing systems engineering) понимается что ни попадя: легко выкинуть слово "система", которое лишь обозначает некий "научный лоск". Инженеры легко любой объект называют "системой", не задумываясь об осознанном использовании при этом системного мышления, не используя системный подход, “инженерия управляющей системы” это просто “инженерия управляющего объекта”. Никакого специального мышления при этом не предусматривается, слова “система” и “объект” взаимозаменяемы. В самом лучшем случае про систему скажут, что “она состоит из взаимодействующих частей” — на этом обычно разговор про “систему” и “системность” заканчивается, он не длится больше двадцати секунд.

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

Поэтому желающие заниматься "инженерией систем" -- не трогайте их, пусть делают своё частное узкое специальное инженерное дело, они очень полезны и нужны, но они не системные инженеры.

В последние годы увеличилось количество перводов инженерной литературы, и слово engineering не удосуживаются перевести как “инженерия”, так и оставляют “инжинирингом”. Перевод “системный инжиниринг” уже начинает побеждать — это легко отследить по результатам сравнения в интернет-поисковых системах. Можно считать, что “системная инженерия” и “системный инжиниринг” синонимы, но есть маленькая проблема: в России почему-то в тех местах, где занимаются инженерным менеджментом, а не инженерией, называют его “системным инжинирингом”. Так что будем считать “инженерию” и “инжиниринг” синонимами, но в случае “инжиниринга” проверять на всякий случай, не менеджмент ли имеется ввиду вместо чисто инженерной работы.

Целокупность, которая подчёркнута многократно — от “междисциплинарности” в первой половине определения до целостности всех действий по созданию системы во второй половине определения, до целостности/полноты проблемы, до охвата всего жизненного цикла системы “от рождения до смерти”. Целостность (полнота охвата всех частей целевой системы согласованным их целым), междисциплинарность (полнота охвата всех дисциплин) — это ключевое, что отличает системную инженерию от всех остальных инженерных дисциплин.
Параллельность выполнения самых разных практик (а не последовательное выполнение их во времени, как можно было бы подумать, прочитав перечисление практик)
Много особенностей, которые будут понятны позднее (различение нужд пользователей и требований, проверки и приёмки, упор на синтез для противопоставления “аналитическим” дисциплинам и т.д.).

Ответственность за целокупность и междисциплинарность

Ответственность за всю систему как целое (whole system) и связанная c этим межпредметность/междисциплинарность (interdisciplinary) подхода к другим инженериям (механической, электрической, программной, предприятия и т.д.) отличают системную инженерию от все других инженерных дисциплин. Представим себе ледовую буровую платформу:

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

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

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

Самолёт — это много-много кусков металла и пластика, синхронно летящих на скорости 900км/час (0.85 от скорости звука, это типовая скорость Boeing 787 Dreamliner) на высоте 10км. Системный инженер — это тот, кто придумал, как обеспечить их надёжный и экономичный совместный полёт, увязав самые разные требования (грузоподъемность, расход топлива, дальность полёта, шум при взлёте и посадке, требования к длине разбега и посадки, необходимость лёгкого обслуживания на земле, отсутствие обледенения, безопасность людей на борту, и т.д. и т.п.), при этом требования выдвигались самыми разными людьми, представляющими самые разные профессиональные и общественные группы. Пара-тройка миллионов деталей изготавливается и собирается в одно изделие — и самолёт летит, обеспечивая комфорт пассажирам и прибыль владельцам!

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

Раньше люди боролись со сложностью тем, что инженерными проектами занимались гении. Сейчас на гениальность не надеются: проекты должны получаться независимо от гениальности “генерального конструктора”, проекты должы получаться успешными на основе метода — гениальность при этом позволяет дополнительно поднимать планку сложности, уже высоко поднятую использованием системноинженерного мышления и практик системной инженерии.

Кто ответственен за правильность проекта, правильность выбранного решения, соблюдение всех сложнейших практик, дающих на выходе “правильно с первого раза”? Системные инженеры: именно они должны придумать такие технические решения, чтобы не было неприятных (впрочем, и приятных тоже) неожиданностей при изготовлении, эксплуатации и последующем выводе из эксплуатации систем, создаваемых во всех этих сложнейших проектах. И эти системные инженеры справляются — каждый год сверхсложные проекты прошлых лет становятся просто сложными, а сложные проекты — типовыми. Это не значит, что такие проекты, как полёт на луну или создание атомной станции становятся более простыми. Нет, не становятся: наоборот. Сложность этих проектов год от года растёт за счёт опережающего роста требований, прежде всего требований безопасности.

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

Но почему системную инженерию назвали именно системной, а не какой-то другой инженерией? Потому как на сегодняшний день единственным способом удержать сверхсложное целое в междисциплинарных проектах является использование системного подхода, в котором термин “система” используется в специальном смысле, и который подразумевает специальное устройство мышления для применяющих системный подход людей. Этому мышлению и посвящена наша книга.

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

Вложенные файлы: 1 файл

21.docx

Системная инженерия (systems engineering) — это процесс определения, проектирования, реализации, тестирования, внедрения и поддержания систем в целом. Системным инженерам по долгу службы приходится сталкиваться с ПО, аппаратурой и взаимодействием системы с пользователями и собственным окружением.

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

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

Системы зачастую иерархичны и включают в себя другие подсистемы. Например, полицейская система может включать в себя геоинформационную систему (ГИС) для определения места происшествий. Характерной особенностью подсистем является то, что они могут выступать как самостоятельные системы, хотя их поведение может зависеть и от других подсистем.

Примеры производных свойств:

надежность системы (зависит от надежности компонент системы и связей между компонентами),
удобство использования системы (помимо ПО и аппаратуры, зависит также от операторов системы и от окружения).

Для системных программистов необходимо какое-то знание вопросов CBSE, так как ПО приобретает все большее и большее значение в реальных системах. Например, в американском проекте Apollo 1969 года потребовалось всего 10 мегабайт кода для того, чтобы поддержать аппаратуру при полете на Луну. Сегодня же программное обеспечение американского орбитального комплекса составляет 100 мегабайт. Поэтому системное программирование становится критичным для успеха всей системы.

Что дает системная инженерия

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

Это достигается через

А) введение общего языка, описывающего проект

Б) сознательный сдвиг усилий на ранние стадии проекта, где цена ошибки экспоненциально меньше

Стадия обнаружения ошибки

Коэффициент стоимости ошибки

x1 (единица отсчета)

Междисциплинарный подход к проблеме успешного создания систем и средство для её решения.

Фокусируется (при постоянном внимании к охвату проблемы во всей полноте):

- на определении нужд пользователей и требуемой функциональности на ранних стадиях цикла разработки,

- на документирования требований,

- на синтезе дизайна системы,

- на подтверждении соблюдения пользовательских требований

Описывает процесс разработки систем и как бизнес-процесс, и как технический процесс

Охватывает стадии жизни систем от появления замысла до вывода из эксплуатации

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

Внедряет в практику организации ряд ключевых идей системной инженерии:

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

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

Она применима к любым рукотворным системам любой области человеческой деятельности (включая организации, сервисы, сами системы стандартизации).

Охватывает полный цикл жизни (например: замысел, разработка, производство, использование, поддержка и вывод из эксплуатации).

Учитывает необходимость контрактации (приобретения и поставки продуктов и услуг).

Включает в процессы людей, оборудование, компьютеры, софт (ссылается на связанный стандарт ISO 12207 – жизненный цикл софта).

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

Учитывает особенности композиции любых систем – встроенных, автономных, интегрированных и любых других, сложных и простых.

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

Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Полный жизненный цикл информационной системы включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае жизненный цикл можно в свою очередь разбить на ряд стадий. В принципе, это деление на стадии достаточно произвольно. Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational Software – одной из ведущих фирм на рынке программного обеспечения средств разработки информационных систем (среди которых большой популярностью заслуженно пользуется универсальное CASE-средство Rational Rose).

Стадии жизненного цикла:

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

На стадии уточнения проводится анализ прикладной области, разрабатывается архитектурная основа информационной системы.

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

В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных факторов риска в проекте.

3) Стадия конструирования

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

4) Стадия передачи в эксплуатацию

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

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

Стандарты жизненного цикла :

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

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission )1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Выдержки из оригинала показаны цитатами, из других источников – курсивом. Плюс рассуждения вокруг системотехники.

Немного про SE

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

При том, что Советская школа системной инженерии \ системотехники не уступала на тот момент западной.

Сомневаюсь, что советские аналогичные проекты не использовали такие же SE-подходы.

Причем, что очень важно – этот подход стоит, прежде всего, на страже интересов потребителя разработки (заказчика), а не консалтера или разработчика. Во всяком случае, так изначально задумывалось.

1. Начало

Они демонстрируют узость взглядов в своей работе и редко, если вообще когда-либо, связывают её с более общими целями системы.

Такая узость взглядов является основной характеристикой бюрократа.

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

Собственно это механизм перехода от крупного масштаба рассмотрения к мелкому и обратно.

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

Обязательства в каждом случае были: (1) непосредственный вклад, (2) вклад в долгосрочной перспективе и (3) очень долгосрочный вклад. Также я понял, что под пунктами (2) и (3) одна из моих функций в исследовательском отделе была не столько решением существующих проблем, сколько разработкой методов решения проблем, расширением диапазона возможностей и обучением других тому, что мне удалось обнаружить, чтобы они смогли в дальнейшем применить, продолжить и улучшить результаты моих усилий.

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

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

Тем не менее, позже я понял, что мне стоит обращать внимание не только на нужды Исследовательского Отдела, но и на все потребности Лабораторий.

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

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

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

Это все — к вопросам: стандартизация, унификация, типизация, свободный обмен лучшими практиками. Отечественная SE – это ГОСТы серий 34.ххх и многие из 15.ххх и 2.ххх.

Обязательность их исполнения осталась в прошлом, но это обеспечило на то время мощный потенциал, прежде всего, при производстве военных систем (ГОСТ РВ 15.ххх и 2.ххх.).
Максимум, что сейчас делается – это переводы зарубежных ГОСТов.

Собственные (отечественные) методологические разработки в этих областях – нулевые.
Зачем нам это сегодня? Хотя, когда-то наша страна была пионером в этих отраслях, как минимум, в подходах к стандартизации и унификации к проектированию сложных систем.

Правильно – не нужно нам это, т.к. у нас:

Я убежден, что ЕА и ВРМ и SE могут быть также представлены и досконально формализованы как подходы к кодированию информации. И эти направления когда-нибудь станут настоящими научными и инженерными дисциплинами.

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

Первое правило системной инженерии

Проблема с заземлением дифференциального анализатора – как то не совсем мне очевидна. Это скорее технический дефект.

Я бы привел другой пример, не особо показательный, но в ином направлении: помним старую игрушку — Диггер. Играли – играли, все было хорошо.

Не совсем понял критику. Вообще основная цель процесса обучения – это тренировка. Тренировка и развитие памяти человека (наращивание его ОЗУ), мыслительного процесса (вычислительная мощность CPU и DSP мозга). Примеры онтологий, понятийных аппаратов. Это просто позволит аналогию для практических задач. Задачи разные – подходы к решению одинаковые (общесистемные).

В итоге, если смотреть в целом, в обучении Математике появились большие пробелы. Мы практически не затрагиваем (1) важный метод Математической индукции, (2) после краткого упоминания в связи с квадратичными уравнениями в алгебре мы практически полностью игнорируем любое упоминание комплексных чисел до того рокового дня, когда появляются сложные собственные значения и собственные функции, и бедный студент знакомится с двумя новыми сложными концепциями одновременно и, естественно, это сбивает его с толку, (3) вкратце упоминается полезный метод неопределенных коэффициентов, (4) практически полностью игнорируются доказательства невозможности, (5) игнорируется дискретная математика, (6) не прилагаются усилия к тому, чтобы вывести размышления студентов из обучающих примеров к значимым концепциям, применимым в реальном мире.

Как раз поэтому:

… многие люди знают, что сказать, но не многие могут фактически применить это на практике, когда придет время действовать в реальном мире. Большинство из вас не может!

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

Второе правило

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

Как я писал ранее, период полураспада подходов к проектированию составляет 15 лет — половина идей, которые вы узнаете сейчас, будут бесполезны через 15 лет.

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

Кстати, тогда же я сравнивал стадии проектирования в ГОСТах на АСУ (24.ххх, 34.ххх) и в строительных (21.ххх) и других (ЕСКД-ЕСПД), стадии в методологии АРИС и еще в чем-то (не помню уже). И все сводилось к одному:

1) предпроект (аванпроект, концепция и т.п.)
2) эскизный проект, технический проект, рабочий проект
3) испытания, приемка, внедрение

В разных методологиях – разные термины, но суть на удивление – одинакова (классический каскад), в том числе и внутри указанных стадий. Причем независимо от масштабов: строим радиостанцию, танк, здание, АСУ, предприятие.

Третье правило

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

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

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

Я уже упоминал об этом, но позвольте заметить еще раз: решение, которое не дает более глубокого понимания — плохое решение, но, возможно, что это всё, что возможно сделать в текущем временном ограничении. Целью системной инженерии должно быть более глубокое и долгосрочное понимание сущности проблемы, в то время как клиент всегда хочет увидеть оперативное избавление от текущих симптомов. Опять же, конфликт, ведущий к мета-системной инженерии!

Видимо – это несбыточная мечта или порог, после которого последует SkyNet.

Как пример углубленного понимания системы и её проблем, я хочу рассмотреть проект управляемых ракет Nike.

Что такое SE

Заключение

Основной мотив SE и вообще автоматизации

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

Методики SE нацелены на минимизацию последнего, причем как в процессе проектирования системы (т.е. проектирование по шаблону, фреймворку), так в процессе сопровождения системы (также по шаблону, регламенту).

На сегодня SE не позволяет полноценного проектированная ни в области ЕА (проектирование предприятия или его АСУ), ни проектирования процессов (BPM). Можно конечно сказать, что это не является задачей SE, но это лишь отговорка.

Тем не менее, стандарты SE более понятны, чем ЕА и BPM, и более полезны, но насколько я понимаю, с каждым годом происходит сокращение проектов, реализуемых по ним. Во всяком случае, (по субъективным ощущениям и публикациям) 20 лет назад их было больше, чем 10 лет назад, а сегодня их меньшее, чем 10 лет назад.

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

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

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

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

Применение принципов системной инженерии к разработке программной системы выявляет операции, задачи и процедуры, называемые системной инженерией программного обеспечения: (software system engineering — SwSE). Многие считают SwSE специфичным случаем системной инженерии, а другие относят ее к программной инженерии. Однако я могу утверждать, что SwSE — совсем иной мощный инструментарий, используемый для управления технической разработкой крупных программных проектов.

В этой статье определения и процессы из стандартов IEEE на программную инженерию [2] интегрируются в процесс SwSE. Более подробное изложение этого материала, включая детальное пошаговое описание развертывания SwSE, содержится в [3].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции SwSE

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

Таблица 1. Функции системной инженерии, коррелирующие с системной инженерией ПО

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

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

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

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

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

Дизайн программного обеспечения

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

Дизайн программного обеспечения традиционно разделяется на две части.

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

Предложенная в статье методология архитектурный дизайн относит к SwSE, а детальный дизайн — к SwE.

Планирование процессов

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

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

В таблице 2 показан пример разделения функций планирования для проекта программной системы.

Таблица 2. Планирование процессов и планирование проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

4. IEEE Std. 1220-1998, Standard for Application and Management of the System Engineering Process, 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

В статье автор рассматривает сущность и понятия системной инженерии.

Ключевые слова: системная инженерия, стандарт, ISO, оптимизация.

1) Многогранность системной инженерии;

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

3) Системная инженерия должна использовать передовые техники исследования потребностей окружающей и внутренней среды.

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

Автор

Определение

Л. фон Берталанфи

Научная, учебная и профессиональная дисциплина, главная задача которой состоит в обеспечении того, чтобы все требования, предъявляемые к био/аппаратной/программной системе, были удовлетворены на протяжении полного жизненного цикла этой системы [2].

На текущий момент системная инженерия является самостоятельной дисциплиной, в которую входят такие направления, как:

1) Системный анализ;

2) Программная инженерия;

3) Системное планирование и т. д.

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

В основе системной инженерии лежит жизненный цикл системы. Жизненный цикл — совокупность этапов, либо последовательные элементы процесса, которые начинаются появления потребности в создании системы и заканчиваются полным выводом из эксплуатации [3]. На всем этапе жизненного цикла применяются различные инструменты анализа, проектирования, прогнозирования и т.д. (рис 1).

Рис.1. Инструменты системного инжиниринга в разрезе жизненного цикла

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

1) Спроектированные системы не взаимодействуют между собой;

2) Подсистемы не создают единую систему;

3) Разработанные системы н функционируют, как ожидалось и порождают потери, увеличенные трудозатраты и перерасход бюджета.

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

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

Розин, В. М. Эволюция инженерной и проектной деятельности и мысли: Инженерия: становление, развитие, типология / В. М. Розин. — М.: Ленанд, 2016. — 200 c.
Гумеров, А., М. Инженерия знаний. Модели и методы: Учебное пособие / А. М. Гумеров. — СПб.: Лань, 2016. — 324 c.
Чошанов, М. А. Инженерия обучающих технологий / М. А. Чошанов. — М.: Бином, 2015. — 239 c.

Основные термины (генерируются автоматически): системная инженерия, жизненный цикл, система, ISO, автор, построение системы, самостоятельная дисциплина, стандарт, фокус внимания.

Читайте также: