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

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

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

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

- проектирование,

- кодирование (программирование),

- тестирование и отладка,

- эксплуатация и сопровождение,

- отказ от сопровождения.

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

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

В соответствии со стандартом в процессе разработки программного обеспечения, необходимо:

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

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

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

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

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

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

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

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

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

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

Согласно ГОСТ 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 – как термин нигде не определяется, является омонимом, то есть имеет множество значений в словарном гнезде.

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 и т.д.).

2. Определение:

С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, вводится в стандартах, основывающихся на системном подходе.

2. Определение:

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.

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

Уровни описания системы

- опорный (в основном функциональный);

- принципиальный (в основном конструкционный);

- выполняемый (инструкции);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Деятельностные подходы

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

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