Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Дэвид Марка book

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

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

10.6. Резюме

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

Дополнительная литература:

Cohen, G.: "A New Way to Test Writing", 22nd International Technical Communications Conference, 1975.

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and G. Weinberg: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Freedman, D., and G. Weinberg: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Hale, R.: "Inspections in Application Development - Introduction and Implementation Guidelines", IBM Report TNL GN20-3814, August 1978.

IBM: "Code Reading, Structured Walkthroughs, and Inspections", IBM Report GE-19- 5200, 1976.

Kohli, R.: "High Level Design Inspection Specification", IBM Report TR21.601, July

1975.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1977.

91

Глава 11. Соглашения по построению диаграмм

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

11.1. Соглашения по размещению блоков

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

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

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

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

92

11.2. Соглашения по размещению дуг

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

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

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

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

93

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

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

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

11.3. Соглашения по размещению блоков и дуг

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

94

11.4. Резюме

Соглашения по размещению элементов SADT-диаграмм строго следуют схеме вычерчивания сверху вниз и слева направо. Блоки обычно располагают по ступенчатой схеме; дуги подходят к блокам под прямым углом. Расстояния между дугами сохраняются максимальными, и они всегда одинаковы. Когда несколько дуг однородной природы идут из одного блока в другой, они часто объединяются в единую дугуОбратные связи по управлению всегда чертят "вверх и над". Циклические обратные связи изображаются редко.

Дополнительная литература

Cohen, G.: "A New Way to Test Writing", 22nd International Technical Communications Conference, 1975.

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Hale, R.: "Inspections in Application Development - Introduction and Implementation Guidelines", IBM Report TNL GN20-3814, August 1978.

IBM: "Code Reading, Structured Walkthroughs, and Inspections", IBM Report GE-19-5200, 1976.

Kohli, R.: "High Level Design Inspection Specification", IBM Report TR21.601, July 1975.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1977.

97

Часть III Рецензирование диаграмм и моделей

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

Основные этапы цикла автор/читатель изложены в пяти главах. В главе 12 дан общий обзор процесса рецензирования. В главе 13 приведено определение SADT-папки и описаны методы ее формирования. В главе 14 показано как нужно читать папки, что необходимо делать всем, кто работает над SADT-проектом. В главе 15 показано, как должен читатель записывать свои замечания, пожелания и сообщения, возникающие в процессе чтения материалов папки. В главе 16 обсуждаются ответы автора на замечания рецензентов и их обобщения. На протяжении этих глав полностью прослеживается цикл автор/читатель на примере папки, содержащей некоторую часть материалов модели экспериментального механического цеха. В процессе изложения иллюстрируется: (1) как на титульном листе папки отмечается ее продвижение по циклу автор/читатель,

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

98

Глава 12. Цикл автор/читатель

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

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

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

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

12.1. Составление исходной документации

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

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

99

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

Рис. 12-1. Процесс проверки модели в SADT

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

12.2. Комментирование работы

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

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

100