Ставрополь - 2015 - МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ
ФЕДЕРАЦИИ
Федеральное государственное автономное
образовательное учреждение высшего профессионального

образования
«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
Дроздова В.И., Романенко М.Г.
УЧЕБНОЕ ПОСОБИЕ (КУРС ЛЕКЦИЙ)
«СИСТЕМНАЯ ИНЖЕНЕРИЯ»
Направление подготовки: 09.04.02 «Информационные системы и

технологии»
Магистерская программа: Управление данными;
Квалификация выпускника: Магистр
Ставрополь
Печатается по решению
Учебно-методического совета
Северо-Кавказского федерального
университета
УДК
ББК
Рецензенты:
Линец Г.И. доктор технических наук, заведующий кафедрой

инфокоммуникаций института информационных систем и
телекоммуникаций Северо-Кавказского федерального университета
Панкратова О.П. кандидат педагогических наук, доцент кафедры
информатики Северо-Кавказского федерального университета
Дроздова В.И.., Романенко М.Г. Системная инженерия: учебное

пособие (курс лекций). – Ставрополь: Изд-во СКФУ, 2015. – 121 с.
Учебное пособие по дисциплине «Системная инженерия» составлено в

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

отражает основные понятия системной инженерии и жизненного цикла
программного обеспечения, методологии, применяемые в системной
инженерии, стандарты, используемые при создании программного
обеспечения и реинжиниринг бизнес-процессов.
УДК
ББК
© ФГАОУ ВПО «Северо-Кавказский
федеральный университет», 2015
СОДЕРЖАНИЕ
РАЗДЕЛ 1. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМНОЙ ИНЖЕНЕРИИ
Тема 1. Основы системной инженерии
План лекции
1.1Определение системной инженерии.
1.2Проблемы современной инженерии

1.3Универсальность системной инженерии
Проблемы современной инженерии
Сложность современных проектов: до 10 млн. деталей (нефтяная

платформа), проект существует до 100 лет;
До 1000 контракторов на один проект, у каждого контрактора свой

язык;
Мультидисциплинарность;
Требования и спецификации проекта приходят с самых разных сторон

и непрерывно меняются;
Каждый проект стал «вавилонской башней».
Что дает системная инженерия
По данным INCOSE:
8% затрат на внедрение системной инженерии дают выигрыш в 20%

стоимости проектов, и на 50% увеличивают вероятность окончания
проекта в срок. Это достигается через введение общего языка,
описывающего проект, сознательный сдвиг усилий на ранние стадии
проекта, где цена ошибки экспоненциально меньше.
Стадия обнаружения ошибки Коэффициент стоимости ошибки
Требования x1 (единица отсчета)
Проектирование x5
Строительство x12
Проверки x40
Функционирование x250
Новизна
Интеграция разных идей в одной организационной системе на уровне

международного стандарта;
Использование этих идей в организации можно обсуждать и проверять.
Универсальность системной инженерии

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

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

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

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

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

частей системы
Учитывает особенности композиции любых систем – встроенных,

автономных, интегрированных и любых других, сложных и простых
Происхождение
Совместная разработка ISO и IEC, активное участие INCOSE;
Начало работ в 1996, версии в 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-

2005), 2008;
Призван гармонизировать так называемое «болото стандартов»

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

организованных для достижения одной или более провозглашенных
целей (предоставления продукта или услуги)
Зафиксированный вариант (Baseline) – вариант спецификации или

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

оборудования, для которых определены ответственность, полномочия и
взаимоотношения (адаптировано из ISO 9000:2005). Часть
организации (даже один человек) или группа организаций – тоже
организация, если в ней есть ответственность, полномочия и
отношения
Процесс – набор взаимосвязанных или взаимодействующих действий,
преобразующих входы в выходы (из ISO 9000:2005). Процессы состоят
из действий (activities), а действия – из задач (tasks)
Продукт – результат процесса (ISO 9000:2005)
Проект – мероприятие с определенными критериями начала и

окончания, предназначенное для создания продукта или услуги с
учётом определённых ресурсов и требований (адаптировано из ISO
9000:2005). Может быть рассмотрен как уникальный экземпляр
процесса, состоящий из скоординированных и управляемых действий,
и может включать действия из Проектных процессов и Технических
процессов, определенных в ISO 15288
Приёмка (Validation) – подтверждение, что система удовлетворяет

пользовательским требованиям.
Проверка (Verification) – подтверждение, что специфицированные к

системе требования выполняются.
Обеспечивающая система (Enabling system) – система,

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

системной инженерии
Вопросы для самопроверки
1. Дайте определение системной инженерии.
2. Перечислите проблемы современной инженерии.
3.Дайте определение основным терминам, использующимся в

системной инженерии.
РАЗДЕЛ 2. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Тема 2. Жизненный цикл и этапы разработки программного

обеспечения

2.1. Подход жизненного цикла
2.2. Этапы жизненного цикла программного обеспечения
2.2.1 Постановка задачи
2.2.2 Анализ требований и определение спецификаций
2.2.3 Проектирование
2.2.4 Реализация
2.2.5 Сопровождение
Подход жизненного цикла
Жизненный цикл (ЖЦ) системы представляет собой эволюцию

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

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

цикла. Это подходы, не акцентирующие внимания на единстве системы
во времени, то есть не рассматривающие систему как единый 4D
(«четырехмерный», пространство 3D+время) объект. Для таких
подходов характерно отдельное рассмотрение множества целевых
систем – проект, строительная площадка, готовый объект,
реконструкция, ремонт. Решения по поводу этих систем принимаются
без учета их дальних последствий. Типовые ошибки, допускаемые при
таких подходах: при подготовке описания проекта принимают во
внимание функционирование объекта, но забывают о потребностях,
как стройки, так и отдаленной во времени реконструкции; или во
время стройки считают возможным допускать отклонения от описания
проекта без внесения в него изменений.
В рамках подхода жизненного цикла вводится понятие стадии

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

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

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

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

приводит к необходимости при описании жизненного цикла и его
составляющих описывать процессы, протекающие в системе. Процесс
«управление жизненным циклом» состоит из подпроцессов,
соответствующих различным стадиям жизненного цикла. Переход от
одной стадии к другой приводит к постадийной эволюции системы.
Стандарт ISO/IEC 15288:2008 «Systems and software engineering 

System life cycle processes» задает в рамках объединения процессного
подхода и подхода жизненного цикла набор конкретных опорных
описаний отдельных процессов, применяемых к целевой системе при
ее продвижении по стадиям жизненного цикла. Стандарт ISO/IEC
15288:2008 – процессный стандарт жизненного цикла, включающий:
1. Конкретный процессный подход жизненного цикла,

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

нотаций описания).
2. Опорные описания групп процессов жизненного цикла,

организованных как:
- процесс «Управление жизненным циклом системы X», состоящий из

- процессов «Управление Стадией N жизненного цикла системы X».
- процесс «Управление Стадией N жизненного цикла системы X»,

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

например, служить стандарт МАГАТЭ IAEA-TECDOC-1305. Этот
процессный стандарт содержит указание на другие методы описания
процессов, свой конкретный набор стадий жизненного цикла АЭС и
иной набор архитектурных описаний процессов ЖЦ.
Для интеграции требований разных стандартов управления жизненным

циклом, предписывающих различные группы описаний процессов
жизненного цикла, может быть применена конструкция тематической
группы описаний архитектурного подхода ISO 42010, как это описано в
Приложении D ISO 15288:2008 на примере специальных свойств. Для
доказательства того, что система обладает определенным набором
специальных свойств (безопасности, ремонтопригодности, качества и
т.п.) из описаний процессов базового подхода (например, подхода ISO
15288:2008) делаются специальные выписки практик и результатов,
адресующие те специальные интересы стейкхолдеров, для которых и
были разработаны соответствующие отраслевые стандарты (например,
IAEA-TECDOC-1305 в случае АЭС). Стейкхолдер (Stakeholder) – это
заинтересованная сторона. Это лицо или организация, имеющие права,
долю, требования или интересы к системе или использованию ее
свойств. Эти группы выписок являются не самостоятельными
описаниями процессов, а процессными выписками – выборками
(возможно, расширенными) тех частей основных описаний процессов,
которые адресуют специальные интересы, т.е. обеспечивают
достижение нужных специальных характеристик. Реализуемость такого
подхода к проблемам безопасности или качества может быть
обоснована тем, что обеспечение качества или безопасности не только
являются предметом отдельных процессов, но и определяются
обязательными практиками при осуществлении всех процессов
жизненного цикла системы.
Нужно также добавить, что процессы, как любые системы, сами

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

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

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

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

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

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

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

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

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

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

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

- совершенствование версий программного продукта, расширение его

функциональности;
- адаптация программного продукта под новое программное

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

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

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

обеспечения.
2. Рассмотрены этапы жизненного цикла программного обеспечение.

1. Дайте определение жизненного цикла.
2. Расскажите о подходе жизненного цикла.
3.Охарактеризуйте этапы жизненного цикла программного

3.1. Системный подход
3.1.1 Подход
3.1.2 Онтология
3.1.3 Стейкхолдер
3.1.4 Система
3.2 Архитектурный подход
3.3 Деятельностные подходы
3.4 Процессный подход
3.5 Четыре группы процессов
Подход системной инженерии к управлению жизненным циклом систем

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

введены основные термины, необходимые для их применения.
Далее мы дадим значительно более точное определение термина

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

мире системы, их границы, назначение, элементы, их связи,
стейкхолдеров, их интересы и т.д., и описывать мир с использованием
именно этих терминов.
Подход
1. Framework – как термин нигде не определяется, является омонимом,

то есть имеет множество значений в словарном гнезде.
2. Определение:
This International Standard establishes a common process framework for

describing the life cycle of man-made systems (ISO 15288).
ISO/IEC 15288 defines a generic, top-level framework based upon a set of

processes that can be combined into various suitable life cycle models.
Нормативная клауза архитектурных описаний ISO 42010 представляет

собой conceptual framework (or frame of reference), that establishes
terms and concepts pertaining to the content and use of (architectural)
description.
ISO/IEC TR 15543 -- A framework for IT security assurance.
3. Русский: «подход» понимается как набор (в том числе

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

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

используется слово approach, а когда подход оформляется в виде
конкретного описания, то он чаще называется framework.
4. Формально: подход – это набор методов описания систем и правил
их применения, используемый для формирования описаний систем и
установления деятельностных (процессных) норм.
5. Комментарий: можно считать, что «междисциплинарность»,

входящая в определение системной инженерии (INCOSE: Systems
Engineering is an interdisciplinary approach and means to enable the
realization of successful systems) – это гармонизация множества
подходов – системного, процессного, архитектурного и ряда других.
Framework в сочетании «reference framework» переводится как

стандарт, то есть описание подхода, используемое в качестве
проверяемой нормы.
Онтология
1. Ontology, data model. Используется в методах интеграции данных

(стандарты ISO 15926, ISO 18876, ISO 18629, Gellish и т.д.).
Сonceptual data model -- data model in the three schema architecture

defined by ISO/TR 9007, in which the structure of data is represented in a
form independent of any physical storage or external presentation format.
NOTE Adapted from the IDEF1X specification. (ISO 15926 3.1.3)
В описании языка Gellish уточняется:
Such a model has different names in different disciplines and different

conventions are used in those disciplines to document such a model:
- In philosophy such a model is called an ontology that tries to describe in

general terms the structure of reality and imagination or a part of it. An
ontology is generally documented as a collection of propositions expressed
in a natural or artificial language.
- In information technology such a model is called a data model or schema

that describes the structure of 'data' about a part of the reality or
processes in it. Such a 'data structure' is a collection of relationships
between 'objects'. A data model is generally documented in an artificial
language. To support understanding it is often also documented in a
graphical schema that shows the objects and their relationships. Data
models in information technology can be used to model nearly anything, so
they include models of any kind of object and its behaviour, including also
models of business processes.
- In linguistics such a model is called (the definition of) an artificial

language, with as aspects a grammar and a vocabulary with its semantics.
The definition of the structure of such an artificial language has an
'ontological commitment', which means that the language definition is such
that it enables the expression of meaningful propositions about the
structure of reality and imagination.
3. Русский: онтология. Мы выбираем наиболее общее (философское)

наименование, поскольку даже в сфере IT все больше используется
слово ontology (в том числе среди разработчиков ISO 15926 в
последние годы модель данных ISO 15926-2 все чаще называют
онтологией, а не моделью данных). Нужно также учесть, что слово
«онтология» используется не только в сфере IT, но и в методологии –
когда речь идет о создании и сравнении различных методов описания
систем или деятельности.
4. Формально: онтология – это набор концептов и отношений между

ними. Данное определение следует парадигме Bunge-Wand-Weber, в
которой весь мир состоит из объектов и отношений, эта парадигма на
сегодняшний день общепринята в информационных технологиях.
5. Комментарий: онтологии в системной инженерии используются для

двух целей:
- Интеграция различных описаний (как в случае правил соответствия

методов описания - viewpoint correspondence rule, так и в случае
интеграции данных информационных моделей в варианте ISO 15926
или Gellish).
- Обсуждений адекватности методов описаний интересам

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

подходе.
Stakeholder – individual or organization having a right, share, claim, or

interest in a system or in its possession of characteristics that meet their
needs and expectations (ISO 15288 4.29).
System stakeholder: An individual, team, or organization (or classes

thereof) with interests in, or concerns relative to, a system (ISO 42010
3.8).
3. Русский: стейкхолдер. Перевод «заинтересованное лицо» создает
дополнительную омонимию с юридическим термином гражданского
кодекса «заинтересованное лицо», а также аналогичным термином из
корпоративного управления. Слово «стейкхолдер» уже закрепилось в
русском языке, Яндекс находит его на 19 тыс. страниц.
4. Формально: стейкхолдер – это роль, в которой могут быть человек

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

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

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

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

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

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

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

выделяем во внешнем мире иные системы, с которыми взаимодействует
интересующая нас система. Чтобы отличать ту систему, которая нас
интересует, от иных систем, мы будем иногда называть интересующую
нас систему целевой системой. Роли систем во внешнем мире тоже
могут быть уточнены: обеспечивающая система, система в
операционном окружении.
Говоря о системе, необходимо всегда указывать ту конкретную
систему, которая имеется в виду в данный момент. Просто слово
система стоит использовать только в общетеоретических текстах.
Самым предпочтительным вариантом является использование названия
системы, определяющее её границы и назначение: АЭС, ГЭС, самолёт,
информационная модель, процесс. Если это невозможно, следует
добавлять разъяснения, позволяющие определить границы или
элементы системы: «компьютерная система – это комплект
оборудования и установленное на нём программное обеспечение…».
Ещё два важных для дальнейшего рассмотрения понятия, связанные с

понятием системы – интерес и стейкхолдер.
Для любой системы можно выявить множество интересов к разным

аспектам её функционирования или устройства. Это могут быть
интересы к продуктам и результатам, предоставляемым системой. При
этом продукты и результаты бывают как прямые (например,
вырабатываемая ГЭС электроэнергия), так и косвенные (например,
потенциальная угроза для жизни и здоровья, которой является АЭС).
Среди интересов может быть интерес к деньгам, которые система
приносит – интерес собственника к его предприятию, или интерес
налоговой инспекции к налогоплательщику. Интересы могут быть к
составным частям системы – интерес начальника цеха к станкам в его
сфере ответственности, или интерес конструктора к чертежам
порученного ему узла.
Условное лицо, роль которого по отношению к системе определяется

его интересами, мы будем называть стейкхолдером (иногда также
говорят «заинтересованное лицо»).
Введённые понятия система (system), целевая система (system of

interest), обеспечивающая система (enabling system), система в
операционном окружении (system in operational environment), интерес
(concern), стейкхолдер (stakeholder) соответствуют основным
понятиям, введённым международным стандартом процессов
жизненного цикла ISO/IEC 15288:2008 Systems and software
engineering - System life cycle processes.
Архитектурный подход
Теоретически, человек может начать создавать требуемую ему систему

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

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

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

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

была (или будет) порождена о системе. В описание АЭС входят и
строительные чертежи в недрах какого-нибудь архива, и самая свежая
информация, отображённая на её пульте управления, и многолетний
архив данных о режимах АЭС, хранящийся в СО ЕЭС, и расчёт цен на
завтра в её узле поставки, выполненный в АТС. Наличие связей с
целевой системой и единообразное использование накопленных в
разных местах данных позволяют считать эту слабосвязанную
совокупность информации одной системой – описанием целевой. Как
показывает этот пример, описание системы в полном виде может быть
недоступно какому-то одному лицу, и извлечение из описания данных
о системе бывает чрезвычайно трудоёмко. Часто проще бывает
обратиться к самой системе и получить данные непосредственно
(например, лазерной съёмкой уже построенной электростанции в 3D),
а не из описания (чертежа).
Большинство описаний систем начинаются своё существование как

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

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

использовать наилучшие, самые актуальные и удобные. На сегодня
«наилучшими» можно считать те описания, для которых обеспечены
датацентричность и учётность. Именно такие описания мы будем
называть информационными моделями.
Информационная модель – датацентрическое описание системы,

являющееся в то же время единой учётной системой.
При рассмотрении и описании системы можно пользоваться разными

методами.
В рамках каждого метода в системе рассматриваются свои собственные

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

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

междисциплинарный подход к проблеме создания успешно
функционирующих систем и средства для её решения.
Фокусируется (при постоянном внимании к охвату проблемы во всей

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

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

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

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

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

Сейчас в мире ежегодно издаются десятки книг и журналов по
системной инженерии. Ежегодно проводятся многочисленные
международные конференции по системной инженерии. Ведущие
интеграторы: Institute of Electrical and Electronics Engineers (IEEE) и
International Council on Systems Engineering (INCOSE).
Достижения системной инженерии в практике проектов используют

ведущие мировые организации и компании, занятые заказом,
сопровождением и созданием систем, среди них:US Department of
Defense, US Federal Aviation Administration (FAA), National Aeronautics
and Space Administration (NASA), ITRE Corporation, Boeing.
Отечественная практика системной инженерии характеризуется тем,

что:
- в основе современной отечественной практики лежит создание

систем обеспечения основного производства или оказания услуг;
- среди руководителей компаний распространено мнение, что для

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

методологические вопросы создания систем практически не
рассматриваются;
- среди технических вопросов основное внимание уделяется

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

технические университеты мира имеют в своих программах блок
дисциплин, посвященных изучению методологии и практики системной
инженерии, и успешно реализуется множество программ повышения
квалификации и переподготовки кадров в области системной
инженерии. Курс «Системная инженерия» включен сегодня в
программы подготовки магистров направления 230400. Отечественные
методические материалы по системной инженерии можно найти в
Internet, но методологические основы программной инженерии в нашей
стране издавались, например, книга: Батоврин В.К. Системная и
программная инженерия. Словарь-справочник. ДМК, Москва, 2009
допущена в качестве учебного пособия для студентов направления
«Информационные системы».
Нормативное обеспечение системной инженерии – это совокупность

нормативных актов разного уровня.
Цели нормирования:
- Безопасность (техническое регулирование)
- Управленческие «хорошие практики» («управления» качеством,

проектами и т.д.)
- Технические решения (стандартизация)
Нормирующие органы:
- Международные организации (например: ВОЗ, МАГАТЭ, ИКАО)

- Государство (законы и постановления Правительства РФ и
государств-клиентов)
- Организации стандартизации (стандарты ISO, W3C, IETF,

Росстандарт)
- Ведомственные регуляторы (министерства, агентства)
- Отраслевые и корпоративные регуляторы (холдинги и

госкорпорации)
- Предприятия (ДЗО холдингов).
Все три типа норм взаимосвязаны. Например, техрегулирование

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

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

гетерархической распределенной системой нормирования, в которой
одни и те же эксперты заседают в разных нормирующих организациях
и тем самым обеспечивают содержательное единство нормативного
обеспечения. Система нормирования работает в терминах
содержательных норм, а не нормативных актов. Каждая норма
воплощается пакетом нормативных актов разного уровня
(законопроектов, проектов Постановлений Правительства, проектов
ФНП, проектов стандартов и т.д. – в том числе проекты изменений
действующих актов).
Организационно система нормирования включает два типа институтов:
- Содержательные, разрабатывающие («инженерно») пакет проектов

нормативных актов разного административного уровня;
- Административные, утверждающие («политически») относящиеся к

ним проекты нормативных актов.
Содержательные институты нормирования требуют:
- Правил (Процесса) коллективной разработки (создания коллектива и

выделения ресурсов, правил работы и принятия решений);
- Администрирующей Правила (Процесс) организации (обычно –

Консорциум по стандартизации);
- Четкого указания полномочий по принятым решениям (например,
возможности по участию в процедурах fast track определенных
административных институтов).
Административные институты не содержат достаточного аппарата для

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

допускаемых для процедуры fast track
Содержательным процессом в стандартизации руководит Архитектор

(суть – содержательная разработка, а не политическое «достижение
компромисса»)
Обычно три стадии рассмотрения («чтения»):
- начальное (после внесения – нужен ли такой стандарт, можно ли

взять за основу предложенный текст);
- Рабочее (утвердить результаты разработки, обязателен пример

реализации/макет);
- Публичное (приняты замечания широкой публики, должны быть

примеры коммерческой реализации).
Термины:
Нормативное обеспечение – система нормативных актов разного

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

административные) нормировочных институтов, оформляющие
совокупность содержательных норм в виде административных
нормативных актов.
Fast track – особая процедура ускоренного принятия нормативных

актов, если их разработка была выполнена признанным
(аккредитованным) нормировочным институтом.
«Карта» нормативного обеспечения (классификация) нужна прежде

всего для организации деятельности по нормированию. Предлагается
проблемно-ориентированная организация:
учет шаблонов планирования работ («делай что пишешь, пиши что

делаешь») и оргмоделирование [пример: ISO 9000] 4D (3D+жизненный
цикл) цифровые модели и «учет вообще», ISO 15926.
Стандарт ISO/IEC 15288 «Системная инженерия – процессы

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

платформа), проект существует до 100 лет;
До 1000 контракторов на один проект, у каждого контрактора свой

язык;
Мультидисциплинарность;
Требования и спецификации проекта приходят с самых разных сторон

и непрерывно меняются;
Каждый проект стал «вавилонской башней».
Что дает системная инженерия
По данным INCOSE:
8% затрат на внедрение системной инженерии дают выигрыш в 20%

стоимости проектов, и на 50% увеличивают вероятность окончания
проекта в срок. Это достигается через введение общего языка,
описывающего проект, сознательный сдвиг усилий на ранние стадии
проекта, где цена ошибки экспоненциально меньше.
Стадия обнаружения ошибки Коэффициент стоимости ошибки
Требования x1 (единица отсчета)
Проектирование x5
Строительство x12
Проверки x40
Функционирование x250
Новизна
Интеграция разных идей в одной организационной системе на уровне

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

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

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

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

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

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

частей системы
Учитывает особенности композиции любых систем – встроенных,

автономных, интегрированных и любых других, сложных и простых
Происхождение
Совместная разработка ISO и IEC, активное участие INCOSE;
Начало работ в 1996, версии в 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-

2005), 2008;
Призван гармонизировать так называемое «болото стандартов»

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

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

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

преобразующих входы в выходы (из ISO 9000:2005). Процессы состоят
из действий (activities), а действия – из задач (tasks)
Продукт – результат процесса (ISO 9000:2005)
Проект – мероприятие с определенными критериями начала и

окончания, предназначенное для создания продукта или услуги с
учётом определённых ресурсов и требований (адаптировано из ISO
9000:2005). Может быть рассмотрен как уникальный экземпляр
процесса, состоящий из скоординированных и управляемых действий,
и может включать действия из Проектных процессов и Технических
процессов, определенных в ISO 15288
Приёмка (Validation) – подтверждение, что система удовлетворяет

пользовательским требованиям.
Проверка (Verification) – подтверждение, что специфицированные к

системе требования выполняются.
Обеспечивающая система (Enabling system) – система,

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

системной инженерии
1. Дайте определение системной инженерии.

2. Перечислите проблемы современной инженерии.
3.Дайте определение основным терминам, использующимся в

системной инженерии.
РАЗДЕЛ 2. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Тема 2. Жизненный цикл и этапы разработки программного

2.1. Подход жизненного цикла
2.2. Этапы жизненного цикла программного обеспечения
2.2.1 Постановка задачи
2.2.2 Анализ требований и определение спецификаций
2.2.3 Проектирование
2.2.4 Реализация
2.2.5 Сопровождение
Подход жизненного цикла
Жизненный цикл (ЖЦ) системы представляет собой эволюцию

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

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

цикла. Это подходы, не акцентирующие внимания на единстве системы
во времени, то есть не рассматривающие систему как единый 4D
(«четырехмерный», пространство 3D+время) объект. Для таких
подходов характерно отдельное рассмотрение множества целевых
систем – проект, строительная площадка, готовый объект,
реконструкция, ремонт. Решения по поводу этих систем принимаются
без учета их дальних последствий. Типовые ошибки, допускаемые при
таких подходах: при подготовке описания проекта принимают во
внимание функционирование объекта, но забывают о потребностях,
как стройки, так и отдаленной во времени реконструкции; или во
время стройки считают возможным допускать отклонения от описания
проекта без внесения в него изменений.
В рамках подхода жизненного цикла вводится понятие стадии

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

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

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

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

приводит к необходимости при описании жизненного цикла и его
составляющих описывать процессы, протекающие в системе. Процесс
«управление жизненным циклом» состоит из подпроцессов,
соответствующих различным стадиям жизненного цикла. Переход от
одной стадии к другой приводит к постадийной эволюции системы.
Стандарт ISO/IEC 15288:2008 «Systems and software engineering 

System life cycle processes» задает в рамках объединения процессного
подхода и подхода жизненного цикла набор конкретных опорных
описаний отдельных процессов, применяемых к целевой системе при
ее продвижении по стадиям жизненного цикла. Стандарт ISO/IEC
15288:2008 – процессный стандарт жизненного цикла, включающий:
1. Конкретный процессный подход жизненного цикла,

предписывающий:
- идентификацию систем и их окружения;

- идентификацию стейкхолдеров, их интересов;
- использование некоторых методов описания процессов (онтологий и

нотаций описания).
2. Опорные описания групп процессов жизненного цикла,

организованных как:
- процесс «Управление жизненным циклом системы X», состоящий из
- процессов «Управление Стадией N жизненного цикла системы X».
- процесс «Управление Стадией N жизненного цикла системы X»,

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

например, служить стандарт МАГАТЭ IAEA-TECDOC-1305. Этот
процессный стандарт содержит указание на другие методы описания
процессов, свой конкретный набор стадий жизненного цикла АЭС и
иной набор архитектурных описаний процессов ЖЦ.
Для интеграции требований разных стандартов управления жизненным

циклом, предписывающих различные группы описаний процессов
жизненного цикла, может быть применена конструкция тематической
группы описаний архитектурного подхода ISO 42010, как это описано в
Приложении D ISO 15288:2008 на примере специальных свойств. Для
доказательства того, что система обладает определенным набором
специальных свойств (безопасности, ремонтопригодности, качества и
т.п.) из описаний процессов базового подхода (например, подхода ISO
15288:2008) делаются специальные выписки практик и результатов,
адресующие те специальные интересы стейкхолдеров, для которых и
были разработаны соответствующие отраслевые стандарты (например,
IAEA-TECDOC-1305 в случае АЭС). Стейкхолдер (Stakeholder) – это
заинтересованная сторона. Это лицо или организация, имеющие права,
долю, требования или интересы к системе или использованию ее
свойств. Эти группы выписок являются не самостоятельными
описаниями процессов, а процессными выписками – выборками
(возможно, расширенными) тех частей основных описаний процессов,
которые адресуют специальные интересы, т.е. обеспечивают
достижение нужных специальных характеристик. Реализуемость такого
подхода к проблемам безопасности или качества может быть
обоснована тем, что обеспечение качества или безопасности не только
являются предметом отдельных процессов, но и определяются
обязательными практиками при осуществлении всех процессов
жизненного цикла системы.
Нужно также добавить, что процессы, как любые системы, сами

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

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

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

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

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

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

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

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

необходимое оборудование и программное обеспечение;
- произвести анализ требований к программному обеспечению;

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

передачи информации заказчику о соответствии программного
продукта требованиям;
- произвести установку программного обеспечения на оборудовании

заказчика и проверку его работоспособности;
- произвести приемку программного совместно с заказчиком,

окончательную передачу программного обеспечения заказчику.
Согласно ГОСТ 19.102-77 «Стадии разработки» вышеперечисленные

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

сопровождения (началу этого этапа соответствует стадия «Внедрение»
по ГОСТ). Однако по международному стандарту в соответствии с
изменениями, происшедшими в индустрии разработки программного
обеспечения, этот процесс теперь рассматривается отдельно.
Постановка задачи
Процесс постановки задачи является очень важным этапом в

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

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

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

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

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

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

- физическое проектирование, которое включает описание

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

процесс написания кода на выбранном языке программирования
(кодирование),а также его тестирование и отладка.

Сопровождение
Сопровождение - процесс, обеспечивающий качественное

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

- совершенствование версий программного продукта, расширение его

функциональности;
- адаптация программного продукта под новое программное

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

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

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

2. Рассмотрены этапы жизненного цикла программного обеспечение.
1. Дайте определение жизненного цикла.
2. Расскажите о подходе жизненного цикла.
3.Охарактеризуйте этапы жизненного цикла программного

Тема 3. Понятия подхода системной инженерии к управлению
жизненным циклом
3.1. Системный подход
3.1.1 Подход
3.1.2 Онтология
3.1.3 Стейкхолдер
3.1.4 Система
3.2 Архитектурный подход
3.3 Деятельностные подходы
3.4 Процессный подход
3.5 Четыре группы процессов
Подход системной инженерии к управлению жизненным циклом систем

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

введены основные термины, необходимые для их применения.
Далее мы дадим значительно более точное определение термина

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

Системный подход
Системный подход задаёт свою онтологию – предписывает видеть в

мире системы, их границы, назначение, элементы, их связи,
стейкхолдеров, их интересы и т.д., и описывать мир с использованием
именно этих терминов.
Подход
1. Framework – как термин нигде не определяется, является омонимом,

то есть имеет множество значений в словарном гнезде.
This International Standard establishes a common process framework for

describing the life cycle of man-made systems (ISO 15288).
ISO/IEC 15288 defines a generic, top-level framework based upon a set of

processes that can be combined into various suitable life cycle models.
Нормативная клауза архитектурных описаний ISO 42010 представляет

собой conceptual framework (or frame of reference), that establishes
terms and concepts pertaining to the content and use of (architectural)
description.
ISO/IEC TR 15543 -- A framework for IT security assurance.
3. Русский: «подход» понимается как набор (в том числе

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

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

используется слово approach, а когда подход оформляется в виде
конкретного описания, то он чаще называется framework.
4. Формально: подход – это набор методов описания систем и правил

их применения, используемый для формирования описаний систем и
установления деятельностных (процессных) норм.
5. Комментарий: можно считать, что «междисциплинарность»,

входящая в определение системной инженерии (INCOSE: Systems
Engineering is an interdisciplinary approach and means to enable the
realization of successful systems) – это гармонизация множества
подходов – системного, процессного, архитектурного и ряда других.
Framework в сочетании «reference framework» переводится как

стандарт, то есть описание подхода, используемое в качестве
проверяемой нормы.
Онтология
1. Ontology, data model. Используется в методах интеграции данных

(стандарты ISO 15926, ISO 18876, ISO 18629, Gellish и т.д.).
Сonceptual data model -- data model in the three schema architecture

defined by ISO/TR 9007, in which the structure of data is represented in a
form independent of any physical storage or external presentation format.
NOTE Adapted from the IDEF1X specification. (ISO 15926 3.1.3)
В описании языка Gellish уточняется:
Such a model has different names in different disciplines and different

conventions are used in those disciplines to document such a model:
- In philosophy such a model is called an ontology that tries to describe in

general terms the structure of reality and imagination or a part of it. An
ontology is generally documented as a collection of propositions expressed
in a natural or artificial language.
- In information technology such a model is called a data model or schema

that describes the structure of 'data' about a part of the reality or
processes in it. Such a 'data structure' is a collection of relationships
between 'objects'. A data model is generally documented in an artificial
language. To support understanding it is often also documented in a
graphical schema that shows the objects and their relationships. Data
models in information technology can be used to model nearly anything, so
they include models of any kind of object and its behaviour, including also
models of business processes.
- In linguistics such a model is called (the definition of) an artificial

language, with as aspects a grammar and a vocabulary with its semantics.
The definition of the structure of such an artificial language has an
'ontological commitment', which means that the language definition is such
that it enables the expression of meaningful propositions about the
structure of reality and imagination.
3. Русский: онтология. Мы выбираем наиболее общее (философское)

наименование, поскольку даже в сфере IT все больше используется
слово ontology (в том числе среди разработчиков ISO 15926 в
последние годы модель данных ISO 15926-2 все чаще называют
онтологией, а не моделью данных). Нужно также учесть, что слово
«онтология» используется не только в сфере IT, но и в методологии –
когда речь идет о создании и сравнении различных методов описания
систем или деятельности.
4. Формально: онтология – это набор концептов и отношений между

ними. Данное определение следует парадигме Bunge-Wand-Weber, в
которой весь мир состоит из объектов и отношений, эта парадигма на
сегодняшний день общепринята в информационных технологиях.
5. Комментарий: онтологии в системной инженерии используются для

двух целей:
- Интеграция различных описаний (как в случае правил соответствия

методов описания - viewpoint correspondence rule, так и в случае
интеграции данных информационных моделей в варианте ISO 15926
или Gellish).
- Обсуждений адекватности методов описаний интересам

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

подходе.
Stakeholder – individual or organization having a right, share, claim, or

interest in a system or in its possession of characteristics that meet their
needs and expectations (ISO 15288 4.29).
System stakeholder: An individual, team, or organization (or classes

thereof) with interests in, or concerns relative to, a system (ISO 42010
3.8).
3. Русский: стейкхолдер. Перевод «заинтересованное лицо» создает

дополнительную омонимию с юридическим термином гражданского
кодекса «заинтересованное лицо», а также аналогичным термином из
корпоративного управления. Слово «стейкхолдер» уже закрепилось в
русском языке, Яндекс находит его на 19 тыс. страниц.
4. Формально: стейкхолдер – это роль, в которой могут быть человек
или организация, состоящая в наличии интереса к системе, в том числе
к её функционированию или конструкции, назначению, продукту,
обладанию системой какими-либо характеристиками.
Предметом наших рассмотрений будут являться создаваемые людьми

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

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

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

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

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

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

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

систему, которая имеется в виду в данный момент. Просто слово
система стоит использовать только в общетеоретических текстах.
Самым предпочтительным вариантом является использование названия
системы, определяющее её границы и назначение: АЭС, ГЭС, самолёт,
информационная модель, процесс. Если это невозможно, следует
добавлять разъяснения, позволяющие определить границы или
элементы системы: «компьютерная система – это комплект
оборудования и установленное на нём программное обеспечение…».
Ещё два важных для дальнейшего рассмотрения понятия, связанные с

понятием системы – интерес и стейкхолдер.
Для любой системы можно выявить множество интересов к разным

аспектам её функционирования или устройства. Это могут быть
интересы к продуктам и результатам, предоставляемым системой. При
этом продукты и результаты бывают как прямые (например,
вырабатываемая ГЭС электроэнергия), так и косвенные (например,
потенциальная угроза для жизни и здоровья, которой является АЭС).
Среди интересов может быть интерес к деньгам, которые система
приносит – интерес собственника к его предприятию, или интерес
налоговой инспекции к налогоплательщику. Интересы могут быть к
составным частям системы – интерес начальника цеха к станкам в его
сфере ответственности, или интерес конструктора к чертежам
порученного ему узла.
Условное лицо, роль которого по отношению к системе определяется

его интересами, мы будем называть стейкхолдером (иногда также
говорят «заинтересованное лицо»).
Введённые понятия система (system), целевая система (system of

interest), обеспечивающая система (enabling system), система в
операционном окружении (system in operational environment), интерес
(concern), стейкхолдер (stakeholder) соответствуют основным
понятиям, введённым международным стандартом процессов
жизненного цикла ISO/IEC 15288:2008 Systems and software
engineering - System life cycle processes.
Архитектурный подход
Теоретически, человек может начать создавать требуемую ему систему

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

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

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

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

была (или будет) порождена о системе. В описание АЭС входят и
строительные чертежи в недрах какого-нибудь архива, и самая свежая
информация, отображённая на её пульте управления, и многолетний
архив данных о режимах АЭС, хранящийся в СО ЕЭС, и расчёт цен на
завтра в её узле поставки, выполненный в АТС. Наличие связей с
целевой системой и единообразное использование накопленных в
разных местах данных позволяют считать эту слабосвязанную
совокупность информации одной системой – описанием целевой. Как
показывает этот пример, описание системы в полном виде может быть
недоступно какому-то одному лицу, и извлечение из описания данных
о системе бывает чрезвычайно трудоёмко. Часто проще бывает
обратиться к самой системе и получить данные непосредственно
(например, лазерной съёмкой уже построенной электростанции в 3D),
а не из описания (чертежа).
Большинство описаний систем начинаются своё существование как

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

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

использовать наилучшие, самые актуальные и удобные. На сегодня
«наилучшими» можно считать те описания, для которых обеспечены
датацентричность и учётность. Именно такие описания мы будем
называть информационными моделями.
Информационная модель – датацентрическое описание системы,

являющееся в то же время единой учётной системой.
При рассмотрении и описании системы можно пользоваться разными

методами.
В рамках каждого метода в системе рассматриваются свои собственные

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

каждой предметной онтологии должна существовать специальная
нотация – совокупность графических изображений для концептов и их
отношений и правил использования этих изображений. Буквы и
цифры, используемые для построения означающих концепты слов,
также составляют нотацию. Именно такая нотация используется при
строго формализованной записи бухгалтерских данных в виде цифр в
клетках предписанных форм отчетности. Не менее строго, но
совершенно по иному, формализовано создание сборочных чертежей в
виде наборов линий, организованных в графические и текстовые
изображения.
Каждый метод описания предназначен для составления описаний,
адресующих определённые интересы, которые имеют те или иные
стейкхолдеры. Для наилучшего удовлетворения этих интересов и
используются принятые стейкхолдерами предметные онтологии и
нотации. Если какое-то описание не предназначено для
удовлетворения конкретного интереса какого-то стейкхолдера – оно
является излишним.
Метод описания – состоящий из онтологии и нотации способов

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

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

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

понятиями:
Каждый стейкхолдер характеризуется набором своих интересов.

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

или нескольких интересов.
Каждое описание системы входит в какую-либо тематическую группу

описаний (чаще всего в одну такую группу), порождённую одним
методом описания. Если какое-то описание входит в разные
тематические группы, то это означает, что способ его получения также
входит в разные методы описания.
Введённые понятия стейкхолдер (stakeholder), интерес (concern),

метод описания (viewpoint), тематическая группа описаний (view),
отдельное описание (model) и их связи соответствуют основным
понятиям и связям, введённым международным стандартом ISO/IEC
42010:2007 Systems and software engineering – Recommended practice
for architectural description of software-intensive systems.
К созданию целостного описания системы можно прийти только в

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

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

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

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

соответствующих предметной онтологии метода фактов о системе;
Определение подхода позволяет говорить о наличии подхода при

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

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

стейкхолдеров, но всего лишь один метод описания системы. Таков,
например, подход онтологического организационного моделирования
DEMO. Но подход может содержать и целую группу методов описания,
и даже включать в себя другие подходы.
Подход системной инженерии ISO/IEC 15288:2008 основан более
широком системном подходе, содержит ссылки на архитектурный
подход, включает элементы процессного подхода и проектного
подхода, подробнее о которых будет рассказано ниже.
Подход конкретной организации к решению задач системной

инженерии может включить подход онтологического организационного
моделирования DEMO как часть процессного подхода при адаптации
этой организацией для своих нужд подхода системной инженерии
ISO/IEC 15288:2008.
Описание системы может быть выполнено с разной степенью

абстракции. Мы будем говорить о разных уровнях абстракции при
описании системы.
Уровни описания системы
- опорный (в основном функциональный);
- принципиальный (в основном конструкционный);
- выполняемый (инструкции);
- исторический (измерения, временные ряды, отчёты): актуальные

(измеренные), прогностические (прогнозные данные), нормативные
(показатели эффективности)
На опорном уровне система описывается как целое, то есть как

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

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

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

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

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

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

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

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

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

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

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

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

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

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

семействе деятельностных подходов. Этот термин используется
некоторыми течениями философии и психологии, предлагающими ряд
конкурирующих определений понятия деятельность. Кроме философов
и психологов, определением отношений понятий деятельности,
процессов, проектов, активностей, работ, задач и множества других
занимаются в рамках инженерной метафизики – построения
онтологических описаний реальности, направленных на решение
самых разных инженерных задач, от интеграции компьютерных систем
промышленного предприятия до выработки новых методов управления
проектами. Мы постараемся дать лишь несколько базовых
определений, позаботившись об отсутствии противоречий при их
использовании в контекстах разных управленческих теорий (теорий
менеджмента).
Тема 4. Методологии, применяемые в системной инженерии
4.1. Методология MRP
4.1.1 История появления и развития MRP-систем

4.1.2 Принцип работы MRP II
4.2 ERP-системы
4.3 Функции ERP-систем
4.4 Выбор ERP-системы
4.4.1 Достоинства
4.4.2 Недостатки
4.5 Методология RUP
4.5.1 Общие сведения
4.5.2 Отличительные черты RUP
4.5.3 Итерации
4.5.4 Принципы RUP
4.5.5 Жизненный цикл разработки
4.5.6 Стадии итеративной разработки по RUP
4.5.6.1 Начальная стадия (Inception)
4.5.6.2 Уточнение (Elaboration)
4.5.6.3 Построение (Construction)
4.5.6.4 Внедрение (Transition)
4.5.6.5 RUP – процесс, основанный на архитектуре
4.5.6.6 Технологические процессы в RUP
Методология MRP
Планирование потребности в материалах (Material Requirements

Planning, MRP) – методология, используемая в управлении
производством и обеспечивающая разработку планов и графиков
поставки материалов и комплектующих для обеспечения заданной
программы производства.
MRP-система – программное обеспечение, реализующее

регламентированный MRP-методологией алгоритм и формирующее
результаты материального аспекта производства на основе входных
данных.

История появления и развития MRP-систем
В докомпьютерную эпоху все задачи по контролю за наличием

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

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

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

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

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

системы MRP с замкнутым циклом в расширенную модификацию,
которую впоследствии назвали MRP II (Manufactory Resource Planning).
Эта система была создана для эффективного планирования всех (в том
числе, финансовых и кадровых) ресурсов производственного
предприятия.
Системы планирования производства развиваются постоянно, стараясь

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

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

период на основании анализа принятой программы производства;
- учёт материалов, не включённых в производственную программу, но

присутствующих в заказах;
- расчёт полной потребности в каждом материале в соответствии с

составом конечного продукта;
- расчёт чистой потребности в каждом материале и составление

заказов на материал;
- внесение корректив в сформированные заказы с целью

предотвращения несвоевременных поставок.
В результате система выдаёт план заказов с оперативными

изменениями и ряд служебных отчётов. Классическая MRP-система
выдает на выходе следующие результаты:
- План Заказов. Он определяет, какое количество каждого материала

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

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

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

планирования.
- Исполнительный отчет. Индикатор корректности выполнения всех

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

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

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

то она начинает взаимодействие с MRP-системой, иначе в программу
вносятся коррективы, и она подвергается повторному тестированию
посредством подсистемы планирования производственных мощностей.
Принцип работы MRP II
Планирование производственных ресурсов (Manufacturing Resource

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

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

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

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

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

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

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

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

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

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

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

расстановки приоритетов между руководящей и исполняющей
сторонами.
- Планирование потребности в мощностях.
- Управление входным/выходным материальным потоком контролирует

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

преобразует заявки в заказы на закупку.
- Планирование ресурсов распределения обеспечивает планирования в

случае, когда предприятие имеет территориально распределённую
структуру с несколькими удалёнными друг от друга площадками.
- Закупки (Purchasing).
- Интерфейс с финансовым планированием.
- Оценка результатов деятельности (Performance Measurement.
- Моделирование (Simulation).
Рисунок 4.1 – Модули MRP
Одной из основных причин того, что MRP была с готовностью

воспринята как методология управления производством, является ее
обращение к возможностям вычислительной техники в области
хранения и обработки больших массивов данных и предоставления
доступа к ним в целях эффективного управления предприятием. Она
помогает координировать деятельность различных подразделений
предприятия по исполнению свойственных им функций. Поэтому
привлекательность MRP состоит не только в поддержке принятия
решений, но и, что более важно, в ее интеграционной роли для
производственных предприятий.
ERP-системы
ERP-система (Enterprise Resource Planning System – Система

планирования ресурсов предприятия) – корпоративная
информационная система, предназначенная для автоматизации учёта и
управления. Как правило, ERP-системы строятся по модульному
принципу, и в той или иной степени охватывают все ключевые
процессы деятельности компании.
ERP- система – это финансово ориентированная информационная

система для определения и планирования ресурсов предприятия,
необходимых для получения, изготовления, отгрузки и учета заказов
потребителей. Система ERP отличается от типичной системы MRP II
техническими характеристиками, такими как:
- графический интерфейс пользователя,

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

систем.
На отечественном рынке представлены ERP-системы большинства

ведущих международных разработчиков, а также решения
отечественных компаний.
Решения для крупного и среднего бизнеса:
- IFS Applications - компании IFS;
- Alfa ERP - компании Информконтакт;
- CBOSSmis - компании CBOSS ;
- Infor ERP LN - компании Infor;
- NetSuite OneWorld - компании NetSuite ;
- Oracle E-Business Suite;
- SAP ERP - компании SAP;
- Галактика ERP;
- Капитал CSE - компании Геликон Про;
- НОРДИС/2 - компании Алекта.
Решения для среднего бизнеса:
- IFS Applications - компании IFS;
- 1С:Управление производственным предприятием 8 - компании 1С;
- Alfa ERP Express - компании Информконтакт;
- Epicor 9 - компании Epicor;
- Exact Globe Enterprise - компании Exact Software;
- Dynamics NAV - компании Microsoft;
- Галактика ERP;
- Dynamics AX;
- NetSuite ERP - компании NetSuite;
- SAP Business All-in-One - компании SAP;
- НОРДИС/2 - компании Алекта;
- AVA ERP - компании AVASystems;
- Infor ERP SyteLine - компании Infor;
- Компас - компании Компас;
- Solaris ERP - компании ИТеЯ.
Решения для среднего и малого бизнеса:
- Галактика Прогресс, Галактика Старт;
- Comtec for Business - компании Комтех-системы для бизнеса;
- OrganicERP - компании Фаст Финанс;
- SAP Business One - компании SAP;
Open Source решения для малого и среднего бизнеса:
- ERP5;
- Openbravo ERP;
- Compiere;
- OpenERP;
- Галактика Экспресс;
Исторически концепция ERP стала развитием более простых концепций

MRP (Material Requirement Planning – Планирование материальных
потребностей) и MRP II (Manufacturing Resource Planning –
Планирование производственных ресурсов). Используемый в ERP-
системах программный инструментарий позволяет проводить
производственное планирование, моделировать поток заказов и
оценивать возможность их реализации в службах и подразделениях
предприятия, увязывая его со сбытом.
Один из важных вопросов – относится или нет система к классу ERP,

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

наличие в системе обратной связи. Т.е. на основании целей
управления составляется план, затем по ходу выполнения работ
проводится фиксация реальных показателей, их анализ и на основании
сравнения поставленных целей и достигнутых результатов
вырабатывается корректирующее воздействие. Учётная система
позволяет только фиксировать результаты. Она, в отличие от ERP-
системы не включает в себя функции для автоматизации
планирования, и сравнения «план – факт». Иначе говоря, с помощью
учетных систем можно выполнить только некоторую аналитическую
часть управления, но не синтетическую. В этом принципиальное
отличие ERP-системы от учетной системы.
Функции ERP-систем
В основе ERP-систем лежит принцип создания единого хранилища

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

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

объёмов поставок для выполнения плана производства продукции;
- управление запасами и закупками: ведение договоров, реализация

централизованных закупок, обеспечение учёта и оптимизации
складских и цеховых запасов;
- планирование производственных мощностей от укрупнённого

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

признаки ERP-систем можно подразделить на технологические и
функциональные. На технологическом уровне общепринятыми
требованиями являются: наличие трехуровневой архитектуры системы,
включающей сервер баз данных, сервер приложений и клиентскую
часть, единая база данных (или распределенная с задействованным
механизмом репликации данных), открытость систем, использование
реляционных СУБД и средств CASE для проектирования и развития
этих систем. Среди технологических требований называют также
графический пользовательский интерфейс, но систем без него сегодня
крайне мало.
Что касается функционального наполнения ERP-систем, то оно описано

в определениях APICS (American Production and Inventory Control
Society, сейчас – Association for Operations Management) и Gartner. По
версии APICS в ERP-системе должны быть реализованы следующие
функциональные блоки:
- автоматизации управления производственными ресурсами

(Manufacturing Resource Planning – MRPII);
- автоматизации управления цепочками поставок (Supply Chain

Management – SCM, в развитие Distribution Resource Planning – DRP);
- автоматизации расширенного объемно-календарного планирования

(Advanced Planning and Scheduling – APS);
- автоматизации управления конструкторско-технологической

документацией (Product Data Management – PDM);
- автоматизации конечного планирования ресурсов (Finite Resource

Planning – FRP);
- электронной коммерции (Electronic Commerce – ЕС);
- автоматизации управления взаимоотношениями с клиентами

(Customer Relationship Management – CRM, ранее – Sales Force
Automation – SFA);
- бизнес-аналитики (Business Intelligence – BI);
- конфигурирования системы (Standalone Configuration Engine – SCE).
В данном списке не упоминается финансовый блок, так как он включен

в MRPII (Financial Planning).
Что касается «матери» аббревиатуры ERP как таковой – компании
Gartner – то, по ее версии, ERP-система должна включать следующие
блоки:
- MRPII;
- поддержки всех видов производств;
- финансового учета и планирования;
- управления продажами;
- управления логистикой;
- управления закупками;
- управления персоналом.
При этом центральным блоком, связывающим между собой все

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

«ERP-систем» полным функциональным наполнением по требованиям
APICS и Gartner обладают продукты только компаний SAP и Oracle.
Решения же остальных разработчиков реализуют разные сочетания
описанных выше функциональных блоков «идеальной» ERP-системы. В
то же время, участники рынка относят их к классу ERP, что лишний раз
подтверждает рекомендательный характер приведенных выше
описаний.
Любая ERP-система, как правило, рассчитана на определенный сегмент

рынка. Так, SAP чаще используют на крупных промышленных
предприятиях, Microsoft Dynamics – в компаниях среднего размера и
разного профиля, 1С – в компаниях небольших, а также в случае
ограниченного бюджета.
Стоимость внедрения ERP, в зависимости от размера компании,

сложности и выбранной системы, может составлять от 20 тыс. USD до
нескольких миллионов USD. В эту сумму включаются лицензии на ПО,
а также услуги по внедрению, обучению и поддержке на этапе запуска
системы в эксплуатацию. Не стоит пытаться узнать точную стоимость
ERP-проекта. Оценка стоимости проекта всегда дается индивидуально,
с учетом бизнес-процессов компании, ее приоритетов и потребности в
автоматизации, а также количества пользователей, которые будут
работать с ERP. Поэтому чтобы узнать ориентировочную стоимость
проекта, необходимо обратиться к консультантам и быть готовым
обсуждать необходимые им детали. Кроме того, надо быть готовым к
тому, что полученная оценка не является точной, и скорее всего, будет
пересматриваться после подготовки технического задания на проект.

Выбор ERP-системы
Рост сложности ERP-систем, вызванный постоянно наращиваемыми

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

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

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

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

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

информации уменьшает эффективность системы.
Согласно результатам исследования, проведенного в 2008 году
американской компанией Panorama Consulting Group, 93% ERP-
проектов длятся дольше запланированного срока, и почти две трети
проектов не укладываются в выделенный им бюджет. Более того, лишь
13% компаний полностью довольны результатами ERP-проектов, и
только 21% компаний смогли реализовать в ходе внедрения ERP хотя
бы половину запланированных задач.
Множество проблем, связанных с функционированием ERP, возникают

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

достаточно денег в ERP и адекватно обучить всех сотрудников;
- внедрение является достаточно дорогим;
- Система может страдать от проблемы «слабого звена» –

эффективность всей системы может быть нарушена одним
департаментом или партнёром;
- проблема совместимости с прежними системами.
Существует заблуждение, что иногда ERP сложно или невозможно

адаптировать под документооборот компании и её специфические
бизнес-процессы. В действительности, любому внедрению ERP-системы
предшествует этап описания бизнес-процессов компании.
Методология RUP
Общие сведения
Rational Unified Process (RUP) – методология разработки программного

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

при разработке программных систем и объединенных единым
философским подходом. Методом будем называть совокупность,
включающую концептуальные понятия, базовую нотацию,
описывающую графическое представление этих понятий и правила
построения моделей, а также описание процесса проектирования и
разработки. Наконец, термином «методика» мы будем пользоваться
для обозначения достаточно подробного описания последовательности
шагов, выполняемых при разработке проекта системы на основе
определенного метода. Методика обычно предполагает использование
одного или нескольких инструментальных средств.
Отличительные черты RUP
- RUP – это итеративный процесс (Controlled Interactive);
- Предполагает сквозное применение аппарата Use Cases (Use Case

Driven);
- Особое внимание уделяется разработке архитектуры (Architecture

Centric);
- Включает управление требованиями и изменениями (Requirements

Configuration and Change Management);
- Опирается на компонентную концепцию разработки ПС (Component

Based Development).
- Базируется на визуальном моделировании (Visual Modeling

Techniques).
Итерации
Классический водопадный жизненный цикл включает этапы анализа

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

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

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

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

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

использованию программных элементов. Анализ результатов каждой
итерации позволяет архитекторам ПС выделить фрагменты,
потенциально подлежащие повторному использованию, а в следующей
итерации оформить их как повторно используемые коды. Это свойство
очень хорошо сочетается с идеями ОО и компонентного
Принципы RUP
В основе RUP лежат следующие принципы:
- Ранняя идентификация и непрерывное (до окончания проекта)

устранение основных рисков.
- Концентрация на выполнении требований заказчиков к исполняемой

программе (анализ и построение модели прецедентов (вариантов
использования)).
- Ожидание изменений в требованиях, проектных решениях и

реализации в процессе разработки.
- Компонентная архитектура, реализуемая и тестируемая на ранних

стадиях проекта.
- Постоянное обеспечение качества на всех этапах разработки проекта

(продукта).
- Работа над проектом в сплочённой команде, ключевая роль в которой
принадлежит архитекторам.
Жизненный цикл разработки
RUP использует итеративную модель разработки. В конце каждой

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

(рисунок 4.2), каждая из которых включает в себя одну или несколько
итераций:
Рисунок 4.2 – Графическое представление процесса разработки по RUP
Методы проектирования информационных систем (ИС) постепени

автоматизацииразделяются на методы:
- ручного проектирования, при котором проектирование компонентов

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

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

следующие методы проектирования:
- оригинального (индивидуального) проектирования, когда проектные

решения разрабатываются «с нуля» в соответствии с требованиями к
ИС;
- типового проектирования, предполагающего конфигурацию ИС из

готовых типовых проектных решений (программных модулей).
Оригинальное (индивидуальное) проектирование ИС характеризуется

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

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

классифицируются на методы:
- реконструкции, когда адаптация проектных решений выполняется

путем переработки соответствующих компонентов
(перепрограммирования программных модулей);
- параметризации, когда проектные решения настраиваются (пе-

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

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

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

подкласса: автоматизированное (использование CASE-технологий) и
типовое (параметрически-ориентированное или модельно-
ориентированное) проектирование. Использование индустриальных
технологий проектирования включает в отдельных случаях
использование канонической технологии.
Таблица 5.1 - Характеристики классов технологий проектирования
Класс технологии Степень Степень Степень

проектирования автоматизации типизации адаптивности
Каноническое Ручное Оригинальное
Реконструкция
проектирование проектирование проектирование
Индустриальное Реконструкция
Компьютерное Оригинальное
автоматизированное модели
проектирование проектирование
проектирование (генерация ИС)
Параметризация
Индустриальное Типовое и реконструкция
Компьютерное
типовое сборочное модели
проектирование
проектирование проектирование (конфигурация
ИС)
Для конкретных видов технологий проектирования свойственно

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

использования ЭВМ и с использованием ЭВМ.
Средства проектирования без использования ЭВМ применяются на всех

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

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

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

операции проектирования ИС и могут применяться независимо друг от
друга.
Ко второму подклассу относят средства, поддерживающие

проектирование отдельных компонентов проекта ИС. К данному
подклассу относятся средства общесистемного назначения:
- системы управления базами данными (СУБД);
- методоориентированные пакеты прикладных программ (решение

задач дискретного программирования, математической статистики и
т.п.);
- табличные процессоры;
- статистические пакеты прикладных программ (ППП);
- оболочки экспертных систем;
- графические редакторы;
- текстовые редакторы;
- интегрированные ППП (интерактивная среда с встроенными

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

проектирование разделов проекта ИС. В этом подклассе выделяют
функциональные средства проектирования.
Функциональные средства направлены на разработку

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

информации относятся типовые проектные решения, функциональные
пакеты прикладных программ, типовые проекты.
К четвертому подклассу средств проектирования ИС относятся

средства, поддерживающие разработку проекта на стадиях и этапах
процесса проектирования. К данному классу относится подкласс
средств автоматизации проектирования ИС (СASE-средства).
Современные CASE-средства, в свою очередь, классифицируются в
основном по двум признакам:
- по охватываемым этапам процесса разработки информационных

систем;
- по степени интегрированности: отдельные локальные средства

(tools), набор неинтегрированных средств,охватывающих большинство
этапов разработки ИС (toolkit) и полностью интегрированные
средства,связанные общей базой проектных данных – репозиторием
(workbench).
Качество программного обеспечения является относительным

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

аспектами: качество программного продукта, качество процессов
жизненного циклаи качество сопровождения или внедрения (рисунок
6.1).

Рисунок 6.1 – Основные аспекты качества программного обеспечения
Качество продукта целиком и полностью определяется процессами

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

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

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

(показателей) качества для программного обеспечения, каждая из них
отражает отдельную точку зрения пользователя на качество. Согласно
стандарта ISO/IEC 9126. Infofmation Technology. – Software Quality
Characteristics and metrics. определено шесть характеристик или шесть
показателей качества в стандартной модели качества:
- функциональная пригодность (functionality),
- надежность (realibility),
- удобство применения (usability),
- эффективность (efficiency),
- сопровождаемость (maitainnability),
- переносимость (portability).
Второму уровнюсоответствуют атрибуты качества для каждой

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

каждая из них согласно стандарта ISO/IEC 9126 определяется как
комбинация метода измерения атрибута и шкалы измерения значений
атрибутов. Для оценки атрибутов качества на этапах жизненного цикла
(при просмотре документации, программ и результатов тестирования
программ) используются метрики с заданным оценочным весом для
нивелирования результатов метрического анализа совокупных
атрибутов конкретного показателя и качества в целом. Атрибут
качества определяется с помощью одной или нескольких методик
оценки на этапах жизненного цикла и на завершающем этапе
разработки программного обеспечения.
Четвертый уровеньзадает оценочный элемент метрики для оценки

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

программного обеспечения выбираются наиболее важные
характеристики качества и их приоритеты. Выбранные для каждой
характеристики атрибуты и их приоритеты отражаются в требованиях
на разработку систем. Для программных систем, при разработки
которых в требованиях не указан приоритет характеристик качества,
используется приоритет эталона – класса программного обеспечения, к
которому оно относится.
Модель качества согласно стандарта ISO/IEC 9126 приведена на

рисунке 6.2, а краткое описание семантики каждой из шести
характеристик качества и ее атрибутов приводится ниже.

Рисунок 6.2 – Модель характеристик качества
1. Описано качество и надежность программного обеспечения
1. Дайте определение системы и укажите ее основные свойства.
2. Охарактеризуйте критерии определения качества программного

3. Что понимается под надежностью программного обеспечения?
Тема 7 Стандартизация и сертификация программного

7.1.Стандартизация и сертификация
7.1.1.Стандартизация
7.1.2. Сертификация
7.1.3 Типы стандартов
7.2. Системные основы современных технологий программной

инженерии
Стандартизация и сертификация
Стандартизация
Программные продукты бывают двух типов: заказные (под заказ

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

которых разрабатывают те или иные требования, характеристики,
параметры, правила и т. п. Стандартизация может касаться либо
объекта в целом, либо его отдельных составляющих (характеристик).
Областью стандартизации называют совокупность взаимосвязанных
объектов стандартизации.
Термин «стандарт» происходит от английского standard – норма,

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

документ, устанавливающий комплекс норм, правил по отношению к
предмету стандартизации;
-типовой образец, эталон, модель, принимаемые за исходные для

сопоставления с ними других предметов.
Например: ГОСТ ЕСПД – единая система программной документации –

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

веществ);
-нормы, правила, требования организационно-методического и

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

деятельности: науку, технику, промышленное и сельскохозяйственное
производство, строительство, здравоохранение, транспорт и т.д.
Необходимость стандартизации разработки ПО наиболее удачно
описана во введении в стандарт ISO/IEC 12207: «Программное
обеспечение является неотъемлемой частью информационных
технологий и традиционных систем, таких, как транспортные, военные,
медицинские и финансовые. Имеется множество разнообразных
стандартов, процедур, методов, инструментальных средств и типов
операционной среды для разработки и управления программным
обеспечением. Это разнообразие создает трудности при
проектировании и управлении программным обеспечением, особенно
при объединении программных продуктов и сервисных программ.
Стратегия разработки программного обеспечения требует перехода от
этого множества к общему порядку, который позволит специалистам,
практикующимся в программном обеспечении, «говорить на одном
языке» при разработке и управлении программным обеспечением. Этот
международный стандарт обеспечивает такой общий порядок».
Сертификация
Сертификация – это процесс подтверждения того, что система или

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

система или элемент соответствуют заданным требованиям и могут
использоваться по назначению (ISO/IEC24765).
Сертификация в переводе с латыни означает «сделано верно». Для

того чтобы убедиться в том, что продукт «сделан верно», надо знать:
- каким требованиям он должен соответствовать;
- каким образом можно получить достоверные доказательства этого

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

сертификация соответствия и заявление о соответствии.
Заявление поставщика о соответствии означает, что поставщик

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

ссылается изготовитель;
-указание о личной ответственности изготовителя за содержание
заявления.
Заявление не является гарантией на соответствие стандарту.

Заявление отражает готовность нести ответственность.
Сертификация соответствия предполагает обязательное участие

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

ее деятельностью и может передавать право на проведение
сертификации другим органам; правила и порядок проведения
сертификации;
- нормативные документы, на соответствие которым осуществляется

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

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

основные типы стандартов:
Корпоративные стандарты разрабатываются крупными фирмами

(корпорациями) с целью повышения качества своей продукции. Такие
стандарты разрабатываются на основе собственного опыта и с учетом
требований мировых стандартов. Корпоративные стандарты не
сертифицируются, но являются обязательными для применения внутри
корпорации. В условиях рыночной конкуренции могут иметь закрытый
характер. В сфере IT известны стандарты, разработанные Microsoft,
Intel, IBM.
Отраслевые стандарты действуют в пределах организаций некоторой

отрасли (министерства). Например, СНИП – строительные нормы и
правила. Разрабатываются с учетом требований мирового опыта и
специфики отрасли. Являются, как правило, обязательными для
отрасли. Подлежат сертификации.
Государственные стандарты (ГОСТы) принимаются государственными
органами, имеют силу закона. Разрабатываются с учетом мирового
опыта или на основе отраслевых стандартов. Могут иметь как
рекомендательный, так и обязательный характер (стандарты
безопасности). Для сертификации создаются государственные или
лицензированные органы сертификации.
Международные стандарты. Разрабатываются, как правило,

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

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

ошибка при реинжиниринге – это когда никакого реинжиниринга
вообще не происходит, а под этим названием понимаются
незначительные изменения в процессе. В последнее время термин “BPR
– business process reengineering” используется по отношению к самым
разным программам, которые ничего общего не имеют с радикальным
перепланированием процесса.
Предприятия часто идут на огромные жертвы, чтобы избежать

радикальной перепланировки, связанной с BPR. Они могут провести
реорганизацию (изменяется не процесс выполнения работы, а всего
лишь административные рамки, в которых находятся сотрудники),
сокращение (использование меньшего числа сотрудников для
выполнения той же самой работы, иногда в меньших размерах), другие
мероприятия, которые различными способами побуждают людей
работать более интенсивно. Существующие процессы, даже в том
случае, если они являются источником проблем для предприятия, все
же хорошо знакомы и привычны; инфраструктура, нужная для
организации этих процессов, уже имеется. Кажется, гораздо проще и
разумнее улучшить эти процессы, а не отбросить их и начать с нуля.
Путь наименьшего сопротивления, по которому идут большинство
предприятий – внесение небольших изменений. Это также самый
верный путь к провалу при проведении BPR.
2. Внимание не фокусируется на бизнес-процессах. Одна из причин

неудач BPR заключается в неправильно поставленной задаче. Такие
цели, как расширение полномочий, повышение эффективности работы
в группе, улучшение обслуживания клиентов и т.д. являются
абстрактными понятиями, это желательные для предприятия
характеристики или атрибуты, при этом не существует какого-то
четкого пути к их достижению. Они являются последствиями
планирования процессов и достигнуты могут быть только в таком
контексте. Как можно расширить чьи-то полномочия, если не в рамках
организации рабочих процессов?
3. Игнорируется все, кроме перепланирования процесса.BPR приводит

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

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

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

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

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

Существует две причины, по которым работники низшего звена и
руководители среднего звена не могут инициировать и реализовать
BPR. Первая причина заключается в том, что работники низшего звена
не могут видеть полной картины того, что требуется при BPR. Во-
вторых, любой бизнес-процесс выходит за границы предприятия,
поэтому ни один руководитель среднего звена не обладает
достаточными полномочиями, чтобы настаивать на изменении такого
процесса. Более того, некоторые из руководителей такого ранга
опасаются, что радикальные изменения существующего процесса
приведут к снижению их собственной власти, влияния, авторитета.
8. Недостаток ресурсов на проведение BPR.Предприятие не сможет
добиться успеха при проведении BPR, если не будет вкладывать
средства в этот процесс. При этом наиболее важная составляющая этих
вложений - время и внимание лучших сотрудников, включая личное и
непосредственное участие руководства верхнего звена. От руководства
не требуется самим проводить все работы по BPR, но ответственность
за весь процесс нельзя перекладывать ни на кого. Урезание ресурсов
на BPR означает также и то, что руководство не считает эту работу
такой уж важной, и тем самым толкает сотрудников на уклонение от
этой работы или сопротивление ей.
9. Попытка провести BPR, чтобы никого не обидеть.Для BPR очень

верна поговорка: «Чтобы сделать яичницу, нужно разбить яйца». От
результатов BPR выигрывают не все. Одни потеряют работу, другие
будут недовольны той работой, которую они будут выполнять после
BPR. Желание угодить всем приведет к тому, что BPR сведется к
незначительным изменениям или его реализация будет отложена на
потом. Поэтому сопротивление является неизбежной реакцией на
серьезные изменения, к которым приводит BPR. Руководство должно
ожидать этого сопротивления и не позволить завалить все дело.
Все рассмотренные ошибки (а безусловно, существуют и другие) имеют

одну общую характеристику. Они связаны с ролью, которую играет
руководство верхнего звена. Если попытка проведения BPR
провалилась, то глубинная причина провала в том, что руководство
недостаточно поддерживало процесс.
1. Описан реинжиниринг бизнес-процессов.
2. Рассмотрены основные подходы к реинжинирингу бизнес-процессов.
3. Проанализированы причины неудач при реинжиниринге.
1. Дайте определение реинжиниринга.
2. Перечислите подходы к реинжинирингу систем.
3.Расскажите основные причины неудач при реинжиниринге.

СПИСОК ЛИТЕРАТУРЫ И ССЫЛКИ НА ИНТЕРНЕТ-РЕСУРСЫ:
Основная литература
1. Батоврин В.К. Толковый словарь по системной и программной

инженерии: учеб. Пособие для ВУЗов. М.: ДМК Пресс, 2012. – 280с.
2.Иванова Г.С. Технология программирования: учебник/ М.:КНОРУС,

2011. – 336 с.
3.Буч Г. Объектно-ориентированный анализ и проектирование с

примерами приложений на С++: пер. с англ. М.: Бином, СПб.: Невский
диалект, 1998.
4.Камаев В.А., Костерин В.В. Технологии программирования: Учебник.

М.: Высш.шк., 2005. – 359 с.
5. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование

экономических информационных систем: учебник / Г.Н. Смирнова, А.А.
Сорокин, Ю.Ф. Тельнов. – М. : Финансы и статистика, 2001. – 512 с.
6. Фахтутдинов В. А. «Инновационный менеджмент»: Учебник для

вузов 6-е изд. – СПб, Питер, 2008 ISBN 978-5-469-01658-8
7. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя.

Издательство: ДМК Пресс, 2007 г.
8. Брукс П. Метрики для управления ИТ-услугами. Издательство:

Альпина Бизнес Букс, 2008 г.
9.Леоненков А.В. Самоучитель UML 2. СПБ: BHV-СПб, 2007. – 576 с.

(CASE средства Borland Together Designer)
Дополнительная литература
1. Гаврилов Д.А. Управление производством на базе стандарта MRP II.

2-е изд. – СПб.: Питер, 2005. – 416 с.
2. Магазанник В.Д. Человеко-компьютерное взаимодействие: Учебное

пособие. Издательство: Университетская книга, Логос, 2012 г.
3. Вдовин В.М., Суркова Л.Е, Валентинов В.А. Теория систем и

системный анализ: Учебник. Издательство: Дашков и К, 2010 г.
Интернет-ресурсы
3. http://www.citforum.ru
4. http://guardmag.com
5. http://gradschools.com/search-programs/system-engeneering
6. http://www.intuit.ru
ЗАКЛЮЧЕНИЕ ПО КУРСУ ЛЕКЦИЙ
В предложенном учебном пособии (курс лекций) «Системная

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

«Системная инженерия» для подготовки магистра по направлению
подготовки 09.04.02. – Информационные системы и технологии и
профилю подготовки «Управление данными».
Полученные знания могут быть использованы магистрами для

выполнения научно-исследовательской работы и подготовки
магистерской диссертации.

Ставрополь - 2015 - МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ставрополь - 2015 - МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Загружено:

Авторское право:

Доступные форматы

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ

Федеральное государственное автономное

образовательное учреждение высшего профессионального

«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

Дроздова В.И., Романенко М.Г.

УЧЕБНОЕ ПОСОБИЕ (КУРС ЛЕКЦИЙ)

Направление подготовки: 09.04.02 «Информационные системы и

Магистерская программа: Управление данными;

Квалификация выпускника: Магистр

Линец Г.И. доктор технических наук, заведующий кафедрой

Дроздова В.И.., Романенко М.Г. Системная инженерия: учебное

Учебное пособие по дисциплине «Системная инженерия» составлено в

Теоретический материал, представленный в учебном пособии,

© ФГАОУ ВПО «Северо-Кавказский

федеральный университет», 2015

РАЗДЕЛ 1. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМНОЙ ИНЖЕНЕРИИ

Тема 1. Основы системной инженерии

1.1Определение системной инженерии.

1.2Проблемы современной инженерии

Проблемы современной инженерии

Сложность современных проектов: до 10 млн. деталей (нефтяная

До 1000 контракторов на один проект, у каждого контрактора свой

Требования и спецификации проекта приходят с самых разных сторон

Каждый проект стал «вавилонской башней».

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

8% затрат на внедрение системной инженерии дают выигрыш в 20%

Стадия обнаружения ошибки Коэффициент стоимости ошибки

Требования x1 (единица отсчета)

Интеграция разных идей в одной организационной системе на уровне

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

Универсальность системной инженерии

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

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

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

Включает в процессы людей, оборудование, компьютеры, софт

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

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

Совместная разработка ISO и IEC, активное участие INCOSE;

Начало работ в 1996, версии в 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-

Призван гармонизировать так называемое «болото стандартов»

Система – совокупность взаимодействующих элементов,

Зафиксированный вариант (Baseline) – вариант спецификации или

Организация – человек или группа людей, сооружений и

Продукт – результат процесса (ISO 9000:2005)

Проект – мероприятие с определенными критериями начала и

Приёмка (Validation) – подтверждение, что система удовлетворяет

Проверка (Verification) – подтверждение, что специфицированные к

Обеспечивающая система (Enabling system) – система,

1. Определение системной инженерии.

2. Проблемы современной инженерии

3. Описаны основные аспекты подтверждающие универсальность

Вопросы для самопроверки

1. Дайте определение системной инженерии.

2. Перечислите проблемы современной инженерии.

3.Дайте определение основным терминам, использующимся в

РАЗДЕЛ 2. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Тема 2. Жизненный цикл и этапы разработки программного

2.1. Подход жизненного цикла

2.2. Этапы жизненного цикла программного обеспечения

2.2.1 Постановка задачи

2.2.2 Анализ требований и определение спецификаций

Подход жизненного цикла

Жизненный цикл (ЖЦ) системы представляет собой эволюцию