Курс лекций инструментальные средства. Конспект лекций
 Скачать 1.6 Mb.
|
|
Процесс управления конфигурацией Бесконтрольный доступ и изменение данных жизненного цикла ПО может привести к полной его остановке или потере всех созданных артефактов. Поэтому в любой жизненный цикл разработки надежного ПО обязательно должен входить процесс управления конфигурацией, контролирующий все то, что создается на всем протяжении жизненного цикла разработки ПО. Процесс управления конфигурации занимается идентификацией всех конфигурационных элементов, контролем их изменений и доступа, созданием базовых линий для отслеживания последующих модификаций; он осуществляет действия по оповещению, трассировке и коррекции проблем. Он также отвечает за архивацию и восстановление всех конфигурационных элементов, включая программное обеспечение. Процесс управления конфигурации начинается в тот момент, когда принято решение, что накопленные материалы, такие как чертежи, схемы, требования, любые другие документы, достаточны для начала процесса планирования. Этот процесс действует на всем протяжении жизненного цикла ПО в соответствии с разработанным планом. Стандарты DO178B/DO178С требуют, чтобы план управления конфигурации описывал: Какие инструменты используются для управления конфигурацией. Все типы контролируемых данных. Как данные будут храниться и выдаваться, например, выдача данных может осуществляться по интернету в зашифрованном виде. Как хранится и контролируется код, в том числе описание того, на каких физических носителях он хранится, как осуществляются процедуры резервного копирования и восстановления кода. Процесс обеспечения качества При разработке программного обеспечения всегда есть вероятность, что что-то идет не так, что какой-то из процессов, входящих в жизненный цикл, работает неправильно, и что есть расхождения с установленным планом. Процесс обеспечения качества занимается выявлением таких проблем. Надежное программное обеспечение нельзя создать, если в жизненный цикл его разработки не включен этот процесс. Процесс обеспечения качества должен отслеживать, что все процессы идут в соответствии с намеченными планами, что они выполняют все установленные цели, что требования стандартов соблюдаются, переходы между процессами осуществляются в соответствии с установленными критериями, все артефакты соответствуют установленной спецификации. При возникновении проблем во время жизненного цикла разработки процесс обеспечения качества должен гарантировать, что они будут рассмотрены и по ним будут приняты соответствующие решения, и в конечном итоге они будут разрешены. Процесс верификации оценивает деятельность всех процессов, входящих в жизненный цикл разработки, с помощь различных аудитов и ревизий. Результатами работы процесса являются его записи. Они содержат информацию об проведенных аудитах, записи о санкционированных отклонениях и записи, подтверждающие проведение ревизий. Процесс верификации проводится в соответствии с разработанным планом, который для критического ПО должен включать следующие описания: Окружение обеспечения качества, а именно: инструменты, процедуры, стандарты, в чем заключается обеспечение качества, как организован процесс обеспечения качества, и кто за что в нем отвечает и перед кем. Действия по обеспечению качества: аудиты, рапорты, инспекции, мониторинг, контроль процессов жизненного цикла, отслеживание запросов на изменение и проблемных рапортов, и их мониторинг. Критерии перехода для процесса обеспечения качества, контрольные списки того, что должно быть проверено. Частота и последовательность действий процесса обеспечения качества. Список всех данных, создаваемых за время работы процесса, например протоколы митингов, записи проверок, записи установленных отклонений от процессов. Ведение истории разработки программного обеспечения Любые действия, проводимые на всем протяжении жизненного цикла разработки ПО, должны быть отражены в соответствующих документах. Необходимо также хранить информацию, кем они были совершены, и результаты этих действий. Все артефакты, произведенные за время ЖЦ разработки, составляют ее историю. История продукта должна показать, как поэтапно было создано программное обеспечение, что это за программное обеспечение, зачем оно нужно, какие системные и функциональные требования были в нее заложены, как осуществлялся процесс ее создания, контроля и проверки, почему данная система является надежной, как это было доказано. Для критического программного обеспечения история создания ПО имеет очень важное значение, поскольку она может быть использована для расследования инцидентов, произошедших на системах, где это ПО было использовано. Может возникнуть ситуация, когда в суде нам придется рассказывать поэтапную работу над созданием нашего ПО и доказывать, что все что мы сделали, является правильным. Поэтому если задать вопрос авиационному сертифицирующему органу, какую информацию, какие данные и какие документы нужно хранить для сертификации программного обеспечения, они отвечают: все, что касается проекта и любых действий, проводимых в его рамках, включая даже и неформальную информацию, такую как мнения, обсуждения, записи переговоров и так далее. Для надежного ПО требование по хранению всей созданной за время разработки информации является чрезмерными. Но все, что непосредственно касается проекта, должно быть сохранено. Независимое проведение процедур проверки Для сертификации критического программного обеспечения стандарты DO178B/DO178С устанавливают 5 различных уровней безопасности ПО, от катастрофического, когда ошибочная работа программного обеспечения может привести к гибели людей, до уровня, когда ПО никак не может повлиять на безопасность полета. Сертификации ПО для разных уровней существенно отличается, и одним из основных отличий является то, как проходят процессы верификация и валидация. Чем выше уровень критичности ПО, тем выше требования к тому, чтобы процессы верификации и валидации на различных этапах разработки проводили люди, не имеющие прямого отношения к процессу разработки проверяемого ПО. Для сертификации на самые критические уровни безопасности требуется, чтобы всю верификацию и валидацию проводили только независимые от разработчика данного ПО люди. Для создания надежного программного обеспечения принцип независимости также имеет существенное значение. Необходимо, чтобы процедуру верификации и валидации результатов работы различных процессов (в том числе и тестирование) проводили люди, непосредственно не участвующие в их создании. Это не обязательно должны быть люди со стороны, из другой организации или компании. Это могут быть люди, входящие в команду разработки данного программного обеспечения, но не принимающие участие в создании того, что они проверяют. Тесты должны базироваться на требованиях Процесс верификации включает в себя процесс тестирования. Этот процесс является наиболее интенсивной частью процесса разработки. Тестирование, в свою очередь, делится на два процесса: определение теста, когда решается, что собой будет представлять тест, и выполнение теста. Обычно тестирование можно разделить на две части: неформальное тестирование, когда тестирование проводится самими разработчиками во время написания кода, и формальный процесс тестирования. Как правило, трудностей при создании неформальных тестов не возникает, поскольку сам программист знает, что и как нужно тестировать, но могут возникнуть сложности в определении тестовых процедур для формального тестирования. Стандарты DO178B/DO178С рекомендуют, чтобы тестовые процедуры были сфокусированы на требованиях. Каждая тестовая процедура должна адресоваться к определенному требованию или набору требований. Поэтому нельзя просто так добавить или убрать тестовую процедуру. В зависимости от того, на каких требованиях базируется тестирование, принято различить: Тестирование программно-аппаратной интеграции, когда верификация корректной работы ведется на целевом компьютере с целевым окружением. В этом случае идет проверка высокоуровневых требований. Тестирование программной интеграции, когда проверяется взаимодействие различных компонентов ПО. Цель этих тестов – проверка соответствия требованиям архитектуры и дизайна ПО. Низкоуровневое тестирование, когда ПО проверяется на соответствие низкоуровневым требованиям. Как и какое тестирование проводить, должно быть описано в плане верификации. Для разработки надежного ПО можно ограничится только тестовыми процедурами, проверяющими высокоуровневые требования. Но если возникает необходимость поднять уровень надежности, то нужно создать и тесты, базирующиеся на низкоуровневых требованиях. Так же, как и для критического ПО, процесс тестирования должен проходить в соответствии с разработанным планом. Тестирование должно включать не только нормальное тесты, но и тесты на устойчивость. Для безопасного и надежного программного обеспечения тестирования с использованием тестов, которые проверяют работу программы только в нормальных условиях, недостаточно. Необходимо также использовать тесты, которые проверяют программу на устойчивость, или так называемые робастные тесты. Основная цель этих тестов – убедиться, что ПО работает корректно: при установке неправильных инициализационных значений для переменных; при инициализации в ненормальных условиях; при сбойной модели входных данных; при использовании счетчиков цикла за пределами их ограничений; в сбойных режимах или режимах отказа; при неправильной работе программного окружения; при работе в стрессе по времени, памяти и синхронизации с другими программами; при работе в любых других условиях, отличных от нормальных. Обязательно должна быть проведена проверка корректности работы механизма защиты и работа ПО в переходных состояниях, если о них указано в требованиях. Хорошая восприимчивость к сбоям является одной из важнейших характеристик надежного программного обеспечения. Программное обеспечение должно ломаться "правильно" Надежное и безопасное программное обеспечение должно быть спроектировано так, чтобы при возникновении критической ситуации оно ломалось ”правильно”. Это означает не только, что компьютер не должен зависать или выдавать ошибку операционной системы, если в программном обеспечении возник сбой. Гораздо важнее, чтобы при возникновении сбоя пользователь знал, что ПО перестало работать. Если ПО выдает некоторые значения, то очень важно, чтобы разница между сбойным значением и реальным была большой, чтобы можно было легко заметить, что это ПО сломалось и не работает. Например, пусть у вас есть программа, которая в соответствующем приборе участвует в измерении давления у человека. Если эта программа сломается, то какое значение она должна показывать: нулевое, последнее измеренное давление, выше или ниже реального давления? Надежное и безопасное ПО должно выдавать такое значение, чтобы человек, измеряющий давление, мог однозначно понять, что прибор сломан. Если в приведенном примере прибор покажет ноль, то становится понятно, что он сломан и никакой большой проблемы здесь нет. Нужно просто использовать другой прибор. Серьезная проблема может возникнуть, если прибор при сбое покажет значение, близкое к реальному, но все же от него отличающееся. Это может привести к неправильным и даже опасным действиям, например к медикаментозному увеличению или уменьшению давления. Анализ тестового покрытия Анализ тестового покрытия является еще одним инструментом, помимо трассировки, базирующимся на требованиях к тестированию и позволяющим проверить, что код полностью соответствует заданным требованиям. Для критического ПО анализ тестового покрытия состоит из двух этапов: анализа покрытия тестов и анализа структурного покрытия. Первый из анализов проверяет, что для каждого требования, высокоуровневого или низкоуровневого, существуют свои нормальные и робастные тесты. В задачу анализа структурного покрытия входит нахождение кода, который не был протестирован ни одним из тестовых примеров. Как правило, для этого необходимо использовать специальные инструменты. Считается хорошим результатом, если структурное покрытие составляет 80%. То, что нельзя проверить инструментами, должно быть проверено анализом кода вручную. Если структуры кода не покрыты тестами, то это может происходить из-за: недостатков в тестовых процедурах; неадекватности требований; наличия ”мертвого”, не использованного кода; наличия деактивированного кода – кода, для которого есть требования, но он не выполняется при всех конфигурациях ПО. Для каждой ситуации должен быть план, что и как нужно делать. Обычно, если есть проблемы в тестовых процедурах или в требованиях, то их переделывают, мертвый код удаляют, а деактивированный код анализируют вручную. Для надежного ПО анализ тестового покрытия может производиться только для высокоуровневых требований. Можно также понизить требуемый процент покрытия кода или вообще не проводить структурное покрытие. Методика проведения анализа тестового покрытия должна быть оговорена на этапе планирования. Нельзя вносить изменения без соответствующего запроса При обнаружении ошибки в документе, требовании, коде или тестовой процедуре нельзя просто исправить ее. Неконтролируемое исправление может привести к еще большим проблемам, нежели первоначальная ошибка. Поэтом стандарты DO178B/DO178С требуют, чтобы все исправления осуществлялись только по запросу. Человек, обнаруживший ошибку, должен составить специальный рапорт на ошибку. Этот рапорт должен включать: уникальный идентификатор рапорта, чтобы за ним можно было проследить, описание проблемы, ее приоритет и возможные действия по ее устранению. Должно быть установлено, кто будет исправлять ошибку, и за какой срок. После исправления ошибки рапорт закрывается и проводится повторная верификация. Может оказаться так, что ошибся сам верификатор. В этом случае для закрытия рапорта нужно дать подробное объяснение, почему заявленная проблема не является ошибкой. Процесс сертификации может выйти на свою финальную стадию только если все рапорты об ошибках являются закрытыми. Весь механизм исправления ошибок прописывается в плане верификации. При разработке надежного ПО также очень важно, чтобы исправление ошибок во всех артефактах жизненного цикла было под контролем. Во время процесса планирования необходимо определить приемлемый механизм исправления ошибок. Любая другая команда, используя ваши артефакты, может воспроизвести ваш продукт Если программный продукт может быть воспроизведен только один раз или только определенной группой людей, то этот продукт не может считаться ни надежным, ни тем более безопасным. Весь процесс разработки необходимо организовать так, чтобы создаваемое ПО могло быть воспроизведено другими людьми. Прежде всего это касается качества документации. Документация разрабатываемого ПО должна быть такой, чтобы люди, не имеющие отношения к вашему проекту, могли понять, какие функции и как выполняет ваше ПО, что представляет собой весь процесс его разработки, какое программно-аппаратное окружение для него используется и как его можно заново воспроизвести. Для надежного и безопасного ПО должны быть созданы документы, в которых содержится: общий обзор программного обеспечения с описанием того, что оно делает; описание функций работы ПО и их влияние на надежность; описание модели жизненного цикла разработки и всех процессов, в него входящих; описание всех артефактов жизненного цикла; полное описание программно-аппаратного окружения; полное описание конфигурации программного продукта: версия, дата создания, описание всех компонентов, которые в него включены или используются, и так далее. информацию о том, кто за что отвечал на всем протяжении жизненного цикла; все планы, включая планы разработки, верификации, обеспечения качества, план управления конфигурации; ссылки на все стандарты; описание всех процедур верификации и валидации; записи всех верификационных действий и их результатов. Следует также иметь в виду и человеческий фактор. Может возникнуть ситуация, когда какой-то ключевой разработчик заболеет, по той или иной причине уйдет из команды разработчиков или вообще покинет компанию. Нужно организовать процесс разработки таким образом, чтобы это не повлияло или незначительно повлияло на весь процесс разработки и сроки его выполнения. Для этого рекомендуется весь процесс делать более формальным и менее зависимым от конкретных людей. 3.2 Функциональная методология IDEF0 Наиболее популярной методологией IDEF является методология IDEF0. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique – Техника структурного анализа и дизайна). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В России приняты официальные рекомендации по применению методологии IDEEF0. Целью методологии является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. Другими словами, в IDEF0 моделируемая система представляется как совокупность взаимосвязанных работ (функций, активностей). Методология IDEF0 получила столь широкое распространение в бизнес–моделировании потому, что эта методология легко представляет такие системные характеристики, как управление, обратная связь, исполнители. Кроме того, методология IDEF0 имеет развитые процедуры поддержки коллективной работы. В основе методологии лежат четыре основных понятия: функциональный блок, дуга (стрелка), декомпозиция, глоссарий. Функциональный блок, или работа (Activity Box)представляет собойнекоторую конкретную функцию ( работу) в рамках рассматриваемой системы. Блок должен иметь название в глагольном наклонении (например, "Проверить документ" или "Проверка документа"). На диаграмме функциональный блок изображается прямоугольником (рисунок 3.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль) и определяет тип интерфейса, т. е. способ взаимодействия дуги с блоком: верхняя сторона имеет значение "Управление" (Control); левая сторона имеет значение "Вход" (Input); правая сторона имеет значение "Выход (Output); нижняя сторона имеет значение "Механизм" (Mechanism). Дуга (Arrow)отображает элемент системы,который обрабатываетсяфункциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. С помощью дуг отображают различные объекты, которые передаются между блоками, обрабатываются блоками, определяют правила обработки и механизмы обработки . Такими объектами могут быть элементы реального мира (детали, вагоны , сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). Стрелки снабжаются надписями – названиями. В зависимости от того , к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей", "управляющей", "механизмом" или вызовом.  Рисунок 3.1 – Функциональный блок В IDEF0 различают пять типов стрелок. Вход (Input) –материальные объекты или информация,которые используются или преобразуются работой для получения результата (выхода). Допускается, что блок может не иметь ни одной стрелки входа. При описании технологических процессов не возникает проблем определения входов. Вход – это нечто, что перерабатывается в блоке для получения результата. При моделировании информационной системы, когда стрелками являются не физические объекты, а данные, определение входа может вызвать трудности. Например, чтобы показать переработку данных блоком, целесообразно на входе указать "Документ", а на выходе – "Заполненный документ". Например, не может быть входом блока " Прием экзамена" стрелка "Студент", а выходом – стрелка "Экзаменационная ведомость", т. к. студент не перерабатывается в ведомость. В данном примере можно использовать входную стрелку "Не аттестованный студент" и выходную стрелку "Аттестованный студент". Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются /изменяются ли данные в блоке или нет. Если изменяются, то, скорее всего, это вход, если нет – управление. Например, задание на курсовой проект является управлением, а не входом. Управление (Control) –правила,стратегии,процедуры,стандарты,ограничения на бюджет и время, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.Управление влияетна работу, но не преобразуется работой. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления. Выход (Output) – материальный объект или информация,которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Механизм (Mechanism) – ресурсы,которые выполняют работу,например персонал предприятия, станки, устройства и т. д. По усмотрению аналитика стрелки механизма могут не изображаться в модели. Вызов (Call) –специальная стрелка , указывающая на другую модель работы. Стрелка вызова используется при расщеплении модели и указывает, что некоторая работа представлена отдельной моделью. Расщепление моделей необходимо для коллективной работы над моделью. Руководитель проекта может создать декомпозицию верхнего уровня и провести расщепление модели на отдельные модели. Аналитики работают над отдельными моделями, а затем сливают отдельные модели в единую модель. Отдельная ветвь модели может быть отщеплена для использования в качестве независимой модели. Таким образом, любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую дугу и одну исходящую. То есть каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Декомпозиция (Decomposition)является основным понятием стандартаIDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Глоссарий (Glossary) –это набор соответствующих определений,ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор является описанием сущности данного элемента. Глоссарий дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Модель в методологииIDEF0 –это совокупность иерархически упорядоченных и взаимосвязанных диаграмм . Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Модель может содержать четыре типа диаграмм: Контекстная диаграмма,которая представляет всю систему какодин блок и показывает контекст системы, т. е. связь системы с внешним миром. Модель может иметь только одну контекстную диаграмму. Диаграммы декомпозиции,которые получаются в результате разбиения контекстной диаграммы на отдельные активности. Такой процесс называется функциональной декомпозицией, а диаграммы, получившиеся в результате декомпозиции, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы производится декомпозиция каждой получившейся диаграммы и т. д. Декомпозиция продолжается до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы –эксперты предметной области проверяют соответствие реальныхбизнес–процессов созданным диаграммам. Найденные несоответствия исправляются , и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес–процессам на каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Диаграммы дерева узлов показывают иерархическую зависимостьработ. То есть, в виде дерева показывается, какие активности получились в результате декомпозиции каждой активности. Диаграмм деревьев узлов может быть в модели несколько, поскольку дерево может быть построено на различную глубину и начиная с любой диаграммы (не обязательно с контекстной). Диаграммы только для экспозиции (FEO – for exposition only)строятся для иллюстрации альтернативной точки зрения, для хранения старых версий. FEO – это просто картинка. Дело в том, что методология не поддерживает альтернативные варианты декомпозиции. Если необходимо хоть как-то сохранить альтернативный вариант декомпозиции, то применяют диаграмму только для экспозиции. Рассмотрим подробнее различные виды диаграмм. Модель IDEF0 всегда начинается с представления системы как единого целого – одной активности с дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одной активностью называется контекстной диаграммой.Дуги контекстной диаграммы должны описывать всеосновные связи моделируемой системы с внешним миром. Методология IDEF0 подразумевает, что модель является не просто совокупностью диаграмм, а содержит всю необходимую информацию о моделируемой области. Информация о модели задается в свойствах модели. В BPWin информация задается в диалоге свойств модели (Model Properties). В общих свойствах (General) указываются имя модели, название проекта, автор модели временные рамки модели (Time Frame) – AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы –AS-IS(как есть).Анализ функциональной модели позволяет понять,где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес– процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес–процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) – модели новой организации бизнес–процессов. Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным . В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход – это тоже бизнес– процесс. Цель моделирования (Purpose)определяется из ответов на следующиевопросы: Почему этот процесс должен быть смоделирован? Что должна показывать модель? Что может получить клиент? Точка зрения (Viewpoint) – это перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Даются также определение модели (Definition) и описание области действия модели (Scope). Указываются источники получения данных о модели (Source), например, "Опрос экспертов предметной области и анализ документации". Статус модели (Status) – это рабочая версия (новая модель, не прошедшая экспертиз) – WORKING, черновой вариант (модель прошла первичную экспертизу) – DRAFT, рекомендовано (прошла экспертизу) – RECOM-MENDED, публикация (окончательный вариант) – PUBLICATION. Каждая активность может быть подвергнута декомпозиции на другой – "дочерней" диаграмме (Child Diagram). Каждая диаграмма нижнего уровня показывает "внутреннее" строение активности на родительской диаграмме (Parent Diagram). Каждая из активностей дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели. Чтобы сделать диаграммы удобочитаемыми, в стандарте IDEF0 приняты ограничения сложности: на диаграмме может быть от трех до шести активностей (в BPwin – от 2 до 8), при этом количество подходящих к одной активности и выходящих из одной активности дуг предполагается не более четырех. Работы на диаграммах декомпозиции обычно располагаются в так называемом порядке доминирования – по диагонали от левого верхнего угла к правому нижнему. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ. Все активности модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная активность имеет номер А0. Активности, полученные в результате декомпозиции контекстной активности номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской активности и очередной порядковый номер, например активности декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Активности образуют иерархию, где каждая активность может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы – номер А0, остальные диаграммы декомпозиции – номера по соответствующему узлу (например, Al, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. Чтобы отличать различные версии одной и той же диаграммы, используется специальный номер – C-number, который должен присваиваться автором модели вручную. C-number – это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем, в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например GVI021. Если активность не повергалась декомпозиции, то левый верхний угол прямоугольника активности автоматически перечеркивается. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.Граничные стрелки мигрируют(переносятся)из родительскойдиаграммы в дочернюю диаграмму. Границы дочерней диаграммы соответствуют границам декомпозируемой активности. Поэтому входные стрелки располагаются на левой границе диаграммы декомпозиции и т. п. Для большего удобства граничные стрелки могут снабжаться так называемыми |