методы
разработки
систем
ЯЯШ
от
стратегического
планирования
до тестирования

Структурные
методы
разработки
систем:
от
стратегического
планирования
до тестирования

Structured
Systems
Development
Techniques:
Strategic
Planning
to System Testing
Garfield Collins
BIS Applied Systems Ltd
Gillian Blay
BIS Applied Systems Ltd
Consultant editor:
Ronald Yearsley
(BIS Applied Systems Ltd)
Pitman

ГКоллинз
Дж.Блэй
Структурные
методы
разработки
систем:
ОТ
стратегического
планирования
до тестирования
Перевод с английского
А.А. АЛЕКСАНДРОВА и В.Г. ЛУКИЧЕВА
Под редакцией В.М. САВИНКОВА
Москва
Финансы и статистика
1986

ББК 32.973
К60
Коллинз Г., Блэй Дж.
К60 Структурные методы разработки систем:
от стратегического планирования до тестирования.
Пер. с англ. / Под ред. и с предисл. В. М. Савинко¬
ва.— М.: Финансы и статистика, 1986. — 264 с.: ил.
В работе английских авторов описывается полный набор совме¬
стимых методов разработки информационных систем широкого на¬
значения, сформирована целостная технология проектирования, охва¬
тывающая весь процесс — от стратегического планирования до тести¬
рования.
Для специалистов в области применения вычислительной техни¬
ки, аспирантов и студентов вузов.
2405000000—117
К 	 131—86	ББК	32.973
010(01)—86
Научное издание
Гарфилд Коллинз, Джиллиан Блэй
СТРУКТУРНЫЕ МЕТОДЫ РАЗРАБОТКИ СИСТЕМ:
ОТ СТРАТЕГИЧЕСКОГО ПЛАНИРОВАНИЯ ДО ТЕСТИРОВАНИЯ
Книга одобрена на заседании секции редсовета
по электронной обработке данных в экономике 30.05.84 г.
Зав. редакцией К. В. Коробов. Редактор Н. К. Логинова
Мл. редакторы О. Г. Виноградова, 3. Ф. Кормилицына
Худож. редактор Ю. И. Артюхов. Техн. редактор И. В. Завгородняя
Корректоры Г. А. Башарина, И. П. Сперанская и Т. Г. Кочеткова
Переплет художника С. И. Валдаева
ИБ № 1772
Сдано в набор 3.06.86. Подписано в печать 5.09.86.
Формат 70X 100!/i6. Бум. офсетная № 2. Гарнитура «Литературная».
Печать офсетная. Уел. п. л. 21,45. Уел. кр.-отт. 21,45. Уч.-изд. л. 21,26.
Тираж 15 000 экз. Заказ 1783. Цена 1 р. 60 к.
Издательство «Финансы и статистика», 101000, Москва,
ул. Чернышевского, 7.
Московская типография № 4 Союзполиграфпрома
при Государственном комитете СССР
по делам издательств, полиграфии и книжной торговли.
129041, Москва, Б. Переяславская, 46
(С) Garfield Collins and Gillian Blay 1982
© Перевод на русский язык, предисловие,
примечания, «Финансы и статистика», 1986

Предисловие к русскому изданию
Средства вычислительной техники (СВТ) с начала 70-х годов игра¬
ют важную роль в автоматизации производственных процессов и науч¬
ных исследованиях, совершенствовании управления социалистической
экономикой. Они являются неотъемлемой составляющей научно-техни¬
ческого прогресса в нашей стране. За эти годы произошли глубокие ка¬
чественные изменения как в самих СВТ, так и в формах и методах их
применения. Стало очевидным, что необходимо рассматривать возни¬
кающие проблемы управления отраслью промышленности, предприяти¬
ем, технологическим процессом, научными исследованиями в неразрыв¬
ной связи с оптимальными формами и методами использования СВТ и
их программного обеспечения. Нарушение такого единства тормозит
повышение эффективности народного хозяйства в целом.
В настоящее время резко возрастают требования к качеству инфор¬
мационных систем (ИС), предоставляющих достоверную и полную ин¬
формацию административным и научным работникам, а также всем, кто
связан с управлением хозяйственной деятельностью предприятий и уч¬
реждений. Требования к методам проектирования и создания автомати¬
зированных систем, технологии управления проектом, оценки самого
проекта, организации взаимодействия подсистем и этапов разработки
максимально сближаются с требованиями к техническим производст¬
венным системам. Достижению этой цели и посвящена предлагаемая
советскому читателю книга Г. Коллинза и Дж. Блэй «Структурные ме¬
тоды разработки систем: от стратегического планирования до тестиро¬
вания». В книге приводится полный комплекс совместимых методов
разработки ИС общего назначения, излагается технология процесса про¬
ектирования от стратегического планирования таких систем до тести¬
рования законченной разработки.
В нашей стране уже созданы и успешно функционируют свыше че¬
тырех тысяч автоматизированных систем управления. Специалисты
располагают различными общеотраслевыми и другими руководящими
методическими материалами и стандартами, регламентирующими раз¬
работку таких систем. Невольно возникает вопрос: чем же тогда может
быть полезна данная книга?
Прежде всего книга Г. Коллинза и Дж. Блэй построена на основе
информационных методов, составляющих инструментарий системы
Modus (разработка фирмы BIS Applied Systems Ltd). В рамках этой си¬
стемы проектирование ИС пока еще не может считаться полностью фор¬
мализованным (скорее всего, общая теория автоматизированных систем
управления, подобных ИС рассматриваемого в книге класса, будет фор¬
мироваться с заметным опаздыванием). Но уже сегодня возможно соз¬
дание и эффективное применение систем, аналогичных Modus, на осно¬
ве опыта проектирования различных автоматизированных систем управ¬
ления в нашей стране. И в этом основное назначение книги.
5

Главное содержание книги — методы разработки проекта ИС. Уже
первый из них—анализ реализуемости — необычен априорными требо¬
ваниями к разнообразию таких ресурсов, как технические и программ¬
ные средства. Этап анализа реализуемости должен следовать за эта¬
пом общего стратегического планирования разработки системы, когда
оценены и сопоставлены с планом вовлекаемые в разработку ресурсы
(обязательно со всеми техническими средствами). Стратегический план
разработки включает в качестве возможной альтернативы даже ее пре¬
кращение после создания опытного образца системы. Авторы отмечают,
что на практике, если выбор оптимального технического решения не
состоялся на этапе анализа реализуемости, то, скорее всего, он не бу¬
дет сделан никогда.
Комплексность и интеграция методов разработки проекта ИС имеют
первостепенное значение. После обоснования целесообразности реали¬
зации проекта должен быть выполнен его системный анализ. Предла¬
гаемые компоненты системного анализа — формирование первоначаль¬
ного плана, обследование, подготовка эскизного проекта, анализ данных
и т. п. — хорошо известны специалистам. В процессе системного анали¬
за должны быть сформулированы и уточнены информационные потреб¬
ности пользователей, выраженные в терминах их основной деятельно¬
сти, и выделены те требования, которые могут быть удовлетворены в ре¬
зультате создания ИС. При этом выявляются недостатки действующей
системы обработки данных, определяются необходимые изменения, а
затем специфицируются все основные характеристики новой системы.
Наиболее важным этапом разработки ИС является проектирование
системы, объединяющее анализ, программирование и эксплуатацию.
Как обычно, понятия предметной области (административно-управлен¬
ческой сферы) не всегда известны программистам и операторам, а тех¬
ническая терминология, непонятна системным аналитикам и пользова¬
телям. Поэтому авторы делят проект ИС на два главных компонента:
логический проект, моделирующий предметную область, и технический
проект, реализующий эту модель.
Авторы книги последовательно проводят принцип декомпозиции про¬
екта на некоторое число задач, поддающихся простой проверке. Соот¬
ветствие получаемых при разбиении компонентов функциям предметной
области ИС дает пользователям возможность плодотворно участвовать
в разработке системы. И в отношении данных в книге выдерживается
тот же принцип: декомпозиция данных на простейшие компоненты и
выявление взаимосвязей между ними. К такому результату можно
прийти только после анализа, проверки и документирования всех дан¬
ных ИС, когда для каждой группировки данных определена зависящая
от нее функция в системе, а для каждого элемента данных указаны его
источники. Таким образом должны быть определены все входы и вы¬
ходы системы, которые не могут произвольно изменяться разработчиком.
Информационная система должна облегчить работу пользователей, и
прежде всего операторов терминалов. Для проектирования интерфей¬
сов пользователей с системой авторами введено понятие транзакции как
логической единицы работы с точки зрения оператора терминала. Тран¬
закция может быть разделена на несколько операций, включая обра¬
щение к ЭВМ. Отдельные обращения проектируются как пары сообще¬
ний или единицы обмена между оператором терминала и ЭВМ.
В методике предусмотрена наглядная схема проектирования логических
путей или «профилей» транзакций, представленная в виде операционных
диаграмм.
6

Не останавливаясь подробно на описании процесса проектирования
системы, отметим лишь еще две его характерные особенности: итера¬
тивность и структурный характер. Первая особенность позволяет прово¬
дить уточнения проекта (а следовательно, и реализацию новых требо¬
ваний) на всех этапах, вторая же лежит в основе выполняемой при
проектировании декомпозиции процессов и данных. Именно структур¬
ный метод обеспечивает организацию эффективного взаимодействия
прикладных программ как с файлами, так и с базами данных в систе¬
мах реального времени, т. е. при обработке транзакций, поступающих
с терминальных устройств.
Этап программирования включает проектирование, составление и
отладку программ. Авторы сумели в сжатой и наглядной форме изло¬
жить современный взгляд на программирование при соблюдении един¬
ства известных научных подходов и практического опыта разработок
ИС. Основополагающие идеи структурного программирования, метод
проектирования программ по принципу «сверху вниз» и многое другое,
без чего невозможно представить сегодня работу коллективов профес¬
сиональных программистов — все это, вместе взятое, впервые включено
в методическое пособие по проектированию ИС. Речь идет, по существу,
об универсализации программирования, составляющего важнейшую
часть методики проектирования ИС.
После завершения программирования ИС уже практически подго¬
товлена к следующему этапу — тестированию. На этом этапе проекти¬
ровщик убеждается в надежном и эффективном функционировании си¬
стемы, а пользователь — в удовлетворении его требований. Поскольку
тестирование системы часто так же трудоемко, как и разработка, авто¬
ры рекомендуют выполнять подготовительные работы к испытаниям на
всех этапах проектирования ИС, а само тестирование ИС выполнять с
участием группы эксплуатации с тем, чтобы можно было проверить и
процедуры обслуживания.
Этап тестирования представляется неотъемлемой частью проекта.
ИС подвергается проверке по методу «черного ящика» (на соответствие
получаемых выходных данных заданным входным данным). По резуль¬
татам тестирования разработчики получают возможность подготовить¬
ся к приемо-сдаточным испытаниям ИС. Наиболее трудоемкой опера¬
цией на этом этапе считается подготовка тестовых данных. Авторы кни¬
ги для подготовки тестовых данных рекомендуют самые различные ме¬
тоды— от их генерации до извлечения из существующих файлов. И на¬
конец, при тестировании определяются реальные эксплуатационные ха¬
рактеристики системы.
Все рассматриваемые методы детализированы в книге до соответст¬
вующих процедур, формирующих целостное представление о процессе
создания ИС.
Книгу Г. Коллинза и Дж. Блэй, несомненно, можно рекомендовать
как хорошее практическое пособие всем, кто профессионально занимает¬
ся разработкой ИС в нашей стране. Она может быть полезна специ¬
алистам в области автоматизированных систем, желающим повысить
свою квалификацию, а также студентам и аспирантам вузов соответст¬
вующих специальностей.
В. М. Савинков

Предисловие
Современная информационная технология предоставляет широкий
выбор способов реализации систем. В свою очередь многообразие при¬
кладных задач обусловливает необходимость интеграции данных и тех¬
нологии их обработки. Потребителям предлагаются сегодня самые раз¬
личные методы и средства проектирования. К сожалению, эти методы
не отличаются полнотой и не систематизированы: как правило, они не
гарантируют сквозной поддержки всех этапов проектирования, а мето¬
ды, позволяющие выполнять отдельные фазы проекта, не согласованы
между собой.
В книге сделана попытка представить полный комплекс методов,
обеспечивающих процесс разработки системы от стратегического плани¬
рования до тестирования. Методы изложены достаточно детально с тем,
чтобы читатель смог хорошо уяснить их и применить на практике.
Мы выражаем глубокую признательность всем, кто оказал нам по¬
мощь в работе над книгой: сотрудникам фирмы BIS Applied Systems
Limited, владеющей правами на неоднократно упоминаемые в книге ме¬
тоды проектирования, предложенные в системе Modus, и в частности
Д. Броутону, П. Эглтоуну, П. Селларсу и Р. Уэлтону, давшим много
полезных замечаний по книге, С. Холмвуду и Б. Келли, высказавшим
ряд ценных идей по ’ стратегическому планированию, Р. Борнхему,
Д. Бордету, Р. Скарсбруку и М. Вуду, разрабатывавшим методы, о ко¬
торых пойдет речь.
Мы приносим также благодарность нашим коллегам, помогавшим
нам в подготовке иллюстраций и редактировании рукописи на компь¬
ютере.
Ноябрь, 1981
Г. Коллинз
Дж. Блэй

Часть 1.
Основные концепции и обзор
методов разработки
Глава 1
Общие сведения
В настоящей главе приводится общий обзор методов, применяемых
при создании информационных систем (ИС). В конце главы читатель
знакомится с расположением материала в книге.
1.1.	Практика применения методов разработки ИС
Конкретные способы планирования, разработки и эксплуатации ИС
могут существенно различаться. Ряд организаций не придерживается
формализованных методов. В результате создаваемые ИС часто не со¬
ответствуют нуждам потребителей информации, неоправданно дороги и
вводятся в действие с большим запозданием, а после внедрения возни¬
кают серьезные проблемы в связи с сопровождением системы. Указан¬
ные издержки проектирования обусловлены нечетким распределением
обязанностей между разработчиками и слишком поздним выявлением
неудачных решений.
Многие организации располагают нормативной документацией, рег¬
ламентирующей разработку ИС, но, к сожалению, имеющиеся методы,
как правило, несовременны, непопулярны среди разработчиков и редко
находят практическое применение.
Для правильного использования достижений современной информа¬
ционной технологии (систем баз данных, распределенной обработки и
сетей ЭВМ) необходимо тщательно планировать весь процесс создания
ИС, поскольку принятие необоснованных технологических решений мо¬
жет повлечь за собой полное перепроектирование системы. Нередко
такая ситуация складывается в ходе реализации второго или третьего
проекта ИС — и все сделанное ранее сводится на нет.
За последние годы в распоряжение администрации службы обработ¬
ки данных (ОД) было предоставлено несколько новых методов проек¬
тирования ИС. Однако несмотря на очевидные достоинства этих мето¬
дов, в ряде организаций они не дали желаемого результата, поскольку
применялись не по назначению. Так, методы структурного программиро¬
вания вряд ли могут помочь в решении задач общего планирования ИС.
В то же время, если упущения в планировании ИС будут обнаружены
на стадии программирования, вполне вероятно, что новый метод помо¬
жет выявить и решить проблемы разработки программ.
Сегодня ощущается реальная потребность в целом комплексе мето¬
дов, поддерживающих все аспекты создания ИС, причем методы решения
частных задач должны быть взаимно увязаны в сквозную технологиче¬
9

скую схему разработки системы. Только на этой основе можно согласо¬
вать различные точки зрения участников проекта и рационально ис¬
пользовать кадровые ресурсы, а также организовать своевременное
обучение персонала и эффективно контролировать получаемые проект¬
ные решения.
При работе над книгой авторы стремились систематизировать преж¬
де всего методы разработки ИС. В то же время на протяжении всего
изложения прослеживается связь этих методов с другими аспектами уп¬
равления ИС. С точки зрения разработки системы рассматриваемые
здесь методы представляются полностью преемственными и согласован¬
ными.
Конечно, может показаться странным, что в сфере обработки дан¬
ных, где основное внимание всегда уделялось созданию хороших ИС
для конечных пользователей, возникает необходимость в стройной си¬
стеме, обеспечивающей их разработку и эксплуатацию.
В других областях (инженерной) деятельности вопрос о несогласо¬
ванности или недостатке методов проектирования так остро не ставит¬
ся. В самом деле, фирма, получившая заказ на создание нового произ¬
водственного комплекса, скорее всего, располагает конкретными мето¬
дами проектирования и управления разработкой. Не вызывает проблем
и качество нормативно-технической документации, а также оценка про¬
ектных решений. Методы разработки ИС должны обладать аналогичны¬
ми характеристиками. Не менее важно обеспечить и высокое качество
документации на проектируемую систему, поскольку основной результат
труда разработчиков — «бумага»: планы, сметы, схемы, спецификации,
инструкции по эксплуатации и т. д.
1.2.	Краткое содержание книги
В книге представлен весь комплекс инструментальных методов, при¬
меняемых при разработке ИС, в широком контексте проблем управле¬
ния информационными системами. Кроме того, здесь описываются и от¬
дельные методы управления, наиболее тесно связанные с разработкой
систем.
Предполагается, что читатель знаком с основами машинной обра¬
ботки данных. Книга адресована администрации службы ОД, заинтере¬
сованной в совершенствовании методов проектирования систем, а так¬
же разработчикам, желающим углубить свои знания по частным ме¬
тодикам, уже применяемым ими на практике и известным по фирменной
документации.
Поскольку разработчики могут участвовать в оценке и выборе кон¬
кретных методик, полезно кратко сформулировать исходные требова¬
ния, выбрав какой-либо набор методов в качестве модели.
Книга не претендует на роль детального руководства по проектиро¬
ванию ИС. В ней опущены многие детали, например применяемые фор¬
мы документов, техника проведения опросов и собеседований с заказ¬
чиком. Авторы ставили перед собой другую задачу — дать исчерпыва¬
ющее представление о назначении и существе рассматриваемых
методов. Поэтому наряду с конкретными правилами в книге приводит¬
ся целый ряд практических примеров по использованию методов. Ква¬
лифицированные специалисты с помощью предлагаемых материалов,
вероятно, смогут выработать собственный подход к разработке ИС и
соответствующие нормативные документы. При этом следует помнить
о принципе преемственности и согласованности частных методик, упо¬
мянутом выше.
10

Администрации службы ОД для получения общего представления
о методах разработки ИС мы рекомендуем обратиться сначала к гла¬
вам, указанным на рис. 1.1, а затем к гл. 5—9, где рассматривается
применение описываемых методов. Прежде чем приступить к реализа¬
ции конкретных методов, следует подробно изучить содержание соот¬
ветствующего этапа разработки. Например, руководству отдела про¬
граммного обеспечения целесообразно прочесть гл. 8.
Номер
Содержание
главы
1
Общие сведения
2
Стратегия разработки ИС
3
Обзор методов разработки ИС
4
Применение структурных методов
10
Послесловие к разработке систем
18
Управление проектом
Рис. 1.1. Рекомендуемая последовательность изучения материала для получения об¬
щего представления о методах разработки ИС
Разработчикам, для которых важны именно детали, мы предлагаем
иной порядок ознакомления с методами проектирования ИС (рис. 1.2).
Частные методики, упоминаемые в основном тексте, рассмотрены в
гл. 11 —18. Рекомендации по их изучению даются в процессе изложения
материала.
Номер главы	Содержание
1	Общие сведения
3	Обзор методов разработки ИС
В следующих главах описаны конкретные этапы проектирования (в скобках указа¬
ны главы, где рассмотрены процедуры, применяемые на этих этапах):
5	Анализ реализуемости разработки	ИС	(11,	12, 13, 16, 17, 18)
6	Системный анализ (И, 12, 13, 15,	16,	17,	18)
7	Проектирование системы (13, 14, 15, 16, 17, 18)
8	Программирование (14, 17, 18)
9	Тестирование
Главы, освещающие смежные этапы проектирования (без указания применяемых
процедур)
10	Послесловие к разработке систем
4	Применение структурных методов
Рис. 1.2. Порядок детального ознакомления с методами разработки ИС
Читатель может использовать настоящую книгу и в качестве спра¬
вочника по проектированию ИС. С этой целью в разд. 1.3 показана
связь отдельных глав с конкретными аспектами разработки.
1.3.	Обзор методов, применяемых при создании ИС
Графическое представление. Рассматриваемые в книге методы мож¬
но представлять с помощью диаграмм, подобных приведенной на
рис. 1.3. Это так называемые операционные диаграммы, на которых по¬
казана декомпозиция отдельной задачи (функции) на составляющие.
Различают диаграммы верхнего и нескольких нижних уровней, харак¬
теризующихся большей степенью детализации. В частности, на диа¬
граммах нижнего уровня показаны связи функций и используемых
данных.

УПРАВЛЕНИЕ
ИНФОРМАЦИОННЫМИ
СИСТЕМАМИ
И ДАННЫМИ
12
Рис. 1.3. Схема системы Modus

Планирование. Любая организация в какой-то мере планирует ос¬
новные направления своей деятельности. План работы организации
служит отправной точкой при определении общих требований к ИС. Он
же лежит в основе всех этапов реализации такой системы, представ¬
ленных на диаграмме (рис. 1.3). Эта диаграмма заимствована из доку¬
ментации к инструментальной системе разработки ИС Modus фирмы
BIS Applied Systems Ltd, в основу которой положен ряд хорошо согла¬
сованных методов. Их краткое описание приводится ниже.
Стратегия разработки ИС. Стратегия разработки ИС формируется
на этапе общего планирования, выполняемого отделом системного про¬
ектирования. В ходе планирования определяется, какие системы долж¬
ны быть разработаны и каковы наиболее эффективные технологические
решения, а также оцениваются потребности в кадровых ресурсах. Мож¬
но выделить четыре направления общего планирования ИС:
• анализ основных функциональных областей деятельности органи¬
зации с целью выявления возможных информационных систем и их вза¬
имосвязей;
• выбор основных технологических решений для реализации новых
ИС и обеспечения эксплуатации разработанных систем;
• идентификация главных проектов, установление последовательно¬
сти их реализации и оценка необходимых для этого ресурсов; при ана¬
лизе реализуемости общего плана и расчете требуемых ресурсов, веро¬
ятно, придется провести дополнительные исследования;
• оценка общих трудозатрат.
Выделение ресурсов и контроль их использования. Подразделение
обработки данных (как и любое другое подразделение) может успешно
функционировать только в том случае, если ему выделяются необходи¬
мые ресурсы и осуществляется контроль их использования. Поэтому не¬
обходимо прежде всего правильно оценить потребности в тех или иных
ресурсах, добиться их выделения и организовать эффективный контроль
использования полученных ресурсов в соответствии с текущими и перс¬
пективными планами, а при значительных отклонениях от планов —
принять необходимые меры. С этой точки зрения главными представля¬
ются следующие задачи:
• выбор (разработка) методик выполнения всех проектных работ;
• критический анализ краткосрочных и перспективных планов в со¬
ответствии с принятой стратегией разработки ИС;
• детальная оценка необходимых ресурсов и планирование их ис¬
пользования;
• составление и согласование смет;
• получение основных программных и технических средств и комп¬
лектование штата;
• организация обучения персонала;
• контроль трудозатрат и использования машинных ресурсов в под¬
разделениях разработки и эксплуатации ИС;
• организация службы администрации данных.
Управление разработкой. После одобрения проекта и утверждения
сметы необходимо организовать управление разработкой, основу кото¬
рого составляет поэтапный подход, предусматривающий в частности:
• планирование и контроль трудозатрат на разработку;
• контроль качества проектных решений;
• подготовка отчетов руководству о ходе разработки;
• пересмотр целевых установок при нехватке тех или иных ресурсов;
• периодический анализ возможности успешного завершения про¬
екта;
13

• официальное утверждение результатов каждого этапа проектиро¬
вания.
Ответственность за управление разработкой ИС возлагается совме¬
стно на руководство службы ОД и руководство подразделений-заказчи-
ков. При этом утверждение корректировок исходных требований на си¬
стему, обусловленных значительными отклонениями от плана, должно
оставаться за заказчиком.
Разработка и ввод системы в опытную эксплуатацию. Как отмеча¬
лось выше, ИС должна разрабатываться поэтапно. За начальные этапы
(от анализа реализуемости до тестирования системы) отвечает в основ¬
ном отдел проектирования. По завершении тестирования к проекту все
шире привлекаются другие подразделения: служба эксплуатации и под¬
разделения-пользователи. Полученные в результате проектирования ре¬
шения должны подвергаться критическому анализу, главная цель кото¬
рого— выявить, не нарушены ли ограничения, накладываемые имеющи¬
мися техническими и программными средствами. Результаты опытной
эксплуатации следует оформить документально. Эти документы помогут
определить необходимые изменения в системе и пригодятся при реали¬
зации новых проектов. Аналогичный подход рекомендуется и при раз¬
работке отдельных прикладных программ или средств обслуживания,
например программ поддержки базы данных. При этом решаются сле¬
дующие задачи:
• выявление альтернативных решений и поиск наилучшего в рам¬
ках ограничений, накладываемых общим планом создания ИС;
• реализация поэтапного подхода к разработке системы;
• тщательное тестирование системы перед вводом ее в опытную экс¬
плуатацию;
• привлечение пользователей и других подразделений к участию в
разработке системы;
• организация управления разработкой;
• реализация системы;
• исследование результатов опытной эксплуатации.
Более подробно эти и смежные вопросы рассматриваются в гл. 3.
Промышленная эксплуатация. При промышленной эксплуатации ИС
одновременно решается несколько задач, преследующих единую цель:
обеспечить нормальное функционирование системы и предоставить поль¬
зователям необходимые услуги. Для этого нужно организовать обслу¬
живание технических средств и сопровождение системного и прикладно¬
го программного обеспечения. Время от времени следует замерять и
анализировать операционные характеристики системы с тем, чтобы
установить, не требуется ли смена или настройка технических средств.
В службе эксплуатации создаются подразделения технических средств
и программного обеспечения, на которые возлагаются следующие обя¬
занности:
• выбор, установка и сопровождение системных программных
средств (причем основные средства такого рода нужно выбрать за¬
ранее) ;
• выбор, установка и обслуживание оборудования ЭВМ;
• сопровождение прикладных систем в части устранения ошибок, на¬
рушающих их нормальное функционирование (развитие систем —
самостоятельная задача);
• планирование и организация вычислительного процесса;
• обеспечение безопасности данных при эксплуатации ИС;
• измерение операционных характеристик системы.
14

1.4.	Расположение материала в книге
Вопросы, освещаемые в книге, указаны на рис. 1.3 в прямоугольни¬
ках, выделенных жирными линиями. Поскольку проблемы разработки
методов управления ИС отражены лишь частично, соответствующие им
прямоугольники изображены пунктиром.
На этом рисунке показано также, в каких главах книги можно озна¬
комиться с теми или иными аспектами управления ИС: рядом с прямо¬
угольником указывается номер нужной главы. Если номер главы не
отмечен, то подразумевается, что весь материал рассмотрен в данной
главе.
Гл. 3 посвящена разработке и вводу системы в эксплуатацию (опе¬
рация 4 на рис. 1.3).
Глава 2
Стратегия разработки ИС
2.1.	Введение
Основной предмет рассмотрения настоящей главы составляют мето¬
ды разработки систем, позволяющие создавать функциональные ИС,
повысить их экономичность и обеспечить высокие эксплуатационные ха¬
рактеристики. Однако эти методы применимы только к индивидуаль¬
ным проектам. Вопросы распределения приоритетов между проектами
и выбора конфигурации технических средств выходят за рамки данной
книги.
Для успешной разработки ИС в организации должен существовать
план, согласно которому ресурсами обеспечиваются наиболее эффек¬
тивные проекты. Должна быть также продумана разумная последова¬
тельность реализации взаимосвязанных систем. До начала разработки
систем, разделяющих одни и те же ресурсы (ЭВМ или базы данных),
необходимо создать единую техническую базу. Это даст возможность
избежать дорогостоящего перепроектирования при внедрении новых
систем.
Все сомнения в целесообразности применения той или иной техноло¬
гии должны быть разрешены на ранних стадиях проекта, до выделения
основных средств. Кроме того, потребности в кадровых и машинных
ресурсах следует определить прежде, чем будет сформирован план реа¬
лизации ИС.
Перечисленные требования настолько существенны, что их анализ
предшествует описанию методов разработки.
Вообще говоря, планированию разработки информационной системы
должно предшествовать исследование основных направлений деятельно¬
сти организации, в результате которого определяются ее главные задачи
и могут быть пересмотрены как способы реализации тех или иных функ¬
ций, так и сферы деятельности, номенклатура выпускаемой продукции,
виды предоставляемых услуг и т. п. Этот аспект общего планирования
систем в настоящей главе не рассматривается.
Здесь речь пойдет, главным образом, о планировании собственно
системы, причем предполагается, что анализ основных направлений
деятельности организации завершен. Мы рассмотрим, как планируются
информационные системы, наилучшим образом отвечающие перспектив¬
ным потребностям организации, и как планируется выделение кадровых
и машинных ресурсов на их разработку.
15

Предполагается, что читатель знаком с операционными диаграмма¬
ми, анализом ключевых факторов эффективности и анализом данных,
однако для первого ознакомления с материалом эти сведения не обя¬
зательны.
2.2.	Характер деятельности организаций
Характер основной деятельности организации в значительной степе¬
ни определяет подход, применяемый этой организацией при планирова¬
нии. (Под организацией здесь следует понимать либо промышленное
или торговое предприятие, либо государственное учреждение.) Если
планирование не ведется, дальнейшее обсуждение теряет смысл. Боль¬
шинство организаций в какой-то мере планирует свою работу, но даже
при отсутствии обобщенного представления об информационных потреб¬
ностях администрация службы ОД может планировать разработку ИС
самостоятельно.
Существуют организации самых различных типов, но с точки зрения
информационной технологии наибольший интерес представляют лишь
несколько из них.
Прежде всего здесь следует назвать организации, поставляющие оп¬
ределенный набор сходных изделий или предоставляющие комплекс
каких-либо услуг некоторой группе клиентов. Примерами могут слу¬
жить автозавод, реализующий свою продукцию через посредников, и
больница, обслуживающая пациентов. В подобных организациях, без¬
условно, может быть разработана единая стратегия реализации ИС, и
именно к ним в первую очередь относятся методы, описываемые в дан¬
ном разделе.
План создания единой ИС вполне реален и для группы однотипных
организаций, однако при его разработке, скорее всего, потребуется про¬
вести общесистемный анализ информационных процессов и средств
обработки данных.
Для объединения различных организаций характерно наличие не¬
скольких сфер основной деятельности. Такую группу, в частности, могут
составить машиностроительное предприятие и мебельная фабрика. Пол¬
ностью скоординированный план развития ИС здесь может оказаться
невозможным. Например, вряд ли целесообразно создавать единую базу
данных для заказчиков. Каждая организация должна сформулировать
свою стратегию развития ИС, согласовав с остальными вопросы исполь¬
зования необходимых для этого ресурсов или средств. Необходимо
исследовать возможность закупки общей ЭВМ и установки на ней
единых программных средств, например систем управления базами лан-
ных (СУБД) или пакетов прикладных программ для обработки платеж¬
ных ведомостей.
Наконец, в организациях, предоставляющих клиентам услуги по
типу сервисного бюро, требования клиента к средствам обработки дан¬
ных к моменту выбора технических и программных средств известны
далеко не всегда. Поэтому часто такой выбор производится просто на
основе анализа средств, имеющихся на рынке. Как правило, организа¬
ции рассматриваемого типа специализируются в определенной сфере
деятельности, и поэтому вынуждены придерживаться долговременной
технической политики. Именно в таком положении оказываются многие
подразделения обработки данных. Особенность их функционирования
заключается в том, что выбор моделей ЭВМ и устанавливаемого на них
программного обеспечения не может производиться без учета требова¬
16

ний пользователей. С точки зрения долговременного планирования это
наименее благоприятная ситуация. Техническая политика в таком слу¬
чае должна ограничиваться созданием необходимых вычислительных
мощностей и оптимизацией их загрузки. Если же разработка ИС возло¬
жена на само подразделение обработки данных, желательно все же ори¬
ентироваться на описываемую здесь процедуру планирования, посколь¬
ку для достижения успеха при создании ИС необходим постоянный кон¬
такт с конечными пользователями.
Многие организации по роду их деятельности трудно отнести к ка¬
кому-то конкретному типу, и при планировании это нужно учитывать.
Для простоты ниже рассматривается гипотетический пример однород¬
ной организации. В реальных условиях, возможно, потребуется внести
некоторые коррективы.
2.3.	Формирование стратегии разработки ИС
На рис. 2.1 этот процесс показан поэтапно. В широком смысле его
содержание сводится к следующему. Во-первых, проводится критиче¬
ский анализ требований к ИС с целью определения функций новых си¬
стем. Во-вторых, анализу подвергаются технические характеристики
ИС: как, на каких ВЦ и по какой технологии они функционируют. На¬
конец, оцениваются необходимые для разработки системы ресурсы и
технические средства. После этого формируется общий план создания
системы, в котором распределяются приоритеты между отдельными на¬
правлениями работ.
Термин «критический анализ» применительно к той или иной опера¬
ции означает, что имеющиеся решения, пусть даже не оформленные
документально, могут быть*изменены и развиты.
Детализация операций 1.1 и 1.2 (нумерация иерархическая, сверху
вниз) приведена на рис. 2.1, и об этом упоминается в тексте. Выполне¬
ние остальных операций потребуется только при соответствующих усло¬
виях, например при работе в сети ЭВМ или при переходе к новой техно¬
логии. Подробное описание всех операций приводится ниже.
2.4.	Критический анализ требований к ИС
При ознакомлении с материалом данного раздела у читателя может
создаться впечатление, что критический анализ требований к ИС про¬
водится однократно. На практике требования к ИС пересматриваются
регулярно, например каждые два года в течение пяти лет с промежу¬
точными мини-корректировками. Иногда к такому критическому анали¬
зу прибегают потому, что непомерно возрастает нагрузка на ЭВМ, а
это уже ставит под вопрос дальнейшее развитие ИС.
Анализ текущих потребностей. На первом шаге дается краткая ха¬
рактеристика организации: укрупненно описывается выпускаемая про¬
дукция или предоставляемые услуги и собирается статистика о сфере
деятельности, например основные параметры объектов, с которыми при¬
ходится иметь дело (их штаты, клиентура, число нерабочих дней), фи¬
нансовые показатели (товарооборот по категориям продукции, сметы по
основным статьям расходов, намечаемые деловые операции).
На втором шаге необходимо определить, в чем состоит суть дея¬
тельности организации, избегая, по возможности, употребления приня¬
той в ней терминологии, т. е. построить ее функциональную модель. Эта
17

18
Рис. 2.1. Этапы разработки ИС

функциональная модель в действительности является операционной
диаграммой высокого уровня (гл. 11), фрагмент которой показан на
рис. 2.2. Преимущество такого подхода заключается в том, что модель
позволяет мысленно преодолеть организационные барьеры. Например,
гораздо важнее определить с самого начала, что для ведения перегово¬
ров с поставщиками и учета материальных ресурсов целесообразно
Рис. 2.2. Функциональная модель
создать ИС, чем решать, какое подразделение должно выделить средст¬
ва на ее разработку и эксплуатацию.
Операции верхнего уровня могут быть рассмотрены на следующем
уровне детализации, так что может быть выявлено до шести операцион¬
ных уровней. Такой способ декомпозиции трудоемок, но, по-видимому,
оправдан, поскольку деятельность любой организации сама по себе
достаточно сложна.
Успешно построив функциональную модель, можно проанализиро¬
вать текущие информационные потребности в ее терминах. Так, могут
быть выявлены функциональные связи организационных подразделений
и существующие информационные подсистемы.
19

Информация, используемая для деловых операций, позволяет су¬
дить о полноте имеющихся данных. С целью ее изучения здесь можно
применить методы анализа данных. Это поможет лучше уяснить ос¬
новные направления деятельности организации и построить более со¬
вершенную функциональную модель. Далее следует определить, какие
типы данных требуются для проведения той или иной операции.
Наконец, должны быть зафиксированы сведения о наличии техниче¬
ских средств обработки информации и указано, в каких системах они
используются.
Выявление перспективных потребностей. Основные усилия на этой
стадии должны быть направлены на выявление новых требований к си¬
стеме в будущем. Но конечно, необходимо определить и направления
усовершенствования существующих систем.
Хотя при планировании системных требований желательно охватить
все сферы деятельности организации, точные планы, как правило, могут
быть разработаны лишь для некоторых из них. В остальных случаях
может потребоваться дальнейшая детализация требований, результаты
которой будут анализироваться поздней.
Для установления перспективных потребностей организации целесо¬
образно дополнить ее функциональную модель информацией о затра¬
тах, связанных с проведением каждой деловой операции.
Так, для выполнения операции по подготовке рекламных материа¬
лов (см. рис. 2 2) имеет смысл отдельно указать стоимость изготовле¬
ния иллюстраций и печати. В сведения по операции «Управление запа¬
сами» можно включить отношение хранимых запасов к товарообороту.
В ряде случаев можно вычислить вероятность успешного завершения
операции (например, при разработке новых продуктов) и расходы по ее
выполнению. Можно также провести ретроспективный анализ эффек¬
тивности последних исследовательских проектов: чем выше эффектив¬
ность, тем ниже потребность в новых информационных системах.
Таким образом, в основу анализа требований к ИС должны быть
положены три показателя: стоимость выполнения операции, количество
используемых ресурсов и вероятность ее успешного завершения. Опе¬
рации с наивысшими значениями этих показателей должны стать пред¬
метом более тщательного анализа.
Дополнительно целесообразно провести систематизированные опро¬
сы руководства, сообразуясь с существующей организационной струк¬
турой. Полученные результаты следует сопоставить с описанием дело¬
вых операций несколько позже.
Для организации диалога между аналитиками и руководством по¬
требуются специальные вопросники (анкеты). Главное — направить диа¬
лог в нужное русло. Большую помощь в этом плане может оказать
метод анализа ключевых факторов эффективности, рассмотренный
в гл. 12. Он позволит не только выявить проблемы, но и оценить веро¬
ятность достижения успеха при создании ИС. Этот метод нашел свое
отражение в документе (рис. 2.3), составленном применительно к ор¬
ганизации, функциональная модель которой приведена на рис. 2.2.
Результаты анализа оцениваются здесь с точки зрения руководителей
подразделений и служат не для определения новых требований, а лишь
для выявления направлений поиска. Графы таблицы соответствуют оп¬
ределенным операциям. Так, для правильного ценообразования необхо¬
димы точные сведения о себестоимости продукции.
Подобным образом для каждой операции целевые установки можно
сопоставить с возможностями существующих систем, а дальнейший ана¬
лиз требований к разрабатываемой системе выполнить, например, ис-
20

Целевые установки | Операция
f~ л
<и к
о. v
* =Г
о 2
Я S
gS
о и
5 Я
ГО
е
о
о. S
с 5
н я
3 >?
VO Ч
U
к
я
я
я
и
о
ч
О)
ч
о
о
я
я
ш
о
с
' я
"J а
О С*
с ^
ЛЛ о
3 g ^ Си
ь* 3 5 с
<ъ> Я ^
£Г 2 Я 5
Ь 3 я 5
О Оч< КС
VO
х Л
3 £
я ю
3 и
4
Я
s я н
= 1°|
н о ’©■ Ч
о О,
я 3 е
Н Я
*о ь
Я° о
КС— о.
S ^
Си |-1
а я о^
о
я
со
“ 3
Я S
О) я
•е- ч
о Я
^ 0J
(Т) о.
о
VO
£ X ш
я Л °
§ ж 2
«ДО.
gi&
.»• §.ся
>5
я си
н К 0
Я Я
н <и о
«!^
* Я Л
,9 “ я
U о
£ Л
я =
Н _ -о
Я
О- £ °
я 2 —
° я
и э
<и
я 2
i S S
I
П М со СО
о^ЫЛ
О Б S О
о.ч2 °-
яю ^ 03
5 я ^ я
S Л* о
н VO И
Л ° Я я
s £5
Р , Я S
Я «
я я
^ «
И я
<1 я
4)
S §
° g.
я
я
о
О) н
3 а
5 к
3 s
Я с_1
И S.
о сз
о- с
я
|§
< £
5 ^
н н
Я О
2 сх
S о
Я VO
о о
н о
^ о.
я я
я
О) я
«
я
я
я
я
я
I -
|!
о I
»я
Я s
3 о
2 «
^ о
4 я
& О
£ а
Я со
го я
X
3
н
к
я
я
§
Ч <и
У о.
К ni
^-0-
си
я я
Я CL)
&*
О &
и ч
ся ;
vo :
о ;
2 \
О)
а’
ч
о
я
я
я
о
<и
VO
си
° я
Р§
1 “
в 3
§1
<и с
5 s
2 8
3 а
Я s
О °
Н о
си
VO
я
{- я
я я
<и н
о. о
ч
я
я
я
я
о
с
я
я
£ к
О о>
н я
»я
я
я
21
Рис, 2.3, Примеры ключевых факторов эффективности

следуя приблизительные формы отчетов. Оценка же операций по степе¬
ни их важности позволит установить приоритеты этих требований и вы¬
явить расхождения в результатах опроса.
Взаимосвязанные системные требования группируются в области,
каждая из которых обозначается подходящим термином. Далее иссле¬
дуется экономическая целесообразность создания ИС. При этом могут
быть выявлены две проблемы. Во-первых, несмотря на большую потреб¬
ность в ИС, требования к ней могут быть сформулированы нечетко:
Необходимо более детально изучить потребности, возможно, и не
оформляя результаты до следующего пересмотра. Во-вторых, несмотря
на наличие некоторого требования к ИС, может оказаться неясным со¬
ответствующее ему техническое решение. В такой ситуации необходим
анализ реализуемости ИС (гл. 5), причем оформление результатов так¬
же может быть отложено до очередного пересмотра. В обоих случаях
по завершении всех работ общий план реализации ИС необходимо еще
раз подвергнуть критическому анализу.
Подготовка нормативных документов, регламентирующих разработ¬
ку И С. Составляются краткие описания новых системных областей с
указанием их относительных приоритетов. Определяется воздействие
каждой операции на основную деятельность организации. Для каждой
системной области, по возможности, выполняется предварительная
калькуляция затрат на разработку и эксплуатацию. Разумеется, на
данной стадии эти показатели будут весьма приблизительными и могут
быть получены главным образом путем сравнения с соответствующими
показателями существующих систем.
В документации кратко описываются необходимые технические
средства и ресурсы. Например, если речь идет об управлении производ¬
ством и выдвигается требование автоматизировать производственный
процесс, то должна быть зафиксирована связь между блоками управле¬
ния этим процессом й ЭВМ. В документацию следует также включить
краткие сведения о действующих системах, отразить и их связи с функ¬
циональной моделью организации.
Подготовленный таким образом план разработки ИС должен быть
утвержден руководством. Очень важно при этом оценить относительные
приоритеты автоматизации различных сфер деятельности организации
до рассмотрения технологических ограничений. Весьма желательно до¬
биться успеха в процессе планирования и руководства, особенно на ста¬
дии согласования и утверждения плана.
2.5. Критический анализ основных технологических решений
На данном этапе в план реализации ИС необходимо включить ос¬
новные положения, отражающие техническую политику организации
в области обработки данных. Несмотря на то что многие организации
применяют хорошо проверенные технические решения, внедрение но¬
вейших достижений информационной технологии (например, автомати¬
зации делопроизводства, распределенной обработки) может потребо¬
вать их пересмотра. В результате критического анализа должна быть
разработана общая технологическая схема ИС, в которой следует пока¬
зать размещение вычислительных центров, распределение прикладных
систем по этим центрам и места хранения данных.
Не всегда конкретные положения, отражающие техническую поли¬
тику организации, удается сформулировать однозначно. В таких слу¬
чаях целесообразно все-таки дать несколько общих рекомендаций.
2 2

Например, может быть установлено, что при ориентации на применение
микроЭВМ в подразделениях-пользователях «...ни одно из подразделе¬
ний не должно приобретать вычислительное оборудование стоимостью
свыше 10 тыс. ф. ст. без согласования закупки с координационным со¬
ветом. В ЭВМ, устанавливаемых в подразделении, могут храниться
только те файлы, которые содержат непосредственно относящуюся к
нему информацию. На хранение данных, относящихся к другим подраз¬
делениям, должно быть получено разрешение коор¬
динационного совета».
В настоящем разделе исследуются лишь те си¬
стемные требования, которые определяют общую
конфигурацию технических средств. Значение рас¬
сматриваемого этапа критического анализа опре¬
деляется тем, что на принимаемые здесь решения
оказывает влияние политика и стиль деятельности
организации как в деловой сфере, так и в области
обработки данных.
Определение технологических стадий. В тех
организациях, где в разработке ИС применяются
проверенные решения, технологическая схема мо¬
жет быть сформирована без дополнительных иссле¬
дований. Обычно под проверенными технологиче¬
скими решениями подразумевается пакетная обра¬
ботка, интерактивная обработка или системы баз
данных. Во всех этих случаях влияние конкретных
решений при формировании технологической схемы
может быть учтено.
Если же речь идет о новой или быстро развива¬
ющейся технологии, то необходимо определить
основные стадии ее внедрения в разработку ИС.
При этом может потребоваться рассмотреть ши¬
рокий круг вопросов: от политики конкретного по¬
ставщика ЭВМ (чтобы избежать закупки непер¬
спективного программного обеспечения) до тенден¬
ций развития микропроцессорной техники. Главны¬
ми в этой связи представляются следующие три
проблемы:
• выявление потенциальных направлений раз¬
вития технологии;
• отбор тех из них, которые соответствуют потребностям органи¬
зации;
• установление последовательности технологических стадий и со¬
ставление графика их освоения.
В качестве примера на рис. 2.4 показаны основные технологические
стадии при создании сети ЭВМ. Как возможные варианты здесь рас¬
сматривались коммутация пакетов, передача цифровой информации,
спутниковая связь, передача видеоданных, видеоконференции. Критери¬
ями для выбора нужной технологии должны были стать ответы на сле¬
дующие вопросы: в какие сроки могут быть удовлетворены потребности
организации, будут ли оправданы затраты, гарантируются ли целост¬
ность и безопасность данных, не скажутся ли на выбранной технологии
последующие структурные изменения в организации?
Прежде всего был дан краткий обзор существующих технических
средств, ставший основой для выявления возможных технологических
решений. Затем детально анализировались новые средства. Некоторые
23
ВЫЯВЛЕНИЕ
ПОТЕНЦИАЛЬНЫХ
НАПРАВЛЕНИЙ
РАЗВИТИЯ
ТЕХНОЛОГИИ
ВЫБОР
ОСНОВНЫХ
ТЕХНОЛОГИЙ
ЭСКИЗНОЕ
ПРОЕКТИРОВАНИЕ
СЕТИ
КРИТИЧЕСКИЙ
АНАЛИЗ
ПРИНЯТИЕ
РЕШЕНИЯ
И ПОДГОТОВКА
ДОКУМЕНТАЦИИ
Рис. 2.4. Технологи¬
ческие стадии соз¬
дания сети ЭВМ

из них пришлось отвергнуть по критерию «затраты — эффективность»
или из-за сложности технической реализации. Остались лишь наиболее
перспективные варианты, среди которых также предстояло сделать
выбор.
Следующий шаг — разработка эскизного проекта будущей сети и
координация технических решений на каждой технологической стадии.
Очевидно, что необходимость обеспечения плавного перехода от стадии
к стадии потребовала глубокого анализа технических решений и оказа¬
ла влияние на техническую политику организации.
В этой связи было проведено дополнительное исследование влияния
потенциальных изменений при развитии сети на функционирование ор¬
ганизации. Анализировалось, например, останется ли сеть рентабель¬
ной, если закроется филиал организации, или сможет ли сеть обеспе¬
чить выполнение заранее неизвестных требований. Результаты исследо¬
вания строго документировались с тем, чтобы к ним можно было
обратиться при перепроектировании системы через несколько лет.
Преимущество такого подхода состоит в том, что выбранные техни¬
ческие средства смогут применяться и в эксплуатируемых сетях, и в
тех, которые еще только будут созданы. Так, может потребоваться, что¬
бы терминалы, обычно работающие в соответствии с коммуникацион¬
ным протоколом SDLC фирмы IBM, имели интерфейс с сетью коммута¬
ции пакетов. Конечно, в этом случае, несмотря на смену техники, тер¬
миналы, сохраняющие привычный пользователю интерфейс, окажутся
более предпочтительными.
Разработка технологической схемы. На этом этапе еще рано ста¬
вить вопрос о выборе конкретных поставщиков технических или про¬
граммных средств, поскольку преждевременные контакты с поставщи¬
ками могут отвлечь от основной цели — разработки общей технологиче¬
ской схемы ИС.
Однако при выборе технического решения часто желательно остано¬
виться на каком-то варианте конфигурации технических и программ¬
ных средств, что связано с двумя обстоятельствами. Во-первых, если
это удается сделать, то и сам подход к разработке становится более
реальным. Во-вторых, выбор базовых технических или программных
средств позволяет более точно оценить затраты на реализацию систе¬
мы. В ряде случаев организации уже ориентируются на определенных
поставщиков, но тогда возможности выбора базовых средств, естест¬
венно, ограничены.
Формируя техническую политику организации в области обработки
данных, важно рассмотреть возможные принципиальные решения. Ведь
иногда приходится перечеркнуть все сделанное ранее просто потому, что
оптимальное техническое решение в свое время вообще не рассматри¬
валось. В информационной системе, где требуется удаленная обработка
данных, могут исследоваться следующие принципиальные технические
решения:
• простая (радиальная) сеть терминалов, подключенных к цент¬
ральной ЭВМ;
• несколько групп интеллектуальных терминалов для сбора данных
с последующей передачей их по каналам связи или на машинных носи¬
телях на центральную ЭВМ для основной обработки;
• несколько мини- или микроЭВМ, на которых решаются отдель¬
ные прикладные задачи, а данные передаются на центральную ЭВМ
либо по выделенным или коммутируемым каналам связи, либо на ма¬
шинных носителях.
24

В качестве вариантов реализации функций центральной ЭВМ могут
рассматриваться следующие:
• традиционная централизованная система, в которой программы в
режиме разделения времени выполняются на фоне обработки пакетных
задач;
• распределенная система обработки данных, включающая несколь¬
ко мини- или микроЭВМ, на которых решаются отдельные прикладные
задачи;
• система баз данных;
• специализированный телекоммуникационный процессор, управляю¬
щий работой удаленных устройств и обменом данными или файлами.
При этом в каждой точке сети распределенной обработки данных мо¬
гут применяться пакеты прикладных программ.
Приведенный список далеко не исчерпывает всех вариантов. Пред¬
ставляют интерес и «комбинированные» технические решения. Целесо¬
образность применения того или иного из них может быть определена в
ходе проработки эскизного проекта системы, на основе системных тре¬
бований. Для этого необходимо оценить не только стоимость реализации
конкретной технологии, но и ее потенциальные достоинства и недостат¬
ки, причем обязательно должны приниматься во внимание такие фак¬
торы, как соответствие технологии общему характеру работы организа¬
ции, обеспечение безопасности, целостности и восстанавливаемости
данных после возникновения отказов в системе, простота реализации
последней, требования, предъявляемые к квалификации пользователей
и персонала обработки данных. Подобный анализ следует проводить
достаточно детально, чтобы можно было обоснованно сопоставить раз-,
личные технологические решения.
Первый просмотр всех предложенных вариантов нужно выполнить
очень быстро. Часто он ограничивается анализом только тех факторов,
которые упрощают отсев неприемлемых решений. Например, введение
распределенной обработки может потребовать увеличения продолжи¬
тельности рабочего дня операторов, что не предусмотрено принятым на
данном предприятии режимом работы. Поэтому такая технология пос¬
ле небольшого обсуждения отвергается.
При выборе технологии весьма важным представляется анализ эко¬
номических характеристик. Предпочтение следует отдавать тем систе¬
мам, которые требуют меньших первоначальных инвестиций. Полезно
также оценить влияние ключевых факторов эффективности на ожидае¬
мую прибыль, например выяснить, каковы будут последствия шестиме¬
сячной задержки поставки некоторого специализированного программ¬
ного средства, необходимого для реализации системы?
Особое внимание следует уделить пакетам прикладных программ
(ППП). Многие пакеты в настоящее время имеют настолько широкие
возможности, что удовлетворяют большей части системных требований
организации. Это может отразиться на всем процессе проектирования,
так что рекомендуется решить вопрос о целесообразности использова¬
ния прикладных пакетов именно на данной стадии разработки. Наличие
подходящих пакетов может радикально изменить технологическую схе¬
му процесса обработки информации.
Допускаются также некоторые итерации по уточнению системных
требований. Менее существенными требованиями можно пренебречь.
Если основные требования не выполняются, то возможности ППП долж¬
ны быть расширены за счет дополнительных технических программных
средств, но при сохранении концептуальной целостности всей системы.
25

Естественно, что ППП, обеспечивающие только конкретную функцию
(обработка платежной ведомости), могут рассматриваться позже.
Не останавливаясь подробно на организационном аспекте выбора
технологической схемы обработки данных, отметим лишь, что любая
система, используемая для поддержки различных сфер деятельности
предприятия, должна рассматриваться на самых высоких уровнях про¬
цесса проектирования. Смысл изменений, проблем и преимуществ, свя¬
занных с разработкой и внедрением системы, должен быть предель¬
но ясен. Отсюда следует, что все радикальные перемены в характере
работы персонала необходимо тщательно согласовывать с руковод¬
ством.
Системы распределенной обработки заслуживают особого внимания,
поскольку в них в контакте с машиной должны работать люди, не име¬
ющие никакого опыта работы в области автоматизированной обработки
данных. Поэтому при реализации таких систем крайне важна как под¬
держка руководства, так и высокая квалификация пользователей.
Разработка и оценка опытных вариантов. В тех случаях, когда на
предприятии внедряется новая технология обработки данных, т. е. нет
опыта использования такой технологии, имеет смысл разработать и
ввести в эксплуатацию опытный вариант системы.
Технологическая схема процесса обработки задается заранее, но
считается предварительной. Таким образом, опытный вариант пред¬
ставляет собой модель будущей системы, реализованной в меньшем
масштабе. Часто такую модель создают для того, чтобы проверить, как
воспримет новую систему персонал предприятия, и изучить технологию.
При этом важно зафиксировать результаты испытаний и прекратить
дальнейшие работы в случае неудачи.
Анализ технической политики. В тех организациях, где несколько
систем разделяют одни и те же ресурсы (сеть ЭВМ, базу данных), эс¬
кизное проектирование отдельно для каждой системы на стадии анали¬
за реализуемости невозможно. Необходимо обеспечить четкую коорди¬
нацию использования ресурсов и уточнить решения по окончании раз¬
работки опытного варианта системы.
Координация осуществляется на начальной стадии формирования
стратегии разработки, когда создается единый, целесообразный и эф¬
фективный план реализации системы. Оцениваются и сопоставляются
с ожидаемым эффектом дополнительные затраты, связанные с совмест¬
ным использованием ресурсов. Например, для двух систем, разделяю¬
щих общие линии связи и терминалы, часто оказывается оправданным
применение поддерживающих программных средств повышенной сто¬
имости.
В качестве примера рассмотрим анализ стратегии разработки систем
баз данных. Допустим, что необходимо:
• проанализировать данные предметной области и разработать про¬
ект их логической структуры;
• подготовить общий технический проект, наилучшим образом удов¬
летворяющий системным требованиям;
• оформить этот проект и дать рекомендации для поэтапной разра¬
ботки;
• выявить дополнительные затраты на раздельную реализацию си¬
стем и определить ожидаемый эффект.
Предметная область включает шесть изолированных систем, исполь¬
зующих одни и те же данные о заказчиках торговой фирмы.
На рис. 2.5 перечислены основные фазы анализа и приведено их
краткое содержание. Для анализа была выбрана сегментированная ба¬
26

за данных, так как она более эффективна, чем традиционные файлы и
лучше соответствует поэтапному подходу к реализации системы.
Сама концепция баз данных нацелена на обеспечение возможности
создания различных прикладных систем, совместно использующих одни
и те же данные. Для реализации такой возможности с минимальным
риском существенных изменений в физической схеме при подключении
каждой новой системы проект должен быть максимально детализиро¬
ван, в частности, необходимо специфицировать форматы внутреннего
1. Разработка исходной документации на существующие файлы и новые отчеты, а
также на имеющиеся транзакции, которые потребуется выполнять и в будущем
2. Анализ данных
3. Выявление принципиальных технологических решений по организации хранениия
данных
• традиционные файлы;
• единая база данных;
• сегментированная база данных
4. Разработка критериев оценки проектных решений с точки зрения
• эффективности обработки;
• простоты реализации;
• простоты эксплуатации;
• возможности поэтапной разработки;
• трудоемкости переделки существующих систем;
• тестирования системы;
• обеспечения безопасности данных;
• чувствительности к изменениям технологической схемы обработки данных
5. Выполнение опытных вариантов проекта (применяется имеющаяся в организа¬
ции СУБД IDMS)
6. Выбор и оценка проектных решений
7. Анализ затрат и результатов
8. Документирование общего плана разработки
Рис. 2.5. Анализ стратегии разработки систем баз данных
представления данных, методы доступа и размещение указателей. Мож¬
но допустить некоторую неточность в определении элементов данных,
если приблизительно известны размеры записей каждого типа. При
оценке временных характеристик ограничиваются 10—20 основными
(с точки зрения нагрузки на ЭВМ) типами транзакций.
Анализ стратегии разработки систем базы данных, помимо создания
общего технического проекта базы данных, дает возможность обсудить
некоторые вопросы, касающиеся самих данных, в частности о структу¬
ре ключей. Если строится новая система кодирования, то на это потре¬
буется не меньше времени, чем на создание самой базы данных. В таких
случаях необходим анализ данных и, так как физическая структура
базы данных формируется на основе решений, принятых на этом этапе,
анализ должен быть выполнен весьма тщательно.
Говорят, что базы данных обеспечивают независимость программ от
структуры данных. Это справедливо при небольших изменениях (добав¬
ление элементов данных в структуру записей конкретного типа). Одна¬
ко в случае более серьезных изменений такая независимость возможна
далеко не всегда.
Предположим, что в некоторой организации (рис. 2.6) хранятся
записи о каких-то заданиях. Неожиданно принимается решение, что за
выполнение этих заданий должны отвечать постоянные подразделения,
27

а не временные рабочие группы. Структура данных тем самым изменя¬
ется с (рис. 2.6, а) на (рис. 2.6,6). В среде большинства СУБД тогда
должны быть изменены и повторно скомпилированы программы. Внесе¬
ние изменений не потребовалось бы при структуре данных, приведенной
на рис. 2.6, в. Здесь организационная структура может изменяться про¬
извольным образом. Конечно, отдельные записи типа «Задание» при¬
шлось бы переподчинить другим записям типа «Подразделение», но
изменения на уровне программного кода или повторной компиляции
были бы не нужны. Такие обобщенные структуры данных применимы
во многих областях, где реорганизация может повлечь за собой глубо¬
кие структурные изменения в данных.
ОТДЕЛ
ПОДРАЗДЕЛЕНИЕ
ОТДЕЛ
(а) до
ГРУППА
ПОДРАЗДЕЛЕНИЕ
1
г
1
г
ЗАДАНИЕ
ЗАДАНИЕ
ГРУППА
(б) после
ОТДЕЛ
ПОДРАЗДЕЛЕНИЕ
ГРУППА
ПОДРАЗДЕЛЕНИЕ
содержит
* ЗАДАНИЕ
входит в состав
ОРГАНИЗАЦИОННАЯ
СТРУКТУРА
(в) обобщенная
Рис. 2.6. Повышение гибкости базы данных
В заключение следует отметить, что анализ стратегии разработки
систем баз данных позволяет создать общий технический проект для
комплекса взаимосвязанных систем. На основе такого анализа можно
построить логическую структуру данных, максимально гибкую по отно¬
шению к возможным изменениям в предметной области.
Аналогичный подход может быть применен и в других случаях про¬
ектирования систем с разделением ресурсов. Главная цель его приме¬
нения— предотвратить возможные «сюрпризы» в процессе дальнейшей
разработки систем.
Подготовка нормативных документов. Создание технологической
схемы обработки информации завершается подготовкой документации.
В нее включаются описания рассмотренных вариантов с указанием при¬
чин, по которым они отклонены. Там, где необходимо, приводятся ру¬
ководства по внесению изменений в технологическую схему на последу¬
ющих этапах. На основе результатов анализа стратегии разработки
ИС обычно формируется отдельный документ, содержащий описание
технологической схемы информационных процессов.
28

2.6. Критический анализ стратегии разработки ИС
Анализ сводится в основном к увязке планируемых общих ресурсов
с требованиями к ИС и техническими решениями. На этом этапе опре¬
деляются виды и приблизительные объемы необходимых ресурсов.
Пересмотр стратегии разработки может быть обусловлен также труд¬
ностями выделения ресурсов для реализации ранее принятого плана.
В зависимости от стратегии разработки проекты классифицируют на
краткосрочные, среднесрочные и долгосрочные, причем отдельные про¬
екты могут затрагивать одни и те же сферы деятельности организации.
Для каждого проекта оцениваются требуемые ресурсы — машинное
время, программные средства, трудозатраты. ,В соответствии с резуль¬
татами оценки график реализации конкретных проектов может быть
изменен с целью обеспечения сбалансированного использования ресур¬
сов. Любые последующие решения должны приниматься с учетом
результатов критического анализа стратегии разработки ИС.
2.7.	Заключение
Предлагаемая технология планирования позволяет надеяться, что
разработка систем не прервется из-за недостатка кадровых ресурсов и
вычислительных мощностей или из-за нестыковки с другими системами.
Еще менее вероятно, что по каким-либо техническим причинам придет¬
ся приостановить выполнение проекта или радикально изменить смету
расходов. Кроме того, более «эффективным» системам в соответствии с
рассматриваемым подходом будет присвоен приоритет.
Наконец, следует отметить, что описываемая здесь методика предпо¬
лагает идеальные условия, в которых ведется планирование. Очевидно,
что на практике идеалы не всегда достижимы, однако точный стратеги¬
ческий расчет поможет вам избежать критических ситуаций в ходе даль¬
нейшей разработки.
Глава 3
Обзор методов разработки ИС
3.1.	Введение
В гл. 1 была показана связь методов разработки с методами управ¬
ления ИС. В настоящей главе проведена декомпозиция процесса разра¬
ботки на составляющие его операции, указаны цели выполнения этих
операций и их взаимосвязи.
Так, декомпозиция процесса «разработка и внедрение системы» мо¬
жет быть представлена следующим образом:
• поэтапная разработка системы;
• оценка ее объемно-временных характеристик;
• приемо-сдаточные испытания;
• внедрение;
• ревизия внедренной системы.
Все эти операции в следующих главах рассматриваются детально.
Здесь же дается их краткое описание.
29

3.2. Поэтапная разработка системы
Цель разработки — создание высококачественной системы, удовлет¬
воряющей потребности соответствующих пользователей — подразделе¬
ний и организаций. Процессом разработки необходимо управлять с тем,
чтобы обеспечить реализацию системы в заданные сроки, без превыше¬
ния сметы и с соответствующими характеристиками. Следовательно,
разработка систем должна основываться на определенной дисциплине,
включать стандартные процедуры и завершиться подготовкой норматив¬
ных документов. Рекомендуется использовать методы, регламентирую¬
щие уровень сложности технических решений.
Системы должны гарантировать установленный заказчиком показа¬
тель «стоимость — эффективность», обладать высокой надежностью,
легко восстанавливаться после отказов и быть простыми в сопровож¬
дении.
Методы, рассматриваемые в данной книге, применяются в системе
Modus. Эта система позволяет обеспечить:
• единую схему планирования и управления проектом;
• процедуры для выполнения всех необходимых операций на каждом
этапе;
• применение методов, адекватных существу задач, стоящих перед
разработчиком;
• нормативные документы, регламентирующие создание ИС;
• контрольные бланки для проведения ежедневного контроля, перио¬
дических инспекций и ревизии.
Декомпозиция операции «поэтапная разработка системы» на опе¬
рации более низкого уровня, которые и называются этапами, показана
на рис. 3.1. Для каждого этапа задана схема выполняемых процедур и
определен состав подготавливаемой документации. Так как процедуры
четко определены и строго разделены на отдельные шаги, на любом
этапе может быть проведена эффективная инспекция (т. е. проверка
выполнения операций).
Методы, предлагаемые для использования на каждом этапе, могут
быть рекомендованы в качестве дополнительных. Они могут оказаться
полезными как на отдельных этапах, так и для всего проекта в целом.
Перейдем к более подробному рассмотрению операций, перечислен¬
ных на рис. 3.1.
Начало анализа реализуемости. На предшествующих этапах систем¬
ного планирования нужно было выявить информационные потребности
в некоторой предметной области. Такой ацализ необходим не только
при разработке новых ИС, но и при усовершенствовании существую¬
щих систем.
Однако предварительное планирование осуществляется далеко не
всегда, например хотя бы потому, что предметная область определена
по случайному запросу пользователя. В таких случаях до формирова¬
ния исходных посылок для анализа реализуемости обычно проводится
краткое обоснование целесообразности создания ИС. Если выясняется,
что создание ИС нецелесообразно, оценка реализуемости теряет смысл.
Анализ реализуемости (гл. 5). Это первый основной этап проектиро¬
вания. Здесь проводится исследование технической и экономической реа¬
лизуемости ИС для заданной предметной области. Такое исследование
необходимо как при разработке новой ИС, так и при усовершенствова¬
нии существующей системы.
На данном этапе выполняется анализ имеющейся системы с целью
выявления перспективных информационных потребностей. Требования
30

определяются в терминах функций, реализуемых системой, и предо¬
ставляемой ею информации. Обсуждаются различные подходы, создает¬
ся эскизный проект, на основе которого оцениваются техническая реа¬
лизуемость и вероятные расходы на разработку и эксплуатацию ИС.
Выбирается наиболее подходящий метод разработки.
Для проектов, признанных реализуемыми, составляется техническая
схема и определяется область применения предлагаемой системы. Об¬
ласть применения рассматривается с трех точек зрения:
• функции существующей системы, которые должны быть исследо¬
ваны в процессе системного анализа;
Рис. 3.1. Поэтапная разработка системы. Номера глав, где излагается основной мате¬
риал по данному вопросу, указаны справа от прямоугольников, а номера глав, где
описаны соответствующие методы, — под прямоугольниками. Гл. 17 и 18 относятся ко
всем этапам.
• функции, которые, вероятно, потребуют изменений, и эти измене¬
ния осуществимы;
• уровень желаемого эффекта.
Техническая схема представляет собой эскизный проект системы.
При ее составлении необходимо решить вопрос об использовании таких
средств, как базы данных или программные средства режима реального
времени, а также установить степень сложности системы баз данных,
например, будут ли данные, управляемые СУБД, модифицироваться в
режиме реального времени.
На последующих этапах проектирования эти характеристики подле¬
жат критическому анализу.
При исследовании реализуемости разработки применяются методы
структурного системного анализа и целый ряд других методов (анализ
по показателю «стоимость — эффективность», оценка характеристик си¬
стемы и т. д.), однако не следует забывать, что главная цель на данном
этапе — только установить реализуемость системы; детали будут рас¬
сматриваться на последующих этапах. Таким образом, очень важно ана¬
лиз реализуемости проводить по сокращенной схеме управления проек¬
том, а для того, чтобы результаты можно было оценить и проконтроли¬
ровать, нужна хорошая методика такого анализа.
31

Системный анализ (гл. 6). На этапе системного анализа вырабаты¬
вается детальная спецификация новой системы в терминах функцио¬
нальной схемы организации. Спецификация служит основой согласован¬
ного с пользователем списка предоставляемых услуг и требуемых ха¬
рактеристик ИС. Она содержит всю необходимую для проектирования
информацию.
Успешный'системный анализ возможен, конечно, лишь при наличии
высокой квалификации и большого опыта проектировщиков, однако
методы, процедуры и тщательно подготовленная документация играют
здесь не последнюю роль. Главная задача — установить хорошие дело¬
вые взаимоотношения с пользователем и добиться получения четких
спецификаций системы.
Системный анализ, рассматриваемый в этой книге, предполагает це¬
лый комплекс методов, процедур и нормативных документов, разрабо¬
танных для решения вышеуказанных задач. В него входят:
• функциональный анализ, дающий более полное представление о
функциях существующей или новой системы. Большую помощь в иссле¬
довании существующей системы или в создании образа новой системы
оказывают операционные диаграммы;
• анализ данных, предназначенный для полного и однозначного оп¬
ределения данных и их взаимосвязей;
• анализ требований, позволяющий сопоставить выявленные в при¬
кладной области требования с характеристиками существующей систе¬
мы для оценки необходимых изменений.
Для реализации каждого из перечисленных видов анализа нужны
методики и технологические схемы (процедуры), по которым они будут
выполняться. Методики помогут специалистам решать сложные проб¬
лемы, возникающие в процессе анализа, и тем самым обеспечить соот¬
ветствие характеристик системы однозначно сформулированным и пол¬
ностью специфицированным требованиям организации. Процедуры поз¬
волят выделить комплекс работ, которые должны быть выполнены на
протяжении всего этапа проектирования. Необходимо наметить четкие
контрольные точки для проведения инспекций. Весьма важным пред¬
ставляется и создание нормативных документов, регламентирующих
взаимодействие между аналитиками, пользователями, конструкторами и
другими членами проектной группы.
Проектирование системы (гл. 7). На этом этапе происходит транс¬
формация логических представлений в спецификации программ, фай¬
лов, входных и выходных данных, управляющих воздействий. Основная
цель проектирования — создание системы, для которой легко организо¬
вать сопровождение. Целевые и машинные характеристики здесь еще в
расчет не принимаются.
В книге рассматривается метод структурного системного проектиро¬
вания, предполагающего наличие множества методик, процедур и нор¬
мативных документов. С их помощью устанавливаются связи между
группами функций, определенных во время системного анализа, а также
выбирается способ реализации этих функций программами. Таким об¬
разом, структурное системное проектирование — первый этап в цепи
формирования «строительных блоков» системы, являющихся элемен¬
тарными группировками данных и процессов, которые впоследствии мо¬
гут быть объединены в проект.
Прежде всего создается логическая модель требуемой вычислитель¬
ной системы, после чего выполняется упрощенное проектирование. В ре¬
зультате формируется первый вариант проекта, который затем после¬
довательно дорабатывается.
32

Спецификации программ подготавливаются в процессе проектирова¬
ния, а не выделяются в самостоятельную задачу, решаемую вне данного
этапа. Такой подход применим к системам, работающим в режиме ре¬
ального времени, и к системам баз данных в той же мере, что и к тра¬
диционным пакетным системам.
Методики помогают конструкторам сформулировать критерии, по
которым можно оценить качество проекта. Периодический анализ полу¬
ченных результатов способствует более заинтересованному участию в
работе программистов и эксплуатационного персонала.
Процедуры гарантируют выполнение проекта и, как и на других
этапах, создают основу для его оценки и развития. Периодические ре¬
визии способствуют повышению квалификации персонала.
Документация содержит определения структуры проекта и описа¬
ния решения общих вопросов, например о целостности данных и исполь¬
зовании ресурсов. Детальные спецификации проекта также являются
составной частью метода, реализуемой в форме спецификаций про¬
грамм, подробных описаний файлов и базы данных, входных и выход¬
ных данных, форматов экранов терминалов и структуры диалогов.
Программирование (гл. 8). На этом этапе разрабатываются авто¬
номно тестируемые программы по спецификациям, подготовленным во
время системного проектирования. Главная цель программирования —
создать надежные программы, для которых легко организовать сопро¬
вождение.
В книге рассматривается метод структурного программирования,
базирующийся на соответствующих методиках, процедурах и норматив¬
ных документах. В частности, предлагается методика структурного ана¬
лиза файлов как средства разработки логической схемы программы.
Выбирается основной файл и его структура сравнивается со структура¬
ми других файлов, используемых программой. Такой способ позволяет
обеспечить адекватность структур и выполнить требования процесса об¬
работки информации. Измененная структура становится основой для
конструирования программы, определяемой с помощью иерархической
схемы логических модулей и псевдокода. Проект затем «переводится»
на соответствующий язык программирования с помощью четко сформу¬
лированных правил кодирования.
От программистов не требуется особой интуиции и большого опыта
в решении аналогичных проблем для создания хорошо составленных и
легко воспринимаемых программ.
Тестирование (гл. 9). Описываемый в книге метод структурного те¬
стирования позволяет проверить разработанную систему «в действии».
Поэтапная разработка предусматривает две стадии тестирования: тести¬
рование программ и тестирование системы. Планирование работ по
тестированию начинается еще на этапе системного анализа. Эти планы
затем уточняются во время системного проектирования и программиро¬
вания.
Тестирование программ проводится в основном с целью установле¬
ния их надежности. Проверке подлежит каждая программа и каждый
логический модуль.
Системное тестирование должно продемонстрировать надежность си¬
стемы в целом. Проверяются точность обработки данных, «качество»
внутренних и внешних интерфейсов, способность системы восстанавли¬
ваться после отказов и обеспечение целостности данных. Кроме того,
выясняется, удовлетворительно ли работает система на выделенных
технических ресурсах.
2 Зак. 1783

3.3.	Технический контроль проекта (гл. 16)
Параллельно с поэтапной разработкой системы замеряются ее ха¬
рактеристики с целью определения потребляемых ресурсов. Эти опера¬
ции выполняются с помощью описываемой в книге методики техниче¬
ского контроля проекта, что позволяет прогнозировать использование
основных вычислительных ресурсов (центрального процессора, каналов
ввода-вывода и других). Прогноз формируется на этапе исследования
реализуемости разработки, затем изменяется на следующих этапах ана¬
лиза, детализируется при проектировании и уточняется во время тести¬
рования. Таким образом осуществляется актуальный прогноз ресурсов,
в том числе и при пиковых нагрузках. Для относительно дорогих или
работающих в критических условиях систем этим способом могут быть
получены обоснованные рекомендации по выбору направлений их моди¬
фикации. Часто достаточно приложить совсем небольшие усилия на
ранних стадиях разработки, чтобы предотвратить серьезные «хирурги¬
ческие» вмешательства на ее завершающих этапах. Такое вмешательст¬
во, как правило, неизбежно при недостатке времени и информации для
тщательной проработки проблемы.
3.4.	Тестирование (гл. 9)
Тестирование должно показать, удовлетворяет ли система требова¬
ниям пользователя и готова ли она к сдаче в эксплуатацию. Планирова¬
ние этой операции начинается вслед за системным анализом. Характер
работы с системой при тестировании должен быть максимально прибли¬
жен к условиям промышленной эксплуатации. Проводимые испытания
дают пользователям возможность получить необходимые навыки в ра¬
боте с системой и могут быть распараллелены.
Очень важно установить формальные процедуры фиксации ошибок
и наметить контрольные точки тестирования. Процедуры тестирования
должны включать регулярные ревизии выполняемого процесса.
Методы тестирования, рассматриваемые в книге, используются при
приемо-сдаточных испытаниях и являются составными частями комп¬
лексного метода полного тестирования. Приемо-сдаточные испытания в
сочетании с тестированием систем и программ позволяют сократить
трудозатраты на планирование, генерацию тестовых данных и собст¬
венно выполнение тестов.
3.5.	Внедрение
К планированию внедрения приступают уже на этапе исследования
реализуемости разработки. Прежде всего формируется эскизный план,
отдельные разделы которого (по оборудованию ВЦ или преобразованию
файлов) впоследствии детализируются. План внедрения уточняется по
мере поступления дополнительной информации. В плане внедрения си¬
стемы необходимо предусмотреть следующее:
• составление графика внедрения;
• преобразование данных;
• формирование штатов и обучение персонала;
• проектирование систем делопроизводства;
• подготовку технической документации;
• ввод новой системы в эксплуатацию.
34

Разработка процедур делопроизводства в условиях эксплуатации
вычислительных систем осуществляется параллельно с проектировани¬
ем автоматизированной части системы. Эти процедуры должны опреде¬
лять все ручные операции в сфере действия создаваемых систем. На
этапе системного анализа необходимо описать ручные операции в логи¬
ческих терминах и специфицировать физические интерфейсы к автома¬
тизированной части. При проектировании системы делопроизводства для
определения наиболее эффективных способов выполнения ручных опе¬
раций могут применяться различные организационные методы.
В некоторых больших системах разработка процедур делопроизвод¬
ства приобретает первостепенное значение, а при автоматизации учреж¬
денческой деятельности ее роль еще более возрастает.
Известно много хороших методов проектирования систем делопроиз¬
водства, которые могли бы быть стандартизованы в рамках предприя¬
тия. Некоторые из этих методов, приведенные в гл. 6, посвященной си¬
стемному анализу, могут быть адаптированы и развиты. Однако нужны
и другие методы, позволяющие оценить и измерить объем рутинной ра¬
боты.
Проблемы внедрения ИС, безусловно, заслуживают более широкого
обсуждения, но они не являются предметом нашего рассмотрения. Ко¬
нечно, необходимы и процедуры, обеспечивающие плавное внедрение
новой системы.
3.6.	Ревизия внедренной системы
Ревизия проекта проводится в двух аспектах: с точки зрения процес¬
са разработки и в отношении эффективности системы.
На практике обычно ревизия процесса проектирования выполняется
сразу же после внедрения системы. Ревизия же ее эффективности не¬
возможна до тех пор, пока не будет очевиден эффект. Ревизия процесса
разработки должна включать сопоставление реальных затрат времени
и ресурсов с запланированными, проверку соответствия проектных ре¬
шений стандартам и оценку их эффективности. Должна быть также
произведена оценка качества проекта. Результаты ревизии могут ис¬
пользоваться для улучшения технической документации и при состав¬
лении плана обучения членов проектной группы и их преемников.
При оценке эффективности системы необходимо выяснить мнение о
ней пользователей и выполнить повторный расчет баланса «стоимость —
эффективность». Следует определить, в какой степени система соответ¬
ствует своему назначению и насколько просты ее эксплуатация и сопро¬
вождение. Результаты этой оценки также позволят улучшить качество
технической документации и повысить квалификацию членов проектной
группы, что создаст предпосылки для разработки еще более эффектив¬
ных систем.
В книге процесс ревизии подробно не рассматривается. Однако ос¬
новные сведения о том, какие вопросы должны быть отражены в отче¬
те, будут приведены при детальном обсуждении этапов разработки.
3.7.	Инспекции (гл. 17)
В описываемом методе разработки ИС определено множество конт¬
рольных точек как в конце каждого этапа проектирования, так и на
всем его протяжении при завершении конкретных операций. Для конт¬
роля качества выполняемых работ желательно привлекать к проверкам
2*
35

не самих исполнителей, а других членов проектной группы. Предлагае¬
мые здесь методы проверок называются инспекциями. При проведении
инспекций должен применяться конструктивный подход, обеспечиваю¬
щий эффективное обнаружение ошибок при приемлемых затратах вре¬
мени и ресурсов.
1.8.	Графическое представление системных методов
Для представления системных методов в книге используются опера¬
ционные диаграммы. Так, на рис. 1.3 приведена сводка операций, отра¬
жающая содержание методов, применяемых в системе Modus, с несколь¬
кими уровнями детализации. Каждая указанная на диаграмме операция
включает целое множество более мелких операций.
С целью идентификации операций им присваиваются определенные
иерархические цифровые шифры. Например, операция «Проектирование
системы» имеет шифр 4, операция «Поэтапная разработка системы» —
шифр 4.1, а операция «Системный анализ» — шифр 4.1.3 (см. рис. 3.1).
В последующих главах, где каждый этап рассматривается более де¬
тально, первые две цифры для простоты опущены. Например «систем¬
ный анализ» далее просто обозначается как операция 3.
Существует еще один способ представления системных методов —
с помощью операционных диаграмм, на которых, помимо операций,
изображены потоки данных, соединяющие операции и хранимые данные.
Операционные диаграммы подробно рассмотрены в гл. И.
Глава 4
Применение структурных методов
4.1.	Введение
Выбор и применение системных методов следует рассматривать как
самостоятельную задачу. Очень важно, чтобы ее решение носило плано¬
вый характер, было понятным и получило одобрение всех инстанций.
В этой главе рассматриваются проблемы, связанные с внедрением опи¬
санных в книге структурных методов проектирования.
Наиболее широкое распространение получил подход типа «учись и
делай». Члены проектной группы читают книги и журнальные статьи,
возможно, посещают специальные курсы с тем, чтобы применить полу¬
ченные знания в своих разработках. Это дает определенный эффект,
если специалисты обладают достаточной квалификацией и ясно пред¬
ставляют себе стоящие перед ними цели, но не обязательно способствует
формированию последовательной и скоординированной методики проек¬
тирования в рамках всего подразделения. В некоторых организациях для
решения указанной проблемы высококвалифицированные специалисты
объединяются в централизованную службу, в обязанности которой вхо¬
дит обучение кадров, подготовка стандартов и проведение консультаций
при разработке первых проектов.
Ниже описывается порядок выбора, планирования, внедрения и со¬
провождения новой технологии проектирования. На рис. 4.1 приведена
краткая сводка решаемых при этом задач. В первую очередь необходи¬
мо определить, каким образом организация должна осваивать новую
технологию — собственными силами либо с помощью внешней органи¬
зации.
36

ВНЕДРЕНИЕ
И ПРИМЕНЕНИЕ
МЕТОДОВ
37
Рис. 4.1. Задачи, решаемые при выборе, внедрении и сопровождении методов проектирования

4.2.	Выбор методов
Прежде чем рассматривать весь спектр методов проектирования,
следует определить информационные потребности пользователя. Вполне
возможно, что реализация проектов запаздывает из-за неточных расче¬
тов, слабого руководства, отсутствия необходимой квалификации кад¬
ров или избытка различных стандартов. Иногда неточно выполняется
системный анализ, в результате чего, несмотря на хороший уровень про¬
граммирования, созданная система не удовлетворяет запросам пользо¬
вателя. С этой точки зрения разнообразие проблем, стоящих перед лю¬
быми проектными организациями, не так уж велико. Как только выяв¬
лены основные прикладные области, могут быть рассмотрены методы
решения проблем и определен фронт работ.
Несколько лет назад, когда структурное программирование стало
популярным, руководители некоторых подразделений ВЦ считали, что
новый метод поможет им избежать всех проблем — от неверной кальку¬
ляции и плохих характеристик системы до ее несоответствия требовани¬
ям пользователя и сложного, длительного тестирования. Они ошиба¬
лись. Структурное программирование может помочь решить только
проблемы программирования или тесно связанные с ним задачи. Если
же ключевая проблема не имела непосредственного отношения к про¬
граммированию, то оказывалось, что структурное программирование не
оправдывает возлагаемых на него надежд. Это свидетельствует о том,
как важно правильно выбрать метод или совокупность методов для
решения реальных проблем: каждой проблеме — свой подход!
Точно так же, как порой мы выявляем недостатки в работе того или
иного подразделения, необходимо отмечать и его сильные стороны.
Если одна из проектных групп располагает эффективным методом ре¬
визии, то этим методом должны овладеть и все остальные группы. При
внедрении структурной технологии редко возникает необходимость ко¬
ренной перестройки подразделений системотехники и программирова¬
ния. Как правило, новые^ методы и процедуры объединяются с действу¬
ющими стандартами и внедряются в плановом порядке.
Далее следует ознакомиться со всеми имеющимися методами и тех¬
нологиями. Конечно, при большом разнообразии методов многие из них
не удастся изучить достаточно детально. В таких случаях можно реко¬
мендовать обратиться за консультацией к другим организациям, кото¬
рые уже используют эти методы. Желательно, чтобы консультирующие
организации были сопоставимы по масштабам своей деятельности, вы¬
числительной базе и решаемым задачам. На основе полученных сведе¬
ний и данных из последних отчетов и статей формируется краткий пере¬
чень перспективных методов, по каждому из которых нужно собрать
максимум информации. С этой целью можно читать книги и статьи, но
это потребует слишком много времени. Более простой способ — упоря¬
дочить представление о различных методах, причем особое внимание
следует уделить таким вопросам, как:
• практическая направленность методов;
• полный набор приемлемых методов;-
• ППП, способствующие их реализации;
• применение методов на различных этапах разработки;
• взаимосвязи между этапами;
• разрабатываемая документация;
• сроки и стоимость внедрения;
• требуемые стандарты;
• влияние методов на организацию работ службы ОД;
38

• влияние методов на работу пользователей;
• круг пользователей;
• число и местонахождение пунктов сопровождения.
Для достижения лучших результатов целесообразно подключить к
этой работе руководителей подразделений, в которых данные методы
должны быть опробованы. Структурные методы, аналогичные описывае¬
мым в настоящей книге, обеспечивают основу для рационального уп¬
равления процессом разработки.
Очень полезно посетить организации, где применяются рассматри¬
ваемые методы. Встречи .со специалистами разных уровней — от дирек¬
торов и руководителей групп до системотехников и программистов —
позволят должным образом оценить используемые методы, их преиму¬
щества и недостатки. Можно изучить документацию и на ее основе
сделать вывод о целесообразности применения метода. Многие методы
выглядят весьма привлекательно, но нужно выяснить, как они зареко¬
мендовали себя на практике. Специалисты, уже работавшие по той или
иной технологии могут дать ряд полезных советов и предостеречь от
возможных ошибок.
После оценки процедур и методов может быть принято решение о
реализации некоторых из них. Существует множество технически вер¬
ных подходов, но основным фактором, определяющим успех задуман¬
ной операции, является способ ее проведения. Если удастся добиться
одобрения и поддержки всех инстанций, то вполне вероятно, что новые
методы дадут ожидаемый эффект. Однако, если члены проектной груп¬
пы настроены отрицательно и считают, что они вынуждены следовать
«еще одному набору стандартов», эта технология себя не оправдает.
Ключевым фактором, способствующим успешному внедрению новой
технологии, может оказаться привлечение к выбору методов и планиро¬
ванию реализации специалистов, которым предстоит работать по этой
технологии. Желательно также проконсультироваться с ними относи¬
тельно наилучшего способа применения методов проектирования в под¬
разделениях. При выборе методов нужно хорошо представлять себе
следующее:
• Будут ли все группы проектировщиков использовать новые ме¬
тоды?
• Какие методы следует испытать первыми?
• В каком объеме придется проводить обучение персонала?
• В какие сроки должны быть изменены стандарты?
• Какая помощь потребуется от внешних организаций?
• Как обеспечить гарантии того, что методы применяются пра¬
вильно?
• Как составить график обучения?
• Какова будет реакция пользователя на внедрение методов?
• Как следует обучать операторов?
Все эти вопросы следует согласовать не только с теми, кому предсто¬
ит внедрять новые методы, но и с теми, кто уже имеет опыт в их при¬
менении.
4.3.	Создание условий для внедрения новых методов
Как бы шцроко ни были распространены новые методы, жизненно
важно, чтобы они нашли свое отражение в стандартах. Это должно
стать одной из первых задач при планировании разработки ИС. Деталь¬
ное описание формирования стандартов дается в следующем разделе.
39

Стратегия реализации методов в значительной степени зависит от
характера выполняемых подразделением работ. В идеальном случае
выбирается небольшой проект и с ним проводятся эксперименты по
применению новых методов. В конце проектирования можно оценить
результаты, внести необходимые изменения и соответствующим образом
модифицировать стандарты. Только после того, как методы пройдут экс¬
периментальную проверку, они могут внедряться повсеместно. Однако
во многих организациях в период внедрения структурных методов уже
выполняются сложные долгосрочные проекты и может пройти немало
лет, прежде чем начнется разработка небольшого проекта. В такой си¬
туации методы можно опробовать на любом этапе. Если в данный мо¬
мент выполняется анализ, то проектирование и программирование
системы можно осуществлять уже с помощью структурных методов.
Некоторые организации специально для испытания методов созда¬
ют «искусственные проекты», что обычно ведет к «искусственным» ре¬
зультатам, поэтому им не может быть дана правильная практическая
оценка. Если не установлены конкретные (причем довольно сжатые)
сроки разработки, нет контактов с пользователем и проектировщикам
известно, что система никогда не будет реализована, они, скорее всего,
не смогут относиться к проекту как к «настоящему». Намного полезнее
внедрять методы на плановых проектах, как далеки бы они ни были
от идеала.
Еще одной запланированной задачей должно быть обучение кадров.
Здесь также возможно несколько вариантов (разд. 4.5). На этапе пла¬
нирования необходимо решить вопрос о комплексном и своевременном
обучении всего персонала.
При планировании следует предусмотреть и возможность управле¬
ния процессом внедрения методов. Очень важно установить, какая по¬
мощь со стороны разработчика потребуется на первых порах, когда и
как должны пересматриваться методы. При изучении и применении лю¬
бого нового средства наступает время, когда проектная группа должна
подвести итоги своей работы. Именно на это время желательно плани¬
ровать проведение инспекций. Явное подтверждение правильности по¬
лученных результатов стимулирует исполнителя, и в будущем он сможет
решить аналогичную задачу быстрее и с большей уверенностью. В слу¬
чае же каких-либо сомнений или ошибок своевременная инспекция поз¬
волит принять необходимые меры до выполнения большого объема
работ. Такая поддержка окажется для проектной группы весьма по¬
лезной.
4.4.	Разработка и изменение стандартов
В отношении стандартов наиболее характерны три ситуации:
• имеются хорошие стандарты, но они непригодны для структурной
технологии;
• стандарты отсутствуют;
• стандартов так много и они настолько не согласованы, что их ни¬
кто не знает или ими не пользуются.
Применение стандартов необходимо во всех областях обработки
данных — от стратегического планирования до измерения ресурсов, по¬
требляемых установленным оборудованием. Во многих подразделениях
обработки данных принят упорядоченный подход, предполагающий
стандартизацию всех операций. Проекты «проваливаются» чаще всего
там. где не соблюдаются основные стандарты. Более того, с развитием
40

распределенной обработки данных, обеспечивающей пользователю не¬
посредственный доступ к вычислительным ресурсам, возрастает необхо¬
димость в расширении сферы действия стандартов. Поэтому внедрение
структурных методов может оказаться удобным случаем для полной ре¬
визии стандартов.
Термин «стандарт» может трактоваться неверно, поэтому важно по¬
казать, что он означает. В стандарты входят:
• процедуры, планируемые и действующие (что делается?);
• документация (что вырабатывается?);
• методики (как это делается?).
В стандартах также формулируются требования к контролю разра¬
ботки:
• «контрольные точки» для пользователей, ревизоров, операторов и
руководителей службы ОД;
• положения, касающиеся управления проектом;
• предложения по расстановке кадров;
• прогноз использования машинных ресурсов.
Если структура отчетности и функциональных связей в подразделе¬
нии не соответствует структуре стандартов, последние могут оказаться
неэффективными. При планировании работы подразделения необходимо
предусмотреть последовательное распространение передового опыта.
В противном случае роль стандартов, введенных в какой-то одной сфере
деятельности, существенно снизится, если в других сферах не были
произведены соответствующие изменения. Поэтому прежде, чем присту¬
пить к детальной проработке стандартов и рекомендаций, следует про¬
думать процедурную схему работ, выполняемых в подразделении.
Многие организации в течение ряда лет успешно применяют одни и
те же стандарты. Этим организациям достаточно лишь добавить в них
несколько новых методик и процедур.
При планировании работ по стандартизации необходимо учитывать,
что грамотно составленные стандарты позволят существенно сократить
расходы на обучение персонала. Стандартам следуют только тогда,
когда удается убедиться в целесообразности их применения. Они долж¬
ны быть также динамичными, чтобы после экспериментального исполь¬
зования в них можно было внести необходимые поправки. Стандарты
будут лучше восприниматься и осваиваться, если в их разработке при¬
мут участие те, кому они предназначены.
Очень важно внедрять стандарты таким образом, чтобы у членов
проектной группы возник к ним интерес. С этой целью стандарты следу¬
ет изучать на всех учебных курсах.
Наконец, необходимо пересмотреть действующую в подразделении
систему контроля и обеспечить сбор статистической информации, требу¬
емой для критического анализа применяемых методов. При завершении
работы над системой весьма желательно получить количественную оцен¬
ку достигнутых успехов. Для сбора такой информации могут потребо¬
ваться некоторые изменения стандартов в части управления проектами.
4.5.	Обучение кадров
Существует четыре основных подхода к обучению персонала новым
методам: обучение в процессе работы, самостоятельное изучение мате¬
риалов, обучение на специализированных курсах и организация соответ¬
ствующих курсов на самом предприятии. Рассмотрим достоинства и
недостатки каждого из перечисленных подходов.
41

Численность сотрудников, квалификация которых должна быть по¬
вышена, в значительной степени зависит от внедряемых методов. Поми¬
мо полного курса обучения для специалистов, выполняющих данный
этап работ, следует организовать чтение краткого обзорного курса лек¬
ций для тех, с кем они должны взаимодействовать. Так, системотехни¬
ков нужно подробно ознакомить с методом структурного системного
проектирования и в то же время дать общие сведения по этому методу
аналитикам и программистам, поскольку они должны участвовать в
проведении инспекций. Кроме того, такой подход будет способствовать
лучшему взаимопониманию между специалистами, занятыми на разных
этапах проекта. Желательно также повысить профессиональный уро¬
вень пользователей и операторов, чтобы они могли воспринимать доку¬
ментацию, с которой им предстоит иметь дело в процессе проектиро¬
вания.
Как отмечается в разд. 4.6, лучше всего проводить обучение персо¬
нала в период, непосредственно предшествующий практическому внед¬
рению изучаемых методов, поскольку новый материал весьма быстро
забывается, как только слушатели возвращаются к своей прежней ра¬
боте.
Обучение в процессе работы в отдельных случаях дает очень хоро¬
шие результаты. Если все проектные группы уже применяют внедряе¬
мые методы и новый сотрудник приступает к работе, ему можно объяс¬
нить технологию решения каждой задачи. Коллеги легко могут оказать
ему необходимую поддержку. Более того, если ему доведется участво¬
вать в инспекции работ, выполненных другими, он быстро разберется
и в прочих методах.
Если же с новой технологией знаком лишь один из членов проект¬
ной группы, то у него уйдет много сил и времени на обучение своих
коллег. Кроме того, это приведет к увеличению срока разработки про¬
екта. Вероятно также неверное использование некоторых методов.
В результате от новых методов приходится отказаться, так как возни¬
кает слишком много проблем. Отсюда видно, насколько существенно
обеспечить хорошее обучение, поскольку затраченные средства и время
оправдываются только при быстром внедрении и освоении методов.
Второй подход (самостоятельное изучение литературы) имеет свои
недостатки. Каждый член проектной группы заинтересован в такой
работе хотя бы потому, что он получает время для чтения. Так как
обычно изучаемые материалы не содержат достаточно иллюстративных
примеров, внедряемым методам трудно дать практическую оценку. Ма¬
ловероятно также, что прочитанный материал будет одинаково воспри¬
нят всеми специалистами. Это усложнит организацию процесса проекти¬
рования, и инспекции сведутся к прениям по поводу используемых
методов, а не задач.
В том случае, когда по экономическим соображениям на предпри¬
ятии не удается создать соответствующие курсы, один из членов груп¬
пы может изучить методы и прочесть лекцию остальным сотрудникам.
Для лучшего уяснения этих методов могут быть выполнены различные
упражнения. Ответственный за обучение, скорее всего, должен отве¬
чать и за внедрение стандартов, что позволит ему ознакомить с ними
всю группу. К началу работ над проектом группа будет лучше понимать
стандарты и сможет использовать их как справочный материал.
Третий подход к обучению — направление сотрудников на специаль¬
ные курсы. Преимущество этого подхода состоит в том, что такое обуче¬
ние проводится высококвалифицированными преподавателями и дает
более полное представление о теоретических и практических аспектах
42

внедряемых методов. Прежде чем направлять сотрудников на курсы,
необходимо проанализировать предлагаемую программу. Чрезвычайно
важно, чтобы изучаемые методы демонстрировались на приближенных
к реальности примерах. Это дает возможность слушателям ставить и
решать некоторые практические проблемы, хотя, конечно, трудно зара¬
нее предугадать, какие проблемы возникнут при применении новых ме¬
тодов. Польза обучения на специальных курсах состоит и в том, что
здесь могут встречаться и обмениваться идеями представители самых
разных организаций.
Однако программа таких курсов не может учесть все специфические
особенности или потребности каждой конкретной организации. Во мно¬
гих случаях это не имеет решающего значения, поскольку новая техно¬
логия преподается именно так, как она должна осваиваться. Но при
значительных отклонениях от программы на практике могут возникать
серьезные проблемы.
Последний, четвертый, способ обучения предусматривает создание
на предприятии собственных курсов. Этот способ считается наилучшим,
поскольку он позволяет организовать обучение большого числа сотруд¬
ников и учесть специфику предприятия. При изучении методов можно
использовать пересмотренные стандарты, а программу построить при¬
менительно к типу прикладных задач, решаемых в данном подразделе¬
нии. Члены проектной группы, окончившие такие курсы, совершенству¬
ют свое мастерство при проведении инспекций. Наконец, совместное
обучение и последующее освоение новых методов способствует улучше¬
нию микроклимата в коллективе.
4.6.	Планирование первого проекта
Общие оценки первого проекта, выполняемого с помощью новых ме¬
тодов, могут быть получены примерно так же, как и для предыдущих
проектов, которые разрабатывались по старой технологии. Декомпози¬
ция задач, вероятно, будет иной, и может потребоваться дополнительное
время на решение подзадач. Важно помнить, что первое решение любой
задачи займет больше времени, чем ожидается. Обычно следующая ана¬
логичная задача решается уже и быстрее и качественнее. Исключение
составляет случай, когда задача с самого начала была решена неверно
и после этого выполнялась бессмысленная работа. Применение струк¬
турных методов, как правило, форсирует выполнение всех детальных опе¬
раций и позволяет закончить их до проведения ревизии документации.
Необходимо выделить время для подготовки проведения структур¬
ной инспекции. Во многих проектах это не делается, поэтому инспек¬
ция выполняется либо слишком поспешно, либо не выполняется совсем.
Считается, что проведение инспекции на ранних этапах сопряжено с
большими накладными расходами, однако на этапе тестирования необ¬
ходимость в ранних инспекциях становится очевидной.
Если первый проект слишком масштабен, может потребоваться пе¬
риодическая переподготовка кадров. Занятия следует проводить перед
каждым этапом, а не проходить полный курс обучения в начале проек¬
та. Там, где по экономическим соображениям, такие занятия организо¬
вать невозможно, рекомендуется проводить по крайней мере собеседо¬
вания, которые могут протекать в неформальной обстановке.
.43

4.7.	Выполнение первого проекта
Общая проблема, с которой приходится сталкиваться при выполне¬
нии первого проекта, связана с удлинением начальных этапов (планиро¬
вания, анализа и проектирования) по сравнению с соответствующими
этапами предшествующих проектов, поскольку структурные методы тре¬
буют детальной проработки. Когда исчерпана большая часть времени,
отведенного на проектирование, а к кодированию программ еще не
приступали, руководитель проекта обычно начинает беспокоиться. Хотя
теоретически ему известно, что программирование и тестирование осу¬
ществляются намного быстрее/ если анализ и проектирование выполне¬
ны верно и подготовлена вся необходимая информация, он не уверен в
успехе. В большинстве случаев дело обстоит именно так.
Руководители всех рангов обязаны доверять членам проектной груп¬
пы. Наихудший вариант—попытаться ускорить выполнение первых
этапов и не завершить их полностью, что ставит под угрозу срыва по¬
следующие этапы и дискредитирует структурные методы. Эта пробле¬
ма проще решается в условиях небольшого проекта. Вот почему для
первой реализации следует по возможности выбирать небольшой
проект.
Вторая проблема заключается в правильном использовании методов.
Структурные инспекции должны обеспечить регулярные ревизии резуль¬
татов работ и выявлять недоразумения прежде, чем они окажут свое
воздействие на систему. Однако иногда методы применяются неверно
из-за неправильного их толкования большинством членов группы. В дан¬
ной ситуации не всегда требуется немедленное вмешательство руково¬
дителя проекта, но, если результаты работы свидетельствуют об
устойчивых отклонениях от принятой технологии, следует обратиться к
экспертам.
После завершения анализа и проектирования могут усложниться
взаимоотношения с программистами, если они будут считать, что дан¬
ные им спецификации слишком детальны. Подобная регламентация
может мешать при написании программ. Поэтому желательно привле¬
кать ведущих программистов к проектированию. Большинство из них
вполне справятся с созданием спецификаций программ. Однако проек¬
тирование и кодирование программ должны быть затем поручены дру¬
гим программистам. При таком решении проблемы интерес программи¬
стов к написанию программ существенно возрастает, даже если заданы
детальные спецификации.
Проблемы возникают и при первых инспекциях. Некоторые трудно¬
сти и пути их преодоления подробно рассмотрены в гл. 17.
Говоря о проблемах, нельзя не отметить и положительные эффекты,
связанные с выполнением первого проекта. Прежде всего к разработке
системы привлекаются все члены проектной группы, которые должны
быть достаточно компетентны. Между членами группы устанавливают¬
ся хорошие деловые контакты, что помогает выявить потенциальные
проблемы. Ошибки, в том числе и вероятные отклонения от плана раз¬
работки, следует обнаруживать как можно раньше, поскольку это поз¬
воляет быстро вносить необходимые коррективы. Структурные методы
гарантируют более полное выполнение каждого задания. Упрощаются
контроль завершенных заданий и оценка оставшихся работ. Декомпо¬
зиция системы на логические компоненты дает возможность адаптиро¬
ваться к изменениям требований пользователей. Наконец, тщательное
тестирование упрощает внедрение и эксплуатацию системы.
44

4.8.	Ревизия первого проекта
По завершении проекта необходимо убедиться в том, что все постав¬
ленные при внедрении методов цели достигнуты. При выборе методов
разработки был составлен перечень требований к ним. Теперь результа¬
ты проектирования могут быть сопоставлены с этим списком. Полезно
также проанализировать проект по следующим пунктам:
• Удалось ли завершить проект в соответствии с графиком?
• Насколько точными оказались предварительные оценки затрат
времени и ресурсов на разработку?
• Как выполнялись различные этапы проекта, имелась ли возмож¬
ность оценить незавершенные работы?
• Какова была производительность труда?
• Удовлетворяет ли система целевым характеристикам?
• Сколько потребовалось времени на каждую фазу тестирования?
• Равномерно ли распределялось время тестирования?
• Каково отношение стоимости разработки к стоимости сопровож¬
дения?
• Сколько ошибок было обнаружено при приемке системы?
• Сколько ошибок было обнаружено в процессе эксплуатации?
• Как соотносятся эти показатели с аналогичными показателями
других (неструктурных) проектов в данной организации?
На последние вопросы можно ответить лишь после того, как система
проработает некоторое время.
Следует пересмотреть стандарты с учетом опыта выполнения пер¬
вого проекта. Но делать это нужно с большой осторожностью и только
в том случае, если возникнет необходимость в изменении методик или
процедуры, а не из-за недостаточной квалификации персонала.
4.9.	Последующие проекты
Последующие проекты должны планироваться и контролироваться
точно так же, как и первый проект. Специалисты, не участвовавшие в
первом проекте, обязаны пройти соответствующую подготовку. По воз¬
можности, в каждую проектную группу следует включить по крайней
мере одного специалиста с опытом работы в первом проекте. Необходи¬
мо позаботиться о стимулировании внедрения новых методов. Каждая
группа должна чувствовать заинтересованность и поддержку со стороны
руководства.
Полезно периодически проводить семинары по новым методам и при¬
влекать к ним всех, кто использует эти методы. На таких семинарах
обычно обсуждаются возникшие проблемы и пути их решения, а также
предлагаемые изменения в стандартах. Таким образом устанавливают¬
ся деловые контакты между проектными группами, а сами группы не
теряют массу времени на решение одних и тех же проблем.
Тем, кто отвечает за внедрение стандартов, можно рекомендовать
провести анализ перечня работ, отчетов и прочей документации всех
групп. Такой анализ часто позволяет выявить слабые стороны проекта,
определить, какие стандарты нуждаются в изменении, подтвердить не¬
обходимость дальнейшего обучения персонала. Пересмотр стандартов
крайне важен, поскольку они должны отражать используемые в орга¬
низации методы работы и точно предписывать, как их следует приме¬
нять. Введение стандартов служит гарантией того, что системы, разра¬
45

батываемые различными проектными группами, создаются по одной и
той же схеме.
В некоторых подразделениях принято, что члены проектных групп
время от времени участвуют в инспекции «чужих» проектов. Это еще
один путь для достижения взаимопонимания и более глубокого изуче¬
ния методов. Чтобы инспекция прошла успешно, необходимо заранее
ознакомиться со всеми материалами. Такие мероприятия не следует
проводить слишком часто, поскольку на это уходит много времени, но
в отдельных случаях они исключительно полезны.
Ревизия последующих проектов проводится теми же методами, что
и ревизия первого проекта.
4.10.	Сопровождение систем
В настоящее время сформировались два основных подхода к орга¬
низации сопровождения систем. В соответствии с первым подходом за
сопровождение системы отвечает разработавшая ее группа, а в соот¬
ветствии со вторым — группа общего сопровождения всех функциониру¬
ющих систем. Первый подход после внедрения структурных методов не
нуждается в пояснении. Для реализации же второго подхода может
потребоваться дополнительное планирование.
Во-первых, группа общего сопровождения должна изучить новые ме¬
тоды, чтобы сопровождать систему в том же стиле, в каком она разра¬
батывалась. Методы и процедуры сопровождения могут измениться в
результате применения структурного подхода.
Во-вторых, в период разработки члены группы сопровождения могут
привлекаться к проведению инспекции. Руководитель группы должен
иметь возможность оказывать влияние на ход проектирования. Полезно
также, чтобы группе сопровождения была известна программа тестиро¬
вания системы.
Еще одна проблема, связанная с сопровождением, состоит в следу¬
ющем. Должны ли системы, разработанные до введения структурных
методов, сопровождаться по структурному4 принципу? Как подсказывает
здравый смысл, решения следует принимать тогда, когда становятся из¬
вестны объем и последствия предстоящих изменений. Если изменение
потребует создания одной или нескольких новых программ, эти про¬
граммы должны разрабатываться с использованием структурного под¬
хода, структурных спецификаций и структурного программирования.
Если же нужно изменить всего несколько строк в программе, нет смысла
переделывать всю программу только затем, чтобы превратить ее в
структурную. Во всех остальных случаях решение этого вопроса можно
оставить на усмотрение специалистов, осуществляющих данное изме¬
нение. Необходимо оговорить время, требуемое для внесения изменений
и обеспечить простоту сопровождения. Однако, каким бы способом ни
выполнялось проектирование и кодирование, в период сопровождения
всегда целесообразно провести инспекцию и изучить текст программы.
4.11.	Дальнейшее применение структурных методов
После успешного применения новых методов в нескольких проектах
они получают «путевку в жизнь», и никто уже не помышляет о возвра¬
те к старой технологии. Инспекции и промежуточные ревизии гаранти¬
руют им дальнейшее распространение и корректное использование.
46

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

Часть 2-
Методы разработки проекта
Глава 5
Анализ реализуемости разработки ИС
5.1.	Введение
Это первый этап, относящийся, собственно, к разработке проекта, а
следовательно, и к конкретной прикладной области. Он занимает проме¬
жуточное положение между стратегическим планированием, рассмот¬
ренным в гл. 2, и системным анализом.
Целью исследования являются определение общесистемных требова¬
ний в прикладной области и выбор соответствующего технического ре¬
шения. На этом же этапе должно быть проведено экономическое обос¬
нование проекта и выявлена возможность его выполнения при выделен¬
ных ресурсах. Операционная диаграмма анализа реализуемости показа¬
на на рис. 5.1.
Если предварительное формирование стратегии разработки ИС за¬
вершено, то эскизный проект системы должен создаваться на этапе
планирования. В противном случае необходимо провести краткое си¬
стемное обследование и решить вопрос о целесообразности выполнения
оценки реализуемости в данной области. В процессе обследования нуж¬
но сопоставить по основным показателям новые системы с существую¬
щими и пересмотреть планы развития последних.
В том случае, когда предполагается какое-либо разделение ресурсов
между системами, уже при формировании стратегии разработки долж¬
но быть принято определенное техническое решение. Оценка реализуе¬
мости потребуется при этом только для контроля и изменения (при
необходимости) данной стратегии. Чем больше прошло времени после
формирования стратегии, тем большее значение приобретает этап ана¬
лиза реализуемости с точки зрения пересмотра всего проекта.
Анализ реализуемости должен быть обобщенным. Детализация
представляется совершенно излишней. С другой стороны, для получения
реалистичного эскизного варианта системы на этом этапе желательно
учесть все влияющие на него факторы. В противном случае планы раз¬
работки и расчеты затрат вряд ли будут обоснованными. Оценка реали¬
зуемости необходима и для прогноза эффективности будущей системы.
Допускаются некоторые неточности в деталях логических специфи¬
каций, поскольку они не противоречат здравому смыслу и могут быть
устранены на последующих этапах.
Предполагается, что читателю известны методы анализа и стратеги¬
ческого планирования систем. Однако предварительно ознакомиться с
содержанием и назначением этапа исследования реализуемости разра¬
ботки ИС можно и без предварительного чтения соответствующих раз¬
делов книги.
48

Рис. 5.1. Анализ реализуемости
5.2.	Постановка задачи
Несмотря на важность начальных операций, в этом разделе им не
уделяется особого внимания, поскольку они подробно рассматриваются
в других главах. Основной акцент здесь сделан на применении более
общих методов к конкретным задачам оценки реализуемости (1, 2, 3 на
рис. 5.1).
Исследование реализуемости начинается вслед за выявлением проб¬
лем, не разрешимых в рамках существующей системы. Прежде всего
формулируются основные задачи и создается небольшая группа разра¬
ботчиков, имеющих навыки анализа, проектирования и внедрения си¬
стем.
Определение области применения системы и планирование опера¬
ций. Область применения системы рассматривается совместно с руко¬
49

водством службы ОД и пользователями. На этом этапе область приме¬
нения может быть определена произвольно, так как именно здесь необ¬
ходимо уточнить ее и четко сформулировать для последующих этапов
проектирования. Например, назначение системы может быть определе¬
но следующим образом: спецификация требований к административным
системам на предприятии, которые могли бы обеспечить повышение
объема производства. По всей вероятности, при такой постановке зада¬
чи нужно выяснить следующее:
• Должна ли система внедряться лишь на одном предприятии, не¬
смотря на то, что существуют и другие аналогичные предприятия?
• Сможет ли только одна административная система обеспечить
больший объем производства? Имеет ли отношение к этой проблеме про¬
цесс управления?
• Сверхнормативные запасы отрицательно влияют на производство,
снижая оборачиваемость основных и оборотных средств. Нужно ли ка¬
саться этой темы?
Часто идеи пользователя наиболее ясно излагаются при первона¬
чальной формулировке назначения системы. Обсуждение этих идей на
самых разных стадиях обеспечивает правильное представление о сфере
применения будущей ИС и позволяет направить проект в более конкрет¬
ное «русло». Кроме того, это дает возможность составить операцион¬
ную диаграмму (см. гл. 11), которая четко определяет границы функ¬
ционирования системы и ее связь с другими системами.
Итак, на этом этапе специфицируются представления пользователей,
выявляется степень их противоречивости, составляется и координирует¬
ся подробный план выполнения анализа.
Анализ существующей системы. Здесь используются те же процеду¬
ры, что и на соответствующей стадии системного анализа. Они разли¬
чаются лишь по степени детализации и точности. Вначале вырабатыва¬
ется сводка операций (см. рис. 6.4). Определяются потоки данных для
операций самого нижнего уровня; при этом учитываются имеющиеся
файлы. Операции документируются на стандартном бланке операций
(как показано на рис. 6.5), что позволяет выявить очевидные и потен¬
циальные проблемы. В отличие от аналогичной стадии анализа систем
здесь допускается некоторая неточность. Таким образом, образ сущест¬
вующей системы может проясниться в результате нескольких бесед, что
дает возможность легко установить взаимосвязи между операциями.
Полученную информацию затем дополняют приблизительными оцен¬
ками всех системных элементов, сведениями о размерах и частоте ис¬
пользования файлов, а также подробными данными о самых больших
файлах, входных транзакциях и отчетах.
Определение структуры данных позволяет оценить функциональную
схему предприятия извне, сделать сводку операций и уточнить детали.
С этой целью применяется процедура, называемая логической ассоци¬
ацией данных (гл. 13). В результате ее выполнения создается диаграм¬
ма, аналогичная приведенной на рис. 13.4.
Следует собрать информацию о структуре затрат, например о зара¬
ботной плате, затратах на оборудование, премиях и т. д., и об их рас¬
пределении по операциям. Необходимо, кроме того, иметь представле¬
ние о стоимости и характеристиках существующей системы, в частности,
о том, какова численность обслуживающего персонала, какое примени-,
ется оборудование, каково соотношение специалистов и технических ра¬
ботников. Желательно фиксировать также сильные и слабые стороны
деятельности организации. Недостатки в информационной сфере следу¬
ет рассмотреть специально, осветив существующую практику решения
50

вопросов защиты данных, юридические и финансовые требования или
производственные связи.
Результаты исследования существующей системы обсуждаются и
согласовываются с пользователями.
Определение требований. На данной стадии необходимо полностью
сформулировать требования к системе. С этой целью применяют про¬
цедуру анализа ключевых факторов эффективности (key performance
factor), рассматриваемую в гл. 12. Конкретный пример определения
требований приводится в разд. 6.6 при описании системного анализа.
К сожалению, часто такие требования либо вообще не рассматривают¬
ся, либо подробно не документируются.
Далее необходимо изучить, насколько функции, реализуемые суще¬
ствующей системой, соответствуют выдвинутым требованиям (см.
рис. 6.9).
В заключение разрабатывается и согласуется с пользователями опе¬
рационная диаграмма верхнего уровня, являющаяся своеобразным эски¬
зом будущей системы.
5.3.	Возможные решения
Следующий шаг на этапе исследования реализуемости — анализ
альтернативных решений выявленных проблем. Здесь мы рассмотрим
некоторые возможные подходы к решению этих проблем, а в разд.
5.4 — основные процедуры оценки реализуемости.
Выбор оптимального технического решения. Еще недавно было из¬
вестно всего два варианта организации систем обработки данных: па¬
кетная обработка на основной ЭВМ и интерактивная обработка с по¬
мощью терминалов, соединенных с центральным процессором. Теперь
же благодаря значительному снижению-стоимости, уменьшению разме¬
ров и расширению возможностей оборудования, а также распростране¬
нию программных средств, пользователи могут решать с помощью ЭВМ
практически любые задачи.
Для достижения экономической целесообразности системы обработ¬
ки данных совсем не обязательно применять пакетную обработку. Не¬
большие коммерческие машины обладают ныне свойствами, ранее при¬
сущими только большим компьютерам. Наличие языков высокого уров¬
ня, СУБД, простота использования, нетребовательность современных
ЭВМ к окружающей среде этому весьма способствуют. Стали общедо¬
ступными программы управления телеобработкой и удобные средства
разработки ИС, что позволяет строить сети ЭВМ и распределенные си¬
стемы, в которых удается обеспечить «прозрачность» файлов и про¬
грамм для пользователей.
Мини-машины прошлых лет снабжены сегодня более мощным про¬
граммным обеспечением, дающим возможность разрабатывать сложные
прикладные системы, а на базе микропроцессоров созданы персональ¬
ные компьютеры.
Появились интеллектуальные терминалы, выполняющие множество
функций: контроль и временное хранение файлов, локальную обработ¬
ку и др. Недорогие терминалы изготовлены на базе бытовых телевизо¬
ров. В сочетании с технологией передачи «видеоданных» (viewdata)
применение таких терминалов способствует массовому распространению
диалоговых систем реального времени и систем ввода данных. Неизме¬
римо возросли возможности микроЭВМ. Даже дешевый бытовой компь¬
ютер можно использовать как интеллектуальный терминал путем эму¬
ляции стандартного протокола.
51

Разнообразны способы автоматизации учрежденческой деятельно¬
сти: от автоматического распознавания машинописного текста до обра¬
ботки речевых команд. Практически доступны средства хранения и по¬
иска цветных изображений на видеодисках, электронной почты, хране¬
ния, поиска и обработки текстов и данных.
Все эти потенциальные технические решения могут совместно при¬
меняться в условиях локальных и глобальных, в том числе междуна¬
родных, сетей ЭВМ, работающих по принципу коммутации пакетов дан¬
ных и телексной связи.
При таком разнообразии вариантов необходимо как можно раньше
ограничить выбор альтернатив. Именно эти цели и преследует стратеги¬
ческое планирование (гл. 2). Любые услуги или оборудование много¬
целевого назначения должны быть объектом исследования на стадии
формирования технической политики, предшествующей анализу реали¬
зуемости. В некоторых случаях для унификации технических и програм¬
мных средств в организации могут быть введены соответствующие стан¬
дарты, что позволяет снизить требования к уровню квалификации пер¬
сонала, обслуживающего эти средства.
Тем не менее при оценке реализуемости разработки приходится рас¬
сматривать еще довольно много вариантов. Так, для конкретной при¬
кладной системы, обслуживающей дирекцию филиала некоторой фир¬
мы, возможны следующие альтернативы:
• совершенствование неавтоматизированных методов;
• централизованная пакетная обработка с физической доставкой
данных;
• удаленный ввод заданий в центральную ЭВМ;
• применение терминалов, подключенных к центральной ЭВМ;
• организация терминального пункта с локальным вводом данных и
централизованным обменом файлов;
• использование технологии электронной подготовки данных на
микрофишах и микроЭВМ для приема и хранения изменений в файлах
и локального ввода данных для посылки в центральную ЭВМ на па¬
кетную обработку;
• установка небольших коммерческих машин, соединенных с цент¬
ральной ЭВМ.
Более того, при любом варианте организации вычислительной систе¬
мы имеется несколько различных способов организации процесса обра¬
ботки. Файлами можно управлять либо с помощью СУБД, либо тради¬
ционными средствами. Если к одним и тем же данным требуется мно¬
жество путей доступа, то применение СУБД целесообразно. В каждом
конкретном случае необходимо взвешивать все «за» и «против».
Аналогично в интерактивных системах файлы могут изменяться в
реальном масштабе времени либо в пакетном режиме по окончании
сеанса. Из-за высокой стоимости и сложности реализации режима опе¬
ративной модификации данных этот вопрос следует обсуждать только
при необходимости срочного доступа к модифицированным данным сра¬
зу после внесения изменений.
Таким образом, очевидно, что, прежде чем приступить к детальному
проектированию ИС, необходимо выбрать принципиальное техническое
решение, поскольку иначе будет очень трудно выполнить анализ реали¬
зуемости разработки. Без такого решения невозможно определить ин¬
терфейсы новой системы. Проектирование нельзя начинать, не имея
четкой концепции.
Очень часто оказывается, что если тщательный анализ с целью вы¬
бора оптимального технического решения не был проведен на этапе
52

оценки реализуемости, к нему уже не возвращаются. К сожалению, бы¬
вали случаи когда, по настоянию руководства или по рекомендации по¬
ставщика во время дружеского обеда принимались необоснованные
решения, которые приводили к непомерным затратам на реализацию
системы.
Распределенные системы. Распределенные системы создают при ана¬
лизе реализуемости дополнительные проблемы. В централизованных си¬
стемах все данные и функции локализованы. При рассмотрении же рас-
ПРЕДСТАВЛЕНИЕ
ОБРАБОТКИ
ДАННЫХ
Рис. 5.2 Распределенная обработка
пределенных способов обработки информации приходится учитывать
альтернативные варианты распределения данных и функций в различ¬
ных точках сети (рис. 5.2). Пользователю нужен конкретный набор
функций для решения своих задач. В первом приближении вычисли¬
тельные средства, реализующие эти функции, могут быть размещены
у него «под рукой», в центре или в некотором промежуточном пункте.
Основное проектное решение заключается в выборе оптимальной степе¬
ни распределения средств вычислительной техники.
Обычно существующая сеть не может обеспечить такое распределе¬
ние. Поэтому весьма вероятно, что при разработке системы потребует¬
ся рассмотреть вопрос о развитии сетевых технических и программных
средств. Необходимо учесть также и «человеческий фактор», что приве¬
дет к появлению новых задач при оценке реализуемости разработки.
Некоторые варианты, на первый взгляд вполне приемлемые, могут
оказаться впоследствии непрактичными. Например, иногда полагают,
что множество локальных функций свидетельствует о целесообразности
создания распределенной системы. Однако распределение данных и
функций должно быть предметом тщательного анализа. Так, к данным,
53

хранимым на одной локальной ЭВМ, может быть придется часто обра¬
щаться другой машине. Подобные вопросы проясняются только при
детальном рассмотрении вариантов.
Если указанные выше факторы не были учтены с самого начала, си¬
стема может стать гораздо более сложной, чем предполагалось. Это за¬
труднит реализацию системы, вызовет перерасход машинных ресурсов,
а также приведет к увеличению затрат и задержке ввода ее в эксплу¬
атацию.
Поскольку при исследовании реализуемости распределенных систем
приходится принимать во внимание множество факторов, здесь целесо¬
образен пошаговый подход. Последовательность выполнения шагов на
примере системы Modus приведена на рис. 5.3 и кратко рассмотрена
ниже.
1. Анализ данных
2. Анализ «функции-данные-время»
3. Логическое распределение данных и функций
4. Включение дополнительных (к выявленным на шаге 3 решениям) сервисных
функций
5. Документирование для каждого пункта обработки данных:
• реализуемых здесь функций;
• данных, подлежащих хранению;
• данных, передаваемых в другие пункты
6. Проработка каждого альтернативного решения с учетом имеющихся или предпо¬
лагаемых технических средств
7. Отсев экономически нецелесообразных решений
8. Оценка оставшихся решений
9. Выбор окончательного решения
Рис. 5.3. Анализ альтернативных решений при распределенной обработке
Анализ данных. Логическая структура данных разрабатывается с
помощью метода, описанного в гл. 13. Ее образуют основные агрегаты
данных и их связи.
Анализ «функции-данные-время». Определяется, какие данные нуж¬
ны для выполнения каждой функции, где находятся их источники и
куда направляются результаты. Должны быть тщательно рассмотрены
требования к актуализации данных и времени реакции системы.
Далее, могут быть составлены альтернативные схемы распределе¬
ния. Даже если система не должна быть распределенной и в ней ис¬
пользуются оперативные терминалы, этот метод может оказаться полез¬
ным. Таким образом, от избыточных требований по модификации фай¬
лов в реальном масштабе времени следует отказаться с самого начала.
Логическое распределение данных и функций. На этой стадии фор¬
мируется схема наиболее предпочтительного варианта системы. Основ¬
ной принцип формирования схемы заключается в том, что взаимосвя¬
занные группы функций распределяются в соответствии с территориаль¬
ным распределением соответствующих им неавтоматизированных опе¬
раций. При этом особенности технических и программных средств в рас¬
чет не принимаются, благодаря чему расширяется выбор вариантов.
Введение сервисных функций. Сам факт распределения данных и
функций приводит к необходимости реализации дополнительных средств
защиты информации в системе. Например, если организуется распреде¬
ленная обработка страховых полисов, то приходится обеспечивать акту¬
ализацию ставок страховых премий в каждом удаленном пункте. Ана¬
логично при удаленном сборе данных (например, по квартирной плате)
54

ОБРАБОТКА
ЗАКАЗОВ
1.0 ЗАПРОСЫ
2.0 ПРИЕМ
ЗАКАЗОВ
2.1 ПРОВЕРКА
КЛИЕНТА
КОНТРОЛЬ
ПОЛЕЙ
2.2 ВВОД
ЗАКАЗА
КОНТРОЛЬ
Ф.АЙЛА
ОБРАБОТКА
ЗАКАЗА
необходимо по крайней мере периодически передавать пакет данных в
тот пункт, где выполняется обработка файла клиентов. Для предотвра¬
щения нарушения целостности этого файла может потребоваться еже¬
дневная передача сведений об изменениях в^удаленный пункт. При об¬
работке одних и тех же записей некоторого файла или базы данных в
нескольких пунктах следует согласовывать изменения, а в некоторых
случаях — потребуется реализовать согласование в режиме реального
времени.
Необходимо выявить все дополнительные функции, которые обязаны
своим происхождением распределенной природе обработки данных, и
обязательно полностью
учесть их в проекте. Та¬
кие сервисные функции
оказывают иногда реша¬
ющее влияние на исполь¬
зование оборудования.
Для обеспечения жиз¬
неспособности системы
может потребоваться
централизация отдельных
файлов. Например, в си¬
стемах бронирования би¬
летов на самолеты при¬
меняются преимуществен¬
но централизованные
файлы. Если это не сде¬
лано, при обработке за¬
казов, поступающих с уда¬
ленных центров, чрезмер¬
но возрастает нагрузка
в сети ЭВМ.
Подготовка докумен¬
тов. Для каждого техни¬
ческого решения доку¬
ментируются все процес¬
сы и данные, а также межцентровые обмены и дополнительные сервис¬
ные функции.
Проектирование распределенной системы. Определяется конфигура¬
ция технических и программных средств системы. При отсутствии стан¬
дартных решений по программным и техническим средствам для оценки
проекта выбирается некая «модель» среды. Цель оценки — выбрать ва¬
риант проекта, который обеспечивает требуемый уровень надежности и
эффективности системы. Рассчитываются также предполагаемые затра¬
ты на разработку.
Оценка проекта. Проект исследуется с точки зрения таких общих
требований, как простота сопровождения и использования ИС, выдви¬
гаемых руководством службы ОД и пользователями, хотя подобные
требования и не должны быть предметом специального рассмотрения
при анализе реализуемости разработки. Необходимо составить, согла¬
совать с пользователями и ранжировать список критериев оценки.
Большое внимание должно уделяться вопросам эксплуатации. На¬
пример, имеется ли в удаленном пункте квалифицированный персонал
для восстановления и ведения файлов? Возможна ли адаптация распре¬
деленной системы в соответствии со структурными изменениями в орга¬
низации?
ПРОВЕРКА/
ОБНОВЛЕНИЕ
ЗАПАСА
Рис. 5.4. Функциональная декомпозиция транзакций
в системе обработки заказов
55

При окончательном выборе технического решения следует оценить,
насколько эффективно система будет выполнять свои функции, удов¬
летворяет ли она требованиям руководства и каковы расходы по каж¬
дому варианту проекта.
Пример анализа распределенной системы. Рассмотрим некоторую
систему обработки заказов, декомпозиция функций которой показана
на рис. 5.4. Прежде всего следует решить,- какие функции нужно выпол¬
нять централизованно, а какие — передать в местные бюро по приему
Прикладная функция
Тип данных
Операция
Время
фактиче¬
ское
реакции
требуемое
1.0. Запрос по заказу
Заказ
Чтение
Секунды
В течение
ночи
2.0. Прием заказа:
2.1. Проверка данных о клиенте
Клиент
Чтение
»
То же
2.2. Ввод заказа:
проверка полей
—
—
»
—
проверка файла
Продукция
Чтение
»
В течение
ночи
проверка запасов
Запасы
Модифи¬
Секунды
кация
проводка заказа
Заказ
Запись
—
Сервисная функция
3.0., Передача заказа
Заказ
Чтение
В течение
В течение
дня
ночи
4.0. Передача данных о клиен¬
Клиент
Модифи¬
То же
То же
те
кация
5.0. Передача данных о про¬
Продукция
Модифи¬
»
»
дукции
кация
6.0. Передача данных о запа¬
Запасы
Модифи¬
>
сах
кация
Рис. 5.5. Результаты анализа «функции—данные—время»
заказов. На рис. 5.5 приведены результаты анализа данных с указани¬
ем требуемых типов данных. Здесь же представлены результаты анали¬
за «функции — данные — время». Можно заметить, что функция «про¬
верка запаса» выполняет модификацию логического файла «запасы» с
секундной задержкой и требует актуализации данных также в секунд¬
ный интервал.
Различия между физическим временем ответа и реальной потребно¬
стью в актуальных данных, показанные на схеме для распределенной
системы, весьма существенны, поскольку мгновенная реализация изме¬
нений может вызвать необоснованное усложнение проекта.
Таким образом, чрезвычайно важно знать, для выполнения каких
функций нужны «сверхоперативные» данные и где требования к опера¬
тивности могут быть менее жесткими. Примером тому может служить
функция обработки заказов. Хотя при разговоре с клиентом по телефо¬
ну паузы не должны превышать нескольких секунд, реальная актуали¬
зация данных потребуется только в конце рабочего дня.
56

Для рассматриваемой системы возможны три варианта логического
распределения:
Вариант 1
Централизован¬
ная система без
распределения
Вариант 2
Вариант 3
Анализ заказов;
проверка клиента
просмотр поля;
просмотр файла;
прием заказа,
т. е. функции, только
читающие распреде¬
ленные файлы
Все функции, т. е. тре¬
буется восстановление
в реальном времени
всех модифицирован¬
ных файлов
Для вариантов 2 и 3 необходимы некоторые сервисные функции, в
том числе функции 3.0, 4.0 и 5.0, а для варианта 3, если потребуется
ежедневное восстановление, — и функция 6.0. Далее можно определить
объемы передачи данных для каждого варианта. Самая высокая за¬
грузка имеет место при варианте 1. Затем исследуются эскизные проек¬
ты всех трех вариантов, и на основе сравнения полученных оценок
выбирается наиболее предпочтительный вариант.
• Определение необходимости приобретения конкретного средства
• Подготовка списка возможных поставщиков
• Сбор сведений о поставщиках
• Оценка предлагаемых средств
• Выбор поставщика
• Подписание контракта
• Проверка возможностей приобретенного средства
Рассмотренный метод способствует принятию рациональных реше¬
ний по распределенной обработке данных и ее дальнейшему развитию.
Применение этого метода при оценке реализуемости разработки, веро¬
ятно, позволит сгладить воздействие таких факторов, как организаци¬
онные перестройки, обычно приводящие к перепроектированию систем.
Выбор поставщика. Выбор поставщика технических и программных
средств может потребоваться на любом этапе проектирования. Основ¬
ные решения по структуре технических средств, как правило, принима¬
ются на этапе стратегического планирования (гл. 2). Однако нередко
к ним приступают лишь на этапе оценки реализуемости, и этот процесс
продолжается на протяжении всего этапа проектирования.
Основные операции по выбору поставщика представлены на рис. 5.6.
Выбор следует начинать только после того, как сформулированы ос¬
новные принципы проектирования. Бессмысленно, например, пытаться
выбрать поставщика, если еще не установлена степень распределения
обработки данных. Конкурирующие фирмы-поставщики будут стараться
сбыть свое оборудование, а не заботиться об удовлетворении техниче¬
ских или организационных потребностей фирмы-заказчика.
Итак, продолжим описание процедуры анализа реализуемости.
В этом разделе исследуется и оценивается множество различных реше¬
ний, соответствующих тем требованиям, которые были выдвинуты при
выполнении операции 2.3 (см. рис. 5.1). Затем осуществляется выбор
Рис. 5.6. Последовательность операций при выборе поставщика
5.4.	Оценка альтернативных вариантов
57

наилучшего варианта в рамках, установленных на стадии стратегиче¬
ского планирования. Так, если принято, что сеть ЭВМ или база данных
должна сообща использоваться несколькими прикладными система¬
ми,— это и определяет основные требования к проекту. При оценке
реализуемости разработки ИС на основе более точных сведений необ¬
ходимо проверить, в какой степени данные требования выполняются.
С этой целью проводится ряд мероприятий.
Фиксация альтернатив. Подготавливается перечень имеющихся аль¬
тернатив с краткими комментариями (в предыдущем разделе приведе¬
ны прймеры возможных вариантов и методы их выбора). Для каждого
варианта указываются основные функции обработки, входные и вы¬
ходные данные, а также логические файлы. Следует также отметить
основные средства защиты, управления и обеспечения непротиворечиво¬
сти данных. Особое внимание необходимо обратить на разделение про¬
цессов обработки в пакетном и оперативном режимах. Тщательно рас¬
сматривается степень распределения обработки. Формулируются специ¬
фические требования к техническим и программным средствам и к ква¬
лификации персонала.
Эскизное проектирование вариантов. Для каждого варианта техни¬
ческого решения составляется проект. Метод структурного системного
проектирования, описанный в книге, для данного этапа представляется
слишком детальным. Однако меньшая точность не должна повлиять на
правильность результатов. Нужно стремиться к созданию приблизи¬
тельной модели системы и оценке ее стоимости, а не начинать с деталь¬
ного проектирования. Поэтому проблемы, порождаемые недостатками
проектирования (например, трудности в сопровождении программ),
здесь игнорируются. Для каждого проекта исследуются операционные
характеристики. Главное внимание при проектировании должно быть
сосредоточено на наиболее объемных транзакциях, больших файлах и
элементах особой сложности.
Сравнение альтернативных решений. Технические решения сначала
сравниваются с точки зрения установленных требований и стоимости.
Составляется краткий список вариантов для дальнейшего анализа. Эти
варианты затем оцениваются по следующим критериям:
• соответствию назначению;
• выполнению технических требований;
• предполагаемому уровню затрат;
• влиянию на другие существующие системы;
• накладываемым ограничениям;
• техническим проблемам управления;
- требованиям к квалификации персонала;
• требованиям к ресурсам основной ЭВМ;
• требованиям к испытаниям и тестированию;
• требованиям к переходу на новые вычислительные средства;
• необходимости изменений при внедрении системы;
• влиянию на другие разработки;
• стоимости разработки;
• стоимости эксплуатации;
• ожидаемому эффекту;
• гибкости.
Оцениваются также последствия выбора того или иного варианта:
не приведет ли это к радикальному изменению характера работы со¬
трудников. Например, возможно, придется пересмотреть требования к
квалификации персонала, никогда не имевшего дела даже с удален¬
ным вводом пакетов заданий в ЭВМ, если ему предстоит непосредст¬
58

венно использовать небольшие коммерческие ЭВМ с оперативными
терминалами. Аналогично установка сложной СУБД на основной ЭВМ
создает определенный риск, если разработчики программных средств
ранее с СУБД не работали.
В очень сложных или больших проектах рекомендуется поэтапная
реализация. При стратегическом планировании необходимо путем де¬
композиции довести «размерность» системы до приемлемого уровня.
Процесс декомпозиции часто продолжается на этапе оценки реализуе¬
мости разработки.
В качестве примера можно привести систему оперативной сортиров¬
ки чеков. Основная программа сортировки чеков очень сложна и имеет
жесткие временные ограничения. Поэтому было решено саму программу
и простейшие прикладные функции разработать на первом этапе, а
остальные прикладные функции — на трех последующих этапах. Для
всех четырех этапов установлены сроки, к которым требовалось принять
решения по дальнейшему развитию проекта. Это было сделано на этапе
оценки реализуемости проекта. Далее следовал общий анализ, а де¬
тальное проектирование, программирование и реализация выполнялись
для каждого этапа в отдельности.
Выбор наиболее предпочтительного варианта. В тесном сотрудниче¬
стве с пользователями проводится анализ по показателям «затраты—
эффективность» и выбирается наилучший вариант.
Анализ затрат. Для выбранного варианта уточняются результаты
анализа «затраты — эффективность», использованные при сравнении
альтернатив. Рассматрицаются все виды затрат.
Расходы на разработку с распределением по фазам:
• заработная плата;
• аренда машинного времени;
• прочие расходы, например транспортные и связанные со снабже¬
нием.
Эксплуатационные расходы:
• заработная плата;
• арендная плата;
• расходы по организации передачи данных;
• расходы по обслуживанию дополнительного оборудования;
• расходы по обслуживанию программных средств;
• расходы по сопровождению системы;
• прочие расходы.
При оценке экономического эффекта от реализации ИС учитывается
экономия фонда заработной платы, обусловленная сокращением штатов
или ограничением набора рабочих и служащих при ожидаемом расши¬
рении основного производства.
Косвенный эффект. Описывается кратко, желательно предложения¬
ми типа «информация о колебаниях валютного курса позволит сокра¬
тить потери валюты в размере . . .».
В сводке суммарных затрат и прибылей, которая теперь может быть
получена (рис. 5.7), не учитывается влияние различных скидок с налога
на капиталовложения и отсутствуют прогнозы.
Для учета этих факторов необходимо провести расчеты приведен¬
ных затрат. Для каждого периода следует рассмотреть инвестиционные
субсидии, льготы и налоги. Чистая прибыль определяется путем дискон¬
тирования на расчетный период. Затем можно определить срок самооку¬
паемости проекта. Он может отличаться от срока, полученного в сводке
суммарных затрат и прибылей. На рис. 5.8 представлены результаты
расчета приведенной стоимости (см. также рис. 5.7).
59

Общая сводка затрат и прибылей
Составил: RJW	Проект:	Обработка	счетов
Дата: 25.07.85	Этап:	Анализ	реализуемости
I 1986
| 1987
| 1988
| 1989
| 1990
1991
J Итого
Затраты па разработку
системы:
затрачено на разра¬
ботку
5025
5025
ожидаемые затраты
на разработку
44500
88750
—
—
—
133250
затраты на эксплу¬
атацию
—
16625
30650
31350
31450
31450
141525
суммарные ожидае¬
мые затраты
44500
105375
30650
31350
31450
31450
274775
суммарные затраты
49525
105375
30650
31350
31450
31450
279800
Ожидаемая прибыль:
замешенная стоимость
18000
59250
59250
59250
59250
255000
прибыль
—
—
10000
16000
22000
28000
76000
суммарная прибыль
—
18000
69250
75250
81250
87250
331000
Итоги:
прямая экономия в со¬
поставлении с ожи¬
даемыми затратами
(44500)
(87375)
38600
43900
49800
55800
56225
ожидаемые затраты
нарастающим итогом
(44500)
(131875)
(93275)
(49375;
425
56225
прямая экономия в
сопоставлении с сум¬
марными затратами
(-49525)
(87375)
38600
43900
49800
55800
51200
чистый нарастающий
итог
(49525)
(136900)
(98300)
(54400)
(4600)
51200
т.е. пок¬
рытие
расходов
через 43
мес.
после
01.07.86
Рис. 5.7. Общая сводка затрат и прибылей
Утверждение выбранного варианта. Полный отчет об экономической
эффективности проекта согласуется с пользователями, и после этого
выбранный вариант утверждается.
5.5.	Планирование последующих фаз
В процессе анализа экономической эффективности оцениваются ре¬
сурсы, необходимые для выполнения последующих фаз разработки. На
этой стадии требования к ресурсам уточняются и координируются с
планами других разработок, а также с наличными кадровыми ресурса¬
ми и ресурсами ЭВМ. Составляется и утверждается руководством
график проведения работ по проекту.
60

Составил: RJB
Дата: 26.07.85
Расчет приведенной стоимости
Проект: Обработка счетов
Этап: Анализ реализуемости
Пери¬
од
1
2
3
4
5
б
7
8
9
10
11
1 2
1985
86
87
88
89
90
91
20000
20000
49525
88750
13625
27650
28350
28450
28450
31286
46069
12442
12758
12803
10553
18000
69250
75250
81250
87250
8100
31163
33863
36562
39263
(69525)
(53089)
79569
28179
31695
40041
0,909
0,826
0,751
0,683
0,621
0,564
(63108)
(43852)
59756
19246
19683
22583
(63198)
(107050)
(47294)
(28048)
(8365)
(14218)
т.е. пок¬
рытие
расходов
через 48
мес.
после
01.07.86
7. Общая прибыль
8. Налоги
9. Чистые поступления
10. Фактор зависимости прибыли от
объема производства
11. Чистая приведенная стоимость
12. Чистая приведенная стоимость на¬
растающим итогом
Рис. 5.8. Результаты расчета приведенной (дисконтированной) стоимости
5.6.	Завершение анализа
Составляется итоговый отчет (его содержание приведено на
рис. 5.9), который обсуждается затем с руководством службы ОД и
пользователями. Он может быть представлен и другим заинтересован-
Введение
Распределение полномочий
Существующая система
Требования к системе
Анализ ключевых факторов эффективности
Вопросы ревизии, защиты и контроля данных
Предлагаемые системы
Эскизный проект системы
Отличия от существующей системы
Ограничения
Организационные и кадровые вопросы
Программное и техническое обеспечение
Защита и контроль данных
План разработки
Затраты и прибыли
Анализ альтернатив
Заключение и рекомендации
Приложения
Рис. 5.9. Содержание отчета об исследовании реализуемости системы
ным лицам, например главному бухгалтеру. После обсуждения итого¬
вый отчет корректируется по результатам обслуживания и дополняется
листом согласования. Утверждение отчета и принятие его в качестве
1. Приобретение оборудования
2. Субсидии
3. Инвестиции
4. Затраты на разработку
5. Затраты на эксплуатацию
6. Экономия от уменьшения налогооб¬
ложения
61

основы для последующей разработки свидетельствует о том, что подход
к проектированию выбран правильно.
Если раньше системные аналитики всегда добивались скорейшего
утверждения проекта, то теперь они убедились в том, что некоторые
экономически или технически нецелесообразные проекты приходится
«замораживать» до или даже после внедрения. Безусловно, есть смысл
потратить какое-то время на обсуждение альтернативных технических
решений, чтобы не пришлось компенсировать все недостатки на после¬
дующих этапах проектирования. Поэтому всесторонняя оценка реализу¬
емости разработки должна рассматриваться как непременное условие
успеха всего проекта в целом.
Глава 6
Системный анализ
6.1.	Введение
«Кратко основные цели системного анализа формулируются следую¬
щим образом: выявление недостатков существующей системы, уточне¬
ния необходимых изменений и нововведений и спецификация характери¬
стик новой системы. Иногда (например, в недавно созданной организа¬
ции) ИС еще нет, и в этом случае первый аспект системного анализа
теряет смысл.
Главная задача на данном этапе — полностью описать новую систе:
му, дав логические определения всех операций, а также хранимых, вход¬
ных и выходных данных. Физическая структура файлов, алгоритмы об¬
работки и детальное описание ручных операций прорабатываются на
следующих этапах.
В процессе системного анализа формулируются, уточняются и коор¬
динируются требования пользователей, выраженные в терминах основ¬
ной деятельности организации, причем особо выделяются те требова¬
ния, которые могут быть выполнены с помощью некоторой автоматизи¬
рованной системы. Подготовленная таким образом информация интер¬
претируется для проектировщиков и эксплуатационного персонала. Си¬
стемные аналитики часто недооценивают важность обеспечения посто¬
янного взаимодействия между пользователями и проектировщиками,
считая, что вполне достаточно провести одну встречу и подготовить со¬
ответствующий документ. Если к тому же на разработку и согласование
этого документа будет отведено слишком мало времени, то пользы от
него будет немного.
Спецификации, перегруженные техническими деталями, как правило,
трудно воспринимаются. Поэтому нередко и пользователи, и руководи¬
тели проекта принимают решения на основе собственного представления
об эффективности системы. В таких случаях на внедрение системы рас¬
ходуется намного больще средств, чем предполагалось, и в то же время
она не оправдывает надежд и оказывается сложной в сопровождении.
Решение всех этих проблем является задачей нескольких этапов про¬
ектирования, начиная с анализа реализуемости. На этапе же систем¬
ного анализа важно обеспечить взаимопонимание между разработчика¬
ми и пользователями и составить полное представление о назначении
системы и ее характеристиках.
В настоящей главе описывается метод структурного системного ана¬
лиза, разработанный фирмой BIS Applied Systems Ltd применительно к
62

системе Modus. Здесь показывается также, чем отличается данный ме¬
тод от общеизвестных методов системного анализа.
Традиционные средства (например, процедуры опроса) детально не
представлены, поскольку подразумевается, что они используются в
большинстве подобных методов. Кроме того, предполагается, что чита¬
тель знаком с традиционными методами системного анализа.
6.2.	Общие сведения о системном анализе
Прежде чем приступить к системному анализу, необходимо выбрать
принципиальное техническое решение, составить приближенную смету
затрат, сформулировать системные требования и оценить ожидаемый
эффект. Анализ можно начинать, только убедившись в том, что ожидае¬
мый эффект превышает-затраты. Очень важно при проведении анализа
придерживаться первоначально принятой схемы и отступать от нее лишь
при наличии достаточно веских причин.
Рис. 6.1. Элементы структурного системного анализа
При описании структурного системного анализа (ССА) предпола¬
гается, что исследование реализуемости разработки завершено. Однако
этот метод применим и в том случае, если такое исследование не прово¬
дилось.
Результатом ССА должна стать полная логическая схема, которая
послужит проектировщикам систем обработки данных и работникам
службы эксплуатации основой для разработки технического проекта си¬
стемы. В соответствии с методом ССА подробное физическое описание
дается только для входных и выходных данных, связывающих неавто¬
матизированные и автоматизированные процедуры, а также для форма¬
тов основных внемашинных документов и записей.
Основные задачи ССА перечислены на рис. 6.1, а в следующих раз¬
делах приведено их краткое описание. На этом же рисунке указаны
главы книги, в которых рассматриваются операционные диаграммы,
анализ данных и анализ ключевых факторов.
Формирование первоначального плана. Разработчики изучают пред¬
63

метную область, просматривают документацию и знакомятся с пользо¬
вателями. Устанавливаются и согласовываются права и обязанности
обеих сторон, определяются назначение и основные цели разработки
ИС. Составляется план проведения системного анализа.
Обследование существующей системы. Обследуются все существую¬
щие системы в сфере действия проектируемой ИС. Составляется их де¬
тальное описание. Кратко формулируются выявленные проблемы. При
подготовке документации применяются операционные диаграммы
(гл, 11).
Определение требований. Это наиболее ответственная операция, по¬
скольку именно на данной стадии определяются направления дальней¬
шего развития проекта. Методом анализа ключевых факторов (КФ)
исследуются цели создания системы, формулируются и согласовывают¬
ся с пользователем конкретные задачи, решению которых может спо¬
собствовать система. Чтобы выяснить объем необходимых изменений,
рассматриваются все процессы в существующих системах. Результаты
исследований вместе с новыми требованиями документируются для вы¬
полнения последующих работ.
Разработка эскизного проекта. Новые требования вызывают необхо¬
димость введения новых функций и новых отчетов или изменения дейст¬
вующих функций и хранимых данных. Документация по проектируемой
системе готовится с помощью операционных диаграмм, построенных
как сети взаимодействующих элементов. Поскольку выдвинутые требо¬
вания могут выполняться разными способами, обычно составляют не¬
сколько эскизных вариантов системы в виде операционных диаграмм.
Можно отсрочить фиксацию границ между неавтоматизированными и
автоматизируемыми операциями. Кроме того, могут быть оценены аль¬
тернативные варианты границ автоматизации. На этом этапе пере¬
сматривается смета, составленная на стадии оценки реализуемости, что
помогает выбрать наиболее эффективный вариант логической структу¬
ры системы.
Анализ данных. Для создания логической схемы данных хранимые
в новой системе данные подвергаются анализу. В процессе анализа не¬
обходимо проверить полноту их описаний и соответствие требованиям
предметной области. На этом этапе формулируется логическое опреде¬
ление всех данных.
Детальная проработка новой системы. Операционные диаграммы
расширяются введением дополнительных операций, отражающих раз¬
деление неавтоматизируемых и автоматизируемых процессов. Далее,
детально определяются процедуры с использованием языка описания
логики операции1. Логика автоматизируемых процессов проверяется
путем исследования профилей доступа (гл. 13). Этот процесс помогает
вскрыть в системе любые неоправданные усложнения и устранить их, а
также убедиться в том, что необходимые для выполнения операций дан¬
ные имеются в наличии.
Специфицируются форматы входных и выходных данных и экранов.
Приводятся примеры, демонстрирующие интерфейсы с автоматизируе¬
мыми процедурами. В заключение критически анализируется завершен¬
ность детального описания системы.
Составление плана разработки. Производится детальная оценка про¬
екта, рассматриваются приблизительные планы выполнения последую¬
1 В системе Modus для этих целей применяется так называемый структурный анг¬
лийский язык (Structured English). — Примеч. пер.
64

щих этапов и планы использования ресурсов (например, машинного вре¬
мени), пересматриваются сметы, корректируется общий план реализа¬
ции системы.
Подготовка спецификаций системы и сводного отчета. На всех пред¬
шествующих этапах создавались отдельные компоненты спецификаций
системы. Теперь они дополняются разделами общесистемного характе¬
ра, которые следует обсудить с компетентными пользователями, и раз¬
работка спецификаций может быть завершена. После каждой операции
анализа проводились соответствующие совещания с пользователями,
но окончательное согласование проектных спецификаций выполняется
именно на данном этапе. На основе этих спецификаций готовится свод¬
ный отчет для представления руководству.
6.3.	Графическое представление метода
На рис. 6.1 приведена краткая операционная диаграмма ССА. Такие
диаграммы позволяют компактно (на одной странице) представить все
операции в системе. В данном случае предметом нашего рассмотрения
является сам метод системного анализа. С помощью операционной диа¬
граммы мы можем более подробно отобразить потоки данных.
Детальная операционная диаграмма метода ССА показана на
рис. 6.2. Все указанные на ней основные операции будут рассмотрены
в последующих разделах. Однако к их изучению мы рекомендуем при¬
ступить лишь после ознакомления с гл. 11, 12 и 13, где описаны сами
операционные диаграммы, анализ ключевых факторов эффективности и
анализ данных. (Представленная здесь операционная диаграмма отоб¬
ражает третью операцию в диаграмме «Поэтапная разработка систем»,
о которой шла речь в гл. 3.)
6.4. Формирование первоначального плана
Назначается руководитель проекта. Он рассматривает план разра¬
ботки, который входит в документацию, созданную на стадии анализа
реализуемости системы, и включает исходные данные для составления
сметы и штатного расписания группы разработчиков. Члены проектной
группы, включившиеся в работу позднее, изучают результаты анализа
реализуемости и прочую документацию по прикладным разделам.
Руководитель проекта проводит совещание с заказчиком, где обсуж¬
даются и согласуются задачи и объект анализа. Разработчики должны
четко уяснить все возникающие вопросы до начала исследований. За¬
дачи, которые не могут быть решены с помощью разрабатываемой ИС,
необходимо исключить из рассмотрения. Например, если задание фор¬
мулируется следующим образом: «Система должна уменьшить стои¬
мость запасов на 20%», то для его выполнения придется полностью
автоматизировать отправку заказов поставщикам. Если же предпола¬
гается неполная автоматизация, формулировку нужно изменить, ска¬
жем, так: «Система должна допускать уменьшение стоимости запасов
на 20%». В этом случае необходимо обеспечить соответствующей ин¬
формацией службу управления запасами и провести анализ, способству¬
ющий решению данной задачи.
Для создания хорошего микроклимата в проектной группе (если
только эта группа не выполняла уже анализ реализуемости) целесооб-
3 Зак. 178.4
65

.АНАЛИЗ
РЕАЛИЗУЕМОСТИ
СИСТЕМНЫЕ	ОТЧЕТ
СПЕЦИФИКАЦИИ	V	РУКОВОДСТВУ
Рис. 6.2. Операционная диаграмма структурного системного анализа
разно организовать коллективное изучение результатов анализа. Кон¬
текстная диаграмма, операционные диаграммы верхнего уровня, логи¬
ческая схема данных в совокупности с ключевыми факторами эффек¬
тивности и характеристиками производительности системы могут слу¬
жить предметом дискуссий.
Руководитель проекта разрабатывает систему нормативной докумен¬
тации, регламентирующую ход разработки в целом.
66

6.5. Обследование существующей системы
Соответствующая операционная диаграмма представлена на рис. 6.3.
Обследование проводится с целью изучения прикладной области, выяв¬
ления насущных проблем и получения детальных сведений об имеющей¬
ся системе, что позволяет приступить к разработке новой системы.
Важнейшим аспектом этой работы является установление хороших де¬
ловых контактов между разработчиками и пользователями. Ниже дает¬
ся краткое описание каждой из перечисленных на рис. 6.3 операций.
2.ИССЛЕДОВАНИЕ
реализуемости'
ИНТ*
ИССЛЕДОВАНИЕ СУЩЕСТВУЮЩЕЙ СИСТЕМЫ
ОТЧЕТ О
РЕАЛИЗУЕМОСТИ
.... . ЕРВЬЮ,
ЗАМЕЧАНИЯ
(ПОЛЬЗОВАТЕЛЬ)
ГРАНИЦЫ
РАЗРАБОТКА
ПЕРВОНАЧАЛЬ¬
НЫХ ПЛАНОВ
ГРАНИЦЫ
СБОР
ДЕТАЛЬНЫХ
СВЕДЕНИЙ
1
РАБОЧИЕ
МАТЕРИАЛЫ
ПОДГОТОВКА
^ОПЕРАЦИОННЫХ
ДИАГРАММ 2
ОПИСАНИЕ
ДАННЫХ
ОБОБЩЕНИЕ
ПРОБЛЕМ
ИНТЕРВЬЮ,
ДОКУМЕНТАЦИЯ
ОПРЕДЕЛЕНИЕ
ОПЕРАЦИЙ
*\
3
БЛАНКИ
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ
' ИМЕЮЩЕЕСЯ
ЛОГИЧЕСКОЕ
ОПИСАНИЕ
ДАННЫХ
ЛОГИЧЕСКОЕ
ОПИСАНИЕ
ДАННЫХ
КОМПОНОВКА
ДОКУМЕНТАЦИИ
СВОДКА
ПРОБЛЕМ
Q
СУЩЕСТВУЮЩАЯ
СИСТЕМА
КРИТИЧЕСКИЙ
АНАЛИЗ
СОВМЕСТНО С 7
ПОЛЬЗОВАТЕЛЯМИ
  х
ЗАМЕЧАНИЯ
Рис. 6.3. Обследование существующей системы
Сбор информации. Подробную информацию о системе часто можно
получить методом опроса пользователей. Полезны и другие методы, на¬
пример анкетирование и изучение документации. Эти методы общеиз¬
вестны и здесь не рассматриваются.
Порядок опроса соответствует структуре организации-заказчика. По
завершении очередного опроса может быть вчерне составлен и согласо¬
ван с заказчиком фрагмент операционной диаграммы. Сфера обязан¬
ностей каждого должностного лица отображается на диаграмме опреде¬
ленной операцией с указанием входных и выходных потоков и доступа
к хранилищу данных.
Если нельзя сделать ссылки на действующие инструкции и стандар¬
ты, сведения, полученные при опросе, следует подробно документиро-
3*	67

вать. Типовые документы можно приложить к диаграмме. Для опера¬
ций верхнего уровня необходимо продумать план дальнейшей деком¬
позиции.
Собранная информация хранится в качестве рабочих материалов.
Составление операционных диаграмм. Далее составляется набор
операционных диаграмм для существующей системы. Операционные
диаграммы верхнего уровня по мере подготовки обсуждаются с руко¬
водством подразделений пользователей. Здесь важно договориться о
терминологии. Например, запись «дополнить перечень квитанций» менее
понятна, чем запись: «завершить обработку партии проданных това¬
ров». Жаргон в таком деле может послужить барьером для взаимопони¬
мания.
Скорее всего, в новой системе потребуется изменить специальную
терминологию, поэтому нет смысла использовать ее для описания су¬
ществующей системы.
Операционные диаграммы должны представлять полное техническое
описание существующей системы. Это поможет выявить ее «узкие ме¬
ста».
Там, где уже есть автоматизированные ИС, их необходимо отразить
на самом верхнем (техническом) уровне диаграммы, так как эти сведе¬
ния должны быть включены в техническое описание системы с тем, что¬
бы облегчить пользователю ее освоение.
Примерный комплекс операционных диаграмм применительно к су¬
ществующей системе приведен в гл. 11. Для иллюстрации процедур, рас¬
смотренных в данной главе, в качестве существующей системы выбрана
торговая информационная система CGT (рис. 6.4). В этой полностью
документированной системе каждый из блоков на рис. 6.4 должен быть
представлен операционной диаграммой.
Документирование операций. Любая операция нижнего уровня,
представленная на диаграмме, документируется с помощью бланков
операций. На рис. 6.5 показан пример такого бланка для системы CGT.
На основе анализа бланков операций принимается решение о возмож¬
ности и эффективности автоматизации каждой конкретной функции. На¬
пример, если для операции дано слишком общее описание, то прежде,
чем обдумывать способ ее автоматизации, следует повысить степень
формализации описания. Если же этого сделать не удается, речь может
идти только об обеспечении с помощью ЭВМ информацией сотрудни¬
ков, осуществляющих эту операцию, а не об автоматизации соответст¬
вующей функции.
Объем описания должен быть достаточно полным, чтобы процедура
была понятна. В нашем примере в процедуре легко разобраться по
данному описанию и форматам входных транзакций. В других случаях,
возможно, придется сослаться на документ, где описана эта процедура,
или дать ее словесное описание заново.
После заполнения всех бланков рабочие материалы следует распо¬
ложить в соответствии со структурой операционных диаграмм. Это
упростит доступ к информации.
Необходимо тщательно проверить все собранные о существующей
системе сведения. Составление операционных диаграмм уже само по
себе обеспечивает контроль интерфейсов между операциями. Для каж¬
дой операции нужно удостовериться в наличии требуемых входных
транзакций или хранилищ данных. Выходные данные должны быть по¬
лучены из этих источников или в результате внутренней (для операции)
обработки.
68

СИСТЕМА
CGT
69
Рис. 6.4. Сводка операций для существующей системы ОСТ. Символ U означает, что операция не изменяется

Определение данных. Для более глубокого изучения существующей
системы следует провести анализ данных. В гл. 13 описаны два метода
такого анализа. На рассматриваемом этапе проектирования вряд ли
нужен очень точный анализ, поскольку весьма вероятно, что детальные
характеристики данных на уровне элементов данных будут пересматри¬
ваться в ходе разработки новой системы. К тому же при этом может
возникнуть избыточность описания данных, так что выполнять деталь¬
ный анализ данных на этом этапе не имеет смысла. Целесообразно от¬
ложить его до завершения разработки эскизного проекта новой си¬
стемы.
ОПЕРАЦИЯ
ИМЯ: Изменение записи накладной диаграмма: 2.3
ДЛЯ КАЖДОГО: Квитанция по продаже
КОГДА:	Непосредственно после продажи
ВХОД:	Квитанция по продаже
ВЫХОД:	Измененная строка накладной
МЕСТО
выполнения:	Контора
ИСПОЛЬЗУЕМЫЕ
РЕСУРСЫ:	Клерк для выписки накладных
ПОСЛЕДНИЕ/ВЕРОЯТНЫЕ
ИЗМЕНЕНИЯ:	При больших объемах поставки операция усложняется, см.
прим. 1
ОЦЕНКА
ПРОИЗВОДИТЕЛЬНОСТИ: Клерк обрабатывает в день в среднем 10 накладных,
желательное число — 30
КОНТРОЛЬ:	По балансу
НЕОПРЕДЕЛЕННОСТЬ:	Нет
НЕФОРМАЛИЗОВАННЫЙ
ВВОД-ВЫВОД:	Расшифровка рукописных документов вместе с поставщиком
ПРИМЕЧАНИЯ: 1. Размер бланка накладной ограничен, использование несколь¬
ких бланков создает определенные проблемы
ПРОЦЕДУРА:	Примеры бланков накладной, заказа и квитанции прилагаются.
Процедура их заполнения очевидна
Рис. 6.5. Пример бланка операций для системы СОТ
В процессе исследования существующей системы предпочтение сле¬
дует отдать обобщенному логическому анализу данных. Он позволяет
быстро разработать логическую схему данных на основе операционных
диаграмм. Такую схему можно проверить и согласовать с пользовате¬
лями. С помощью логической схемы данных можно, во-первых, выявить
структурные ошибки в операционных диаграммах, а во-вторых, опреде¬
лить ,новые требования к ИС. Так, если в некоторой системе запись
«склад» является владельцем записи «клиент», то это означает, что кли¬
ент может иметь дело только с одним складом. С подобным ограниче¬
нием заказчик может быть не согласен, причем обнаружится это при
анализе логической схемы данных.
Выявление недостатков. Теперь модель существующей системы поз¬
воляет приступить к выявлению ее недостатков. В системе CGT анализ
рекомендуется начать с рассмотрения операций верхнего уровня, т. е.
исследовать процессы заключения договоров, доставки продукции
и т. д. Особое внимание при этом нужно обратить на следующие воп¬
росы:
70

• дублирование функций или информации;
• адекватность процедур контроля информации;
• число исключений из правил;
• неточности и ошибки в описаниях;
• перегрузки и недогрузки;
• возникновение «узких мест»;
• привычные или традиционные, но неоправданные действия (од¬
нажды потребовавшийся специальный отчет регулярно составляется,
но не используется).
В примере с системой CGT обнаружено много неточностей в описа¬
нии операции расчета при продаже партии товаров. Имеются замеча¬
ния и по контролю информации, так как при составлении счета на по¬
ставку допускаются корректировки квитанций без проверки их досто¬
верности.
В операции есть «узкое место»: анализ продаж трудно проводить в
течение дня. Это порождает две сопутствующие проблемы. Во-первых,
поставщики не могут получить необходимую информацию утром, чтобы
успеть выбрать товары и дать заявку на следующий день. Во-вторых,
продавцы не имеют точных данных о запасах и вынуждены вести соб¬
ственные реестры.
Проверка документации. Проверяется комплектность документации,
созданной на данном этапе. На ее основе составляется справочный том,
включающий краткие описания, аннотации и другие материалы по си¬
стеме. Такой справочник может пригодиться новым членам проектной
группы. Проверяется непротиворечивость документации, например, не
изменяются ли потоки данных при декомпозиции операции на состав¬
ляющие.
Критический анализ (совместно с заказчиком). Еще раз просматри¬
вается вся документация. Совместно с.заказчиком устанавливается, на¬
сколько точно определены границы исследования и функции в опера¬
ционных диаграммах верхнего уровня. Проверяется степень соответствия
операционных диаграмм, определения данных и описаний операций
нижних уровней существующей системы.
6.6.	Определение детальных требований
Определение требований к новой системе — наиболее ответственная
задача в системном анализе. От точности решения этой задачи зависит
качество создаваемой системы. Слишком часто процесс анализа прекра¬
щается сразу после завершения описания существующей системы, и
исследование целесообразных направлений ее развития для удовлетво¬
рения текущих и перспективных потребностей не проводится. Если при
оценке реализуемости системы детальные требования исследовались
лишь частично, то на рассматриваемом этапе эти требования должны
подвергнуться тщательному критическому анализу до определения вли¬
яния их реализации на существующую систему. На рис. 6.6 показана
операционная диаграмма определения детальных требований к систе¬
ме, а в гл. 12, посвященной анализу ключевых факторов эффективно¬
сти, описана соответствующая процедура.
Необходимо убедиться в том, что конкретные цели разработки сфор¬
мулированы точно и попятно и выявлены основные недостатки в суще¬
ствующей системе. Новые требования должны выражаться таким обра¬
зом, чтобы в создаваемой системе их выполнение можно было прове¬
рить.
71

Критический анализ требований. Ключевые факторы эффективности
и их количественные оценки, полученные при исследовании реализуемо¬
сти системы и рассмотренные в процессе выполнения первой задачи
анализа, сопоставляются с характеристиками существующей системы.
Затем они подвергаются критическому анализу и регистрируются в со¬
ответствии с формой, приведенной на рис. 6.7. Этот анализ проводится
совместно с заказчиком.
Рис. 6.6. Определение детальных требований к системе
Анализ ключевых факторов эффективности (КФЭ). Для упрощения
предположим, что основные факторы эффективности были выявлены на
этапе анализа реализуемости разработки ИС. В системе CGT ключевые
факторы эффективности установлены в соответствии со следующими
соображениями (номера факторов в скобках совпадают с приведенными
на рис. 6.7):
• Поставщики заинтересованы в скорейшем получении информации
о ценах, по которым их продукция продавалась на рынке, поскольку она
позволяла им принимать решения об ассортименте товаров для продажи
на следующий день. Они предпочитают иметь дело с тем рынком, кото¬
рый может дать точные и своевременные сведения (1).
72

03
К d
Я 03 о
t=C s о,
>> я я
Ч 03
О Э* К
8
я к
о 5
а о
So
с. о>
CQ
ж
ч
S
с-
н л
У ^
>1 аз
н
О 03
О tr
Я X
= о
03 X
а-О
~ CNJ
2
О
О
ЕЕ
(Я
ч
С-
X
ч
»я
я
X
03
Я
3
03
я
2
>.
d я
аз я
я
£
Ч 03
о d
_, 5Я
UO
-2 я
—
I я
CJ1 5*
>Я
О
О
Н
Я
9 S
ч d
О» 03
d я
О)
К со
§ *
Я 03
0-9-
*
ч
о
ч
ч
о
ч
О о CQ
к к
2 2
03 03
о. с,
CQ CQ
*
Ч
О
ч
оз
О
О-
*
5
6
ч
2
О
Ч
О
Со
u:j
к 03
Ч О
g.«
ь я
X х
о 03
Я 23
н о
Я Q.
03 £7
-9- о
-9- Я
(Т) из
см' со
со со
*
W
л
ч
03
VO
ч s
аг н
н
аг х ег £
Дг 2 fr о
О я О я
я
03
о
ч
X
оз
03
я
(—
о
о
о
о
сх
с
03
я
я
н
я
о
я
о
X
я
03
я
я
ч
я
03
о
-е-
03
я
н
ч
я
я
03
со
а
ю
*
ч
о
ч
2 °
из х
>я
о
к
ч
CD
VO
2 я
г §
л О
н CD н
03 Я 03
ЕГ Я ЕГ
н з н
о а.о
VO
о
о
73
Рис. 6.7. Анализ ключевых факторов эффективности для системы CGT

• Анализ поставок не отличается достоверностью результатов. Отме¬
чается большое число ошибок (2).
• На погашение несвоевременно оплаченных задолженностей затра¬
чиваются большие средства (3).
• Продавцам нужна была более точная информация о прибылях,
получаемых при реализации поставок (4).
• Трудно найти служащих, согласных начинать работу в 5 часов
утра (5).
• При торговых сделках цены устанавливаются без учета конъюнк¬
туры (6).
Как можно заметить, в данном примере при анализе ключевых фак¬
торов эффективности приняты целевые установки, которые могут быть
полностью выполнены с помощью автоматизированной системы, Напри-
I ПРОДУКЦИЯ |
СОРТ
| ДИАПАЗОН ЦЕН |
средняя цена
ОТЧЕТ О ЦЕНАХ НА РЫНКЕ /ЕЖЕДНЕВНО/
ПРОДУКЦИЯ!СОРТ I ДИАПАЗОН I СРЕДНЯЯ
| |ЦЕН | ЦЕНА 1
[номер
|НАКЛАДН0Й
[торговец |комиссионные]время [необходимая [стоимость*
1 1 1 продажи! ПЛОЩАДЬ | время
ОТЧЕТ о РЕНТАБЕЛЬНОСТИ /ЕЖЕДНЕВНО/
торговец
1 НОМЕР
| КОМИССИОННЫЕ
1 % комиссионных
НАКЛАДНОЙ
ОТЧЕТ О КОМИССИОННЫХ /ЕЖЕМЕСЯЧНО/
Рис. 6.8. Отчеты по маркетингу
мер, система не может сама по себе обеспечить снижение уровня задол¬
женности, но гарантирует решение такой задачи, как выписка счета в
течение следующего рабочего дня после заключения сделки, а это, как
выяснилось при обследовании, создает предпосылки для уменьшения
задолженности. Было также решено изменить практику платежей по
составляемым еженедельно ведомостям и ввести платежи по счетам,
выписываемым на следующий день после заключения сделки.
Что касается КФЭ «Рентабельность поставок» и «Конкурентоспособ¬
ность», было принято, что система должна лишь предоставлять инфор¬
мацию по указанным вопросам. Анализ завершился разработкой форм
некоторых отчетов, которые приведены на рис. 6.8.
Внесение изменений. На следующем этапе выявляются особенности
существующей системы, препятствующие достижению поставленных це¬
лей. Для этого составляется матрица, подобная приведенной на рис. 6.9,
где операции нижнего уровня (см. рис. 6.4) сопоставляются с систем¬
ными задачами. В ту же матрицу вносятся замечания по основным
проблемам, выявленным в существующей системе, которые не решаются
созданием новой системы. Для каждой системной задачи делается от¬
метка против операции, подлежащей изменению. Операции, не требую¬
щие никаких изменений, помечаются знаком U. Это полезно сделать и
в сводке операций (см. рис. 6.4).
74

Теперь можно систематизировать все операции и определить измене¬
ния, требуемые для построения новой системы. Внимание при этом дол¬
жно быть сосредоточено на операциях, наиболее важных для решения
ОСНОВНЫЕ ОПЕРАЦИИ /
/ ЦЕЛИ СИСТЕМЫ
I УСТНЫЙ ОТЧЕТ ПОСТАВЩИКАМ В СЕРЕДИНЕ ДНЯ
АНАЛИЗ НАКЛАДНЫХ В КОНЦЕ ДНЯ
•
ВРЕМЯ АНАЛИЗА НАКЛАДНОЙ МЕНЬШЕ 15 МИН
ВЫПИСКА СЧЕТА НЕ ПОЗДНЕЕ СЛЕДУЮЩЕГО ДНЯ
КОНТРОЛЬ ПО ИСТЕЧЕНИИ НЕДЕЛИ
ПРЕСЕЧЕНИЕ ЗАДОЛЖНИКОВ ЧЕРЕЗ 3 НЕДЕЛИ
МЕНЕЕ КВАЛИФИЦИРОВАННЫЙ ПЕРСОНАЛ
ПРОБЛЕМЫ В СУЩЕСТВУЮЩЕЙ СИСТЕМЕ
ИЗБЫТОЧНЫЕ ЗАПИСИ О ЗАПАСАХ
НЕАДЕКВАТНЫЙ КОНТРОЛЬ
ОПЕРАЦИИ НЕ ИЗМЕНЕНЫ
СМ
о
СМ
СП
см
СП
п
СП
о
ю
1.1
ФИЗИЧЕСКИЙ КОНТРОЛЬ ПОСТАВКИ
3
1.2
СОЗДАНИЕ ЗАПИСИ-НАКЛАДНОЙ
3
2.1
СОВЕРШЕНИЕ СДЕЛКИ
">
2.2
РЕГИСТРАЦИЯ СДЕЛКИ
Y
>
">
2.3
ИЗМЕНЕНИЕ ЗАПИСИ-НАКЛАДНОЙ
">
>
3.1
ПРЕДВАРИТЕЛЬНЫЙ АНАЛИЗ НАКЛАДНОЙ
3.2
УТОЧНЕНИЕ
>
>
>
3.3
КАЛЬКУЛЯЦИЯ СБОРА
3.4
ОКОНЧАТЕЛЬНЫЙ АНАЛИЗ НАКЛАДНОЙ
>
4.1.1
ПОДГОТОВКА И РАССЫЛКА СЧЕТОВ
>
4.1.2
ПРОВОДКА В РЕГИСТР
>
4.1.3
ПОДГОТОВКА И РАССЫЛКА СМЕТЫ
">
4.1.4
ПРИЕМ ПЛАТЕЖЕЙ
4.1.5
ПРЕСЛЕДОВАНИЕ ЗАДОЛЖНИКОВ
4.2
ВЕДЕНИЕ ГЛАВНОЙ БУХГАЛТЕРСКОЙ КНИГИ
3
4.3.1
РАССЫЛКА УВЕДОМЛЕНИЙ
3
4.3.2
ПРОВОДКА В РЕГИСТР ПОСТАВЩИКОВ
4.3.3
ПЛАТЕЖИ
3
I '
Рис. 6.9; Анализ изменений
главных задач, чтобы не выступили на первый план второстепенные
проблемы. Например, желательно избежать дублирования записей о за¬
пасах, и хотя необходимость ведения таких записей вызывает раздра¬
жение торговых агентов, эта работа отнимает у них не так уж много
времени.
75

Создание новых системных интерфейсов. Операции, требующие из¬
менения, по определению принадлежат новой системе, а операции,
оставшиеся неизменными, находятся за ее пределами. На этой стадии
выявляются все потоки данных между измененными и неизмененными
операциями. На диаграммах отмечаются, кроме того, потоки данных к
внешним объектам и хранилищам данных. Операции в указанных гра¬
ницах могут быть ручными или автоматизированными.
Потоки данных к дополнительным объектам делятся на входные и
выходные. Документация по этим интерфейсным потокам проверяется с
целью определения точной структуры данных, требований по их актуа¬
лизации, а также временных и объемных характеристик.
Если интерфейсный поток реализуется посредством машинного но¬
сителя, например магнитной ленты, на этой стадии можно не рассмат¬
ривать технические детали. Поскольку точная спецификация обработки
данных должна даваться на стадии проектирования, при анализе доста¬
точно просто указать способ реализации интерфейса.
Критический анализ требований. Каждая из описанных выше опера¬
ций в спецификации системы входит составной частью в раздел опре¬
деления детальных требований, которые следует тщательно проанали¬
зировать совместно с заказчиком. Необходимо, в частности, установить,
что задачи, поставленные заказчиком, хорошо отражены в КФЭ и рас¬
смотрены при их анализе и что система может успешно решать эти за¬
дачи. Нужно согласовать вопрос о внесении изменений в существующую
систему и обсудить интерфейсы новой системы. По определению новая
система должна включать все операции, которые подвергнутся измене¬
ниям. Для этого может потребоваться расширение границ системы. Же¬
лательно также выяснить, не ведутся ли другие разработки, пересека¬
ющиеся с данной, и при необходимости изменить приоритеты.
6.7.	Разработка эскизного проекта
На этой стадии системного анализа детальные требования служат
основой для создания эскиза логической структуры новой системы. Во
многих случаях сформулированным требованиям могут в принципе
удовлетворять несколько логических решений, и различия между ними
обычно затрагивают технические аспекты реализации. Поэтому для вы¬
бора конкретного варианта можно сравнить степень автоматизации
функций при разных подходах, но целесообразнее перенести рассмотре¬
ние этого вопроса на последующие этапы.
Если анализ реализуемости разработки выполнен тщательно, прин¬
ципиальные технические решения должны быть отражены в эскизном
проекте, и по этой «модели» можно рассчитать эффективность отдель¬
ных вариантов. Задачи, решаемые при создании эскизного проекта, пе¬
речислены на рис. 6.10.
Поиск вариантов логических решений. Возможность существования
различных логических решений можно показать на примере системы
CGT, где задача выписки счета может быть логически решена по мень¬
шей мере двумя способами: после заключения сделки, как в старой си¬
стеме (операция 4.11 на рис. 6.4), или во время совершения сделки (опе¬
рация 2.2).
Лучший способ поиска вариантов логических решений — взять не¬
сколько копий сводки операций для старой системы и модифицировать
их в соответствии с различными решениями. На рис. 6.11 показана одна
из таких модификаций для системы CGT. Логические изменения можно
76

обнаружить, сравнив эту диаграмму с диаграммой, изображенной на
рис. 6.4.
Здесь введена новая подсистема торговой информации, включающая
три операции по подготовке новых отчетов.
При анализе системных требований в отношении снижения уровня
задолженности было решено выписывать счета в процессе заключения
сделки. Это решение нетрудно реализовать, поскольку в существующей
3 РАЗРАБОТКА ЭСКИЗНОГО ПРОЕКТА
НОВОЙ СИСТЕМЫ
С
СУЩЕСТВУЮЩАЯ
СИСТЕМА
О
ПОЛЬЗОВАТЕПЬ
ПРЕИМУЩЕСТВА,
НЕДОСТАТКИ
!)<->
поиск
РАЗЛИЧНЫХ
ЛОГИЧЕСКИХ
РЕШЕНИЙ
	21
РАЗРАБОТКА
ОПРЕДЕЛЕНИЕ
ОПЕРАЦИОННЫХ
ГРАНИЦ
ДИАГРАММ
АВТОМАТИЗАЦИИ
2
3
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ
7
ИССЛЕДОВАНИЕ
СТОИМОСТИ
РЕАЛИЗАЦИИ
РЕШЕНИЙ
СТОИ¬
МОСТЬ*
2, АНАЛИЗ
РЕАЛИЗУЕМОСТИ
ПРИМЕРНЫЕ
ГРАНИЦЫ
АВТОМАТИЗАЦИИ
ТЕКУЩИЕ
ПЛАНЫ
РАЗРАБОТКИ
КРИТИЧЕСКИЙ
ПРЕДСТАВЛЕНИЕ
АНАЛИЗ
ПОЛЬЗОВАТЕЛЮ
1
ЭСКИЗНОГО
И ВЫБОР
У
ПРОЕКТА
РЕШЕНИЯ
НОВОЙ
6
СИСТЕМЫ 5
С
(РУКОВОДСТВО^
СЛУЖБЫ ОД J
ЭСКИЗНЫЙ ПРОЕКТ
НОВОЙ СИСТЕМЫ
Рис. 6.10. Разработка эскизного проекта новой системы
системе покупателю выдается документ о приобретении товара, который
можно просто расширить данными о его стоимости. Торговые агенты во
время продажи товара должны регистрировать цены, так как последние
меняются в течение дня. Соответственно изменяется и функция ведения
основного бухгалтерского регистра: из него удаляются операции по под¬
готовке и высылке отчета и ведомости. Ведомость в прежней системе
была нужна для взыскания задолженности. Теперь же вводится оплата
непосредственно по счету, так что наличие вспомогательных ведомостей
может только усложнить взаимоотношения покупателей и поставщиков.
77

СИСТЕМА
CGT
78
Рис. 6.11. Сводка операций для новой системы CGT. Символом А обозначены автоматизируемые операции

Из операции по ведению регистра поставщиков полностью изъяты
две составляющие. Процедура выдачи извещений о переводе была из¬
лишней даже в старой системе, поскольку итоговый анализ поставки
дает информацию о сумме оплаты.
После уточнения всех вопросов часто останавливаются на единствен¬
ном варианте новой системы. Если же это сделать не удается, рассмот¬
рение приходится откладывать на следующие этапы.
Подготовка операционных диаграмм. На основе диаграмм сущест¬
вующей системы составляются новые операционные диаграммы. При
этом вводятся новые операции, потоки и хранилища данных, а также
внешние объекты. Несмотря на кажущуюся завершенность сводок опе¬
раций, при составлении диаграмм нижнего уровня часто возникают
проблемы. Так, в процессе выполнения операции могут использоваться
какие-то данные, и при составлении операционной диаграммы прихо¬
дится выявлять их источник. Это могут быть внешние объекты, сущест¬
вующие либо еще не указанные на схеме операции или хранилища
данных.
В качестве примера на рис. 6.12 приведена операционная диаграмма
верхнего уровня системы CGT. Для новой операции (5) необходима ин¬
формация о рыночных ценах, источником которой служат ежедневные
сводки Би-Би-Си. Они передаются рано утром и содержат полную
сводку цен за день и их колебания. Если бы такая информация была не¬
доступна, потребовалась бы специальная операция по составлению свод¬
ки рыночных цен, причем сразу должен был возникнуть вопрос по
поводу непомерно высокой стоимости такой информации.
На рис. 6.13 показана декомпозиция описанной выше новой опера¬
ции. Можно заметить три новых хранилища данных, которые необхо¬
димо иметь для получения регулярных отчетов.
Ежедневные отчеты о ценах необходимо сохранять, так как они поз¬
воляют определить среднерыночные цены для анализа рентабельности
79

сделок. Хранилище данных «Продукция» содержит сведения о стан¬
дартных видах продукции и о местах их хранения. Поскольку цены за¬
висят от продукции, потребуется и хранилище данных «Сорт», в кото¬
ром должны накапливаться сведения о стандартных сортах продукции.
Новым хранилищам данных нужно уделить особое внимание. Например,
применительно к системе CGT уместен такой вопрос: «Можно ли хра¬
нить данные по всем стандартным видам и сортам продукции для всех
поставщиков?». При решении этого вопроса нужно учитывать, что на
одни виды продукции установлены международные стандарты, а оцен¬
ка других происходит более субъективно. Неточность информации в по¬
добных ситуациях необходимо иметь в виду.
АВТОМАТИЗАЦИИ
Рис. 6.13. Фрагмент новой системы CGT
На рассматриваемом этапе часто приходится продолжить обсужде¬
ние требований с пользователями, которые могут наилучшим образом
оценить точность информации.
Определение границ автоматизации. Для каждого из возможных ло¬
гических вариантов нужно решить, какие операции следует автоматизи¬
ровать, а какие должны выполняться вручную. Приблизительно грани¬
цы автоматизации определяются при анализе реализуемости системы.
Здесь же необходимо подтвердить ранее принятые решения.
В соответствии с требованиями к системе CGT операции 2.3, 3.1, 3.2,
3.3,	3.4 (см. рис. 6.11), безусловно, следует автоматизировать, так как
это единственный способ достижения поставленных целей. Без автома¬
тизации нельзя повысить точность и скорость обработки данных и одно¬
временно снизить требования к квалификации служащих. А это озна¬
чает, что и операция 1.2 должна быть автоматизирована.
Рассматривая расширение системы, представленное на рис. 6.13,
можно заключить, что операция 5.1, источником информации для кото¬
рой служат передаваемые по радио сводки Би-Би-Си, не подлежит ав¬
томатизации, тогда как операции 5.2 и 5.3, нуждающиеся в сборе и по¬
иске данных, могут быть автоматизированы. Граница автоматизации
системы на рис. 6.13 отмечена пунктирной линией, показывающей, в ча¬
стности, что если операция находится в пределах сферы автоматизации,
80

то и хранилища данных, необходимых для ее выполнения, тоже должны
быть в этих границах.
Различные операции по ведению счетов в системе CGT не вызывали
проблем с точки зрения обеспечения точности информации или трудоем¬
кости их выполнения. Внесение логических изменений было обусловле¬
но лишь стремлением ускорить процесс обработки данных в целом.
Однако операции по регистру сделок, характеризующиеся значительным
объемом обработки, представляются наиболее предпочтительными для
автоматизации.
Таким образом, как и при разработке эскизного проекта системы,
при определении границ автоматизации могут возникнуть альтернатив¬
ные решения.
Стоимостные оценки вариантов. Если был проведен анализ реализу¬
емости системы, эта операция также не должна вызвать затруднений.
В противном случае в соответствии с рекомендациями, данными в пре¬
дыдущей главе, потребуется выполнить оценку затрат для этапа анали¬
за реализуемости, сопоставив их с ожидаемым эффектом.
Вернемся к системе CGT. Допустим, что при оценке реализуемости
принято принципиальное решение об использовании с целью повышения
оперативности терминалов мини-ЭВМ. Терминалы должны применяться
для создания записей о поставках после приема товаров и для загрузки
«пачек» торговых квитанций вскоре после заключения сделок. Запросы
по отдельным поставкам могут вводиться с терминалов, а пакетная ге¬
нерация отчета по ходу сделок (предварительный анализ поставок) вы¬
полняется в фоновом режиме. С помощью терминалов- вводятся также
сведения об издержках для подготовки итогового отчета о поставках.
Таким образом примерно определились границы автоматизации.
Однако при закупке оборудования и программного обеспечения один из
поставщиков предложил традиционный пакет программ обработки сче¬
тов. Было решено, что операции по регистру сделок можно автоматизи¬
ровать именно этим способом, обеспечив приемлемое значение показа¬
теля «затраты — эффективность», так как, хотя эффективность и не вы¬
сока, затраты в данном случае весьма незначительны.
Представление альтернатив пользователю и выбор наилучшего вари¬
анта. Варианты эскизных проектов новой системы с указанием возмож¬
ных границ автоматизации согласуются с пользователями. Не все вари¬
анты будут в одинаковой степени соответствовать требованиям к новой
системе, но стоимостный и другие методы анализа должны помочь най¬
ти оптимальное решение.
Следует стремиться сократить число исследуемых вариантов и не
забывать о том, что часто критерием оценки служит показатель «затра¬
ты — эффективность».
Критический анализ эскизного проекта. Выбранный вариант обсуж¬
дается с руководством ОД и согласуется с общим планом разработки
ИС. На этом этапе следует всесторонне оценить влияние на технические
характеристики данной системы ресурсов, разделяемых с другими си¬
стемами, проверить обоснованность принятых решений и их качество.
При необходимости можно проконсультироваться с заказчиком.
6.8.	Анализ данных
Операционная диаграмма анализа данных приведена на рис. 6.14.
В результате его выполнения удается получить обобщенное представ¬
ление о структуре данных и еще раз уточнить и проверить эскизный
81

проект системы, а также определения элементов данных. Это позволяет
избежать появления неточностей и соответствующих корректировок про¬
екта на следующем этапе детального проектирования системы.
Определение состава хранилищ данных. Хранилища данных рас¬
сматриваются в качестве логических группировок элементов данных,
которые подлежат на этой стадии описанию. Прежде всего с помощью
соответствующих форм документов необходимо детально определить со¬
став элементов данных для каждого хранилища.
Определение логической структуры данных. Для этой цели приме¬
няется метод реляционного анализа данных, рассматриваемый в гл. 13.
Здесь же формируются только логическая схема данных, словарь эле-
Рис. 6.14. Анализ данных
ментов данных, сводка и определения типов данных. Логическая схема
данных для системы CGT приведена на рис. 6.15. Типы данных и связи,
которые не будут использоваться (например, «Номер	строки наклад¬
ной» и ее связи), можно удалить. Эту операцию целесообразно выпол¬
нить для всех хранилищ данных или, по крайней мере, для тех из них,
которые находятся в пределах границ автоматизации.
Критический анализ эскизного проекта. Устанавливается, что храни¬
лища содержат не менее одного типа данных. Это проясняет логику си¬
стемы и помогает проводить последующие проверки. Примеры по систе¬
ме CGT:
Хранилища данных	Типы	данных
Поставки	Поставки,	элемент поставки
Квитанции по продаже	Квитанция	по продаже,	эле¬
мент квитанции
Продукция	Продукция
Непосредственные ссылки на типы данных не всегда удобны, по¬
скольку они часто усложняют операционные диаграммы. Пользователи
охотнее оперируют понятиями более высокого уровня.
82

При проверке логической структуры данных могут выявиться невер¬
ные представления о сфере деятельности организации, поэтому потребу¬
ется модификация эскизного проекта новой системы. В системе CGT
аналитик может считать, что многие поставщики сдают на склад один
и тот же товар. В таком случае «сделки» должны быть напрямую свя¬
заны с «продукцией». Однако полученная структура данных показывает,
что «сделки» связаны с конкретными «поставками». Это в большей сте¬
пени соответствует реальной ситуации, поскольку продавец отвечает
перед поставщиком за реализацию его продукции. Таким образом, лю¬
бые ошибки в структурном представлении сферы деятельности могут
быть выявлены до детального определения системы.
ВЫПЛАТА i  ПОКУПАТЕЛЬ
НОМЕР
'1
j СТРОКИ I
| НАКЛАДНОЙJ
КВИТАНЦИЯ
ПО ПРОДАЖЕ
ПОЗИЦИЯ
КВИТАНЦИИ
СОРТ
ЕЖЕДНЕВНЫЙ
ОТЧЕТ
О ЦЕНАХ
Рис. 6.15. Логическая схема данных для новой системы CGT
Определение состава потоков данных и описание элементов данных.
Просматриваются потоки данных. Потоки, взаимодействующие с хра¬
нилищами данных, представляются в терминах одного или нескольких
типов данных, что упрощает логику и проверку системы. Часто боль¬
шинство элементов данных используется той операцией, с которой свя¬
зан поток данных.
Детальная документация по потокам данных должна включать спи¬
ски типов данных или описания логических записей на уровне элемен¬
тов данных. Необходимо убедиться в том, что состав потоков данных
верхнего уровня не противоречит содержанию потоков данных нижнего
уровня.
Затем дается полное описание элементов данных. Для каждого эле¬
мента определяется формат, диапазон значений, специальные значения
и синонимы его имени. В системе Modus для этих целей разработаны
конкретные формы документов (здесь они не приводятся).
83

Критический анализ результатов. Проверяются комплектность и
точность документации по анализу данных, а также ее соответствие
эскизному проекту новой системы. Результаты проверки согласуются с
администратором данных.
6.9.	Разработка детального проекта новой системы
На этой стадии выполняется большой объем преимущественно ру¬
тинных работ. Для завершения описания функций новой системы необ¬
ходимо проработать все детали, проверить их и определить интерфейсы
между автоматизируемыми и неавтоматизированными компонентами
систем. Соответствующая операционная диаграмма приведена на
рис. 6.16.
3.6 РАЗРАБОТКА ДЕТАЛЬНОГО ПРОЕКТА НОВОЙ СИСТЕМЫ
ЭСКИЗ
НОВОЙ
СИСТЕМЫ
/^ДОКУМЕНТАЦИЯ
[ ПО АНАЛИЗУ 4
\ ДАННЫХ
РАСШИРЕНИЕ
ОПЕРАЦИОННЫХ
ДИАГРАММ 1
АВТОМАТИЗИРУЕМЫЕ (
ОПЕРАЦИИ	Ч
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ
РУЧНЫЕ
ОПЕРАЦИИ
ОПРЕДЕЛЕНИЕ
* Л
ИНТЕРФЕЙСЫ,
ОПРЕДЕЛЕНИЕ
АВТОМАТИЗИРУЕМЫХ
ПОТОКИ
РУЧНЫХ
ОПЕРАЦИЙ 2
ОПЕРАЦИЙ 3
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ
АВТОМАТИЗИРУЕМЫХ
^ОПЕРАЦИЙ
СОПОСТАВЛЕНИЕ
ОПЕРАЦИЙ
И ЛОГИЧЕСКОЙ
СТРУКТУРЫ
ДАННЫХ	5
ОПРЕДЕЛЕНИЕ
ВХОДНЫХ
И ВЫХОДНЫХ
ДАННЫХ
И ФОРМАТОВ
ЭКРАНОВ
ТЕРМИНАЛОВ 4
ФОРМАТЫ
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ ДЛЯ
НЕАВТОМАТИЗИ-
РУЕМОЙ ДЕЯТЕЛЬ¬
НОСТИ
ДОКУМЕНТАЦИЯ
ПО АНАЛИЗУ
ДАННЫХ
КРИТИЧЕСКИЙ
АНАЛИЗ
ДЕТАЛЬНОГО
ПРОЕКТА
НОВОЙ
СИСТЕМЫ
<
ПОЛЬЗОВАТЕЛЬ
ЗАМЕЧАНИЯ
С
ДЕТАЛЬНЫЙ
ПРОЕКТ
НОВОЙ
СИСТЕМЫ
Рис. 6.16. Детальная разработка новой системы
Расширение операционных диаграмм. Если границы автоматизации
определены, то почти всегда требуется вводить дополнительные опера¬
ции. В частности, ими могут быть:
• процессы контроля;
• исправление ошибок;
84

• управление пакетами заданий;
• подключение и отключение терминалов.
Эти операции все еще представляются на логическом уровне, но от¬
ражают технические аспекты автоматизированных систем. Например,
в системе CGT (см; рис. 6.11) функция модификации записи о поставке
реализуется двумя операциями: «Собрать пакет квитанций по прода¬
же», пр.и выполнении которой группируются документы и формируется
контрольное число, и «Ввести пакет квитанций по продаже», являющей¬
ся процедурой ввода документов с терминала. На данной стадии часто
необходима более глубокая детализация операционных диаграмм.
Особую группу интерфейсных операций составляют интерактивные
процедуры. На рис. 6.17 приведен пример такой процедуры (не из си*
Рис. 6.17. Операционная диаграмма интерактивного процесса
стемы CGT). Точное определение взаимодействий подобного рода мо¬
жет быть отложено до следующего этапа. (Более подробно системный
анализ интерактивных систем рассмотрен в [1].)
Определение операций. Теперь с помощью бланков операций, при¬
менявшихся для анализа существующей системы, следует определить
все автоматизируемые и неавтоматизированные операции. При этом
должна быть показана точная логика выполнения новых процессов.
Ссылки на документацию предыдущих этапов не допускаются, посколь¬
ку все определения операций уже модифицированы.
На рис. 6.18 и 6.19 показаны примеры неавтоматизированной и ав¬
томатизируемой операций, составляющих запрос на поставку продукции
в системе CGT. Логика операции описана с помощью структурного язы¬
ка (гл. 15).
Описания автоматизируемых операций после завершения данной ста¬
дии будут преобразованы в машинную форму на этапе системного про¬
ектирования. Аналогично для ручных операций потребуются детальная
проработка, составление руководств и инструкций и введение их в дей¬
ствие. Например, необходимо решить вопрос о том, все ли служащие
могут использовать полный набор операций или каждый работает с не¬
которым его подмножеством.
Определение входных и выходных данных и форматов экранов. Сле¬
дует как можно более точно показать, что будет «видеть» пользователь
85

на границе между неавтоматизированной и автоматизированной частя¬
ми системы. С этой целью рекомендуется на примерах из сферы его дея¬
тельности представить структуру входных и выходных данных, а также
форматы экранов.
На рис. 6.20 приведен отчет поставщику об итогах анализа поставки
в системе CGT. Такой документ может быть рассмотрен руководителем
отдела сбыта. Бесполезно пытаться согласовать с ним форму описания
логической записи, содержащую имена данных и номера уровней. Тем
не менее полная спецификация на уровне элементов данных для вход¬
ных и выходных данных так же нужна для проекта системы, как и спе¬
цификации хранилищ и потоков данных.
ОПЕРАЦИЯ
ИМЯ: Запрос о партии продукции	ДИАГРАММА: 3.5.1
ДЛЯ КАЖДОГО: Партия продукции после утреннего звонки поставщику
КОГДА: Около 10 ч
ВХОД: Список номеров партий продукции
ВЫХОД: Бланк предварительного анализа накладной
МЕСТО ВЫПОЛНЕНИЯ: Контора
ИСПОЛЬЗУЕМЫЕ РЕСУРСЫ: Старший клерк, терминал с принтером
ПОСЛЕДНИЕ/ВЕРОЯТНЫЕ ИЗМЕНЕНИЯ: Контора должна переехать в течение
6 месяцев
ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ: Анализ должен быть выполнен в течение
5 мин после запроса
НЕОПРЕДЕЛЕННОСТЬ: Если цены слишком высоки или низки, клерк делает за¬
мечание
НЕФОРМАЛИЗОВАННЫЙ ВВОД-ВЫВОД: Обсуждение цены с поставщиком
ПРОЦЕДУРА: 1. Напечатать и передать номер партии продукции
2. Получить бланк предварительного анализа накладной, при ошиб¬
ке в номере партии исправить ее и возобновить обработку с ша¬
га 1
3. Проверить цены. При значительных отклонениях дать на распе¬
чатке замечания
4. Передать результаты поставщику
5. Повторять для всех номеров партии продукции
Рис. 6.18. Пример бланка операции (неавтоматизированной) для новой системы CGT
Сопоставление операций и логической структуры данных. Как мож¬
но заметить из рис. 6.19, даже детальное описание процедуры может все
еще быть неточным или содержать ошибки, поскольку в нем упомина¬
ются хранилища данных.
Хорошее средство контроля операций рассмотрено в гл. 13, где при¬
веден метод исследования профилей доступа. На рис. 13.6 дан пример
профиля для запроса по реализации поставки.
Анализируя профиль доступа и выявляя на каждом шаге наличие
подлежащей обработке информации, можно обеспечить тем самым дей¬
ственную проверку логики. Сложность профиля доступа может свиде¬
тельствовать о необоснованной сложности процесса обработки. Более
того, этот способ позволяет проверить логику обращения к данным.
Там, где к хранилищу данных «Поставка» требуется доступ по произ¬
вольным значениям ключа, может быть проверено наличие последнего.
86

В нашем примере возможен поиск поставки по номеру, заданному во
входном сообщении.
Число операций доступа зависит от логики процесса обработки.
Ясно, что требования к производительности ЭВМ будут в значительной
степени зависеть от объемов информации. Это часто приводит к тому,
что оперативную обработку вполне оправданно заменяют пакетной.
Не только операции, но и логическая структура данных могут под¬
вергнуться изменениям в процессе проектирования. Так, некоторые
типы данных или связи, не используемые в процессе выполнения опера¬
ций (тип данных «День» и соответствующая ему связь на рис. 6.15),
следует удалить. Требования по дальнейшему развитию системы долж¬
ны были быть приняты во внимание на всех предыдущих этапах проек¬
тирования. При этом на логическом уровне необходимо рассматривать
ОПЕРАЦИЯ
ИМЯ: Запрос о партии продукции	ДИАГРАММА:	3.5.2
(автоматизированная процедура)
ДЛЯ КАЖДОГО: Принятый номер партии продукции
КОГДА: Немедленно
ВХОД: Номер партии продукции
ВЫХОД: Предварительный анализ накладной
ПРОЦЕДУРА: 1. Принять номер партии
2. Проверить номер партии
2.1. Если верно, то найти запрошенные партии и квитанции
Если найдено
создать предварительный анализ накладной
Если не найдено
выдать сообщение об ошибке
3. Послать результаты на терминал
Перечень сообщений об ошибках:
Текст	Смысл
Неверный номер партии	Нарушены ограничения целостности
Рис. 6.19. Пример бланка операции (автоматизируемой) для новой системы CGT
только те данные, которые принадлежат конкретной системе. В процес¬
се разработки следует также учитывать особенности других систем,
разделяющих с проектируемой системой данные.
Оценка ресурсов. На основе логического проекта системы критиче¬
ски анализируются требования к машинным ресурсам и затраты на
разработку, определенные на стадии исследования ее реализуемости.
При проведении системного анализа могут быть скорректированы как
требования к проектируемым средствам, так и границы автоматизации.
Оценки необходимых ресурсов используются в качестве исходных дан¬
ных для окончательной ревизии детального проекта.
Ревизия детального проекта новой системы. Проверяется комплект¬
ность документации на новую систему. Однако цель ревизии состоит не
только в том, чтобы проверить полноту описаний системы, но и в том,
чтобы оценить качество разработки и согласованность принятых техни¬
ческих решений. Необходимо детально сопоставить на уровне элемен¬
тов данных бланки операций со связанными с этими операциями пото¬
ками данных, хранилищами данных и определениями входных и выход¬
ных данных. Проверяется корректность расширения операционных диа¬
87

грамм в границах автоматизации, а также корректность иерархии
операционных диаграмм и потоков данных.
Следует уточнить состав пользователей, привлекаемых к анализу де¬
тальной документации. Если на двух предыдущих стадиях к анализу
подключались руководители среднего звена и выше, то здесь нужны ру¬
ководители среднего звена и ниже, так как именно на их работу повли¬
яют конкретные проектные решения.
Поставщик
ДЖОН ХАРРИС ЛТД
Контора
НКГР Лондон СВ8
Получатель Л. ВЕРМИЛЛИ
Адрес
ИТАЛИЯ
Дата приема
Извещение
Дата продажи
Номер счета
14 июля 1980
978
15 июля 1980
195015
Номер
К-во
Описание
550
упак
ПЕРСИКИ "КРАСНЫЙ ДИКСИ"
Марка
К-во
Вес
Описание
К-во
Цена
Ф. ст.
Пенсов
50
А
40
1.00
40
00
481
Б
10
1.05
10
50
100
0.75
75
00
150
0.77
115
50
200
0.80
160
00
31
0.85
26
35
Итого
427
35
Хранение
Комиссионные
Сборы проч.
8.55
42.74
148.90
Сборы
200
19
Чистыми
227
16
Рис. 6.20. Результаты завершающего анализа накладной в новой системе CGT
Выше отмечалось, что уточненные оценки ресурсов ЭВМ и затрат на
разработку сравниваются с данными прогноза. Если затраты окажутся
намного выше, чем ожидалось, потребуется более серьезный анализ.
Для начала можно ограничиться пересмотром границ автоматизации
или исключить сложные операции, которые не играют решающей роли
при создании системы. Если же этого будет недостаточно, придется пе¬
ресмотреть цели разработки. Операции, предназначенные для решения
второстепенных задач, могут быть исключены из новой системы. На¬
пример, в случае чрезмерно высокой стоимости разработки в системе
CGT целесообразнее вообще отказаться от автоматизации ведения реги¬
стра сделок, чем реализовать эту функцию с помощью несовершенного
пакета программ.
Я8

6.10. Составление плана разработки
Пересчитанные ресурсы используются для подготовки программы
реализации всего проекта и составления сметы (гл. 18), после чего они
сопоставляются с планируемыми ресурсами других систем. При необхо¬
димости планы корректируются.
6.11. Подготовка и инспекция системной спецификации
Разрабатывается спецификация системы. Она может состоять всего
из двух отдельных документов: сводного отчета и детального описания
системы. Хотя полное описание требований к документации выходит за
рамки нашего рассмотрения, представление о ее содержании в соответ¬
ствии с требованиями системы CGT можно получить, ознакомившись с
рис. 6.21 и 6.22.
СОДЕРЖАНИЕ ОТЧЕТА
Введение
Ответственные
Основные подходы
Общие сведения
Сводка требований
Сводка альтернатив
Сводка затрат и результатов согласно альтернативным вариантам
Краткое описание рекомендуемого подхода
Описание обработки при рекомендуемом подходе
Сводка неавтоматизированных функций
Форматы входных и выходных данных
Ограничения
Преобразования
План разработки и реализации
План обучения
Примеры функции с точки зрения пользователя
Анализ затрат/результатов
Отвергнутые альтернативы
Отличия от предлагаемого подхода
Несоответствие требованиям
Рис. 6.21. Сводный отчет для представления руководству
В сводном отчете необходимо кратко изложить основные идеи и про¬
ектные решения. Они должны быть понятны каждому руководителю,
участвующему в обсуждении проекта. В процессе обсуждения следует
глубже изучить содержащуюся в спецификации системы документацию,
которая ранее уже представлялась сотрудникам подразделений-пользо-
вателей. Если на этапе системного анализа проводились инспекции и
согласовывались документы, то теперь участники совещания могут еще
раз обратиться к своим замечаниям и вновь рассмотреть те компоненты
системы, по которым было достигнуто соглашение либо предложено вы¬
полнить дополнительный критический анализ. Цель такого обсужде¬
ния— утвердить то, что может быть утверждено и переработать разде¬
лы, требующие изменения. Структурный системный анализ сам по себе
способствует реализации этой процедуры.
89

Совершенно очевидно, что решить все организационные и финансо¬
вые проблемы в один день невозможно. Поэтому на согласование про¬
екта в программе его реализации необходимо предусмотреть по край-
СИСТЕМНАЯСПЕЦИФИКАЦИЯ
Введение
Границы анализа
Ответственные
Ограничения на окончательный проект
Существующая система
Ориентация
Сводка операций.
Операционные диаграммы
Бланки операций
Логическая структура данных
Описание данных
Ссылки на эксплуатационную документацию
Стоимостные оценки
Требования к системе
Общие цели
Детальные требования
анализ КФЭ
информационные требования
Новые и модифицированные операции
Новая система
Общее описание
Сводка операций
Операционные диаграммы
Бланки операций
неавтоматизированных
автоматизируемых
Описание данных
документация по анализу данных
форматы входных и выходных данных
Интерфейсы с другими системами
Защита, безопасность и контроль данных
требования по контролю данных и файлов
основные положения по защите данных
контроль распределения данных
контроль ошибок
ревизия
альтернативные требования к средствам обработки
требования по восстановлению и рестарту
Уровни секретности данных
Объемы данных
Частота обработки
План реализации
Обязанности пользователей
Реализация
Повторное рассмотрение
Организация и обучение
Планы преобразования данных
Оценки стоимости и требуемых ресурсов
Оценки по показателю «затраты — эффективность»
Текущие и прогнозируемые затраты
Прибыли
прямые
косвены ые
Рис. 6.22. Системная спецификация
ней мере несколько недель, а если потребуется официальное утвержде¬
ние документов, составить расписание встреч руководителей соответст¬
вующих подразделений.
90

6.12. Преимущества структурного системного анализа
Последовательное применение методов, подобных предлагаемым в
системе Modus, в общем случае позволяет создать полную и точную спе¬
цификацию системы, которая с большой степенью вероятности удовлет¬
воряет выдвинутым требованиям. На последующих этапах проектиро¬
вания удается избежать крайне нежелательных последствий работы с
неполными и неточными исходными спецификациями.
С точки зрения администрации иерархическая организация докумен¬
тации упрощает восприятие системы на любом уровне. Таким образом,
руководство подразделений пользователей и разработчиков может бы¬
стро усвоить основные идеи и принципы работы системы. Нет необходи¬
мости вдаваться в подробности. В то же время конкретно поставленные
цели можно обсуждать и согласовывать в деталях, что наряду с выше¬
сказанным создает для пользователей реальную возможность участво¬
вать в создании системы.
Разделение фаз проектирования на несколько компактных задач
позволяет рационально распределить обязанности между участниками
проекта. Наиболее опытные специалисты могут привлекаться к разра¬
ботке проекта в качестве консультантов на сравнительно небольшой
срок. Им можно поручать решение основных задач, например планиро¬
вание, определение детальных требований к системе, разработку эскиз¬
ного проекта и т. д. Остальные члены проектной группы могут работать
под их руководством.
Более рационально может быть организована-работа пользователей.
Администрации уже не придется утверждать буквально «километры»
детальных спецификаций. Детальная структуризация операций проекти¬
рования дает возможность эффективно контролировать ход процесса
разработки, упростить расчеты.
Наконец, по мнению руководства, результаты анализа наглядно де¬
монстрируют хорошую подборку и комплектность документации и отде¬
лены от проекта машинной реализации системы. Тем самым специфика¬
ции удается освободить от излишних технических подробностей. Специ¬
алисты тоже заинтересованы в применении метода ССА. Поскольку схе¬
ма задач предполагает наличие специалистов с разными уровнями ква¬
лификации, перед ними можно ставить вполне конкретные цели. Не¬
большие объемы задач обеспечивают более частое получение результа¬
тов, поддающихся оценке в точно определенные сроки. Благодаря тому
что процедуры выполнения каждой задачи легко освоить, члены проект¬
ной группы могут быстрее переходить к решению более сложных задач
и даже участвовать в нескольких проектах. Документация составляется
единовременно, что позволяет избежать многократной корректировки
рабочих материалов и последующего оформления окончательной версии
спецификаций.
Наконец, важно отметить, что благодаря постоянно проводимым про¬
веркам комплектности и непротиворечивости документации на протя¬
жении всего этапа членам проектной группы больше не приходится да¬
вать пояснения по уже завершенным работам.
Литература
1.	lebbs D., Collins G. Real Time Svstems:	Management	and	Design.
/McGraw-Hill. 1977.
91

Глава 7
Проектирование системы
7.1. Введение
Проектирование системы начинается с изучения спецификаций, под¬
готовленных в процессе анализа, и завершается созданием специфика¬
ций программ. На этом этапе необходимо выполнить очень большой
объем работ. Система должна быть разделена на программы, данные
распределены по файлам, включены соответствующие процедуры обес¬
печения защиты и восстановления данных, определена потенциальная
эффективность системы и разработана документация для пользователей,
операторов и программистов. Это не простая задача, и ее успешное ре¬
шение часто целиком зависит от опыта и интуиции квалифицированных
проектировщиков.
Этап проектирования является промежуточным звеном между си¬
стемным анализом, программированием и эксплуатацией. Следователь¬
но, проект должен отражать как административно-управленческие, так
и технические аспекты функционирования системы. Однако программи¬
сты и операторы не всегда знакомы с производственной терминологией,
а язык технической документации непонятен системным аналитикам и
пользователям. В результате проект нередко удовлетворяет только од¬
ному из своих назначений. В системе Modus проект разделен на два
компонента: логический проект, в котором строится функциональная
модель предметной области, и технический проект, доводящий эту мо¬
дель до технической реализации. Именно такой подход и описывается
в настоящей главе.
Спецификации операций в логическом проекте не дублируют описа¬
ния, составленные на этапе системного анализа. Последние расширя¬
ются и верифицируются в такой степени, чтобы их можно было вклю¬
чить в спецификации программ.
Операционная диаграмма этапа проектирования приведена на
рис. 7.1. Рассматриваемый метод проектирования предполагает такую
последовательность операций:
1. Изучение требований.
2. Выделение в системе основных компонентов, типов данных и про¬
цессов.
3. Разработка логической структуры системы.
4. Усовершенствование этой структуры в соответствии с технически¬
ми ограничениями.
5. Завершение спецификации системы и переход к программиро¬
ванию.
Основной принцип этого метода заключается в декомпозиции проек¬
та на некоторое число небольших задач, результаты решения которых
поддаются проверке. Такой принцип не только упрощает контроль раз¬
работки, но и позволяет всем членам проектной группы эффективно
участвовать в проектировании. Описание программ и файлов выполня¬
ется по достаточно формализованной схеме, что позволяет наиболее
эффективно использовать квалификацию разработчиков.
Вначале проверяется завершенность спецификаций системы и фор¬
мально выявляются все противоречия. Система разделена на ряд ком¬
понентов в соответствии с прикладными функциями, что дает возмож¬
ность привлечь к проектированию и пользователей. Участие пользова¬
теля весьма желательно на протяжении всего процесса проектирования.
92

Сводится к минимуму число компонентов файлов или программ. Это
повышает гибкость реализованной системы при изменении целевых
установок.
В настоящей главе на примере анализа простой ситуации представ¬
лены все стадии проектирования. Структура главы показана на рис. 7.2.
Пример. Выбрать пример для иллюстрации технологии проектирова¬
ния системы не просто из-за большого объема системной документации.
Поэтому речь здесь пойдет о разработке упрощенной, но близкой к ре¬
альной системе.
Рис. 7.1. Операционная диаграмма этапа проектирования
Итак, некой туристической фирме необходима централизованная ин¬
формационная система для бронирования мест в отелях. Клиенты,
желающие заказать номер, обращаются к фирме, которая на основе ин¬
формации, хранящейся в ее картотеках, бронирует места в отелях. Фир¬
ма направляет заказы на бронирование в отели, а они уже затем ведут
все финансовые дела непосредственно с клиентом. Кроме того, фирма
должна обрабатывать отказы от бронирования или изменения в зака¬
зах и нести ответственность за хранение информации обо всех таких
изменениях.
Клиент может при бронировании либо указать конкретный отель
либо, получив 10%-ную скидку и задав определенную территориальную

9-1
ПРОФИЛЕЙ ПРОЕКТИРОВАНИЕ
ТРАНЗАКЦИЙ 7 4 , 7.5

зону и класс отеля, оставить выбор конкретного отеля за фирмой. Кли¬
ент заполняет бланк заказа по форме, представленной на рис. 7.3.
Часто запросы о наличии свободных мест делаются по телефону,.
Фирма может предоставить ту информацию, которой она в данный мо¬
мент располагает, но поскольку предварительные заказы по телефону
не принимаются, свободных номеров к моменту поступления заказа
может не оказаться. Поэтому на стадии оценки реализуемости системы
было решено обрабатывать телефонные запросы в соответствии со спи¬
ском свободных номеров, подготовленным в конце предыдущего дня.
АДРЕС
ч
1ЛЕНЫ ГРУПП
Ы
ФАМИЛИЯ
ИНИЦИАЛЫ
ВОЗРАСТ
ТЕЛЕФОНЫ*. ДОМАШНИЙ СЛУЖЕБНЫЙ
ДАТА
ЗАСЕЛЕНИЯ.
ОТЕЛЬ
(ЕСЛИ
ИЗВЕСТНО)
ТИП
НОМЕРА
ЧИСЛО
СУТОК
КОЛИЧЕСТВО
. ПРОЖИВАЮЩИХ .
КЛАСС ОТЕЛЯ
□
ДВОЙНОЙ I 1	СЕМЕЙНЫЙ
(ПОЖАЛУЙСТА, УКАЖИТЕ ТРЕБУЕМОЕ ЧИСЛО КОМНАТ)
ОДИНАРНЫЙ
□
Рис. 7.3. Бланк резервирования места в отеле
В перспективен конечно, может быть создана оперативная система, ко¬
торая будет среди прочих предоставлять и услуги такого рода.
Разрабатываемая автоматизированная система должна выполнять
следующие основные функции: ведение справочных файлов, первичную
обработку заказов, регистрацию изменений и отказов от брони. В систе¬
ме также должны храниться данные по каждому отелю и каждому кли¬
енту.
Были определены входные транзакции:
а) включение сведений об отеле;
б) изменение сведений об отеле;
в) удаление сведений об отеле;
г) заказ на бронирование (см. рис. 7.3);
д) исправление бланка заказа (можно изменить имя клиента, адрес,
телефон и уточнить детали заказа).
е) корректировка списка свободных номеров.
Для каждого принятого заказа должны вырабатываться подтверж¬
дения:
• подтверждение заказа клиента — одно на индивидуальный заказ
и по одному на каждого клиента в коллективном заказе; агенту фирмы
направляются две копии подтверждения для передачи клиенту в отель;

ПЕРВОНАЧАЛЬНЫЙ ЦИКЛ БРОНИРОВАНИЯ
96
Рис. 7.4. Укрупненная операционная диаграмма гипотетической системы. Граница автоматизации отмечена пунктиром

• подтверждение принятых агентом заказов, т. е. сводка принятых
заказов.
Кроме того, для каждого агента должна составляться сводка анну>-
лированных заказов.
Новая система будет также подготавливать следующие ежедневные
отчеты:
• о свободных номерах — список свободных номеров по всем отелям
региона для ответа на телефонные запросы;
• о заказах на бронирование — сводка обработанных и направлен¬
ных в отели заказов.
Аннулирование и прием заказов непосредственно в отелях будут вы¬
полняться либо агентами фирмы, либо соответствующей службой
отеля.
Для того чтобы фирма была правильно и своевременно информиро¬
вана, ее агенты и отели должны подготавливать «корректировки описи
номеров», содержащие данные о числе аннулированных заказов и о чис¬
ле заказов, принятых непосредственно от клиентов.
На этапе анализа реализуемости отмечалась необходимость получе¬
ния в перспективе отчетов для целей общего планирования и рекламы.
Операционная диаграмма системы представлена на рис. 7.4. Здесь
показаны потоки данных и логика первичной обработки заказов. Зака¬
зы контролируются, и при обнаружении в них ошибок выдается отчет
для повторной корректировки и ввода. Заказы, в которых указан конк¬
ретный отель, должны обрабатываться в первую очередь. Если же ука¬
зан только класс отеля, то сначала осуществляется поиск отеля нуж¬
ного класса, а затем выполняется обычная обработка заказа. В конце
каждого дня выдаются списки свободных номеров для ответов на теле¬
фонные запросы и списки забронированных мест для каждого отеля, в
который направлялись заказы.
В последующих разделах описывается детальная разработка отдель¬
ных компонентов системы в соответствии с методом структурного проек¬
тирования системы.
7.2.	Декомпозиция данных
После изучения системных спецификаций сразу приступают к анали¬
зу и документированию всех данных системы. Основная задача на этой
стадии — декомпозиция данных на простые компоненты и выявление
взаимосвязей между ними. Попутно проверяется полнота описаний дан¬
ных и уясняется смысл информационных потоков в системе.
Рассматриваются все элементы данных, хранимые или выдаваемые
системой. Каждый из них может быть либо введен в систему, либо полу¬
чен в результате обработки других элементов данных, которые логиче-/
ски связаны или сгруппированы. Выявляются взаимосвязи между этими
логическими группами. Для каждого элемента данных указывается его
источник.
Любые возникающие проблемы должны обсуждаться с аналитиками.
К началу проектирования все входные и выходные данные системы
должны быть согласованы с пользователями и не могут произвольно
изменяться разработчиком. Тем не менее если получение выходного эле¬
мента данных приведет к чрезмерным затратам на разработку или со¬
провождение системы, то у пользователя необходимо выяснить, насколь¬
ко важны эти данные.
На рис. 7.5 представлено содержание рассматриваемой задачи. Если
задача решается коллективом разработчиков, то лучше сначала про¬
4 Зкк. 1783
97

анализировать хранимые данные. После этого каждый разработчик
сможет рассматривать входные и выходные данные в пределах одной
логической области. Так, в приведенном выше гипотетическом примере
можно выделить обработку сведений о клиентах, отелях, заказах и т. д.
Операции выделения входов в систему и выходов из нее схожи и
требуют проверки наличия всей необходимой информации. Интерес
представляют такие сведения, как имена элементов данных, их форма¬
ты, методы контроля значений, частота и сложность обработки и др.
Наиболее быстро и просто такая проверка выполняется с помощью
бланка, показанного на рис. 7.6. Каждому входу в систему присваива¬
ется некоторый идентификатор, скажем, IN01, IN02 и т. д., а каждому
элементу данных — порядковый номер. Это обеспечивает наглядную
идентификацию всех элементов данных и может быть полезно при по-
1. Выявление входных данных
2. Выявление выходных данных
3. Анализ хранимых данных
4. Определение связей между хранимыми данными
5. Анализ взаимосвязанных файлов
6. Сопоставление хранимых и входных данных
7. Сопоставление выходных данных с хранимыми и входными данными
Рис. 7.5. Подзадачи при декомпозиции системы
следующем анализе перекрестных связей. Например, «Домашний теле¬
фон» должен обозначаться на бланке как IN04/6, т. е. как шестой эле¬
мент данных на входе IN04 «Заказы». Там, где требуются особые про¬
верки, метод контроля указывается в графе «содержание».
Аналогичная форма используется для описания выходных данных.
Идентификаторы показывают, что компоненты — выходные, например
0Р01—«Список корректировок», 0Р02 — «Отчет по отелям» и т. д.
Графа «Содержание» остается незаполненной до проведения перекрест¬
ного анализа, после чего в нее вносятся специальные замечания по
формату вывода.
Спецификация системы подробно описывает все хранимые в ней
данные. Если реляционный анализ данных (гл. 13) не выполнялся на
этапе системного анализа, его необходимо выполнить на этой стадии.
Каждый выявленный тип информационных объектов становится логи¬
ческим основным файлом, который описывается по форме, аналогичной
форме описания входных данных.
Довольно часто новая система должна использовать данные, физи¬
ческие характеристики которых уже заданы, например файлы из дру¬
гой системы. Для определения структуры интерфейсных файлов следует
выполнить соответствующий анализ (гл. 14). Если структура файла
слишком сложна, приходится применять методы реляционного анализа
данных (гл. 13). Однако иногда целесообразнее провести реструктури¬
зацию файла. Затраты на создание программы переформатирования
записей полностью окупятся за счет упрощения программ доступа к
этому файлу.
Последние две подзадачи заключаются в сопоставлении каждого
элемента данных, хранящегося в системе или выводимого из нее, с
источником. Графа «Содержание» в форме определения данных запол¬
няется в том случае, если описываемый элемент непосредственно полу-
98

Наименование:
Данные До брониро¬
ванию
Вид: ввод с клавиа¬
туры на диск
Частота: ежедневно
Объем:
Ежед¬
невно:
мин.
0
макс.
3000
средн.
800
Иденти¬
фикатор:
IN04
к
Коэффициент
ч
о
с
Название поля
Уровень
иерархии
повторения
Формат
%
мин .
макс.
среди.
1
Тип записей
9
2
Номер клиента
9(8) А
3
Имя
1
А (30)
4
Адрес
1
5
Строка адреса
2
2
3
3
А (30)
6
Домашний телефон
1
9(10)
7
Рабочий телефон
1
9(10)
8
Группа
1
9
Член группы
2
0
8
3
10
Фамилия
3
А (20)
11
Инициалы
3
А(6)
12
Возраст
3
9(2)
13
Дата начала отпуска
1
А(8)
14
Число суток
1
9(2)
15
Количество человек
1
9
16
Район
1
99
17
Класс отеля
1
9
18
Номер отеля
1
9(6)
19
Тип номера
1
9(6)
Рис. 7.6. Бланк описания входных данных
чается из другого элемента данных в системе. Любые пропуски в этой
графе либо означают, что должен существовать процесс, требуемый для
получения элемента данных, либо указывают на недостаток исходной
информации для проектирования.
7.3.	Декомпозиция процессов
По завершении анализа данных проводится анализ требований к
процессам обработки. Если системный анализ не выполнялся, специфи¬
кации часто оказываются неполными или неточными. На этой стадии
разработки их необходимо исправить. Прежде всего следует выделить
основные процессы, которые затем должны быть изучены аналитиками
и пользователями.
Прежде чем перейти к описанию подзадач, целесообразно объяснить
значение термина «процесс». Процессом называют событие, затрагива¬
ющее некоторую группу данных. Это может быть определенный вид
контроля, модификации, генерации отчета или вычисления итогов1.
Группировка данных может представлять собой какую-то логическую
запись либо логический основной файл. Процесс рекомендуется опреде¬
лять таким образом, чтобы осуществлялась обработка не более одного
файла. Только в этом случае процесс останется простым и обеспечит
гибкость на дальнейших этапах проектирования. Сложность процесса
зависит от реализуемой функции, но обычно его описание должно уме¬
1 Процесс можно рассматривать как некоторую логически законченную последова¬
тельность действий, выполняемую в предметной области. — Примеч. пер.
4*
99

щаться на одной странице и быть достаточно детальным для последу¬
ющего использования в спецификации программы. Если уже был про¬
веден системный анализ, то описание логики претерпит лишь небольшие
изменения, за исключением тех ситуаций, когда процесс слишком гро¬
моздок или сложен и необходимо его деление на компоненты. Процес¬
сы определяются при исследовании потоков данных. Подзадачи, кото¬
рые должны быть решены на этой стадии, приведены на рис. 7.7. Здесь
представлен очень простой и универсальный метод определения процес¬
сов. Существует и другой, более точный метод, используемый в системе
Modus, но в настоящей книге он не описывается.
Первый шаг согласно рассматриваемому методу заключается в ис¬
следовании «жизненного цикла» каждого входного потока и логическо¬
го основного файла. Например, реализация запроса потребует выполне¬
ния нескольких процессов, включая контроль типа и диапазона значе-
1. При рассмотрении каждого входа в систему и «жизненного цикла» каждого ло¬
гического основного файла процессы идентифицируются и документируются
2. Вводятся процессы, обеспечивающие целостность данных и ревизию системы, а
также значения элементов данных
3. Сопоставляются хранимые и входные данные для процессов
4. Идентифицируются элементы данных, не выявленные при сопоставлении
5. Идентифицируются и перечисляются ограничения и перспективные потребности
6. Проводится подготовка к критическому анализу
Рис. 7.7. Подзадачи при декомпозиции процессов
ний элементов данных и их сопоставление с файлами клиентов и отелей.
Если системный анализ проводится, то в строке «Для каждого» бланка
описания процесса указываются обрабатываемые данные. Любая опера¬
ция будет, вероятно, соответствовать нескольким простым процессам:
Такие процессы могут быть выявлены для всех данных в системе.
Дополнительные процессы вводятся при наличии специальных требова¬
ний по контролю, проверке отношений между элементами данных и
обеспечению целостности данных. Например, если удаляются сведения
по некоторой территории, должны быть удалены и сведения о располо¬
женных здесь отелях, иначе могут возникнуть проблемы, например при
печати названия территории в отчете.
При исследовании элементов данных можно было отметить, что вре¬
мя от времени необходима инициализация их значений, и поэтому сле¬
дует определить процессы для всех событий, имеющих место ежедневно,,
ежемесячно и ежегодно. Может также потребоваться инициализация
значений данных перед конкретным видом обработки. Контрольный
лист, предлагаемый в системе Modus, помогает разработчикам при вы¬
явлении процессов не упустить важных деталей.
На этом этапе проектирования документируются только логические
процессы; способ их технической реализации здесь пока еще не рас¬
сматривается.
Многие процессы могут быть общими для нескольких операций. На¬
пример, контроль чисел преобразования дат, форматирование и подго¬
товка заголовков для страниц используются во многих операциях ИС в
рассмотренном выше примере. В таких случаях создается один обоб¬
щенный процесс и ему впоследствии соответствует общий модуль.
Процессы документируются с помощью специального бланка
(рис. 7.8). Заголовок в верхней части бланка отражает назначение про¬
100

цесса, данные, которыми он оперирует, и условия его выполнения. Далее
дается графическое представление процесса. Диаграммы впоследствии
будут скомпонованы вместе для формирования технической схемы си¬
стемы. В последнем разделе бланка приводится детальное описание
бланк процесса
ПРОЦЕСС	подготовить СПИСОК БРОНИ ПО ОТЕЛЮ
ДЛЯ КАЖДОГО	ЗАКАЗ НА БРОНИРОВАНИЕ В РАЙОНЕ
КОГДА	ПОСЛЕ ВЫБОРКИ ДАННЫХ ПО ОТЕЛЮ, РАЙОНУ	И НОМЕРУ
ДИАГРАММА
БРОНИРОВАНИЕ
ПО РАЙОНУ
+ L
СПИСОК
БРОНИ
ПО ОТЕЛЮ
ОПИСАНИЕ:
(СМ. ОПЕРАЦИЮ 10}
1. ДЛЯ КАЖДОЙ "ДАТЫ БРОНИРОВАНИЯ"
1.1 ПЕЧАТЬ "НАЗВ. Р-НА", "ДАТА БРОНИРОВАНИЯ"
1.2 ДЛЯ КАЖДОГО "ОТЕЛЯ"
1.2.1 ДЛЯ КАЖДОГО "ТИПА НОМЕРА" - ВЫЧИСЛИТЬ "НОМЕР
СВОБОДЕН"^ "ЧИСЛО НОМЕРОВ"— "ЗАБРОНИРОВАНО
НОМЕРОВ"
1.2.2 ПЕЧАТАТЬ СТРОКУ
1.2.3 НАКАПЛИВАТЬ ИТОГИ ДЛЯ КАЖДОЙ "ДАТЫ
БРОНИРОВАНИЯ" ПО КАЖДОМУ "РАЙОНУ"
1.3 ПЕЧАТАТЬ ИТОГИ ДЛЯ "ДАТЫ БРОНИРОВАНИЯ" ПО "РАЙОНАМ"
Рис. 7.8. Бланк описания процесса
процесса в простой форме, понятной пользователю. Оно предназначено
для разработки программной спецификации и составляется на струк¬
турном языке, описанном в гл. 15.
Вся информация, содержащаяся в бланках процессов, используется
на,следующих этапах проектирования. Так, на этапе логического проек¬
101

тирования потребуются сведения из заголовков для компоновки процес¬
сов, а при формировании логической схемы системы — диаграммы.
Описания послужат основой для составления спецификаций программ.
Поэтому, хотя заполнение бланков процессов и может показаться слож¬
ным делом на стадии декомпозиции процессов, на самом деле эта про-',
цедура уменьшает объем детальной документации, необходимой на
дальнейших этапах проектирования. Если бланки процессов заполня¬
лись в соответствии с методикой системного анализа, то для определе¬
ния логики системы во многих случаях потребуется лишь упорядочить
уже имеющуюся в них информацию. Средства машинной обработки тек¬
стов помогут значительно упростить эту работу.
ПРОЦЕСС
ДЛЯ КАЖДОГО
КОГДА
ПРОФИЛЬ
ТРАНЗАКЦИИ
П04 - ПРОВЕРКА - БРОНИ
ЗАПРОС НА
БРОНИРОВАНИЕ
ВВОД
П14 - ПРОВЕРКА - РАЙОНА
ДЛЯ - БРОНИ
ЗАПРОС НА
БРОНИРОВАНИЕ
ПОСЛЕ ВЕРИФИКАЦИИ
ОСНОВНЫХ ПОЛЕЙ
П24 - ПРОВЕРКА - ОТЕЛЯ
ДЛЯ - БРОНИ
ЗАПРОС НА
БРОНИРОВАНИЕ
ПОСЛЕ ВЕРИФИКАЦИИ
ОСНОВНЫХ ПОЛЕЙ
П34 - ПРОВЕРКА - КЛИЕНТА -
ДЛЯ - БРОНИ
ЗАПРОС НА
БРОНИРОВАНИЕ
ПОСЛЕ ВЕРИФИКАЦИИ
ОСНОВНЫХ ПОЛЕЙ
П99 - ПРОВЕРКА - НОМЕРА -
КЛИЕНТА + ПРОВЕРКА - ЦИФРЫ
НОМЕР КЛИЕНТА
В ЗАПИСИ
ВВОД
014—ОБР—ОТЕЛЬ - ДЛЯ -
РАЗМЕЩ
ЗАПРОС НА
БРОНИРОВАНИЕ
БЕЗ ОШИБОК
ПОСЛЕ ПРОВЕРКИ
ФАЙЛА РАЙОНОВ
024-ОБР- НОМЕР -
В - ОТЕЛЕ
НОМЕР В ОТЕЛЕ
099—ОТЧЕТ—ОШИБКИ—ВВОДА
Рис. 7.9. Фрагмент указателя бланков процессов
Перекрестный анализ данных и процессов. После составления блан¬
ков процессов выполняется перекрестный анализ хранимых данных и
выходных документов. Основная цель при этом — выявить процессы, ко¬
торые создают или модифицируют каждый элемент данных. Во время
анализа должно быть завершено заполнение всех бланков описания эле¬
ментов данных.
При рассмотрении входных потоков или логических основных фай¬
лов и процессов, с помощью которых ведется их обработка, обнаружи¬
ваются новые элементы данных, например индикаторы ошибок, или
элементы данных, выбранные из справочного файла для последующей
обработки. Эти элементы данных также документируются.
Указатель бланков процессов. Так как даже небольшая система рас¬
членяется на множество процессов, полезно создать и вести их указа¬
тель. На рис. 7.9 показан фрагмент такого указателя. Его последняя
графа заполняется на следующем этапе.
102

Ограничения и перспективные потребности. При анализе специфика¬
ции системы могут быть установлены ограничения на обработку и опре¬
делены перспективные потребности в ИС. Все эти сведения должные
быть зафиксированы, поскольку они могут оказать влияние на техниче¬
ское проектирование. На рис. 7.10 первые два пункта отражают ограни¬
чения на реализацию системы, а остальные — перспективы развития,
которые принимаются во внимание при анализе спецификаций, но де¬
тально не прорабатываются. Может случиться, что в процессе развития
системы в нее потребуется включить новые средства. Такие случаи сле¬
дует предусмотреть заранее.
Ограничения на систему могут накладываться службами эксплуата¬
ции, программирования, системного программирования или внешнего
1. Бронирование номеров в конкретных отелях должно производиться до брониро¬
вания района
2. Все «Списки редактирования» должны одновременно генерироваться в одном
отчете
3. При выделении номера следует предусматривать возможность заказа дополни¬
тельных услуг, например телевизора
4. В перспективе запросы о наличии свободных номеров необходимо обрабатывать
в оперативном режиме
5. При бронировании мест на группу в дальнейшем нужно предусмотреть воз¬
можность размещения членов группы по разным отелям района, если в заказе
не был указан конкретный отель
Рис. 7.10. Ограничения на обработку и перспективные потребности в ИС
контроля. Хотя их пожелания и рассматриваются при техническом про¬
ектировании, часто удобно систематизировать их на данной стадии, что¬
бы и производственные, и технические .ограничения были зафиксирова¬
ны в едином документе.
Эти ограничения могут распространяться на оборудование (напри¬
мер, на типы дисководов и каналов связи), планирование заданий, рас¬
пределение основной памяти, контроль данных, стандарты, используе¬
мые ППП, время реакции системы и отдельные компоненты конфигура¬
ции ЭВМ. Ограничения могут отражатр предполагаемые изменения в
технических или программных средствах.
При анализе реализуемости проекта обычно оцениваются и требуе¬
мые технические ресурсы. Полученные оценки и должны в первом при¬
ближении выступать в качестве проектных ограничений. Любое превы¬
шение этих оценок должно быть тщательно изучено.
Критический анализ. Вся разработанная документация должна под¬
вергаться критическому анализу. Из-за большого объема документации,
вероятно, целесообразно за один просмотр проанализировать все про¬
цессы, связанные с одним входным потоком или одним логическим ос¬
новным файлом.
7.4.	Разработка профилей транзакций
Профиль транзакций — это логический путь, который транзакции
(входные данные или логический основной файл) «проходят» в системе.
Он представляет собой схематическое отображение всех процессов, вы¬
полняемых в отношении данных, их последовательности и логических
файлов, участвующих в обработке. Пример профиля транзакции приве¬
ден на рис. 7.11.
103

Для создания профилей бланки процессов просматриваются по гра¬
фам «Для каждого» и сортируются с тем, чтобы бланки всех процессов,
обрабатывающих одни и те же данные, оказались в одной пачке. Обыч¬
но делается «подшивка» всех необходимых бланков, относящихся к
одному входному потоку данных или логическому основному файлу.
Кроме того, бланки сортируются и по графе «Когда» в соответствии с
последовательностью обработки входных потоков.
После сортировки следует определить логическую структуру процес¬
сов. Различают пять типов структур: последовательную, параллельную,
Рис. 7.11. Профиль транзакции
с ветвлением (выбор), с циклами (итерации) и вложенную. Все эти
структуры аналогичны используемым в программировании и описанным
в гл. 8. Типовые структуры, применяемые в проектировании ИС, приве¬
дены на рис. 7.12—7.16.
При выборе типа структуры, соответствующей связи двух процессов,
сопоставляются заголовки соответствующих бланков. Например, если
графы «Для каждого» и «Когда» в описаниях двух процессов идентич¬
ны, то эти процессы относятся к одним и тем же данным, в одно и то же
время и поэтому могут выполняться параллельно.
Далее проверяется логическая корректность выбранной структуры.
С этой целью анализируется вся информация, содержащаяся в бланках
операций. При создании профилей транзакций часто выявляются ошиб¬
ки, совершенные ранее во время составления бланков.
Профиль основной транзакции представляет структуру процессов,
выполняемых в отношении одного и того же входного потока или логи¬
ческого основного файла. Наглядность схемы улучшается при введе-
104

ПРОЦЕСС:	R54 - ОТЧЕТ - ПОДТВЕРЖДЕНИЕ
ДЛЯ КАЖДОГО: ПОДТВЕРЖДЕННОГО ЗАКАЗА
КОГДА:	ПОСЛЕ РАСПРЕДЕЛЕНИЯ ЗАКАЗОВ
ПРОЦЕСС:	R64 - ОТЧЕТ - БРОНИРОВАНИЕ
ДЛЯ КАЖДОГО: ПОДТВЕРЖДЕННОГО ЗАКАЗА
КОГДА:	ПОСЛЕ РАСПРЕДЕЛЕНИЯ ЗАКАЗОВ
ПРОФИЛЬ ТРАНЗАКЦИИ
ПОДТВЕРЖДЕНИЕ
заказа
ОТЧЕТ О
БРОНИРОВАНИИ
МЕСТ
Рис. 7.12. Параллельная структура
ПРОЦЕСС:	V04 - КОНТРОЛЬ - ЗАКАЗА
ДЛЯ КАЖДОГО: ЗАПРОСА ДИП ЗАПИСЕЙ = 04/
КОГДА:	ПРИ ВВОДЕ
ПРОЦЕСС:	V14 - КОНТРОЛЬ - ОБЛАСТИ - ДЛЯ - ЗАКАЗА
ДЛЯ КАЖДОГО: ЗАПРОСА ДИП ЗАПИСЕЙ = 04/
КОГДА:	ПОСЛЕ ПРОВЕРКИ ЗНАЧЕНИЙ ОСНОВНЫХ ПОЛЕЙ
Рис 7.13. Последовательная структура
105

ПРОЦЕСС:	Р04 - ОБРАБОТАТЬ - ОТЕЛЬ - ДЛЯ - РАЗМЕЩЕНИЯ |
ДЛЯ КАЖДОГО: ВЕРНОГО ЗАПРОСА НА БРОНИРОВАНИЕ МЕСТ В ДАНЧ
НОМ ОТЕЛЕ	|
КОГДА: 	ПОСЛЕ	ВЫПОЛНЕНИЯ	ВСЕХ	ПРОВЕРОК	I
ПРОЦЕСС:	R99 - ОТЧЕТ - ОШИБКИ - ВО - ВХОДНЫХ - ДАННЫХ
ДЛЯ КАЖДОГО: ВХОДНОГО СООБЩЕНИЯ, СОДЕРЖАЩЕГО ОШИБКИ
КОГДА:	ПОСЛЕ ВЫПОЛНЕНИЯ ВСЕХ ПРОВЕРОК
СПИСОК ДЛЯ ИСПРАВЛЕНИЯ
Рис. 7.14. Структура с ветвлением (выбор)
ПРОЦЕСС:
Р14-ОБРАБОТАТЬ- ОТЕЛЬ - ДЛЯ - РАЗМЕЩЕНИЯ
ДЛЯ КАЖДОГО:- ВЕРНОГО ЗАПРОСА
КОГДА:
ПОСЛЕ ПРОВЕРКИ
ПРОЦЕСС:	Р24 - ОБРАБОТАТЬ - НОМЕР - ОТЕЛЯ
ДЛЯ КАЖДОГО: НОМЕРА ОТЕЛЯ
КОГДА:	ПОСЛЕ ПРОВЕРКИ
ПРОФИЛЬ ТРАНЗАКЦИИ
НОМЕР
Рис. 7.15. Структура с циклами (итерации)

нии ссылок на справочные файлы. Эта информация черпается из диа¬
граммы, приведенной на бланке процесса.
В заключение на схему наносятся «тактовые линии» (пунктирные),
пересекающие профили и отображающие условия выполнения процес¬
сов. Процессы могут быть периодическими, т. е. происходить ежеднев¬
но, еженедельно, ежемесячно, либо выполняться после завершения
другого процесса, например после модификации сведений об отеле или
выбора номера. Тактовые линии, показывающие взаимосвязь процессов,
дополняются информацией о файле, к которому производится обраще-
ПРОЦЕСС:
V04 - ПРОВЕРКА - ЗАКАЗА
ДЛЯ КАЖДОГО: ЗАПРОСА /ТИП ЗАПИСЕЙ = 0,4/
КОГДА:
ПРИ ВВОДЕ
ПРОЦЕСС:
V99 - ПРОВЕРКА - НОМЕРА - КЛИЕНТА
ДЛЯ КАЖДОГО: НОМЕРА КЛИЕНТА В ЗАПИСИ
КОГДА:
ПРИ ВВОДЕ
ПРОФИЛЬ ТРАНЗАКЦИИ
±
V04
[V99
Рис. 7.16. Вложенная структура
ние (см. рис. 7.11, где процесс V24 «обращается» к файлу «Отель» для
контроля корректировки счетчика номеров по этому файлу после моди¬
фикации последнего. Тактовая линия здесь указывает на зависимость от
процесса и имеет пометку: «После модификации отеля»).
По завершении разработки профиль транзакции подвергается кри¬
тическому анализу. Модифицируется указатель бланков процессов: в
него включаются профили транзакций для каждого процесса. По этому
указателю можно проверить, все ли процессы включены в профили. Для
общих процессов проводится специальная проверка, позволяющая убе¬
диться в том, что они используются всюду, где это необходимо.
7.5.	Логическое проектирование
Логическое проектирование заключается в увязке профилей транзак¬
ций с целью получения единой схемы системы. Если бы не существова¬
ло ограничений по эффективности обработки, то система могла бы быть
реализована следующим образом: каждый процесс выполняется про¬
граммой, а каждый логический файл соответствует физическому фай¬
лу. Однако возможности технических средств не безграничны, поэтому
на стадии технического проектирования приходится объединять процес¬
сы в программы, а данные — в файлы. Целесообразно определенный
объем подобных группировок проводить на стадии логического проекти¬
107

рования. Во избежание неоправданного усложнения проекта необходи¬
мо точно соблюдать правила группирования, приведенные в настоящей
главе.
Вначале путем комбинирования последовательных процессов, обра¬
батывающих одни и те же данные в определенном временном интервале,
модифицируется профиль каждой транзакции. Исключение делается
лишь для итеративных структур. Проще проверить проект, если такие
Рис. 7.17. Профиль транзакции с процессами по обе стороны тактовой линии
структуры рассматриваются в рамках основного процесса. Никакие
группировки данных на стадии логического проектирования не произво¬
дятся.
После первого этапа группирования процессов необходимо свести
профили транзакций в единую логическую схему. Так как даже в не¬
большой системе профилей может быть много, эту задачу следует ре¬
шать поэтапно.
Для упрощения каждый профиль транзакции рекомендуется пред¬
ставить в виде последовательности групповых процессов, причем груп¬
повой процесс должен отображать все процессы в пределах смежных
тактовых линий. Показываются только основные входные и выходные
данные, справочные же файлы пока не рассматриваются.
На рис. 7.17 изображен профиль транзакции с процессами по обе
стороны тактовой линии, а на рис. 7.18 — два групповых блока с глав¬
ными входами и выходами. Групповые блоки профилей транзакции за-
108

тем объединяют между тактовых линий и отмечают для них основные^
потоки данных. При необходимости изменяют формат схемы логическо¬
го проекта с тем, чтобы сократить число пересекающихся линий.
На рис. 7.19 приведен фрагмент системы гипотетической фирмы.
Здесь блоки профиля транзакции по принятым заказам (рис. 7.18) до¬
полнены блоками трех профилей для генерации отчетов.
Наконец, в каждый групповой блок включаются составляющие его
процессы, причем процессы-компоненты теперь изображаются в одном
прямоугольнике. Приводятся, кроме того, и справочные данные. Там,
где данные модифицируются, показываются также входные и выходные
данные, поскольку это отражает логическую функцию процесса.
Рис. 7.18. Укрупненные блоки профиля транзакции
Критический анализ логического проекта. Скомпонованный логиче¬
ский проект рассматривается аналитиками и проектировщиками совме¬
стно с представителями организации-заказчика.
Такой структурный анализ имеет особое значение, поскольку он
проводится на грани логического и технического проектирования. Для
пользователя, который не участвует в техническом проекте, это «по¬
следний шанс» повлиять на ход разработки. Задача пользователя на
этой стадии существенно упростится, если на этапе системного анализа
состоялось детальное согласование проекта.
Проверяется точность и полнота спецификации, обеспечивающие
возможность продолжения проекта. Пользователи и аналитики могут
уточнить характер использования каждого логического файла и содер¬
жащейся в нем информации. Конкретные решения по технической реа¬
лизации файла принимает впоследствии группа проектирования.
109

7.6. Уточнение технических деталей
Уточнение технических деталей сводится к модификации логического
проекта в соответствии е ограничениями, накладываемыми возможно¬
стями используемой ЭВМ.
Прежде чем описывать метод решения этой задачи, необходимо сде¬
лать несколько общих замечаний по процедуре. Во-первых, не следует,
полагать, что существует совершенный во всех отношениях технический
проект. Речь может идти о нескольких корректных альтернативах.
Предлагаемый метод помогает в выявлении проблем и в организации
процесса принятия решений, но сам по себе не содержит готовых реше-
Рис. 7.19. Фрагмент обобщенной структуры
ний. Однако, с точки зрения службы эксплуатации ИС, лучшим счита¬
ется проект, наиболее близкий к логической модели. Разработчики всег¬
да должны помнить правило: «чем проще, тем лучше». Во-вторых, тех¬
ническое проектирование представляет собой итеративный процесс и
должно продолжаться до тех пор, пока не будут выполнены все техни¬
ческие требования.
Имеет смысл начать с простого проекта и по мере необходимости
развивать какие-то его компоненты, а не приступать сразу к сложному
проекту и упрощать его путем декомпозиции. Наконец, поскольку мо¬
жет быть несколько альтернатив, все члены проектной группы должны
участвовать в разработке вариантов, каждый из которых может быть
оценен до окончательного выбора. Не следует экономить время, сокра¬
щая эту стадию проектирования, так как успех реализации разработки
во многом зависит от качества проекта.
В основном техническое проектирование предусматривает следую¬
щие операции:
110

• документирование и утверждение ограничений;
• выбор способа физической реализации файлов;
• ввод процедур сортировки и управления доступом;
• оценка объемно-временных характеристик системы и при необхо¬
димости корректировка проекта.
Детальный список задач приведен на рис. 7.20. Технические аспекты
реализации файлов на данной стадии стараются рассматривать не в
последнюю очередь. При необходимости следует ввести процедуры сор¬
тировки и защиты данных. В остальном логический проект трактуется
как первый вариант технического проекта. Если он не удовлетворяет
системным требованиям, то уточняются размеры блоков, методы досту¬
па и т. д. Если и после этого ограничения все еще не выдерживаются,
то процессы группируются в компоненты, а данные — в файлы. В конце
1. Выявление имеющихся ограничений
2. Определение целей проектирования
3. Фиксация первоначальной версии структуры файлов
4. Определение необходимости в сортировках
5. Установление оптимального способа доступа к каждому файлу
6. Выбор методов организации файлов для первой версии проекта
7. Определение требований по обеспечению безопасности данных и реорганизации
файлов
8. Критический анализ первой версии проекта
9. Оценка ресурсов оперативной памяти
10. Оценка времени работы системы
11. Оценка ресурсов дисковой памяти
12. Сопоставление результатов проектирования с целевыми установками
13. Корректировка проекта при необходимости
Рис. 7.20. Задачи, решаемые при техническом уточнении проекта
концов, если система не может быть реализована при установленных
ограничениях, они должны быть пересмотрены.
В последующих разделах основные задачи, решаемые на данной
стадии проектирования, описываются более подробно.
Введение ограничений. Основным ограничением обычно является
стоимость разработки и эксплуатационные расходы, но они устанавли¬
ваются «вне» проекта. Руководитель проекта лишен возможности нанять
сотни специалистов экстра-класса для создания сверхновой операцион¬
ной системы или приобрести новую машину, чтобы снять ограничения
по производительности. Хотя большинству людей и не присущ столь
явный экстремизм, нередко возникают какие-то другие ситуации, менее
драматичные, но тем не менее оказывающие свое влияние на ход собы¬
тий. Затраты на проект всегда должны сопоставляться с ожидаемым эф¬
фектом.
Иные ограничения вводятся подразделениями программирования и
эксплуатации. Представители этих подразделений при обсуждении тре¬
бований к системе стараются ограничить используемое машинное время
и объемы требуемой памяти. Например, может выдвигаться требование,
согласно которому программа модификации и печати данных должна
работать не более 20 мин и «выдать» отчет объемом 40 страниц. Огра¬
ничения могут касаться объема оперативной памяти, объема внешней
памяти на дисках, числа одновременных устанавливаемых лент. Такие
ограничения наиболее просто сформулировать по результатам анализа
системных требований и логического проекта. Большинство ограниче¬
ний, предлагаемых программистами, может быть рассмотрено на стадии
111

детального проектирования при спецификации программ, но некоторые
из них, в частности стандарты, используемые в программировании, на¬
пример общие модули или сообщения об ошибках, оказывают влияние
и на технический проект. Технический проект должен учитывать эти
ограничения. Другие ограничения накладываются применяемым про¬
граммным обеспечением. Так, конкретные языки программирования мо¬
гут ограничивать выбор способа организации файлов, а генераторы от¬
четов— диктовать характер подготовки выходных данных.
Все установленные ограничения вместе с требованиями по развитию
системы, сформулированными при ее декомпозиции, следует включить
в спецификации системы. При техническом проектировании требования
по развитию системы должны быть учтены таким образом, чтобы ее по¬
следующее расширение было, по возможности, простым. Например, не¬
дальновидно создавать последовательный файл на ленте, если предпо¬
лагается работать с ним в оперативной системе.
После того как ограничения определены, можно сформулировать и
цели проектирования.
Упорядочение файлов. В начале технического проектирования сле¬
дует исходить из того, что файлы упорядочены наиболее простым спосо¬
бом. Входные потоки рассматриваются как неупорядоченные квазифай¬
лы. Организация существующих файлов сохраняется, если только ранее
не было принято решение об их реорганизации. Файлы с доступом по
ключу применяются для хранения данных и справочной информации.
И наконец, упорядочение выходных файлов производится в соответст¬
вии с требованиями пользователя. На последующих этапах проектиро¬
вания способ упорядочения файлов может быть изменен.
Сортировка. На данном этапе сортировки предусматриваются толь¬
ко там, где они необходимы для выполнения условий прикладной зада¬
чи. В дальнейшем сортировки могут быть включены для повышения
эффективности обработки, но при переходе от логического проекта к
первому варианту физического проекта эти вопросы не рассматрива¬
ются.
Типичные ситуации, когда могут потребоваться сортировки: гене¬
рация отчета по упорядоченным объектам или необходимость избира¬
тельного обращения к последовательным файлам.
Оптимизация доступа к файлам. В качестве наилучшего метода до¬
ступа к файлам следует считать тот, который определяется требования¬
ми прикладной области. Существуют следующие виды доступа:
• Физически последовательный. Каждая запись обрабатывается в
отдельности. Между записями не существует никаких взаимосвязей, и
не предполагается никакого их упорядочения.
• Логически последовательный. К записям обращаются в определен¬
ном порядке, который устанавливается отношениями между ними, т. е.
записи обрабатываются группами.
• Прямой. Требуется конкретная запись, но последовательный до¬
ступ невозможен, поскольку нужный порядок доступа не может быть
реализован при данной организации файла. Вероятен также прямой
доступ с дальнейшим последовательным обращением, например когда
требуется группа записей, но основной ключ файла отличается от ос¬
новного элемента в запросе.
Эффективность доступа к файлу зависит от способа его упорядоче¬
ния. Если порядок входных данных отличается от порядка, принятого
в справочном файле, то оптимальным способом доступа будет прямой.
Если же входной и справочный файлы упорядочены одинаково, опти¬
мальный способ доступа — последовательный. В том случае, когда логи¬
112

ка обработки входных данных требует, чтобы группа записей тракто¬
валась как единое целое, оптимальным также считается последователь¬
ный метод доступа.
Так как файлы используются при выполнении самых различных
процессов, каждый процесс следует рассмотреть отдельно, за исключе¬
нием ситуации, когда процессы уже сгруппированы. Результаты выбора
способа доступа должны быть зафиксированы. На рис. 7.21 показана
соответствующая таблица для системы рассмотренной ранее гипотети¬
ческой фирмы. Заметим, что процесс бронирования номеров в перспек¬
тиве планируется реализовать в оперативном режиме, что полезно от¬
разить в таблице.
Данные
Требуемый тип доступа
последовательн ый
прямой
Область D07
Р71
Р51
Отель D01
Y24
Р11
Р60
Р52
Р70
Р50
Отель
V34
Р01
Тип номера D03
34
Р61
Р72
Заказ номера D04
U04
Р60
Р61
R50
Р02
Р70
Впоследствии
Р71
в оперативном
R10
Р14
режиме
Рис. 7.21. Карта оптимального доступа
Организация файлов. Способы организации файлов, позволяющие
реализовать оптимальный доступ, зависят от применяемых видов обо¬
рудования. Известны последовательный, индексный и произвольный
способы организации файлов. Наиболее подходящий из них выбирается
в соответствии с таблицей доступа.
Должен быть определен и физический формат файла. 10% длины
записей резервируется на расширение в будущем. Размер блока выби¬
рается по правилам, действующим на данном ВЦ. На магнитном диске
обычно он равен половине или полной дорожке. Все сведения, относя¬
щиеся к организации файлов, вносятся в соответствующие формы.
Защита данных и реорганизация. Реорганизация требуется в случае
модификации и включения новых записей в индексные файлы. При не¬
обходимости создаются резервные копии и устанавливаются точки ре¬
старта.
Критический анализ. Далее следует убедиться в том, что предлагае¬
мый технический проект реализуем. Эта проверка может быть выполне¬
на разработчиками, так как нет нужды привлекать к ней подразделе¬
ния программирования и эксплуатации до завершения проекта.
Требования к памяти. Требования к памяти можно оценить с по¬
мощью простых правил на основе анализа характера и числа процес¬
сов, составляющих отдельные компоненты системы. При этом должны
113

учитываться число и объем обрабатываемых файлов. Указанные прави¬
ла зависят от типа используемой ЭВМ.
Оценка временных ресурсов. Время работы каждого компонента
системы определяется многими факторами. На время выполнения про¬
граммы влияют приоритет задания в мультипрограммном режиме, чис¬
ло и размер заданий, используемые каналы и прочие характеристики
операционной среды. Однако эти факторы обычно не контролируются
разработчиками.
Время, требуемое центральному процессору, в общем случае намно¬
го меньше времени обращения к файлам. Поэтому, как правило, доста-
Компонент
Данные
| Общие оценки
Имя
Число
записей
среди . со
•о
гмя
X
сз
S
Размер
буфера
Объема
памяти
Времен и
среди .
макс.
среди . | макс .
1. Первона¬
чальная про¬
верка
Число номеров
Число номеров
2000
2000
10000
10000
0,5
0,5
2,6
2.6
13К
13К
Раб. обл.
1К
Програм¬
ма 8 К
35 К
1 С
5,2с
2. Корректи¬
ровка брони
Число номеров
Тип номера
Заказ номера
2000
1500
135000
10000
2000
150000
0,5
0,2
23
2,6
0,2
25
13К
3,2К
з,зк
1
Раб. обл.
1К
Програм¬
ма юк
54,4К
47 с
57 с
3. Поиск све¬
дений о но¬
мере
Бронирование
номера в отеле
Тип номера
13620
10692
26240
21384
8,9
588
17,2
1170
13К
3,2К
Раб. обл.
1К
Програм¬
ма 8 К
38,2К
10 мин
20 мин
6с
Юс
Рис. 7.22. Фрагмент бланка оценки объемно-временных характеристик системы
точно точное приближение дает оценка времени, затрачиваемого на
обращение к файлам. Однако это не всегда верно, особенно при приме¬
нении СУБД или мини-ЭВМ, предназначенных для научных расчетов,
где время работы процессора, связанное с каждой операцией ввода-вы¬
вода, может даже превышать время собственно ввода-вывода. В таких
случаях временем работы процессора пренебрегать нельзя.
Необходимость учета этого фактора обычно очевидна либо из сути
прикладной задачи, либо из заранее известных накладных расходов,
связанных с применением конкретного программного обеспечения.
Продолжительность сортировок, получения резервной копии и реор¬
ганизации файлов также нужно учитывать, поскольку это составляет
значительную часть общих затрат времени.
Оценке использования машинных ресурсов и времени посвящено до¬
вольно много работ, поэтому указанные здесь вопросы детально не
рассматриваются. В гл. 16 приведены более подробные сведения по ана¬
лизу, контролю и повышению эффективности использования ресурсов
оборудования и программного обеспечения. Полезные данные для про¬
ведения оценок содержатся и в материалах разработчиков ЭВМ.
114

При оценке важно сохранять чувство меры. Неразумно проводить
расчеты с точностью до миллисекунд для небольшой системы, потреб¬
ляющей незначительные ресурсы. С другой стороны, такие вычисления
для системы реального времени с критическим временем отклика и
большой загрузкой должны выполняться на самом детальном уровне.
Требования к объему дисковой памяти. Эти требования могут быть
определены исходя из числа и размеров блоков в файлах.
Проверка выполнения целевых установок. Перед сопоставлением
оценок, необходимых для работы ИС, ресурсов с целевыми установка¬
ми сами оценки времени и объемов памяти должны быть внесены в
стандартные формы. На рис. 7.22 приведен фрагмент такой таблицы
для гипотетической системы описанной выше туристической фирмы.
Данные этой таблицы можно сравнить с соответствующими критерия¬
ми. Если выдвинутые требования не выполняются, необходимо скоррек¬
тировать проект.
Корректировка проекта. Корректировка проекта должна способство¬
вать выполнению установленных требований и осуществляться путем
минимальных изменений. Следовательно, уточнению подлежат наибо¬
лее критичные компоненты системы. При необходимости могут быть
изменены любые ранее принятые решения, касающиеся таких характе¬
ристик, как размеры блоков, способы организации файлов, сортировки,
уменьшение числа резервных копий и т. д.
Изменение одних параметров может отрицательно повлиять на дру¬
гие параметры, поэтому после каждой итерации нужно повторить оцен¬
ки и только тогда сопоставить их с целевыми установками.
7.7.	Группирование компонентов
Если предлагаемый технический проект все еще не удовлетворяет
сформулированным целям, то процессы необходимо сгруппировать в
укрупненные компоненты, а типы данных — в файлы. Эта процедура,
как и уточнение технических деталей, носит итеративный характер. Су¬
ществуют несколько уровней группирования, и после выполнения каж¬
дого из них должны снова проводиться оценки.
Цель группирования — с помощью минимального числа перестано¬
вок обеспечить выполнение требований, не снизив одновременно каче¬
ство системы с точки зрения организации ее эксплуатации. Как и ранее,
основное внимание при этом должно быть уделено наиболее критичным
компонентам.
Правила группирования. Правила группирования процессов и дан¬
ных иллюстрируются таблицей на рис. 7.23. Большинство правил оче¬
видны, но некоторые из них требуют дополнительных пояснений.
Хранение небольших файлов в оперативной памяти может значи¬
тельно улучшить временные характеристики, если при обработке боль¬
шого файла транзакций необходимо в произвольном порядке обращать¬
ся к небольшому справочному файлу. Однако это может вызвать за¬
труднения при распределении памяти и сопровождении программы, осо¬
бенно если используемый язык программирования не имеет таких
средств динамического выделения оперативной памяти (как, например,
атрибут CONTROLLED в ПЛ/1), так как в этом случае придется вос¬
пользоваться фиксированной областью памяти, размеры которой при¬
дется время от времени пересматривать. Механизм виртуальной памяти
также должен быть принят во внимание.
115

Процессы
Данные
1.
2.	Процессы, «обрабатывающие» одни и те
же входные данные, но различные ссыл¬
ки
3.	Процессы, «обрабатывающие» одни и
те же входные данные (сходные процес¬
сы)
4.	Процесс посылки и выборки данных
5.
6.	Все процессы для функций
7.	Все процессы для входных данных
8.	Все процессы для тактовой линии
9.	Все процессы для системы
Небольшой файл в оперативной па¬
мяти
Выделение таблицы
Объединение файлов
Рис. 7.23. Группирование процессов и данных
На рис. 7.24 представлены результаты включения файла номеров
отелей в качестве внутреннего элемента в компонент «Поиск сведений
о номере».
По правилам 2 и 3 (см. рис. 7.23) объединяются процессы, опериру¬
ющие одними и теми же входными данными. При последовательном вы¬
полнении это позволяет избежать лишних операций чтения и записи.
В том случае, когда входной файл имеет большие размеры, такой спо¬
соб может оказаться весьма эффективным.
Данные
Общие оценки
Ком момент
Ч исло
Время
Времени
Имя
записей
X
ef
о
X
о. 2
О) о.
2 ^
П-в¬
ь
X
2
п
СJ
X
среди .
макс .
о.
и
яз
2
яз >>
О, О
я:
сх
о
яз
2
Первая версия
проекта
Поиск сведений о
номере
Бронирование но¬
мера в отеле
Тип номера
Бронирование
номера в отеле
13620
10692
13620
26240
21384
26240
8,19
588
8,9
17.2
1176
17.2
13К
3,2К
13К
29К
Раб.
обл.
1К
Прог¬
рамма
8К
38,2К
10 МИН
20 мин
56 с
Юс
После размещения записей «тип но¬
мера» в оперативной памяти
Поиск сведений
о номере
Бронирование
Тип номера
Бронирование
номера в отеле
13620
1500
13620
26240
2000
26240
8.9
0,2
8.9
17.2
0,2
17.2
13К
(3,2 К)
13К
26 К
Раб.
обл.
32К
Прог¬
рамма
8К
57К
18с
34 с
Рис. 7.24. Результаты перемещения файла в оперативную память
116

На рис. 7.25 приведен пример группирования двух аналогичных про¬
цессов, оперирующих одними и теми же данными. Потенциальный эф¬
фект здесь состоит в том, что оба процесса «обращаются» к одному и
тому же справочному файлу. В итоге наполовину уменьшается время
обращения при сохранении требований к памяти.
Компонент
Имя
Данные
Общие оценки
Число
записей
Время
°-2.
<ц Q.
5 0)
it
С, О
Памяти
Времени
среди.
макс .
среди.
макс .
среди .
макс .
Первая версия
проекта
Поиск отеля при
заказе клиента
Бронь
Отель
Бронь
16022
11542
16022
30785
23085
30785
10.5
635
10.5
20,2
1270
20,2
13К
3,3 к
13К
29,ЗК
Раб. обл
1К
Програм¬
ма
8К
38,ЗК
10 мин
21 мин
56 с
Юс
Поиск отеля при
подтверждении
заказа
Бронь
Отель
Бронь
16022
11542
16022
30785
23085
30785
10.5
6,35
10.5
20,2
1270
20,2
13К
з,зк
13К
29,ЗК
Раб. обл.
1К
Програм¬
ма
38,ЗК
10 мин
21 мин
56 с
10 с
После обобщения
(при тех же
входных данных)
Поиск отеля при
заказе клиента и
при подтвержде¬
нии заказа
Бронь
Отель
Бронь
16022
11542
16022
30785
23085
20785
10.5
635
10.5
20,2
1270
20,2
13К
з,зк
13К
29,ЗК
Раб. обл.
1К
Програм¬
ма
8К
38,ЗК
10 мин
21 мин
56 с
Юс
до
ПРИНЯТЫЕ ЗАКАЗЫ
N
поиск
11
ОТЕЛЯ
для
ПОДТВЕРЖДЕНИЯ
КЛИЕНТА
ОТЕЛЬ
. ._зг
ПОИСК
14
ОТЕЛЯ
для
ПОДТВЕРЖДЕНИЯ
ПОСЛЕ
ПРИНЯТЫЕ ЗАКАЗЫ
ОТЕЛЬ
11/14
ПОИСК
ОТЕЛЯ
для
ПОДТВЕРЖДЕНИЯ
Рис. 7.25. Группировка процессов, использующих одни и те же входные данные и
справочные файлы
117

Выборка таблиц полезна в том случае, когда произвольный доступ
осуществляется к справочному файлу, объем которого слишком велик
для хранения в оперативной памяти. Компромисс достигается путем
хранения части файла в оперативной памяти и обращения к диску толь¬
ко тогда, когда требуемой записи нет в выделенной, таблице. Такой
способ позволяет значительно уменьшить число операций ввода-вывода.
Его результативность еще более повышается, если можно выделить дан¬
ные, к которым обращаются очень часто, или если одни и те же записи
многократно обрабатываются для конкретного файла. В качестве при¬
мера можно привести выделение части данных из файла «Заказы» рас¬
смотренной выше гипотетической системы, так как он слишком велик
для хранения в оперативной памяти целиком.
Правило 4 (см. рис. 7.23) относится к выборке данных из справочно¬
го файла. Указанную операцию лучше всего выполнять незадолго до
использования данных в обрабатывающих процессах. Логически такая
последовательность обработки оправдана, однако здесь возникает опас¬
ность лишних обращений к справочному файлу, когда эти данные боль-:
ше не требуются для остальных операций. Потери будут особенно за¬
метны, если происходит произвольное обращение большого входного
файла к справочному файлу. В таком случае значительный выигрыш
может быть получен при группировании процесса выборки данных с
другим процессом, оперирующим теми же самыми данными. Это стано¬
вится еще более ощутимым, если можно произвольный доступ заменить
последовательным.
При совместной обработке нескольких логических основных файлов
их можно объединить в один файл с целью уменьшения числа операций
ввода-вывода. Таким образом объединяются повторяющиеся группы и
общие заголовки, например данные о заказах и свободных номерах в
отеле в гипотетической системе туристической фирмы, что позволяет
значительно сократить число операций ввода-вывода, поскольку все
элементы записи о заказе становятся доступными для элемента данных
«тип номера» за одно считывание.
Существует целый ряд проблем, связанных с рассматриваемым ви¬
дом группирования. Во-первых, если число повторяющихся элементов
является переменным или вообще неизвестно, то возникают трудности
при организации структуры обобщенной записи. Можно, конечно, уста¬
новить максимальный коэффициент повторения, но тогда при отклоне¬
нии его среднего значения от максимального теряется много места на
дисках. Можно использовать записи переменной длины, но при этом
усложняется процесс обработки. Если вероятное число повторений
очень велико, длина записи может превысить размер дорожки диска,
что допустимо не для всех типов устройств, а следовательно, потребует¬
ся несколько записей для хранения одного заголовка.
Кроме чисто реализационных проблем, для таких структур файлов
характерны и проблемы эксплуатационные, поскольку максимальное
число повторений может быть изменено пользователем. Включение зави¬
симых полей (например, для указания района, где расположен отель, в
упомянутой выше гипотетической системе).также усложняет дело, так
как изменение названия района потребует последовательного просмотра
сведений обо всех отелях.
Определенные трудности возникают и р том случае, когда повторя¬
ющиеся данные приходится предоставлять пользователю в порядке, от¬
личном от порядка следования их заголовков. В такой ситуации перед
сортировкой обобщенных записей необходимо выделить их компоненты.
Например, если в нашей гипотетической системе сведения о заказах и о
118

свободных номерах объединены, то для получения отчета о свободных
номерах, упорядоченного по районам, датам заказов и отелям, следует
разделить записи, так как обобщенные записи невозможно отсортиро¬
вать по дате заказа.
Остальные правила определяют порядок группирования процессов
по функциям, входным данным, временному диапазону и в целом по
системе. В любом случае смысл группирования состоит в том, чтобы
уменьшить число операций считывания входных данных и доступа к
справочным файлам.
Изменение целевых установок. Если после выполнения всех возмож¬
ных группировок система все еще не удовлетворяет предъявляемым тре¬
бованиям, последние должны быть пересмотрены с участием подразде¬
лений системного анализа и эксплуатации. При этом следует вносить
только те изменения, которые будут способствовать реализации си¬
стемы.
Проверка сложности компонентов. Хотя перегруппировка компонен¬
тов часто является жизненно необходимой' для системы, при ее осуще¬
ствлении важно иметь чувство меры.
Прежде чем объединять компоненты, нужно обязательно проанали¬
зировать целесообразность такой перегруппировки, особенно если оче¬
видно, что она будет иметь серьезные последствия. С этой целью можно
исследовать структуру файлов. Так как логика программы нередко оп¬
ределяется структурой обрабатываемых ею файлов, анализ связей меж¬
ду файлами поможет выявить сложность программной логики. Процеду¬
ра анализа связей рассматривается в следующей главе. Основное ее
содержание составляет проверка соответствия файлов. Если прямого
соответствия между файлами нет, желательно, чтобы процессы обработ¬
ки были разделены, за исключением тех случаев, когда это считается
неприемлемым по другим, более веским причинам технического харак¬
тера.
Окончательный просмотр. В заключение полученные результаты ис¬
следуются совместно с проектировщиками, аналитиками, представите¬
лями службы эксплуатации и программистами для определения степе¬
ни завершенности технического проекта.
7.8.	Детализация проекта
При детализации проекта в него следует включить все технические
спецификации, позволяющие в дальнейшем приступить к программиро¬
ванию. Это касается описания физических файлов, определения комп¬
лекса необходимых проверок целостности данных, выявления общих
модулей и спецификации программ.
Описание файлов. Определяется физический формат полей в каждой
записи и заполняются формы описания данных. Для каждого файла со¬
ставляется структурная диаграмма (гл. 14).
Контроль целостности данных. Весьма желательно обеспечить ав¬
томатический контроль логической целостности данных так, чтобы каж¬
дая программа проверяла используемые ею файлы. Возможны следу¬
ющие виды контроля;
• проверка упорядоченности файла;
• подсчет числа записей и контрольных сумм для их сверки с анало¬
гичными значениями, занесенными в итоговые записи;
• проверка заголовка, содержащего поля, которые идентифицируют
версию файла;
119

• проверки по контрольному файлу: порядка запуска программ, вер¬
сии выполняемой программы, версии используемого файла.
Для упрощения контроля целостности данных можно стандартизи¬
ровать некоторые из этих проверок для ВЦ и создать общие модули,
которые должны включаться во все системы.
1.	Схема выполнения программы, на которой показаны входные и выходные дан¬
ные
2 Общее описание функций и интерфейсов программы
3. Описание структуры входных и выходных данных
4. Описание структуры выходных отчетов с указанием источников результатов сре¬
ди входных данных
5. Описание способов контроля значений данных, выполняемых программой
6. Описание (копии спецификаций) системных процедур контроля
7. Копии спецификаций общих модулей
8. Детальное описание логики программы
Рис. 7.26. Содержание спецификации программ
Общие модули. На стадии декомпозиции процессов были система¬
тизированы все требования пользователей, благодаря чему удалось вы¬
делить общие процессы. Последние теперь подвергаются анализу для
выявления общих модулей. Ими могут быть подпрограммы ввода-выво¬
да, обработки данных и сложных вычислений, а также неоднократно
повторяющиеся процессы.
Общие модули автономно компилируются или помещаются в библио¬
теки исходного текста для копирования в программы.
Процесс:	Завершение обработки
Для каждого:
Когда:	В конце обработки
1. Проверить согласование итогов по входному файлу районов, транзакции коррек¬
тировки и выходному файлу районов
Если согласования нет, выдать сообщение № 29
2. Записать «хвостовую метку» в новый файл
3. Подготовить контрольный отчет
Рис. 7.27. Дополнительный бланк описания процесса
Утилиты. Перед разработкой спецификаций программ в проекте вы¬
являются те программы, которые можно заменить утилитами. Как пра¬
вило речь идет о программах создания контрольных копий, реоргани¬
зации, сортировки и получения дампов.
Спецификация программ. Спецификация программ — один из наибо¬
лее ответственных моментов в проектировании системы. Здесь требует¬
ся однозначно и четко определить функции, которые должна выполнять
программа.
Спецификация программы компонуется из документов, разработан¬
ных на этапе проектирования (рис. 7.26). На данной стадии создается
только схема выполнения программы и ее общее описание. Вся осталь-
120

пая документация должна быть уже готова. Документация может быть
дополнена указателями для облегчения работы программиста. Однако
целесообразнее обеспечить программистов копиями всех необходимых
документов, так как много проще работать с полной спецификацией.
Лишние копии должны быть уничтожены после завершения разработки
программы.
Процессы, сгруппированные в программу, документируются с по¬
мощью специальных бланков. Для внутренних процедур, вызываемых
в начале и конце программы, может потребоваться создание дополни¬
тельных бланков. На рис. 7.27 показана одна из таких процедур. После
завершения спецификации выполняется ее просмотр. Весьма желатель¬
но при этом присутствие программиста, который будет писать програм¬
му, так как в этом случае могут быть разрешены многие проблемы и
ориентировочно определено время, необходимое для составления про¬
граммы.
По завершении спецификации всех программ можно приступать к
следующему этапу разработки — программированию.
7.9.	Структурное проектирование систем реального времени
В этом разделе термин «система реального времени» используется
применительно к любым системам, обрабатывающим транзакции, кото¬
рые вводятся с терминалов. В таких системах единицей обработки яв¬
ляется транзакция. Ввод данных обычно осуществляется с клавиатуры,
а вывод—на экран терминала или на низкоскоростной принтер, напри¬
мер телетайп.
Транзакция это логическая единица обработки с точки зрения опе¬
ратора терминала. При выполнении системного анализа отдельные тран¬
закции могут быть разделены на несколько операций прикладного ха¬
рактера, каждая из которых требует обращения к ЭВМ (см. рис. 6.17).
Подобные обращения часто проектируются как пары логических сооб¬
щений. Пара логических сообщений считается единицей обмена между
оператором терминала и ЭВМ. Изредка, например при необходимости
передачи сообщений очень большой длины, они подвергаются дальней¬
шей декомпозиции.
Общая схема процесса структурного проектирования систем реаль¬
ного времени представлена на рис. 7.28 и описана ниже. Конечно, не¬
редко в состав систем реального времени входят ППП, проектирование
которых уже рассматривалось ранее.
Общая схема диалоговых программ. Для систем реального времени
практически любого назначения прежде всего необходимо определить
(операционную) «среду» функционирования прикладных программ, по¬
скольку программисты не всегда могут квалифицированно разобраться
во всех этих аспектах. Такая «среда» должна обеспечить:
• управление сетью терминалов;
• интерфейс высокого уровня для прикладных программ;
• доступ к файлам с помощью стандартных методов;
• возможность одновременной обработки-сообщений;
• восстановление системы после отказов оборудования и программ¬
ного обеспечения;
• тестирование интерфейсов;
• организацию службы времени;
• интерфейс с системами пакетной обработки;
• защиту данных.

Могут потребоваться и другие средства. Как правило, они снабжа¬
ются ППП, настраиваемыми при генерации системы. Обычно эти ППП
весьма сложны и располагают более широкими возможностями, чем это
необходимо в каждом отдельном случае. Например, средствами какого-
либо пакета можно реализовать несколько стратегий восстановления си¬
стемы. Эффективнее заранее ограничить выбор стандартных для данной
ЭВМ средств и способов их использования, однако в некоторых ситуа¬
циях придется принимать индивидуальные решения для конкретного
проекта.
К ПРОЕКТИРОВАНИЮ
СЕТИ <4
ТЕРМИНАЛОВ
НЕОБХОДИМЫЕ
ИЗМЕНЕНИЯ
ФОРМАТЫ
ЭКРАНОВ
X
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ
И БЛАНКИ ДЛЯ
ТРАНЗАКЦИЙ
ПРОЕКТИРОВАНИЕ
ТРАНЗАКЦИЙ
ДЕКОМПОЗИЦИЯ
И ЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ
ТРАНЗАКЦИЙ
ФИЗИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ -
УВЯЗКА
ПРОЦЕССОВ
СО СХЕМОЙ
ПРОГРАММЫ
ДЕТАЛЬНОЕ
ПРОЕКТИРОВАНИЕ
т
ОСНОВНЫЕ
РЕЗУЛЬТАТЫ
СИСТЕМНОГО
АНАЛИЗА
ОБЩАЯ
СХЕМА
ДИАЛОГОВЫХ
ПРОГРАММ
ЗАВЕРШЕНИЕ
ПРОЕКТИРОВАНИЯ
Рис. 7.28. Схема структурного проектирования систем реального времени
Проектирование транзакций. Результаты анализа транзакций, в ча¬
стности, включают операционные диаграммы и форматы экранов, ис¬
пользуемые для ввода и вывода данных в реальном масштабе времени.
Повышенная сложность программирования таких задач заставляет рас¬
сматривать транзакции в качестве самостоятельного объекта проекти¬
рования. Для сравнения отметим, что в системах пакетной обработки
результаты анализа входных и выходных потоков данных, как правило,
непосредственно применяются на этапе проектирования.
При проектировании транзакций характеристики пар логических
сообщений сопоставляются с ограничениями, присущими данному типу
терминала, и при необходимости разделяют сообщения на более мелкие
компоненты. Разрабатываются форматы и точная последовательность
сообщений, поскольку на этапе системного анализа были определены
лишь основные из них. Особое внимание при этом следует обратить на
полноту передаваемой информации, возможность указания ошибок и
использование функциональной клавиатуры. Наконец, производится
унификация форматов экранов для всех транзакций, что упрощает ра¬
боту пользователей и программистов.
Проекты транзакций имеют двойное назначение: для продолжения
проектирования автоматизированной системы и для разработки проекта
сети. Последнее предполагает выполнение следующих работ:
122

• определение числа терминалов в каждом пункте;
• расчет времени передачи сообщений;
• проектирование линий связи.
В настоящей книге перечисленные вопросы детально не рассматри¬
ваются, но их решение может повлиять на проектирование транзакций.
Для реализации некоторых слишком сложных проектов может потребо¬
ваться терминальная сеть неприемлемой стоимости, что может привести
к пересмотру проекта транзакций.
Основные задачи структурного проектирования, описанные выше для
систем пакетной обработки, будут далее представленье с учетом особен¬
ностей систем реального времени. Общие положения остаются неизмен¬
ными.
Декомпозиция системы. Транзакции, соответствующие операциям,
обрабатываемым в реальном времени, рассматриваются следующим
образом. Каждое вводимое сообщение трактуется как логический вход¬
ной поток данных, для которого выявляются и описываются процессы,
необходимые для получения требуемых результатов.
Здесь, однако, нужно учитывать ряд особенностей. Логическая тран¬
закция часто состоит из нескольких взаимосвязанных входных сообще¬
ний. При этом обычно информация, содержащаяся в одном сообщении
или сгенерированная при его обработке, должна восприниматься про¬
цессами, «обрабатывающими» другие сообщения. Если это так, то для
всей транзакции составляется схема структуры файлов, раскрывающая
связи между парами сообщений.
Для организации взаимодействия между сообщениями необходимо
хранить информацию в течение всего периода обработки транзакции.
Предполагается, что эта информация должна храниться в участке па¬
мяти, называемой областью связи транзакции. Эта область инициализи¬
руется при вводе первого входного сообщения и освобождается при
выдаче последнего выходного сообщения транзакции. Механизм хране¬
ния информации и доступа к ней зависит от решений, принятых на ста¬
дии технического проектирования, и от применяемой системы телеобра¬
ботки данных. На логическом уровне необходимо установить лишь ха¬
рактер взаимодействия транзакций.
С этой целью используется область связи транзакции, которая долж¬
на быть описана с помощью формы определения данных. В указанной
области хранится вся информация, необходимая для организации взаи¬
модействия сообщений. На информацию, требуемую для обработки кон¬
кретного сообщения, дается ссылка в бланке соответствующего про¬
цесса.
Обычно можно выявить информацию, которая нужна только для
взаимодействия процессов, обрабатывающих одно входное сообщение.
Примером могут служить индикаторы ошибок. Целесообразнее хранить
такие данные в специальной области связи сообщения, а не в области
связи транзакции. Область связи сообщения инициализируется при вво¬
де сообщения. Определяя процесс, следует выбрать место хранения
входных и выходных данных, необходимых для реализации других про¬
цессов. Рекомендуется соблюдать правило, по которому эти данные раз¬
мещаются в области связи сообщения, если только они не потребуются
при обработке последующих сообщений. В противном случае информа¬
ция размещается в области связи транзакции. Структура областей
должна быть пересмотрена после завершения спецификаций всех про¬
цессов для конкретной транзакции. Именно на этой стадии возможна
эффективная проверка «обеспечения» всех процессов входными данны¬
ми или данными, получаемыми при выполнении других процессов.
123

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

вовсе нет. Тем не менее всегда следует оценивать зависимость времен¬
ных характеристик системы от типа ЭВМ и применяемого программного
обеспечения.
Физическое проектирование файлов проводится с использованием
описанной выше схемы оптимального доступа. Проектирование баз дан¬
ных рассматривается в следующем разделе. После принятия решений
по реализации транзакций в среде конкретного телемонитора, физиче¬
ские профили процессов могут быть представлены в модели, применяе¬
мой для контроля технического проекта (см. гл. 16).
Детальное проектирование. Как и в системах пакетной обработки,
детальное проектирование сводится к объединению программных спе¬
цификаций и документации на данные. На этой стадии особенно важно
обеспечить разработчикам доступ к документации по применяемому
телемонитору (например, системам CICS, TPS и т. д.). Специфика
команд передачи данных, обращения к файлам и управления восстанов¬
лением существенно влияет на характер спецификаций и последующее
программирование.
7.10.	Структурное проектирование систем баз данных
Общие положения. Процесс проектирования систем баз данных в об¬
щих чертах аналогичен проектированию традиционных файловых си¬
стем. Однако ключевой задачей в этом случае является отделение опи¬
саний данных от программ и использование СУБД в качестве интер¬
фейса между ними. Предлагаемый метод позволяет в значительной сте-
РЕЗУЛЬТАТЫ
АНАЛИЗА
ДАННЫХ
... 1
ОПЕРАЦИОННЫЕ
ДИАГРАММЫ
И БЛАНКИ
1 J
ПРОЕКТИРОВАНИЕ
БАЗЫ
ДАННЫХ
«-
ДЕКОМПОЗИЦИЯ
И ЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ
ПРОЦЕССОВ
ТЕХНИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ
-► ПРОЦЕССОВ
ДЕТАЛЬНОЕ
ПРОЕКТИРОВАНИЕ
ЗАВЕРШЕНИЕ
г ПРОЕКТИРОВАНИЯ
ОСНОВНЫЕ
РЕЗУЛЬТАТЫ
СИСТЕМНОГО
АНАЛИЗА
Рис. 7.29. Схема структурного проектирования систем баз данных
пени разделить проектирование данных и процессов, а затем согласо¬
вать результаты. На рис. 7.29 представлена схема этапа проектирова¬
ния, на которой показаны основные связи с этапом системного анализа.
Для изучения материала, излагаемого в настоящем разделе, чита¬
тель должен иметь хотя бы общее представление о концепции базы
данных и анализе данных (гл. 13). Рассматриваемой проблеме посвя¬
щена не одна монография, поэтому здесь приводятся лишь те сведе¬
ния, которые необходимы для освоения структурных методов.
125

Проектирование базы данных. Основная цель проектирования —
отображение обобщенной логической модели данных на модель данных,
поддерживаемую конкретной СУБД, предоставление необходимых путей
доступа к данным и обеспечение приемлемых эксплуатационных харак¬
теристик системы. Обобщенная логическая модель данных разрабаты¬
вается на стадии анализа технической стратегии (гл. 2) 1.
Главная проблема состоит в поиске компромиссного решения, позво¬
ляющего выполнить самые различные требования в отношении доступа
к данным.
Рис. 7.30. Проектирование баз данных
Процесс проектирования разделен на две стадии: разработка первой
версии базы данных и ее уточнение (рис. 7.30). В качестве примера рас¬
сматривается проектирование системы предоставления социальных
услуг. Логическая схема данных этой системы, полученная методом ре¬
ляционного анализа данных, приведена на рис. 7.31.
В гл. 13 детально описаны реляционный анализ данных, профили до¬
ступа и логические схемы данных.
Разработка первой версии проекта. На этой стадии создается струк¬
тура базы данных, наиболее полно отражающая логическую схему дан¬
ных и в то же время удовлетворяющая требованиям СУБД. При нали¬
чии нескольких вариантов структуры базы данных выбирается тот,
который обеспечивает эффективный способ обработки наиболее частых
запросов. Детальные оценки временных характеристик такой начальной
структуры не проводятся до уточнения проекта базы данных.
Итак, при разработке первой версии проекта должны быть выполне¬
ны следующие операции:
1 Процесс проектирования базы данных авторы рассматривают со стадии логиче¬
ского проектирования, полагая, что основные результаты концептуального проектирова¬
ния получены на предшествующих этапах. — Примеч. пер.
126

1. Отображение (обобщенной) логической модели данных на модель
данных, поддерживаемую СУБД.
2. Определение структуры типов записей (сегментов).
3. Выбор физических характеристик файлов (включая размеры
блоков).
4. Реализация связей между записями и обеспечение путей доступа.
5. Расчет эффективности обработки наиболее частых обращений к
базе данных и при необходимости модификация ее структуры.
ПЕРВАЯ
Рис. 7.31. Уточнение проекта базы данных
127

Вслед за первой версией проекта необходимо разработать структу¬
ру данных, которая может быть реализована средствами СУБД. Такая
структура должна обеспечивать обработку всех требуемых запросов.
Эффективность обработки на этой стадии может не приниматься во
внимание.
Рассмотрим в качестве примера первую версию проекта базы дан¬
ных для СУБД TOTAL. Стандартными средствами системы реализуются
только два уровня иерархии. Разрешены лишь два типа файлов: основ¬
ные и зависимые. Снять указанное ограничение можно с помощью сле¬
дующего приема проектирования.
Каждый тип данных, являющийся логически основным (исходным)
и одновременно логически зависимым для другого типа данных, пре¬
образуется в два файла СУБД TOTAL: основной и зависимый, объеди¬
ненные связью типа «один с одним». При этом первое отношение реали¬
зуется через зависимый файл, а второе — через основной.
Известны и другие приемы, позволяющие разработать первую вер¬
сию проекта базы данных. Рассмотренный выше прием дает представ¬
ление о характере изменений, которым должна подвергнуться (обоб¬
щенная) логическая схема данных при переходе к модели данных.
СУБД TOTAL — не единственная система, где такие изменения неиз¬
бежны. Даже для СУБД, разработанных на основе предложений
КОДАСИЛ, например IDMS, следует принимать решения по физиче¬
скому блокированию записей, благодаря чему удается повысить эффек¬
тивность одних способов доступа за счет определенного ухудшения
временных характеристик других. В так называемых чисто реляцион¬
ных базах данных ссылки не хранятся вместе с данными. Связи под¬
держиваются с помощью специального процедурного языка. Теоретиче¬
ски можно обеспечить доступ к данным в любых комбинациях. Практи¬
чески же приходится ограничивать объем реляционных баз данных либо
создавать указатели или индексы для баз данных большого объема.
Таким образом, современная технология пока еще предполагает при
формировании структуры данных учет способов ее последующего ис¬
пользования.
Уточнение проекта. Принимая первую версию проекта в качестве
исходного материала, на этой стадии пересматривают все логические
профили доступа с учетом особенностей физической структуры базы
данных. При использовании СУБД TOTAL (и большинства других
СУБД), скорее всего, потребуется ввести дополнительные типы
записей.
Во многих ситуациях в логические профили доступа будут включены
дополнительные типы записей или сегментов. Например, в системе
TOTAL необходимы дополнительные структурные файлы для устране¬
ния весьма существенного ограничения на число уровней иерархии.
Иногда физические пути доступа оказываются короче логических, по¬
скольку именно эта цель преследовалась при проектировании физиче¬
ской базы данных. В других случаях неизбежны обращения к дополни¬
тельным типам записей или сегментов, упоминавшимся выше.
На практике нет необходимости перечерчивать заново физические
профили доступа, так как каждый из них может быть теперь представ¬
лен на бланке технического контроля проекта ТКП (гл. 16). Всякое
физическое обращение к отдельной записи или сегменту в профиле
изображается на этом бланке одной строкой.
После составления всех профилей доступа выполняется оценка объ¬
емно-временных характеристик проекта системы базы данных и полу¬
ченные данные сопоставляются с установленными ограничениями на
128

время выполнения прикладных программ, время реакции системы и
объемы памяти. Проект корректируется до тех пор, пока результаты
оценки не будут свидетельствовать о том, что система удовлетворяет
всем предъявляемым к ней требованиям (см. рис. 7.31).
Как отмечалось выше, сроки проектирования сокращаются при пере¬
ходе от логических профилей доступа к физическому представлению на
бланках ТКП. После каждого изменения проекта корректируются все
связанные с этим изменением бланки ТКП. С помощью автоматизиро¬
ванных процедур ТКП можно выполнять многократные корректировки
проекта, используя ручные операции лишь для переделки рисунков.
Более детальное описание проектирования систем баз данных дано
в [1].
Спецификация процессов. Проводится декомпозиция логических опе¬
раций на процессы (разд. 7.3). Выполняется группирование с целью ра¬
ционального объединения процессов в программы. По завершении про¬
ектирования базы данных влияние этих процессов на временные
характеристики системы может быть учтено в физических профилях
доступа, используемых при техническом контроле проекта, а общие
характеристики системы пересчитаны заново. Учет «собственного» вре¬
мени выполнения прикладных программ редко приводит к изменению
проекта базы данных, так как в большинстве коммерческих систем опе¬
рации с файлами или базой данных с точки зрения времени выполнения
превалируют над остальными операциями. Коррекция проекта будет
необходима только в том случае, если при группировании процессов в
программы потребовались дополнительные пути доступа к базе данных.
В некоторых ситуациях к данным обращаются дважды, поскольку
профиль доступа разделен между программами. Иногда из соображе¬
ний эффективности обработки для отдельных запросов приходится осу¬
ществлять поиск данных в одной последовательности, а при выводе
сортировать эти данные в другой последовательности. Подобные сор¬
тировки должны быть учтены в окончательном варианте.
Таким образом, проектирование процессов, выполняемых в среде
СУБД, мало отличается от аналогичной операции для традиционных
файловых систем. В оперативных системах баз данных применяется
модифицированная форма спецификации процессов, рассмотренная в
разд. 7.9.
7.11.	Заключение
В настоящей главе описаны задачи, решаемые на этапе структурного
проектирования системы. Вначале они рассматривались на примере не¬
большой системы пакетной обработки, а в двух последних разделах —
на примере систем реального времени и баз данных. Общая структура
проекта для всех перечисленных систем практически одинакова.
Структурное проектирование системы может выполняться даже в
TOxM случае, если ее анализ не проводился. Очень важно до начала про¬
ектирования ИС тщательно провести декомпозицию данных и процес¬
сов. Конечно, имея результаты анализа эту задачу выполнить проще,
но, с другой стороны, при ее решении должны выявиться все неточности
и ошибки, допущенные на стадии системного анализа.
Выделение этапа логического проектирования позволяет разработчи¬
ку сосредоточиться на поиске принципиального решения прикладной за¬
дачи, прежде чем приступить к проектированию файлов и программ.
В итоге созданная система будет полнее соответствовать требованиям
5 Зак. 1783
129

пользователей и окажется проще с точки зрения ее сопровождения. Ис¬
пользование предлагаемых здесь правил может упростить реализацию
системы и в значительной степени облегчить разработчику принятие
технических решений. Конечно, он должен быть знаком с работой опе¬
рационных систем, телемониторов и СУБД, а структурные методы помо¬
гут ему обеспечить требуемые объемно-временные характеристики си¬
стемы.
Так как основная документация формируется на предшествующих
этапах, последняя задача по проектированию системы — разработка
спецификаций программ — выполняется достаточно просто и быстро.
Следует помнить, что поскольку программы пишутся на основе подго¬
товленных спецификаций, последние должны быть точными и понятны¬
ми и не требовать дополнительных пояснений. Бланки описания процес¬
сов после заполнения на первой стадии проекта впоследствии постоянно
уточняются и подвергаются проверке, так что, скорее всего, специфика¬
ции будут удовлетворять самым жестким требованиям. Еще одно досто¬
инство этого метода заключается в том, что в спецификациях формули¬
руется лишь назначение программы, а проектирование ее внутренней
структуры остается за программистом.
Благодаря разделению процесса проектирования ИС на четко опре¬
деленные стадии, а объекта разработки — на ряд небольших логических
компонентов существенно упрощается управление проектом: появляет¬
ся возможность распределять задачи между разработчиками, оператив¬
но корректировать календарный план, дополнительно привлекать специ¬
алистов на этапе постановки задачи и контроля проектных решений.
Постоянный контроль полученных результатов гарантирует своевремен¬
ное обнаружение ошибок и позволяет проектировщикам лучше разо¬
браться в деталях проекта.
Созданная система должна быть гибкой и обеспечивать быструю
реализацию новых требований пользователей. Это нетрудно осущест¬
вить, поскольку она строится на основе логической функциональной мо¬
дели организации, поэтому входящие в ее состав файлы и программы
проектируются максимально простыми и точно соответствующими дан¬
ным и процессам предметной области.
Литература
1.	Kelly В. Database Techniques. — BIS Applied Systems, 1977.
Глава 8
Программирование
8.1. Введение
На этапе программирования можно выделить три самостоятельные
группы задач: проектирование, составление (кодирование) и тестиро¬
вание (отладку) программ, причем все эти задачи одинаково важны, и
для решения каждой из них необходимы свои методы. На рис. 8.1 пока¬
зана декомпозиция процесса программирования на подзадачи и мето¬
дики, применяемые при их решении. Индексы в правом нижнем углу
прямоугольников указывают номер раздела главы, в котором рассмат¬
ривается та или иная методика.
130

ГЛАВА
"ПРОГРАММИРОВАНИЕ"
5*
131
Рис. 8.1. Структура главы

На операционной диаграмме (рис. 8.2) перечислены подзадачи, ко¬
торые необходимо решить при программировании, этапы проверки полу¬
ченных результатов и разрабатываемой документации. Обычно все эти
задачи выполняются последовательно одним программистом, хотя
известны случаи, когда проектирование, кодирование и тестирование
РАЗРАБОТКА ПРОГРАММЫ
ПРОЕКТИРОВАНИЕ
ПРОГРАММЫ
СПЕЦИФИКАЦИИ
ПРОГРАММЫ
ПРОЕКТ
ПРОГРАММЫ
КРИТИЧЕСКИЙ
АНАЛИЗ
ПРОЕКТА
ПРОГРАММЫ
ПЕРЕСМОТРЕННЫЙ
ПРОЕКТ
ПРОГРАММЫ
ПЛАНИРОВАНИЕ
ТЕСТИРОВАНИЯ
ПРОГРАММЫ
ПЛАН
ТЕСТИРОВАНИЯ
ПРОГРАММЫ
КРИТИЧЕСКИЙ
АНАЛИЗ
ПЛАНА
ТЕСТИРОВАНИЯ
ПРОГРАММЫ
ПЕРЕСМОТРЕННЫЙ
ПЛАН ТЕСТИРОВАНИЯ
ПРОГРАММЫ
/Спецификация
( ОБЩИХ
\МОДУЛ ЕЙ
КОДИРОВАНИЕ
ПРОГРАММЫ
УСПЕШНАЯ
КОМПИЛЯЦИЯ
ЧТЕНИЕ
ТЕКСТА
ПРОГРАММ
ПОДГОТОВКА
ДАННЫХ ДЛЯ
ТЕСТИРОВАНИЯ
КОД |
ПРОГРАММЫ:
нН
ДАННЫЕ ДЛЯ
ТЕСТИРОВАНИЯ
ТЕСТИРОВАНИЕ
ПРОГРАММЫ
КРИТИЧЕСКИЙ
АНАЛИЗ
РАЗРАБОТАННЫХ
ПРОГРАММ И
ДОКУМЕНТАЦИИ g
С
ДОКУМЕНТАЦИЯ
НА ПРОГРАММЫ
ЗАВЕРШЕНИЕ
ПРОГРАММЫ
ОБЪЕКТНЫЙ
КОД СИСТЕМЫ
Рис. 8.2. Операционная диаграмма этапа программирования
проводились разными программистами. При этом уменьшалось число
ошибок, но несколько возрастало время разработки. С другой стороны,
примерно тех же результатов можно добиться и при «непрерывном»'
программировании, если проводить эффективный анализ (просмотр)
получаемых решений.
132

8.2. Проектирование логики программы
Разработка программ базируется на методах анализа структуры
файлов, описанных в гл. 14, и проектирования логики программ, рас¬
сматриваемых в настоящем разделе. Обе методики тесно взаимосвя¬
заны, поэтому, прежде чем приступать к разработке логики программ,
важно разобраться в типовых структурах данных и подходах к анализу
структуры файлов.
Логика программы должна точно отражать решение некоторой при¬
кладной задачи и быть хорошо сформулированной. Нецелесообразно
пытаться решать сразу несколько задач. Следует избегать также чрез¬
мерного ветвления решений.
В гл. 14 показано, что структура программы должна соответство¬
вать уточненной структуре файлов, в которой заключена суть програм¬
мируемой задачи. Другими словами, логика программы должна осно¬
вываться на структуре обрабатываемых данных. Иллюстрацией тому
служат показанные на рис. 8.3 три основные структуры данных и соот¬
ветствующие им типовые логические конструкции. Последние имеет
смысл дополнить четвертой конструкцией выбора (IF ELSE), очень ча¬
сто используемой и реализованной в большинстве языков высокого
уровня.
Любая из перечисленных логических конструкций имеет один вход
и один выход, поэтому их легко объединять в линейные структуры, по
которым нетрудно проследить последовательность передач управления.
Типовые логические конструкции могут быть вложены одна в другую,
но и при этом для каждой из них соблюдается главное правило: один
вход и один выход. Рассматриваемые конструкции непосредственно со¬
ответствуют типовым подструктурам данных, что позволяет сформули¬
ровать общие правила проектирования логики программ.
Общие правила проектирования логики программ можно сформули¬
ровать следующим образом:
1. Прежде всего следует считывать управляющий файл.
2. Запись читается сразу по завершении обработки предыдущей
записи.
3. Логические конструкции должны как можно полнее соответство¬
вать структуре обрабатываемых данных.
4. В конструкции цикла DO WHILE необходимо проверять выполне¬
ние условия с тем, чтобы впоследствии ее было легко модифицировать
при изменении структуры обрабатываемого файла.
Эти правила положены в основу так называемого принципа предва¬
рительного считывания, который можно пояснить на следующем при¬
мере. Пусть программа должна прочитать детальные сведения обо всех
торговых, сделках с магазинами, расположенными в разных районах
(главный почтовый файл, содержащий нужные данные, показан на
рис. 8.4). Отчет, подготавливаемый программой, должен содержать по
одной строке итогов для каждого района и общий итог. Блок-схема ло¬
гики программы, составленной с помощью перечисленных выше правил,
приведена на рис. 8.5. Мы вернемся к ней после рассмотрения альтер¬
нативного метода спецификации логики программ.
Альтернативный метод спецификации логики программ. Проектиро¬
вать логику программы, непосредственно ориентируясь на обработку
трех типовых подструктур данных, весьма просто, но сами блок-схемы
вряд ли можно считать элегантным способом изображения логики. Не¬
смотря на то что блок-схемы повсеместно применяются при разработке
программ и подготовке программной документации, они, как выясни-
133

лось, не свободны от недостатков. Во-первых, составление блок-схем
занимает много времени. Во-вторых, их трудно расширять и модифици¬
ровать, поэтому часто они перестают точно отражать текущую версию
ЛОГИКА
Рис. 8.3. Структуры программ и данных
программы. Наконец, этот способ нельзя считать удовлетворительным
для документирования при использовании нисходящих методов проекти¬
рования программ.
В качестве альтернативы были предложены так называемые специ-
фикационные языки (псевдокоды), и, хотя их стандартизация • еще не
134

завершена, многие пользователи работают с некоторым диалектом, ко¬
торый можно считать устоявшимся. Для построения типовых логических
конструкций применяются ключевые слова: ВЫБОР, ВАРИАНТ, КО¬
НЕЦ ВЫБОРА, ЕСЛИ, ТО, ИНАЧЕ, КОНЕЦ ЕСЛИ, ПОВТОРЯТЬ
ПОКА, КОНЕЦ ПОВТОРЕНИИ. Для описания действий, выполняемых
программой, используются предложения естественного языка. Большое
значение имеют пробелы, улучшающие восприятие текста. Пример та¬
кого описания приведен на рис. 8.6.
Рассмотрим, насколько логика программы соответствует структуре
файла. На первом уровне обрабатываются заголовок файла, данные по
областям и хвостовые метки (первый уровень иерархической структуры
Рис. 8.4. Структура основного файла
файла), на втором — заголовок области и детальные данные (следую¬
щий уровень, иерархии) и на третьем — данные по магазинам (нижний
уровень иерархии). Как можно заметить, благодаря введению циклов
легко отслеживается переход с одного уровня иерархии на другой. Кро¬
ме того, обработка каждой порции данных логически завершается в
пределах циклов. В результате удается упростить саму логику програм¬
мы: например, печать итогов по району в нашем примере специфициро¬
вана только один раз, в то время как при традиционном подходе кэ
проектированию это пришлось бы сделать дважды: при изменении на¬
звания района и по достижении конца файла.
Псевдокоды близки (по стилю) к языкам программирования, и их
применение позволяет повысить качество и облегчить восприятие про¬
грамм, в то время как, основываясь на блок-схеме, программу можно
закодировать самыми различными способами. Кроме того, чисто фор¬
мальное применение новых подходов, например использование только
четырех основных логических конструкций при сохранении старых
способов подготовки спецификаций, не всегда способствует изменению
стиля программирования. (Действительно, казалось бы, так просто про¬
вести на блок-схеме новую линию, однако это может полностью разру¬
шить конструкцию цикла.) По этой причине справедливо считается, что
наилучший и наиболее точный способ документирования логики про-
135

Рис. 8.5. Блок-схема программы выборки из основного файла
136

грамм, разработка которой основана на структурах обрабатываемых
данных, — с помощью псевдокода.
До сих пор мы рассматривали очень простые примеры. Реальная же
программа выполняет гораздо больше функций, и если не принять спе¬
циальные меры, описание ее логики окажется слишком сложным. По¬
этому в программе вычленяются модули — подпрограммы, реализую¬
щие отдельные функции. Логический модуль обладает свойствами «чер¬
ного ящика», у которого имеются только один вход и один выход.
ОТКРЫТЬ ФАЙЛЫ
ЧИТАТЬ ОСНОВНОЙ ФАЙЛ
ОБРАБОТАТЬ ЗАГОЛОВОК ФАЙЛА
ЧИТАТЬ ОСНОВНОЙ ФАЙЛ
ВЫПОЛНЯТЬ ПОКА ЕСТЬ РАЙОНЫ
ОБРАБОТАТЬ ЗАГОЛОВОК РАЙОНА
ЧИТАТЬ ОСНОВНОЙ ФАЙЛ
ВЫПОЛНЯТЬ ПОКА ЕСТЬ ЕЩЕ ДЕТАЛЬНЫЕ ДАННЫЕ
ЕСЛИ ПРЕДПРИЯТИЕ
ОБРАБОТАТЬ ДАННЫЕ ПО ПРЕДПРИЯТИЮ
КОНЕЦ ЕСЛИ
ЧИТАТЬ ОСНОВНОЙ ФАЙЛ
КОНЕЦВЫП
ВЫВЕСТИ СТРОКУ ИТОГОВ ПО РАЙОНУ
КОНЕЦВЫП
ОБРАБОТАТЬ ИТОГОВЫЕ ДАННЫЕ ПО ФАЙЛУ
ВЫВЕСТИ СТРОКУ ОБЩИХ ИТОГОВ
ЗАКРЫТЬ ФАЙЛЫ
Рис. 8.6. Псевдокод программы выборки из основного файла
Принцип модульности дает возможность выделить достаточно «ком¬
пактные» логические функции и описать их с помощью псевдокода.
Размер модуля должен быть таким, чтобы его описание размещалось на
одной странице. Функции или действия, логика которых раскрывается
в ходе проектирования, в описании подчеркиваются. Например:
ПОВТОРЯТЬ ПОКА имеются сведения о клиен¬
тах
Обработать сведения о клиенте
Читать файл сведений о клиентах
КОНЕЦ ПОВТОРЕНИЙ
Подчеркнутые функции должны быть реализованы в качестве от¬
дельных логических модулей.
Логический модуль, как правило, обрабатывает отдельную подструк¬
туру данных в файле или выполняет некую общую функцию. Програм¬
ма при этом образуется совокупностью модулей, которые могут быть
физически реализованы в виде самостоятельно компилируемых компо¬
нентов и в свою очередь состоять из ряда внутренних модулей. Концеп¬
ция логического модуля является фундаментальной в структурном про¬
граммировании. Поэтому везде далее термин «модуль» следует тракто¬
вать как логический модуль.
137

8.3. Структура программы
По завершении разработки структуры файлов и детализации или
обобщения структурных диаграмм наиболее важных входных файлов
(что позволяет, как показано в гл. 14, уяснить основные задачи про¬
граммирования) следует определить общую структуру будущей про¬
граммы. Для этого сопоставляются структуры входных и выходных фай¬
лов. Проверяется следующее:
• точность и достаточность детализации имеющихся спецификаций;
• наличие источников
всех выходных данных;
• принципиальная воз¬
можность решения приклад¬
ной задачи;
• корректность выпол¬
ненного ранее обобщения
или детализации структуры
файла;
• уровень сложности бу¬
дущей программы.
Такой подход позволяет
создать программу, структу¬
ра которой допускает при¬
менение принципа модуль¬
ности. Большинству моду¬
лей предстоит обрабатывать
входные или выходные дан¬
ные, а некоторым из них —
выполнять функции ввода-
вывода, специальные вычисления и т. д. На этом этапе проектирования
системы нужно определить структуру обрабатывающих модулей. Ос¬
тальные модули будут специфицированы на стадии логического проек¬
тирования программ.
Рассмотрим простейший пример. Речь пойдет о программе, обраба¬
тывающей уже упоминавшийся главный файл (см. рис. 8.6).
Допустим, требуется напечатать название всех районов, сведения о
которых имеются в файле. В отчете каждому району будет соответство¬
вать новая страница, на которой сначала печатаются данные, взятые из
заголовка области, затем — строки детальных данных о каждом мага¬
зине или каждом клиенте. Сопоставим выходные данные и их источ¬
ники:
Рис. 8.7. Схема выполнения программы рассыл¬
ки объявлений
Выходные данные	Источник
Заглавная строка для области	Заголовок области
Детальная строка для магазина	Сведения о магазине
Детальная строка для клиента	Сведения о клиенте
Нетрудно убедиться в том, что для получения выходных данных име¬
ются все необходимые источники информации и что структура програм¬
мы должна соответствовать структуре входного главного файла. Раз¬
рабатываемая программа будет очень простой.
Теперь обратимся к более сложному примеру, иллюстрирующему
обработку нескольких входных и выходных файлов, причем управление
обработкой осуществляется с помощью специального файла парамет¬
ров. Предметом рассмотрения является программа рассылки объявле¬
ний. Эта программа должна читать файл управляющих перфокарт, со-
138

держащих информацию для выбора районов и находящихся на их тер¬
ритории магазинов, в которые следует рассылать объявления, формиро¬
вать и печатать адреса для рассылки. Управляющие карты проверяются
и, в случае обнаружения в них ошибок, включаются в специальный
отчет. Общая схема программы приведена на рис. 8.7, а структура об¬
рабатываемых ею файлов — на рис. 8.8.
Прежде всего нужно выписать все выходные данные и их источники
(рис. 8.9).
Рис. 8.8. Структуры данных для программы рассылки объявлений
Из таблицы видно, что спецификации достаточны и задача может
быть решена.
Теперь нужно расширить структуру главного файла (рис. 8.10),
включив в нее блоки, необходимые для получения каждой группы вы¬
ходных данных. В противном случае не удастся добиться однозначного
соответствия между входными и выходными данными. Так, введя лишь
дополнительные сведения о магазине, можно обеспечить выбор тех
торговых предприятий, которые удовлетворяют критерию, указанному
на управляющей карте. Точно так же распечатывают строки заголовка
только для областей, удовлетворяющих критерию выбора. Однако нет
смысла выделять в агрегате данных «Детальные данные» две подструк¬
туры и обрабатывать эти данные одинаково, поскольку в такой ситуа¬
ции неоправданно усложнится программа. После того как установлено
соответствие входных и выходных данных, структуру файлов необходи¬
мо еще раз проанализировать и удалить все лишние блоки.
139

Для анализа расширенной структуры файлов полезно применить
следующий прием (рис. 8.11). На блок-схеме программы из каждого
прямоугольника, отражающего обработку входных данных и генерацию
Выходные данные	|	Источники
Файл адресов
Адрес магазина
Список рассылки
Строка заголовка области
Детальная строка для каждого мага¬
зина
Строка, в которой указано общее чис¬
ло объявлений для данного района
Отчет об ошибках
Строка, соответствующая карте, со¬
держащей ошибки
Сведения о магазине, который удовлет¬
воряет критерию для данного района
согласно управляющей карте
Заголовок области
Сведения о магазине, который удовлет¬
воряет критерию для данной области
согласно управляющей карте
Общее число магазинов, удовлетворя¬
ющих критерию. (Вычисляется при ра¬
боте программы.)
Управляющая карта, содержащая
ошибки
Рис. 8.9. Соответствие входных и выходных данных
Рис. 8.10. Уточненная структура данных
некоторых выходных данных, проводят линию со стрелкой и помечают,
что представляют собой выходные данные. При этом сразу обнаружатся
как отсутствующие (стрелки неоткуда провести), так и избыточные вет¬
ви программы.
140

Осталось рассмотреть еще два вида выходных данных: итоговые
строки для районов и строки, соответствующие картам, содержащим
ошибки. Остановимся сначала на итоговых строках. При анализе вход¬
ных и выходных данных было установлено, что они должны накапли¬
ваться при работе программы для каждого магазина, удовлетворяюще¬
го критерию, указанному в управляющей карте конкретного района.
ОТМЕТКА НА
СПИСКЕ
РАССЫЛКИ
Рис. 8.11. Эскиз структуры программы
Итоговые строки печатаются по завершении обработки всех детальных
сведений по району (см. «Итоговые данные» на рис. 8.12). Пунктирная
линия на рисунке ведет к блокам, которые не отражают структуру фай¬
ла, а введены для пояснения логики будущей программы. Назначение
этой линии станет очевидным при описании проектирования программ.
Последний тип выходных данных — строки, соответствующие управ¬
ляющим картам, содержащим ошибки. В структуре входного файла рас¬
сылки источник для них не определен. Он задан в управляющем фай-
141

ле, причем для его явного указания в схеме нужно как-то отразить, что
управляющая карта может быть либо верной, либо содержать ошибки.
Другими словами, структуру управляющего файла необходимо расши¬
рить точно так же, как это было сделано при печати итогов по районам.
Управляющий файл читается во время обработки данных по районам,
поэтому на схеме структуры файлов имеющимся в нем данным соответ¬
ствуют блоки, расположенные под блоком «Район». Фрагмент расширен¬
ной структуры файлов приведен на рис. 8.13.
Рис. 8.12. Включение блока обработки итогов
Итак, мы построили расширенную структуру файлов, которая обес¬
печивает обработку всех входных и выходных данных. На рис. 8.11 по¬
казана ее схема, которая будет использоваться при модульном проекти¬
ровании программы. Верхний блок ее обозначен как «Управляющий мо¬
дуль» в соответствии с логикой программы. Остальные модули програм¬
мы предназначены для обработки данных. Исходящие стрелки показы¬
вают, что модуль гёнерирует выходные данные, а входящие, — что
модуль читает какой-либо файл. Подробнее этот вопрос обсуждается в
Рис. 8.13. Включение блока обработки файла параметров
следующем разделе. На схеме сохранены условные обозначения повто¬
рений и выбора, которые помогают при разработке логики программы.
При небрежной подготовке спецификаций программ может возник¬
нуть ряд проблем, например:
• будет невозможно получить выходные данные в требуемой после¬
довательности;
• для принятия решений в ходе обработки придется запоминать мно¬
жество записей;
• составленная по спецификации программа окажется слишком
большой и сложной.
142

Тщательный анализ соответствия входных и выходных данных поз¬
воляет выявить такие проблемы до того, как будут затрачены значи¬
тельные усилия на составление программ и, при необходимости, вовре¬
мя скорректировать проект системы. Известны случаи, когда в резуль¬
тате незначительного увеличения расходов на проектирование системы
удавалось существенно облегчить эксплуатацию и обслуживание разра¬
ботанных программ.
8.4.	Логическое проектирование программ
При логическом проектировании программ применяются методы
анализа структуры файлов (гл. 14), проектирования логики и специфи¬
кации программ (разд. 8.2), а также анализ соответствия входных и
выходных данных (разд. 8.3). Внимание разработчика должно быть со¬
средоточено на решении прикладной задачи, а не на особенностях конк¬
ретного типа ЭВМ или языка программирования. Исходя из структуры
обрабатываемых данных при поиске решения нужно выделить ряд про¬
стых модулей, которые и составят будущую программу. Для лучшего
восприятия модули следует проектировать достаточно компактными,
руководствуясь тем, что текст модуля на языке программирования дол¬
жен помещаться примерно на одной странице. В настоящем разделе
рассматривается процедура логического проектирования программ, во¬
семь основных стадий которого перечислены на рис. 8.14.
1. Разработка структуры всех входных и выходных файлов, которые не были вклю¬
чены в спецификации программы
2. Выбор управляющего файла
3. Уточнение структуры управляющего файла в соответствии с требованиями к об¬
работке данных
4. Выявление соответствия между файлами
5. Разработка укрупненной структуры программы
6. Расширение (раскрытие содержания) модулей с помощью псевдокода начиная с
верхнего уровня логической структуры и самой сложной ее ветви
7. Введение дополнительных модулей, обеспечивающих завершение процесса обра¬
ботки данных
8. Оценка полученных результатов
Рис. 8.14. Логическое проектирование программы
Обратимся вновь к примеру разработки программы рассылки объяв¬
лений, логическая схема и структуры файлов для которой приведены
на рис. 8.7 и 8.8.
Если все члены проектной группы владеют структурными методами,
то первая стадия проектирования программы должна была выполнять¬
ся при разработке ее спецификаций. Однако можно воспользоваться лю¬
бой формой спецификаций при условии, что в начале проектирования
программ разработана структура файлов. Далее следует выбрать наи¬
более важный (главный) файл, поскольку это позволит упростить
структуризацию программы. Главным считается файл, от содержания
записей которого зависит обработка остальных данных. В этом случае,
как правило, читаются все записи главного файла. Для программы ак¬
туализации некоторых данных, например, главным будет файл транзак¬
ций. Практика показывает, что даже когда не удается однозначно
выбрать главный файл, выбор любого варианта может обеспечить раз¬
143

работку хорошо структурированной программы, если только тщательно
проработать структуру этого файла. В нашем примере главным являет¬
ся файл рассылки. Его структура была уточнена в свете требований к
обработке данных. Соответствующая процедура описана в гл. 14, а по¬
лученные результаты приведены на рис. 8.11. Четвертая и пятая стадии
(см. рис. 8.14) описаны в разд. 8.3.
Переходя к шестой стадии проектирования программы, мы должны
составить описание управляющего модуля с помощью псевдокода, а за¬
тем рассмотреть наиболее сложную ветвь программы. Каждый модуль
описывается с использованием псевдокода. Дополнительно вводятся
модули, выполняющие операции ввода-вывода и др. Эти модули отра¬
жаются на иерархической схеме модулей программы. По проекту про¬
граммы разрабатывается документация, в которую включается иерар¬
хическая схема модулей и спецификация каждого модуля, составленная
с помощью псевдокода.
Текст спецификации управляющей модуля приведен на рис. 8.15
Инициализация
Обработать заголовок файла
ПОВТОРЯТЬ ПОКА есть данные по рай¬
онам
Обработать данные по районам
КОНЕЦ ПОВТОРЕНИЙ
Обработать хвостовые метки файла
Завершение
Рис. 8.15. Текст спецификации управляющего модуля
Первая строка подчеркнута. Это означает, что инициализация может
выполняться отдельной подпрограммой, а спецификация соответствую¬
щего модуля будет дана позднее. Однако не следует подчеркивать стро¬
ку, если характер требуемых в данной части программы действий не
ясен. Откладывать решение вопросов такого рода не рекомендуется.
На рис. 8.16 показан верхний уровень иерархической схемы модулей,
в которую включены дополнительные блоки.
Анализируя наиболее сложную ветвь программы, в ней можно вы¬
делить, например, следующие операции:
• обработка данных по району;
• обработка данных по району, удовлетворяющих определенному
критерию;
• обработка заголовка для района;
• обработка детальных данных;
• обработка данных по магазину;
• обработка данных по магазину, удовлетворяющих определенному
критерию;
• обработка итоговых данных по рассылке объявлений.
После того как раскрыто содержание операций, выполняемых моду¬
лями верхнего уровня, на основе структуры данных детализируют спе¬
цификации модулей следующего уровня. Дойдя до модулей нижнего
уровня, необходимо обратить внимание на стрелки, указывающие вы¬
ходные данные и вспомнить принцип предварительного считывания.
Стрелки помогут детализировать выполняемые на этом уровне опера¬
ции, например, при обработке заголовка для района — напечатать еще
и заглавную строку в списке рассылки. Поскольку в соответствии с
144

принципом предварительного считывания по завершении обработки не¬
которой порции данных сразу же считывается следующая порция, мо¬
дули чтения данных, должны располагаться в нижних уровнях структу¬
ры программы.
Чтение файла всегда должно осуществляться с помощью самостоя¬
тельной подпрограммы, в которую включаются все необходимые допол¬
нительные функции, например проверка упорядоченности файла и цело¬
стности данных путем подсчета контрольных сумм и сопоставления их
с содержимым хвостовых меток. По завершении составления подпро¬
граммы чтения некоторого файла к ней можно обращаться во всех про¬
граммах, где требуется доступ к этому файлу. Наличие такой подпро¬
граммы позволяет сократить общее время, затрачиваемое на разработ¬
ку системы, особенно на этапе тестирования, поскольку подпрограмма
может быть отлажена и проверена автономно. Упрощается также и со-
Рис. 8.16. Первый вариант структуры Модулей
провождение программного обеспечения системы, так как при измене¬
нии структуры какого-либо файла достаточно внести изменения только
в одну подпрограмму. Кроме того, при использовании подпрограмм чте¬
ния файлов ошибки в данных обнаруживаются при первом же считыва¬
нии, а не месяц спустя, когда данные могут потребоваться.
В структуре программы могут оказаться модули, которые не выпол¬
няют никаких действий. В нашем примере это модуль, обрабатываю¬
щий данные о клиенте, поскольку в выходных данных ни сведения об
отдельных клиентах, ни итоговые данные по ним не содержатся. Подоб¬
ные модули нужно удалить из структуры программы.
Закончив составление иерархической схемы модулей и текстов их
спецификаций, результаты проектирования следует подвергнуть крити¬
ческому анализу. Цель анализа — убедиться в том, что требования,
сформулированные в спецификациях, могут быть выполнены. Вторым
критерием оценки результатов должна быть простота сопровождения
создаваемых программ.
Опытный разработчик, просмотрев схему структуры программы, сра¬
зу же сможет установить, насколько ее проект сбалансирован. В сба¬
лансированном проекте программы каждый логический элемент разде¬
лен на составляющие, но в то же время отсутствует излишняя слож¬
ность и фрагментация логики.
При критическом анализе качества проектных решений по тексту
спецификаций модулей можно воспользоваться контрольным списком,
в который могут входить, например, следующие вопросы:
• Можно ли сформулировать назначение модуля одним предложени¬
ем? Если это так, то, скорее всего, его логика достаточно проста.
• Предназначен ли модуль для обработки данных?
145

• Соответствуют ли процедуры инициализации и завершения своему
прямому назначению и не модифицируют ли они вместо этого какие-
либо физические записи?
В процессе логического проектирования программы применялся це¬
лый ряд процедур по разработке ее логической структуры и технические
ограничения не принимались во внимание. Проект программы может
уточняться на стадии технического проектирования, здесь же важно до¬
биться наиболее элегантных программных решений.
8.5.	Уточнение проекта
Наряду со специальными требованиями, выдвигаемыми пользовате¬
лями и службой сопровождения программного обеспечения, необходимо
принимать во внимание и другие факторы, которые могут оказывать
влияние на проект программы, например смету затрат, имеющиеся тех¬
нические средства, сроки завершения работ, объемно-временные харак¬
теристики программы и т. д. В этом разделе рассматриваются уточне¬
ния, вносимые в логический проект программы с учетом указанных
ограничений. После уточнения проекта может, например, сократиться
размер программы, что упростит ее тестирование, но общая логическая
структура остается неизменной.
Последовательность операций, выполняемых при уточнении проекта,
приведена на рис. 8.17.
1. Проверка приемлемости размера модулей
2. Объединение или разделение модулей
3. Выявление общих функций и выделение самостоятельных модулей
4. Корректировка проекта с учетом ограничений, накладываемых имеющимися тех¬
ническими средствами или используемым программным обеспечением
5. Критический анализ внесенных уточнений
Рис. 8.17. Последовательность операций при уточнении проекта
В строгом соответствии с методом логического проектирования про¬
грамм для каждого блока в структуре файлов разрабатывается отдель¬
ный модуль. Исключение составляют те данные, которые не должны об¬
рабатываться проектируемой программой. При этом одни модули могут
оказаться слишком маленькими (программу, состоящую из таких моду¬
лей, трудно читать из-за фрагментации ее структуры), а другие, наобо¬
рот,— чрезмерно большими (в них трудно разобраться). Поэтому
теперь придется часть модулей либо объединить, либо разделить. Чет¬
ких правил, позволяющих определить оптимальный размер модуля, не
существует, однако можно согласиться с тем, что он колеблется от поло¬
вины страницы текста для простых модулей до нескольких страниц для
сложных.
При дедуктивном подходе к проектированию программ «сверху
вниз» возможны случаи, когда некоторые функции, например вычисле¬
ния, должны будут выполняться в нескольких местах программы. Це¬
лесообразно выявить такие функции и рассматривать их в качестве об¬
щих модулей. Для этого подчеркиваются соответствующие строки в
спецификации программы и расширяется иерархическая схема модулей.
Последняя группа ограничений, затрагивающих проект программы,
связана с особенностями технических или программных средств, кото¬
рые предполагается использовать. В частности, могут вводиться ограни¬
146

чения на объем оперативной памяти либо на применение того или иного
пакета прикладных программ. В таких ситуациях в проект вносятся не¬
обходимые корректировки и примечания.
По завершении всех уточнений выполняется критический анализ
скорректированного проекта. Поскольку, как правило, эти уточнения не¬
существенны, критический анализ можно совместить с проверкой ре¬
зультатов начального этапа проектирования программы либо поручить
его выполнение одному из членов проектной группы.
8.6.	Оптимизация программы
Следующая стадия — оптимизация программы. Любая методология
программирования должна упрощать разработку при сохранении высо¬
ких эксплуатационных характеристик программ. И хотя структурное
программирование в целом удовлетворяет этим требованиям, в отдель¬
ных случаях приходится прибегать к оптимизации.
Объемно-временные характеристики программ, структура которых
полностью соответствует структуре обрабатываемых данных, могут ока¬
заться неудовлетворительными, так как при проектировании не учиты¬
вались реальные объемы данных. Если нужна очень эффективная про¬
грамма, можно принять специальные меры для улучшения ее характе¬
ристик. На последнее замечание следует обратить особое внимание, по¬
скольку опытные разработчики стараются придерживаться следующих
двух правил:
• стараться не проводить оптимизацию;
• оптимизировать программы только при крайней необходимости.
Размеры буферов и блоков, часто заметно влияющие на объемно¬
временные характеристики программы обработки файла, обычно можно
изменять, не затрагивая исходного текста программы. Хорошие резуль¬
таты может дать правильное использование конкретного компилятора
или типа ЭВМ, и с этой целью полезно применять стандартные проект¬
ные решения. В то же время эксплуатационные характеристики про¬
граммы в значительно большей степени зависят от выбора структуры
файлов и методов доступа, чем собственно от техники программирова¬
ния. Это еще раз подчеркивает важность решения таких вопросов на
этапе проектирования системы.
При необходимости увеличить скорость работы программы чаще
всего ее логику не подвергают коренной перестройке, поскольку обыч¬
но замедление счета связано с неэффективной реализацией отдельных
небольших фрагментов программы. Если такие фрагменты выявлены
(здесь опять может помочь анализ структуры файлов), их целесообраз¬
но оптимизировать.
Следует обращать внимание на те модули, которые обрабатывают
наибольшие объемы данных. Они должны программироваться наиболее
оптимальным образом.
8.7.	Физическое проектирование программ
На стадии физического проектирования принимается решение о ра>
делении программы на несколько автономно компилируемых модулей.
При этом должны учитываться следующие факторы:
• действующие в организации нормы на максимальный размер мо¬
дулей;
147

• производительность технических средств;
• возможность применения общих подпрограмм;
• возможность написания самых «ответственных» модулей на языке
более низкого уровня;
• простота тестирования и отладки программы;
• возможность привлечения к работе над программой нескольких
программистов.
Вопрос о реализации программы в виде самостоятельных физиче¬
ских модулей представляется весьма важным, поскольку его правиль¬
ное решение может сократить общее время разработки, а неверное —
Рис 8.18. Логическая структура модулей
увеличить это время в несколько раз. Необоснованное разделение на
физические модули может разрушить логическую структуру программы
и потребовать реализации сложных интерфейсов, что затруднит ее те¬
стирование и сопровождение.
Логический проект программы не должен изменяться при ее физиче¬
ской реализации в виде отдельных модулей. Поэтому физические моду¬
ли следует компоновать из логических модулей.
Необходимо уяснить, с какой целью и как выполняется физическая
структуризация программы. Группа логических модулей, образующих
«ветвь» в логической схеме программы, компилируется совместно в виде
отдельного физического модуля. На рис. 8.18 приведена иерархическая
структура логических модулей, на которой показано, как логические
модули будут объединяться в физические модули. Связи последних по¬
ясняет рис. 8.19. Эта иерархическая схема физических модулей — суще¬
ственная часть проектной документации программы.
148

На практике рассмотренный метод удается применить не всегда
из-за ограничений, связанных с языком программирования. Так, в про¬
граммах, написанных на Коболе, вся обработка какого-либо файла
должна совершаться одним модулем. Поэтому, например, структура мо¬
дулей, представленная на рис. 8.18, несмотря на внешнюю простоту, при
использовании Кобола не »
может быть реализована не¬
посредственно:	основной
файл рассылки здесь обра¬
батывается тремя модуля¬
ми. В этом случае нужно
скомпоновать модуль, обес¬
печивающий выполнение
всех трех функций обработ¬
ки данного файла (рис.
8.20). И хотя такое решение
на первый взгляд может по¬
казаться излишне сложным,
именно оно представляется
оптимальным, поскольку t
К МОДУЛЮ обработки указан-	рис	8.19. Физическая структура модулей
ного файла смогут обра¬
щаться многие программы в
создаваемой системе. Часто полезно выделить подпрограммы ввода-вы¬
вода, так как их можно отладить заранее и тем самым ускорить разра¬
ботку программ доступа к файлам. Второе решение, не предполагаю¬
щее создания автономно компилируемых модулей, — организовать биб¬
лиотеку исходных текстов, из которой в разрабатываемые впоследствии
программы будут включаться разделы, содержание подпрограммы вво-
Рис. 8.20. Физическая структура программы на Коболе
да-вывода в исходной форме. Оба решения упрощают модификацию
программ, обусловленную изменениями в структуре обрабатываемых
ими файлов.
Во многих организациях придерживаются правила, согласно которо¬
му физические модули должны иметь не более одной точки входа и од¬
ной точки выхода. Это разумно для логических модулей, но совершенно
ОБРАБОТКА
ДАННЫХ О
КЛИЕНТАХ
ОБРАБОТКА
ИНТЕРЕСУЮЩИХ
НАС РАЙОНОВ
ОБРАБОТКА
НЕ ИНТЕРЕСУЮЩИХ
НАС РАЙОНОВ
УПРАВЛЯЮЩИЙ
МОДУЛЬ
149

ОТКРЫТИЕ
ВХОД В ОТКРЫТИЕ
ЧТЕНИЕ
необязательно для физических. На логическом уровне проектирования
указанное правило облегчает восприятие программ. Однако слепо сле¬
довать ему нельзя во избежание усложнения физической реализации
программ. Последнее связано с
необходимостью введения допол¬
нительной управляющей логики,
не вытекающей непосредственно
из решаемой прикладной задачи.
Физический модуль имеет смысл
рассматривать как некоторый
удобный способ объединения ло¬
гических модулей. Поэтому в ло¬
гических модулях рекомендуется
сохранять единственную точку
входа и единственную точку вы¬
хода, а при реализации физиче¬
ского модуля это ограничение
целесообразно снять. На рис. 8.21
приведена	структура	типового	физического модуля, а из рис. 8.23 вид¬
но,	насколько	она	усложнится,	если	в модуле будет только одна точка
входа и одна точка выхода.
ЗАКРЫТИЕ
-► выход ИЗ ОТКРЫТИЯ
ВХОД В ЧТЕНИЕ
-► выход из ЧТЕНИЯ
ВХОД В ЗАКРЫТИЕ
-► ВЫХОД ИЗ ЗАКРЫТИЯ
Рис. 8.21. Модуль чтения основного файла
1. Объединение взаимосвязанных логиче¬
ских модулей в физические модули
2. Разработка иерархической схемы физи¬
ческих модулей
3. Спецификация интерфейсов между фи¬
зическими модулями
4. Критический анализ результатов
Рис. 8.22. Задачи физического проектирова¬
ния программы
Рис. 8.23. Модуль чтения основного файла с
единственной точкой входа и выхода
На рис. 8.22 перечислены задачи, решаемые при физическом проек¬
тировании программ.
8.8.	Принципы структурного кодирования
Текст программы, несомненно, является важнейшей частью докумен¬
тации системы, поэтому нужно приложить все усилия, чтобы он был
максимально понятен. Оформление текста программы должно непо¬
средственно отражать ее структуру.
Всегда существует возможность «перевода» спецификаций програм¬
мы на любой язык программирования. При этом, конечно, не следует
забывать о том, что в одних языках структурные средства развиты
больше, чем в других. Ниже мы рассмотрим технику составления про¬
грамм на языках ПЛ/1, Кобол и Бейсик.
Оформление текста программы. При оформлении программы необ¬
ходимо особо пометить в ней логические модули. В начале программы
150

нужно разместить комментарии, в которых раскрывается ее назначение,
структура обрабатываемых ею файлов и перечень ссылочных докумен¬
тов. Для выделения каких-либо частей программы рекомендуется ис¬
пользовать пропуски и нумерацию страниц. Соответствующая система
меток, отражающая порядок следования модулей (например, от А до:
Z), также облегчит чтение программы.
Оформление логического модуля. Модуль должен быть оформлен та¬
ким образом, чтобы при ознакомлении с ним не нужно было обращаться
к другим разделам текста, программы. В комментариях, размещаемых в
начале текста модуля, раскрывается его назначение, описываются спо¬
соб вызова и передаваемые параметры, а при необходимости и зависи¬
мость получаемых результатов от предыдущих обращений к модулю.
Каждая типовая логическая структура должна быть реализована с
помощью одних и тех же конструкций языка программирования, причем
в тексте программы нужно предусмотреть такие же пробелы, как и в
тексте спецификации.
Не следует злоупотреблять комментариями, поскольку по ходу раз¬
работки их придется постоянно корректировать, а уж неверные коммен¬
тарии просто недопустимы. Примечания, включаемые в текст програм¬
мы, необходимо выделять особо и ни в коем случае не смешивать с опе¬
раторами языка программирования.
Введение имен данных. Введение в программу мнемоничных имен
может значительно облегчить ее сопровождение. Имена данных должны
стать объектом унификации. До написания программы полезно соста¬
вить перечень выявленных имен, причем желательно не торопиться и
включить в него полные наименования объектов данных, понятные
пользователям.
При именовании объектов данных нужно стараться избегать возник¬
новения двусмысленности. Например, совершенно недопустимо одно¬
временное существование таких имен:
НОМЕР-СЧЕТА и НОМЕРА-СЧЕТОВ,
КЛЮЧ-СОРТИРОВКИ и КЛЮЧИ-СОРТИРО¬
ВОК и т. д.
По возможности для хранения определений данных рекомендуется
применять автоматизированные средства, поскольку это гарантирует
однозначность толкования имен во всех разработках и упрощает соз¬
дание и изменение программ.
Упрощение сопровождения программ. Программа должна быть мак¬
симально гибкой, чтобы можно было сократить число изменений, кото¬
рые предстоит внести в нее, и заранее спланировать перспективные из¬
менения. Гибкость программы обеспечивается главным образом тща¬
тельным проектированием системы, но кое-что зависит и от програм¬
миста.
Программист должен руководствоваться прежде всего высказанны¬
ми выше соображениями по оформлению программ, особенно в отно¬
шении комментариев и использования автоматизированных средств хра¬
нения описаний данных.
Второй фактор, упрощающий сопровождение программ, — стандарты
на их составление. Если все программы оформлены одинаково и напи¬
саны по одним и тем же правилам, то любой программист сможет бы¬
стро в них разобраться.
И наконец, следует отметить две общие проблемы, возникающие при
написании программ на основе спецификаций: использование операто¬
ра GOTO и сложных условных выражений.
151

Использование оператора GOTO. Структурное программирование
часто отождествляют с отказом от оператора GOTO, что не всегда вер¬
но. Структурное программирование, с одной стороны, означает нечто
большее, чем просто запрещение команды перехода, а с другой — в
принципе не противоречит разумному использованию этого оператора.
В то же время оператор GOTO по ряду причин подвергается справедли¬
вой критике.
Одна из целей, которую преследовали авторы при работе над дан¬
ным разделом книги, — показать, как нужно писать понятные програм¬
мы. Логический модуль, составленный в соответствии с изложенными
здесь рекомендациями, можно прочитать «сверху донизу». Но при появ¬
лении в теле модуля операторов GOTO уследить за логикой становится
труднее. Наличие оператора GOTO свидетельствует о передаче управ-
IF R-W3 NOTE = SPACES AND W1 NOT = ZERO
IF W3 NOT = CMPT (MOD) GO TO PA1 ELSE
JF SW-R = 1 GO TO PA1 ELSE SUBTRACT 1 FROM MOD
)F W1 =C-MPT (MOD) ADD 1 TO MOD MOVE 4 TO W2 GO TO WL.1
ELSE ADD 1 TO MOD GO TO РД1
Рис. 8.24. Пример того, как не следует использовать вложенные условные выражения
ления в программе, причем не очевидно, когда оно будет возвращено.
Такие операторы редко соответствуют логике решения прикладной за¬
дачи, и чем большее-их число вы используете в программе, тем запу¬
таннее будет программа.
Однако в ряде случаев употребление операторов GOTO оправдано
и не усложняет программу. Это прежде всего реализация выхода из
процедуры, цикла или конструкции выбора в языках программирования
(например, в Фортране), которые другими средствами для указанных
целей не располагают. В подобных конструкциях точки входа и выхода
очевидны.
Использование вложенных операторов IF. Многие программисты
подсознательно избегают употребления вложенных операторов IF.
Поэтому мы постараемся здесь показать, что данная конструкция поз¬
воляет эффективно представить логику структурированной программы.
Бесспорно, что при неправильном употреблении вложенные операто¬
ры IF чрезвычайно трудно понять. Это иллюстрируется на рис. 8.24.
Однако попробуем развернуть схему файла (рис. 8.25) на 90°. Мы сра¬
зу же получим структуру вложенных операторов IF, управляющих логи¬
кой его обработки (рис. 8.26). Следовательно, рассматриваемый опера¬
тор можно с успехом и притом достаточно естественным образом при¬
менять для организации обработки иерархических структур данных.
Кроме того, поскольку согласно излагаемой в книге методологии проек¬
тирования программ каждому блоку н'а схеме файла должен соответст¬
вовать отдельный логический модуль в структуре программы, уровень
вложенности операторов IF, скорее всего, не будет превышать 2 или 3.
Критический анализ текста программы. Конечно, организовать и
провести детальный анализ текста программы силами проектной груп¬
пы довольно сложно, поэтому целесообразно поручить одному из чле¬
нов группы проверить откомпилированные тексты программ.
152

Не следует возлагать проверку программы на ее разработчика, При
проверке необходимо проконтролировать точность соответствия текста
программы спецификациям, его понятность и соблюдение стандартов,
действующих в организации. Возникающие при чтении программы воп¬
росы и замечания рекомендуется записывать прямо на листинге. Про¬
граммист должен либо ответить на них, либо изменить текст программы
или имена данных.
КОНЕЦ ЕСЛИ
КОНЕЦ ЕСЛИ
Рис. 8.25. Структура файла	Рис. 8.26. Соответствие иерархической
структуры файла структуре предложений
языка спецификации программ
Итак, главное при чтении текста программы — убедиться в том, что
спецификации правильно преобразованы в конструкции языка програм¬
мирования и что программу легко понять и при необходимости внести
в нее изменения.
8.9.	Составление программ на Коболе
Прежде всего рассмотрим представление типовых логических кон¬
струкций, а затем общие рекомендации по реализации модулей на
Коболе.
Реализация конструкции ЕСЛИ-TO. Эта конструкция имеет прямой
эквивалент в Коболе, причем в тексте программы можно сохранить те
же правила отступа, что и для представления логики действий в специ¬
фикации программы. Если компилятор, с которым вы работаете, допу¬
скает комментарии (отмеченные звездочкой в седьмой позиции текста
программы), то полезно употреблять фразу КОНЕЦ ЕСЛИ. Это упро¬
стит сопоставление текста программы с ее спецификацией. Кроме того,
распространенная ошибка при программировании на Коболе — пропуск
или неправильное размещение точки. Использование комментария КО¬
НЕЦ ЕСЛИ упростит обнаружение подобных ошибок.
Можно составить несложную программу переформатирования исход¬
ного текста, которая в соответствии с правилами, принятыми в органи¬
зации, включит в текст необходимые инструкции пропуска строк и ком¬
ментарии. Если все исходные тексты будут обработаны такой програм¬
мой, это обеспечит их стандартное и корректное оформление.
Основная проблема при реализации конструкции ЕСЛИ-TO заклю¬
чается в преобразовании вложенных условных операторов (рис. 8.27).
153

Если конструкции псевдокода непосредственно представлены соответст¬
вующими операторами Кобола, то, как видно из рисунка, «Предложе¬
ние-3» будет выполняться только в том случае, если верно «Условие-2».
Существуют два варианта решения этой проблемы. Во-первых, мож¬
но дополнительно закодировать «Предложение-3» сразу после «Предло¬
жения-1». Если «Предложение-3» занимает не слишком много строк,
такое решение вполне оправдано. Во-вторых, можно удалить вложен¬
ный оператор IF, выполнить проверку после анализа условия-1 и офор-
1F УСЛОВИЕ-1
IF УСЛОВИЕ-2
ПРЕДЛОЖЕНИЕ-1
ELSE
ПРЕДЛОЖЕНИЕ-2
END IF
ПРЕДЛОЖЕНИЕ-.З
ELSE
ПРЕДЛОЖЕНИЕ-4
END IF
Рис. 8.27. Вложенные условные вы-	Рис.	8.28.	Реализация	.	конструкции	выбора
ражения, которые нужно записать	в Коболе
на Коболе
мить ее в виде отдельного параграфа. Программа, правда, станет
несколько менее понятной, но на это придется пойти ради сохранения
ее логической структуры.
Размещение параграфов, содержащих вложенный оператор IF, рас¬
сматривается ниже, при анализе преобразования логических модулей.
Реализация конструкции ВЫБОР. Пример наиболее простого спосо¬
ба реализации конструкции выбора на Коболе приведен на рис. 8.28.
Применение управляемого перехода и вложенного оператора IF имеет
свои отрицательные стороны.
Предложенный пример наиболее точно соответствует конструкции
псевдокода и реализуется в большинстве компиляторов Кобола. Ско¬
рость выполнения фрагмента программы можно слегка повысить, если
проверку наиболее часто выполняемых условий производить в первую
очередь. Противники употребления оператора GOTO вполне могут со¬
ставить аналогичную конструкцию, используя только операторы IF, но
поскольку при работе программы должны проверяться все условия, ско¬
рость ее выполнения может несколько снизиться. Кроме того, при
написании подобной конструкции более вероятны ошибки.
Реализация конструкции ПОВТОРЯТЬ ПОКА. Эквивалентом этой
конструкции в Коболе является PERFORM UNTIL NOT. Отрицательное
условие используется для того, чтобы можно было не учитывать значе¬
ний данных, которые следуют за фразой ПОВТОРЯТЬ ПОКА, но не
обрабатываются в цикле.
IF
ТИП-ЗАПИСЕЙ = 'A'
КОД ДЛЯ ОБРАБОТКИ А
GOTO CASE—EXIT.
IF
ТИП-ЗАПИСЕЙ = 'В'
КОД ДЛЯ ОБРАБОТКИ В
GO ТО CASE—EXIT.
IF
ТИП-ЗАПИСЕЙ = 'С'
КОД ДЛЯ ОБРАБОТКИ С
GOTO CASE-EXIT.
CASE
-EXIT.
EXIT.
154

Обычно в теле цикла выполняется отдельный раздел программы
(т. е. логический модуль). Поэтому фрагменту спецификации
ПОВТОРЯТЬ ПОКА есть данные по областям
Обработать данные по области
КОНЕЦ ПОВТОРЕНИЙ
на Коболе будет соответствовать оператор
PERFORM OBR—OBL UNTIL NOT OBL.
Если тело цикла состоит из нескольких операций, их нужно выде¬
лить в самостоятельный параграф и выполнить его, например:
PERFORM POVTOR—РОКА—DETAL UNTIL NOT DETAL.
Здесь POVTOR — РОКА — DETAL — заголовок параграфа в данном
разделе программы.
BA—OBR—OBL SECTION
***	комментаии	***
***	р	***
ВАШ.
Реализация основной логики
ВА20. GOTO BA—EXIT
***	реализация вложенного ЕСЛИ	***
***	***
В A—EXIT
EXIT.
Рис. 8.29. Логический модуль на Коболе
Реализация логических модулей. В программе на Коболе логическо¬
му модулю соответствует отдельный раздел, название которого раскры¬
вает смысл выполняемых действий. При необходимости включаются
комментарии. За ними следуют операторы, управляющие выполнением
параграфов основной части раздела. После управляющих операторов
выполняется переход на конец раздела. Далее идут операторы основ¬
ной части. Отметим, что их приходится кодировать, когда прямая реа¬
лизация логических конструкций псевдокода, например вложенного опе¬
ратора ЕСЛИ или ВЫПОЛНЯТЬ ПОКА, на Коболе невозможна.
На рис. 8.29 приведен пример реализации логического модуля на
Коболе. Здесь необходимо отметить следующее:
• Приставка в названиях разделов и параграфов позволяет связать
текст программы с иерархической схемой модулей.
• Параграф ВА10 введен только из-за ограничений, вносимых мно¬
гими компиляторами Кобола. Поскольку никакие действия не выполня¬
ются, название параграфа содержит только приставку.
• Оператор GOTO используется лишь для перехода в конец раздела.
• Параграфы EXIT целесообразно использовать, так как они содер¬
жат метку для выхода из раздела и указывают окончание логического
модуля.
155

8.10. Составление программ на ПЛ/1
Язык ПЛ/1 включает развитые средства структурирования про¬
грамм, и поэтому может с успехом применяться при структурном под¬
ходе к их разработке. Рассмотрим правила реализации типовых логи¬
ческих конструкций и логических модулей.
СПЕЦИФИКАЦИЯ
ВЫБОР ТИП ЗАПИСЕЙ
ВАРИАНТ ЗАГОЛОВОК СЧЕТА
НАКАПЛИВАТЬ ИТОГ ПО СЧЕТАМ
ВАРИАНТ СТРОКА СЧЕТА
НАКАПЛИВАТЬ ИТОГ ПО СЧЕТУ
ОБРАБОТАТЬ СТРОКУ
ВАРИАНТ ПРОЧЕЕ
ОБРАБОТАТЬ ДАННЫЕ ПО СЧЕТУ
КОНЕЦ ВЫБОРА
PL/1
SELECT (FA—REC—TYPE);
WHEN (ACCOUNT^HEADER)
WA-ACCOUNT-TOTAL« WA-ACCOUNT-TOTAL t 1;
WHEN (ACCOUNT-DETAIL)
DO
WA-DETAI L-TOTAL = WA-DETAIL—TOTAL + 1;
CALL BAA-ACCOUNT-DETAIL;
END:
OTHER WISE
CALL BAB-ACCOUNT-INFO;
END:
Рис. 8.30. Реализация конструкции выбора на ПЛ/1
СПЕЦИФИКАЦИЯ
ОБРАБОТАТЬ ДАННЫЕ ПО ПОСТАВКЕ
ПОВТОРЯТЬ ПОКА ЕСТЬ ДАННЫЕ ПО ПОСТАВКАМ
ПЕЧАТАТЬ СЧЕТ-ФАКТУРУ
ЧИТАТЬ ДАННЫЕ ПО ПОСТАВКЕ
КОНЕЦ ПОВТОРЕНИЙ
ПЕЧАТАТЬ ИТОГИ ПО СЧЕТАМ
РЕ/1
PROCESS DELIVERY
PROC' (parameter list);
DCL parameters;
/* *!
/♦description of module*/
/* explanation of complex Code (if required) */
DCL local variables (if any) ,
DO WHILE (delivery);
code to print invoice;
CALL READ—DELIVERY (argument list);
END;
code to print invoice summary;
END;
156
Рис. 8.31. Реализация логического модуля на ПЛ/1

Реализация конструкции ЕСЛИ-TO. Простая конструкция ЕСЛИ-ТО
имеет в языке ПЛ/1 прямой эквивалент IF —THEN.
Вложенные конструкции ЕСЛИ-TO требуют при реализации боль¬
шего внимания, поскольку может оказаться необходимым использовать
группы операторов DO; . . . END; .
Конструкция ВЫБОР. В настоящее время во многих версиях ПЛ/1
имеется эквивалентная конструкция SELECT (рис. 8.30).
Реализация конструкции ПОВТОРЯТЬ ПОКА. Прямой эквивалент
этой конструкции в ПЛ/1 —группа операторов DO WHILE . . . END; .
Реализация логических модулей. Логические модули реализуются в
ПЛ/1 посредством внутренних процедур, каждая из которых содержит
объявления параметров и локальных переменных, что существенно уп¬
рощает восприятие программ (рис. 8.31). Физические модули реализу¬
ются посредством внешних процедур.
8.11.	Составление программ на Бейсике
Язык Бейсик не ориентирован на структурное программирование.
Программы на Бейсике громоздки, их трудно читать и модифицировать.
Комментарии почти не применяются, поскольку на них расходуется па¬
мять. Числовые метки затрудняют восприятие логики программы.
Фирма BIS Applied Sys¬
tems Ltd с учетом недостатков
Бейсика разработала препро¬
цессор этого языка, который
позволяет вводить в програм¬
му дополнительные управляю¬
щие операторы и мнемоничные
метки (рис. 8.32). Пример реа¬
лизации типовых логических
конструкций на структурном
Бейсике приведен на рис. 8.33.
Препроцессор генерирует
следующие выходные данные:
• модифицированный ис¬
ходный текст на расширенном
Бейсике с отступами, полнее
отражающими логику про¬
граммы;
• исходный текст програм¬
мы на базисном Бейсике
в максимально сжатой форме,
что позволяет интерпретатору
строить программу, занимаю¬
щую МИНИМалЬНЫЙ объем па- рис 8.32. Реализация основных логических
МЯТИ.	конструкций на структурном Бейсике
Первый вариант текста про¬
граммы сохраняется в качест¬
ве документа, который может быть впоследствии отредактирован
и вновь обработан препроцессором структурного Бейсика. Сжатый
текст хранится как рабочая версия программы.
Второе важное свойство препроцессора — он может быстро собирать
программы, составленные в виде группы небольших модулей. Это свой¬
ство полезно при реализации общих модулей.
DO WHILE X <
; 20
ОПЕРАТОРЫ БЕЙСИКА
END DO
IF I = J
ELSE
ОПЕРАТОРЫ БЕЙСИКА
END IF
CASE ПО ЗНАЧЕНИЮ A
CASENTRY A = 1
CASENTRY A = 2
CASEOTHER ОПЕРАТОРЫ БЕЙСИКА
V_.
END CASE

Для того чтобы программы, написанные на Бейсике, были понятны,
необходимо включить в них некоторые управляющие структуры. Поэто¬
му до тех пор, пока язык не будет соответствующим образом расширен,
применение препроцессора представляется наилучшим решением всех
проблем.
220	DO WHILE 1%<N%	'!5
230	ON ERROR GO TO ERROR:	'!6
240	OPEN "I", И 1, F$	(1%)
250	ON ERROR GO TOO
260	GOSUB TOP-OF-PAGE
270	LPRINT "FILE -	F$	(1%)
280	LPRINT STRINGS	(7 +	LEN (F$ (1%)),
290	LPRINT
300	C% = C% + 3 ' УВЕЛИЧИТЬ ЗНАЧЕНИЕ СЧЕТЧИКА СТРОК
310	DO WHILE NOT EOF (1) :	47
320	LINE INPUT V41, W$:	'!8
330	W1%=1 ' СЧЕТЧИК ЛИТЕР В СТРОКЕ
340	DO WHILE W1%<LEN	(W$)'ЕЩЕ ЕСТЬ МЕСТО:	49
350	IF C%>M%—B% 'СТРАНИЦА ЗАПОЛНЕНА:	410
360	GOSUB	BOTTOM—OF-PAGE:	411
370	GOSUB	TOP-OF-PAGE
380	END IF	412
390	LPRINT MID$ (W$, W!%, W%) :
400	C%=C%+1' УВЕЛИЧИТЬ ЗНАЧЕНИЕ СЧЕТЧИКА СТРОК
410	W1%=W1%+W%
420	END DO
430	END DO	413
440	GOSUB BOTTOM-OF-PAGE:	414
450	LABEL RESUME:	415
460
470	CLOSE 1
480	1%=1%+1
490	END DO
500	END:	416
510 '
520	LABEL ERROR:	417
530	'
540	PRINT "ФАЙЯF$ (1%);	" 'HE НАЙДЕН"
550	RESUME LABEL	(RESUME)
Рис. 8.33. Пример структурного представления программы на
Бейсике
8.12.	Тестирование программы
При тестировании проверяется, работает ли программа и все ее вет¬
ви в соответствии со своей спецификацией. Для того чтобы убедиться в
том, что программист правильно понимает функции программы, и обес¬
печить полный и эффективный контроль всех ее ветвей, заранее разра¬
батывается стратегия тестирования. В настоящем разделе мы обсудим
основные вопросы, связанные с формированием этой стратегии.
Источники тестовых данных. В идеальном случае тестовые данные
должны быть подготовлены проектной группой или, по крайней мере,
автором спецификации программы. Эти данные помогают программи¬
сту понять программу и, кроме того, в какой-то степени служат гаран¬
тией того, что программа при тестировании оправдает ожидания разра¬
ботчиков. Если в процессе программирования появится необходимость в
дополнительных тестовых данных, их может подготовить сам програм¬
ме

мист. В качестве примера можно привести уточненные условия возник¬
новения сбоев, которые программист обычно выявляет при проектиро¬
вании программы.
На практике, однако, подготовку тестовых данных часто целиком
поручают программисту. В результате ошибки могут остаться необна¬
руженными вплоть до тестирования системы или ее комплексной от¬
ладки.
Формирование единого набора тестовых данных для системы гаран¬
тирует их достоверность и уменьшает трудоемкость тестирования. На
подготовку данных с помощью утилит программисты, как правило, тра¬
тят слишком много времени. Для полного тестирования программы не¬
редко требуется предоставить множество записей в нескольких файлах
и тщательно спланировать саму процедуру тестирования, поскольку
проверить работу программы при наличии сложных связей между фай¬
лами весьма непросто.
Определение объема тестирования. Как уже отмечалось, необходи¬
мо убедиться в том, что программа работает в соответствии со своей спе¬
цификацией. Объем испытаний может ограничиваться проверкой лишь
основной логики, а может заключаться в тестировании каждой ветви
или логического пути, вплоть до отдельных логических модулей со все¬
ми комбинациями входных данных.
Обычно каждая ветвь программы должна проработать хотя бы один
раз, при этом следует проверить все основные комбинации условий,
включая ошибочные ситуации. Составление детального плана тестиро¬
вания— это наиболее ответственный аспект программирования. Любая
небрежность, как правило, приводит к реализации неудачных программ
и срыву сроков выполнения работ.
Для проведения полноценного тестирования необходим формальный
подход. В системе Modus с этой целью для каждого логического моду¬
ля заполняется контрольный лист условий, подлежащих проверке.
Контрольный лист тестирования модуля. Контрольный лист тестиро¬
вания модуля приведен на рис. 8.34. В него вносится описание каждой
проверки и ожидаемые результаты. Должны быть проверены все логиче¬
ские конструкции, представленные в спецификации на псевдокоде.
В конструкции ЕСЛИ проверяется как истинное, так и ложное усло¬
вие, в конструкции ПОВТОРЯТЬ ПОКА — как повторение цикла, так
и прекращение итераций, а в конструкции ВЫБОР — каждое условие.
Приводятся также ссылка на запись или записи, с помощью которых
будут проверяться условия. Объем данных, содержащихся в файлах, не
имеет значения, поскольку в тестировании должно участвовать только
небольшое число записей.
После выполнения проверки на контрольном листе проставляется
дата тестирования. При модификации программы необходимо испытать
те модули, в которые были внесены изменения.
Стратегия тестирования. Простейший метод тестирования программ
заключается в компиляции всех логических модулей и последующей
проверке работы программы. Существуют три альтернативных вариан¬
та тестирования: нисходящее, восходящее и раздельное, отличающиеся
порядком кодирования модулей и процедурой передачи данных тести¬
руемым компонентам.
Нисходящее тестирование. В соответствии с принципом нисходящего
проектирования первым кодируется управляющий модуль. Вместо всех
модулей второго уровня ставятся заглушки (см. ниже), затем управля¬
ющий модуль тестируется с привлечением файлов, назначенных ему
операторами управления заданием, и модулей-заглушек. После отладки
159

управляющего модуля модули-заглушки второго уровня расширяются
до их полной спецификации. Далее эти модули тестируются с помощью
данных, передаваемых им через управляющий модуль и с использова¬
нием заглушек для модулей третьего уровня.
Процесс тестирования каждого модуля с заглушками вместо моду¬
лей нижнего уровня продолжается до полного кодирования и тестирова¬
ния всех модулей. Необходимо отметить, что при тестировании моду¬
лей нижних уровней данные проходят через всю программу, поэтому
специального тестирования последней не требуется.
Программа: BF010A (печать сведений о магазинах)
Модуль: ВА (обработка данных по районам)
Дата: 30.02.81
Автор: Джилл Блэй
Проверка
Описание
Файл/
запись
Дата
проверки
Район, в котором имеется несколько ма¬
газинов
— название района должно появиться
в отчете
Магазин с объемом продаж свыше 1 тыс.
ф. ст.
— в отчете должны появиться полные
сведения о магазине
Магазин с объемом продаж менее 1 тыс.
ф. ст.
— в отчете должно появиться только
название магазина
Район, в котором нет магазинов
— специальное сообщение
TESTM-
MF1
16—23
TESTM-
MF1
17
TESTM-
MF1
19
TESTM-
MF2
3
17.07.81
17.07.81
17.07.81
17.07.81
Рис. 8.34. Контрольный лист тестирования модуля
Один из вариантов этого метода состоит в тестировании одной пол¬
ной ветви программы. Первой проверяется (с использованием при не¬
обходимости заглушек) управляющая логика. Некоторые системы реа¬
лизуются очередями, причем вначале, до полного тестирования програм¬
мы, обрабатывается некоторое подмножество данных. Такой порядок
реализации системы возможен, поскольку при разработке каждой про¬
граммы нетрудно предусмотреть отдельные ветви для обработки раз¬
личных данных. Это может оказаться весьма полезным, так как часто
10% обрабатываемых типов данных могут на 90% обеспечить потреб¬
ности пользователей.
Модули-заглушки. Модули-заглушки имитируют работу реальных
модулей. Они обычно содержат описания данных для редактора связей,
операторы ввода данных, переданных модулю, и операторы, возвраща¬
ющие данные вызывающему модулю.
Следует отметить, что большую часть операторов модуля-заглушки
можно применять и в реальном модуле, поэтому издержки, связанные
с созданием заглушки, невелики.
Восходящее тестирование. Метод восходящего проектирования логи¬
чески противоположен методу нисходящей разработки программ. Поле¬
160

зен он в тех случаях, когда программа состоит из отдельно компилируе¬
мых физических модулей. Первыми обычно кодируются и тестируются
с помощью «имитаторов» вызывающих модулей физические модули
нижнего уровня. Передача данных и имитация вызывающих модулей
упрощается при использовании специальных программ-тестировщиков.
Такая программа имитирует работу вызывающих модулей и обеспе¬
чивает передачу данных в тестируемый физический модуль и из него.
Данные, создаваемые физическим модулем, выводятся на печать. Неко¬
торые программы-тестировщики осуществляют также автоматическую
проверку полученных и ожидаемых результатов, многократное тестиро¬
вание за один прогон и автоматическое исправление ошибок.
После того как составлены и испытаны все физические модули ниж¬
него уровня, тестируются физические модули следующего верхнего
уровня, причем совместно с только что проверенными модулями. Этот
процесс продолжается до тех пор, пока не будут составлены и оттести¬
рованы все физические модули. Управляющий модуль кодируется и те¬
ст и руг гея последним.
Такой метод наиболее удобен при испытании программ модульной
структуры и при наличии квалифицированных программистов.
Раздельное тестирование. Этот метод (один из вариантов метода
восходящего проектирования) применяется только для раздельно ком¬
пилируемых физических модулей. Он весьма полезен в тех случаях,
когда программу не удается полностью специфицировать либо когда
имеется один критический модуль, на характеристики которого накла¬
дываются определенные ограничения, и он должен быть испытан до
принятия решения о работоспособности программы. Процедура тестиро¬
вания разбивается на две стадии:
• автономная разработка каждого физического модуля с имитацией
вызывающего модуля и использованием модулей-заглушек;
• совместное редактирование связей уже проверенных модулей и
комплексное тестирование.
Тестирование программы в целом. Программа тестируется как еди¬
ное целое, а не как совокупность отдельных модулей. Все тестовые дан¬
ные используются одновременно, соответственно изменяются контроль¬
ные листы модулей. Основное достоинство этого метода — его простота.
Кроме того, сл.едует отметить меньшие затраты машинного времени,
отсутствие необходимости устанавливать модули-заглушки и применять
программу-тестировщик.
Выбор метода. Простейший метод — тестирование программы в це¬
лом, у. отказываться от его применения следует лишь по очень веской:
причине. Все остальные методы увеличивают трудозатраты на проверку
программы и расход машинного времени. Они применяются обычно для
тестирования сложных, громоздких программ или в условиях дефицита
программистов.
Другие подходы к тестированию программ. В большинстве органи¬
заций тестирование проводит программист, спроектировавший и соста¬
вивший программу. Передача программы для тестирования другому
программисту вряд ли целесообразна в основном по соображениям пси¬
хологического характера, поскольку он предпочтет поиск ошибок в
программе их исправлению. Тестирование больших и сложных про¬
грамм можно упростить, подключив к испытаниям двух специалистов:
«контролера», отвечающего за соответствие работающей программы
спецификациям, и «сапера», пытающегося «взорвать» программу. Они
могут предоставлять любые входные данные и анализировать результа¬
ты. Программа должна отвергать неверные данные.
6 Зак. 1783
161

Любые необходимые изменения могут вноситься либо лицом, выпол¬
няющим тестирование, либо автором программы. Первому из них обыч¬
но удается обеспечить эффективное тестирование программы в тех ус¬
ловиях, в которых ей предстоит работать, а автор в это время может
работать над другими программами.
Локализация и исправление ошибок. После обнаружения ошибки ее
необходимо локализовать и исправить. Поскольку рассматриваемый ме¬
тод проектирования обеспечивает локализацию обработки каждого эле¬
мента данных в программе, для этого должна потребоваться только
одна корректировка. Если предлагаемое изменение затрагивает какие-то
другие разделы программы, необходимо тщательно проанализировать
его возможные последствия. В случае затруднений при локализации
ошибки часто полезно дополнительно привлечь к работе кого-нибудь из
специалистов. Как правило, любой программист, анализируя ошибки,
может найти собственное решение.
После локализации ошибки целесообразно внимательно проверить
весь модуль. Не исключено, что будут выявлены еще какие-то ошибки
(например потому, что эта часть программы была написана в пятницу
после обеда). Если корректировка требует серьезных изменений, необ¬
ходимо проанализировать текст программы полностью. В заключение
нужно обязательно скорректировать документацию.
8.13.	Проектирование программ для систем реального времени
Проектирование программ для систем реального времени выполня¬
ется в той же последовательности, что и пакетных. Большинство про¬
грамм в системах реального времени не обменивается данными с экра¬
ном. Обычно эта функция реализуется специальными программными
средствами, называемыми телемониторами.
Телемониторы. Телемонитор — это специализированный ППП, рас¬
ширяющий возможности операционной системы по взаимодействию цен¬
тральных устройств ЭВМ с терминалами через линии связи, модемы,
коммуникационные процессоры и т. д. пР и использовании телемонито¬
ра значительно упрощается программирование задач телеобработки,
поскольку прикладная программа может вызывать необходимые функ¬
ции, реализуемые этим ППП, с помощью оператора CALL или (реже)
некоторого расширения базового языка. Например, отдельные телемо¬
ниторы позволяют применять операторы ACCEPT (ПРИНЯТЬ) и
DISPLAY (ВЫДАТЬ).
Телемониторы часто ориентированы на конкретный тип оборудова¬
ния. Например, телемонитор фирмы IBM нельзя использовать на обору¬
довании фирмы ICL, и наоборот. Особенности каждого телемонитора
обусловливают определенный порядок обращения к нему, который дол¬
жен соблюдаться в прикладной программе. С точки зрения проектиро¬
вания программ интерес представляют две группы телемониторов:
• диалоговые, позволяющие осуществлять ввод и вывод данных на
терминал аналогично чтению и размещению записей в файле;
• недиалоговые, которые, приняв данные, передают управление соот¬
ветствующей прикладной программе; после выдачи ответа программа
возвращает управление телемонитору1.
1 Прежде чем передать управление, кроме того, такой телемонитор выделяет необ¬
ходимые программе ресурсы и освобождает их, когда программа возвращает управле¬
ние. — Примеч. пер.
162

Иными словами, в среде недиалогового телемонитора за один вызов
прикладная программа обрабатывает только два сообщения (входное
и выходное), тогда как под управлением диалогового телемонитора она
может обработать несколько сообщений. Исходя из этих различий не¬
обходимо придерживаться одного из описанных ниже подходов к проек¬
тированию программ.
Введем несколько определений.
Сообщения. Сообщения, которыми программа обменивается с терми¬
налом, состоят из двух частей:
• управляющей области, содержащей такую информацию, как иден¬
тификатор терминала и сообщения, код состояния и т. д.;
• области данных, содержащей данные, которые введены пользова¬
телем с экрана или предназначены для отображения на экране.
Рис. 8.35. Структура входной транзакции
Область сохранения данных. Недиалоговые мониторы должны сох¬
ранять результаты обработки одного входного сообщения для обработ¬
ки последующих. Например, при обработке заказа может потребовать¬
ся, чтобы код клиента записывался для каждой строки заказа. Эти све¬
дения хранятся обычно на диске в так называемой области сохранения
данных. Данные размещаются в ней программой непосредственно перед
передачей управления телемонитору и восстанавливаются последним
всякий раз при вводе нового сообщения оператором терминала. Одни
телемониторы управляют областью сохранения данных автоматически,
другие же требуют этого от прикладной программы.
Проектирование программы. Проектирование прикладных программ
выполняется в общем случае вне зависимости от типа применяемого те¬
лемонитора. Определенные отличия имеются в способах уточнения
структур файлов и спецификации логики программы на псевдокоде. Все
эти вопросы рассматриваются ниже.
Структура файлов. Структура файлов разрабатывается здесь таким
же образом, как и для ф.айлов, обрабатываемых пакетными программа¬
ми. В нее включаются входные транзакции, которые состоят из не¬
скольких входных сообщений. Например, транзакция обработки заказа
может иметь структуру, приведенную на рис. 8.35. В этом случае эле¬
ментами входных сообщений будут «Клиент», «Заказ», «Принять заказ»,
«Отклонить заказ». Структура «файла» для вывода на экран показана
на рис. 8.36. Если какой-либо экран содержит повторяющиеся группы
данных или факультативные данные, их следует отразить в структуре
файла. В программах систем реального времени в качестве управляю¬
щего файла всегда рассматривается файл входных сообщений.
Уточненная структура файла. Процедура уточнения структуры фай¬
ла в среде диалогового монитора аналогична таковой для пакетных
программ с той лишь разницей, что сообщения, вводимые с терминала,
6*
163

трактуются как записи некоторого файла. Напршмер, для упоминавшей¬
ся выше транзакции обработки заказа возможна уточненная схема
структуры файла, показанная на рис. 8.37 и 8.38.
Так как программы, работающие в среде недиалогового телемонито¬
ра, могут обрабатывать только одно входное сообщение при одном обра-
Рис. 8.36. Структура «файла» для вывода данных на экран
щении, транзакции приходится рассматривать как двухуровневые иерар¬
хические структуры1 (рис. 8.39). Структура файла уточняется обычным
способом, но каждое входное сообщение обрабатывается изолированно.
Особенности спецификации. Спецификация программ выполняется
по завершении уточнения структуры файлов. Эта процедура для диало-
Рис. 8.37. Уточненная структура файла для обработки в оперативном режиме
гового монитора мало отличается от аналогичной процедуры при созда¬
нии пакетных программ. Единственное существенное отличие заключа¬
ется в том, что программа немедленно прекращает свою работу при при¬
еме сообщения «КОНЕЦ». Последнее должно восприниматься в любой
части программы. Пример спецификации управляющего модуля для
диалоговой программы приведен на рис. 8.40.
Подходы к проектированию программ для систем реального времени
и пакетной обработки несколько различаются, а именно:
1 При каждом вызове программы обрабатывается какой-либо один элемент нижне¬
го уровня. — Примеч. пер.
164

t-
ш
I
' г;
<
>.
CJ
cz
<
tn
о
о
<
cz
<
о
cz
<
<
<
со
JD
, h-
s
X
о
*
I-
o
¥
<
CO
S5
СЕ ш
< З'
ш С
s9
- 3C
¥ 3 ш
со О X
4)
S
X
X
4)
a
a
4)
с
о
о
VO
»0
a
vo
о
с;
<o
с;
>x
ГО
*0*
а
>ч
а
x
Ф
X
т
о
У-
165

• Модули, разрабатываемые по нисходящему принципу, содержат
конструкцию «ВЫБОР», зависящую от типа сообщения. Для некоторых
телемониторов перечень вариантов выбора будет представлять собой
список внутренних подпрограмм телемонитора, а не прикладных про¬
грамм.
Рис. 8.39. Структура файла входных сообщений
• Для входа в программу используется общий модуль, обеспечива¬
ющий всю внутреннюю обработку и прием входных сообщений.
- Точно так же выход из программы осуществляется с помощью об¬
щего модуля, обеспечивающего внутреннюю обработку и форматирова¬
ние данных для выдачи на экран терминала.
• Если телемонитор не поддерживает область сохранения данных
автоматически, то за их сохранность и восстановление «отвечает» при¬
кладная программа.
УПРАВЛЕНИЕ
УПРАВЛЕНИЕ
А — Инициализация
А - Инициализация
В — Проверить сообщения "клиент”
ПОВТОРЯТЬ ПОКА ошибка в данных о клиенте
ВЫБОР в зависимости от входного сообщения-
ВАРИАНТ клиент
В - Проверить сообщение "клиент"
В - Сообщение "клиент"
КОНЕЦ ПОВТОРЕНИЙ
ВАРИАНТ тоедр
С — Обработать верные данные о клиенте
С — Сообщение "трвар"
ПОВТОРЯТЬ ПОКА есть товары
ВАРИАНТ заказ принят
D - Обработать данные о товаре
D - Принять заказ
КОНЕЦ ПОВТОРЕНИЙ
ВАРИАНТ Заказ отклонен
Е - Проверить сообщение "подтверждение"
Е — Отклонить заказ
КЙНЁЦ ПОВТОРЕНИЙ
ВАРИАНТ прочее
ЕСЛИ заказ принят
F — Прочее
F — Обработать принятый заказ
ИНАЧЕ
ВАРИАНТ конец
G — Конец
G — Обработать отклоненный заказ
ВАРИАНТ нераспознано
КОНЕЦ ЕСЛИ
' Н -> Ошибка
ZZ - Завершение
КОНЕЦ ВЫБОРА
Рис. 8.40. Спецификация управляющего	Рис. 8.41. Спецификация управляющего мо-
модуля для диалогового телемонитора	дуля для недиалогового телемонитора
• Точно так же, если телемонитор не выполняет инициализацию ра¬
бочих областей, например для экрана, автоматически, это должна де¬
лать прикладная программа.
Спецификация управляющего модуля, предназначенного для работы
в среде недиалогового телемонитора, приведена на рис. 8.41.
Сопоставление режимов. Некоторые телемониторы, например C1CS,
могут работать как в диалоговом, так и недиалоговом режимах. Кроме
того, любой диалоговый телемонитор можно использовать как недиало¬
говый. В чем же состоят преимущества и недостатки каждого из ре¬
жимов?
166

Логика прикладной программы, разработанной для диалогового те¬
лемонитора (как и логика пакетной программы), более точно соответ¬
ствует логике автоматизируемой функции. С этой точки зрения легче
организовать сопровождение такой программы.
Диалоговые мониторы уязвимы с точки зрения процедуры восстанов¬
ления. При машинном или программном сбое во время обработки тран¬
закции программа не может повторить все выполненные действия, по¬
скольку ее состояние в момент сбоя нигде не регистрируется. Это озна¬
чает, что данные, введенные до сбоя, должны быть введены повторно.
Программы, разработанные для применения в среде недиалогового
монитора, труднее сопровождать, так как они в меньшей степени соот¬
ветствуют автоматизируемым функциям (входные сообщения, как упо¬
миналось выше, приходится логически разделять).
В недиалоговых телемониторах, как правило, более эффективна про¬
цедура восстановления, которая обычно реализуется на уровне сообще¬
ний. Кроме того, поскольку процессы обработки каждого сообщения ло¬
гически обособлены, можно физически разделить и реализующие их
модули, что позволит сэкономить память. В результате вся система смо¬
жет функционировать на менее мощных ЭВМ с меньшим объемом опе¬
ративной памяти.
Заключение. Единого подхода к разработке программ для систем
реального времени не существует, так как многое здесь зависит от типа
используемого телемонитора и его характеристик, от процессора и дру¬
гой аппаратуры, характера прикладной задачи и требуемой степени
восстановления работоспособности программы. Эти вопросы не могут
решаться только программистом. Целесообразно создать комплекс стан¬
дартов, которые применялись бы во всех разработках, ориентированных
на конкретный тип оборудования.
8.14.	Разработка программ в диалоговом режиме
Автоматизированное рабочее место (АРМ)1 программиста предна¬
значено для решения задач, связанных с разработкой и сопровождени¬
ем программного обеспечения в диалоговом режиме. Программисты
предпочитают' работать за пультом терминала, а не с карандашом и
бумагой. Возможности разных АРМ существенно различны, но все они
нацелены на повышение производительности труда программистов.
Вопреки сложившемуся мнению применение АРМ не препятствует
структурному программированию. Наоборот, для эффективного исполь¬
зования средств диалоговой разработки программ необходим методиче¬
ски обоснованный подход.
В настоящем разделе описываются средства, типичные для систем
диалоговой разработки программ, и рассматриваются способы их эф¬
фективного использования при реализации структурного метода проек¬
тирования.
Командный язык. Командный язык предназначен для запуска про¬
грамм. При наличии хорошего командного языка от программиста не
требуется, чтобы он в совершенстве владел языком управления задани¬
ями. Это позволяет уменьшить число ошибок на 20—30%.
Контроль изменений. Можно добиться точной регистрации измене¬
ний в программах, для чего необходимо поддерживать последователь¬
ные версии программ, в которых отражается их «история»: сведения о
1 В оригинале использован термин «workstation»--рабочая станция. -- Примеч.
пер.
167

датах, авторах и причинах изменений. Точно так же можно следить за
изменением тестовых файлов.
Инструментальные средства проектирования программ. Предусмот¬
рены средства для автоматизированной генерации иерархических схем
модулей. Некоторые системы позволяют вводить описание программы с
помощью псевдокода и «стимулируют» использование программистом
только трех основных логических конструкций. Можно получать табли¬
цы соответствия имен данных по разделам.
Редактирование. Текстовый редактор обеспечивает внесение любых
изменений в программу или файл. Можно по желанию изменять или за¬
менять строки литер. Оформление программ облегчается благодаря на¬
личию средств табулирования и управления форматом. Сокращения,
введенные программистом, могут распознаваться и автоматически рас¬
шифровываться системой, что сокращает время, затрачиваемое на про¬
граммирование, и упрощает сопровождение программ.
Средства отладки. В настоящее время имеются средства корректи¬
ровки и интерактивной отладки, позволяющие исправить ошибки во
время компиляции или контрольного запуска программы и затем про¬
должить ее тестирование.
Управление проектами. Многие системы могут предоставить точную
информацию об объеме сгенерированного программного кода, числе ком¬
пиляций и выполненных тестов, а также о времени, затрачиваемом каж¬
дым программистом на разработку программы. Более широкими воз¬
можностями в плане управления проектами обладают специализирован¬
ные пакеты прикладных программ.
Использование элементов структурного программирования. Некото¬
рые программисты полагают, что, получив доступ к терминалу, они
должны сидеть за ним с момента создания спецификации программы и
до окончания ее тестирования. Такой стиль работы способствует приня¬
тию необдуманных решений и появлению множества ошибок из-за не¬
внимательности программиста.
Проектирование программы и критический анализ проекта должны
всегда предшествовать работе с терминалом. Первичный ввод програм¬
мы лучше поручить оператору, квалификация которого в данном случае
выше, чем у программиста. Однако отдельные программисты предпочи¬
тают сразу набирать программу, а не писать ее на бланках.
Текст программы, написанный каким-либо программистом, должен
быть прочитан другим программистом, поскольку программа может
оказаться малопонятной и содержать ошибки. Весьма эффективно опе¬
ративное редактирование текстов, так как программист может немед¬
ленно ознакомиться с результатами корректировки. Значительно упро¬
щается и редактирование файлов, что экономит время при подготовке
тестовых данных.
Особенно серьезно следует отнестись к отладке в режиме диалога.
Программисты, получив возможность быстро корректировать програм¬
мы, часто теряют «бдительность». Очень важно тщательно проанализи¬
ровать результаты тестирования с тем, чтобы обнаружить как можно
большее число ошибок. Нельзя забывать, что программа может рабо¬
тать неверно, даже если не происходит ее аварийное завершение.
В некоторых системах задержки при выполнении операций копиро¬
вания или других функций могут составлять до 15—30 мин. За это вре¬
мя целесообразно просмотреть материалы, подготовленные для крити¬
ческого анализа, или привести в порядок документацию.'
Если система может автоматически генерировать схемы структуры
файлов и иерархические схемы модулей, это значительно упрощает ве-
168

деиие документации. До установки АРМ должны быть созданы стан¬
дарты, регламентирующие их использование программистами. Обычно
нет необходимости выделять каждому программисту отдельное автома¬
тизированное рабочее место, так как ему придется заниматься и про¬
ектированием, и изучением результатов тестирования, и другими дела¬
ми. Поэтому если принять предлагаемую схему организации труда про¬
граммистов, то одного АРМ достаточно для шести программистов.
Большинство программистов получают истинное удовольствие, работая
в диалоговом режиме, что, по-видимому, немаловажно.
Глава 9
Тестирование
9.1.	Введение
По трудоемкости тестирование можно сравнить с проектированием
ИС, но поскольку это последний этап разработки, его планированию
нередко уделяют меньше внимания, чем предшествующим стадиям. Та¬
кой подход представляется неверным, и многим проектным группам при¬
ходилось убеждаться в этом
на собственном опыте. Свое¬
временное планирование и под¬
готовка могут облегчить про¬
ведение испытаний и повысить
их эффективность. В настоя¬
щей главе рассматриваются
процедура тестирования ИС и
предварительные операции, ко¬
торые должны выполняться на
более ранних этапах разработ¬
ки системы.
Основная цель тестирова¬
ния — проверить, выполняет
ли разработанная система воз¬
ложенные на нее функции и
высока ли ее надежность. На
рис. 9.1 показаны основные
стадии тестирования ИС и их
связь с предшествующими эта¬
пами разработки. Тестирова¬
ние программ детально обсуж¬
далось в гл. 8 и здесь не рас¬
сматривается.
Испытания должны проде¬
монстрировать, что система со¬
ответствует своему назначению,
удобна в эксплуатации и правильно взаимодействует с другими автома¬
тизированными системами. Для проверки процедур обслуживания си¬
стемы необходимо привлекать к ее тестированию представителей под¬
разделений эксплуатации. Кроме того, следует проверить процедуры
обеспечения защиты и восстановления данных, а также все процессы
циклического и периодического взаимодействия между программами.
Таким образом, план испытаний — неотъемлемая часть проекта ИС, и
он должен разрабатываться на этапе проектирования системы.
Рис. 9.1. Стадии тестирования системы
169

При разработке программы испытаний следует применять методы,
основанные на принципах структурного проектирования ИС, а исход¬
ным материалом должна служить документация, полученная в процес¬
се декомпозиции, а также логического и технического проектирования
системы. В результате определяются виды и способы проверок, которые
необходимо провести в ходе испытаний. Совместно с пользователями
подготавливаются требуемые тестовые данные, причем их объемы и со¬
став могут уточняться с помощью специальных процедур.
На стадии анализа должны быть разработаны и согласованы с поль¬
зователями способы проверки «внешних» функций системы1. Так, мо¬
жет быть установлено, что во время испытаний система будет работать
параллельно с другой автоматизированной системой или что пользова¬
тели подготовят специальные тестовые данные. Основное отличие между
испытаниями системы и проверкой внешних функций состоит в том, что
в последнем случае пользователи рассматривают объект испытаний в
качестве «черного ящика» и интересуются только входными и выходны¬
ми данными. В ходе испытаний необходимо рассмотреть и взаимодейст¬
вующие с системой неавтоматизированные процедуры. Программа,
график проведения приемо-сдаточных испытаний и состав комиссии
утверждаются руководством подразделен ийгпользо'вателей. Детальная
проработка плана испытаний возлагается на аналитиков.
9.2.	Подготовка тестовых данных
В гл. 8 было показано, что заранее подготовленные тестовые данные
позволяют одновременно упростить испытание программ и обеспечить
эффективность выполняемых при этом проверок. Такого же результата
можно добиться и при испытаниях системы, если поручить подготовку
тестовых данных пользователям. Решив работать с единым комплектом
тестовых данных, вы затратите больше времени на определение его
состава, но зато будете освобождены от подготовки данных. Подобные
комплекты могут быть сформированы для каждой стадии испытаний,
причем всякий раз объем тестовых данных должен определяться соста¬
вом проверяемых функций (рис. 9.2).
По завершении анализа пользователям удобно рассматривать систе¬
му как «черный ящик», для которого определены входы (входные дан¬
ные), хранимые файлы, выходы (выходные данные) и в самых общих
чертах логика их обработки. С точки зрения тестирования системы для
пользователей интерес представляют только входные и выходные дан¬
ные и относительно постоянная информация (файлы). Проектировщик
же должен заглянуть внутрь «черного ящика»: он исследует программы
и временные файлы, детали процессов обработки данных, вопросы
обеспечения защиты и восстановления данных и интерфейсы с другими
автоматизированными системами и должен подготовить все необходи¬
мые тестовые данные, если они не были предоставлены пользователями.
После этого программисты проверяют каждую программу в отдельно¬
сти, обращая внимание на ее работу в нормальных условиях и при воз¬
никновении ошибок, а также на интерфейсы с вызываемыми модулями.
Излагаемый подход не только позволяет упростить подготовку те¬
стовых данных. Он дает еще одну возможность выявить и устранить
разногласия между пользователями, аналитиками, проектировщиками
и программистами, а пользователям, кроме того, предоставляет право
1 Такие проверки составляют основное содержание приемо-сдаточных испытаний
системы. — Примеч. пер.
170

ПОЛЬЗОВАТЕЛЬ ПРОЕКТИРОВЩИК СИСТЕМЫ ПРОГРАММИСТ
s (5	s I (5	s
* « 5 5 s ,S	*
OftS5/esO®
LQ п. 1— in n а_ со Lfl О
2(-й}О01-С^
uji4ss;ij3ui<
0SOOCS>*0«
ш
S .
* 2
О и -
-‘Шо£
Л У ш ”
4S So
otox
X О £ з
oqca
о 5
ш <
Ь ct
171
Рис. 9.2. Различные представления о системе и возрастание объемов тестовых данных

участвовать в разработке системы, начиная с самых ранних ее стадий.
При других подходах пользователи, участвовавшие в постановке зада¬
чи, практически отстраняются от проектирования и к началу испытаний
успевают «забыть» о системе. А ведь привлечение пользователей к про¬
ектным работам, например подготовке тестовых данных, весьма важно,
так как они на собственном опыте могут убедиться в том, насколько
сложна и трудоемка разработка автоматизированных систем.
Поскольку каждая стадия тестирования затрагивает самостоятель¬
ные аспекты разработки ИС, объекты испытаний будут различными.
Поэтому при планировании для каждого вида испытаний нужно подго¬
товить специальные бланки, в которых должны быть четко сформули¬
рованы цели испытаний и виды выполняемых проверок, и уже с по¬
мощью таких бланков проконтролировать достаточность тестовых
данных.
Если же из-за нехватки времени или необходимости проводить испы¬
тания новой системы параллельно с эксплуатацией старых систем поль¬
зователи не в состоянии подготовить полный комплект тестовых данных,
следует, применяя вышеизложенную процедуру, сформировать отдель¬
ные комплекты тестовых данных, но поручить эту работу самим разра¬
ботчикам. В таких случаях для тестирования системы и проверки ее
внешних функций будут применяться различные данные.
9.3.	Разделение тестовых данных
В большинстве систем в определенные моменты времени, например
в конце каждой недели, месяца или года, выполняется специальная об¬
работка данных. Для ее проверки требуются многократные испытания.
В очень большой или сложной системе может оказаться целесооб¬
разно выделить основные- логические компоненты и провести их раз¬
дельные испытания. Так, обслуживание клиентов, обработка заказов,
извещений и счетов могут проверяться автономно. При выполнении раз¬
дельного тестирования компонентов на завершающем этапе испытанию
должны подвергнуться все внутренние и внешние интерфейсы системы.
9.4.	Процедура тестирования
На рис. 9.3 перечислены задачи, решаемые при подготовке и прове¬
дении испытаний ИС, а на рис. 9.4 приведен сетевой график выполне¬
ния работ. Из сетевого графика видно, что все работы по пп. 1 —12 мо¬
гут быть выполнены до написания программ.
Если в процессе подготовки или проведения испытаний обнаружится,
что в систему необходимо внести некоторые изменения, последние долж¬
ны быть согласованы с пользователями. Однако «симптомы» возникно¬
вения подобных проблем должны выявляться на более ранних стадиях
разработки.
На сетевом графике указана и документация, разрабатываемая в
процессе планирования и проведения испытаний. Объемы ее весьма
значительны, поэтому при подготовке к испытаниям целесообразно про¬
думать организацию специальной «библиотеки» со справочной служ¬
бой: впоследствии каждый раздел документации нужно будет подверг¬
нуть тщательному анализу.
Ниже мы рассмотрим каждую из перечисленных на рис. 9.3 задач,
указав ответственных за ее решение должностных лиц и виды создава¬
емой на данной стадии документации.
172

Общее планирование испытаний. Главная цель при решении этой за¬
дачи— установить, какие конкретно работы будут проводиться в ходе
испытаний, и составить их календарный план. План разрабатывается
службой эксплуатации совместно с пользователями и, возможно, с ад¬
министратором базы данных, а затем утверждается руководителем про¬
екта. На этой стадии важно определить степень участия подразделений-
пользователей в испытаниях системы и наметить состав выполняемых
ими работ.
Общий план испытаний должен включать следующие разделы:
1. Описание стратегии тестирования системы.
2. Сетевой график выполнения основных работ.
1. Общее планирование испытаний
2. Детальное планирование испытаний
3. Планирование проверки внешних функций
4. Планирование проверки интерфейсов с другими системами
5. Планирование проверки работоспособности системы
6. Систематизация проверок
7. Формирование плана выполнения контрольных примеров
8. Подготовка тестовых данных
9. Использование тестовых данных
10. Прогнозирование результатов проверок
11. Разработка заданий на выполнение контрольных примеров
12. Составление календарного плана испытаний
13. Выполнение контрольных примеров
14. Анализ результатов испытаний
15. Анализ объемно-временных характеристик системы
16. Анализ ошибок, обнаруженных в ходе испытаний
17. Ведение библиотеки испытаний системы
18. Утверждение результатов и завершение испытаний
Рис. 9.3. Задачи, решаемые при подготовке и проведении испытаний системы
3. Календарный график выполнения основных работ с указанием
необходимых ресурсов.
4. Краткое описание каждой работы.
Подготовленный план должен быть тщательно рассмотрен всеми
участвовавшими в его составлении. Важно, чтобы этот итоговый доку¬
мент получил всеобщее одобрение. Одновременно желательно утвердить
процедуры проверки выявляемых ошибок, подведения итогов рабочих
совещаний и обучения сотрудников, привлекаемых к испытаниям. При
необходимости следует изучить вопросы, связанные с преобразованием
файлов и созданием специальных программных средств, которые мо¬
гут понадобиться при подготовке тестовых данных.
Детальное планирование испытаний. По завершении проектирования
системы общий план испытаний может быть уточнен и скорректирован.
Ответственность за это, как и прежде, возлагается на руководителя про¬
екта. Уточненный план обсуждается и согласуется со всеми, кто участ¬
вовал в его составлении.
Наряду с вопросами подготовки тестовых данных теперь следует
рассмотреть специальные программные средства тестирования систем,
которые позволят упростить проведение испытаний. Такие программы
или модули, как генераторы данных, утилиты сопоставления и печати
файлов и средства регистрации объемно-временных характеристик си¬
стемы, могут быть закуплены или разработаны членами проектной
группы.
17.3

174
Рис. 9.4. Сетевой график подготовки и проведения испытаний системы. Нумерация работ соответствует рис. 9.3.

При создании вспомогательных средств тестирования собственными
силами необходимо тщательно проработать их функции и структуру на
этапе проектирования системы. Например, целесообразно, чтобы любая
программа такого рода, обращающаяся к некоторому главному файлу
системы, использовала обобщенную подпрограмму ввода-вывода для
данного файла. В ряде случаев это значительно сокращает общие тру¬
дозатраты на программную реализацию системы.
Специально разработанные средства по сравнению с приобретаемы¬
ми на рынке, как правило, проще в эксплуатации и предоставляют вы¬
ходные данные в более удобных форматах. Однако на разработку и те¬
стирование таких программ потребуется определенное время. Поэтому,
если за приемлемую сумму можно приобрести готовые средства, позво¬
ляющие в принципе решить поставленную задачу, не следует пренебре¬
гать этой возможностью.
На вспомогательные средства тестирования составляются точно та¬
кие же спецификации, что и на прикладные программы. Если создавае¬
мые средства могут быть использованы и в других разработках, нужно
своевременно уведомить остальные проектные группы об их реализации.
Разработка вспомогательных средств ведется в соответствии с метода¬
ми структурного программирования.
Планирование проверки внешних функций системы. Прежде всего
необходимо выявить те внешние условия, реакция на которые отражает
функционирование системы с точки зрения пользователей и должна
проверяться при проведении испытаний. Эта задача решается аналити¬
ками при участии пользователей. Контрольные бланки заполняются сле¬
дующим образом. Для каждого типа входных данных просматривается
их «путь» в системе и записываются все условия (допустимые и недопу¬
стимые), реакция на которые подлежит проверке. Затем аналогичная
процедура выполняется и для каждой выходной формы, получаемой в
системе. Поскольку при этом заполняется большое число бланков, вре¬
мя от времени их следует объединять в «подшивку» и подвергать ана¬
лизу.
Планирование проверки интерфейсов с другими системами. Этот вид
планирования выполняется членами проектной группы по завершении
проектирования системы. Составляется список условий, которые могут
иметь место при взаимодействии разрабатываемой и существующих ав¬
томатизированных систем. Заполняются контрольные бланки, и в них
вносятся сведения по каждому интерфейсному файлу, главному файлу
или файлу базы данных. Заполненные бланки анализируются состав¬
лявшими их сотрудниками.
Планирование проверки работоспособности системы. Проектировщи¬
ки должны записать все условия «внутренней» обработки данцых, про¬
веряемые в ходе испытаний системы.
В процессе декомпозиции системы были разработаны бланки описа¬
ния процессов, отражающие «прохождение» каждой группы данных по
системе. На основе этих бланков позднее формировались профили тран¬
закций и выполнялось логическое проектирование системы. На стадии
технического проектирования процессы объединялись в программы и
составлялись спецификации последних. Теперь же с помощью блан¬
ков описания процессов можно записать условия, подлежащие проверке
при испытаниях работоспособности системы.
Пример записи проверяемых условий на бланке описания процесса
приведен на рис. 9.5.
При детальном проектировании, кроме того, были дополнительно
введены бланки описания процессов, реализующих специальные функ-
175

Процесс Р11 —Заказ на бронирование места в
в данном районе
отеле, расположенном
0.1
г>
^ с
3 а
X с
Проверяемые условия
и ожидаемые результаты
Номер
испыта¬
ния
Конт¬
рольный
пример
Файл/Запись
1
Неверно задан район
— выборка не должна произво¬
диться
7
4
D01 —1/1
IN20B—2/10
9
Район задан верно, но класс отеля
назван неправильно
— выборка не должна произво¬
диться
7
4
То же
3
Область и класс отеля заданы верно
— должна производиться выбор¬
ка
7
4
»
4
Для данного отеля вызван процесс
Р01
— будет сделан запрос об общем
числе номеров данного типа в
отеле
7
5
»
5
Для данного отеля вызван процесс
Р02
— будет сделан запрос о резуль¬
татах выделения номера
7
1
»
б
В первом выбранном отеле есть сво¬
бодные номера
— при бронировании будет выда¬
но подтверждение
7
1
То же
IN20B—3/10
7
В первом выбранном отеле свобод¬
ных номеров нет
— бронирование не выполняется,
перейти к следующему отелю
7
1
То же
8
В третьем выбранном отеле есть сво¬
бодные номера
при бронировании будет выда¬
но подтверждение
7
4
D01 —1/15
IN20B—2/12
9
В последнем из отелей, расположен¬
ных на территории данного района,
есть свободные номера
— при бронировании будет выда¬
но подтверждение
7
4
D01 —1/20
IN20B—2/13
IN20B—3/13
10
Ни в одном из отелей на территории
данного района свободных номеров
нет
— заказ на бронирование откло¬
няется
7
11
D01 —1/23—28
IN20B—2/14
Рис. 9.5 Контрольный бланк испытаний процесса
ции: инициализацию и завершение обработки, защиту данных, обработ¬
ку сбоев оборудования и т. д. Для каждого из них тоже нужно соста¬
вить список контрольных проверок.
Как и ранее, из-за больших объемов подготавливаемой документа¬
ции целесообразно создавать «подшивки», чтобы ускорить процесс ее
анализа.
Систематизация проверок. Основная цель этой операции — система¬
тизировать различные виды проверок, необходимость проведения кото¬
рых была определена на предыдущих стадиях, и сформировать конт-
176

рольные примеры. При каждой проверке может выполняться несколько
логических условий, относящихся к некоторой подсистеме или группе
программ. Систематизация нужна для того, чтобы испытания проводи¬
лись в обстановке, максимально приближенной к реальной.
При планировании испытаний системы следует придерживаться при¬
мерно того же подхода, что и при ее проектировании: разбить систему
на логические компоненты, которые затем реализуются в виде файлов
и программ. Во время испытаний контрольные примеры объединяются в
задания, выполняемые на ЭВМ. При формировании таких заданий нуж¬
но стремиться к упрощению процедуры их запуска и выполнения.
.М* 11 / 11
Цель проверки
Файл
Последова¬
тельность
выполнения
Срок
выполнения
1
Подготовка файла районов
I N07—1
06.11.81
2
Подготовка файла отелей
IN 01 — I
IN 02—1
После п. 1
07.11.81
3
Подготовка файла номеров в отеле
IN 03— I
После п. 2
08.11.81
4
Подготовка файла бронируемых
I D03
После п. 3
09.11.81
номеров
11
Подготовка отчета о наличии мест
в отелях
D04—5
D07—I
После
п. 10
05.12.81
Рис. 9.6. Фрагмент плана проведения испытаний системы
Краткое описание проверяемых условий заносится в специальные
бланки контрольных примеров, снабжаемые для облегчения работы пе¬
рекрестными ссылками. При критическом анализе описаний контроль¬
ных примеров необходимо установить, будет ли в действительности про¬
верено каждое условие.
Формирование плана выполнения контрольных примеров. На этой
стадии запланированные ранее проверки систематизируются и форми¬
руется план выполнения контрольных примеров, предусматривающий
проверки и внешних функций, и интерфейсов, и работоспособности си¬
стемы. Такой план должен отражать оценки затрат памяти и машинно¬
го времени, а также трудоемкости данных.
Фрагмент плана выполнения контрольных примеров для гипотети¬
ческой системы туристической фирмы приведен на рис. 9.6. В каждом
конкретном случае здесь указываются цели проверки, используемые
файлы, последовательность выполнения в зависимости от других конт¬
рольных примеров и срок выполнения. При подготовке контрольных
примеров обращаются к диаграммам, входящим в состав технического
проекта системы. Для всех временных интервалов, отмеченных такто¬
выми линиями, составляются полные комплексы контрольных примеров.
При этом учитываются подготовка, обслуживание и печать файлов те¬
стовых данных.
При формировании плана выполнения контрольных примеров следу¬
ет учитывать взаимосвязи между отдельными примерами. Подготавли¬
вается специальный документ (гл. 18), отражающий необходимые для
проведения испытаний ресурсы: время, в том числе машинное, кадры,
число терминалов. Этот документ должен быть согласован с группой
подготовки тестовых данных и службой эксплуатации ИС.

Подготовка тестовых данных. После составления плана выполнения
контрольных примеров можно приступить к подготовке тестовых дан¬
ных. Целесообразно привлечь к этой работе пользователей, которые не¬
посредственно должны сформировать входные формы документов. Для
того чтобы максимально сократить время подготовки тестовых данных,
желательно принять следующие меры:
• воспользоваться генератором тестовых данных;
• подготовить тестовые данные силами проектной группы;
• привлечь пользователей к подготовке тестовых данных;
• взять данные, подготовленные какой-то другой автоматизирован¬
ной системой;
• выделить тестовые данные из имеющихся машинных файлов;
• выделить тестовые данные из внемашинных документов.
Как правило, приходится рассматривать отдельно каждый из имею¬
щихся файлов, в результате чего удается выделить минимальный объ¬
ем тестовых данных, которые позволят выполнить необходимые провер¬
ки. Часто с помощью только машинных файлов оказывается невозмож¬
ным подготовить все тестовые данные, и поэтому приходится прибегать
к указанным выше способам их получения.
Иногда имеет смысл разработать специальные формы документов
либо однократно выполняемые программы выборки и переформатирова¬
ния тестовых данных. Такие работы должны быть предусмотрены в
плане подготовки и проведения испытаний системы.
Наилучший вариант — предоставить подготовку данных непосредст¬
венно пользователям с помощью форм входных документов. Однако
этот способ не всегда применим, поскольку обычно главные файлы
должны быть созданы прежде, чем система может быть запущена.
После того как для каждого контрольного примера составлена об¬
щая схема тестовых данных, следует проанализировать ее с целью
исключения дублирования. В отдельных случаях, правда, избыточность
в тестовых данных допускается сознательно.
Использование тестовых данных. Здесь потребуется перфорация или
ввод данных с терминала, загрузка в файлы и проверка загруженных
файлов. Один из членов проектной группы должен отвечать за коорди¬
нацию и проведение этих работ.
Прогнозирование результатов проверок. После подготовки тестовых
данных для каждого проверяемого условия могут быть сформулированы
ожидаемые результаты. Это довольно трудоемкая задача, но она позво¬
ляет ускорить анализ результатов тестирования. Общие результаты той
или иной проверки следует отразить в документации, указав также ста¬
рые и новые значения соответствующих элементов данных. Может по¬
требоваться, кроме того, получить образцы отчетов, для которых долж¬
ны быть подсчитаны контрольные итоги и отмечены сообщения, выда¬
ваемые на консоль оператора.
Разработка заданий на выполнение контрольных примеров. Во вре¬
мя программирования могут быть подготовлены задания для выполне¬
ния контрольных примеров. Их следует согласовать со службой эксплу¬
атации, поскольку тексты заданий должны соответствовать предъявля¬
емым на ВЦ требованиям. Для разработки процедур на языке управле¬
ния заданиями целесообразно применять те же структурные методы;
что и при программировании. Процедуры должны быть составлены так,
чтобы их было можно легко понять и осуществить восстановление и
рестарт заданий.
Составление календарного плана испытаний. Прежде всего прово¬
дится оценка трудоемкости выполнения каждого теста и выявляется
178

взаимосвязь между контрольными примерами. Затем совместно со
службой эксплуатации составляется график испытаний, в котором учи¬
тываются ресурсы, необходимые для выполнения контрольных приме¬
ров, такие, как магнитные ленты или диски, программные средства
сбора операционных характеристик системы, канцелярские принадлеж¬
ности и т. д. График должен быть согласован со всеми подразделения¬
ми, распоряжающимися нужными ресурсами, и с пользователями, если
они будут участвовать в проверке результатов.
Выполнение контрольных примеров. Это первая задача, имеющая
непосредственное отношение к тестированию системы. Все предыдущие
задачи могут решаться на этапах проектирования или программирова¬
ния. Контрольные примеры должны выполняться в соответствии с ка¬
лендарным планом. Целесообразно поручить проведение этой операции
службе эксплуатации, что обеспечит корректность используемых экс¬
плуатационных процедур.
При тестировании диалоговых систем запись диалога ведется вруч¬
ную. Оператор должен зафиксировать результаты диалога и предста¬
вить их разработчикам на проверку. Для копирования содержания эк¬
ранов нужны специальные программные средства, которые производят
печать экранов в автономном режиме, одновременно снабжая распечат¬
ку идентификаторами контрольного примера и транзакции. При отсут¬
ствии таких средств следует фотографировать экраны.
Диалоговые системы сначала необходимо полностью испытать в ре¬
жиме пакетной обработки. Это упрощает проверку мелких деталей про¬
грамм с терминала, а также изменение транзакций, содержащих
ошйбки.
Анализ результатов испытаний. Сопоставляются фактические и ожи¬
даемые результаты выполнения контрольных примеров. Если обнару¬
живается расхождение и выясняется, что-оно является следствием сбоя
системы, а не ошибки при формулировании ожидаемого результата, за¬
полняется ведомость дефектов. В ведомости дефектов описывается сама
ошибка и обстоятельства, при которых она была найдена, даются де¬
тальные описания контрольного примера и тестовых данных, а также
необходимые ссылки на файлы и выходные отчеты. Если ошибку сразу
же удается локализовать, в систему вносится соответствующее измене¬
ние. Однако при неясной картине сбоя исправления откладываются до
тех пор, пока не будут точно установлены его причины.
Анализ объемно-временных характеристик системы. На функциони¬
рование большинства систем при проектировании накладываются опре¬
деленные ограничения. Они могут затрагивать, например, время выпол¬
нения задания и загрузку центрального процессора для системы пакет¬
ной обработки или время ответа для диалоговой. При наличии каких-
либо ограничений должны быть проведены испытания, подтверждаю¬
щие, что система ограничениям удовлетворяет. Проще всего провести
такие испытания с помощью средств регистрации объемно-временных
характеристик системы. Результаты сопоставляются с проектными зада¬
ниями. Часто при этом возникает необходимость увеличения объема те¬
стовых данных для моделирования реальной ситуации. Процедура вы¬
полнения анализа объемно-временных характеристик описана в гл. 16.
Анализ ошибок, обнаруженных в ходе испытаний. После каждого
сеанса выполнения контрольных примеров должны быть определены
источники всех найденных ошибок. Ошибка может возникнуть в резуль¬
тате машинного сбоя, нечеткой работы эксплуатационного персонала и
неточностей в операторах языка управления заданиями или в тестовых
данных. Могут иметь место логические ошибки в системе или програм¬
179

ме. Их исправление представляется наиболее трудоемким и часто свя¬
зано с изменением графика испытаний.
Для упорядочения испытаний различных версий программ все опера¬
ции должны проводиться в определенной последовательности. По мере
исправления ошибок в ведомости дефектов вносятся соответствующие
записи и, когда будут обработаны все дефектные ведомости для конк¬
ретного теста, испытание можно выполнить вновь. Во избежание на¬
прасной траты времени следует придерживаться жесткого порядка ис¬
правления ошибок и повторного запуска контрольных примеров.
Ведение библиотеки испытаний системы. В процессе подготовки и
проведения испытаний системы составляется множество документов.
Как и на всех остальных этапах разработки, здесь очень важно органи¬
зовать централизованное хранение документации, чтобы при необходи¬
мости к ней можно было получить доступ. Если в проектной группе
имеется «библиотекарь», то именно ему и следует поручить эту работу.
Все материалы по результатам тестирования нужно собрать в «под¬
шивки» и установить строгий порядок работы с ними, что обеспечит их
сохранность.
Утверждение результатов и завершение испытаний. После успешно¬
го завершения испытаний должна быть проверена вся полученная при
тестировании документация, в том числе и ведомости дефектов. Окон¬
чание испытаний необходимо формально согласовать с пользователями,
службой эксплуатации и технической группой.
Приемо-сдаточные испытания. При тестировании системы пользова¬
телем или при организации параллельной работы новой и какой-либо
из существующих систем применяют ту же процедуру испытаний, ис¬
пользуя для фиксации ошибок ведомость дефектов. До начала внедре¬
ния системы необходимо утвердить акт о завершении ее испытаний.
Если в программу испытаний включалось выполнение контрольных при¬
меров на данных, подготовленных пользователями, специальные при¬
емо-сдаточные испытания можно не проводить. В этом случае пользо¬
ватели должны отвечать за прогнозирование и согласование всех ре¬
зультатов испытаний.
9.5. Хранение тестовых данных систем
Часто после внедрения системы возникает необходимость в ее раз¬
витии. Этот процесс можно ускорить, если тестовые данные системы
всегда доступны. Как правило, некоторые изменения системы требуют
дополнения, удаления или уточнения тестовых данных, что обычно сде¬
лать проще, чем подготовить новый комплект тестовых данных и заново
дать прогноз результатов. Поэтому соответствующая документация
должна тщательно храниться. Выходные данные на машинных носите¬
лях следует хранить таким образом, чтобы данные, получаемые на но¬
вых версиях программ, можно было автоматически сравнить со стары¬
ми. В этом случае удастся избежать чрезвычайно трудоемкого сравне¬
ния файлов «вручную».
Тестовые данные системы и всю остальную документацию нужно
хранить в актуализированном состоянии. Общепризнано, что необходи¬
мо поддерживать программы в том виде, в котором они были составле¬
ны первоначально. То же относится и к тестовым данным. Как и при
программировании, нужно проверять корректность предлагаемых изме¬
нений и внимательно просматривать документы, прежде чем подшивать
их в папки.
180

9.6. Заключение
Мы рассмотрели основные задачи по подготовке и проведению испы¬
таний системы, а также показали, как нужна здесь документация, соз¬
данная на этапах анализа и проектирования системы. Но даже при на¬
личии документации на этой стадии предстоит выполнить большой объ¬
ем работ. Подготовка спецификаций данных и прогнозирование резуль¬
татов всегда занимают много времени, но они необходимы. Преимуще¬
ство предлагаемой процедуры состоит в том, что она позволяет целена¬
правленно выявить условия, подлежащие проверке, и подготовить кон¬
трольные примеры. Справочная система на базе таблиц перекрестных
ссылок гарантирует, что ни один из разделов документации не будет
упущен, и упрощает проверку результатов тестирования. Если тестовые
данные подготавливались на этапе проектирования системы, их можно
применять при программировании. Это значительно ускоряет тестирова¬
ние программ и обеспечивает требуемую «глубину» испытаний, посколь¬
ку при выполнении контрольных примеров удается использовать боль¬
шие объемы тестовых данных. Раннее планирование и хорошая доку¬
ментация, созданная на этапе проектирования, способствуют уменьше¬
нию нагрузок в наиболее напряженный момент разработки — при про¬
ведении испытаний системы.
Глава 10
Послесловие к методам разработки ИС
10.1.	Введение
В настоящей главе обобщаются вопросы применения описанных выше
методов при различных подходах к реализации ИС, а также рассматри¬
ваются перспективы развития этих методов, в частности автоматизация
выполнения проектных работ.
. 10.2. Обзор методов поэтапной разработки ИС
Напомним вкратце сформулированные в предыдущих главах основ¬
ные положения по применению методов проектирования на отдельных
этапах жизненного цикла ИС.
Формирование стратегии разработки. Успех разработки ИС в значи¬
тельной степени зависит от того, насколько тщательно проработана
стратегия ее реализации. Это означает, что должны осуществляться
долгосрочное планирование информационных потребностей организа¬
ции и заблаговременный выбор принципиальных технических решений,
обеспечивающих их удовлетворение. При планировании следует свое¬
временно решить вопрос о выделении на разработку требуемых ресур¬
сов и в случае необходимости скорректировать планы.
Очередность проектирования и ввода в эксплуатацию ИС должна
соответствовать относительным приоритетам отдельных направлений
основной деятельности организации: прежде всего желательно созда¬
вать те системы, от внедрения которых ожидается наибольшая прибыль,
но отсюда вовсе не следует, что вообще не нужно начинать разработку
ИС, если эффект от ее внедрения не поддается точной количественной
оценке. Имея четкие стратегические установки, разработку любой ИС
можно привязать к текущим планам организации.
181

Анализ реализуемости проекта. По каждому направлению проект¬
ных работ в области создания ИС должно быть проведено исследова¬
ние реализуемости, в результате которого уточняется, какими возмож¬
ностями будет располагать новая система и на каких технических и
программных средствах ей предстоит функционировать. В условиях не¬
прерывного совершенствования информационной технологии значение
этапов формирования стратегии и исследования реализуемости разра¬
ботки существенно возрастает, поскольку сопоставление различных тех¬
нических решений и выбор оптимальных вариантов с точки зрения удов¬
летворения требований пользователей и затрат на реализацию необхо¬
димо проводить как можно раньше.
Системный анализ. Это очень важный этап, но, к сожалению, неред¬
ко на него выделяется недостаточно времени. Основная цель системного
анализа — исследовать существующую систему, определить направле¬
ния ее развития и в общих чертах обрисовать новую систему.
Последнюю задачу часто пытаются решить сразу после завершения
исследования действующей системы. При этом опускается наиболее су¬
щественная часть системного анализа — выявление недостатков дейст¬
вующей системы в аспекте пользовательских требований и определение
характеристик создаваемой системы. В результате, скорее всего, удаст¬
ся получить хорошую копию старой системы, но проблемы, с которыми
сталкиваются пользователи, так и не найдут своего решения.
Методы, предлагаемые в настоящей книге, позволяют с успехом ре¬
шать как общие, так и частные задачи системного анализа.
Проектирование системы. На этом этапе требования пользователей
воплощаются в технических и программных решениях. Проектирование
завершается созданием спецификаций программ. Наиболее сложный
участок проектирования недостаточно обеспечен методически. Речь
идет о разработке общей схемы будущей системы, когда нужно опреде¬
лить, каким способом будут реализованы файлы и программы и их вза¬
имодействие. Излагаемый здесь метод позволяет упорядочить процедуру
разработки ИС и отказаться от проектирования «по наитию». Метод
обеспечивает более точное соответствие технических решений характеру
прикладных функций, которые должны выполняться проектируемой си¬
стемой. Усложнение проектных решений допускается только при нали¬
чии существенных ограничений на доступные ресурсы ЭВМ. В конечном
счете упрощается эксплуатация и сопровождение ИС.
Программирование. В процессе программирования разрабатывается
основная документация на систему, которая затем длительное время
хранится в службе сопровождения программных средств. Работу про¬
граммиста в некотором смысле можно уподобить творчеству автора ли¬
тературного произведения. Главные качества хорошей программы в
представлении тех, кто отвечает за сопровождение математического
обеспечения (а они составляют большинство «читательской аудито¬
рии»),— понятность, отсутствие ошибок и гибкость.
Программы, обладающие такими качествами, создаются с помощью
методов структурного проектирования, кодирования и тестирования.
Эти методы предусматривают неоднократные проверки результатов, по¬
лучаемых в ходе разработки. Как показывает опыт, рассматриваемые в
книге методы обеспечивают быструю разработку свободных от ошибок
и простых в сопровождении программ.
Тестирование. Проблемы, связанные с испытанием разработанных
программ, часто пытаются решать на последних стадиях проекта. Недо¬
статочная координация планов подготовки и проведения испытаний за¬
трудняет создание и контроль тестовых данных.
182

Описанный в книге метод позволяет при меньших трудозатратах на
тестирование организовать и провести комплексные испытания ИС.
Планирование испытаний и подготовка тестовых данных должны начи¬
наться уже на этапе системного анализа и продолжаться на последую¬
щих стадиях проекта.
Этап тестирования системы иногда оказывается наиболее сложным
во всей разработке. Здесь могут проявиться все неточности и упущения,
на которые до поры до времени «закрывали глаза» при проектировании
системы. Это еще раз подчеркивает необходимость последовательного
контроля результатов, получаемых в ходе разработки ИС.
10.3.	Внедрение методов
Бессмысленно приступать к внедрению методов разработки ИС, ос¬
новываясь только на материалах, изложенных в настоящей книге.
В любом учреждении потребуется некоторым образом видоизменить
эти методы в соответствии либо с характером ее основной деятельно¬
сти, либо с принятой технологией обработки данных. Поэтому внедре¬
нию методов должна всегда предшествовать стадия планирования, на
которой анализируются достоинства и недостатки применяемых мето¬
дов, выявляется необходимость перехода к новым методам и определя¬
ются требования к ним с точки зрения организации работ. В результате
разрабатываются процедуры выполнения проектных заданий и норма¬
тивно-техническая документация, устанавливается порядок ее согласо¬
вания с руководством службы обработки данных и подразделений-поль-
зователей ИС.
Разработанные процедуры утверждаются в качестве стандартных и
используются при внедрении конкретных проектных методик. В усло¬
виях перехода на новые методы необходимо учитывать специфику орга¬
низации— в этом залог их успешного внедрения.
Прежде чем приступить к практическому применению новых мето¬
дов в соответствии с планом разработки ИС, следует провести курс
обучения персонала и ознакомить с ними членов проектной группы.
10.4.	Организация работ по новым методам
Гибкость. Совершенно не обязательно, чтобы сразу же по утверж¬
дении стандартов все разработки переводились на новую схему. В неко¬
торых (небольших) проектах для ускорения выполнения работ имеет
смысл объединить этапы системного анализа и проектирования. Воз¬
можно, при этом придется обойти какую-либо из «контрольных точек»,
предусмотренных новой схемой. Важно своевременно согласовать это
решение с пользователями.
Другой пример: при создании некоторой несложной системы, пред¬
назначенной для подготовки отчетов по уже существующим файлам,
детальное исследование реализуемости оказывается излишним, посколь¬
ку затраты на разработку могут быть определены весьма просто. В та¬
ком случае пользователь может утвердить смету затрат без предвари¬
тельной детальной оценки ожидаемого эффекта.
В рассматриваемом примере, таким образом, исследование реализу¬
емости сводится к элементарной операции. Кроме того, располагая
соответствующими языками программирования высокого уровня, разра¬
ботчик может принять обоснованное решение об объединении стадии
анализа программирования и проведения приемо-сдаточных испытаний
данной ИС.
183

Не менее важна гибкость в применении методов проектирования и
при сопровождении ИС. В одной ситуации может потребоваться изме¬
нить положение некоторой литеры в заголовке какого-либо отчета, в
другой — разработать совершенно новую подсистему. Очевидно, что во
второй ситуации нужно выполнить все стадии проектирования, тогда
как в первой достаточно внести минимальные изменения в имеющийся
файл параметров отчета.
В любом случае, действуя в рамках регламентирующих разработку
стандартов, руководитель проекта должен обладать некоторой «сте¬
пенью свободы». Однако принимать решения, связанные с отступлением
от стандартов, во избежание необоснованного нарушения последних
необходимо до начала проектирования конкретной системы. В особен¬
ности это относится к работам, выполняемым при сопровождении си¬
стемы, когда речь идет о модификации какого-то компонента ИС.
Корректировка методик. Применяемые методы разработки должны
претерпевать изменения в соответствии с эволюцией технологии и си¬
стем обработки данных. Если стандарты, затрагивающие какой-либо
аспект разработки, оказываются неэффективными, их следует пере¬
смотреть и после утверждения пользоваться впредь только этими по¬
следними документами.
Не рекомендуется руководствоваться устаревшими стандартами, так
как тогда нужно помнить обо всех принятых изменениях. Именно по
этой причине в ряде организаций стандарты морально устаревают и их
перестают применять.
Система контроля. В управлении разработкой ИС большое значение
имеет обеспечение контроля. Результаты завершения отдельных этапов
проектирования ИС рассматриваются и утверждаются руководством.
Не менее важны единые процедуры анализа и утверждения конкретных
проектных решений, которые позволяют своевременно оценивать ресур¬
сы, выделяемые для проведения разработки.
Все эти мероприятия должны упрощать организацию работ в усло¬
виях применения новых методов и в конечном счете обеспечивать мак¬
симальный эффект от их внедрения. Если разрабатываемая в ходе про¬
екта документация неточно отражает полученные результаты и поэтому
их не удается вовремя проконтролировать, вся проделанная работа мо¬
жет быть сведена на нет.
Документация, регламентирующая разработку. Можно выделить два
вида документации: текущие документы, используемые и изменяемые
разработчиками в ходе проектирования, и комплект конструкторских и
эксплуатационных документов на систему, поддерживаемых в процессе
ее эксплуатации. Все разрабатываемые материалы относятся к одной
из этих категорий. Если какие-то документы часто изменяются, нужно
организовать «подшивку» и снабдить ее указателем изменений. Напри¬
мер, для администратора данных создается словарь-справочник дан¬
ных. В то же время редко изменяемые документы не менее важны в
ходе проектирования системы, и к ним предъявляются такие же жест¬
кие требования, как и к остальной документации.
10.5.	Применение методов при различных подходах к реализации ИС
Существует множество подходов к реализации ИС, и их число про¬
должает возрастать! С основными из них вы сможете кратко ознако¬
миться в настоящем разделе. Здесь же отмечаются особенности приме¬
нения описанных выше методов разработки ИС.
[84

Персональные вычисления. Под персональными вычислениями сле¬
дует понимать самостоятельную работу пользователя по составлению
программ за терминалом, в качестве которого могут рассматриваться
как обычные экранные пульты в системе разделения времени, так и
мощные микропроцессоры, подключенные к центральной ЭВМ. Если
речь идет о разработке редко применяемых «личных» программ, то
нужны лишь самые элементарные стандарты, причем они могут быть
«индивидуальными». Если же в работах по созданию коллективно ис¬
пользуемой системы участвуют несколько человек, целесообразно при¬
держиваться упрощенной схемы разработки, начинающейся с исследова¬
ния реализуемости и завершающейся тестированием ИС. Наилучшим
считается вариант, когда стандарты утверждены и действуют в рамках
всей организации. В этих условиях разработчики смогут разобраться
не только в своих системах, но и в созданных другими членами проект¬
ной группы.
Полная унификация методов разработки становится совершенно не¬
обходимой, если персональные компьютеры подключены к общей базе
данных или системе разделения времени. Для обеспечения эффектив¬
ного использования коллективных информационных ресурсов потребу¬
ется провести унификацию имен объектов данных, способов доступа,
типов и содержания сообщений и т. д.
Применение ППП. Пакеты прикладных программ, применение кото¬
рых может существенно повлиять на организацию разработки ИС в це¬
лом, должны рассматриваться на самом общем уровне стратегического
планирования системы. ППП, затрагивающие отдельные прикладные
области, например расчет заработной платы, следует изучать на этапе
анализа реализуемости ИС. И в том и в другом случае необходим тща¬
тельный системный анализ, показывающий, насколько ППП соответст¬
вуют требованиям пользователей системы. -При этом основное внимание
нужно уделить функциям, которые можно реализовать с помощью кон¬
кретного ППП. При разработке технического проекта иногда выясняет¬
ся, что для ряда операций нужно написать программы, расширяющие
возможности данного ППП. Таким образом, слегка изменив рассмот¬
ренную выше схему проведения системного анализа, можно с успехом
решать задачи-отдельных групп пользователей средствами ПГ1П. После
этого проектирование и программирование выполняются для новой
функциональной области традиционным способом. На этапе тестирова¬
ния должны проверяться все функции системы, включая реализуемые
ППП.
Применение генераторов программ. Генераторы программ в ряде
случаев вытесняют традиционные языки программирования, например
Кобол. Языки, подобные RPG3, располагают мощными процедурными
конструкциями, позволяющими быстро создавать сложные программы,
причем объем исходного текста оказывается небольшим. Некоторые
генераторы программ работают с «языком бланков» и поэтому являют¬
ся непроцедурными.
Однако и те и другие в сравнении с традиционным программирова¬
нием позволяют повысить производительность труда разработчика в не¬
сколько раз.
Воздействие средств такого рода на методы разработки систем за¬
ключается в следующем. Для процедурных языков, подобных RPG3,
как и для Кобола, может быть разработан набор правил реализации ло¬
гических конструкций программы, так что методы программирования,
по существу, остаются прежними. При использовании непроцедурных

языков основную работу, обычно выполняемую на стадии программиро¬
вания, «делает» генератор программ. Программисту остается лишь про¬
вести испытания полученной программы. Тем не менее ранние стадии
проектирования по-прежнему сохраняются: нужно определить, какие
потребуются программы и какие функции должна выполнять каждая
из них.
Создание прототипов. Сущность этого подхода состоит в том, чтобы
быстро разработать прототип новой системы, который предъявляется
пользователям, опробуется ими, всесторонне оценивается и модифици¬
руется по замечаниям. Процесс повторяется до тех пор, пока все недо¬
статки не будут устранены. После этого составляется документация на
систему. Для разработки прототипа широко применяются генераторы
программ, языки высокого уровня, библиотеки стандартных модулей,
генераторы описаний данных и баз данных. Иными словами, с целью
ускорения цикла разработки максимально автоматизируется этап про¬
граммирования.
Для того чтобы этот подход себя оправдал, необходимо выполнять
ранние этапы проектирования, особенно системный анализ. Если первая
версия системы предъявляется на малых объемах данных и скорость
обработки данных и организации эксплуатации не играют существен¬
ной роли, этап детального проектирования можно опустить. Но после
того как будет установлено, что система в принципе удовлетворяет
функциональным требованиям, придется вернуться к этапу проектиро¬
вания и найти технически эффективные решения, а также обеспечить
простоту сопровождения системы. Поэтому большинство из рассматри¬
вавшихся в гл. 6 работ все же предстоит выполнить.
Существует мнение, что необходимость в системном анализе при та¬
ком подходе отпадает, поскольку можно сразу изготовить прототип си¬
стемы, а затем довести его до окончательной версии/ Однако эту точку
зрения вряд ли можно признать обоснованной. Как показано в книге,
важнейший этап разработки ИС — системный анализ — нужен и в том
случае, когда последующие этапы проектирования опускаются. В то же
время, если уже имеется база данных и требуется создать относительно
простую систему, например генерации отчетов, то метод проб и ошибок
может оказаться достаточно конструктивным.
Применение микроЭВМ. При разработке систем управления техно¬
логическими процессами, в которых применяются простейшие микропро¬
цессоры, как правило, не приходится иметь дело с обработкой сложных
структур данных. Поэтому, хотя общие принципы проектирования ин¬
формационных систем остаются неизменными, в детальных методах
исследования реализуемости, системного анализа и проектирования,
описанных в настоящей книге, практически нет необходимости. При
программировании таких систем используются особые методы, посколь¬
ку программы должны вначале разрабатываться на инструментальной
вычислительной системе, а затем вводиться в специальные постоянные
устройства микроЭВМ. В этих условиях чрезвычайно важное значение
придается тестированию программ.
С другой стороны, современные микрокомпьютеры, предназначенные
для коммерческой обработки данных, оснащаются развитым программ¬
ным обеспечением, в том числе трансляторами с Кобола, средствами
машинной графики и системами управления базами данных. При разра¬
ботке ИС, базирующихся на этих микрокомпьютерах, должны приме¬
няться фактически все методы — от исследования реализуемости до
тестирования систем.
186

10.6. Автоматизация разработки ИС
Общие проблемы. Развитие систем автоматизации учрежденческой
деятельности должно затронуть и нужды подразделений обработки дан¬
ных, наиболее подготовленных к таким работам. При создании ИС ее
разработчикам приходится иметь дело с описаниями множества объек¬
тов, например файлов или процессов. В типичной ИС насчитывается не¬
сколько тысяч таких объектов.
Между объектами должны поддерживаться сложные динамические
связи. Так, в действующей системе существуют связи между операци¬
ями, хранилищами и потоками данных. После проведения системного
анализа определяются новые объекты и связи между ними. На стадии
проектирования первоначальная структура объектов постоянно уточня¬
ется и модифицируется. На этапе программирования также необходимо
получать доступ к самым разнообразным описаниям.
Только в конце разработки после завершения испытаний системы
взаимосвязи объектов ИС приобретают относительно «статичный» ха¬
рактер. Таким образом, информация, используемая при создании ИС
сама по себе имеет сложную структуру и постоянно изменяется. Поэто¬
му автоматизация процессов разработки ИС представляет собой не¬
простую задачу. Возможные направления автоматизации кратко рас¬
сматриваются ниже.
Основные требования. Имеются два вида средств автоматизации раз¬
работки. Одни из них автоматизируют некоторую рутинную функцию и
могут применяться на соответствующей стадии непосредственно разра¬
ботчиком. Другие позволяют решить определенную задачу практически
без участия человека, как это имеет место при использовании генерато¬
ров программ, управляемых входных, хранимых и выходных данных
или непроцедурных языков высшего уровня.
Рассмотрим основные элементы систем машинной поддержки разра¬
ботки ИС.
Обработка бланков. Одно из основных требований к системе автома¬
тизации разработки ИС состоит в обеспечении хранения и воспроизве¬
дения всех бланков для подготовки документации на различных этапах
проектирования системы. Выполнение этого требования позволит хра¬
нить актуализированные копии бланков и при необходимости работать
с ними в оперативном режиме.
Описание входных и выходных данных. Средства описания входных
и выходных данных желательно иметь для документирования форматов
экранов и выходных отчетов. К таким средствам могут предъявляться
специфические требования, например по определению полей фиксиро¬
ванного формата для работы с экранами и по использованию перемен¬
ных форматов в отчетах, выдаваемых на АЦПУ. Некоторые неудобства
могут быть связаны с применением экранов малого формата для про¬
смотра больших документов.
Словари-справочники данных. Словарь-справочник данных — третье
обязательное средство в системах автоматизации разработки ИС. С по¬
мощью этого средства запоминается и предоставляется информация об
элементах ИС и их взаимосвязях. Его основное назначение — хранение
описаний элементов данных. На рис. 10.1 представлена упрощенная
структура данных, позволяющая документировать результаты деталь¬
ного анализа системы. Поддержка даже такой простой структуры сред¬
ствами современных систем словарей-справочников данных представ¬
ляет определенные трудности, особенно в отношении унификации имен
элементов разрабатываемой системы. На практике при разработке ИС
187

приходится иметь дело с гораздо более сложными структурами описа¬
ний, например, нужно поддерживать связи между файлами, операцион¬
ными диаграммами, модулями и т. д. Системы словарей-справочников
данных пока еще не обеспечивают хранения всего многообразия описа¬
ний элементов ИС.
Редактирование текстов описаний процессов. На этапе подготовки
спецификаций системы логика ее программных компонентов описывает¬
ся с помощью структурного псевдокода или каким-либо другим спосо¬
бом. Для этого целесообразно применять экранный текстовый редак¬
тор, позволяющий включать, исключать, заменять и переставлять слова,
строки и более крупные фрагменты текста.
Рис. 10.1. Упрощенная структура данных для документирования результатов деталь¬
ного анализа системы
Средства моделирования. По ходу разработки приходится время от
времени проверять, соответствует ли конкретное проектное решение за¬
данным объемно-временным характеристикам. Это связано с моделиро¬
ванием реальной системы и, как показано в гл. 16, часто сопряжено с
громоздкими вычислениями. Поэтому весьма полезно располагать сред¬
ствами машинного моделирования, которые позволяют оценивать раз¬
личные проектные решения, варьируя входными параметрами.
Автоматизация логического проектирования структур данных. Ана¬
лиз данных часто затруднительно проводить из-за наличия большого
числа элементов данных. В частности, весьма трудоемким оказывается
проектирование логической структуры данных. Для решения этой за¬
дачи целесообразно применять средства машинной поддержки. Как
показано в гл. 13, полностью автоматизировать реляционные методы
анализа данных невозможно, поскольку для выполнения некоторых ша¬
гов процедуры нормализации отношений необходимо понимать семан¬
188

тику данных. Но с другой стороны, анализ ключевых элементов и по¬
строение таблицы связей, на основе которых строится логическая струк¬
тура данных, имеет смысл выполнять с помощью ЭВМ.
Составление схем. Многие из рассматриваемых в настоящей книге
методов предполагают широкое использование графических схем (см.
рис. 10.1). Такое изображение в общем случае менее информа¬
тивно, чем операционные диаграммы. В связи с этим желательно, чтобы
графические средства, как и в традиционных системах автоматизации
проектирования (САПР), позволяли быстро генерировать и компоно
вать схемы, соответствующие различным уровням детализации пред¬
ставлений об ИС. Современная технология еще не обеспечивает непо¬
средственного получения изображений, подобных приведенному на
рис. 10.1. Тем не менее уже сегодня вместо того, чтобы составлять схе¬
мы вручную, целесообразно применять относительно несовершенные
средства машинной графики.
Средства разработки программ. Наиболее развитым направлением
автоматизации программирования сегодня считается применение
средств оперативного составления и отладки программ. В сочетании с
использованием генераторов программ и языков программирования
высшего уровня, позволяющими почти полностью исключить этап про¬
граммирования, они должны составить ядро системы автоматизации
разработки ИС.
Автоматизация на различных стадиях проектирования ИС. Описан¬
ные выше сервисные средства весьма полезны при разработке деталь¬
ного проекта новой системы. Дополнительно может быть организована
формальная проверка непротиворечивости проектных спецификаций по
следующей схеме.
Системный анализ. Прежде всего для всех операций, хранилищ и
потоков данных устанавливается, что всякому элементу выходных дан¬
ных соответствует источник во входных данных, хранилищах данных
или в процессах обработки данных. С этой целью выполняется специ¬
альное именование элементов данных в операциях. Далее проверяется,
каждый ли элемент данных, принадлежащий некоторому хранилищу
данных, используется хотя бы в одной операции. При разработке де¬
тального проекта новой системы целесообразно также применять сред¬
ства автоматизированного анализа данных. Автоматизированная про¬
цедура проверки непротиворечивости спецификаций может выполняться
с помощью табличных форм представления профилей доступа и связей
между типами данных и хранилищами данных.
Описанные выше методы автоматизированного контроля могут обес¬
печить непротиворечивость проектных решений, но практически не
позволяют проверить, насколько точно последние отражают требования
пользователей будущей системы. Для решения второй задачи по-преж¬
нему необходимо тщательно разрабатывать описания операций, причем
процедура решения не поддается формализации. Определение точной
логической схемы системы, способной удовлетворить требованиям поль¬
зователей, и разумных границ автоматизации остается за высококвали¬
фицированными специалистами проектной группы.
Проектирование системы. Для заполнения бланков описания процес¬
сов целесообразно использовать экранные редакторы текстов. При де¬
композиции процессов часто описание их логики дублируется на более
детальных уровнях. На последующих стадиях проектирования процес¬
сы группируются для обеспечения высоких эксплуатационных характе¬
ристик системы. Здесь редакторы текстов также будут полезны разра¬
ботчикам.
189

При оценке объемно-временных характеристик создаваемой системы
и сопоставлении их с целевыми установками потребуются средства ма¬
шинного моделирования.
В процессе проектирования баз данных с помощью редактора тек¬
стов можно с успехом выполнить все необходимые действия в отноше¬
нии логических спецификаций профилей доступа в табличной форме,
подготовленных на этапе системного анализа. Спецификации профилей
доступа содержат исходные данные для средств моделирования, упоми¬
навшихся выше. И наконец, редактор текстов может применяться при
компоновке спецификаций программ из бланков описания процессов.
Программирование. В последнее время наметилась тенденция к ис¬
пользованию генераторов программ вместо традиционного программи¬
рования. Если приходится прибегать к традиционным способам состав¬
ления программ, производительность труда разработчиков можно зна¬
чительно увеличить применением ряда стандартных средств. При нали¬
чии библиотек исходных текстов, из которых стандартные модули и спе¬
цификации форматов экранов включаются в тело программы, скорость
написания последних возрастает. С помощью средств отображения «эк¬
ран— рабочая память», автоматически преобразующих зависящие от
аппаратуры входные и выходные форматы в стандартные образы рабо¬
чих областей, программист может абстрагироваться от конкретного типа
внешнего устройства, с которым должна работать его программа. Нако¬
нец, если имеются соответствующие программные средства, удается
генерировать схемы базы данных на основе описаний, введенных в сло¬
варь-справочник данных на этапе проектирования системы.
Тестирование. В какой-то степени трудозатраты на испытание систем
можно снизить путем применения генераторов тестовых данных. Однако
часто целесообразнее сразу планировать проведение испытаний таким
образом, чтобы данные для них готовились самой системой. Полезны
также вспомогательные средства тестирования, в особенности средства
пакетной имитации работы диалоговых программ. При анализе резуль¬
татов испытаний желательно располагать средствами сравнения данных,
а также средствами подготовки тестовых данных с использованием
обычных форматов ввода.
Одна из наиболее сложных проблем, возникающих при тестировании
системы, связана с отслеживанием различных версий ее компонентов,
например программных модулей или завершенных и прошедших комп¬
лексные испытания подсистем. Для этих целей необходимы гибкие
средства поддержки библиотек с возможностью ведения указателей и
разграничения доступа.
Управление проектом. Как показано в гл. 18, управление проектом
может быть обеспечено машинной поддержкой путем хранения стан¬
дартных данных, отражающих календарный план разработки, последу¬
ющей их сортировки и выдачи разнообразных отчетов.
10.7.	Перспективы развития методов разработки ИС
Уже сегодня доступно большинство из перечисленных выше средств
автоматизации. Принципиальную проблему составляют сами процессы
проектирования ИС, в частности структур данных и программ. В перс¬
пективе решение подобных задач может быть упрощено благодаря та¬
ким достижениям информационной технологии, как реляционные базы
данных, механизмы хранения файлов в виртуальной памяти с элемента¬
ми самоорганизации и запоминающие устройства, обеспечивающие па¬
190

раллельный доступ к данным. Полагают даже, что через какое-то время
внедрение подобных средств при существенном снижении стоимости тех¬
нического обеспечения избавит проектировщика ИС от необходимости
заботиться об улучшении операционных характеристик системы. Но и
при этих условиях логический аспект проектирования ИС не потеряет
своего значения и решение соответствующих задач будет по-прежнему
требовать от разработчика значительных усилий.
В настоящее же время наиболее актуальной представляется проб¬
лема интеграции существующих средств автоматизации, упоминавшихся
выше, и создания для разработчика ИС универсального инструмента,
который мог бы применяться на разнотипных ЭВМ.
Хотя уже сегодня имеются вычислительные установки с програм¬
мными средствами автоматизации проектирования, последние расходуют
значительные машинные ресурсы и требуют от пользователя знания
множества разнородных командных языков. Несогласованными оказа¬
лись и форматы представления генерируемых этими средствами данных.
Интеграция средств автоматизации разработки ИС позволит создать
значительно более удобные для пользователя автоматизированные ра¬
бочие места (АРМ). Появятся устройства отображения информации с
экранами большого размера, на которых могут быть практически без
ограничений представлены любые документы, а также развитые сред¬
ства машинной графики, позволяющие вычерчивать самые различные
схемы и диаграммы. В перспективе станет возможной автоматическая
генерация логических схем программ. Одновременно будет снижаться
стоимость обработки данных и хранения файлов на мощных микро¬
компьютерах, соединенных с большими ЭВМ, где может выполняться
компиляция программ или храниться документация на действую¬
щие ИС.
В результате интеграции разрозненных систем получат более широ¬
кое распространение распределенные базы данных, а также средства
удаленной и сетевой обработки данных. Этому будет способствовать и
объединение развивающихся систем автоматизации учрежденческой
деятельности с традиционными системами обработки данных. При ре¬
шении отдельных информационных задач в условиях интегрированной
ИС значительно возрастет роль начальных этапов проектирования —
формирования стратегии разработки, принятия принципиальных техни¬
ческих решений и анализа реализуемости проекта. Возрастание роли на¬
чальных этапов проектирования в свою очередь обусловит необходимость
комплексной автоматизации процессов разработки систем и постепен¬
ный переход от создания отдельных ИС к применению гибких ППП об¬
щего назначения.
10.8.	Заключение
Ознакомившись с представленными в книге структурными методами
разработки ИС, читатель может подумать теперь и об их применении.
Даже если предпочтение будет отдано каким-то другим методикам про¬
ектирования, содержание вопросов, стоящих перед разработчиком, оста¬
нется неизменным, хотя поиск решений может осуществляться в не¬
сколько иной последовательности. Одни операции могут быть сокраще¬
ны или опущены, другие же, наоборот, расширены. Но в любом случае
необходимо тщательно выполнять начальные этапы проекта и подробно
документировать получаемые результаты, иначе усложнится взаимо¬
действие между участниками разработки. Таким образом, настоящая
191

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

Часть 3.
Процедуры
Глава 11
Операционные диаграммы
11.1.	Введение
Хорошо известно, что схематическое изображение нередко оказыва¬
ется наиболее емкой формой представления информации. В настоящей
главе рассматривается применение так называемых операционных диа¬
грамм для создания документов, регламентирующих разработку ИС на
ранних этапах. На последующих этапах проекта более удобными оказы¬
ваются вербальные формы описаний.
Операционные диаграммы широко используются при формировании
стратегии разработки ИС, исследовании реализуемости проекта и си¬
стемном анализе. На этапах проектирования и программирования на
смену им приходят другие способы документирования проектных ре¬
шений.
Некоторые разработчики полагают, что методы графического доку¬
ментирования разработки системы должны обеспечивать прямую де¬
композицию проектных решений от постановки задачи до реализации
программных кодов. На наш взгляд, при реальных масштабах ИС
такая цель практически недостижима. Основные трудности возникают
на стыке этапов анализа и проектирования, а затем при переходе от
логического проекта к программированию, когда логические функции
системы должны быть реализованы конкретными программами. Чаще
всего отдельная программа не является результатом прямой декомпо¬
зиции некоторой логической функции. Так, конкретная программа мо¬
жет выполнять определенный вид обработки данных для нескольких
функций в системе.
Основное требование, предъявляемое к графическим методам доку¬
ментирования,— простота:	схемы,	детализирующие	любой уровень
представления системы, должны быть понятны всем, а не только тем,
кто хорошо разбирается в вопросах обработки данных на ЭВМ. Необ¬
ходимо обеспечить возможность структурной декомпозиции специфика¬
ций системы с максимальной степенью детализации и согласованность
описаний на смежных уровнях представления. Излагаемый в настоящей
главе метод отражает прежде всего логическую схему системы (т. е. он
позволяет показать, что, а не как, делает система), но в отдельных слу¬
чаях, особенно при документировании действующих систем, затрагивает
и связи между реально существующими компонентами ИС. Любую ин¬
формационную систему можно рассматривать как сеть взаимодейству¬
ющих процессов, хранилищ и потоков данных. Поэтому применяемый
для документирования разработки ИС графический метод должен га¬
рантировать представление сведений о таких компонентах системы.
7 Зак. 1783
193

11.2. Прочие методы
Для сопоставления здесь приводится краткая характеристика неко¬
торых наиболее распространенных методов документирования ИС.
Вербальное описание. Рассмотрим следующее описание: «Система
CGT предназначена для обслуживания клиентов оптового рынка. Поку¬
патели после переговоров с торговыми агентами принимают решение о
приобретении партий сельскохозяйственной продукции. Торговый агент
оформляет квитанции, которые сводятся в специальную таблицу. С по¬
мощью этих же квитанций регистрируется прием поступающих на ры¬
нок партий товаров, доставляемых транспортным агентством. Грузчики
получают необходимые инструкции и отгружают продукцию на склад.
Каждое утро управляющий конторой рынка запрашивает сведения о
ходе продаж. Поскольку сделки на рынке совершаются на комиссион¬
ных началах, следует вести строгий учет цен и количества отпускаемой
продукции...».
Приведенный пример демонстрирует недостатки вербального описа¬
ния ИС. Для того чтобы разобраться в назначении и функциях рассмат¬
риваемой системы, нужно прочесть описание полностью и неоднократно
сопоставить приведенные в тексте детали и описания данных. Наилуч¬
шая форма вербального описания — хорошо структуризованная специ¬
фикация. Документ такого рода воспринимается намного легче, но и с
его помощью обеспечить непротиворечивость отдельных фрагментов
описания достаточно сложно. Следовательно, общее представление о
системе значительно проще составить по графической схеме.
Метод HIPO. В соответствии с этим методом, разработанным фир¬
мой IBM, система изображается в виде иерархической схемы функций.
Каждый блок общей схемы затем детализируется более подробной диа¬
граммой, на которой изображаются входные данные, процессы их обра¬
ботки и выходные данные [4].
В целом метод HIPO позволяет получить общее представление о си¬
стеме. Его основной недостаток заключается в том, что поскольку де¬
тальная схема обработки данных дается на всех уровнях представле¬
ния ИС, трудно обеспечить точное определение данных и проконтроли¬
ровать согласованность информационных потоков.
Метод SADT. Процессам обработки данных на схеме соответствуют
прямоугольные блоки, которые соединяются стрелками, изображающи¬
ми информационные потоки. Каждый такой блок может быть затем де¬
тализирован. Данные определяются в соответствии с аналогичной
иерархической схемой [5].
Главный недостаток метода — сложность сопоставления описаний
данных и процессов при проверке непротиворечивости общей схемы си¬
стемы. Однако процедуры декомпозиции процессов и проверки согласо¬
ванности информационных потоков, предлагаемые этой методикой,
весьма удачны.
Методы Константайна. В работе [3] изложены графические методы,
основанные на идеях овал-диаграмм, описанных JI. А. Константайном
[2]. Им подобны и методы, рассматриваемые в настоящей книге. Отли¬
чительная черта этих методов — непосредственное представление взаи¬
модействия между хранимыми данными и процессами их обработки,
что позволяет устранить основной недостаток, присущий методу SADT.
Обобщенные схемы системы (Американский национальный стан¬
дарт). Этот метод основан на использовании стандартного набора гра¬
фических символов, связываемых в линейные последовательности с
возможностью ветвления. В свое время метод широко пропагандировал¬
194

ся Н. Чапином [1]. Основная проблема, возникающая при документи¬
ровании ИС по данному методу, — получение компактной и в то же
время детальной схемы системы, без которой специалистам различной
квалификации трудно быстро получить представление о системе на со¬
ответствующем уровне детализации.
Традиционные стандарты документирования. На рис. 11.1 приведен
фрагмент схемы ИС, составленной в соответствии с обычными стандар-
Рис. 11.1. Фрагмент схемы ИС, разработанной в соответствии с традиционными стан¬
дартами документирования
тами документирования. Процесс обработки данных разделяется на ряд
«потоков работ» в зависимости от того, на каких конкретно сотрудни¬
ков или на какие подразделения возложены те или иные функции. Дви¬
жение данных между «потоками работ» изображается на схемах пунк¬
тирными линиями. Основной недостаток схем такого рода — излишняя
детализация, что особенно нежелательно на стадии системного анализа.
Целесообразно рассматривать функции автоматизированной систе¬
7*
195

мы отдельно от детальной схемы внемашинных операций по обработке
данных, которые, хотя и имеют очень большое значение, но должны
выполняться только после определения границ автоматизации и машин¬
ной обработки информации.
11.3.	Структурный графический метод:	операционные	диаграммы
В настоящем разделе приводится описание графического метода,
предложенного в системе Modus для составления структурных схем.
Вначале даются некоторые общие правила составления схем и примеры
их использования, которые затем рассматриваются более детально.
Общие правила. Операционная диаграмма отражает главные опера¬
ции, выполняемые в рамках ИС, а также взаимосвязи между операци¬
ями и объектами, находящимися вне системы. В следующих разделах
излагаются назначение и порядок использования основных графических
символов (рис. 11.2). Несмотря на то что набор основных символов
ограничен, он позволяет представить структуру ИС практически с лю¬
бой степенью детализации.
Пример составления операционных диаграмм. На рис. 11.3—11.6
приведены примеры операционных диаграмм для неоднократно упоми¬
навшейся выше системы CGT. На композиционной диаграмме
(рис. 11.3) показана система в целом и ее взаимосвязи со «средой». Си¬
стема взаимодействует с внешними объектами с помощью потоков дан¬
ных. Рис. 11.4 соответствует первому уровню детализации системы. Из
рисунка видно, что основными функциями системы являются получение
партий товара, их продажа, ведение и хранение счетов для расчетов с
клиентами. Торговая документация должна отражать принадлежность
отдельных партий сельскохозяйственной продукции конкретным постав¬
щикам, поскольку рынок является посредническим предприятием, орга¬
низующим торговлю на комиссионной основе.
Для накопления сведений о продукции, которой располагает рынок,
вводится хранилище данных «Партии товара». В хранилище данных
«Торговые квитанции» содержится информация о торговых сделках. Из
такой диаграммы нетрудно уяснить назначение и функции системы и
решить, например, нужно ли включить в нее не упоминавшийся до сих
пор склад.
При дальнейшей детализации проекта ИС для каждого блока со¬
ставляется отдельная диаграмма. На рис. 11.5 и 11.6 показана деком¬
позиция двух операций, представленных на рис. 11.4. Основное правило
составления диаграмм заключается в том, что потоки данных, выходя¬
щие за границы блока, соответствующего конкретной операции, не
должны обрываться. Это означает, что данные не могут «возникать»
или «теряться» на нижних уровнях системы. Так, из рис. 11.5 видно, что
при ведении переговоров о сделках используется информация о нали¬
чии товаров, находящаяся в хранилище данных «Партии товара». Зака¬
зы регистрируются с помощью торговых квитанций, которые также
поступают в соответствующее хранилище данных. При продаже продук¬
ции, кроме того, подготавливаются подтверждения поставщикам и ин¬
струкции по отгрузке товаров. На диаграмме изображено также храни¬
лище данных «Торговые квитанции», из которого черпается информация
для корректировки записей по поставкам, находящимся в хранилище
данных «Партии товара».'
Таким образом удается провести тщательный анализ любого компо¬
нента ИС и уточнить его назначение и связи с другими компонентами.
196

G
ОВАЛ
э
ВНЕШНИЙ ОБЬЕКТ, НАХОДЯЩИЙСЯ ЗА
ГРАНИЦАМИ РАССМАТРИВАЕМОЙ
ПРЕДМЕТНОЙ ОБЛАСТИ. ОТКУДА ПОСТУПАЮТ
ИЛИ КУДА НАПРАВЛЯЮТСЯ ДАННЫЕ ИЛИ
ИНЫЕ МАТЕРИАЛЬНЫЕ ОБЬЕКТЫ.
ПРИ ПОВТОРЕНИИ НА ДИАГРАММЕ ВНЕШНИЙ
ОБЪЕКТ ПОМЕЧАЕТСЯ ВЕРТИКАЛЬНОЙ
ЧЕРТОЙ
СТРЕЛКА
ПОТОК ДАННЫХ ИЛИ ПОТОК МАТЕРИАЛЬНЫХ
ОБЪЕКТОВ
ПРЯМОУГОЛЬНИК
ОПЕРАЦИЯ. КОТОРАЯ ВЫПОЛНЯЕТСЯ В
ОТНОШЕНИИ ДАННЫХ ИЛИ МАТЕРИАЛЬНЫХ
ОБЪЕКТОВ
а
НЕЗАМКНУТЫЙ ОВАЛ
ЛОГИЧЕСКИЙ ФАЙЛ. НАЗЫВАЕМЫЙ ХРАНИЛИЩЕМ
ДАННЫХ. ПРИ ПОВТОРЕНИИ НА ДИАГРАММЕ
ХРАНИЛИЩЕ ДАННЫХ ПОМЕЧАЕТСЯ ВЕРТИКАЛЬНОЙ
ЧЕРТОЙ
УКАЗЫВАЕТ ГРАНИЦУ РАССМАТРИВАЕМОГО
ФРАГМЕНТА ПРЕДМЕТНОЙ ОБЛАСТИ
ГРАНИЦА ОБЛАСТИ
Рис. 11.2. Основные графические символы для составления операционных диаграмм
Рис. 11.3. Композиционная диаграмма
7 В Зак. 1783	>97

ГИПОТЕТИЧЕСКАЯ СИСТЕМА CGT
198
Рис. 11.4. Система CGT

Если вводится какое-либо изменение, оно отражается только в диа¬
грамме данного уровня и не должно распространяться на верхние уров¬
ни. Однако при изменении содержания потока данных, пересекающего
границу операции, необходимо внести соответствующие коррективы в
операционную диаграмму предшествующего уровня. Это позволит обес¬
печить непротиворечивость и согласованность спецификаций.
Конкретные правила. В документации системы Modus приведены
подробные правила и рекомендации по составлению и корректировке
операционных диаграмм. Объем книги не позволяет изложить эти пра¬
вила полностью, поэтому в. настоящем разделе освещаются лишь наибо¬
лее важные из них.
Рис. 11.5. Реализация продукции
Потоки данных и материальные потоки. Потоки данных обознача¬
ются стрелками, указывающими их направления. Содержание потока
поясняется соответствующей надписью. Допускаются двунаправленные
потоки (рис. 11.7).
Возможно ветвление диаграмм. Каждая ветвь может отображать
как весь исходный поток, так и некоторую его часть (рис. 11.8). Суще¬
ствуют три вида потоков: информационные, материальные и управляю¬
щие. Информационные потоки определяются наиболее просто. Как
правило, поток данных соответствует движению документов, отчетов
или некоторой информации, например заказу, выполняемому по теле¬
фону и т. д. Управляющие потоки выявить сложнее, поскольку они пред¬
ставляют внешние управляющие воздействия.
На операционных диаграммах рекомендуется различать потоки пе¬
речисленных выше типов. Для этого в системе Modus предусмотрены
следующие обозначения:
• тонкие непрерывные линии — для потоков данных (во всех рас¬
сматриваемых здесь примерах речь идет именно об этих потоках);
• жирные непрерывные линии — для материальных потоков;
• пунктирные линии — для управляющих потоков.
Рядом с потоками указываются их наименования, причем для пото¬
ков данных они должны отражать не названия передаваемых докумен¬
7В*
199

тов, а содержание последних (вместо названия «Форма № 5», например,
лучше указать: «Сведения о регистрации транспортных средств»).
Обычно желательно указывать названия всех потоков, однако если
это перегружает диаграмму, допускаются исключения из общего прави¬
ла. При разветвлении потока следует приводить наименования каждой
ветви. Если какая-то ветвь потока не названа, предполагается, что она
соответствует исходному потоку. Считается, что содержание входных и
выходных потоков данных некоторого хранилища, если нет специальных
указаний, соответствует его названию.
Рис. 11.6. Учет реализации продукции
Операции. Операции на диаграммах обозначаются прямоугольника¬
ми. Любая операция связана с преобразованием одного или нескольких
входных потоков в один или несколько выходных потоков данных. При
выполнении операции, кроме того, могут использоваться управляющие
данные, которые не подвергаются каким-либо изменениям, а опреде¬
ляют характер обработки основных входных потоков.
Для указания вида операции в прямоугольнике приводится поясни¬
тельная надпись (имя операции), для которой рекомендуется следую¬
щая форма: действие, объект (при составлении композиционных диа¬
грамм от этого правила можно отступить). Действие должно точно от¬
ражать смысл операции, например:
• проверка кредитоспособности клиента;
• сравнение отчетных и плановых показателей роста производства.
Примеры неудачных наименований операций:
• проведение вычислений;
• обработка входных данных.
Дополнительно в прямоугольнике может быть отмечено, где и ка¬
ким образом выполняется операция или кто отвечает за ее реализацию
200

(рис. 11.9). Это позволяет зафиксировать дополнительные сведения о
действующей системе. При документировании эскизного проекта новой
системы такая информация обычно недоступна вплоть до завершения
анализа схемы делопроизводства. Все прямоугольники на операционной
диаграмме нумеруются.
Хранилища данных и материальных объектов. В ряде случаев целе¬
сообразно «сохранять» данные или материальные объекты в течение
некоторого промежутка времени между отдельными операциями. По-
ПОДГОТОВКА
НАКЛАДНАЯ
ПРОВЕРКА
НАКЛАДНЫХ
►
ТОВАРОВ
ОДНОНАПРАВЛЕННЫЙ
поток
ДВУНАПРАВЛЕННЫЙ
поток
ПЛАТЕЖИ
НАЛИЧНЫЕ
ЧЕКИ
Рис. 11.7. Потоки данных	Рис.	11.8.	Ветвление	потока	данных
добные хранилища на диаграммах обозначаются незамкнутыми овала¬
ми (см. рис. 11.2). Внутри такого овала указывается мнемоничное имя
соответствующего объекта, а при необходимости — и его числовой иден¬
тификатор.
Для упрощения диаграммы иногда полезно «дублировать» хранили¬
ща, отмечая каждый незамкнутый овал, соответствующий уже указан¬
ному на диаграмме хранили¬
щу, вертикальной чертой.
Границы системы и внеш¬
ние объекты. Границы иссле¬
дуемой предметной области
указываются на композицион¬
ной диаграмме. Каждый овал
здесь представляет какой-то
внешний объект или группу
объектов (подразделение орга¬
низации, покупателей, постав¬
щиков, банкиров и т. д.), взаи¬
модействие с которыми суще¬
ственно с точки зрения функ¬
ционирования рассматривае¬
мой системы. Указываются также соответствующие их взаимодействию
потоки между внешними объектами и системой.
Нумерация операционных диаграмм. Принят следующий порядок
нумерации:
• Композиционная диаграмма и операционная диаграмма верхнего
уровня не нумеруются.
• Операции на диаграмме верхнего уровня нумеруются цифрами 1,
2 и т. д.
• Каждая операция делится затем на составляющие, для которых
строятся операционные диаграммы следующих уровней. На операцион¬
ной диаграмме нижнего уровня применяется двойная нумерация: пер¬
КЕМ
ВЫПОЛНЯЕТСЯ
КАССИР
ОПИСАНИЕ
ВЫПЛАТА
ОПЕРАЦИИ
ПЕНСИЙ
ГДЕ
СБЕРЕГАТЕЛЬНАЯ
ВЫПОЛНЯЕТСЯ
КАССА
Рис. 11.9. Дополнительные сведения об опе¬
рациях
201

вая цифра соответствует номеру операции диаграммы верхнего уровня,
а вторая — последовательным номерам операций нижнего. Так, на диа¬
грамме второго уровня, раскрывающей первую операцию первого уров¬
ня, нумерация будет иметь вид: 1.1, 1.2, 1.3 и т. д.
• Для упрощения на диаграммах операции всегда нумеруются, на¬
чиная с единицы, а «наследуемый» номер указывается в верхнем левом
углу диаграммы.
• Номера операций указываются в правом нижнем углу соответст¬
вующих прямоугольников.
Нумерация потоков. Для потоков принята сквозная нумерация. При
проверке непротиворечивости полученных спецификаций, которая про¬
водится, начиная с нижних уровней, выявляются одинаковые потоки,
которым на различных уровнях присвоены разные номера. Необходимо
оставить только один номер. Для потоков с ветвлением на нижних уров¬
нях проверяется адекватность содержания их составляющих.
Не рекомендуется использовать иерархическую нумерацию потоков,
так как это может затруднить анализ диаграмм. Для потоков, пересе¬
кающих границы диаграмм, указывается номер исходной диаграммы.
Оглавление. Составляется оглавление полученных диаграмм. Наибо¬
лее простая его форма, удобная для машинописи, — перечень отступа¬
ми, например:
1.1	Выдача кредитной карточки
1.1.1	*	Проверка документа
1.1 .2	Проверка кредитоспособности
1.1.2.1	*	Проверка	рекомендации банка
1.1.2.2	*	Проверка	рекомендации нанимателя
1.1.2.3	*	Проверка	предыдущего адреса
1.1.2.4	*	Проверка	«черного списка»
1.1.3	*	Установление предельного	кредита
1.1.4	*	Открытие нового счета
1.1.5	*	Посылка карточки по почте
1 .2	Проводка дебита в счет
И т.д.
Основные операции помечаются звездочкой.
Более информативны иерархические схемы, с помощью которых ил¬
люстрировался материал гл. 6. Такие схемы часто называют сводками
операций.
Краткая сводка правил составления операционных диаграмм. Итак,
основные правила построения операционных диаграмм можно сформу¬
лировать следующим образом:
• При составлении диаграмм необходимо пользоваться четырьмя
установленными символами: стрелкой (изображающей поток), прямо¬
угольником (изображающим операцию), овалом (изображающим внеш¬
ний объект) и незамкнутым овалом (изображающим хранилище
данных).
• Особое внимание нужно уделять именованию потоков и операций.
• При указании имен следует придерживаться единых правил.
• Не рекомендуется употреблять узкопрофессиональные термины.
• Необходимо по-разному обозначать информационные, «матери¬
альные» и управляющие потоки.
202

11.4. Об использовании операционных диаграмм в настоящей книге
Операционные диаграммы верхнего уровня удобны при определении
общих требований к ИС на этапах формирования стратегии разработки
и исследовании реализуемости проекта. С их помощью достаточно про¬
сто отображается структура и взаимосвязи компонентов будущей си¬
стемы.
На этапе системного анализа операционные диаграммы позволяют
накапливать сведения о действующей системе и дают общее представ¬
ление о создаваемой ИС.
В настоящей книге диаграммы применяются для иллюстрации всего
процесса разработки системы, который сам по себе должен быть опреде¬
лен с системных позиций. Операционные диаграммы дают возможность
отобразить множество составляющих операций, сложные информацион¬
ные потоки и хранилища данных.
Структурный графический метод хорошо зарекомендовал себя при
разработке упоминавшейся выше системы Modus.
Авторы приносят читателю извинения за то, что из-за достаточно
общего характера излагаемого материала некоторые детали операцион¬
ных диаграмм, в частности касающиеся именования потоков данных,
были опущены. Иногда, если это не мешало восприятию, опускались
номера операций на диаграммах верхнего уровня. Номера потоков дан¬
ных не указывались вообще. Основная цель, которую преследовали ав¬
торы,— дать общее представление о методах разработки ИС, а не ис¬
черпывающее описание ее инструментария.
Литература
1. Chapin N. Some Structured analysis techniques. — DATABASE, Winter Issue. 1979.
2. Constantine L. A. et al. Structured Design. — Yourden, 1975.
3. HIPO — A Design Aid and Documentation Technique. — IBM, 1974.
4. DeMarco. Structured Analysis and System Specification. — Yourden, 1978.
5. Ross D. T. Structured Analysis (SA): a language for communicating ideas. —
Software Engineering, vol. SE--3 no. 1, 1977.
Глава 12
Анализ ключевых факторов эффективности
12.1.	Введение
К сожалению, приходится констатировать, что очень часто информа¬
ционные системы не реализуют полностью те функции, для выполнения
которых они создавались. Предоставляемую же такими системами ин¬
формацию легче охарактеризовать ее объемами, чем полезностью для
аппарата управления. Неоправданная сложность ИС может иногда све¬
сти на нет все усилия, затраченные на их разработку. В этой связи
особое значение приобретает точная формулировка и определение от¬
носительных приоритетов целей, выдвигаемых при создании ИС.
В настоящей главе рассматривается метод анализа ключевых фак¬
торов эффективности (КФЭ), который позволяет успешно решить ука¬
занную проблему. Данный метод применяется при стратегическом пла¬
нировании, исследовании реализуемости проекта ИС и системном ана¬
лизе. Он является развитием метода, предложенного в 1979 г. Дж. Рок-
картом для проведения стратегического планирования ИС [1].
203

12.2. Описание метода
В этом разделе приводится общее описание метода анализа КФЭ.
Примеры его применения на соответствующих этапах проекта рассмат¬
риваются ниже. Основные задачи анализа можно сформулировать сле¬
дующим образом:
• установить четкость и ясность целей, поставленных для данной
предметной области или системы;
• проверить возможность достижения целевых установок, на основе
которых разрабатывается ИС;
• обеспечить возможность сопоставления целевых установок и опре¬
деления их относительных приоритетов.
Хотя предлагаемый метод сам по себе и не гарантирует создание
эффективной во всех отношениях системы, он дает руководителям про¬
екта и аналитикам инструмент для решения этой проблемы.
Ключевые факторы эффективности. Ключевые факторы эффективно¬
сти характеризуют основные аспекты деятельности организации или
функционирования системы. Чрезвычайно важно определить количест¬
венную меру эффективности, так как в противном случае невозможно
проверить, достигается ли эффект на самом деле. Например, нецелесо¬
образно в качестве КФЭ для государственного учреждения рассматри¬
вать прибыль, если ценообразование полностью регулируется прави¬
тельством. Точно так же размер задолженностей в системе бухгалтер¬
ского учета торгового предприятия не следует считать ключевым факто¬
ром эффективности, поскольку на него влияет множество внешних по¬
казателей, в частности конкретная экономическая ситуация. Для ана¬
лиза нужны более конкретные факторы эффективности, скажем, сниже¬
ние расходов и скорость выполнения финансовых операций.
Для исследуемого направления деятельности организации прежде
всего рекомендуется перечислить возможные КФЭ. Так, передовая в
технологическом отношении компания может включить в список КФЭ
следующие показатели:
• уровень акций на фондовой бирже;
• «авторитет» в области технологии;
• число клиентов;
• расширение производства и сбыта;
• реалистичные цены на собственную продукцию;
• рентабельность производства.
В системе бухгалтерского учета аналогичный список может содер¬
жать иные факторы:
• точность, своевременность и быстрота выполнения расчетов;
• способы защиты данных;
• уровень снижения затрат;
• удобство эксплуатации.
Анализ КФЭ. При проведении анализа используется специальный
бланк, показанный на рис. 12.1.
По возможности для каждого КФЭ приводится количественная
оценка, поскольку только в этом случае можно правильно сформули¬
ровать цели построения ИС. Очень важно убедиться в том, что эти цели
достижимы в рамках анализируемой системы.
Если такие оценки получить не удается, то, скорее всего, ИС пред¬
назначена лишь для переработки информации, но вполне возможно, что
вне сферы деятельности системы использование этой информации спо¬
собствует решению каких-то насущных проблем. Например, в ИС неко¬
торой торговой фирмы неразумно в качестве количественной меры КФЭ
204

«выполнение плана продаж» принимать рост объема сделок до уровня
50% общего бюджета, поскольку в рамках системы не контролируют*
ся такие весомые с этой точки зрения показатели, как стимулирование
работы продавцов. Перед информационной системой целесообразнее
поставить задачу получения определенных отчетов за определенный пе¬
риод времени. Но в целом для торговой фирмы такой показатель, как
выполнение плана, достаточно точно характеризует эффективность ее
деятельности.
СИСТЕМА
КФЭ
Мера
оценки
Целевые установки при создании ИС
информационные
функциональные
объемно-
временные
Рис. 12.1. Бланк для записи результатов анализа КФЭ
В ряде случаев при проведении анализа КФЭ удается выявить необ¬
ходимость реализации каких-то новых функций в системе, что должно
быть соответствующим образом отражено в бланках анализа.
12.3.	Примеры анализа КФЭ
Производственное предприятие. На рис. 12.2 показан фрагмент
бланка, заполненного при анализе КФЭ некоторого гипотетического
предприятия.
Первый КФЭ — фактор роста производства — в дальнейшей деком¬
позиции не нуждается. Мерой его оценки служит относительный про-
Система: XXX
Целевые установки при создании ИС
КФЭ
. Мера оценки
информацион¬
функциональ¬
объемно¬
ные
ные
временные
4. Рост произ¬
Относительный
Подготовка
_
водства
процент роста
отчетов о ро¬
доходов
сте производ¬
ства
5. Снижение
Процент от¬
Подготовка
—
—
риска
клонения ре¬
отчетов о це¬
альной цены
нах
от прогнозной
5.1. Точность
—
Исследование
—
—
сведений о за¬
затрат и их
тратах
распределения
по статьям
5.2. Быстрота
—
—
Наличие ин¬
Возможность
выполнения
терактивных
принятия ре¬
расчетов
средств моде¬
шения в тече¬
лирования
ние суток
Рис. 12.2. Фрагмент записи результатов анализа КФЭ для производственного пред¬
приятия
205

цент роста доходов за год в сфере сбыта. Рост производства необходим
для сохранения или увеличения объемов продаж. Контроль этого пока¬
зателя требует анализа конъюнктуры рынка. Поскольку информацион¬
ная система не может непосредственно повлиять на рост производства,
ее основной задачей в данном аспекте деятельности предприятия будет
предоставление необходимой информации.
Анализ фактора риска делится на две стадии: проверяется наличие
точных данных о затратах и оценивается возможный риск. Первая ста¬
дия сводится к ретроспективному исследованию затрат и их распреде¬
ления по отдельным статьям. На второй стадии для ускорения оценки
Система: YYY
Целевые установки при создании ИС
кфэ
Мера
оценки
информаци¬
онные
функциональные
объемно¬
временные
3. Своевременная
выдача заработ¬
Время
Анализ
результатов
ной платы
работы
—
—
3.1.	Сбор данных
3.2.	Выполнение
—
—
—
В течение 12 час.
расчетов
3.3. Выдача зара¬
—
—
В течение 2 час.
ботной платы:
наличными
—
—
В течение 8 час.
чеками
Автоматизиро¬
ванная система
перевода денеж¬
ных сумм
Рис. 12.3. Фрагмент записи результатов анализа КФЭ для системы подготовки ведо¬
мостей по заработной плате.
возможного риска целесообразно применять методы моделирования,
позволяющие сопоставить различные варианты производственной поли¬
тики и быстро рассмотреть последствия всех возможных торговых опе¬
раций. Имеет смысл создать систему машинного моделирования, с по¬
мощью которой решение может быть принято в течение суток.
Поставленные цели могут быть достигнуты с помощью информаци¬
онных систем, которые в свою очередь можно оценивать по степени со¬
ответствия этим целям. Для этого, конечно, потребуются более точные
определения, но теперь их уже нетрудно сформулировать с учетом отно¬
сительных приоритетов конкретных целевых установок в рамках всего
предприятия.
Информационная система. На рис. 12.3 приведены некоторые ре¬
зультаты анализа КФЭ для системы бухгалтерского учета. Каждый из
перечисленных на бланке факторов может быть разложен на составля¬
ющие различными способами. Для правильной оценки результатов ана¬
лиза необходимо четко представлять реальные условия, в которых
функционирует система.
Например, в некой организации задачу подготовки ведомости зара¬
ботной платы можно разбить на три подзадачи:
• подготовка ведомости для главной конторы;
• подготовка ведомости для отделений;
• подготовка ведомости для больниц.
206

Если начисление заработной платы в различных подразделениях ор¬
ганизации происходит по-разному, то указанные направления анализа
могут соответствовать первому уровню декомпозиции рассматриваемо¬
го фактора. Так, главная контора может располагать системой автома¬
тизированного учета рабочего времени персонала и выдачи заработной
платы с помощью автомата, установленного в здании конторы. Это
должно повлиять на специфику разрабатываемой ИС. Для нашей же
системы бухгалтерского учета внешние условия одинаковы. Время, не¬
обходимое для подготовки ведомости заработной платы, зависит в ос¬
новном от продолжительности сбора, обработки и распределения
данных.
По каждой из этих подзадач для ИС могут быть сформулированы
самостоятельные целевые установки. Следует скоординировать время,
выделяемое на реализацию отдельных функций, так как при поиске
технических решений специалисты могут столкнуться с определенными
проблемами.
В данном случае было принято на первый взгляд преждевременное
решение об использовании системы автоматического перевода денеж¬
ных вкладов. Однако такое решение соответствует долгосрочным пла¬
нам руководства. Коммерческому директору известно, что это единст¬
венный способ сократить затраты на банковские операции. Поэтому
имеет смысл сформулировать аналогичные целевые установки и для
автоматизируемой и для неавтоматизированной систем, особенно исхо¬
дя из того, что основные процедуры сбора данных не подлежат автома¬
тизации.
12.4.	Анализ КФЭ на различных этапах проектирования
При проведении анализа ключевых факторов эффективности внима¬
ние концентрируется на целевых установках разработки ИС. Предлага¬
емый метод дает возможность четко сформулировать и всесторонне
проанализировать цели. При этом ИС можно рассматривать как сово¬
купность выполняемых ею функций, а ЭВМ и программное обеспече¬
ние— как средства их реализации.
Характер анализа зависит от того, на каком этапе проектирования
ИС он выполняется. При формировании стратегии разработки ИС не¬
обходимо определить функциональные области, для которых должны
создаваться новые системы. На этапе исследования реализуемости ана¬
лиз должен быть ориентирован на конкретную систему, потому что при¬
нятые здесь решения целиком определяют объем и направление всех по¬
следующих работ.
Далее, на этапе системного анализа, следует еще раз пересмотреть
сформулированные ранее цели. К сожалению, довольно часто к изуче¬
нию КФЭ впервые приступают лишь на этом этапе и приходится сразу
же проводить полное исследование факторов эффективности.
Необходимо отметить, что системный анализ предоставляет послед¬
нюю возможность детально изучить и скоординировать целевые уста¬
новки, закладываемые в разработку ИС. Если нереальные цели не бу¬
дут исключены, это может отрицательно сказаться на всех дальнейших
этапах разработки.
Литература
I. Roc kart J. F. Chief executives define their own data needs. — Harward Business
Review, Mar/Apr, 1979.
207

Глава 13
Анализ данных
13.1. Введение
Методы анализа данных создавались примерно в то же время, когда
велась работа по формализации требований к системам баз данных
(Ч. Бахманом и его коллегами из системного комитета КОДАСИЛ).
Результаты исследований, проведенных под эгидой Рабочей группы по
базам данных (РГБД), показали, что необходима вполне определенная
форма описания связей между данными, которая впоследствии могла
бы быть представлена в физической базе данных. Такой формой описа¬
ния связей стали диаграммы Бахмана. Десятью годами позднее были
разработаны теоретические основы реляционной алгебры и методы нор¬
мализации отношений, позволившие проанализировать структуру запи¬
сей данных с помощью математического аппарата теории множеств
Первоначально предполагалось, что эти методы будут прежде всего
применяться при проектировании систем баз данных. Однако математи¬
ческий аппарат, которым должны были овладеть разработчики, оказал¬
ся слишком сложным для рядовых специалистов. В настоящей главе
рассматривается упрощенная методика, основанная на указанных выше
теоретических положениях. Она дает возможность использовать поша¬
говую процедуру проектирования и рассчитана на специалиста средней
квалификации.
Методы анализа данных тесно связаны с общими методами анализа
и проектирования ИС. Сфера применения рассматриваемых методов не
должна ограничиваться системами баз данных: они могут оказаться
полезными при проектировании любых информационных систем вне за
висимости от конкретных способов хранения данных.
Вниманию читателя предлагается несколько частных методик, заим¬
ствованных из системы Modus. Выбор той или иной методики зависит от
того, насколько детальными должны быть определения данных и какое
время выделяется на проведение анализа.
13.2.	Краткий обзор методов анализа данных
В этом разделе дается общее представление о процессе анализа
данных.
Проектирование логической структуры данных. Проектирование ло¬
гической структуры — главный аспект анализа данных. Общее пред¬
ставление об их логической структуре дает схема, подобная приведен¬
ной на рис. 13.1. Прямоугольники на этой схеме соответствуют типам
(множествам экземпляров) логических записей, которые мы из-за пере¬
груженности термина «запись» будем называть типами данных1. Связи
между типами данных отображаются стрелками: тип данных с исходя¬
щей стрелкой называется владельцем, а тип данных с входящей стрел¬
кой — членом связи, причем каждый экземпляр’ данных-владелец мо¬
жет быть связан с любым числом экземпляров данных-членов связи, но
1 Обращаем внимание читателя на то, что здесь и далее термин «тип данных» экви¬
валентен общепринятому термину «тип записей», т. е. совокупности составляющих его
элементов данных. — Примеч. пер.
208

каждый из последних может быть связан не более чем с одним экземп¬
ляром данных-владельцем этой связи.
Согласно рассматриваемому методу представления структуры дан¬
ных все связи должны быть вида «один со многими». Это значит, что
связи вида «многие со многими», которые иногда обнаруживаются в
ходе анализа данных, должны быть представлены связями вида «один
со многими».
Логическая структура данных, приведенная на рис. 13.1, соответству¬
ет схеме организации некоторых курсов, проводимых в ряде пунктов.
Для каждого такого пункта предусмотрен отдельный экземпляр данных
МЕСТО
ПРОВЕДЕНИЯ
КУРС
АУДИ'
г
ГОРИЯ
ПРЕДМЕТ
ОБОЗНАЧЕНИЯ
□ типы
ДАННЫХ
ПРАКТИЧЕСКИЕ
ЛЕКЦИИ
ЗАНЯТИЯ
связи
Рис. 13.1. Логическая схема данных
типа «Место проведения». Любой пункт может располагать нескольки¬
ми аудиториями, и в каждой из них может проводиться несколько кур¬
сов. Экземпляр данных типа «Курс» относится к конкретному курсу,
проводимому в указанное время.
В аудиториях обычно проводятся различные курсы. Сведения об
изучаемых предметах содержатся в экземплярах данных типа «Пред¬
мет». По каждому курсу читаются лекции и проводятся практические
занятия. Всем этим «объектам» в логической структуре соответствуют
свои типы данных.
На начальной стадии анализа можно полагать, что между типами
данных «Предмет» и «Аудитория» имеется связь типа «многие со мно¬
гими», т. е. что в конкретной аудитории читаются лекции по нескольким
предметам, а каждый предмет изучается в нескольких аудиториях.
По описываемому здесь методу представления структуры данных
связи такого рода требуется разложить на две составляющие типа
«один со многими» и ввести дополнительный тип данных — связку. Во
многих случаях этот прием оказывается очень полезным, так как с точ¬
ки зрения моделируемой предметной области новый тип данных приоб¬
ретает самостоятельное значение. В нашем случае подобным образом
удается отразить факт проведения конкретного курса в определенной
аудитории. Введенный при этом дополнительный информационный объ¬
ект представляет интерес как для учреждения, которое организует кур¬
сы, так и для их слушателей.
Следует отметить, что пока мы обсуждаем наиболее простые отноше¬
ния данных. В рассматриваемую структуру можно ввести типы данных
209

о распределении преподавателей по курсам, отражающие возможность
проведения занятий отдельными преподавателями и позволяющие хра¬
нить сведения о размещении и обучении слушателей. Если придется,
кроме того, организовать и бухгалтерский учет, то потребуется вновь
расширить логическую структуру данных.
Мы называем форму представления информационных связей логиче¬
ской схемой данных. Термин «логическая» подчеркивает, что структура
данных отражает только требования предметной области и совершенно
не учитывает особенностей процессов переработки информации.
Процедура анализа данных. Рассмотрим кратко процедуру анализа
данных и покажем, какие методики применяются на его отдельных ста¬
диях (рис. 13.2).
Рис. 13.2. Процедура анализа данных
Прежде всего выявляется совокупность типов данных, подлежащих
анализу. Источник необходимой для этой стадии информации зависит
от условий, в которых проводится анализ. При исследовании действую¬
щей системы чаще всего таким источником служит документация с опи¬
санием реализованных в системе типов записей. При разработке новой
системы рассматриваются определения логических записей или описа¬
ния новых выходных форм. На практике приходится иметь дело со все¬
возможными видами исходной информации. Более подробно исходные
документы для проведения анализа разбираются в следующих главах,
где вопросы анализа данных рассматриваются в контексте соответству¬
ющих этапов проектирования ИС.
Затем разрабатывается логическая схема данных (см. рис. 13.1).
Вместе с описанием множества деталей, характер которых зависит от
210

применяемой вами методики, она включается в документацию по ана¬
лизу данных. Схема, полученная на этой стадии, должна рассматри¬
ваться в качестве эскизной, поскольку еще предстоит убедиться в ее
точности и непротиворечивости. Эскизная схема отражает структуру
относительно постоянной информации.
На следующей стадии формулируются требования к структуре дан¬
ных с точки зрения обработки информации. С этой целью исследуются
и помечаются на схеме логические пути доступа к данным. Определе¬
ние логических путей доступа — существенный аспект анализа данных,
поскольку здесь могут быть обнаружены как упрощения, так и неоправ¬
данная сложность логической схемы.
Далее выполняется сквозная проверка документации по анализу дан¬
ных. Необходимо проследить, чтобы все внесенные изменения были от¬
ражены в описаниях каждого компонента системы, который они затра¬
гивают. Этап анализа завершается разработкой окончательной версии
документации.
Методы анализа. Можно выделить два метода разработки логиче¬
ской схемы данных. Первый из них, называемый анализом логических
связей, позволяет достаточно быстро определить структуру информа¬
ции, не рассматривая подробно элементы данных, составляющих выяв¬
ленные типы данных.
Второй метод предполагает более тонкий анализ, который прово¬
дится в две стадии. Сначала с помощью реляционного анализа1 полу¬
чают точные описания типов данных и входящих в их состав элементов,
а затем формируют логическую схему данных с использованием логиче¬
ского структурирования.
В большинстве случаев оба метода дают схожие результаты, но
из-за различий в точности анализа их полное совпадение практически
невозможно. Разработчики не должны переоценивать быстроту проведе¬
ния анализа логических связей, поскольку впоследствии им все равно
потребуется дать детальные определения элементов данных.
Термин «элемент данных» в настоящей книге соответствует типам
данных, значения которых должны храниться на наиболее детальном
уровне, например «номера счетов клиентов» или «описание продукции».
Перейдем к более подробному обсуждению рассматриваемых ме¬
тодов.
13.3.	Реляционный анализ
Как уже отмечалось, это наиболее тонкий метод анализа данных.
В сочетании с методами логического структурирования он позволяет по¬
лучить детальную логическую схему данных.
Общие положения. Содержание исходных документов может тракто¬
ваться как записи, состоящие из элементов данных. Чаще всего данные
в таких записях относятся к различным объектам, что затрудняет про¬
ведение анализа. Описываемые ниже приемы позволяют привести струк¬
туру записей к более фундаментальной форме.
^Речь идет о так называемой «третьей нормальной форме» (отноше¬
ний). Один или несколько элементов данных образуют ключ исследуе¬
мого типа данных. По значениям ключа идентифицируются экземпляры
объектов, которые представляет этот тип данных.
1 В отечественной литературе часто употребляется термин «нормализация отноше¬
ний». — Примеч. пер.
211

Рассмотрим в качестве примера ключ «номер счета». В простейшем
случае его значения могут быть целыми положительными трехзначными
числами. Каждое из них тогда однозначно соответствует некоторому
счету, поэтому ключ может служить идентификатором для соответству¬
ющего типа данных. Важно, чтобы для всех типов данных были выделе¬
ны такие ключи, так как в противном случае доступ к отдельным эк¬
земплярам данных станет логически невозможным.
Второе свойство типа данных, приведенного к третьей нормальной
форме, заключается в том, что каждый входящий в него элемент данных
зависит от всего ключа. Не допускается наличие элементов данных, за¬
висящих от какой-то части ключа. Кроме того, в тип данных не должны
входить элементы данных, описывающие другие объекты. Таким обра¬
зом, приведение типов данных к третьей нормальной форме позволяет
решить вопрос о том, соответствует ли тип данных проектируемой си¬
стеме и полностью ли описывают элементы какого-то типа данных объ¬
ект, которому он соответствует.
Необходимо особо подчеркнуть два обстоятельства. Во-первых, сле¬
дует проверить достаточность описаний данных с точки зрения функций
будущей системы. Примером могут служить записи о сотрудниках в ка¬
кой-либо кадровой системе. Вполне вероятно, что кто-то из сотрудников
в свободное время выращивает овощи или увлекается решением крос¬
свордов, но поскольку такие сведения не имеют отношения ни к одной
из функций системы, нет необходимости включать соответствующие эле¬
менты данных в структуру записей.
Во-вторых, нужно учитывать возможность доступа к данным по вто¬
ричным ключам. Для каждого типа данных вводится только один (пер¬
вичный) ключ, однако любой элемент данных может рассматриваться
в качестве вторичного ключа. Например, хотя в кадровой системе пер¬
вичным ключом является табельный номер сотрудника, доступ к экземп¬
лярам данных может быть’санкционирован и по коду профессии, что
необходимо отразить в результатах анализа данных.
Процедура анализа. В процедуре выделяется несколько шагов
(рис. 13.3). Здесь анализируется упоминавшееся в гл. 11 хранилище
данных «Партии товара». На практике такому анализу необходимо под¬
вергнуть все выявленные в системе хранилища данных или прочие
источники их описаний. Содержимое хранилища данных видно из переч¬
ня элементов данных, приведенных в левой части рисунка. Ключевые
элементы данных отмечены двумя звездочками. В данном случае это
уникальные номера, которые присваиваются каждой партии при приеме
товара. Две вертикальные черты обозначают повторяющиеся группы
(элементов данных).
Далее удаляются повторяющиеся группы, в результате чего тип дан¬
ных приводится к первой нормальной форме. Каждая из таких групп
выделяется в самостоятельный тип данных, и ей должен быть назначен
уникальный ключ. Кроме того, каждый тип данных следует снабдить
мнемоничным именем.
Для типа данных «Строка накладной» номер партии перестает быть
уникальным ключом. В нашей системе каждому товару в партии1 при¬
сваивается последовательный номер, образующий вместе с номером
партии уникальный ключ соответствующего типа данных.
На следующем шаге проверяется, соответствует ли каждый элемент
данных объекту, идентифицируемому ключом. Рассматривая первую
1 На который заполняется строка накладной. — Примеч. пер.
212

нормальную форму представления объекта «Удержания», можно убе¬
диться, что описание удержания в действительности идентифицируется
его кодом. Единственный элемент данных, который относится непосред¬
ственно к объекту «Удержания», — сумма удержаний. Этот объект сле¬
дует разложить на две составляющих, в каждой из которых элементы
данных полностью зависят от ключа. Типы данных «Партия товара» и
«Строка накладной» уже обладают указанным свойством. Теперь все
данные приведены ко второй нормальной форме.
Остается решить еще одну проблему: некоторые элементы данных
относятся к другим объектам. Иными словами, они ничего не добавля¬
ют к описанию объекта, который идентифицируется ключом соответст¬
вующего типа данных.
В нашем примере тип данных «Партия товара» включает элемент
данных «Имя и адрес фермера», непосредственно связанный с инициа¬
лами фермера. Это означает, что если ввести в тип данных «Партия то¬
вара» элемент данных «Инициалы фермера», то удастся идентифициро¬
вать поставщика указанной партии товара. В то же время элемент
данных «Имя и адрес фермера» не содержит дополнительных сведений
о поставке, а является характеристикой фермера. Элементы данных,
связанные подобным образом, объединяются в новые типы данных. Для
каждого типа данных выделяется ключ и дается мнемоничное имя.
Рассмотренная процедура позволяет получить ряд типов данных,
приведенных к третьей нормальной форме, показанных на рис. 13.3
справа.
При окончательной проверке результатов анализа можно удостове¬
риться в том, что любой элемент данных, принадлежащий некоторому
типу данных, однозначно идентифицируется его ключом. Все элементы
данных, входящие в состав ключей других типов данных, помечаются
звездочкой. Их называют «чужими» ключами.
Основные правила. На основании изложенного можно сформулиро¬
вать следующие правила реляционного анализа данных:
1. Содержание рассматриваемых записей или хранилищ данных
представляется в виде линейных списков элементов данных. Это типы
данных, которым соответствуют ненормализованные отношения.
2. Для всех типов данных определяются первичные ключи.
3. Выделяются повторяющиеся группы, причем для каждой из них
указывается первичный ключ. В результате типы данных приводятся к
первой нормальной форме.
4. Удаляются элементы данных, зависящие от отдельных компонен¬
тов первичного ключа.
5. Эти элементы данных образуют новые типы данных, причем ком¬
поненты ключа, от которых они зависят, становятся первичными ключа¬
ми новых типов данных. В результате все типы данных оказываются
приведенными ко второй нормальной форме.
6. Удаляются элементы данных, связанные с другими элементами
данных, и создаются новые типы данных. Первичными ключами стано¬
вятся те элементы данных, от которых зависели удаленные элементы.
Теперь все типы данных оказываются приведенными к третьей нормаль¬
ной форме.
7. Проверяется, все ли элементы данных каждого типа данных опи¬
сывают лишь полный ключ этого типа данных. Отрицательный резуль¬
тат проверки указывает на ранее допущенную ошибку.
8. Объединяются все элементы данных в различных типах данных,
которые зависят от общего ключа.
9. Каждому типу данных ставится в соответствие мнемоничное имя.
213

НЕНОРМАЛИЗОВАННОЕ ОТНОШЕНИЕ ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА ВТОРАЯ НОРМАЛЬНАЯ ФОРМА ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА
X
X
ZT
|1
< ш
X гг
^ X
< с:
I о
о. С
ш <
^ I-
О <
X d
X
X
ш
ё <
2 О-
CL Ш
О ^
е о.
° g
< £
< ^
d X
е
о
Is
ич. ш
< X
х X
_ ш
2 X
X О
ш *
О о»
X Ш
X ^
О О
С X
3 I LU
< ш _о
^ X X
0 < X
I- о- о
СС X s
<£ L0
CL о У
ш (J X
^ о ^
ОсО
1 и ^
X
о
X
^ >S
<	d
с; о
о-
<	с
X X ш
!§?
о|<
н «=с о
о *
CD О
о CD
^ О
< *
х <
>ч CZ
О *
X О
w	W	_|_	ш	X	Ш
о.	Е:	ш	3-	<	3-	<
Ш	с	2	>ч	cj	X	^
5^sq00qoL
00<0а-ш0<
х^хххт:*^
о
О
ш
о
•х ш
X X
X X
< <
* й
а. О
ш I
d ш <
^ ^ ^
х < :х
CD X О
214
Рис. 13.3. Пример реляционного анализа данных

13.4. Логическое структурирование
Логическое структурирование предполагает более строгий подход к
проведению анализа данных. Рассмотренные выше перечни элементов
данных уже дают определенное представление о логической структуре
данных и обеспечивают ее усовершенствование на детальном уровне.
Метод логического структурирования позволяет сконцентрировать вни¬
мание на связях между типами данных и построить логическую схему
данных.
Поскольку структура данных тесно связана с функциональной схе¬
мой организации, помимо всего прочего, удается еще раз уточнить на¬
правления ее основной деятельности и назначение создаваемой системы.
В системе Modus логическое структурирование данных регламентирова¬
но рядом правил, которые должны последовательно применяться в от¬
ношении типов данных, полученных в результате реляционного анали¬
за. Рассмотрим эти правила на том же примере, что и в предыдущем
разделе.
1.	Любой тип данных представляется прямоугольником, в котором
записывается его имя.
Фермер
** Инициалы фермера
Имя и адрес фермера
ФЕРМЕР
2.	Для каждого ключевого элемента данных, если это еще не сдела¬
но по правилу 1, формируется самостоятельный тип данных:
ПАРТИЯ
ТОВАРА
(ПРАВИЛО 1)
Элемент партии товара
** Номер партии товара
** Номер строки накладной и т. д
СТРОКА
НАКЛАДНОЙ
(ПРАВИЛО 1)
НОМЕР
СТРОКИ
НАКЛАДНОЙ
(ПРАВИЛО 2)
3.	Если ключ типа данных А в типе данных Б является «чужим», то
тип данных Б становится порожденным для типа данных А:
Фермер	Партия товара
** Инициалы фермера	** Номер партии
Имя и адрес фермера	Дата приема
Дата отгрузки
* Инициалы фермера
215

4.	Тип данных с составным ключом является порожденным для всех
типов данных, ключ которых представляет собой часть составного клю*
ча. Дублирование связей устраняется:
Виды удержаний	Удержания
** Вид удержаний	**	Номер	накладной
Наименование сбора	Сумма
5.	Используя правила 3 и 4, следует рассматривать в отдельности
каждую область применения элементов данных.
Наш пример не может служить иллюстрацией этого положения, по¬
этому обратимся к системе резервирования авиабилетов.
Рейс
** Аэропорт (вылет) | Один и тот же элемент данных с
** Аэропорт (прибытие) \ одинаковыми допустимыми значе-
Пассажир, расстояние ниями используется по-разному
ИЗ
	►
АЭРОПОРТ
в
РЕЙС
	►
Связям для уточнения присваиваются имена.
Здесь перечислено лишь несколько правил из тех, которые предла¬
гает система Modus для упрощения работы с большими и сложными
логическими схемами данных.
ТОРГОВАЯ
КВИТАНЦИЯ
♦ СТРОКА
КВИТАНЦИИ
Рис. 13.4. Логическая схема данных (получена методами реляционного анализа)
На рис. 13.4 приведена логическая схема данных, полученная с по¬
мощью рассмотренных выше приемов для описанной в гл. 11 системы
CGT. В разделе, посвященном анализу способов доступа к данным, бу¬
дет показано, как эта схема модифицируется с учетом требований к об¬
работке данных.
ФЕРМЕР
ПАРТИЯ
ТОВАРА
ВИД
УДЕРЖАНИЙ
УДЕРЖАНИЯ
СТРОКА
НАКЛАДНОЙ L
ПРОДУКЦИЯ
НОМЕР
СТРОКИ
НАКЛАДНОЙ
216

13.5. Анализ логических связей
В двух предыдущих разделах рассматривались методики, совместное
применение которых позволяет сформировать логическую схему дан¬
ных, придерживаясь достаточно строгого подхода. Для этого необходи¬
мо наличие детальной исходной документации. Если результат должен
быть получен очень быстро или нет детальной информации, целесооб¬
разно воспользоваться более практичной методикой.
В качестве такой методики мы рекомендуем анализ логических свя¬
зей, с помощью которого можно построить логическую схему данных,
не рассматривая структуру данных на уровне элементов.
Последовательность проведения анализа. Прежде чем приступить к
анализу логических связей, нужно получить описание системы в какой-
либо форме (это могут быть и
детальные спецификации, и
простейшее описание). После¬
довательность проведения ана¬
лиза поясняется на примере
анализа связей в системе CGT.
1. Выявляются все объекты
в системе: реальные объекты
(например, «Клиенты» и «Про¬
дукция»), сведения о которых
хранятся в файлах, а также
транзакции (например, «Зака¬
зы» и «Накладные»), обраба¬
тываемые в системе. Не все
объекты удается ВЫЯВИТЬ С са-	рис 13 5_ Матрица логических связей
мого начала. Впоследствии
при выполнении процедур контроля, предусмотренных предлагаемой
методикой, список объектов может быть расширен.
В нашем примере сразу выявляются объекты «Фермер», «Партия
товара», «Продукция», «Покупатель», «Торговая квитанция».
2. Заполняется матрица связей и с ее помощью исследуются все
возможные связи между парами объектов.
На рис. 13.5 приведена подобная матрица для системы CGT. В са¬
мом начале ее блоки не заполнены, В блоке А представлены связи меж¬
ду отдельными объектами «Фермер». Блок В соответствует связям объ¬
ектов «Фермер» и «Партия товара», а блок С — связям объектов «Пар¬
тия товара» и «Покупатель» и т. д.
3. Отмечаются галочкой блоки с реально существующими связями
и крестиком — блоки, для которых связи нет.
«Фермер» непосредственно связан с «Партией товара», поскольку
именно он поставляет сельскохозяйственную продукцию на рынок. В то
же время первый объект не связан с «Покупателем», так как связь
между ними устанавливается только в момент продажи.
4. Для каждой выявленной связи устанавливается тип ассоциации.
Связи типа «один со многими» отмечаются стрелками, которые должны
быть направлены от владельца к члену связи.
В нашем примере между «Продукцией» и «Партией товара» суще¬
ствуют двунаправленные связи: партия товара может включать не¬
сколько видов продукции и в то же время продукция какого-то вида мо¬
жет входить в несколько партий товара.
Ах
ФЕРМЕР
X
BV
ПАРТИЯ
ТОВАРА
X
X
tx
ПРОДУКЦИЯ
X
X
сх
X
ПОКУПАТЕЛЬ
X
X
t X
X
ч/ ТОРГОВАЯ
\ КВИТАНЦИЯ
217

5. В соответствии с правилами, изложенными в разд. 13.4, все объ¬
екты изображаются на схеме прямоугольниками.
6. Прямоугольники соединяются стрелками, соответствующими
стрелкам в блоках матрицы. Для представления двунаправленных свя¬
зей вводится тип данных-связка С
Каждый экземпляр данных типа «Партия товара», как и каждый
экземпляр данных типа «Продукция» может быть связан с нескольки¬
ми экземплярами данных типа «Связка».
7.	Связкам присваиваются мнемоничные имена. Так, связка, упоми¬
навшаяся в п. 6, имеет имя «Строка накладной».
Сопоставление с методами реляционного анализа. Эта процедура за¬
вершает разработку логической схемы данных по методике анализа ло¬
гических связей. В результате ее выполнения схема может подвергнуть¬
ся некоторым изменениям. Окончательная версия логической схемы дан¬
ных для нашего примера будет во многом схожа со схемой, приведен¬
ной на рис. 13.4, но не идентична ей.
Тип данных «Покупатель» при реляционном анализе выявить не
удастся, поскольку исходная документация не содержит о нем никаких
сведений. Анализ логических связей позволяет обнаружить указанный
тип данных, но зато в схему не войдет тип данных «Удержания». При
последующем детальном анализе элементов данных соответствующая
ему повторяющаяся группа будет найдена в типе данных «Партия това¬
ра». Процедуры контроля логической схемы, составленной по рассмат¬
риваемой методике, скорее всего, дадут возможность устранить неточ¬
ности на уровне типов данных («Покупатель»), но окажутся «нечувст¬
вительными» к более мелким деталям.
13.6.	Анализ путей доступа к данным
До сих пор мы имели дело только с теми данными, которые должны
каким-либо образом храниться. Как было показано выше, рассмотрен¬
ные методики проектирования логической схемы приводят к неодина¬
ковым результатам. Для проверки правильности и уточнения логиче¬
ской схемы полезно проанализировать ее с точки зрения доступа к дан¬
ным при выполнении операций по обработке информации. Документа¬
ция, полученная на основе такого анализа, может служить исходным
материалом при проектировании физической структуры данных, обеспе¬
чивающей высокие эксплуатационные характеристики системы.
Неформальный контроль путей доступа. Этот метод предполагает
выполнение следующей процедуры.
1. Составляется перечень всех транзакций и выходных отчетов.
2. По структуре данных проверяется, могут ли быть получены дан¬
ные, необходимые для обработки каждой транзакции или отчета. При
1 Речь идет о связях типа «многие со многими». — Примеч. пер.
218

этом имеется в виду принципиальная (логическая) возможность досту¬
па: считается, что обеспечен доступ к типам данных по ключам и по
связям (в обоих направлениях). Кроме того, следует убедиться в том,
что типы данных содержат все необходимые элементы данных, а харак¬
тер связей соответствует логике обработки транзакций.
3. Если обработка какой-то транзакции не выполняется, в структуру
данных вводятся дополнительные типы данных и связи.
4. Типы данных или связи, не используемые для обработки транзак¬
ций, можно удалить из структуры (если только они не потребуются в
дальнейшем).
ЛОГИКА
к-во
ТИП ДАННЫХ
ДЕЙСТВИЕ
ПОИСКОВЫЕ
АРГУМЕНТЫ
ПРИМЕ¬
ЧАНИЕ
1
ПАРТИЯ
ТОВАРА
ЧТЕНИЕ
ПАРТИЯ
ТОВАРА
1
ФЕРМЕР
ТОЖЕ
ТО ЖЕ
ПОВТОРЯТЬ
ПОКА
6
10
СТРОКА
НАКЛАДНОЙ
СТРОКА
КВИТАНЦИИ
и
и
и
СТРОКА
НАКЛАДНОЙ
КОНЕЦ
ПОВТОРЕНИЙ
1
ПРОДУКЦИЯ
к
СТРОКА
НАКЛАДНОЙ
Рис. 13.6. Профиль доступа для обработки запроса о реализации продукции
Отметим, что единственная цель такого контроля — удостовериться
в наличии всех необходимых логических путей доступа к данным. Ис¬
следование объемно-временных характеристик системы, которые может
обеспечить имеющаяся структура данных, откладывается до этапа про¬
ектирования.
Анализ профилей доступа. Этот метод точнее предыдущего и позво¬
ляет подготовить более подробную документацию. Для иллюстрации его
применения обратимся вновь к системе CGT. Допустим, что необходимо
получить отчет о продаже продукции, входящей в отдельные партии то¬
вара. Иными словами, определена транзакция «Запрос о реализации
продукции», в результате обработки которой должны выдаваться все
строки квитанций для каждой строки накладной.
На рис. 13.6 показан профиль доступа к данным при обработке та¬
кого запроса. Представление о последовательности доступа к данным
можно получить, просматривая схему сверху вниз и слева направо.
Звездочкой отмечены те типы данных, доступ к которым происходит не¬
однократно. В приведенной здесь же таблице отражена логика процес¬
са обработки данных и указано, к каким типам данных осуществляется
219

доступ. В частности, в таблице показано, что операция чтения строк
накладной выполняется шесть раз, а операция чтения строки квитан¬
ции— до 10 раз при каждом обращении к строке накладной.
В таблице, кроме того, перечислены аргументы поиска, используе¬
мые при доступе к соответствующим типам данных. При доступе по свя¬
зи в обратном направлении аргументом поиска служит имя типа дан-
ных-владельца, а при доступе по ключу — имя ключевого элемента
данных. Так, непосредственный доступ к экземплярам данных типа
«Партия товара» происходит
по значениям элемента дан¬
ных «Номер партии».
Рассматриваемая методика
позволяет документировать
различные операции доступа,
в том числе создание, модифи¬
кацию и удаление экземпля¬
ров данных.
При составлении схем про¬
филей доступа приходится де¬
тально анализировать и прове¬
рять логическую схему дан¬
ных, которая в результате мо¬
жет быть уточнена и расшире¬
на. Любые связи или типы
данных, которые не нужны при
обработке текущих транзак¬
ций и не потребуются в буду-
Рис. 13.7. Модифицированная логическая схе- щем, МОЖНО удаЛИТЬ. С другой
ма данных	стороны, в схему вводятся все
недостающие компоненты.
В спецификации путей доступа включаются лишь наиболее важные
подпрограммы обработки данных в особых ситуациях. При составле¬
нии схем следует избегать излишней детализации, не нарушая в то же
время информативности выдаваемых описаний. Анализ путей доступа
позволяет упростить логику некоторых операций.
Пример критического анализа результатов проектирования логиче¬
ской схемы данных. В результате разработки всех профилей доступа
логическая схема данных, приведенная на рис. 13.4, может измениться
(рис. 13.7).
Для обработки транзакции, с помощью которой оформляются счета
для покупателей, недоставало типа данных «Покупатель». При выпол¬
нении расчета комиссионных потребовалось ввести в схему тип данных
«Продавец». В то же время сформированный по правилам анализа тип
данных «Строка накладной» был удален, поскольку не использовался
при обработке.
13.7.	Подготовка документации
Документация формируется на протяжении всего процесса анализа
данных. Состав комплекта документации, который должен быть разра¬
ботан к концу этого этапа вне зависимости от применяемой методики,
показан на рис. 13.8. Основой его является логическая схема данных и
спецификации путей доступа. Среди остальных документов нужно отме¬
тить следующие:
ФЕРМЕР
ПРОДАВЕЦ
ПОКУПАТЕЛЬ

"	 1
L __
1
Э 4-
4
Г
ПАРТИЯ
ТОВАРА
—►
УДЕРЖАНИЯ
ТОРГОВАЯ
КВИТАНЦИЯ
|
вид
УДЕРЖАНИЙ
^
. СТРОКА
* КВИТАНЦИИ
. . ч
СТРОК
НАКЛ/
:	—.
:а
ОДНОЙ
ПРОДУКЦИЯ
220

• Перечень типов данных. Приводятся размеры и число экземпляров
записей соответствующих типов (рис. 13.9).
• Определения типов данных. Для каждого типа данных указывают¬
ся входящие в него элементы данных и отмечаются ключевые элементы
(см. рис. 13.3).
ПРИ¬
МЕЧ. 1
СЛОВАРЬ
ЭЛЕМЕНТОВ
ДАННЫХ
ТАБЛИЦА
СВЯЗЕЙ
ЛОГИЧЕСКАЯ
СХЕМА
ДАННЫХ
ПРОФИЛИ
ДОСТУПА
СОСТАВ
ХРАНИЛИЩ
ДАННЫХ	J
СОСТАВ
ПОТОКОВ
ДАННЫХ
Рис. 13.8. Состав документации по анализу данных
Примеч. 1. В описания элементов данных на этапе системного анализа включаются
спецификации допустимых значений, форматов и т. д.
Примеч. 2.‘Определяется на этапе системного анализа. Указывается только перечень
типов данных
Тип данных
Размер,
байт
Число
экзем¬
пляров
Общий
объем,
памяти
байт
ПАРТИЯ ТОВАРА
100
500
50 000
СТРОКА НАКЛАДНОЙ
40
3000
120 000
ФЕРМЕР
80
1000
80 000
ПРОДУКЦИЯ
25
200
5 000
КВИТАНЦИЯ
20
1000
20 000
СТРОКА КВИТАНЦИИ
30
2000
60 000
Рис. 13.9. Перечень типов данных
• Словарь элементов данных. На рис. 13.10 приведен фрагмент сло¬
варя элементов данных для системы CGT. С помощью такого словаря
нетрудно проанализировать имена элементов данных, выявить синони¬
мы и омонимы, например даты. (Аналогичные элементы данных, кото¬
ПРИ -
МЕЧ. 2
ПЕРЕЧЕНЬ
ТИПОВ
ДАННЫХ
ОПРЕДЕЛЕНИЯ
ТИПОВ
ДАННЫХ
221

рые имеют различные имена в разных типах данных, удается обнару¬
жить еще при анализе логической схемы данных.) Словарь расширяет¬
ся на этапе системного анализа, когда в него вводятся описания эле¬
ментов данных, диапазоны допустимых значений, форматы представле¬
ния, правила обработки и т. д.
Сумма
УДЕРЖАНИЯ
Инициалы покупателя
КВИТАНЦИЯ
Комиссионные
ПАРТИЯ ТОВАРА
** Номер строки наклад¬
СТРОКА НАКЛАДНОЙ
ной
** Номер строки наклад¬
НОМЕР КВИТАНЦИИ/СТРО¬
ной
КИ
** Номер партии товара
ПАРТИЯ ТОВАРА
** Номер партии товара
СТРОКА НАКЛАДНОЙ
** Номер партии товара
СТРОКА КВИТАНЦИИ
** Номер партии товара
УДЕРЖАНИЯ
Количество
СТРОКА ПРИКЛАДНОЙ
Дата оформления
ПАРТИЯ ТОВАРА
Дата получения
ПАРТИЯ ТОВАРА
Дата продажи
КВИТАНЦИЯ
* Код продукции
СТРОКА НАКЛАДНОЙ
** Код продукции
ПРОДУКЦИЯ
Вес
СТРОКА НАКЛАДНОЙ
Рис. 13.10. Фрагмент словаря элементов данных
Тип данных-
член связи
Тип данных-
член связи
Общий
элемент
данных
Прочие ключе¬
вые элементы
данных
Среднее
число
связей
Приме¬
чание
ПАРТИЯ ТОВА¬
РА
СТРОКА НА¬
КЛАДНОЙ
УДЕРЖАНИЯ
Номер партии
Номер партии
Номер строки
накладной
Код удержа¬
ний
6
0,1
СТРОКА НА¬
КЛАДНОЙ
СТРОКА КВИ¬
ТАНЦИИ
Номер партии
Номер строки
накладной
Номер квитан¬
ции
3
ФЕРМЕР
ПАРТИЯ ТОВА¬
РА
Имя фермера
Номер партии
1 ,2
Рис. 13.11. Таблица связей
• Таблица связей (рис. 13.11). Таблица связей в принципе эквива¬
лентна логической схеме данных, но содержит дополнительную инфор¬
мацию. В примечаниях может быть отмечено название связи.
13.8.	Проблемы, возникающие при анализе данных
Рассматриваемые в литературе примеры анализа относительно про¬
стых структур данных не должны вводить читателя в заблуждение. Ана¬
лиз реальных структур данных, включающих множество элементов, соп¬
ряжен подчас со значительными трудностями. Некоторые из них мы
рассмотрим ниже.
222

Квалификация персонала. Аналитики, выполняющие анализ данных,
должны разбираться в предметной области и владеть соответствующи¬
ми методиками. Только тогда они смогут создать логическую схему
данных, удовлетворяющую информационным потребностям организа¬
ции, и решить проблемы, с которыми им придется столкнуться на прак¬
тике.
Некоторые практические проблемы. Основная проблема, возникаю¬
щая при проектировании логической структуры данных, — ее «размер¬
ность». Сложная схема может включать множество связей, а также ти¬
пов и элементов данных. Для проведения анализа целесообразно выде¬
лить в такой схеме несколько фрагментов и рассматривать их по от¬
дельности. При этом все время следует помнить о непротиворечивости
получаемых спецификаций.
Далее, необходимо иметь в виду, что методы анализа данных не яв¬
ляются догмой. Опытный разработчик часто может принимать стандарт¬
ные решения (без использования рассматриваемых методик) даже тог¬
да, когда, казалось бы, аномальные ситуации неизбежны. Например,
тип данных может содержать некоторый «факультативный» элемент.
В ряде случаев это никак не отражается на общей структуре данных.
В системе CGT к таким элементам данных относится «маркировка».
Далеко не во всех партиях отдельные упаковки специальным образом
маркируются. Если характер связи, направленной к некоторому типу
данных от какого-то другого типа данных, определяется значением фа¬
культативного элемента данных, целесообразно ввести в схему один или
более включающих его типов данных, снабдив их разными именами.
В реальных разработках приходится встречаться со множеством
проблем подобного рода, и для их решения желательно располагать не¬
которым унифицированным методом.
Структурные изменения. Вполне возможно, что в ходе анализа будут
обнаружены связи, которые в настоящее время не поддерживаются, а
их реализация сопряжена со значительной перестройкой работы орга¬
низации. Рассмотрим некую систему учета оплаты коммунальных услуг.
Допустим, что счета в ней идентифицируются каким-либо номером, на¬
пример номером телефона клиента. Если потребуется подготовить от¬
чет, где данные по счетам должны быть упорядочены по месту житель¬
ства и имени клиентов, может встать вопрос об изменении системы ко¬
дирования. В свою очередь это приведет к коренному изменению адми¬
нистративных процедур и, как следствие, — к реорганизации множест¬
ва имеющихся записей. Поэтому очень важно, чтобы подобные измене¬
ния обсуждались и согласовывались в процессе анализа, так как из-за
высокой стоимости реализации нововведений, возможно, их придется пе¬
ресмотреть.
13.9.	Применение методов анализа данных при разработке ИС
Конкретный способ применения рассмотренных в настоящей главе
методов зависит от того, на каком этапе разработки ИС они внедряют¬
ся. На ранних этапах — при планировании ИС, анализе реализуемости
проекта и при выполнении системного анализа — из-за недостаточности
исходной информации целесообразно воспользоваться методами анали¬
за логических связей. Более точные методы реляционного анализа дан¬
ных мы рекомендуем для поздних стадий системного анализа. Но конеч¬
но, из этих общих правил возможны исключения, которые рассматри¬
вались в соответствующих главах.
223

Результаты анализа данных используются при проектировании как
традиционных файловых систем, так и систем баз данных. В последнем
случае особенно важны при физическом проектировании спецификации
профилей доступа.
Даже безотносительно к смежным методикам проектирования ИС
методы анализа данных представляют значительный интерес, поскольку
они позволяют применять процедуры пошаговой детализации требова¬
ний пользователей и получать спецификации данных, которые можно
всесторонне проконтролировать. Таким образом, вне зависимости от
конкретной методики проектирования ИС метод анализа данных обес¬
печивает непротиворечивость и неизбыточность структуры данных, что
в свою очередь дает возможность избежать впоследствии многочислен¬
ных корректировок документации.
Литература
1. С о d d Е. F. Normalised data base structure: a brief tutorial. — ACM-SIGFIDET
Workshop on Data Description, Access and Control, ACM, New York, 1 —18, 1971.
Глава 14
Анализ структуры файла
14.1.	Введение
Анализ структуры файла позволяет реализовать формализованную
процедуру .ее описания. Этот метод применяется при системном проек¬
тировании, спецификации программ и программировании. По результа¬
там анализа формируется схема, отражающая логическую структуру
файла.
14.2.	Основные структуры данных
Мы выделяем три основные структуры данных: последовательную,
иерархическую с альтернативными вариантами и иерархическую с пов¬
торениями. Любой набор данных может быть разложен на указанные
компоненты. С помощью метода анализа структуры файла можно опре¬
делить, из каких элементов складывается логическая структура храни¬
мых в нем данных, и построить логическую схему файла.
Рассмотрим файл перфокарт. Данные здесь упорядочены, т. е. одна
перфокарта следует за другой. Это последовательная структура дан¬
ных. Если перфокарты содержат операторы языка управления задани¬
ями, программы или данные, то речь идет об иерархической структуре
с альтернативными вариантами. Наконец, файл может включать мно¬
жество перфокарт данных. В таком случае говорят об иерархической
структуре с повторениями. На рис. 14.1 показано, как подобные струк¬
туры изображаются на схемах. В последовательных структурах компо¬
ненты на схемах располагаются слева направо: перфокарты типа А, за¬
тем перфокарты типа В и за ними перфокарты типа С. Кружок в пра¬
вом верхнем углу прямоугольника указывает на то, что на данном уров¬
224

не может иметься один из изображенных таким образом компонентов
(в иерархических структурах с альтернативными вариантами), а звез¬
дочка— на повторение какого-либо компонента структуры.
ПОСЛЕДОВАТЕЛЬНАЯ
ИЕРАРХИЯ С
АЛЬТЕРНАТИВНЫМИ
Рис. 14.1. Три основные структуры данных
14.3.	Анализ логической структуры файла
Логическая структура файла определяется логическими функциями,
выполняемыми системой. Его физическая структура разрабатывается
позднее логической с учетом особенностей устройства, на котором он
будет размещаться. При проектировании программ и разработке их
спецификаций физическую структуру можно не принимать во внимание.
Исключение делается только для файлов, выводимых на устройства пе¬
чати (разд. 14.5).
При анализе структуры файла прежде всего выделяют группы логи¬
чески взаимосвязанных данных, а затем устанавливают, с помощью ка¬
ких компонентов можно представить их структуру. Рассмотрим файл,
структура которого изображена на рис. 14.2. Этот файл вначале рас¬
сматривается как единое целое и затем последовательно разбизается
на составляющие. Каждая ветвь «дерева» структуры заканчивается
блоками, соответствующими реально существующим в файле записям.
Файл рассылки включает следующие типы записей: заголовок, данные
по области и хвостовые метки. Для каждой области в свою очередь
имеется заголовок и детальные данные —либо о магазинах, либо о кли¬
ентах. Для уточнения схемы имена повторяющихся записей следует
давать в единственном числе (например, «Область», а не «Области») и
225

указывать их в прямоугольнике только для реально существующих
записей.
После того как схема файла составлена, ее желательно сопоставить
с ключами файла. Если это невозможно, необходимо проверить струк¬
туру файла каким-то другим способом и удостовериться в том, что ло¬
гические функции его обработки могут быть реализованы. Ключ файла,
приведенного на рис. 14.2, содержит следующие элементы данных:
• номер области (принимает нулевое значение в заголовке файла и
наибольшее значение в хвостовой метке);
• номер магазина или клиента (значения в заголовке файла и хво¬
стовой метке — те же, а в заголовке области — нулевое);
• идентификатор типа записей.
Рис. 14.2. Главный файл рассылки
Состав ключа подтверждает, что структура файла разработана пра¬
вильно. Если два последних элемента ключа поменять местами, то дан¬
ные о клиентах должны размещаться перед данными о магазинах.
В рассматриваемом примере распределение номеров магазинов и кли¬
ентов носит случайный характер.
14.4.	Некорректная структура файла
Структура файла не должна порождать двусмысленности. При осво¬
ении описываемой в настоящей главе методики вполне вероятно, что
одни и те же структуры будут интерпретироваться членами проектной
группы по-разному. Ниже описаны наиболее характерные проблемы, с
которыми обычно приходится сталкиваться при формировании струк¬
туры файла, и пути их решения.
Рассмотрим структуру файла, приведенную на рис. 14.3. Каков ее
смысл? На этот вопрос можно ответить двояко:
• для каждого клиента имеется либо только запись, содержащая
сведения о нем, либо запись счета, и автор схемы забыл пометить пер¬
вый блок кружком;
• для каждого клиента имеется запись, содержащая сведения о нем,
за которой следует запись счета, причем последняя может быть опу¬
щена.
226

Структуру файла целесообразно изобразить так, как показано на
рис. 14.4. Некорректность первоначальной схемы можно устранить, если
придерживаться следующих правил:
1.	Структура с альтернативными вариантами должна быть единст¬
венной на данном уровне; кроме нее здесь не должно быть никаких дру¬
гих структур.
Рис. 14.3. Некорректная структура фай- Рис. 14.4. Уточненная структура файла, по¬
ла счетов клиентов	казанного	на	рис.	14.3
2.	Эта структура должна включать не менее двух блоков.
Вторая распространенная ошибка состоит в том, что в структуре
файла выделяется недостаточное число уровней, в результате чего «за
кадром» остаются некоторые «полезные» группировки данных. На этом
этапе разработки ИС предпочтительнее излишне детализировать опи-
Рис. 14.5. Файл счетов
сания, чем упустить какие-то важные сведения (во избежание усложне¬
ния дальнейшего проектирования и программирования). На рис. 14.5
приведена схема файла, которая была представлена программисту.
Согласно последней спецификации обработка с заданным сроком
оплаты счетов отличается от обработки счетов, которые могут оплачи¬
ваться в удобное для клиента время. Проконсультировавшись с пользо¬
227

вателями, программист установил, что для каждого клиента вначале
фиксируются счета первого типа, а затем — второго. Это обстоятельство
существенно упростило написание программы. Фрагмент видоизменен¬
ной структуры файла показан на рис. 14.6.
Рис. 14.6. Детализация структуры данных о клиентах в файле счетов
14.5. Физическая структура файла
Говоря о физической структуре файла, часто подразумевают формат
его записей, размещаемых на внешних запоминающих устройствах.
Представление о физической структуре файла, хранящегося на магнит¬
ной ленте или диске, дает схема, изображенная на рис. 14.7. Основные
компоненты файла печати показаны на рис. 14.8.
При работе с файлами первого типа программисту обычно не при¬
ходится детально изучать их физическую структуру, поскольку объеди-
Рис. 14.7. физическая структура	Рис.	14.8.	Физическая	структура фай-
файла, хранящегося на магнитной	ла	печати
ленте или диске
нение логических записей в блоки и обратное преобразование выполня¬
ют соответствующие модули операционной системы. Несколько иначе
обстоит дело при выводе данных на печать, когда на каждой странице
отчета нужно разместить какой-то заголовок или хотя бы номер стра¬
ницы. Положение заголовка на странице, как правило, не находится в
прямой связи с остальным текстом, поэтому не так просто разработать
структуру файла, в точности соответствующую формату выходного от¬
чета. При разработке спецификаций и проектировании программ снача¬
ла удобно считать, что файл печати не делится на страницы (логиче¬
ская структура). Позднее, при написании программы, программист
должен будет детализировать структуру такого файла и отразить в ней
точное расположение данных на страницах (физическая структура).
228

14.6. Структуры файлов при проектировании систем
На этапе проектирования системы в состав документации рекомен¬
дуется включать схемы, отражающие структуру файлов. Анализируя
их, пользователь сможет получить более точное представление о на¬
правлении автоматизации работ, программист — правильно составить
программы обработки данных, а проектировщик системы — реализовать
компоненты ИС, обеспечивающие защиту и целостность информации, и,
кроме того, средства восстановления данных после возникновения от¬
казов.
14.7.	Структуры файлов при проектировании программ
Рассмотренные выше структуры файлов разрабатываются главным
образом на основе анализа информационного содержания автоматизи¬
руемых функций. Прежде чем приступить к составлению программ, не¬
обходимо еще раз изучить полученные на предыдущих этапах структу¬
ры и убедиться в том, что они адекватны логике процессов обработки
данных. На практике структуры файлов могут оказаться чересчур слож¬
ными либо, наоборот, в них могут быть опущены какие-то важные де¬
тали. Поясним это на примере двух программ обработки файла рассыл¬
ки (см. рис. 14.2).
Первая программа довольно проста и предназначена для контроля
содержания файла, выполняемого при ревизии. Она подсчитывает об¬
щее число записей и два итоговых значе¬
ния: число записей данных и число хво¬
стовых меток в файле. На рис. 14.9 пока¬
зана видоизмененная специально для.
этой программы структура файла. По¬
скольку единственная задача програм¬
мы — подсчет числа записей, деталями
структуры данных можно пренебречь,
значительно упростив таким образом со¬
ставление программы. Программа, раз¬
работанная на основе первоначальной
структура, была бы неоправданно слож¬
на и громоздка.
Здесь также удалось применить правило выделения типов физиче¬
ских записей, что оказалось полезным и при проверке структуры файла,
и при проектировании программы его обработки.
Вторая программа — более сложная. С ее помощью должны извле¬
каться из файла все данные, относящиеся к областям, указанным на
управляющих перфокартах, и подготавливаться отчет, в заголовок кото¬
рого включается информация из заголовка файла. Далее печатается
страница итогов по каждой области, заголовок	которой	в	свою очередь
формируется на основе заголовка для области.	Затем	извлекается	ин¬
формация о магазинах и областях, где объем поставок выше среднего.
Последнее значение содержится в заголовке для области.
Очевидно, что структуру файла, полученную на этапе проектирова¬
ния, следует расширить (рис. 14.10). Из рисунка видно, что структура
данных для областей детализирована: введен новый уровень иерархии,
свидетельствующий о том, что данные по одним областям извлекаются,
а по другим — нет. Решение принимается на основе содержания спра¬
вочного файла, но на нашей схеме отражена только структура главно¬
Рис. 14.9. Упрощенная структура
файла
229

го файла рассылки. Можно, кроме того, упростить структуру данных
для областей, сведения о которых не печатаются. Информация на ниж¬
нем уровне иерархии теперь позволяет уточнить сведения о магазинах
и клиентах, включаемых в отчет.
Такая усовершенствованная структура дает возможность выделить
два вида обработки данных и необходимые для этого группы записей.
Она содержит больший объем информации о решаемой задаче, чем пер¬
воначальная. Как отмечалось выше, на рассматриваемом этапе разра-
Рис. 14.10. Детализированная структура файла
ботки системы совершенно излишне исследовать процесс принятия ре¬
шений по ходу выполнения программы. Важно только, чтобы на необхо¬
димость выбора явно указывали дополнительные блоки схемы. Еще раз
подчеркнем, что это проясняет прикладную проблему в целом. Усовер¬
шенствованная структура файла может служить хорошей основой для
разработки логики программы. Однако усовершенствованную структу¬
ру нужно еще раз всесторонне проверить. Так, в нашем примере жела¬
тельно убедиться в том, что данные по областям по-прежнему включа¬
ют заголовок, за которым следуют детальные сведения либо о магази¬
нах, либо о клиентах.
Дальнейшая проверка структуры файлов выполняется на ранних
стадиях разработки программ.
14.8.	Заключение
На этапе системного проектирования формируются схемы, отражаю¬
щие логическую структуру каждого файла, в которой с помощью иден¬
тификаторов выделены физические записи. Эти схемы создают основу
230

всей логики обработки информации, относящейся к конкретному файлу.
Логика обработки информации должна предусматривать контроль до¬
стоверности данных, создание резервных копий и восстановление после
отказов системы. Необходимо, чтобы спецификация программы вклю¬
чала схемы структур всех обрабатываемых файлов, а также бланки
спецификации логики обработки этих файлов.
Схемы, отражающие логическую структуру файлов, совместно рас¬
сматриваются всеми членами проектной группы. Хорошо сконструиро¬
ванные файлы оказывают определяющее влияние на создание легко
сопровождаемых систем, а метод анализа структуры файлов обеспечи¬
вает удобные средства для повышения качества конструирования
файлов.
При проектировании программы программист расширяет или упро¬
щает структуру файла, приспосабливая ее к программируемой задаче.
Эта структура становится основой для формирования модульной струк¬
туры программы и логики функционирования каждого модуля. Еще
раз следует отметить, что ревизия предложенной схемы является жиз¬
ненно необходимой, так как позволяет уже на ранних этапах разработ¬
ки ИС удостовериться в том, что программист верно понимает функции
программы.
Всегда, когда требуется быстрая оценка проекта, хорошо докумен¬
тированная структура файлов — один из наилучших способов представ¬
ления обобщенной информации о системе. Поэтому нужно постоянно
контролировать не только логическую структуру файлов, созданную на
этапе проектирования системы, но и уточненную структуру, полученную
на этапе проектирования программ.
Глава 15
Спецификация логики обработки данных
15.1.	Введение
На этапё системного анализа необходимо четко определить задачи
пользователей, указав порядок выполнения и назначение каждой опера¬
ции. Подготовка детальной документации на этом этапе дает пользова¬
телям возможность своевременно проверить ее, а разработчикам — по¬
лучить единый источник информации по системе и передать проектной
группе точные спецификации требований к ИС. В ходе проектирования
помимо информационных процессов, отображающих функциональную
модель организации, нужно отработать и технологические процессы,
чтобы впоследствии после соответствующей проверки на их основе под¬
готовить фрагменты спецификаций программ.
Традиционный способ документирования процедур — составление
вербальных описаний. Чаще всего мало кто, кроме самого автора, мо¬
жет полностью понять описания такого рода. По этой причине пользо¬
ватели, как правило, уклоняются от проверки спецификаций. В резуль¬
тате ошибки, не выявленные на ранних стадиях анализа, остаются не¬
обнаруженными в течение всего процесса проектирования вплоть до на¬
чала испытаний, а иногда — и до ввода системы в эксплуатацию.
Исправление подобных ошибок может обойтись непомерно дорого. При¬
чинами же их возникновения являются неточность и неоднозначность
описаний на естественном языке.
231

Поэтому для спецификации логики обработки данных применяется
формализованный язык — псевдокод1. Структура процедуры описывает¬
ся с помощью ключевых слов. Описание оформляется в виде последова¬
тельности пронумерованных разделов. Использование псевдокода в со¬
ответствии с рекомендациями, приведенными в настоящей главе, поз¬
воляет успешно решить упомянутые выше проблемы и обеспечивает
стандартный метод документирования процедур, реализуемых в ИС.
15.2.	Анализ описаний процедур
Прежде всего необходимо установить и документально оформить все
административно-управленческие процедуры, выполняемые в предмет¬
ной области ИС. Начать можно с записей и заметок, сделанных во вре¬
мя сбора исходных данных для разработки системы. Эта работа долж¬
на завершиться составлением бланков описания операций (гл. 6). Бланк
описания операций состоит из нескольких разделов, один из которых
включает собственно описание процедуры, а остальные — дополнитель¬
ную информацию. Мы рассмотрим здесь только раздел с описанием
процедуры.
Анализ начинается с исследования исходных материалов и выявле¬
ния всех неточностей, пропусков и не относящихся к делу деталей. Од¬
новременно фиксируются важнейшие факты, на основе которых будет
формироваться окончательное описание процедуры. При работе с ис¬
ходными текстами для выделения упоминаемых в них условий и дейст¬
вий полезно применять флуоресцентный фломастер. Условие указывает
на некоторое обстоятельство или обстоятельства, при которых следует
предпринять определенные действия. Пример условия: «Учащийся
успешно выдержал 50% испытаний по английскому и французскому
языкам». Предложение в повелительном наклонении означает действие,
например: «Включить уроки немецкого языка в расписание занятий вто¬
рого года обучения».
Фразы, непосредственно не относящиеся к рассматриваемой процеду¬
ре, можно полностью опустить, но иногда из них можно почерпнуть
какие-то важные сведения и включить их в другие разделы бланка.
Так, в разделе «Примечания» можно разместить комментарии, поясня¬
ющие логику процедуры. Необходимо выявить расплывчатые формули¬
ровки условий и уточнить их. Чаще всего в этих случаях речь идет о
перечислении или выборе условий, например: «В список включаются
учащиеся, которые должны приступить к занятиям по двум и более но¬
вым предметам и уже изучают не менее восьми предметов, и в их плане
следует предусмотреть более сорока уроков, или те учащиеся, в распи¬
сании которых нет «окон».
Нередко неточности возникают и при указании диапазонов значений
некоторой переменной, например: «Для учащихся, имеющих успевае¬
мость по математике ниже 50%, включить в расписание шесть уроков, а
для тех, у кого успеваемость выше 50%, — пять уроков». Неясно, как
следует поступить, если успеваемость составляет ровно 50%.
Все фразы, содержащие подобные неточности, нужно пометить, что¬
бы впоследствии можно было получить дополнительную информацию и
прояснить их смысл. Наиболее часто встречаются нечеткие определения,
например: «Занятые преподаватели не должны назначаться на дежур¬
1 В оригинале — Structured English (структурный английский язык). — Примеч.
пер.
232

ство в буфет». Кого следует считать «занятым»? Другой пример: «При
вычислении стоимости заказа умножить объем партии товара на цену».
О какой цене идет речь: с учетом или без учета скидки, на момент со¬
вершения сделки или в настоящее время? Смысл этой фразы следует
уточнить, определив правильно цену.
По завершении анализа исходных данных и устранения всех неточ¬
ностей выполняется структуризация логики процедуры.
15.3.	Верификация и структуризация логики процедуры
Если логика процедуры не тривиальна, важно проверить, выявлены
ли все возможные комбинации условий и оправданы ли предпринимае¬
мые в соответствии с ними действия.
Одним из наиболее простых способов представления логики некото¬
рого процесса является дерево решений (рис. 15.1). По такой схеме
ЕХАТЬ НА
МАШИНЕ
взять
ТАКСИ
ДОБИРАТЬСЯ
ПЕШКОМ
ПОБЫТЬ
ДОМА
15.1. Дерево решений
очень легко уяснить, какие действия выполняются при каждом условии.
Дерево решений позволяет быстро изобразить логику процессов сред¬
ней сложности. Основной недостаток этой схемы состоит в том, что раз¬
работчик может пропустить некоторые комбинации условий. Более
сложные процессы целесообразнее отображать с помощью таблицы
решений, которая позволяет проанализировать все вероятные комбина¬
ции условий. В настоящей книге таблицы решений не рассматриваются.
Для простых процессов представление логики не вызывает затруднений
и не требует каких-либо специальных методов.
Однако ни дерево решений, ни таблицы не удовлетворяют всей сово¬
купности требований, предъявляемых к средствам документирования
процедур при разработке ИС. Дерево решений может оказаться «необо¬
зримым». Таблицы более компактны, но составить и понять их смогут
только те специалисты, которые прошли специальную подготовку, а та¬
кими специалистами располагает далеко не каждая организация. В си¬
стеме Modus для документирования процедур предлагается использо¬
вать псевдокод.
15.4.	Псевдокод
Псевдокод предназначен для описания логики процедур с помощью
ограниченного набора простых четко определенных конструкций. Спе¬
цификации, составленные на псевдокоде, предельно ясны.
МАШИНА
ДЕНЬ
8 Зак. 1783
233

В работах по структурному программированию показано, что логи¬
ка любой процедуры, независимо от степени ее сложности, представля¬
ется с помощью трех основных конструкций. Всякая операция может
быть разложена на некоторую комбинацию последовательных действий,
принятия решений и ветвления действий и циклов. Соответствующие ло¬
гические конструкции рассматривались в разд. 8.2. Все эти конструкции
могут быть специфицированы на псевдокоде, причем форма их записи
упрощена настолько, что они понятны даже тем, кто не имеет специ¬
альной подготовки.
ПРОЦЕСС: продление визы
ДЛЯ КАЖДОГО: запроса
1.	Оформить разрешение если ежедневно обмениваемая сумма
— не менее 5 дол., в противном случае отклонить запрос.
1.1. Для запросов, рассматриваемых в полицейском участке:
— для виз, уже продлевавшихся на три месяца, отклонить запрос;
— визы, продленные менее чем на три месяца, продлить на неделю.
1.2. Для запросов, рассматриваемых иммиграционной службой, принять решение в
соответствии со следующей таблицей:
Продление было оформлено
Разрешить продление
На срок до 2 мес
На срок от 2 до 3 мес
На срок 3 мес и более
На срок до 1 мес
На 3 мес минус срок, на который
уже выдано продление
Отклонить запрос
2. Отметить продление визы в паспорте.
Рис. 15.2. Пример спецификации процесса на псевдокоде
Пример спецификации на псевдокоде приведен на рис. 15.2. Описа¬
ние дается в повелительном наклонении. Каждое действие или условие
нумеруется и записывается с соответствующим отступом. Нумерация и
.отступы в тексте спецификации позволяют установить непосредствен¬
ную связь описания с деревом решений, на основе которого оно разра¬
ботано. Для упрощения восприятия спецификации компоненты описания
нижних уровней не нумеруются.
Последовательные действия представлены предложениями, следую¬
щими в порядке очередности. Сложные действия могут разделяться на
составляющие. В тексте соответствующие предложения располагаются
ниже и правее предложения, описывающего основное действие.
Условия записываются с помощью ключевых слов ЕСЛИ, ДЛЯ,
КОГДА, ГДЕ, после которых дается пояснение ситуации и предприни¬
маемых действий. Отступы соответствуют структуре дерева решений.
Пример спецификации на псевдокоде и дерево решений приведены на
рис. 15.3. Действия, предпринимаемые согласно взаимоисключающим ус¬
ловиям, описываются конструкцией ВЫБОР. Условия записываются в
табличной форме (см. рис. 15.2). Особые условия фиксируются с ис¬
пользованием ключевых слов ПОКА НЕ и В ЭТОМ СЛУЧАЕ.
Циклы представляются фразой «ДЛЯ КАЖДОГО» (объект дейст¬
вия) ПОКА (условие завершения цикла). Вслед за этой фразой пере¬
числяются действия, выполняемые в цикле.
Всякая ссылка на объект данных должна включать имя, определен¬
ное в словаре данных. Такие имена в тексте берутся в кавычки, под¬
черкиваются или записываются строчными литерами. Это совершенно
234

необходимо, если предполагается проводить программную проверку не¬
противоречивости описаний.
Основная цель, преследуемая при составлении спецификаций на
псевдокоде, — сделать описания одинаково понятными пользователям,
ПРЕДОСТАВИТЬ
БОЛЕЕ 	ПОЛНЫЙ
8 МЕС	ОТПУСК
МЕНЕЕ	ПРЕДОСТАВИТЬ
8 МЕС. 	:	ЧАСТИЧНЫЙ
ОТПУСК
ПРЕДОСТАВИТЬ
			 ПОЛНЫЙ
ОТПУСК
Псевдокод
1.1. Если стаж работы сотрудника менее года:
— при стаже работы не менее 8 мес. предоставить полный отпуск
— при стаже работы менее 8 мес. предоставить частичный отпуск
1.2. Если стаж работы сотрудника не менее года:
— предоставить полный отпуск.
Рис. 15.3. Дерево решений и спецификация на псевдокоде
аналитикам и проектировщикам. Поэтому при составлении описаний
нужно быть особенно внимательным. Каждая фраза должна толковать¬
ся однозначно. После завершения разработки бланков описания опера¬
ций все они подвергаются критическому анализу.
15.5.	Описание процессов на стадии проектирования системы
При проектировании ИС к описаниям процессов, отражающих адми¬
нистративно-управленческие функции, выявленные на этапе системного
анализа, добавляются спецификации технологических процессов обра¬
ботки информации. Спецификации процессов, протекающих в предмет¬
ной области системы, могут быть подвергнуты декомпозиции. Бланки
описания процессов, используемые для этих целей, рассматривались в
разд. 7.3. Такой бланк состоит из трех частей: заголовка, схемы и вер¬
бального описания на псевдокоде, составленного с учетом рекоменда¬
ций, рассмотренных в настоящей главе.
Глава 16
Технический контроль проекта
16.1.	Введение
Методы технического контроля проекта (ТКП) применяются при
расчете ожидаемых объемно-временных характеристик разрабатывае¬
мой системы, при проверке соответствия системы заданным целевым
установкам (на этапе проектирования), при формировании стратегии
разработки, для анализа реализуемости проекта и оценки необходимых
ресурсов. В настоящей главе методы ТКП рассматриваются несколько
более подробно.
ДЕРЕВО
РЕШЕНИЙ
СТАЖ
РАБОТЫ
МЕНЕЕ
ГОДА
СТАЖ
РАБОТЫ
БОЛЕЕ
ГОДА
8*
235

При техническом контроле проекта выделяют три основные группы
задач. Прежде всего на начальных стадиях проектирования в процессе
декомпозиции системы создают спецификацию ее операционной среды:
уточняют состав и объемы информации, определяют главные функции
обработки и указывают требуемые объемно-временные характеристики
проектируемой ИС. Затем исходя из имеющихся проектных данных вы¬
полняют расчет ожидаемых объемно-временных характеристик системы.
Если по ходу разработки проектные данные уточняются, расчеты могут
быть повторены. И наконец, результаты вычислений сопоставляют с за¬
данными целевыми установками. При значительных расхождениях либо
корректируют проектные решения, либо пересматривают целевые уста¬
новки.
Технический контроль проекта обеспечивает структурный подход к
расчету ожидаемых объемно-временных характеристик системы, точ¬
ность вычислений и простоту оценки последствий предполагаемых кор¬
ректировок проекта. Кроме того, методы ТКП позволяют выяснить, ка¬
кие компоненты системы используются наиболее часто и по этой при¬
чине требуют более эффективной реализации.
Руководитель проекта с помощью методов ТКП может оперативно
получать результаты расчетов с требуемой степенью точности и заранее
выявлять намечающиеся отклонения реальных характеристик системы
от заданных. Благодаря этому удается избежать «нелинейной» зависи¬
мости интегральных характеристик системы от ошибок в расчетах или
прогнозах.
16.2.	Описание процедуры
Процедура ТКП иллюстрируется рис. 16.1. Основными компонента¬
ми этой процедуры являются описание операционной среды, расчет объ¬
емно-временных характеристик системы и критический анализ результа¬
тов. Указанные операции могут образовать цикл: при неудовлетвори¬
тельных характеристиках системы потребуется заново описать операци¬
онную среду и выполнить вычисления. На рисунке показана также
дальнейшая детализация основных компонентов, которая будет рас¬
смотрена ниже.
Прежде всего необходимо собрать все статистические данные о си¬
стеме, полученные на этапе проектирования. (Напомним, что в процес¬
се декомпозиции системы были определены состав, структура и объемы
данных, а также функции их обработки. По завершении же этапа техни¬
ческого проектирования подготовлены спецификации программ и фай¬
лов. )
Затем специфицируются основные параметры. Для этого, возможно,
придется проконсультироваться со службами технического планирова¬
ния и эксплуатации ИС. Требования пользователей, например по време¬
ни реакции и контрольным срокам ввода данных и получения результа¬
тов, формулируются на стадии системного анализа и служат основой
для определения параметров, которыми должна обладать система. Если
разрабатываемая система будет функционировать на одной ЭВМ парал¬
лельно с другими системами, следует учесть и их взаимное влияние.
Может оказаться, что целевые установки, сформулированные для
разрабатываемой системы, нереальны из-за влияния уже действующих
систем. В этом случае целесообразно пересмотреть целевые установки
совместно со службами технического планирования и эксплуатации и
при необходимости скорректировать их.
236

Одновременно с предыдущей задачей решается еще одна — опреде¬
ляется число обращений к дисковой памяти, выполняемых прикладны¬
ми программами. Требуемую для этого информацию можно почерпнуть
из документации технического проекта, где имеются сведения о различ¬
ных процессах (проверки достоверности данных, корректировки файлов
и т. д.) и числе операций ввода-вывода.
Рис. 16.1. Основные компоненты процедуры ТКП
Последняя подготовительная задача — сбор статистики о работе
оборудования и программного обеспечения. Наиболее точные результа¬
ты получаются при установке на ЭВМ специальных средств монитори-
зации. Если это невозможно, следует запросить соответствующие харак¬
теристики у поставщиков ЭВМ и программных средств. При наличии
СУБД или телемонитора должны быть известны и их операционные ха¬
рактеристики.
Второй компонент процедуры технического контроля проекта, как
уже отмечалось, — расчет объемно-временных характеристик разраба¬
тываемой системы. Для записи результатов расчета применяется специ¬
альный бланк, рассматриваемый в следующем разделе, а сам расчет
237

описывается в разд. 16.4. При выполнении операции 7 (см. рис. 16.1) не¬
обходимо просуммировать оценки, сделанные для отдельных программ,
с учетом всех видов выполняемой периодически обработки данных. Сле¬
дует также вычислить средние и пиковые нагрузки на систему. В ряде
случаев аналогичные расчеты придется провести и для некоторых под¬
систем. Если правильно отразить характеристики программ, выполняю¬
щих каждый вид обработки, подобные вычисления не вызовут затруд¬
нений. Вся нужная информация может быть получена.из документации
технического проекта.
Процедура завершается сопоставлением полученных результатов с
требуемыми значениями параметров. После этого либо корректируется
проект системы, а значит, и заново выполняется полный цикл техниче¬
ского контроля, либо пересматриваются целевые установки создания
ИС. Консультации с пользователями и службами технического планиро¬
вания и эксплуатации могут показать, что к системе предъявлены неоп¬
равданно жесткие требования. Отметим, что любое изменение целевых
установок возможно лишь по согласованию со всеми заинтересованны¬
ми подразделениями. Для уточнения результатов расчета объемно-вре-,
менных характеристик программ проводятся стендовые испытания си¬
стемы, или она сдается в опытную эксплуатацию. Дополнительную ин¬
формацию можно получить у разработчиков или поставщиков ЭВМ и
программного обеспечения.
Цикл ТКП повторяется до тех пор, пока не будет установлено, что
заданные ограничения на объемно-временные характеристики системы
выдержаны, или (реже) до принятия решения о прекращении разработ¬
ки из-за невозможности обеспечить требуемые характеристики системы.
16.3.	Контрольный бланк
Для записи результатов технического контроля проекта использует¬
ся так называемый контрольный бланк, форма которого приведена на
рис. 16.2. В этот бланк достаточно просто внести все необходимые из¬
менения и уточнения.
Результаты технического
контроля проекта
Лист из листов
Функция
Затраты времени
описа¬
ние
вспомо¬
гатель¬
ная
функция
число
обраще¬
ний
на работу центрального
процессора
на
ввод-
вывод
общие
для при¬
кладных
программ
ДЛЯ
СУБД и
теле¬
монитора
Для
ОС
всего
1 2
3 | 4
5
6
7
8
9
Рис. 16.2. Контрольный бланк для записи результатов технического контроля проекта
Расчеты могут выполняться с различной степенью детализации. Вна¬
чале заполняются бланки, соответствующие наибольшей степени дета¬
лизации. На их основе выполняются расчеты для следующего уровня
и т. д. Пример последовательности выполнения расчетов приведен на
рис. 16.3. Важно, чтобы уровни обобщения соответствовали параметрам,
характеризующим «качество» проектных решений.
2 38

Контрольный бланк, подобно другим видам документации, должен
соответствующим образом проверяться и централизованно храниться.
Порядок его заполнения объясняется на примере, приведенном в
разд. 16.5. Здесь же мы остановимся лишь на некоторых деталях. Если
на данном уровне рассмотрения системы невозможно контролировать
время работы центрального процессора или это было сделано на более
низком уровне, заполняется графа 7. В графе 5 указывается время про-
1. Доступ к магнитным дискам
2. Операции ввода-вывода, инициируемые СУБД (одна операция логического досту¬
па к базе данных требует нескольких обращений к диску)
3. Работа программы
4. Передача сообщений в системах телеобработки
5. Функционирование	подсистемы в течение суток
6. Функционирование	системы	в	течение	суток
7. Функционирование	системы	в	течение	недели
8. Функционирование	системы	в	течение	месяца
Рис. 16.3. Последовательность объектов рассмотрения при расчете временных харак¬
теристик
цессора, затрачиваемое СУБД или телемонитором, а в графе 6 — опера¬
ционной системой. В графе 8 отмечается время, требуемое для обраще¬
ния к внешним запоминающим устройствам при выполнении данной
функции.
16.4,	Выполнение расчетов
Рассмотрим пример расчета времени доступа к магнитному диску.
Временные характеристики периферийного оборудования существенно
влияют на скорость обработки данных, поэтому расчеты нужно выпол¬
нять с особой тщательностью.
Расчет проводится по формуле
где Т — время доступа; S — время перемещения головок; / — время ожи¬
дания требуемой записи; t{— время передачи данных при считывании
или записи; t2— время факультативной повторной передачи данных
(запись измененного блока или контрольное считывание).
Составляющая S изменяется от нуля до значения времени, необхо¬
димого для перемещения головок через все цилиндры, а / соответствует
времени ожидания «подвода» требуемой записи к головкам. Его значе¬
ние равно времени полного оборота диска.
Время передачи данных /i обратно пропорционально числу блоков
на дорожке и прямо пропорционально /тах. Время повторной передачи
t2 учитывается только при корректировке или контрольном считывании
записей. Поскольку в этих случаях должна быть передана та же самая
ЗапИСЬ, Принимается, ЧТО t2—lmax>
В отдельных строках бланка могут указываться результаты вычис¬
лений для различных видов доступа (чтение — среднее значение, чтение
на том же цилиндре и т. д.). Далее заполняется строка для каждой со¬
ставляющей времени доступа (перемещение головок, ожидание и т. д.).
В графе «Время работы центрального процессора» указываются два
значения: соответствующее работе операционной системы и суммарное.
239

Значение, указанное в графе «Общее время», соответствует интеграль¬
ной временной характеристике рассматриваемого вида доступа.
На рис. 16.4 показан заполненный бланк ТКП для операций доступа
к дисковым устройствам фирмы IBM. Отметим, что здесь приведены
результаты расчетов, а не реальные характеристики. При проектирова¬
нии ИС нужно стремиться проводить подобные расчеты на основе наи-
РЕЗУЛЬТАТЫ ТЕХНИЧЕСКОГО КОНТРОЛЯ ПРОЕКТА Компонент ИС: Доступ
к запоминающим уст¬
ройствам фирмы IBM
функция
Оценки затрат времени,мс
Наименование
Подфункция
Число обращений
Время работы цент¬
рального процессора
Время обращения к
внешним устрой¬
ствам
Общее время _
для приклад¬
ных прог¬
рамм
для СУБД и
телемонитора
для ОС
суммарное
1. Метод доступа
Выполнение программ
10
10
10
BDAM (чтение и
Поиск записи
30
30
запись)
Ожидание
8
8
Передача данных
2
2
Итого
10
,
40
50
2. Метод доступа
Выполнение программ
15
15
15
VSAM (чтение)
Обращение к дискам
40
40
Итого
15
40
55
3. Метод доступа
Выполнение- программ
15
15
15
VSAM (повторная
Обращение к дискам
запись)
(без поиска)
Ожидание
8
8
Передача данных
2
2
Итого
15
15
10
25
4. Последовательный
5
5
8
13
метод доступа
. (магнитные лен¬
ты)
Рис. 16.4. Результаты оценки доступа к запоминающим устройствам фирмы IBM
более точных исходных данных. Аналогичным образом можно получить
оценки минимального и максимального времени доступа, а также про¬
чие временные характеристики оборудования. При подготовке отчетов,
в которых обобщаются расчетные данные, нужно следить за тем, чтобы
вычисление итогов выполнялось корректно.
16.5.	Пример расчета временных характеристик для СУБД
Рассмотрим пример расчета времени выполнения некоторой транзак¬
ции в среде СУБД ADABAS, функционирующей на ЭВМ IBM 370/145.
Расчет проводится при следующих предположениях:
1.	Индексы верхнего уровня размещаются в оперативной памяти
(в буферном пуле системы ADABAS), поэтому при обращении к индек¬
су физический доступ к внешней памяти осуществляется только для
двух нижних уровней.
240

2.	При каждом обращении к блоку данных или индекса выполня¬
ется операция ввода-вывода. Другими словами, предполагается, что
аналогичный транзакции выполняются не слишком часто и блок, поме¬
щенный в буферный пул, при следующем запросе должен быть считан
из внешней памяти заново.
РЕЗУЛЬТАТЫ ТЕХНИЧЕСКОГО КОНТРОЛЯ ПРОЕКТА Компонент ИС:	Тран¬
закция «Пополнение
реестра»
ФУНКЦИЯ	Оценки	затрат	времени,мс
Наименование
Подфункция
Число обращений
Время работы цент¬
рального процессора
Время обращения к
внешним устрой¬
ствам
к
€
LX
о
си
3"
о
с
для приклад¬
ных прог¬
рамм
для СУБД и
телемонитора
ДЛИ ОС
суммарное
ПОПОЛНЕНИЕ
РЕЕСТРА
1. Поиск кода
Функция FIND
СУБД
10
180
200
380
800
1180
Чтение индекса
2. Поиск записи рее¬
стра
То же
1
18
20
38
80
118
3. Внесение записи в
Добавление записи
0,98
157
39
196
157
353
реестр
Расширение ассоциа¬
тора (до 10 значе¬
ний)
ИТОГО
1651
Рис. 16.5. Результаты оценки времени выполнения транзакции в среде СУБД ADABAS
3.	При .работе программ корректировки базы данных производится
вывод образов записей до и после изменения как в оперативную па¬
мять, так и в системный журнал. Соответствующие операции ввода-вы¬
вода учитываются при рассмотрении процедур ведения журнала.
На рис. 16.5 приведен бланк ТКП для рассматриваемого примера.
Вероятность выполнения операции «Пополнить реестр» равна 0,98, по¬
скольку при предшествующей обработке могли возникнуть ошибки. Зна¬
чения времени, указанные в графах бланка, получаются путем умноже¬
ния времени, затрачиваемого на выполнение «элементарной» операции,
на число ее выполнений.
16.6.	Автоматизация расчетов
Приведенные в настоящей главе примеры показывают, что выполне¬
ние расчетов может на практике оказаться достаточно трудоемким де¬
лом. Поэтому целесообразно воспользоваться для вычислений ЭВМ, в
частности, несложной программной системой на микрокомпьютере.
Один из пакетов прикладных программ для проведения расчетов по
методикам ТКП разработан фирмой BIS Applied Systems Ltd. При ис¬
пользовании этого пакета программ характеристики системы рассмат¬
241

риваются в порядке, указанном на рис. 16.3. Реальное время выполне¬
ния операций независимо от числа обращений к отдельным функциям
учитывается только на самом детальном уровне вычислений.
Пакет программ обеспечивает автоматическое подведение итогов
для любого числа уровней. На каждом уровне детализации это позво¬
ляет исследовать распределение нагрузки на ЭВМ по отдельным ком¬
понентам. Например, для системы реального времени можно показать
распределение затрат времени на работу центрального процессора по
транзакциям во время пиковой нагрузки. Пример отчета, который мо¬
жет быть подготовлен таким пакетом программ, приведен на рис. 16.6.
ППП ДЛЯ РАСЧЕТОВ ПО МЕТОДИКАМ ТКП
РАСПЕЧАТКА ФАЙЛА ТКПДАН 2
ВЕРСИЯ 2.0
26.01.81
ЧИСЛО
ВРЕМЯ НА
ОБЩЕЕ
КОЭФФ.
ОПЕРАЦИЙ
ОДНУ ОПЕ¬
РАЦИЮ
ВРЕМЯ
НАГРУЗКИ
ДЕНЬ ПИКОВОЙ НА¬
ГРУЗКИ
1,00
498 500,00
498 500,00
1000
УТРО
1,00
232 500,00
232 500,00
466
СЕРЕДИНА ДНЯ
1,00
266 000,00
266 000,00
534
УЧЕТ ЗАПАСОВ
500,00
25,00
12 500,00
25
ЗАКАЗ
1 800,00
220,00
396 000,00
794
ПОСТАВКА
1 800,00
50,00
90 000,00
181
Рис. 16.6. Пример отчета, подготовленного пакетом программ для расчетов по мето¬
дикам ТКП
Коэффициент нагрузки наглядно отражает вклад каждой операции
в общий расход времени ЭВМ и ее чувствительность к изменению объ¬
ема обрабатываемых данных. Для самых «чувствительных» операций
можно выполнить более точные расчеты.
С помощью отчетов, подготавливаемых пакетом программ, можно
определить, какие компоненты системы оказывают наибольшее влияние
на объемно-временные характеристики. (Для этих компонентов, воз¬
можно, имеет смысл пересмотреть проектные решения и обеспечить тем
самым существенное повышение суммарной производительности систе¬
мы.) Внеся необходимые изменения в модель системы и выполнив за¬
ново вычисления, можно быстро оценить последствия таких изменений.
Если расчеты ведутся вручную, придется изменить лишь несколько
бланков, но объем вычислений окажется весьма*значительным. При на¬
личии же соответствующих программных средств достаточно изменить
буквально несколько строк в спецификации модели и все результаты
будут получены автоматически. Это существенно снижает вероятность
появления ошибок, и самое главное, — позволяет разработчику сосредо¬
точиться на спецификации системы, не отвлекаясь на проведение вычис¬
лений.
16.7.	Заключение
Методы ТКП позволяют прогнозировать операционные характери¬
стики разрабатываемой системы с помощью формализованных про¬
цедур и выделять те компоненты, от которых в наибольшей степени зави-
242

сит ее суммарная производительность. Несмотря на то что прогнозиру¬
емые и реальные характеристики в действительности могут отличаться
(из-за неправильного учета влияния на них объемов обрабатываемых
данных, внедрения новых версий программного обеспечения, воздейст¬
вия работающих параллельно систем и т. д.), основное достоинство ме¬
тодов ТКП состоит в том, что уже на ранних стадиях проекта удается
выявить симптомы возможного ухудшения характеристик системы и
своевременно принять меры по исключению таких нежелательных эф¬
фектов.
Далее, технический контроль проекта ИС дает возможность прове¬
рить в процессе проектирования реализуемость целевых установок,
сформулированных пользователями и при необходимости скорректиро¬
вать проект еще до начала программирования. Если этого не сделать
вовремя, то оценить реальные характеристики системы можно будет
только уже на стадии ее испытаний. Но на этапе проектирования еще
можно пересмотреть требования пользователей и в крайнем случае при¬
нять решение об использовании более мощных технических средств.
Для проведения эффективного технического контроля проекта в пла¬
не разработки ИС следует предусмотреть выполнение всех необходимых
расчетов. Как отмечалось выше, решение этой задачи существенно об¬
легчается применением специальных программных средств. Однако в
любом случае нужно отдавать себе отчет в том, что все дополнительные
затраты, связанные с проведением технического контроля проекта, пол¬
ностью окупаются лишь при достаточно раннем обнаружении ошибок и
погрешностей в проектных решениях.
Глава 17
Периодический контроль проектных решений
17.1.	Введение
В настоящей главе рассматривается структурный метод периодиче¬
ского контроля результатов \ получаемых в процессе проектирования
ИС. Главная цель такого контроля — как можно раньше обнаружить и
устранить любые ошибки и неточности в проекте, чтобы они не созда¬
вали проблем на последующих этапах разработки.
Контрольные проверки выполняются специальной группой, в кото¬
рую включается несколько разработчиков, что не только упрощает об¬
наружение ошибок, но и позволяет сформировать более целостное пред¬
ставление о системе и повысить квалификацию участников проекта. От¬
метим, что не следует пытаться применять этот метод для формальной
оценки работы проектной группы.
Поскольку контроль проектных решений связан с определенными за¬
тратами времени и требует выделения дополнительных ресурсов, он
должен быть эффективным. Только тогда будет обеспечено высокое ка¬
чество разрабатываемой системы.
1 Авторы называют этот метод «структурным просмотром» (structured walkth¬
rough) . — Примеч. пер.
243

17.2. Время проведения контрольных проверок
Время проведения контрольных проверок не может быть жестко рег¬
ламентировано, так как в значительной степени зависит от характери¬
стик системы, состава контрольной группы и этапа проектирования. Тем
не менее можно выделить несколько точек в жизненном цикле системы
(обычно они совпадают с завершением основных этапов проектирова¬
ния), когда целесообразно оценить результаты выполненной работы. На
рис. 17.1 приведена таблица, отражающая примерный порядок согласо¬
вания и утверждения проектных решений.
В процессе составления основных проектных документов их конт¬
роль осуществляется самими разработчиками. Каждый самостоятельный
раздел документации проверяется сразу по завершении работы над
ним. Рекомендации по составлению и проверке проектной документа¬
ции на различных этапах разработки ИС приводились в соответствую¬
щих главах книги.
17.3.	Подготовка к проверке
Состав контрольной группы определяется руководителем коллектива
разработчиков системы в зависимости от вида проверяемой документа¬
ции и этапа разработки. В общем случае целесообразно включать в
контрольную группу специалистов, знакомых с требованиями, предъ¬
являемыми к проверяемому участку работы, занятых в смежных рабо¬
тах на данном этапе проектирования, а также тех, кому предстоит про¬
должить работу на следующем этапе.
Необходимо определить сроки начала и завершения проверки. Обыч¬
но это не вызывает затруднений, так как к проверке результатов чаще
всего приступают сразу по окончании той или иной работы. Офици¬
альное утверждение сроков завершения проверки помогает реализовать
все запланированные мероприятия.
Заседание контрольной группы должно продолжаться не более од¬
ного часа. Заседания длительностью свыше двух часов, как правило,
непродуктивны. Если ответственный за выполнение проверки полагает,
что рассмотрение материалов займет больше часа, он должен инфор¬
мировать руководителя проектной группы о необходимости проведения
промежуточной, проверки.
Материалы, подлежащие проверке, рассылаются членам контроль¬
ной группы за несколько дней до заседания. Члены контрольной груп¬
пы должны внимательно изучить их и отметить все обнаруженные
ошибки и неточности, которые необходимо устранить в результате про¬
верки. Детальное ознакомление с документацией позволяет ускорить
проведение проверки.
Если к проверке привлекаются рядовые сотрудники, желательно, что¬
бы руководитель проекта или ответственный за выполнение проверки
сделал перед заседанием краткое сообщение о содержании рассматри¬
ваемой работы и ответил на вопросы. Обычно такие сообщения требу¬
ются лишь перед несколькими первыми заседаниями и могут рассмат¬
риваться как своеобразная форма повышения квалификации сотрудни¬
ков. Менее опытные специалисты, как правило, избегают задавать воп¬
росы своим руководителям в ходе официальных заседаний. Однако
нередко именно их вопросы заставляют взглянуть на проблему по-ново¬
му, поэтому очень важно привлечь к дискуссии всех участников про¬
верки.
244

1ЧИЭ1ЭИЭ
ишиаеес! о хэыо
ВИЗ
СОГЛ
ВИЗ
ВИЗ
ОЗН
ОЗН
1<ШЭ1ЭИЭ
ииеивэс! о i3h.LQ
СОГЛ
СОГЛ
СОГЛ
виз
СОГЛ
СОГЛ
СОГЛ
ОНГЭ1ВН
-oeqirou ии^мМюнц
ОЗН
СОГЛ
ОЗН
ОЗН
ОЗН
ОЗН
Biroieaoeqirou
Kirtr oaiotfoeoMAd
ОЗН
СОГЛ
ОЗН
ОЗН
ОЗН
ОЗН
BdoxBdauo
Kirff oaiotfoaonAd
ОЗН
ОЗН
СОГЛ
ОЗН
BHH3dtT3Ha HBiry
СОГЛ
СОГЛ
виз
виз
СОГЛ
ОЗН
ИИНВ11ЧПЭИ BM
-HVoiaw и BwwBdj'odu
СОГЛ
виз
СОГЛ
виз
hhTibxbAbu
-оме on HHtiHAdioHH
СОГЛ
iqw^Bdjodu хэмэх
СОГЛ
Bdawndu ojoh
-qirodiHOM эинвэиио
СОГЛ
wwwBdj
-odu ки’пвнифи'пзпз
СОГЛ
КИП
-ВМИфиЛзЫЭ KBHlM90dU
ОЗН
виз
СОГЛ
ПИЭ1ЭИЗ ки'пвмифи'пэиэ
виз
СОГЛ
виз
виз
СОГЛ
СОГЛ
BaiDt/oaoMAd bitV хэыо
виз
СОГЛ
виз
виз
ОЗН
СОГЛ
BiMaodu
HIDOW9XeHITB9d О 19hlO
виз
СОГЛ
виз
виз
ОЗН
СОГЛ
КИНЭЖ01Г0П Э1ЯННОНЭО
виз
виз
виз
ОЗН
о»
s
>>
о
Cf
Должностное ли¬
цо
Руководитель
подразделения
пользователей
Руководитель
группы пользова¬
телей
Руководитель вы¬
числительного
центра
Руководитель
проектной группы
Руководитель
группы эксплуата¬
ции
Ревизор
Руководитель
проекта ИС
245
Рис. 17.1. Порядок согласования и утверждения проектной документации
ВИЗ—утверждающая виза, СОГЛ — согласующая виза, ОЗН— ознакомление с документом

17.4. Распределение обязанностей между членами контрольной группы
Основные обязанности по выполнению контрольных проверок рас¬
пределяются между тремя членами группы. Руководитель группы обыч¬
но ведет заседание. Он должен добиваться от всех членов группы кон¬
центрации внимания на поставленных задачах и предотвращать ненуж¬
ные дискуссии.
Секретарь фиксирует все исправления, которые должны быть вне¬
сены в проект по окончании проверки и составляет список необходимых
изменений (рис. 17.2). Докладчик доводит до сведения участников со¬
вещания содержание всех рассматриваемых документов.
Система: Бронирование мест в отелях
Дата 30.06.81
Проверяемая документация:
Блоки описания процессов обработки данных об оте¬
лях
Автор:
Джилл
Члены контрольной группы: Джилл, Ричард, Джон, Дэйв
Необходимые изменения
Кто
выполняет
Срок
1.	В файл «Отель» следует включить запись об изме¬
нении предоставляемых услуг
2.	Для обработки вышеупомянутой записи должна быть
разработана специальная программа
3.	Если в отеле имеется плавательный бассейн, нужно
произвести корректировку главного индексного фай¬
ла
Ричард
Дэйв
Джилл
08.07.81
12.07.81
02.07.81
Рис. 17.2. Список необходимых изменений
Руководителем группы обычно назначается старший по должности:
ему проще организовать работу членов группы и провести проверку в
сжатые сроки. Однако будет неплохо, если и другие сотрудники «попро¬
буют» себя в этой роли.
Докладывает на заседании обычно ответственный за выполнение
проверки, но в принципе в этой роли может выступить любой член кон¬
трольной группы. Перспектива неожиданно оказаться докладчиком по¬
будит всех заранее ознакомиться с имеющимися материалами. Кроме
того, ответственному за выполнение проверки труднее обнаружить в со¬
общении ошибки, чем «нейтральному» лицу, поскольку первый невольно
старается оправдать свои действия и решения. Обычно дискуссия про¬
ходит более плодотворно, если результаты проверки представляет не
сам исполнитель, а другой участник проекта.
17.5.	Порядок проведения заседания
Распределив обязанности, члены контрольной группы переходят к
рассмотрению вопросов, возникших при предварительном ознакомлении
с материалами. Пояснения дает ответственный за выполнение проверки.
246

В тех случаях, когда выявляются принципиальные ошибки, требующие
переработки почти всей документации, проверка переносится на более
поздний срок.
Докладчик делает сообщение о результатах проверки и по ходу об¬
суждения отвечает на вопросы. Незначительные ошибки исправляются
сразу же, а корректировки, требующие дополнительной проверки и при¬
нятия решений, вносятся в список необходимых изменений.
17.6.	Контрольные списки
Хотя в ходе проверки последовательно просматривается вся имею¬
щаяся документация, нередко удается обнаружить лишь явные ошибки
и нечеткие формулировки, а пропуски каких-то деталей могут остаться
незамеченными. Так как чаще всего разработчики опускают примерно
одни и те же сведения, для проведения проверки можно воспользоваться
заранее разработанными контрольными списками. В системе Modus
такие списки предлагаются для каждого этапа проектирования, ИС.
Пример контрольного списка для проверки разработанных профилей
транзакций приведен на рис. 17.3.
Контрольный список вопросов для проверки профилей транзакций:
1. Составлен ли профиль транзакции для каждого потока входящих данных?
2. Ко всем ли процессам происходит обращение?
3. Правильно ли специфицирована логика процессов?
4. Не содержит ли ошибок последовательность выполнения процессов?
5. Составлены ли спецификации данных, обрабатываемых каждым процессом?
6. Нет ли противоречий в именах файлов и элементов данных?
7. Правильно ли проведены на схемах тактовые линии?
8. Нет ли каких-то зависимостей между компонентами системы, не описанных в до¬
кументации?
9. Обеспечена ли подготовка всех видов выходных данных?
Рис. 17.3. Пример контрольного списка вопросов для проверки проектных решений
Наличие контрольных списков позволяет докладчику предваритель¬
но оценить результаты, о которых он собирается сделать сообщение и
тем самым сократить время заседания.
При формировании контрольных списков следует учитывать наибо¬
лее распространенные ошибки, возникающие в процессе разработки ИС.
Для этого нужно периодически просматривать составленные в ходе
проверок списки изменений. Чем раньше удастся обнаружить ошибки,
тем больше времени можно будет сэкономить на последующих этапах
проекта ИС. На рис. 17.4 показано, как формируется контрольный спи¬
сок с помощью списков необходимых изменений, составленных на этапе
проектирования системы. Поскольку ошибки могут быть обусловлены
неправильными действиями разработчиков не только на рассматривае¬
мой, но и на предыдущих стадиях проекта, списки необходимых изме¬
нений следует изучать с особой тщательностью.
247

ВОПРОСЫ
ДЛЯ АНАЛИЗА
ЛОГИЧЕСКОГО
ПРОЕКТА
КРИТИЧЕСКИЙ
АНАЛИЗ
ЛОГИЧЕСКОГО
ПРОЕКТА
Ч
\
ч
А.
\
НЕОБХОДИМЫЕ
ДЕЙСТВИЯ
\
ВОПРОСЫ
ДЛЯ АНАЛИЗА
ТЕХНИЧЕСКОГО
ПРОЕКТА
\
КРИТИЧЕСКИЙ
АНАЛИЗ
ТЕХНИЧЕСКОГО
ПРОЕКТА
\
\
/
\
А
А
/
НЕОБХОДИМЫЕ
ДЕЙСТВИЯ
ВОПРОСЫ
ДЛЯ АНАЛИЗА
ДЕТАЛЬНОГО
ПРОЕКТА
КРИТИЧЕСКИЙ
АНАЛИЗ
ДЕТАЛЬНОГО
ПРОЕКТА
НЕОБХОДИМЫЕ
ДЕЙСТВИЯ
Рис. 17.4. Необходимые изменения и контрольные списки вопросов для анализа про¬
ектных решений.
17.7.	Эффективность контроля
Для того чтобы контроль был эффективным, каждый член группы
должен заблаговременно изучить проверяемую документацию и актив¬
но участвовать в ее обсуждении. Не так просто добиться того, чтобы
разработчики, целиком поглощенные решением собственных проблем,
уделяли достаточное внимание изучению результатов, полученных кол¬
легами. Не менее важно заручиться поддержкой руководителя проекта
и выделить необходимое время на проведение проверок. Рассмотрим
некоторые факторы, способствующие повышению эффективности конт¬
роля проектных решений.
Планирование. Как отмечалось выше, контроль проектных решений
нужно предусмотреть при планировании основных проектных работ.
Желательно уже на этой стадии определить состав контрольных групп.
Не следует назначать заседания контрольных групп на вторую половину
пятницы, так как тогда может создаться впечатление, что проверка
проектных решений — дело второстепенное. Результаты проверки луч¬
ше всего обсуждать в начале рабочего дня, пока участвующие в об¬
суждении еще не переключились на собственные проблемы. Не реко¬
мендуется также отступать от утвержденного графика проведения про¬
верок (даже по настоятельной просьбе кого-либо из членов контрольной
группы).
248

Состав контрольной группы. Общие рекомендации по формированию
контрольной группы были даны выше. Напомним, что в группу должны
быть включены специалисты, хорошо знающие требования, предъявля¬
емые к проверяемому участку работ и способные оперативно провести
техническую экспертизу проектных решений.
В обсуждении результатов проверки должны принимать участие не
более пяти специалистов, так как иначе дискуссия может приобрести
слишком общий характер, но и не менее трех, чтобы принимать прин¬
ципиальные решения.
Создание микроклимата в коллективе. Авторитетное мнение безус¬
ловно имеет большое значение, но стоит выслушать и тех, кто его не
разделяет. Все члены контрольной группы должны иметь право голо¬
са— ведь ошибаться может даже умудренный опытом специалист. Обя¬
зательно следует поддерживать молодых специалистов. Руководитель
группы должен создать в коллективе атмосферу сотрудничества и до¬
биться от каждого максимальной отдачи.
Качество документации. Основное требование, предъявляемое к до¬
кументации,— точность и ясность. Если при ознакомлении с материа¬
лами приходится обращаться к дополнительным источникам или
другим документам, работа замедляется минимум в два раза. Целесо¬
образно представить всем членам контрольной группы копии рассматри¬
ваемых документов, чтобы они могли делать на них свои пометки. Од¬
нако не все организации располагают необходимой для этого множи¬
тельной техникой. При отсутствии достаточного числа копий пометки
могут быть сделаны просто на отдельных листах бумаги. Все замеча¬
ния должны быть высказаны в ходе заседания.
Документация, подлежащая проверке, должна храниться централи¬
зованно. При необходимости она может выдаваться на определенный
срок членам контрольной группы.
Место проведения заседаний. Желательно проводить заседание кон¬
трольной группы в отдельном помещении, чтобы не мешать остальным
сотрудникам заниматься своим делом и предоставить членам группы
возможность свободно высказать свое мнение.
Список необходимых изменений. Как отмечалось выше, в данный
документ включаются все изменения, которые необходимо выполнить
после проверки проектных решений. Если по какому-то вопросу возник¬
ла длительная дискуссия, целесообразно зафиксировать все поступив¬
шие предложения, даже если члены контрольной группы пришли в кон¬
це концов к единому мнению. Это позволит сэкономить время при
повторном обсуждении вопроса.
После окончания проверки руководитель контрольной группы перио¬
дически просматривает списки необходимых изменений и следит за их
реализацией.
17.8.	Заключение
Придерживаясь изложенных выше рекомендаций, можно повысить
эффективность контроля проектных решений. Производительность тру¬
да разработчиков возрастает, если ошибки и неточности выявляются
на ранних стадиях проекта. Разработчики, участвующие в проверке, по¬
лучают более полное представление о системе и глубже понимают по¬
ставленную перед ними задачу. Это помогает им избежать многих оши¬
бок. В конечном счете все затраты, связанные с проведением проверки
проектных решений, полностью окупаются.
249

Глава 18
Управление проектом
18Л. Введение
Одним из важнейших аспектов реализации ИС является планирова¬
ние и управление ее разработкой и внедрением. Решить эти задачи не
просто, но совершенно необходимо: соблюдение плановых сроков и сме¬
ты во многом определяет взаимоотношения подразделений организации
и отдела информационных систем. Гораздо выгоднее сразу начинать
работать по реалистичному плану, чем постоянно обращаться к заказ¬
чику с просьбой о переносе сроков и выделении дополнительных ре¬
сурсов.
В управлении проектом ИС можно выделить три основные задачи:
планирование, контроль за выполнением плана работ и оценку затрат
и результатов. Управление проектом предполагает также внедрение,
унификацию и стандартизацию прогрессивных методик и инструмен¬
тальных средств разработки ИС. При необходимости планы должны
своевременно корректироваться. Сама система управления проектом не
должна быть сложной. Обработка слишком большого объема отчетных
данных не вызывает энтузиазма у группы управления проектом, что
может свести на нет все предпринимаемые в этом направлении усилия.
Целесообразнее применять простую неавтоматизированную процедуру,
обеспечивающую накопление итогов и позволяющую представить тре¬
буемую информацию руководителям всех рангов.
На рис. 18.1 приведена схема основных функций, реализуемых в
процессе управления проектом. В настоящей главе рассматривается не¬
автоматизированная процедура управления поэтапной разработкой ИС.
Эту процедуру нетрудно модифицировать с учетом имеющихся в орга¬
низации средств автоматизации управления разработкой. Решение
большинства задач, предусмотренных предлагаемой здесь процедурой
не требует наличия каких-либо специальных знаний и может быть воз¬
ложено на «библиотекаря» проекта или технических специалистов. Рас¬
четы должны выполняться квалифицированным персоналом, Все члены
проектной группы еженедельно заполняют бланки учета времени, за¬
траченного на выполнение тех или иных проектных работ.
В конце каждого этапа разработки затраты сопоставляются с полу¬
ченными результатами. При этом учитываются объем невыполненных
работ и достигнутая производительность труда. Для этапа, непосредст¬
венно следующего за завершенным, выполняются точные расчеты, а для
всех остальных — приближенные. На основе этих оценок администрация
подразделений-пользователей получает представление о ходе разработ¬
ки ИС и может формировать собственные планы, а руководство проект¬
ной группы принимает решение о выделении ресурсов, сроках начала и
завершения работ и т. д. для следующего этапа разработки.
Не менее важная функция, связанная с управлением проектом
ИС, — учет и оценка затрат на разработку. Здесь речь идет о заработ¬
ной плате персонала, стоимости аренды машинного времени и оборудо¬
вания и т. д. Стоимостные оценки оборудования могут быть получены
по результатам учета времени, затрачиваемого на разработку: почасо¬
вая стоимость аренды оборудования умножается на соответствующий
интервал времени. Аналогично рассчитываются и фактические затраты
на текущую дату.
250

Чтобы определить расход ма¬
шинного времени, целесообразно
проанализировать загрузку ЭВМ.
Прочие расходы, как правило, вы¬
числяются по действующей в ор¬
ганизации системе расчетов.
Прежде чем приступить к реа¬
лизации системы управления про¬
ектом, необходимо выяснить, ка¬
кого рода информация требуется
руководству и как часто она
должна предоставляться. В зави¬
симости от сложности проекта
устанавливается необходимое чи¬
сло уровней управления. После
этого можно перейти к планиро¬
ванию проекта системы.
18.2,	Поэтапное планирование
В начале проекта и по завер¬
шении каждого его этапа выпол¬
няется планирование всех после¬
дующих этапов. По мере прибли¬
жения к очередному этапу план
предстоящих работ детализиру¬
ется (уточняется), а для всех по¬
следующих этапов он считается
ориентировочным. Такой план
составляется главным образом
с целью предварительного конт¬
роля сроков разработки и сметы
затрат.
Расчеты,, выполняемые при
формировании ориентировочного
плана, аналогичны расчетам при
точном планировании, но отлича¬
ются меньшей степенью детали¬
зации. В соответствующих доку¬
ментах указывается вид выпол¬
няемых работ, численность выде¬
ляемого на них персонала и пред¬
полагаемые сроки завершения
этих работ.
Оценки следует давать с неко¬
торым запасом (с учетом возмож¬
ности временной нетрудоспособ¬
ности исполнителей, праздников
и т. д.).
При составлении точного пла¬
на на основе ориентировочного
осуществляется декомпозиция за¬
дач на составляющие. Для каж¬
дой подзадачи определяется вре-
и
X
а.
251
18.1. Основные задачи, решаемые при управлении проектом ИС

мя, необходимое для ее выполнения, и требуемый штат специалистов.
Таким образом, ориентировочный план детализируется и уточняется.
С целью контроля могут применяться контрольные списки подзадач
(рис. 18.2).
Нормативы разработаны для «среднего» специалиста, поэтому при
планировании работы в конкретной ситуации может потребоваться не¬
которая корректировка этих показателей. В плане реализации следую¬
Этап: Проектирование системы
Задача (подзадача)
Разрабатываемые
документы
Нормативы
1. Исследование и струк¬
туризация спецификаций
системы
1.1.	Исследование специ¬
фикаций
1.2.	Анализ данных
1.3.	Определение входных
потоков данных
1.4.	Анализ связей между
элементами данных
1.5.	Документирование
процессов
1.6.	Анализ связей между
процессами и данными
1.7.	Определение ограни¬
чений и перспективных
потребностей
1.8.	Проверка специфика¬
ций
Рабочие материалы
Уточненные спецификации
Схемы структуры файлов
Перечень операций и вход¬
ных потоков данных
Описания данных
Бланки описания и пере¬
чень процессов
Таблица соответствия про¬
цессов и данных
Перечень ограничений и
перспективных потребно¬
стей
Полный комплект доку¬
ментации
1—5 дней на рассмотре¬
ние и уточнение
5—6 схем в день
1—2 дня
1—2 дня
0,5—1 день на процесс
1—3	дня
2—5	дней на консуль¬
тации с пользователями
и руководством службы
обработки данных
2—5 дней на работу
контрольной группы
Рис. 18.2. Контрольный список
задач, решаемых в начале
стемы.
этапа проектирования си-
щего этапа разработки предусматривается достаточное время для вы¬
полнения всех взаимосвязанных работ. Для каждого специалиста со¬
ставляется индивидуальный календарный план. Аналогичные докумен¬
ты составляются для всех операций, предусмотренных планом проекта.
По завершении выполнения операций необходимо заполнить соответст¬
вующие бланки для точного и ориентировочного планов.
18.3.	Контроль за выполнением плана
Уже с самого начала проектирования фактические сроки выполнения
отдельных работ еженедельно сопоставляются с плановыми. Для руко¬
водителей всех рангов подготавливаются отчеты с соответствующей
степенью детализации, что помогает своевременно выявить симптомы
срыва планов и принять надлежащие меры. Планирование и контроль
исполнения могут быть организованы по-разному: плановые сроки мо¬
гут жестко устанавливаться руководством либо определяться самим
исполнителем. Вне зависимости от схемы планирования, принятой в
данной организации, каждый исполнитель обязан периодически фикси¬
ровать время, затрачиваемое на выполнение той или иной работы, и
252

время, требуемое, по его мнению, на ее завершение. Эти сведения еже¬
недельно вносятся в специально разработанный бланк учета.
В конце каждой недели сведения, представленные исполнителями,
обобщаются в сводном отчете о ходе выполнения работ. Здесь указы¬
вается время, выделенное на решение данной задачи по плану, затра¬
ченное фактически и необходимое для завершения работы. Подготовка
этого отчета — чисто техническая операция и ее можно поручить даже
неквалифицированному персоналу. По запросу руководства могут фор¬
мироваться и другие отчеты. В них полезно указывать фактически за¬
траченное время в процентах от планового. Через несколько недель мо¬
жет обнаружиться отклонение от плана и тогда придется принять соот¬
ветствующие меры. Отдельные отчеты для руководства подготавлива¬
ются ежемесячно и ежеквартально.
Целесообразно вывесить график хода выполнения проекта на вид¬
ном месте, чтобы все участники разработки были всегда в курсе дела:
кто опережает сроки, а кто отстает.
Если в процессе разработки выяснится, что необходимо выполнить
какие-то дополнительные работы, это следует отразить в плане: либо
увеличить время, требуемое для завершения соответствующей работы,
либо предусмотреть сверхплановые операции. Второй путь предпочти¬
тельнее, за исключением тех случаев, когда подобные дополнения не-
значительн ы.
18.4.	Контроль разработки со стороны администрации
По завершении каждого этапа проекта ИС руководство организа¬
ции официально знакомится с состоянием работ, оценками затрат и ре¬
зультатов, сроками выполнения плановых заданий и принимает реше¬
ние о переходе к следующему этапу.
Для принятия такого решения необходим определенный набор доку¬
ментов, в которых обобщаются данные отчетности по проекту. Эти све¬
дения особенно важны на ранних стадиях разработки, до этапа проек¬
тирования включительно, когда оценки затрат на реализацию ИС и
результатов, ожидаемых от ее внедрения, претерпевают значительные
изменения по мере поступления все более точной информации о пред¬
метной области и технологической среде будущей системы.
Фактические и прогнозируемые данные регистрируются на стандарт¬
ных бланках. Выделяют три статьи расходов: по заработной плате, по
аренде ЭВМ и оборудования и прочие. В конце каждого этапа проекти¬
рования уточняются оценки эксплуатационных расходов по новой систе¬
ме, включая заработную плату персонала, стоимость ЭВМ, дополни¬
тельных технических средств, телекоммуникационного оборудования и
программного обеспечения, а также расходы по снабжению.
Не менее важно учитывать средства, которые могут быть сэконом¬
лены при внедрении системы. С этой целью затраты сопоставляются с
эксплуатационными расходами. Результаты оценки условной экономии
должны быть документально зафиксированы (на бланке учета услов¬
ной экономии).
Следует рассмотреть прямой и косвенный эффекты от внедрения си¬
стемы. Прямой эффект оценивается в стоимостном выражении, а для
оценки косвенного эффекта дается вербальное описание. Желательно
гакже дать оценку перспективного экономического эффекта, поскольку
эта информация потребуется руководству в процессе принятия решений.
Данные, полученные при расчете затрат и результатов, ожидаемых
253

при создании системы, обобщаются в итоговом отчете. Примеры расче¬
та затрат и результатов для проекта ИС рассматривались в гл. 2.
Для руководства организации готовится еще один отчет, отражаю¬
щий ход разработки ИС. В него включаются сроки завершения отдель¬
ных работ, оценки необходимых кадровых ресурсов и краткое описание
возникающих проблем.
Указанные выше документы могут составляться с применением уни¬
фицированных бланков. В процессе разработки эти документы изуча¬
ются вместе с отчетами и спецификациями руководством подразделе¬
ний пользователей. В результате принимается решение либо о перехо¬
де к следующему этапу, либо о продолжении работ по текущему этапу,
либо о «замораживании» проекта ИС.
18.5.	Преимущества реализации системы управления проектом
При реализации системы управления проектом ИС необходим соот¬
ветствующий план, утвержденный руководством организации. Этот
план, в частности, должен регламентировать содержание и частоту
представления отчетов, подготавливаемых для администрации. По. за¬
вершении отдельных этапов проекта фактические данные сопоставляют¬
ся с первоначальными оценками трудозатрат, требуемых ресурсов и т.д.
По мере приобретения опыта в проектировании систем методики расче¬
та показателей, характеризующих ход разработки, корректируются.
Необходимо следить за тем, чтобы при расчете фактических значений
этих показателей учитывались все влияющие на них факторы.
Большинство вопросов, возникающих в связи с управлением разра¬
боткой, удается решить с помощью структурных методов. Эти методы
позволяют осуществить декомпозицию сложных задач на ряд подзадач,
для которых может быть найдёно корректное решение.
Кроме того, применение методов управления проектом способству¬
ет повышению квалификации специалистов, занятых планированием
разработки ИС, а также более эффективному использованию выделяе¬
мых ресурсов. Эти методы помогают своевременно выявить проблемы,
затрудняющие или делающие невозможным дальнейшее проектирова¬
ние, и создают основу для проведения консультаций с руководством
подразделений-пользователей относительно программы работ, выделе¬
ния ресурсов и внедрения ИС.
В заключение остается лишь отметить, что при реализации методов
управления разработкой ИС предстоит еще выполнить необходимые
расчеты и подготовить отчеты для руководства. Использование унифи¬
цированных бланков, а возможно, и средств автоматизации соответст¬
вующих процедур упрощает решение этой задачи. Весьма желательно,
чтобы все участники проекта фиксировали затраты рабочего времени.
Применение типовых методик оценки и контроля за ходом разработки
способствует укреплению дисциплины всего коллектива.
254

Глоссарий
Access profile (Логический) Профиль доступа
Логическая последовательность доступа к типам данных, составляющих логическую
схему, для решения конкретной прикладной задачи. В профиле доступа указываются
также способы идентификации экземпляров данных в пределах их типов и ожидаемое
число операций доступа.
Access profiling Спецификация профилей доступа
Метод документирования операций доступа к данным в ИС, позволяющий устано¬
вить, что в логическую схему данных включены все необходимые типы данных и их
взаимосвязи.
Activity Операция
На ранних этапах проекта и при системном анализе — автоматизированный или
внемашинный процесс, для которого указывается назначение без детализации способа
реализации конкретных функций.
Activity diagram Операционная диаграмма
Схема, на которой изображены операции, внешние объекты, хранилища данных и
потоки данных. Каждая операция в свою очередь может быть представлена операцион¬
ной диаграммой более низкого уровня.
Activity diagramming Составление операционных диаграмм
Метод представления ИС с помощью операционных диаграмм.
Activity number Номер операции
Уникальный числовой идентификатор операции на операционной диаграмме. Отра¬
жает иерархическую подчиненность операций в системе.
Activity sheet Бланк описания операции
Бланк, используемый для спецификации логики операций самого нижнего уровня.
Activity summary Сводка операций
Иерархическая схема, на которой отражены связи между операциями, реализуемые
в системе. Здесь не указываются потоки и хранилища данных, а также внешние объ¬
екты.
Automation Boundary Граница автоматизации
Граница, разделяющая внемашинные и подлежащие реализации в ИС операции.
Bachman diagram Диаграмма Бахмана
Способ изображения логической структуры данных, предложенный Ч. Бахманом.
Аналогичная символика используется в настоящей книге.
Basic data structure Основные структуры данных
Различают три основные структуры: последовательные, иерархические с альтерна¬
тивными вариантами и иерархические с повторениями. Структура любого файла может
быть разложена на такие компоненты.
Bottom—up Метод проектирования «снизу вверх»
Порядок разработки системы, при котором вначале реализуются компоненты само¬
го нижнего уровня, затем компоненты более высокого уровня и т. д.
Boundary Граница
При проектировании систем граница разделяет либо уже исследованные и еще не
рассматривавшиеся, либо модифицированные и не изменявшиеся операции. Указывает¬
ся с помощью пересекающих ее потоков данных.
Business activity model Функциональная модель
Операционная диаграмма высокого уровня, отражающая функциональное содер¬
жание некоторой предметной области.
CAFS Непосредственная адресация записей файла по их содержанию
Разработка фирмы ICL, обеспечивающая аппаратную реализацию выборки записей
файла по значениям одного или нескольких элементов данных.
Calling module Вызывающий модуль
Модуль, который передает управление другому модулю.
Clump(ing) Группирование
Объединение информационных и функциональных компонентов системы в файлы
и программы, выполняемое на этапе технического проектирования.
Code reading Чтение текста программы
Подзадача разработки программы, выполняемая после успешной компиляции
сотрудником, не являющимся ее автором, с целью обнаружения ошибок в реализации
логики соответствующей процедуры и фрагментов программы, затрудняющих ее сопро¬
вождение.
Common module Общий модуль
Модуль, используемый многими компонентами в системе или в нескольких системах.
Common process Общий процесс
Процесс, который, как установлено в ходе системного анализа, выполняется более
чем з одной функциональной области. Такие процессы нередко реализуются в виде
общих модулей.
Context diagram Композиционная схема
255

Схема, изображающая систему на самом общем уровне представления при систем¬
ном анализе.
Control module Управляющий модуль
Главный модуль программы, который управляет процессом обработки данных.
Data administration Администрирование данных
Функции, включающие разработку общих определений данных, руководство техни¬
ческим проектированием файлов и баз данных и др., возложенные на одно или не¬
сколько подразделений организации.
Data analysis Анализ данных
Исследование структуры и способов доступа к данным, подлежащим хранению в
системе, и их описание.
Data definition form Бланк описания данных
Используется при системном анализе для спецификации входных, логических ос¬
новных и выходных файлов. Содержит детальные сведения о форматах, правилах про¬
верки достоверности значений и способах использования элементов данных в системе.
При техническом проектировании служит для спецификации форматов записей.
Data dictionary Словарь данных
Специализированное программное средство, обеспечивающее накопление и предо¬
ставление описаний таких логических компонентов системы, как хранилища и элементы
данных, а также программ и файлов. Предназначен для централизованного контроля
за описаниями компонентов системы и их взаимосвязей и за результатами изменений
описаний.
Data element, data item Элемент данных
Наименьший компонент структуры данных, характеризующихся значениями, кото¬
рые представляют интерес для пользователей ИС.
Data item dictionary Словарь элементов данных
Перечень элементов данных, где указаны типы данных, в которые эти элементы
входят.
Data name Имя данных
При программировании — имя переменной, с помощью которого ссылаются на зна¬
чения элемента данных.
Dataflow Поток данных
Поток данных осуществляет обмен данных между операциями, хранилищами дан¬
ных и внешними объектами.
Datastore Хранилище данных
Логическая совокупность данных, обработка которых происходит после накоп¬
ления.
Datatype Тип данных
Множество экземпляров записей, содержащих элементы данных, один или несколь¬
ко из которых составляют уникальный ключ для этого типа данных.
Datatype summary Перечень типов данных
Приложение к логической схеме данных, в которой для каждого типа данных при¬
ведены размер и число экземпляров, а также объем памяти, необходимый для хране-
' ния всех экземпляров.
Decision table Таблица решений
Метод для записи условий решений и действий, выполняемых в некоторой про¬
цедуре, в форме таблицы.
Decision tree Дерево решений
Формализованный графический метод для записи решений и действий в виде иерар¬
хического дерева.
Design language Псевдокод
Частично формализованный язык для спецификации логики программ, в котором
для выделения основных логических конструкций служат ключевые слова.
Design refinement Уточнение проекта
Задача, выполняемая при проектировании как систем, так и программ, в результа¬
те решения которой логический проект совершенствуется по определенным правилам
без коренной перестройки логики.
Detailed design Детальное проектирование
Заключительный этап проектирования системы, на котором формируются специфи¬
кации блоков контроля файлов, утилит, общих модулей и программ.
Detailed new system Детализация (проекта) новой системы
Основная задача на этапе системного анализа. Включает подробное описание опе¬
раций, хранилищ и потоков данных и знешних объектов, необходимых для удовлетво¬
рения требований к новой системе, а также описание интерфейсов между автоматизи¬
рованной системой и внемашинными процедурами.
Digital transmission Цифровая передача
Передача любого вида информации (речи, изображений и текстов) в цифровой
форме по обычным каналам связи.
256

Distributed processing Распределенная обработка
Решение прикладных задач в рамках некоторой системы на удаленных вычисли¬
тельных установках. Объектом распределения могут быть как данные, так и процессы
обработки.
Driving file Управляющий файл
Термин, иногда употребляемый в программировании для обозначения файла, струк¬
тура которого определяет логику программ. Как правило, каждая запись такого файла
подлежит обработке.
Electronic mail Электронная почта
Средства, обеспечивающие передачу сообщений в цифровой форме в соответствую¬
щие пункты назначения. Обычно реализуется функция «почтового ящика», обеспечи¬
вающая накопление и последующую доставку сообщений адресатам.
Enhanced file structure Усовершенствованная структура файла
Структура файла, подвергшаяся изменению с целью обеспечения более точного со¬
ответствия особенностям прикладной задачи, решаемой с помощью некоторой приклад¬
ной программы. Служит основой для разработки логики программы.
Entirely testing Полное тестирование
Метод испытания программ, содержащих единственный физический модуль. Все
логические модули, входящие в его состав, тестируются за одно выполнение про¬
граммы.
Entity Объект
При анализе данных — предмет, событие или факт, сведения о котором представ¬
ляют интерес для пользователей и должны храниться в системе.
External entity Внешний объект
Объект, лежащий за пределами системы и взаимодействующий с ней посредством
потоков данных или материальных объектов.
Fault log Протокол ошибок
Перечень ошибок, обнаруженных при тестировании системы, включающий описа¬
ние корректирующих действий и дату внесения исправлений.
File structure Структура файла
Логическая структура данных, содержащихся в файле, представленная в виде ком¬
бинации типовых компонентов: иерархической последовательной структуры, структуры
с альтернативными вариантами и структуры с повторениями. Физическая организация
файла при этом не принимается во внимание.
File structure analysis Анализ структуры файла
Иерархическая декомпозиция (содержания) файла на элементы данных, объеди¬
няемые в последовательные, повторяющиеся или содержащие альтернативные компо¬
ненты структуры данных.
Fiie structure diagram Схема структуры файла
Иерархическая схема структуры файла. Ее компонентами являются структуры
данных одного из трех основных типов.
First pass (physical) design Разработка первого проекта системы
Быстрое проектирование первой версии системы. Несмотря на возможную неэф¬
фективность, проектные решения будут по крайней мере удовлетворять ограничениям,
накладываемым имеющимися техническими и программными средствами.
Flow Поток
Передача данных от одного объекта к другому.
Flowchart Блок-схема
Способ графического представления логики процедуры с использованием опреде¬
ленного набора символов.
Foreign key «Чужой» ключ
Элемент данных, входящий в тип данных А и одновременно в состав ключа типа
данных В, является «чужим» ключом для типа данных А.
Function key Функциональная клавиша
Клавиша, нажатие которой на клавиатуре терминала приводит к выполнению за¬
программированной процедуры.
Isolation and linkage testing Раздельное тестирование и последующее редактиро¬
вание связей
Метод тестирования программ, при котором каждый физический модуль тестирует¬
ся автономно, после чего они совместно редактируются и выполняется проверка пра¬
вильности их взаимодействия.
Key Ключ
Один или несколько элементов данных, допустимые значения которых однозначно
идентифицируют экземпляры данных рассматриваемого типа.
Key performance factor (KPF) Ключевой фактор эффективности (КФЭ)
Направление или показатель деятельности организации, существенные с точки зре¬
ния достижения некоторой цели.
Key performance factor analysis Анализ ключевых факторов эффективности
257

Идентификация КФЭУ определение и детальное рассмотрение мер их оценки в про¬
цессе формирования целевых установок при создании ИС.
Link Связь
Логическая ассоциация между двумя типами данных, обусловленная наличием об¬
щего элемента данных.
Link table Таблица связей
Таблица, в которую включены сведения о связях между парами типов данных. Эта
таблица содержит примерно ту же информацию, что и логическая схема данных.
Logic design Проектирование логики
Подзадача этапа логического проектирования программ, в результате выполнения
которой для каждого логического модуля дается спецификация процедуры с использо¬
ванием трех основных логических конструкций.
Logic structure Логическая конструкция
При проектировании программ выделяются три основные логические конструкции:
следование, выбор и итерация, с помощью которых может быть представлена логика
любой процедуры.
Logical data association (LDA) Анализ логических связей данных
Метод, позволяющий определить связи между типами данных и сформировать ло¬
гическую схему данных, исходя из общего представления о предметной области.
Logical data design Логическая схема данных
Графическое представление типов данных, в котором прямоугольники соответству¬
ют типам данных, а стрелки — связям между ними.
Logical data structuring (LDS) Логическая структуризация данных
Метод формирования логической схемы данных на основе анализа содержания
хранилищ данных, определяемого в процессе нормализации отношений.
Logical design Логическое проектирование
Задача проектирования системы, в результате решения которой формируется логи¬
ческая информационная и функциональная модель системы.
Logical design chart Логическая диаграмма
Особый вид схемы, разрабатываемой при логическом проектировании системы, на
которой показаны процессы, обрабатываемые ими данные и временные тактовые линии.
Logical file structure Логическая структура файла
Взаимосвязь компонентов файла. При выделении этих компонентов принимаются
во внимание только логические связи данных и не учитываются особенности физической
реализации файла.
Logical master file Логический основной файл
Термин, который при логическом проектировании системы обозначает один из ти¬
пов данных в системе.
Logical message pair Пара логических сообщений
В диалоговой системе единица обмена оператора терминала и ЭВМ. Для типичной
прикладной транзакции может последовательно обрабатываться несколько пар логиче¬
ских сообщений.
Logical module Логический модуль
Фрагмент программы, реализующий одну функцию и имеющий по одной точке
входа и выхода. Спецификация модуля, как правило, размещается на одной странице.
Logical program design Логическое проектирование программы
Первый шаг при проектировании программы, заключающийся в ее разбиении на
ряд простых модулей.
Main-frame Большая ЭВМ
ЭВМ, производительность и программное обеспечение которой позволяют одновре¬
менно выполнять совокупность заданий, связанных с обработкой данных в пакетном
режиме, управлением базами данных и работой пользователей в сети ЭВМ.
Measures of performance Мера эффективности
Оценка степени достижения фактора эффективности.
Message pair Пара физических сообщений
Акт взаимодействия оператора терминала с диалоговой системой, например ввод
номера клиента и выдача на экран терминала сведений об этом клиенте. Пара физиче¬
ских сообщений может входить составной частью, непосредственно соответствовать
или включать несколько пар логических сообщений. Формат пары физических сообще¬
ний определяется на этапе технического проектирования и зависит от типа используе¬
мого терминала и телемонитора.
Module hierarchy chart Иерархическая схема модулей
Схема, на которой представлены связи логических модулей, входящих в состав
программы.
Module linkage Взаимодействие модулей
Передача данных между двумя модулями для обеспечения их взаимодействия.
Module stub Заглушка
Модуль, имитирующий работу вызываемого модуля при тестировании вызывающе -
258

го модуля по принципу «сверху вниз». Обычно содержит точку входа, инструкции для
печати входных параметров, инструкции возврата необходимых параметров и точку
выхода.
Module test checklist Контрольный список для тестирования модуля
Документ, в котором описаны все условия, подлежащие проверке при тестирова¬
нии данного логического модуля. Создается при планировании тестирования модулей
на этапе программирования.
Network Сеть
Совокупность коммуникационных средств, обслуживающих несколько удаленных
пунктов и обеспечивающих передачу сообщений между ними.
Optimum access Оптимальный метод доступа
Для каждого файла в системе — наиболее предпочтительный метод доступа со сто¬
роны каждого процесса.
Optimum access chart Схема оптимального доступа
Схема, на которой показаны оптимальные методы доступа к каждому файлу со
стороны каждого процесса в системе. Разрабатывается при техническом уточнении про¬
екта на стадии проектирования системы.
Outline new system Эскизный проект новой системы
Совокупность общих спецификаций операций, потоков и хранилищ данных, обра¬
зующих систему, без детализации внутренней структуры. Разрабатывается на этапе
системного анализа.
Outline test plan Общий план испытаний
Общий план работ по тестированию системы, в который включены оценки необхо¬
димых ресурсов и календарный график.
Packet switching Коммутация пакетов (сообщений)
Метод передачи сообщений, при котором сообщение разбивается на несколько
фрагментов фиксированной длины, которые «транспортируются» телекоммуникационной
сетью общего назначения, а после приема исходное сообщение «собирается», из этих
фрагментов и направляется адресату.
Partitioned data base Сегментированная база данных
База данных, спроектированная на основе единой логической схемы, но по сообра¬
жениям эффективности обработки разделенная на несколько физических баз данных.
Performance modelling Оценка операционных характеристик системы методом мо¬
делирования
Метод оценки объемно-временных характеристик проектируемой системы с помо¬
щью модели.
Performance target Требуемые операционные характеристики
Количественная оценка некоторой объемно-временной характеристики, которой
должна обладать создаваемая система. Например, может быть установлено, что пол¬
ный цикл обработки данных должен занимать не более четырех часов.
Phase Этап
Совокупность работ по проектированию и реализации системы, рассматриваемых
как единый комплекс, при управлении проектом и оценке полученных результатов.
Physical access profile Физический профиль доступа
Реальная последовательность физических операций ввода-вывода, необходимых для
реализации некоторого логического процесса или функции обработки данных.
Physical benchmark Измерение операционных характеристик с помощью эталон¬
ной программы
Метод измерения операционных характеристик системы или ЭВМ путем выполне¬
ния специально разработанной эталонной программы.
Physical design Техническое (физическое) проектирование
Подзадача проектирования системы, в результате решения которой логическая
модель системы модифицируется с учетом технических ограничений, накладываемых
имеющимися техническими и программными средствами.
Physical file structure Физическая структура файла
Структура файла, компонентами которой являются физические записи (блоки),
экстенты и т. д.
Physical module Физический модуль
Совокупность строк исходного текста программы, обрабатываемых компилятором
как единое целое. При редактировании связей несколько физических модулей могут
быть объединены в программу.
Physical module hierarchy chart Схема физических модулей
Схема, на которой представлены взаимосвязи всех физических модулей, входящих
в состав программы.
Physical process profile Профиль физического процесса
Профиль физического доступа, в который включены обрабатывающие компонен¬
ты, не связанные с доступом к файлам.
Physical program design Техническое проектирование программы
259

Задача, в результате решения которой спецификация логики программы реали¬
зуется на языке программирования с учетом ограничений, накладываемых имеющимися
техническими и программными средствами.
Physical response Время реакции (отклика)
Время, необходимое для обработки некоторой логической последовательности дей¬
ствий, например затрачиваемое на предоставление сведений о клиенте.
Pointer Указатель
Средства физической адресации записей для реализации их логических связей.
Process Процесс
На ранних этапах проектирования системы процесс соответствует определенной ло¬
гической последовательности действий, выполняемых в отношении некоторой группи¬
ровки данных: проверке достоверности значений, корректировке файла, генерации от¬
чета и т. д. Спецификация процесса обычно размещается на одном листе.
Process decomposition Декомпозиция процессов
Одна из первых задач по проектированию системы, при решении которой операции,
выявленные в результате системного анализа, разбиваются на более мелкие компо¬
ненты.
Process sheet Бланк описания процесса
Документ, разрабатываемый при проектировании системы, в котором указываются
функции, выполняемые процессом, а также входные, выходные и справочные данные.
Process sheet index Указатель бланков описания процесса
Указатель, включающий сведения обо всех процессах, определенных в системе: наи¬
менование, обрабатываемые данные, время выполнения и профили транзакций, в кото¬
рых участвует процесс.
Process test checklist Контрольный список для тестирования процесса
Документ, разрабатываемый при планировании испытаний системы, в котором пе¬
речислены все условия, подлежащие проверке при тестировании данного процесса.
Program generator Генератор программ
Программное средство, выполняющее генерацию программ, реализующих опреде¬
ленные функции, на основе спецификаций, для составления которых не требуется тра¬
диционный язык программирования.
Program structure Структура программы
Структура программы, компонентами которой являются модули.
Program run diagram Схема выполнения программы
Документ, в котором указаны все входные и выходные файлы программы.
Project librarian «Библиотекарь» проекта
Член проектной группы, отвечающий за компоновку и хранение окончательных
версий документации, слежение за версиями документации и т. д.
Read ahead principle Принцип предварительного считывания
Принцип, используемый при разработке программ, согласно которому первой
Должна считываться запись управляющего файла, а обращение к следующей записи
этого файла выполняется всякий раз по завершении обработки записей других файлов.
При этом первым всегда будет вызываться главный модуль программы.
Reference file Справочный файл
Файл, содержащий данные, обрабатываемые процессами, но не являющийся управ¬
ляющим ни для одного из процессов.
Relational data analysis Реляционный анализ данных
Метод анализа структуры данных, в основу которого положены правила, вытекаю¬
щие из теории нормализации отношений.
Remote batch terminal Удаленный терминал, ориентированный на пакетную об¬
работку
Терминальная станция (абонентский пункт), в состав которой входят периферий¬
ные устройства, ориентированные на пакетную обработку. Станция соединена телефон¬
ной линией с вычислительным центром, где происходит выполнение программ.
Set Множество
Совокупность элементов, объединенных по какому-либо логическому признаку.
Sizing sheet Бланк для записи объемно-временных характеристик
Специальный документ, в который вносятся оценки объемно-временных характери¬
стик будущей системы на этапе проектирования.
Staged implementation Поэтапная реализация
Создание системы путем последовательного выполнения определенных этапов
работ.
Store Хранилище
Логический объект, соответствующий некоторой совокупности данных или матери¬
альных объектов, обработка или использование которых происходит через определен¬
ное время после накопления.
Stucture (variable) file Зависимый файл
В СУБД TOTAL — файл, расположенный на втором (система поддерживает не бо¬
лее двух уровней иерархии) уровне структуры данных.
260

Structured English Псевдокод
Частично формализованный язык для спецификации процессов и процедур при ана-
лизе и проектировании системы. Спецификация составляется с использованием несколь¬
ких ключевых слов и последовательной нумерации отдельных предложений.
System decomposition Декомпозиция системы
Одна из задач системного анализа, в результате которой определяются основные
информационные и функциональные компоненты системы.
System stored data Хранимые данные
Данные, подлежащие хранению в системе после завершения выполнения програм¬
мы для последующей обработки.
System targets Целевые установки при создании системы
Цели, которые должны быть достигнуты в результате создания системы. Они могут
относиться к составу предоставляемых данных, функциональным или операционным
характеристикам ИС.
Technical design control (TDC) form Бланк технического контроля проекта (ТКП)
(Контрольный бланк).
Специальный документ, в который на этапе технического контроля проекта вно¬
сятся результаты вычислений. При оценке объемно-временных характеристик системы
заполняется несколько бланков различного уровня.
Technical refinement Техническое уточнение проекта
Первая задача при техническом проектировании системы, состоящая в уточнении
логической модели системы для ее реализации на ЭВМ.
Test case Контрольный пример
Совокупность программ, тестовых данных и предварительно специфицированных
условий, подлежащих проверке при тестировании системы. Разработка контрольных
примеров облегчает планирование и проведение испытаний.
Test case definition form Бланк описания контрольного примера
Документ, разрабатываемый при планировании испытаний системы, в котором при¬
водятся условия, подлежащие проверке при выполнении контрольного примера.
Test condition form Бланк описания проверяемых условий
Документ, разрабатываемый при планировании испытаний системы, в котором пе¬
речисляются все условия, подлежащие проверке.
Test script Сценарий выполнения контрольного примера
Заранее составленный перечень входных сообщений и ответов системы. Сущест¬
венно облегчает проведение испытаний диалоговых систем.
Third normal form Третья нормальная форма (отношения)
Все типы данных (отношения), подвергаемые реляционному анализу данных, дол¬
жны быть приведены к третьей нормальной форме.
Time sharing Разделение времени
Предоставление параллельного доступа пользователей ко всем ресурсам ЭВМ с
помощью терминалов с учетом относительных приоритетов пользователей.
Time band Временной интервал
Интервал времени двумя тактовыми линиями (на бланке описания процесса, под¬
готовленном при проектировании системы). Считается, что все процессы, попадающие
в один интервал, выполняются «одновременно», например ежедневно.
Time-line Тактовая линия
Пунктирная линия на бланке описания процесса, подготовленном при проектиро¬
вании системы, которая указывает на определенный момент времени, отделяющий вы¬
полнение одних процессов от других.
Top-down (design) Проектирование по принципу «сверху вниз»
Метод проектирования, при котором происходит пошаговая детализация компонен¬
тов системы, начиная с расположенных на самом верхнем уровне иерархии.
Transaction design Проектирование транзакций
Процесс разработки последовательностей пар физических сообщений, отражающих
особенности конкретного типа терминала, исходя из логической спецификации тран¬
закции.
Transaction profile Профиль транзакции
Графическое представление всех процессов, обрабатывающих определенную сово¬
купность данных, например входной или главный файл. Разрабатывается при проекти¬
ровании системы.
Utility Утилита
Программа, выполняющая некоторую обобщенную сервисную функцию в системе.
Для выполнения конкретного вида обработки такой программе необходимо передать
соответствующие параметры.
Walkthrough checklist Контрольный список для записи результатов ревизии проекта
Перечень наиболее распространенных ошибок, отсутствие которых должно быть
установлено при проведении ревизии. Такие перечни разрабатываются для всех под¬
задач, выполняемых на различных этапах проекта.
261

Оглавление
Предисловие
ЧАСТЬ 1. ОСНОВНЫЕ КОНЦЕПЦИИ И ОБЗОР МЕТОДОВ РАЗРАБОТКИ
Г л а в а 1. Общие сведения ...
1.1. Практика применения методов разработки ИС .
1.2. Краткое содержание книги
1.3. Обзор методов, применяемых при создании ИС
1.4. Расположение материала в книге ....
Глава 2. Стратегия разработки И С .
2.1. Введение	 .
2.2. Характер деятельности организаций
2.3. Формирование стратегии разработки ИС
2.4. Критический анализ требований к ИС
2.5. Критический анализ основных технологических решений .
2.6. Критический анализ стратегии разработки ИС ....
2.7. Заключение
Глава 3. Обзор методов разработки И С .
3.1. Введение
3.2. Поэтапная разработка, системы ....
3.3. Технический контроль проекта (гл. 16)
3.4. Тестирование (гл. 9)
3.5. Внедрение
3.6. Ревизия внедренной системы
3.7. Инспекция (гл. 17)
3.8. Графическое представление системных методов
Глава 4. Применение структурных методов .
4.1. Введение .	.
4.2. Выбор методов
4.3. Создание условий для внедрения новых методов .
4.4. Разработка и изменение стандартов ....
4.5. Обучение кадров
4.6. Планирование первого проекта
4.7. Выполнение первого проекта
4.8. Ревизия первого проекта
4.9. Последующие проекты
4.10. Сопровождение систем
4.11. Дальнейшее применение структурных методов
4.12. Заключение
ЧАСТЬ 2. МЕТОДЫ РАЗРАБОТКИ ПРОЕКТА
Глава 5. Анализ реализуемости разработки ИС .
5.1. Введение ...	....
5.2. Постановка задачи
5.3. Возможные решения
5.4. Оценка альтернативных вариантов .
5.5. Планирование последующих фаз
5.6. Завершение анализа
Глава 6. Системный анализ .
6.1. Введение
6.2. Общие сведения о системном анализе .
6.3. Графическое представление метода .
6.4. Формирование первоначального плана .
2
9
9
10
11
15
15
15
16
17
17
22
29
29
29
29
30
34
34
34
35
35
36
36
36
38
39
40
41
43
44
45
45
46
46
47
48
48
48
49
51
57
60
61
62
62
63
65
65
262

6.5. Обследование существующей системы ...	.67
6.6. Определение детальных требований ....	,71
6.7. Разработка эскизного проекта	 ,76
6.8. Анализ данных	 .61
6.9. Разработка детального проекта новой системы .	.	84
6.10. Составление плана разработки	 89
6.11. Подготовка и инспекция системной спецификации .	89
6.12. Преимущества структурного системного анализа .	91
Глава 7. Проектирование системы	92
7.1. Введение 	 .	92
7.2. Декомпозиция данных ....	.	97
7.3. Декомпозиция процессов	 .	.	99
7.4. Разработка профилей транзакций .	.	.	.	. ЮЗ
7.5. Логическое проектирование	 ...	.107
7.6. Уточнение технических деталей ...	...	. ПО
7.7. Группирование компонентов	 .115
7.8. Детализация проекта	 119
7.9. Структурное проектирование систем реального времени	121
7.10. Структурное проектирование систем баз данных .	. 125
7.11. Заключение	 .....	. 129
Литература	....	.	.	.	.	.	.130
Глава 8. Программирование ...	.130
8.1. Введение 	 .130
8.2. Проектирование логики программы .	.	133
8.3. Структура программы ....	.	.138
8.4. Логическое проектирование программ .	.	143
8.5. Уточнение проекта	 .146
8.6. Оптимизация программы	 .	. 147
8.7. Физическое проектирование программ .	.	147
8.8. Принципы структурного кодирования	.	.	.150
8.9. Составление программ на Коболе .	...	. 153
8.10. Составление программ на ПЛ/1 .	.	...	. 156
8.11. Составление программ на Бейсике	.	...	.157
8.12. Тестирование программы .	.	.	'	 158
8.13. Проектирование программ для систем реального времени	. 162
8.14. Разработка программ в диалоговом режиме ....	167
Глава 9. Тестирование .....	.169
9.1. Введение .....	.	.	.169
9.2. Подготовка тестовых данных	.	.	.170
9.3. Разделение тестовых данных	.	.	. 172
9.4. Процедура тестирования	 .172
9.5. Хранение тестовых данных систем ...	.180
9.6. Заключение	 .181
Глава 10. Послесловие к методам разработки И С	.181
10.1. Введение	 .	.	181
10.2. Обзор методов поэтапной разработки ИС	 .181
10.3. Внедрение методов	 .183
10.4. Организация работ по новым методам	 .183
10.5. Применение методов при различных подходах	к реализации ИС .	.184
10.6. Автоматизация разработки ИС	 .187
10.7. Перспективы развития методов разработки	ИС	.190
10.8. Заключение	   .	.191
ЧАСТЬ 3. ПРОЦЕДУРЫ
Глава 11. Операционные диаграммы .	.193
11.1. Введение .		 ...	.193
11.2. Прочие методы	 . 194
11.3. Структурный графический метод: операционные диаграммы .	.	.196
11.4. Об использовании операционных диаграмм в настоящей книге .	203
Литература		 .	.	.	. 203
Глава 12. Анализ ключевых факторов эффективности .	. 203
12.1. Введение ....	. 203
12.2. Описание метода .	.	. 204
12.3. Примеры анализа КФЭ	. 205
263

12.4. Анализ КФЭ на различных этапах проектирования .	. 207
Литература ....	.........	. 207
Глава	13. Анализ данных .	.	208
13.1. Введение	 . 208
13.2. Краткий обзор методов анализа данных ....	. 208
13.3. Реляционный анализ	 .211
13.4. Логическое структурирование .	  .215
13.5. Анализ логических связей .	.		 . 217
13.6. Анализ путей доступа к данным	 .218
13.7. Подготовка документации	 . 220
13.8.	Проблемы, возникающие при	анализе данных ...	.	222
13.9. Применение методов анализа данных при разработке ИС	. 223
Литература ....		 . 224
Глава 14. Анализ структуры файла .	. 224
14.1.	Введение	 .	224
14.2. Основные структуры данных	 . 224
14.3.	Анализ логической структуры	файла	...	.	225
14.4. Некорректная структура файла ....	. 226
14.5. Физическая структура файла	 . 228
14.6. Структуры файлов при проектировании систем .	. 229
14.7. Структуры файлов при проектировании программ	. 229
14.8. Заключение 	 . 230
Глава	15. Спецификация логики обработки данных .	.	231
15.1. Введение ....	  .231
15.2. Анализ описаний процедур	 .	232
15.3. Верификация и структуризация логики	процедуры	.	.	.	232
15.4. Псевдокод	 .	233
15.5. Описание процессов на стадии проектирования системы .	.	235
Глава 16. Технический контроль проекта .	.	235
16.1. Введение	 .	235
16.2. Описание процедуры  	 .	236
16.3. Контрольный бланк	 .	238
16.4. Выполнение расчетов	 .	239
16.5. Пример расчета временных характеристик для СУБД	.	240
16.6. Автоматизация расчетов	.	.	.	. 241
16.7. Заключение 	 .	.	. 242
Глава 17. Периодический контроль проектных	решений .	.	243
17.1. Введение	  243
17.2. Время проведения контрольных	проверок	244
17.3. Подготовка к проверке	244
17.4. Распределение обязанностей между членами контрольной группы .	. 246
17.5. Порядок проведения заседания .	.	...	.	.	. 246
17.6. Контрольные списки .	.	...	.	.	.	247
17.7. Эффективность контроля	.	...	.	.	. 248
17.8. Заключение	.	.	...	.	.	.	249
Глава 18. Управление проектом	.	250
18.1. Введение	 .	250
18.2. Поэтапное планирование		 .	251
18.3 Контроль за выполнением плана	 . 252
18.4. Контроль разработки со стороны администрации ...	. 253
18.5. Преимущества реализации системы управления проектом	. 254
Глоссарий	.	.	.	...	.	. 255