129 ПРОЦЕССЫ В САПР (АДАПТАЦИЯ СТАНДАРТА ИСО/ MЭK 12207

ПРОЦЕССЫ В САПР

(АДАПТАЦИЯ СТАНДАРТА ИСО/ MЭK 12207)

 

Учебное пособие

 

 

 

 

 

 

 

 

 

Рязань 2003

 

УДК 681.3

Процессы в САПР (адаптация стандарта ИСО/ MЭK 12207): Учеб. пособие / Ю.М. Цыцаркин, Е.Ю. Скоз; Рязан. гос. радиотехн. акад. Рязань, 2003. 48 с.

ISBN 5-7722-0234-0.

Описаны основные, вспомогательные и организационные процессы разработки САПР, регламентируемые стандартом ИСО/ MЭK 12207, приведены методики формирования и использования процессов разработки САПР на всех стадиях жизненного цикла изделия для различных моделей жизненного цикла: каскадная, пошаговая, заказная и спиральная.

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

Табл. 3. Ил. 11.   Библиогр.: 3 назв.

 

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

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

 

Рецензент: кафедра САПР ВС Рязанской государственной радиотехнической академии (зав. кафедрой чл. корр. АТН РФ, д-р техн. наук, проф. В.П. Корячко)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ISBN 5-7722-0234-0                                     Ó      Рязанская государственная

радиотехническая академия, 2003

 

1. ОСНОВНЫЕ КОНЦЕПЦИИ СТАНДАРТА ИСО/МЭК 12207

 

1.1. Дисциплина инжиниринга

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

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

 

1.2. Архитектура жизненного цикла программных средств

Стандарт ИСО/МЭК 12207 устанавливает архитектуру жизненного цикла программных средств верхнего уровня от разработки концепций до снятия с эксплуатации. Архитектура создается на базе процессов и связей между процессами. В основе процессов лежат два основных принципа: модульность и ответственность.

1.2.1. Модульность. Процессы, определяемые стандартом, имеют модульный характер:

а) процессы имеют сильную связность (strongly cohesive) – все части процесса связаны между собой;

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

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

  1. Процесс должен быть модульным, т.е. один процесс должен выполнять одну и ту же функцию в рамках жизненного цикла; между двумя любыми процессами следует использовать минимальное число интерфейсов.
  2. Каждый процесс активизируется в архитектуру.
  3. Если процесс А активизируется процессом В и только процессом В, процесс А принадлежит процессу В.
  4. Если функция активизируется более чем одним процессом, эта функция становится самостоятельным процессом.
  5. Должна обеспечиваться возможность верификации любой функции в рамках модели жизненного цикла.
  6. Каждый процесс должен иметь внутреннюю структуру, определяемую в достаточной для исполнения степени.

1.2.2. Ответственность

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

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

Свойство «ответственность» архитектуры жизненного цикла облегчает адаптацию и применение стандарта ИСО/МЭК 12207 в проекте, в который на законном основании вовлечено множество лиц.

1.3. Типы процессов

В широком плане процессы делятся на три класса:

  • основные процессы;
  • вспомогательные процессы;
  • организационные процессы.

 

1.3.1. Основные процессы:

  • процесс заказа;
  • процесс поставки;
  • процесс разработки;
  • процесс эксплуатации;
  • процесс сопровождения.

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

1.3.2. Вспомогательные процессы:

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

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

 

1.3.3. Организационные процессы:

  • процесс управления;
  • процесс создания инфраструктуры;
  • процесс усовершенствования;
  • процесс обучения.

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

 

1.4. Конкретизация процесса

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

Таблица 1

Структура процессов

 

Класс

Процессы

Работы

Задачи

Основные

5

35

135

Вспомогательные

8

25

70

Организационные

4

14

27

Итого

17

74

232

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

  • Глагол «должны» (shall) используется для выражения соглашения между двумя или более сторонами.
  • Глагол «должна» (will) используется ля выражения объявления цели или намерения одной из сторон.
  • Глагол «следует» (should) используется для выражения рекомендации из имеющихся возможных вариантов.
  • Глагол «может» (may) используется для обозначения образа действий, допускаемого в рамках ограничений стандарта ИСО/МЭК 12207.

 

1.5. Процессы и проекты

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

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

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

 

1.6. Процессы и организации

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

Процессы, определяемые стандартом ИСО/МЭК 12207, образуют множество общего назначения, охватывающее различные организации. В зависимости от бизнес - целей организация (небольшая или крупная) может выбрать определенное подмножество процессов (и соответствующих работ и задач) для достижения своих целей. Стандарт может использоваться в рамках организации или при заключении договора двумя или более организациями. Для облегчения применения стандарта в рамках одной организации или при заключении договора задачи определяются на языке, принятом при заключении договора. При использовании в рамках организации язык, принятый при заключении договора, интерпретируется как автоматически вводимые задачи (self-imposed).

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

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

 

 

 

 

 

 

 

 

Рис.1.  Связь с существующими документами

Для уровня 1:

- входы и выходы не определены;

- работа выполняется в соответствии с объектами в каждом процессе.

Для уровня 2:

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

Для уровня 3:

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

- процедуры содержат методы решения проблем;

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



 
цифровых систем управления. управления въездом на стоянку. коммуникациямиКоммуникации