Билеты к государственным экзаменам по дисциплине "Проектирование экономических информационных систем"

1. Значение и направления развития проектирования информаци- онных систем, предназначенных для обработки экономической инфор- мации проблемы проектирования автоматизированных экономических информационных систем АЭИС 14.1 . Мировая экономика - широко разветвленная научная отрасль, имеющая мощную информационную базу только в США выходит более 500 наименований журналов по экономике и бизнесу . В нашей стране проблема проектирования АЭИС стоит особенно остро, если учесть, что до недавнего времени

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

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

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

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

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

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

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

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

иерархической структу- ры г Успешность проектирования L - г г Качество Эффективность процесса системы разработки системы L T - L T - T T г г г г г г Челове- Управле- Програм- Челове- Управле- Програм- ческие ние ре- мотехни- ческие ние ре- мотехни- факторы сурсами ка факторы сурсами ка LT -LT -LT - LT -LT -LT - Легкость Эффектив-

Специфиро- Планируе- Анализиру- Осуществи- использо- ность ванность мость емость эф- мость вания полнота Организо- фективнос- Полнота и Удовлетво-LИзмеряе- безопас- ванность ти затрат осуществи- рение пот- мость ность Укомплек- мость тре- ребностей непротиво- тованность Планируе- бований пользова- чивость штатов мость Проектиру- теля осуществи- Руководи- емость из- Реализация мость мость LКонтроли- делия потенциа- проверяе-

Контроли- руемость Програм- льных спо- мость руемость мируемость собностей Правиль- Автомати- Комплекси- пользова- ность зируемость руемость теля LАдаптируе- LСледование Внедряе- LСледование мость модифици- мость модифици- структури- рованному Сопровож- рованному рованность золото- даемость му золотому независи- правилу Снимае- правилу мость мость понятность LУправляемость конфигурацией

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

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

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

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

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

ПЭВМ. Это можно продемонстрировать примером, характерным для США, где предъявляют семь основных четко сформировавшихся требований для ПЭВМ 1 цена всей системы не должна превышать 5000 дол. 2 система включает внешние запоминающие устройства накопи- тели на компакт-диска или на магнитных дисках 3 емкость ОЗУ составляет не менее 64 Кбайт 4 в состав

ПО входит по крайней мере один из языков прог- раммирования высокого уровня Бейсик, Фортран или Паскаль 5 имеется операционная система, способная поддерживать диа- логовое взаимодействие с пользователем 6 распространение ПЭВМ осуществляется на основе сети сбыта с ориентацией на людей, не обладающих навыками работы с ВТ 7 система обладает достаточной гибкостью для поддержки прикладного ПО, она в известном смысле является универсальной.

Создание АЭИС с использованием ПЭВМ позволяет - обеспечивать работников управленческий сферы и финансово- экономических служб оперативной информацией вместо обезличенного представления информации функциональному подразделению в целом - получать комплексную информацию на основе данных всех под- систем управления хозяйственной и коммерческой деятельностью - создать многоуровневый интегрированный банк данных и обес- печить диалоговый режим общения пользователя с системой через ав- томатизированные рабочие места

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

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

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

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

са- монастройки системы на оптимум показателей одновременно с ростом числа задач сокращается допустимое время принятия решений - проектирование начинается и проводится в условиях неопре- деленности, т.е. при отсутствии в полном объеме информации, необ- ходимой для выбора решений. Для комплексного решения проблем проектирования необходимо широкое обеспечение процесса средствами автоматизации всего жиз- ненного цикла АЭИС, начиная от формулирования исходных требований и кончая

завершением промышленного производства и эксплуатации. Рост спроса на АЭИС предъявляет требования к самому проекти- рованию повысить производительность труда при разработке повы- сить эффективность сопровождения, т.к. последнее требует больших затрат, чем непосредственно разработка. 2. Порядок разработки автоматизированных экономических ин- формационных систем АЭИС нормативная последовательность этапов разработки

АЭИС технические предложения,технические требования или техническое задание эскизный проект технический проект ра- бочий проект 19.1. Основанием для начала работ по созданию АЭИС могут быть ре- шения как государственных органов, так Разработка техни- и коммерческих структур и различных ор- ческих предложен. ганизаций, функционирующих в обществен- L T но-социальной сфере. В создании участ-

T вуют как заказчик организация, для ко- Разработка ТЗ или торой разрабатывается АЭИС , так и ис технич.требований полнитель - как специализированная ор- L T ганизация, так и отдельно созданный для этой цели коллектив. L Эскизное Весь период создания проектирование АЭИС состоит из этапов. В L T зависимости от того, в ка- кой степени при L-

Техническое - Макетирование и проекровании испо- проектирование оценочн.программ. льзуются готовые L T L или известные тех- нические решения и методология, неко- Разработка рабо- торые этапы могут объединяться чих чертежей - В других случаях, напротив, от- L T дельные этапы например, эскизное или техническое проектирование могут до- L Изготовление полняться экспериментальными работами опытного образца для исследования новых

решений, схем и L T методов. Связи между этапами, идущие в об- L- Отладка и испыта- ратном по отношению к последователь- L ния опытн.образца - ности разработки направлении, отражают L T возможность корректировки некоторых ре- шений, принятых на предшествующих эта- Изготовл.и экспл. пах, по результатам анализа или иссле- головного образца дований, выполненных на

последующих L T этапах. В рассмотренном порядке создания Серийный АЭИС находят отражение все системотех- выпуск нические принципы. Переход от общих L вопросов к частным, одновременная про- работка отдельных подсистем и устройств, корректировка результатов - эти и другие требования по порядку представляют собой основные системотехнические концепции. Разработка технических предложений. проводится изучение и анализ предметной области в которой

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

с представителями заказчика - анализ и обобщение материалов обследования исследования . Заказчик обеспечивает сбор, систематизацию и представление разработчику всей необходимой информации. На основе проведенной работы проводится определение общих контуров проектируемой АЭИС, выполняется ориентировочная оценка сроков ее создания и приводятся расчеты стоимости и эффективности разработки. Разработка технических требований и технического задания

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

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

АЭИС, обоснование необходимости проведения НИР предвари- тельный выбор методов и средств решения задач, критериев эффек- тивности моделирование наиболее важных функций и характеристик АЭИС предварительная декомпозиция АЭИС на комплексы анализ ана- логов АЭИС по зарубежным и отечественным данным анализ требо- ваний ТТЗ на АЭИС на реализуемость и непротиворечивость разра- ботка требований к

АЭИС разработка требований к критериям, мето- дам и средствам оценки качества системы разработка требований к порядку, видам и срокам испытаний и приемки АЭИС. Состояние АЭИС после этого подэтапа характеризуется выпуском технических требований к информационной системе. Подэтап Разработка ТЗ на АЭИС Помимо определения и форму- лировки в ТЗ требований заказчика к АЭИС и условий ее эксплуата- ции, установлен следующий порядок разработки

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

разработка и оформле- ние ТЗ согласование и утверждение ТЗ на АЭИС. ТЗ оформляется заказчиком в виде документа, подписывается, согласовывается и утверждается заказчиком и исполнителем в соот- ветствии с установленным порядком. Разработка эскизного проекта Этап разработки эскизного проекта идет параллельно с эта- пом эскизного проектирования АЭИС и включает подэтапы Подэтап Проработка архитектуры и декомпозиция

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

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

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

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

Состояние АЭИС после прохождения данного подэтапа требова- ния к конфигурации вычислительной техники частное ТЗ на операци- онную среду. На подэтапе Проработка вопросов оценки и обеспечения ка- чества АЭИС . разрабатываются выбираются методы оценок качества системы и метрики для показателей качества АЭИС. Разрабатываются частные ТЗ для проверки, отладки и испытаний АЭИС. Состав работ разработка количественных показателей и мето- дов оценки качества разработка частных

ТЗ на тесты для проверки, отладки и испытаний системы и ее компонент, частных ТЗ на средс- тва автоматизации испытаний. Состояние АЭИС после прохождения данного подэтапа частное ТЗ на разработку тестов частное ТЗ на средства автоматизации ис- пытаний АЭИС. На подэтапе Разработка технико-экономического обоснования работы проводятся на основании утвержденных отраслевых

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

Подэтап Перспективное планирование создания системы Состав работ выбор и обоснование основных концепций техно- логии разработки и состава технологического оборудования. разра- ботка частного ТЗ на составные части ОКР и программирование соз- дание кооперации разработка проекта руководящих указаний к раз- работке уточнение ТЗ на программные средства разработка частно- го

ТЗ на тренажеры и обучающие средства создание базы данных программного проекта для автоматизации управления и контроля хода разработки разработка пояснительной записки к эскизному проекту. Состояние АЭИС после прохождения данного подэтапа характери- зуется выпуском следующих документов частное ТЗ на составные части ОКР и ТЗ на программирование руководящие указания к разра- ботке частные ТЗ на тренажеры и обучающие устройства. На этапе эскизного проектирования продолжается уточнение ор-

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

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

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

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

и внедрения АЭИС. Технический проект предусматривает Постановку задачи или Исходные данные , в которую включаются наименование задачи, ее содержательная формулировка данные о периодичности решения зада- чи связи данной задачи с другими задачами и ее место в комплексе задач подсистем описание способа организации сбора исходных дан- ных и передачи их в память средств переработки информации описа- ние алгоритма решения задачи, точности решения, методов контроля

вычислений расчет надежности формулировка временных ограничений на выдачу решения задачи обоснование целесообразности предложен- ного варианта задачи по сравнению с другими вариантами. Здесь же приводятся в приложениях описание форм входных документов, форм промежуточных документов, сведения о представле- нии информации, необходимой для связи с другими задачами. Разработанный технический проект АЭИС принимается комиссией, назначаемой заказчиком.

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

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

Состав работ декомпозиция системы на компоненты и модули определение функций и связи со смежными компонентами определение связей с внешними компонентами и операционной средой разработка интерфейсов и протоколов связи разработка структур и докумен- тальных форматов входных и выходных данных, методов организации и доступа, способов кодирования и контроля разработка внешней спе- цификации компонент АЭИС на языке функциональных спецификаций детализация требований к ресурсам, параметрам, режимам использо-

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

ТЗ на операционную среду требования к вычис- лительной технике и сопроцессорным устройствам На подэтапе Разработка прототипа информационной системы осуществляется разработка внутренней спецификации компонент и мо- дулей системы, разработка и верификация прототипа АЭИС. Цель раз- работки прототипа - обеспечить раннюю диагностику ошибок проекти- рования и предупредить их распространение на последующие стадии и этапы. Прототип - это рабочая модель, функциональный эквивалент.

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

спецификаций компонент и модулей АЭИС на языке функцио- нальных спецификаций с учетом характеристик технических средств разработка прототипа АЭИС и имитатора модели внешней среды испы- тание прототипа АЭИС, корректировка внешних и внутренних специфи- каций проекта АЭИС и прототипа оценка качества проектирования АЭИС уточнение графика разработки АЭИС уточнение требований к вычислительным ресурсам разработка уточненных требований к сос- таву и срокам

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

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

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

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

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

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

и сопровождение компонентов, создаваемым по отдельным частным ТЗ. Состояние АЭИС после этого характеризуется выпуском докумен- тов программная документация на тесты паспорта автономной от- ладки аппаратных и программных модулей техническая и программная документация на аппаратные и программные модули. Подэтап Отладка комплексов системы . проводится непосредс- твенно на предприятиях-соисполнителях. Паспорта комплексной от- ладки предъявляются головному исполнителю.

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

готовности специализированного стенда отладки и испыта- ния АЭИС отладка комплексов системы в реальном масштабе времени оценка качества комплексов системы выпуск технической и прог- раммной документации на комплексы системы разработка технических условий разработка, испытания, передача в опытную эксплуатацию и сопровождение системы, создаваемой по отдельным частным ТЗ. Состояние АЭИС после этого характеризуется выпуском докумен- тов паспорт комплексной отладки программная

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

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

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

и программных компонентов системы внутренние спецификации компо- нент и модулей системы технические требования к системе. Подэтап Проведение стендовых испытаний опытного образца системы Стендовые испытания проводятся в соответствии с прог- раммой и методикой испытаний, согласованной с заказчиком. Испыта- ния системы проводятся на специализированном стенде, включающем в свой состав объектные ЭВМ и основные типы переферийных устройств системы.

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

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

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

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

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

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

разработки АЭИС 15.1 Своеобразие информационных систем и в частности АЭИС , как продукции производственно-технического назначения, выражающееся в ее сложности, в отсутствии нормативов на большинство видов проце- дур и работ, делает процесс их планирования и проектирования а также производства весьма сложным и затруднительным. Для управления и осуществления планирования проектом необхо- дима организационная структура, которая

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

АЭИС. Значительная часть работ в жизненном циле сложных информаци- онных систем связана с исследованием и разработкой методов управ- ления информацией. Организация проектирования охватывает следую- щие основные этапы. 1. СИСТЕМНЫЙ АНАЛИЗ И ПРОЕКТИВАНИЕ АЛГОРИТМОВ определение целей системы выбор методов решения задач проектирование алго- ритмов разработка технического задания на АЭИС 2. СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ определение структуры

АЭИС определение структуры модулей распределение производительности ЭВМ распределение памяти ЭВМ 3. ПОДГОТОВКА ТЕХНОЛОГИЧЕСКИХ СРЕДСТВ организация БД проек- та адаптация языков программирования настройка средств трансля- ции и отладки разработка инструкций для применения технологии 4. ПРОЕКТИРОВАНИЕ ТЕХНИЧЕСКИХ СРЕДСТВ 5. РАЗРАБОТКА ПРОГРАММНЫХ

СРЕДСТВ разработка спецификаций на модули и группы программ трансляция глобальных переменных трансляция текстов программ загрузка программ и редактирование связей 6. ОТЛАДКА СИСТЕМЫ В СТАТИКЕ планирование отладки системы тестирование системы локализация ошибок и корректировка систем комплексирование систем 7. КОМПЛЕКСНАЯ ДИНАМИЧЕСКАЯ ОТЛАДКА выбор средств для ими- тации абонентов разработка программ имтации создание программ обработки

результатов отладка функционирования АЭИС в реальном масштабе времени 8. ВЫПУСК МАШИННЫХ НОСИТЕЛЕЙ И ДОКУМЕНТИРОВАНИЕ изготовле- ние машинных носителей изготовление эксплуатационных документов изготовление технологических документов изготовление исследова- тельских документов 9. ИСПЫТАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ испытания на полноту функционирования испытания на надежность функционирования обра- ботка результатов испытаний разработка акта испытания

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

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

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

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

в целом и основных ком- понент, на прогнозировании изменения характеристик качества, на оценках развития обнаружения и устранения ошибок. Долгосрочный план проектирования должен содержать 1. 2Формулировку общих целей АЭИС и и частных целей создания 2ее компонент.0 Проводится в техническом задании с указанием харак- теристик АЭИС, которые должны быть получены при ее создании.

Эта часть расширяется оценками влияния основных факторов на эффектив- ностьрешения основной целевой задачи. 2.2 Стратегию проведения прое0к2тирования.0 Обеспечивает выпол- нение поставленных перед АЭИС как общих, так и частных целевых задач с минимальными затратами или минимальными сроками. Она должна определять принципы и этапы проведения проектирования последовательность и длительность разработки и отладки структурно и функционально законченных групп

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

АЭИС состоит в неопределенности интервалов длительности выполнения ря- да работ. Это обусловлено переплетением процессов технического проектирования и исследований отдельных функциональных алгоритмов, а также отработкой методов решения задач. Для построения 2сетевого графика.0 предлагается перечень основ- ных событий. 1. 1Откорректировано и утверждено заказчиком техническое за-

1дание. 2. 1Откорректирован состав частных задач групп программ и 1осуществлен выбор методов их решения0, что фиксируется в обобщаю- щем документе спецификации требований , являющемся неофициальным расширением и уточнением технического задания. 3. 1Разработана функциональная схема АЭИС0, определяющая ук- рупненную логику обработки информации и функционирование всей системы, а также организацию решения всех функциональных задач, основные логические и информационные связи между группами

прог- рамм, решающими частные задачи, взаимодействие с внешними абонен- тами по обмену информацией. 4. 1Разработаны частные технические задания и предварительные 1варианты групп программ0, фиксирующие назначение, методы решения и состав обменной информации для каждой из разрабатываемой групп программ. При разработке детального сетевого графика необходимо эти этапы распараллеливать по числу функционально законченных частей АЭИС и выделять наиболее трудоемкую и длительную по срокам разработки часть, определяющую

критический путь. 5. 1Разработано описание глобальных переменных0, в котором да- ется строго формализованное описание каждой информационной связи между программами, подробно и точно расшифровываются их признаки и спецификации данных, а также отмечаются имена программ, форми- рующих и использующих такие переменные. 6. 1Уточнена технологическая схема проведения разработки АЭИС с использованием средств автоматизации, в которой особое внимание должно уделяться полноте и комплексному

использованию этих средств. 7. 1Произведено оценочное программирование 0для оптимизации использования ресурсов ПЭВМ, для уточнения затрат на решение от- дельных задач, а также для распределения производительности и па- мяти команд. 8. 1Произведена оценка потоков сообщений и заявок, длитель- 1ностей решений и допустимых запаздываний в решении частных задач путем анализа параметров источников сообщений, по затратам на ре- шение аналогичных задач, а также в результате экспертного опроса ведущих

специалистов. 9. 1Разработано распределение оперативной памяти 0исходя из требований к допустимой вероятности потери сообщений, из функцио- нальных требований АЭИС, а также из ограничений на общий объем оперативной памяти. 10. 1Рассчитаны основные характеристики возможных схем органи- 1зации вычислительного процесса 0и определена их эффективность, в результате чего подготавливаются варианты схемы организации вы- числительного процесса, которые дополнительно проверяются на сте- пень

выполнения ряда технических и идеоло1г0ических ограничений си- стемы управления или обработки информации. 11. 1Рассчитаны основные характеристики вариантов схем опера- 1тивного контроля вычислительного процесса 0для обеспечения надеж- ности решения при наличии искажений исходной информации, сбоев ПЭВМ и невыявленных ошибок в программах. 12. 1Разработано распределение памяти команд и констант0, кото- рое должно обеспечивать реализацию

АЭИС, равнопрочного по ка- честву всех решаемых задач в условиях ограниченных ресурсов ПЭВМ. 13. 1Разработаны функциональная схема организации вычислитель- 1ного процесса 0и алгоритмы взаимодействия с внешними абонентами, алгоритмы начального пуска, центрального диспетчера, местных дис- петчеров, временной тактировки и т.д. 14. 1Разработаны функциональная схема оперативного контроля и 1обеспечения надежности вычислительного

процесса, 0алгоритмы сбора данных об искажениях вычислительного процесса и алгоритмы приня- тия решений в зависимости от характеристик выявленных искажений. 15. 1Произведена оценка необходимой производительности реали- 1зующей ПЭВМ, 0а также выявлены задачи, требующие большего времени для решения. 16. 1Аналитически уточнены основные характеристики выбранных 1методов решения задач0 точностные характеристики,

эффективность, пропускная и разрешающая способность, устойчивость алгоритмов уп- равления и т.д. 17. 1Методом моделирования уточнены характеристики выбранных 1алгоритмов решения задач0, которые сопоставлены с аналитическими исследованиями и представлены как часть пояснительной записки к техническому проекту. 18. 1Определены требования к средствам автоматизации проекти- 1рования и языку программирования0, которые позволяют создавать и отлаживать программы при допустимых

затратах труда и при доста- точно эффективном использовании ресурсов реализующей ПЭВМ. 19. 1Уточнен выбор реализующей ПЭВМ 0с учетом необходимой опе- ративной памяти, памяти команд и производительности, а также ме- тодов организации вычислительного процесса и обеспечения надеж- ности решения задач. 20. 1Подготовлены предложения по уточнению технического зада- 1ния на АЭИС 0с учетом выбранных методов решения задач, параметров

ПЭВМ, сроков разработки , квалификации специалистов, принятой технологии проектирования и т.д. 21. 1Определен состав и форма технической документации на ап- 1паратные и программные средства0, которые согласуются с заказчиком и и формализуются в стандарте предприятия. 22. 1Разработана или выбрана система автоматизации проектиро- 1вания0, которая должна быть рентабельной, т.е. затраты времени и средств на ее разработку или освоение

должны окупаться сокращени- ем времени и затрат при создании АЭИС. 23. 1Разработан и предъявлен заказчику технический проект 1АЭИС, 0в котором представлен макетный образец системы и ее доста- точно полные функциональные и технические характеристики. В зависимости от глубины исследований и и инженерных разра- боток алгоритмов в той области, где предполагается применять АЭИС, критический путь сетевого графика может проходить либо по работам,

носящим исследовательский и методический характер 1 группа , либо по работам, обеспечивающим непосредственное созда- ние программ 2 группа , либо по работам, связанным с созданием технологических средств автоматизации программирования и отладки программ 3 группа . 17 1 группа L работ 16 L 2 группа 11 14 работ L L-T 8 10 13 L L L 1 2 3 4 7 12 15 19 20 23 L LT LT L L L LTT- L L LTT-

L 5 9 L 21 L L L - 3 группа работ L 6 18 22 L L L Критический путь сетевых графиков не всегда проходит по со- бытиям непосредственного создания программ Следует отметить, что в зависимости от глубины исследований и и инженерных разработок алгоритмов в той области алгоритмов в той области, где предполагается применять АЭИС, критический путь се- тевого графика может проходить либо по работам, носящим исследо- вательский

и методический характер 1 группа , либо по работам, обеспечивающим непосредственное создание программ 2 группа , ли- бо по работам, связанным с созданием технологических средств ав- томатизации программирования и отладки программ 3 группа . 2Организация коллективов для создания АЭИС.0. Конец 70-х годов характеризовался за рубежом как кризис в области создания и про- ектирования информационных систем в части программного обеспече- ния, который заключался в отставании технологии

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

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

законченных функцио- нальных задач по группам специалистов, осуществляюшим их полную разработку, и последующего объединения функциональных задач спе- циальной группой ведущих комплексников . Одним из вариантов организационной структуры коллектива при создании крупных АЭИС является иерахическая структура, базирующа- яся на группах из 7-10 человек специалистов разной квалифика- ции, решающих достаточно автономную функциональную задачу.

4. Виды поддержки процесса проектирования автоматизированных информационных систем АЭИС документирование цели проектирова- ния АЭИС 32.1 2Методологическая поддержка.0 включает набор стандартов, инс- трукций и методик, определяющих правила создания систем и регла- ментирующие построение объекта разработки и процесса его созда- ния. В методиках и инструкциях конкретизируются языки проектиро- вания систем, правила использования символов и обозначений, пра- вила структурного построения аппаратных и

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

АЭИС или группы систем одного класса создаются стандарты предприятия и руководящие указания по проектированию. В совокуп- ности эти документы отражают отражают различные аспекты методоло- гии создания конкретных АЭИС. 2Технологическая поддержка.0 детализирует документы методологи- ческой поддержки, регламентирующие технологию обеспечения жизнен- ного цикла систем. Документы технологической поддержки определяют этапы проектирования, их результаты и методы контроля соблюдения предписанной технологии.

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

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

2Инструментальная поддержка.0 состоит из программных средств и средств вычислительной техники, связи и тиражирования, обеспечи- вающих автоматизацию процесса создания АЭИС комплекса программ . 3Программная оснащенность.0 определяется функциональными воз- можностями программных систем автоматизации разработки ПО. Для каждого этапа разработки могут применяться методы и средства, различающиеся эффективностью, в свою очередь зависящей от особен- ностей проектируемой

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

ПС. 2Аппаратурная оснащенность0 .разработки сложных систем опреде- ляется мощностью используемых ЭВМ и возможностью доступа к ним, а именно быстродействием ЭВМ, используемых при разработке - чис- лом дисплеев, сопряженных с различными типами ЭВМ, доступных в среднем каждому разработчику программ средним числом возможных подходов к ЭВМ для реализации технологических операций каждым разработчиком за рабочий день.

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

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

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

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

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

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

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

проектом включает схемы руководства календарными сроками проекта. 5. Техническая документация Содержит функциональные описа- ния аппаратных средств 6. План отладки аппаратных средств 2ЦЕЛИ ПРОЕКТИРОВАНИЯ.0. 2Качество АЭИС учет человеческих факторов.0 Легкость использования. означает такую разработку документа- ции, средств управления структур и форматов входных и выходных данных, которая делает систему удобной, естественной

и гибкой. Удовлетворение потребностей пользователей .означает учет тех требований относительно информации или вычислительных средств, для выполнения которых предназначено АЭИС. Реализация потенциальных способностей пользователя .означает обеспечение более творческого характера труда и большего удовлет- ворения своей работой пользователей, эксплуатирующих АЭИС. Следование модифицированному золотому правилу

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

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

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

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

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

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

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

Адаптируемость .означает, что готовая ИС или ее компоненты можно легко использовать или приспособить для выполнения новых функций. Адаптируемость включает в себя 1 модифицируемость изделие способствует простоте внесения изменений 2 переноси- мость изделие может легко и хорошо эксплуатироваться в новых конфигурациях СВТ 3 работоспособность .в других системах - изде- лие или его компоненты могут использоваться в качестве компонен- тов других систем. Основными характеристиками адаптируемости являются следующие 2структурированность0

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

которых построено изделие, минимально например, в качестве уп- равляющих структур используются только составные операторы if-then-else, case, do-while, do-until и undo следует отметить, что принципы структурированности относятся не только к програм- мам, но и к данным и к документации 2независимость0 ИС независима,если на ее работу не влияют из- менения в устройствах, используемых при функционировании напри- мер, изменения в операционных системах и системах управления

БД 2понятность0 ИС является понятной, если ее назначение и функ- ционирование ясны специалистам, которые должны с ней работать. 2Эфективность процесса разработки АЭИС учет человеческих 2факторов.0 Целью учета человеческих факторов является такое управ- ление занятыми в процессе сотрудниками, которое позволит удовлет- ворить их запросы и реализовать их творческий потенциал. Планируемость .предполагает разработку и непрерывное поддер- жание в рабочем состоянии плана проектирования

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

разделение труда. Некоторые принципы органи- зованности аналогичны принципам структурированности ИС например, модульность и скрытность информации . Это выражено в законе Струтура ИС однозначно соответствует структуре разработавшей ее организации . Укомплектованность штатов .предполагает подбор, набор и зак- репление специалистов. При этом руководитель обычно озабочен сог- ласованием двух различных жизненных циклов жизненного цикла

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

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

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

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

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

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

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

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

не- обходимости его разработки и полезности 5. Жизненный цикл эффективность технологии проектирования автоматизированных экономических информационных систем АЭИС 16.1 . Понятие жизненного цикла , используемое в традиционных из- делиях промышленности, нашло свое отражение и в производстве АЭИС и его элементов аппаратного и программного обеспечения . Несмот- ря на кажущуюся схожесть описаний жизненного цикла изделий про- мышленности и

АЭИС, имеются глубокие различия в содержании от- дельных этапов этапов. Так широкий спектр содержательных показа- телей, которые с различных сторон характеризуют АЭИС, и невысокая достоверность оценки их значений способствует возрастанию диспер- сии при попытке описать создаваемые или используемые АЭИС. Жизненный цикл ЖЦ АЭИС включает в себя все этапы развития от возникновения потребности в информационной системе определен-

ного целевого назначения до полного прекращения ее использования вследствие морального старения или потери необходимости решения поставленных при создании системы задач. По длительности ЖЦ АЭИС разделяется на два класса - системы с малой длительностью эксплуатации, предназначен- ные для получения конкретных результатов вычислений. Они относи- тельно невелики до 10 тысяч команд , разрабатываются, как прави- ло, одним специалистом

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

документацией, как промышленные изделия, преобладают в проектных и отраслевых организациях. Формально ЖЦ АЭИС может быть представлен приведенной ниже схемой Появление пот Техничес АЭИС. Прекращение ребности и по кое зада эксплуатации становка задачи. ние Системный Проекти- Эксплуа- анализ рование тация L L L T Резуль- L Сопрово- тат эк- Расширение функций

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

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

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

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

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

АЭИС на- ваний пользо- чинается с определения набо- вателей ра требований пользователя. и L T и построения функциональной спецификации вытекающей из Разработка фу- требований пользователя. нкциональной Требования пользователя спецификации определяют, что пользователь L T хочет от системы, и что она должна делать. Проектирование

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

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

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

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

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

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

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

отнесенная к совокупным затратам, при которых она достигается. Этот показатель позволяет учитывать прирост эффективности на единицу затрат, и при больших затратах ограничивает качество системы. Глобальная оптимизация эффективности АЭИС на всем жизненном цикле весьма сложна и в большинстве случаев у разработчиков пре- валирует стремление оптимизировать этот показатель лишь на неко- тором интервале времени.

6. Технологические аспекты проектирования автоматизированных экономических информационных систем АЭИС 17.1 . Процесс проектирования занимает особое место в жизненном цикле ЖЦ информационных систем ИС . Установлено, что стоимость выявления и исправления на более поздних стадиях ЖЦ ошибок, допу- щенных при проектировании, возрастает в десятки раз. Поэтому уси- лия направлены на совершенствование языков и, соответственно, трансляторов для проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технология разработки АЭИС в современной интерпретации вклю- чает в себя следующие задачи - планирование и организация всего технологического процесса вплоть до серийного изготовления систем, построенных на основе спроектированных аппаратных и программных средств - разработка математических моделей, алгоритмов, программ и других компонент системы на всех стадиях проектирования - обеспечение программирования алгоритмов, включающего зада- чи автоматизации процесса программирования, унификации типовых компонент программ

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

и т.п. или же комплексами технологичес- ких средств, отнесенных к так называемым системам проектирования или программирования. Такие средства позволяют создавать АЭИС для определенных предметных областей их применения с первоначально определенными жесткими характеристиками, или же АЭИС широкого класса применения, характеристики которых в каждый конкретный мо- мент времени соответствуют пользовательским требованиям. Для получения

АЭИС высокого качества при допустимых затратах необходима комплексная разработка технологических процессов с развитыми средствами методической, технологической, инструмен- тальной и организационной поддержки. 7. Системотехнические принципы проектирования автоматизиро- ванных экономических информационных систем АЭИС классы систем - объектов проектирования декомпозиция как метод проектирования сложных АЭИС 18.1 . Методологией анализа и построения информационных систем, учитывающих их специфику, является

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

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

Для последних характер- на схема вход - функция - выход. Системный подход в данном слу- Вход 1 Выход 1 чае учитывает следующие особенности Вход 2 Сис- Выход 2 современных АЭИС тема - многофункциональный характер Вход n Выход n экономических задач L - большое число составных час- Внешнее окружение тей, действия которых в значитель-

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

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

системы и решение задач оптими- зации по различным критериям эффективности одним из важнейших факторов является экономический . Существует связь между особен- ностями современных АЭИС и системотехническими принципами проек- тирования, состоящая в 1. Многофункциональный характер управления и большое число взаимозависимых составных частей при наличии общей цели функцио- нирования отражается в принципах декомпозиции, комплексности и иерархии.

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

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

АЭИС, т.е. вначале устанавливается выход АЭИС как единого целого затем она разбивается на подсистемы при этом исследуется вклад каждой из них в результатирующий выход и т.д. 3. Основной метод проектирования сложной системы - метод де- композиции Декомпозиция. представляет собой процесс разбиения на составные части с целью исследования этих частей независимо друг от друга. Довольно широкое использование метода декомпозиции обусловлено особенностями

процесса принятия решения как в ходе создания, так и в ходе эксплуатации АЭИС, а именно наличием про- тиворечия между объемом работы по получению и переработке инфор- мации и отводимым на эту работу временем. Один из способов устранения противоречия состоит в разбиении проблемы или задачи, подлежащих решению, ряд подзадач проводится декомпозиция задачи , каждая из которых по объему и сложности та- кова, что может быть решена за приемлемое время и содержит коор- динирующие условия

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

соответствует представлению проектирования АЭИС как совокупности частных целей. Для достижения каждой част- ной цели .необходимы исполнители, средства и связи, представляющие в совокупности автоматизированную информационную подсистему Та- ким образом, АЭИС может содержать ряд автоматизированных экономи- ческих информационных подсистем, но сама при этом не обязательно является механическим объединением последних.

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

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

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

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

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

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

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

к их основным характе- ристикам. Основой для этого служат временные диаграммы .решения задач, устанавливающих допустимые интервалы решения каждой из них. Эти данные вместе с имеющимися параметрами позволяют рассчи- тать требования к производительности АЭИС и объему памяти. На этапе структурного синтеза широко применяются простейшие математические модели, реже физические модели экономических объ- ектов и макеты. Иногда задачи структурного синтеза требуют приме- нения элементов

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

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

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

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

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

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

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

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

АЭИС зат- рудняет разработку общих методов декомпозиции целей и их анализа - 1иерархия задач 0и поведения групп системы, обеспечивающих концептуальное единство единство методов и данных, а также воз- можность последовательного функционального раскрытия системы этот тип связан с иерархией целей системы и ее структурного пост- роения структурирование функциональных задач и их иерархического взаимодействия в значительной степени отражается на реализации иерархической структуры

АЭИС в целом и на ее структурной декомпо- зицией на функциональные группы программ - 1иерархия структуры 0системы и взаимодействия программ и данных, отражающих декомпозицию конкретных компонент комплекса и оформление реализуемых связей между программами и используемыми данными этот тип наиболее доступен для анализа и имеет важное значение при проектировании сложных АЭИС. Многоуровневое иерархическое построение сложных систем .поз- воляет ограничить и локализовать

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

на воздействия и от функционирования компонент нижних уровней, информация от которых передается верхним уровням. В иерархических структурах АЭИС образуется два потока взаи- модействий между компонентами разных уровней - сверху вниз - координирующие и управляющие воздействия верхних уровней - снизу вверх - информация о состоянии и реализации предпи- санных функций компонентами нижних уровней. Взаимодействие предполагает выбор способа координации и и реализацию координирующих алгоритмов с выработкой

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

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

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

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

и постройки программных модулей и ти- повые структуры массивов данных. Устанавливаются допустимые типы межмодульной связи и структура АЭИС в целом. На основе оценок длительности и частости решения отдельных задач выявляются функ- циональные алгоритмы с наибольшим потреблением производительности ПЭВМ, формируются дисциплины взаимодействия процессоров и диспет- черизации вызова программ, а также

оценивается реализуемость дан- ной АЭИС на выбранном классе ПЭВМ. Предварительное распределение оперативной памяти и памяти команд должно обеспечивать рациональ- ное использование этих ресурсов для решения частных функциональ- ных задач. Формально структурное проектирование состоит из следу- ющих этапов - определение структуры - определение структуры модулей - распределение производительности

ПЭВМ - распределение памяти ПЭВМ По принципам построения, языку описания, объему и другим ха- рактеристикам можно выделить следующие 1иерархические уровни 0прог- раммных компонент - операторов и операндов программы, соответствующие компо- нентам текста программы на языке программирования они являются минимальными компонентами, из которых строятся модули разнообра- зие операторов сравнительно невелико 50 100 типов, и каждый оператор реализуется алгоритмом на базе в среднем 1 10 машинных команд с повышением уровня

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

количество типов выходных данных несколько мень- ше если для решения небольшой функциональной задачи требуется 100 операторов или более, то целесообразно провести декомпозицию задачи на несколько более простых, для реализации каждой из кото- рых модуль реализуется 50 100 операторами - функциональные группы программ или пакетов прикладных программ формируются на базе десятков модулей и решают сложные автономные функциональные задачи на их реализацию в ПЭВМ исполь- зуется около десяти тысяч команд, соответственно

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

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

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

АЭИС по принципу 2сверху вниз 0с позиции назначения и наи- лучшего решения основной целевой задачи всей системы. Это обеспе- чивает ее концептуальное единство и возможность рационального распределения ресурсов проектирования по мере декомпозиции компо- нент. Хотя разделение на иерархические уровни требует некоторых затрат, в целом ресурсы используются более эффективно, чем при отсутствии четкой иерархии за счет построения и упрощения компо- нент на каждом уровне. Иногда основному проектированию сверху вниз сопутствует раз-

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

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

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

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

ПЭВМ, на которых реализуется система. Перечисленные правила детализируются 1. 2Правилами связи модулей по управлению0. Передача управле- ния вызываемому модулю всегда осуществляется через его начало, т.е. через первый оператор или команду, а выход из вызываемого модуля всегда происходит через его естественное окончание, т.е. через последний оператор или команду. Модули низших уровней или одного уровня иерархии могут вызываться для исполнения только мо- дулями

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

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

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

1Тело модуля 0- последовательность операторов программы, обес- печивающих следующие функции модуля - сохранение регистров ПЭВМ для последующего восстановления при возврате управления вызывающему модулю - переключение по параметру, задающему точку входа в модуль, если его исполнение может начинаться с некоторого внутреннего оператора - выполнение операторов, реализующих функциональную задачу модуля - запись переменных в обменную зону вызываемого модуля, если вызывает другой с передачей ему параметров

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

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

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

вычислительная последовательность0 заключается в последовательном преобразовании или перемещении совокупности всех исходных переменных. Элементарные конструкции при этом поочередно следуют друг за другом, причем конец предыдущего оператора замы- кается на начало последующего. 2. 2Альтернатива0 состоит в проверке выполнения некоторого ус- ловия и в выборе одного или двух операторов преобразования данных в зависимости от реализации условия.

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

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

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

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

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

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

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

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

2. 2Массивы0, образующиеся из нескольких простых переменных по некоторым правилам объединения, упорядочения и имеющие собствен- ное имя, описание и структуру. Это обеспечивает возможность ис- пользования массива как единой законченной конструкции. Мощность массива характеризуется числом различных значений простых пере- менных, составляющих данный массив. Структура массива и правила упорядочения переменных определяются компромиссом между объемом

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

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

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

массива , что позволяет их объединять в разветвленную структуру и изменять направление поиска в зависимости от результатов проверки некоторого условия. 2Программы обмена с внешними абонентами0 включают - 1программы приема сообщений 0от систем передачи данных в АЭИС определяют буферную зону памяти и место для хранения поступившего сообщения, а также осуществляют его ввод в буферную зону в соот- ветствии с заданной дисциплиной -

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

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

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

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

фиксированные последовательности вызова программных модулей, состав и очеред- ность которых управляется небольшим количеством условий 1программы взаимодействия комплексированных ЭВС или процес- 1соров 0в составе АЭИС обеспечивают межмашинный обмен информацией и распределение функциональных задач по процессорам для обеспечения пропускной способности системы или с целью повышения надежности решения функциональных задач - 1программы взаимодействия с внешними накопителями 0позволяют существенно

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

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

с допустимыми пороговыми уровнями и подготавлива- ет решения на перестройку структуры системы при переходе значений загрузки через пороговые значения - 1программный диагностический тест 0контролирует основные уст- ройства системы без изменения информации, накопленной в оператив- ной памяти при решении функциональных задач - 1контрольная задача 0имитирует решение основных функциональ- ных задач по подготовленным и зафиксированным сообщениям с точным сравнением результатов с известным эталоном -

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

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

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

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

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

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

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

АЭИС. В 2режиме начального пуска 0подготавливаются необходимые ис- ходные данные для последующего функционирования АЭИС в заданных режимах. В процессе рабочего функционирования АЭИС режим пуска включается только при появлении отказов. 2Режим тестового контроля и поиска неисправностей 0разделяется на два подрежима контроля - с помощью специальных диагностических тестов - с помощью контрольных задач, являющихся частью всей систе- мы,

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

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

1рабочего функционирования АЭИС при малой и средней загруз- 1ке 0системы включается основная масса программ решения функцио- нальных задач и устанавливается нормальный темп включения перио- дических программ - 1предельной загрузки 0 1и перегрузки системы0 рабочий режим перестраивается для обеспечения решения основных функциональных задач с допустимыми задержками и потерями входной и выходной ин- формации. Проектированием программного обеспечения завершается второй уровень

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

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

ность АЭИС в целом. Решение задачи выбора зависит от заданных ис- ходных требований и связано с решением задачи разработки прог- раммного обеспечения, поскольку о определенные функции могут вы- полняться как аппаратными, так и программными способами. Типы ап- паратных средств не могут выбираться изолированно друг от друга, т.к. они должны быть совместимыми по входной и выходной информа- ции и по физическим параметрам входных и выходных сигналов. Информационная совместимость предполагает единые способы ко-

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

СПИ в составе АЭИС являются прием информации от средств управления, а также от вншних источников сообщений нпосредственно или через средства передачи данных выполнение арифметических и логических операций в ходе реализации алгормитма управления объектом урав- ление процессами обмена с системами обработки информации СОИ , системами управления и внешними запоминающими устройствами ВЗУ обмен информации с ВЗУ, выдача информации на СОИ или внешним пот- ребителям непосредственно через

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

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

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

печатающее устройство прин- тер , обеспчивающее получение твердых печатных копий экрана в т.ч. графических и цветных . Однопроцессорные П ЭВМ общие принципы построения схем од- нопроцессорной системы Обработка данных производится арифмети- ко-логическим устройством АЛУ под управлением центрального уст- ройства управления ЦУУ . ЦУУ вырабатывает необходимые управляю- щие сигналы для выборки очередной команды из памяти, дешифрации

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

Для большинства П ЭВМ структура памяти может быть представ- лена как двухуровневая система внутренняя память верхний уро- вень и внешняя память нижний уровень . Все ЗУ, входящие в состав внутренней памяти, предназначены для записи, хранния и выдачи команд и оперативной информации, не- посредственно участвующей в данный момент времени в процессе вы- числений. Внешняя память предназначена для более длительного хра- нения информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

МП с фиксированной и с наращиваемой разрядностью. Фиксиро- ванную разрядность обычно 8 или 16 имеют МП первого типа, вы- полняющие фиксированный набор команд. Операнды большей разряднос- ти обрабатываются с помощью такого по частям, обычно байтами по 8 разрядов . Обработка байтов выполняется последовательно, поэто- му быстродействие при работе с многоразрядными кодами существенно уменьшается. МП с наращиваемой разрядностью обычно содержат 2 или 4 разряда.

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

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

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

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

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

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

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

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

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

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

разделении каналов. 11. Проектирование программного обеспечения автоматизирован- ных экономических информационных систем АЭИС система языков проектирования программ комплексирование программ средства ав- томатизации разработки программ 23.1 Эффективность технологий проектирования во многом определя- ется языками проектирования, обеспечивающими общение специалис- тов-разработчиков со средствами автоматизации их труда. Унифика- ция языков проектирования позволяет обмениваться программными средствами или их компонентами,

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

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

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

конкретные ЭВМ, разработчиками функциональных программ и специалистами по комплексированию прог- раммных компонент. Характеристика языков проектирования 1Языком управления заданиями0 обеспечиваются все этапы техно- логии. Технологические системы оснащаются монитором с языком уп- равления заданиями, в т.ч. управления базой данных в различных режимах. Эти достигаются переносимость технологической системы и унификация управления ее работой. Язык управления заданиями представляет собой набор директив, имеющих фиксированный

синтак- сис. Для таких действий, как управление БД и диалог, набор дирек- тив стандартизирован для других функциональных подсистем набор директив определяется их функциями. Элементами являются диагнос- тические сообщения об обнаруженных ошибках. 1Язык подготовки технологических средств 0доступен настройщи- кам пс на среду функционирования. В него включается раздел, представляющий собой пакет описания общих типов данных, их атри- бутов и

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

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

1Языки программирования 0поддерживают этап разработки прог- рамм. К программам ЭВМ предъявляются высокие требования по эффек- тивному использованию вычислительных ресурсов. К этой группе от- носятся алгоритмические языки,макроязыки и автокоды. 2Алгоритмические языки 0при конкретном применении являются подмножеством базового языка. Основными свойствами алгоритмичес- ких языков являются типизация языка, возможность определения но-

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

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

2Автокоды 0 ассемблеры , в которые включаются макросредства системные и структурные макрокоманды , обеспечивающие интерфейс между программами, записанными на языках более высоких уровней, а также структуризацию программ. 1Языки, используемые на этапе отладки программ 0обеспечивают проведение контроля результатов работы программы по различным ис- ходным данным. Этот тип включает язык отладки в статике, который дает возможность задавать указания о режимах отладки, исходные данные и состав выходных результатов язык

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

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

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

программ. 2Методы контроля программ0. Контроль состоит в проверке вход- ной программы на соответствие некоторым формальным правилам он подразделяется на лексический, синтаксический и семантический. 1Логический контроль текста 0решает задачи выявления символов, не принадлежащих к алфавиту входного языка и групп выделенных символов, не принадлежащих к системным символам и символам конк- ретного представления языка. Обычно лексический контроль совмеща- ется с кодированием символов во внутреннее представление

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

логика которых основана на неформализованных прави- лах синтаксиса и семантики языка. 2Методы размещения переменных 0используются с применением плотной упаковки в памяти многоразрядных ЭВМ. Используются такие способы размещения при которых аппаратная выборка реализуется ми- нимальным числом команд или за наименьшее время. Среди переменных, используемых в программе, выделяются вход- ные и выходные параметры, которыми обмениваются программы, непос- редственно вызывающие друг друга.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разработки программных модулей, групп и комплексов программ, используемых данных и связей. Эти аспекты тесно связаны и сложность объекта обычно определяется че- рез трудоемкость процесса разработки. Понятие сложности ассоциируется с ресурсами, необходимыми для решения соответствующей задачи. Для программ наиболее харак- терными являются ресурсы, необходимые для их реализации, которые определяют временную, программную и информационную сложность 1Временная сложность программ 0в основном определяется

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

ЭВМ ограничивают допустимую пол- ноту отладки и объем получаемых результатов. 1Программную сложность 0в простейшем случае можно оценить по числу символов в тексте программы, необходимому для ее полного описания на некотором алгоритмическом языке,или по числу операто- ров команд при реализации программы на ЭВМ. Разнообразие алго- ритмических языков и структур команд ЭВМ затрудняет обобщенные оценки и сравнение программной сложности различных программ.

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

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

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

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

организации вычислительного процес- са, расположенные на высших уровнях они почти не выполняют вы- числений, имеют на входе небольшое число преимущественно логичес- ких переменных и выдают управляющие воздействия на вызовы функци- ональных модулей объем обычно невелик и составляет около 100 операторов на ассемблере - основные функциональные программы - на средних уровнях наиболее сложные для разработки эти модули имеют в среднем 200 300 операторов ассемблера или около 50 операторов на языке высокого уровня, общее

число глобальных переменных составляет в среднем около 20 на каждый модуль - стандартные программы для вычисления различных функций - на нижних уровнях наиболее просты при разработке предназначены для вычисления стандартных функций и решения типовых простейших задач имеют обычно простую структуру без циклов, объем - в пре- делах 30 100 операторов на ассемблере, число переменных как на входе, так и на выходе, составляет 3 5, а число маршрутов испол- нения программы не превышает 10 .

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

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

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

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

на каждом уровне увеличивается по мере снижения уровня, однако медленнее, чем в регулярном бинарном де- реве. Структуры второго вида содержат один или несколько модулей, вызывающих последовательно большое число 5 10 модулей более низкого уровня. Характеристики взаимодействия между модулями значительно различаются в зависимости от их расположения в структуре. 1Управляющие программные модули 0характеризуются слабой инфор- мационной связью со всеми остальными. Они практически не обраба- тывают информацию и не используют

глобальные переменные. Возвраты к управляющим программам производятся по стандартным правилам и могут происходить из нескольких модулей каждой группы программ. 1Функциональные программные модули 0характеризуются широким разнообразием характеристик взаимодействия. Число переменных, считываемых из памяти для обработки модулем, в среднем больше, чем число глобальных переменных. 1Стандартные программные модули 0относительно редко вызывают другие программы обычно такие

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

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

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

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

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

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

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

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

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

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

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

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

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

2Методы распределения ресурсов первого типа 0характеризуются полной априорной информацией о моментах поступления данных, дли- тельностью их обработки, об объеме памяти,необходимом для хране- ния исходных сообщений, программ и массивов данных, о связях меж- ду программами. При этом составляется план последовательности ис- пользования основных ресурсов системы на длительный интервал вре- мени. Затраты на распределение ресурсов являются однократными и могут быть произведены

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

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

оценок потребления ресурсов. Такие оценки позволяют перераспределять поступившие сообщения и реализовывать в первую очередь те, кото- рые требуют минимальных объемов памяти или производительности ВС. Чтобы получить результаты, пригодные для практического ис- пользования, целесообразно разделить сложную вычислительную ин- формационную систему на частные модели. 2Модель однопроцессорной системы без внешней памяти 0характер- на для управления объектами с малым

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

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

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

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

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

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

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

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

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

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

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

1боре задач0 является критерием ее эффективности в целом и методов распределения ресурсов в частности. Возникает задача определения оптимальных параметров системы для решения некоторой совокупности задач с учетом 1качества распределения ресурсов и затрат на их ре- 1ализацию. 2Критерии эффективности распределения ресурсов по штрафам.0. Ожидание результатов и пропуск решения задач можно описать неко- торыми потерями эффективности или штрафами

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

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

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

дисциплина обслуживания заявок в порядке поступления. В зависимости от диапазона изменения значений длительностей обслуживания и щтрафрв за ожидание а также от загрузки и коэффи- циентов вариации времени обслуживания имеется возможность оцени- вать 1рациональное количество приоритетнвх уровней0. Для исследо- ванных моделей и приоритетных дисциплин целесообразно проводить группирование типов заявок по приоритетным уровням в пределах 6 8 приоритетов для дисциплины

с относительными проритетами и 10 16 - для дисциплины с абсолютными приоритетами. Диспетчеризация с относительными или или абсолютными прио- ритетами дает заметный выигрыш в эквивалентной производительности ЭВМ при весьма ограниченном количестве приоритетных уровней, ког- да длительности решения отдельных задач или штрафы за ожидание их результатов различаются не менее чем на порядок. При этом число выделяемых приоритетных уровней целесообразно ограничивать в пре- делах 10 15, т.к.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АЭИС структурная схема комплексной системы автоматизации сложных АЭИС 26.1 Автоматизация технологии проектирования информационных сис- тем реализуется в 2инструментальных системах автоматизации0. Требо- вания к которым зависят от сложности объектов разработки, имею- щихся ресурсов создания систем, ряда конструктивных и организаци- онных факторов, и состоят в следующем снижение общей трудоемкос- ти, длительности создания АЭИС и повышение производительности труда специалистов в

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

и опыта разработки сложных АЭИС сформировались технологичес- кие принципы, которые состоят в следующем 2Комплексная автоматизация регламентированного технологичес- 2кого процесса 0разработки и сопровождения АЭИС, определяющая авто- матизацию всех функционально связанных этапов и операций техноло- гического процесса. Это достигается созданием общей базы данных проектирования, в которой хранятся все компоненты АЭИС во всех формах представления. 2Адаптивность кросс-технологии 0предполагает создание универ- сальных

кросс-систем автоматизации разработки АЭИС, которые наст- раиваются на характеристики реализующих ЭВМ и и обеспечивают еди- ную унифицированную технологию. 2Разделение труда и регламентация результатов этапов работ являются основой для разграничения ответственности специалистов разной квалификации за качество конечного продукта - модуля прог- раммы, системы и т.д. 2Долгосрочное и оперативное планирование работ0, т.е. система- тическое поэтапное планирование работ

коллектива на основе имею- щихся ресурсов. 2Рациональное диалоговое общение 0со средствами автоматизации предполагает комфортное общение специалистов с инструментальными средствами безбумажная технология . Принципы проектирования определяют построение АЭИС и методы достижения их высокого качества, которые состоят в следующем 2Модульно-иерархическое структурное построение 0предполагает организацию связей между модулями. одновременно этот принцип оп- ределяет необходимость упорядочения внутренних структур

модулей, массивов данных и системы в целом. 2Переносимость компонент 0определяет реализацию многократного использования разработанных компонентов, в т.ч. для различных ре- ализующих ПЭВМ. 2Раздельная компиляция 0модулей на основе упреждающей разра- ботки БД предполагает первоочередную разработку описаний глобаль- ных данных, хранение этих описаний в базе данных проектирования, и организацию на этой основе независимой компиляции модулей.

2Эффективное использование памяти 0стимулирует использование при проектировании методов, минимизирующих затраты ресурсов памя- ти реализующей ЭВМ. 2Систематическое описание компонент 0приводит к созданию сис- темы взаимосопряженных языков проектирования разного уровня и назначения, позволяющих регулярно описывать различные свойства АЭИС и ее компонент на разных этапах разработки и сопровождения. 2Многоэтапная систематическая отладка 0компонент АЭИС призвана обеспечить корректность и надежность

создаваемой системы путем последовательного применения методов тестирования и отладки. 2Автоматическое документирование в соответствии с нормативны- 2ми требованиями 0определяет создание средств автоматизации выпуска эксплуатационной и сопровождающей документации на АЭИС и ее ком- поненты, соответствующей требованиям стандартов и нормативов. При проектировании и разработке конкретных АЭИС состав средств автоматизации может существенно изменяться.

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

АЭИС и группы программ описание структуры АЭИС оценки производитель- ности ПЭВМ для реализации АЭИС моделирования функционирования АЭИС на параллельных вычислительных системах. Подготовка технологических средств подготовка базы данных проекта АЭИС адаптация системы автоматизации к конкретным усло- виям разработки АЭИС контроля и управления процессом разработки Разработка программ управления базой данных проекта

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

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

Испытания системы измерения характеристик функционирования АЭИС в реальном времени учета и анализа версий АЭИС имитации расширенных характеристик внешней среды производства и контроля качества тиражируемых АЭИС. Указанные средства обеспечивают минимальные затраты на соз- дание АЭИС, заданные сроки разработки или оптимизацию техни- ко-экономических показателей.

Их использование обусловлено воз- можностями и дифференцируется в зависимости от уровня автоматиза- ции предусмотрено 5 соответствующих уровней . Переход от одного уровня к другому, более высокому, дает возможность повысить сте- пень автоматизации примерно в 1.5 раза. Систему автоматизации АЭИС можно условно разделить на следу- ющие крупные компоненты базу данных проектирования организующую систему систему автоматизации системного анализа систему авто- матизации программирования

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

информации технологичес- кая, предназначенная для размещения основных средств системы ав- томатизации разработки моделирующая, реализующая средства имита- ции внешней среды и обработки результатов отладки. 2Выходными данными .0системы автоматизации разработки САР яв- ляются отработанные программы на машинных носителях, результаты обработки тестовых данных комплексом программ, обобщенные резуль- таты функционирования

АЭИС и отпечатанные документы различного назначения. Отработанные на технологической ЭВМ компоненты систе- мы подготовляются и кодируются на машинных носителях информации для ввода в реализующую ЭВМ. 2База данных .0предназначена для упорядоченного хранения и кор- ректировки большого количества информации, отражающей состояние и изменение разрабатываемой системы. В БД накапливается вся исход- ная, промежуточная и результирующая информация, характеризующая

АЭИС и ее переменные, особенности системы, а также процесс ее создания. В библиотеке проекта накапливаются данные, необходимые для описания характеристик системы и для распределения памяти ар- хивов, с учетом решаемых функциональных задач и характеристик создаваемой АЭИС. Библиотеки технологических и промежуточных дан- ных предназначены для длительного хранения информации, подготав- ливаемой средствами САР. В отдельной библиотеке накапливаются и обобщаются данные о состоянии

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

АЭИС. Для связи пользователей с системой автоматизации и для рас- шифровки их директив служит монитор. Средства управления БД обес- печивают контроль и корректировку информации на магнитных носите- лях, а также каталогизируют всю поступающую и изменяемую информа- цию. Для управления процессом разработки сложной АЭИС используют средства, осуществляющие сбор, обобщение и редактирование информа- ции о состоянии разработки компонент

АЭИС и о результатах дея- тельности каждого специалиста-разработчика. 2Система автоматизации системного анализа.0. Состав средств этой системы и методы решения задач полностью зависят от назначе- ния, функций и области применения разрабатываемой АЭИС. 2Система автоматизации программирования .0обеспечивает трансля- цию программ с нескольких входных языков программирования. Транс- ляция и обработка спецификаций производится для проверки в про- цессе

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

Окончательное редактирование связей и присвоение исполнительных адресов производится загрузчиком. 2Система автоматизации отладки .0на технологической ЭВМ содер- жит средства для символической отладки программ по исходным текс- там, а также для детерминированной и статистической отладки в процессе исполнения протранслированных программ. Для структурного контроля, а также для расчета длительностей исполнения программ и автоматизированного

построения блок-схем используются графовые модели программных модулей. 2Система автоматизированного выпуска документации и машинных 2носителей .0на системы обеспечивает подготовку и изготовление доку- ментов трех типов конструкторских, необходимых для для произ- водства, контроля и эксплуатации АЭИС технологических, использу- емых в процессе разработки, испытаний и сопровождения АЭИС исс- ледовательских, необходимых для анализа проектируемой системы и процесса ее разработки с целью

повышения качества и снижения тру- доемкости создания. Для регистрации на машинных носителях служат средства, обес- печивающие перенос разработанной АЭИС или ее компонент из техно- логической ЭВМ в реализующую. Этот перенос в ряде случаев может быть произведен путем непосредственной передачи информации по те- лекодовым каналам связи. 2Система программной имитации внешней среды.0.

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

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

после за- вершения одного или серии экспериментов. Методика обработки и анализа результатов экспериментов при испытаниях системы должна обеспечивать единство взглядов заказчи- ка и разработчика системы и не допускать искажений интерпретации результатов за счет неоднозначности методики. 2Система динамической отладки .0на реализующей специализиро- ванной ЭВМ функционирования АЭИС в реальном времени управляется внешними и внутренними сообщениями.

В соответствующих системах, реализуемых на на универсальных П ЭВМ, активно используется ряд компонент, входящих в типовые операционные системы и пакеты прик- ладных программ, широкого назначения системы управления БД, трансляторы с языков программирования, текстовые редакторы, доку- ментаторы и т.д Эти компоненты целесообразно комплексировать в единую систему автоматизации, поддерживающую определенную техно- логию проектирования.

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

разработки обычно невелики и составляют 1 2 от тру- доемкости всей разработки. Совокупность работ, обеспечивающая адаптацию машинно-зависимых компонент, составляет 2подготовка языков программирования0 1подготовка автокода 0включает формирование его лексики, син- таксиса и семантики проводя последовательную стандартизацию ком- понент АЭИС, можно получить различную степень унификации операто- ров автокода и, как следствие, различный

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

различные диалекты алгоритмического языка, адаптиро- ванные к специфическим условиям применения. 2подготовка базы данных проектирования 0обеспечивает выбор объемов библиотек, входящих в базу данных состав библиотек опре- делен в кросс-системе и закрепляется для разработки любых АЭИС. Кроме того на этом этапе осуществляется запись в библиотеку мак- роопределений системных макрокоманд. 2подготовка машинно-зависимых компонент 0является наиболее сложной и трудоемкой задачей, включающей 1подготовка

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

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

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

АЭИС методы проектирования систем с заданными надежностью 25.1 Надежность сложных ПС определяется двумя факторами 1надеж- 1ностью компонент и ошибками в конструкции0, допущенными при проек- тировании. Доминирующим является второй фактор . Следует определить фундаментальные понятия теории надежности применительно к анализу характеристик функционирования программ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1Защита от искажения взаимного прерывания программ0, приводя- щих к возможности взаимной блокировки некоторых типов прерываний, осуществляется в основном аппаратными методами. Для защиты от та- ких программных ошибок, а также от от аппаратных сбоев при преры- ваниях должны предусматриваться программный контроль выполнения прерываний и периодический контроль наличия взаимодействия со всеми абонентами. 1Защита от ошибок, приводящих к пропуску программ или их су-

1щественных частей0, производится в основном методами контроля ключевых кодов, определяющих перечень программ, которые должны быть включены предшествования программ и изменения отдельных пе- ременных. При обнаружении пропуска программы при ее завершении производится повторное включение всей функциональной группы. В отдельных случаях осуществляется автоматическое принудительное включение пропущенной программы. 1Защита от перегрузки ЭВМ по пропускной способности 0предпола- гает обнаружение и снижение влияния

последствий алгоритмических ошибок, обусловленных неправильным определением необходимой про- пускной способности ЭВМ. Перегрузки могут быть также следствием неправильного функционирования источников информации и превышения интенсивности потоков сообщений. Последствия сводятся к прекраще- нию решения некоторых функциональных задач, обладающих низким приоритетом. 1Защита от искажения и потери накопленной информации 0предус- матривает контроль результатов перед

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

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

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

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

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

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

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

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

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

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

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

ПС. 16. Проектирование автоматизированных экономических информа- ционных систем на базе персональных ЭВМ особенности и технологи- ческие аспекты проектирования АЭИС, создаваемых на основе ПЭВМ обоснование выбора состава автоматизированных функций при созда- нии и проектировании АЭИС 31.1 . Персональные ЭВМ ПЭВМ представляют собой особый класс средств вычислительной техники. Они отличаются высокой надеж- ностью, дешевизной, компактностью, малым потреблением энергии.

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

необходимость которой вызвана условиями их ориентации на индивидуальное использование непрофессионалами в области применения средств вычислительной техники. Возможность использования ПЭВМ пользователем-неспециа- листом в области систем обработки данных куда относятся и АЭИС обусловлена прежде всего удобством сравнительно недорого гибкого и универсального программного обеспечения. Отличительной особенностью ПЭВМ в области программного обес- печения является то, что при

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

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

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

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

и других средств орг- техники. На основании всей совокупности требований сложилась кон- цепция построения и проектирования информационной системы. При построении АЭИС на базе ПЭВМ, оснащенного интегрирован- ными программными средствами, следует учитывать, что между ПЭВМ и пользователем нет промежуточного звена оператора или программис- та . Следовательно, ПЭВМ должны быть настроены на решение задач конкретной предметной области и адаптированы

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

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

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

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

конечного пользователя. Унификация пользовательского интерфейса проектируемых АЭИС предполагает максимальное единство средств и способов организации работы пользователя с различными пакетами программ, входящими в систему. Он требует единой организации меню и функциональной кла- виатуры, структуры экрана, выдачи поясняющих сообщений и работы с объектами обработки - текстами, частями таблицы, фрагментами баз данных, графиками. Для реализации этого принципа применяются - унифицированная структура

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

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

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

следующие вариан- ты использования ПЭВМ, характеризующиеся особенностями технологи- ческого подхода к проектированию информационных систем для реше- ния экономических задач 1 автономное использование изолированные автоматизирован- ные рабочие места - АРМы 2 использование ПЭВМ в составе локальных сетей 3 использования ПЭВМ в качестве интеллектуальных терминалов больших или средних

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

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

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

Работы по созданию и, следовательно, проектированию удобных для пользователей систем основываются на подборе более подходящих моделей человеко-машинного взаимодействия, учете особенностей оп- ределенных сфер применения автоматизированных систем. Выбор состава автоматизированных функций при создании и про- ектировании АЭИС .включает следующие этапы 1 этап - выявление и формулировку обобщенной функции дея- тельности структурного звена в организационной структуре объекта.

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

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

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

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

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

для различных вариантов технической реализации АЭИС. При этом необходимо учитывать 1 устойчивость процедур, функций и ядра к возможным измене- ниям организационной и технологической структур, а также хозяйс- твенного механизма 2 компактность реализации функций структурного звена 3 временную последовательность одновременность их реали- зации 4 трудоемкость автоматизации процедур и функций. 17. Проблемы выбора языка программирования при проектирова- нии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

на основе ПЭВМ структурирование программ на уровне модулей раз- дельно компилируемые модули библиотеки процедур генерация объ- ектных модулей и загрузочных файлов библиотеки объектных моду- лей реализация сегментированных программ с перекрытиями 4.2 При создании прикладного программного обеспечения ППП АЭИС на основе ПЭВМ большая часть программных модулей составляется на языках высокого уровня ЯВУ . Имеется несколько вариантов органи- зации их взаимодействия, основанных на свойствах

ЯВУ, и на осо- бенностях операционных систем. Часто возникает необходимость программирования машинно-зависимых частей на языке ассемблера или макроассемблера, в связи с чем встает задача организации взаимо- действия программ на ЯВУ с программами на ассемблере. При проектировании большой АЭИС с самого начало необходимо решать несколько принципиальных вопросов, касающихся общей струк- туры системы и способов взаимодействия отдельных компонентов.

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

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

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

Самый простой способ разработки программ не предполагает применения ка- ких-либо приемов деления их на модули или на сегменты. Для сос- тавления такой программы обычно используется текстовый редактор общего назначения Редактор - текст программы - Интерпретатор или редактор, вст- L T L L T роенный в систему. Процесс разработ- L пользователь ки программы соот- L ветствует общей схеме, изображенной на рисунке.

Простейшая программа на паскале, печатающая на экране слово АЭИС может выглядеть следующим образом Более сложные программы включают описа- PROGRAM Test ния типов данных, переменных констант. Важ- BEGIN нейшими компонентами программ на ЯВУ являю- WRITELN АЭИС тся процедуры и функции, которые обеспечи-

END. вают структуризацию программ на уровне ис- L ходных текстов. Так, например, общая струк- тура программы на паскале может иметь вид В этом тексте мож- PROGRAM имя-программы параметры программы но выделить 3 ос- описания глобальных объектов программы - новных компонента типов данных, переменных, констант - заголовок про- PROCEDURE P1 параметры процедуры P1 граммы - название, описание локальных объектов процедуры

P1 список параметров, BEGIN описания типов, тело процедуры P1 глобальных пере- END менных, констант PROCEDURE P2 параметры процедуры P2 - описания про- описание локальных объектов процедуры P2 цедур - их заголо- BEGIN вки с описаниями тело процедуры P2 параметров и тела, END состоящие из вы- ражений

BEGIN - тело програм- начало тела программы мы - последовате- P1 обращение к Р1 льность выражений, P2 обращение к Р2 среди которых вст- конец тела программы речаются обращения END. к определенным вы- L ше процедурам. Структуризация программы на уровне исходного текста обеспе- чивается оформлением отдельных частей алгоритмов в виде процедур и последующему вызову этих процедур

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

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

L программ иметь дело с относительно неболь- шими фрагментами текста, каждый из которых содержит определенную группу функций. Раздельно компилируемые модули Если составленная программа велика по объему содержит от 500 до 100 и более строк , то про- цесс трансляции может занимать довольно много времени - до нес- кольких минут, что Неудобно при интенсивной отладке, когда прихо- дится часто вносить небольшие изменения в исходные тексты и вновь транслировать программу.

Чтобы этого избежать, применяется другой подход к построению больших программ - составление отдельных мо- дулей, которые транслируются совершенно независимо друг от друга и должны связываться лишь на стадии окончательного формирования исполняемой программы в машинных кодах. Так, в некоторых реализациях языка паскаль можно использо- вать два типа раздельно компилируемых модулей MODULE и UNIT. Модуль MODULЕ внешне оформляется почти как главная программа.

Его целью является описание Модуль P1.PAS нескольких взаимосвязанных MODULE P1 процедур вместе с необходи- PROCEDURE PP1 A INTEGER PUBLIC мыми типами, переменными и BEGIN константами. Тело у модуля тело процедуры PP1 обычно отсутствует. END Описанные в этом моду- PROCEDURE PP2 B REAL PUBLIC ле процедуры

РР1 и РР2 сна- BEGIN бжены специальными указате- тело процедуры PP2 лями PUBLIC , которые сви- END детельствуют об общедоступ- BEGIN ности этих процедур для END. других программ. Чтобы использовать эти L процедуры в главной програм- ме и в других модулях, их необходимо объявить следующим образом Указатель EXTERNAL PROCEDURE PP1

A INTEGER EXTERNAL свидетельствует, что объя- PROCEDURE PP2 B REAL EXTERNAL вленные таким образом про- L цедуры являются внешними по отношению к тому модулю, который их использует. Однако обраще- ния к ним в его теле имеют обычный вид, и внешние процедуры не от- личаются от тех, которые описаны непосредственно в данном модуле. Этот способ применяется не только при модульном программиро- вании в рамках одного

ЯВУ, но также и при составлении программ из модулей на разных языках или разных функциональных пакетах. Глав- ная проблема в этом случае состоит в правильной передаче парамет- ров процедур и функций, посколько в разной программной среде па- раметры могут обрабатываться по-разному. Библиотеки процедур Модуль типа UNIT, который можно назвать иначе блоком , описывается с помощью следующих компонентов. Один из них 1реализация блока0 со- Реализация блока

P2.PAS держит тела процедур и вспо- IMPLEMENTATION OF P2 могательные типы, переменные PROCEDURE get key и константы. Другой компо- BEGIN нент - 1описание 0 1блока 0 или тело процедуры get key 1интерфейс0 - содержит описа- END ния типов, переменных и кон- описания и тела других процедур стант,а также заголовки про- BEGIN END. цедур без их тел , которые L предназначены для использо- вания в

P2.INT других мо- INTERFACE дулях и UNIT P2 в главной get key, key descr, имена других процедур программе. TYPE key descr RECORD scan code, ascii byte end В интер- PROCEDURE get key фейс бло- ка включа- заголовки других процедур данного блока ется общий список имен, END указанных объектов, L что дела- ет их видимыми из других модулей. Использование объектов модуля типа UNIT в главной программе требует включения включения его интерфейса

перед заголовком прог- раммы, и упоминания имени блока Главная программа сразу после заголовка программы, INCLUDE P2.INT для чего служит выражение вида USES имя блока PROGRAM PP input, output Начальная часть программы USES P2 приобретает в результате вид, пре- дставленный на схеме слева.

Здесь текстовое включение интер- L фейса блока Р2 в программу РР.PAS осуществляется с помошью рассмотренного выше выражения INCLUDE. Генерация объектных модулей и загрузочных файлов В резуль- тате компиляции отдельных текстовых модулей порождаются объектные модули Например, обращение с целью трансляции исходной программы

PP.PAS имеет вид Объектный модуль, который порождается после PAS1 PP двух проходов трансляции PAS1 и PAS2 , можно счи- PAS2 тать полуфабрикатом - куском машинного кода, го- L товым к превращению в загрузочный файл Объектный модуль заносит- ся в особый файл, которому придается тип OBJ. Для рассматриваемо- го примера этот процесс можно изобразить следующей условной схе- мой

PP.PAS транслятор PP.OBJ Следующий этап состоит в преобразовании совокупности отдель- ных объектных модулей в загрузочный файл типа ЕХЕ или СОМ. Этот процесс называется связыванием объектных модулей. или сборкой за- дачи Соответствующая схема преобразования РР.ОВJ PP.EXE или PP.OBJ PP.COM Этот этап реализуется специальной системной программой LINK, которую называют редактором связей. или компоновщиком

При обраще- нии к LINK указываются все объектные модули, которые должны объ- единены в общую программу указывается также имя файла с резуль- тирующей программой, имя файла с листингом необязательный пара- метр и имя файла с библиотекой процедур LINK PP P1 P2 PP PP.LST PASLIB.LIB объектные загрузоч- файл- библиотека модули ный файл листинг процедур Один из способов оформления независимых частей программ сос- тоит в создании библиотек объектных модулей

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

новая-библиотека При обращении к LIB могут указываться имена старой и новой библиотеки. Размер страницы 16, 32 512 задает величину бу- фера для обмена это необязательный параметр. Главные действия задаются1 операциями0. Операция может иметь следующие разновидности mm - имя модуля mm добавление модуля в библиотеку mm удаление модуля из библиотеки , mm извлечение модуля из библиотеки mm замена модуля в библиотеке mm извлечение модуля с удалением ,

Пример обращения к LIB LIB OLDLIB P2, ,NEWLIB Такое обращение вызывает создание новой библиотеки NEWLIB из старой OLDLIB c добавлением отдельно оттранслированного модуля Р2. После того, как библиотека создана, достаточно упомянуть ее имя при связывании объектных модулей в единую программу. Обращение к библиотечным процедурам в главной программе или в другом модуле требует их упоминания в начале программы с указа- телем EXTERNAL также как и в случае использования модулей

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

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

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

Методы структурирования обеспечивают независимую разработку отдельных частей прикладной системы однако получаемый в результате испол- няемый программный код представляет собой единый файл, который при вызове программы должен полностью разместиться в оперативной памяти. Это далеко не всегда устраивает разработчиков системы. Необходимы способы деления программ на такие части 1сегменты0 , которые могли бы постоянно находиться

во внешней памяти и загру- жаться в оперативную память лишь по мере необходимости. В развитой системе программирования, базирующейся на ЯВУ ти- па паскаль, распространенным приемом такого деления программ на части основан на создании1 перекрывающихся оверлейных сегментов0, при котором программа составляется из отдельных кусков, во время работы они могут по мере необходимости загружаться в оперативную память и частично накладываться друг на друга.

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

Точно так же происходит PROGRAM PP input,output по мере необходимости загрузка дру- гих сегментов из внешней памяти. OVERLAY PROCEDURE P1 Пример объявления оверлейных BEGIN процедур, тела которых после транс- тело процедуры P1 ляции попадают в соответствующие END оверлейные файлы, приведен на схеме. OVERLAY PROCEDURE P2 Трансляция такой программы BEGIN приведет к созданию трех перекрыва- тело процедуры

P2 ющихся сегментов END РР.СОМ РР.000 РР.001 PROCEDURE P3 Первый из них - РР.СОМ - соот- BEGIN ветствует главной программе, два тело процедуры P3 других сегмента - оверлейные. При END этом процедуры Р1 и Р2 попадут в OVERLAY PROCEDURE P4 сегмент РР.000, поскольку в исход- BEGIN ном тексте их описания следуют од- тело процедуры

P4 но за другим. Процедура Р4 окажется END во втором оверлейном сегменте - РР. 001. Такое разделение обусловлено BEGIN тем, что описание Р4 отделено от P1 описаний двух первых процедур внут- END. ренней не оверлейной процедурой L Р3. Получившаяся структура програм- мы может быть отображена схемой, представленной на на рисунке Корневой сегмент

РР.СОМ Оверлейный сегмент РР.000 код программы код процедуры Р1 код процедуры Р2 область для оверлейных L сегментов Оверлейный сегмент РР.001 код программы L код процедуры Р4 L L 19. Организация взаимодействия программ АЭИС на основе ПЭВМ через прерывания ДОС на языке ассемблера особенности ассемблер- ных процедур резидентные программы

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

В их число входит несколько функций, с по- мощью которых может быть организован взаимный вызов программ. Функция 31 Н символ Н означает, что число является шестнад- цатиричным останавливает данную программу и оставляет ее в опе- ративной памяти резидентной, что дает возможность позднее вновь обратиться к ней через соответствующую 1точку входа0. Функция 4В Н обеспечивает вызов загрузку с диска и переход на исполнение другой программы. Когда вызванная программа закон- чится, управление автоматически передается вызывавшей

программе. Имеется вариант этой функции, когда файл только загружается с диска, но не исполняется это используется для загрузки перекры- вающихся сегментов программ или загрузки данных. Функция 4С Н оканчивает работающую программу с засылкой в системный регистр AL1 кода возврата0. Этот код может быть взят и проанализирован вызвавшей программой, для чего используется функ- ция 4D. Функция 4D позволяет выяснить, по какой причине окончи- лась вызванная программа.

Причины могут быть следующие нормаль- ное окончание окончание в результате нажатия клавиш Ctrl Bre- ak окончание в результате фатальной ошибки внешнего устройства окончание в результате применения функции 31. Функции 48 Н и 49 Н позволяют соответственно запросить у ДОС оперативную память для работы программы и освободить ее. Функция 4А Н позволяет изменить уменьшить или увеличить выделенную па- мять.

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

Здесь параметр InterruptNo INTE- INTR InterruptNo, Registers GER - целое десятичное число, L указывающее номер прерывания. Параметр Registers - это список ба- зовых регистров микропроцессора Registers RECORD AX, BX, CX, DX, BP, SI, DI, DS, ES, Flags INTEGER END L При обращении к прерыванию ДОС необходимо сначала занести в ре- гистры нужные значения,

а после завершения прерывания из них мож- но извлечь результаты работы. Каждый из двухбайтовых регистров состоит двух однобайтовых полу регистров. Например, двухбайтовый регистр АХ состоит из двух однобайтовых - АН и AL. Однобайтовые регистры используются для передачи информации в ДОС. Так, по принятому в ДОС соглашению регистр АН служит для задания номера функции, вызываемой через

любое прерывание. Если, например, в прикладной программе применяется прерыва- ние 21 Н и через него вызывается функция 4В Н загрузка и запуск другой программы, то регистры заполняются следующим образом АН 4В - номер вызываемой функции AL - признак загрузки программы с исполнением AL 0 или без исполнения AL 1 DS DX - два указанных регистра содержат длинный адрес строки с расширенным именем файла ES BX - два этих регистра содержат длинный адрес управляю- щего блока запускаемой программы,

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

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

иногда составляются значительные фрагменты программ. В этих случаях возникает задача организации взаимодействия программ на ЯВУ с ассемблерными программами. Ассекмблерные прог- раммы могут объединяться с другими программами на уровне объект- ных модулей - с помощью компоновщика LINK. Главная проблема сос- тоит во взаимной передаче параметров между такими программами.

Предположим, имеется ассемблерная процедура для установки положения курсора в дисплейном окне, которая должна быть доступна из программ на паскале. Описание соответствующей процедуры в пас- каль-программе может иметь PROCEDURE CURPOS LINE INTEGER POS INTEGER вид EXTERNAL Соответс- L твенно обращение к этой процедуре в паскаль- программе может иметь вид CURPOS L, P Вызываемая программа на ассемблере имеет

L следующий вид WINDOW SEGMENT CODE начало сегмента с именем WINDOW PUBlIC CURPOS объявление общедоступной процедуры CURPOS CURPOS PROC FAR обеспечение дальнего вызова процедуры PUSH BP сохранение старого указателя на фрейм MOV BP, SP установка нового положения фрейма PUSH АХ сохранение старых значений регистров

PUSH ВХ АХ и ВХ MOV BX, BP 6 перенос в регистр ВХ 2-го параметра MOV AX, BP 8 перенос в регистр АХ 1-го параметра выполнение необходимых действий с использованием параметров, сохраненных в регистрах АХ и ВХ POP ВХ восстановление регистров ВХ POP АХ и АХ POP ВР восстановление старого указателя на стек RET 8 возврат из процедуры со сдвигом указателя стека на 8 байт назад

CURPOS ENDP конец тела процедуры WINDOW END конец сегмента WINDOW L В приведенном примере можно отметить несколько характерных деталей. Необходимо пояснить, что передача информации между вызы- вающей программой и данной процедурой осуществляется через1 стек - последовательность машинных слов, в которую данные заталкива- ются оператором PUSH и выталкиваются оператором POP. В стек ав- томатически заносятся также1 адрес возврата0 из процедуры.

На теку- щую ячейку стека указывается содержание регистра SP. В регистре ВР находится указатель на1 фрейм,0 т.е. на ту часть стека, в кото- рой хранятся данные, относящиеся к вызванной процедуре. Особенности ассемблерных процедур В начале процедуры проис- ходит сохранение в стеке старого значения регистра ВР, а также регистров АХ и ВХ, которые далее понадобятся для работы.

Затем происходит важная операция - из стека командой MOV извлекаются значения двух параметров заданных в обращении к паскаль-процеду- ре CURPOS как значения переменных L и Р . Эти значения заносятся соответственно в регистры АХ и ВХ и используются затем для выпол- нения основных действий - установки положения курсора в дисплей- ном окне. Положения параметров в стеке фиксированы относительно начала фрейма, заданного значением

указателя ВР. Первые 4 байта заняты адресом возврата и старым значением SP, еще 2 байта - ре- гистром счетчика команд, а параметры занимают по 2 следующих бай- та и поэтому адресуются конструкциями вида BP 6 и BP 8 . Следует иметь в виду, что при обращении к данной процедуре из паскаля стек заполняется от старших адресов к младшим, поэтому первый параметр находится дальше всего от позиции, на которую указывает регистр ВР. Если бы параметров было 4, то они бы адресовались с помощью

следующих выражений BP 6 - адрес 4-го двухбайтового параметра, BP 8 - адрес 3-го двухбайтового параметра, BP 10 - адрес 2-го двухбайтового параметра, BP 12 - адрес 1-го двухбайтового параметра. Важным моментом является то, что в данном моменте процедура CURPOS не меняет значений указанных параметров. Это позволяет пе- редать их из паскаль-программы1 по значению0, т.е. скопировать в стек. Если же предполагается изменение параметров в ассемблерной процедуре,

то их нужно передавать1 по ссылке0. Для этого описание процедуры CURPOS в паскаль-программе должно было бы содержать описания параметров с указателем VAR или VARS, т.е. иметь, напри- мер следующий вид В этом случае и извлече- PROCEDURE CURPOS VAR LINE INTEGER ние параметров в ассемб- VAR POS INTEGER EXTERNAL лерной процедуре должно

L быть оформлено по-друго- му. Сначала нужно извлечь из стека на параметр его адрес , а за- тем уже взять по этому адресу значение ячейки. Резидентные программы Часто бывает необходимо, чтобы слу- жебная программа сработала и осталась в памяти для того, чтобы могли позднее обращаться и другие программы. Такую программу на- зывают1 резидентной0, в отличие от обычных программ, которые по окончании работы освобождают занятую память.

ДОС-функция 31 Н осуществляет остановку программы и оставля- ет ее резидентной в памяти. К этой функции можно обращаться не- посредственно из программы на ЯВУ, если в нем обеспечивается дос- туп к прерываниям ДОС. Можно выполнить те же действия, используя соответствующую подпрограмму на ассемблере. Фрагмент программы на ассемблере, предназначенной для реали- зации указанной операции, имеет следующий

вид PUSH ES запоминание начала программы в стеке POP АХ выталкивание адреса начала MOV DX, SEG ZZ занесение адреса конца программы ZZ в регистр DX SUB DX, AX вычисление длины программы INC DX увеличение длины на 1 MOV АН, 31Н задание в регистре АН номера функции 31 Н остановить задачу и сделать ее резидентной

INT 21Н обращение к прерыванию 21 Н ZZ SEGMENT ZZ конец программы ZZ ZZ ENDS L Такая подпрограмма может быть соединена с любой другой прог- раммой на ЯВУ и использована для создания резидентной копии зада- чи. Связывание программ через потоки ввода вывода Существует способ организации взаимодействия программ, основанный на стан- дартном сервисе, предоставляемом

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

и выходом. В программе на ЯВУ стандартное входное и стандартное выход- ное устройства доступны через обычные операторы ввода вывода в паскале - READ и WRITE Известно, что такие операторы позволяют обмениваться с клавиатурой и дисплеем, не задумываясь о том, что здесь кроются более широкие возможности. В командной строке, обращенной к ДОС и предусматривающей за- пуск какой-либо программы, можно указать, откуда должен поступать в программу

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

Здесь символ from соответствует стандартному PP from to входному потоку, а символ to - стандартному L выходному потоку. Вместо символов from и to могут фигурировать имена файлов или зарезервированные имена внешних устройств CON , PRN , LPT 1, LPT2 , COM . COM1 , COM2 , AUX . следует помнить, что одни внеш- ние устройства работают только выходе принтер , другие только на входе диджитайзер , но есть и такие устройства, которые способны передавать информацию

в обоих направлениях модемы . Если источником или приемником информации для данной прог- раммы является другая программа, то используется иное обозначе- ние. Пример такого обозначения для трех взаимосвязанных программ В данном примере стандартный выходной поток РР1 PP2 PP3 программы РР1 связывается со стандартным вход-

L ным потоком РР2, а ее стандартный выходной по- ток, в свою очередь, поступает на стандартный вход программы РР3. Для обозначения таких цепочечных связей между программами используют термин канал англ. pipe . В ДОС такой канал реали- зуется с помощью временного файла, который операционная система сама создает в корневом каталоге и уничтожает после окончания ра- боты программ. В операционной системе Юникс этот же самый меха- низм реализуется при помощи внутренних файлов, благодаря

чему об- мен информацией между программами происходит гораздо быстрее. Программа, которая принимает данные со стандартного входа и передает их после обработки на стандартный выход называется 1фильтром0. К фильтрам относятся некоторые системные утилиты ДОС SORT, MORE. Программа-фильтр пропускает через себя соответству- ющую информацию, осуществляя ее переработку. Так, фильтр SORT обеспечивает сортировку пропускаемых через него текстовых данных

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

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

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

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

причин отклонения результатов тестирования от заданных эталонных значений или правил - изменение программы с целью исключения причин отклонения результатов от эталонных. Содержание тестирования систем программ Основным методом обнаружения ошибок при отладке является их 1тестирование0. Эффек- тивность тестирования - важнейший фактор, определяющий стоимость и длительность разработки сложных АЭИС с заданным качеством. Зат- раты на тестирование для обнаружения ошибок составляют 30-40 об- щих

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

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

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

данных , явившего- ся причиной отклонения полученных результатов от эталонных - 2контрольное тестирование0, состоящщего в подтверждении пра- вильности выполненной корректировки разрабатываемой системы. Каждая из категорий тестов отличается целевыми задачами, проверяемыми компонентами и методами оценки результатов. Совмест- ное и систематическое применение различных методов тестирования позволяет достигать высокого качества функционирования АЭИС.

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

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

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

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

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

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

в реальном вре- 1мени0. В процессе такого тестирования проверяются исполнение сис- тем программ и обработка исходных данных с учетом времени их поступления, длительности и приоритетности обработки, динамики использования памяти и взаимодействия с другими программами. Отладку АЭИС можно осуществлять при двух стратегиях наращи- вания числа компонент, подлежащих проверке. При систематическом восходящем тестировании. вначале проверя- ются модули нижних иерархических уровней,

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

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

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

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

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

в процессе обработки информации. 2Тестирование комплексов программ при отладке 0- сложный про- цесс, в котором завершается проверка корректности функционирова- ния программ при правильных исходных данных и осуществляются ос- новные проверки при искажениях на входе. Проверяется надежность функционирования всей АЭИС в реальных условиях и эффективность средств программной защиты и восстановления. Определяются кор- ректность использования программами ресурсов

ВС и функционирова- ние программ в критических условиях. 2Тестирование комплекса программ при испытаниях 0предназначено в основном для проверки соответствия ТЗ и для оценки пригодности АЭИС к регулярной эксплуатации и сопровождению. Для этого прове- ряется полнота и точность технической документации и качество функционирования программ по всем требованиям ТЗ. 2Тестирование системы при сопрвождении 0осуществляется с ис- пользованием практически

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

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

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

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

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

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

Эта задача может решаться 1статистически0 без ис- полнения программы по ее тексту и 1динамически 0путем использова- ния программы в объектном коде при конкретных исходных данных. Последствия ошибок в программе могут проявляться как малые изме- нения переменных в процессе вычислений и как полное искажение или отсутствие на выходе требующихся величин. Целесообразно выделить следующие методы тестирования и последовательность их применения - тестирование

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

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

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

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

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

Текст отлаживаемой программы при этом расширяется и деформируется за счет операторов регистрации. 2Метод моделирования 0 интерпретации исполнения тестируемых программ позволяет использовать текст программы в объектном коде, каждая команда которой моделируется в соответствии с логикой опе- раций данной ЭВМ. Системы автоматизации отладки программ Для определенной со- вокупности программных модулей с учетом их сложности, общего чис- ла, требований к качеству и т.д. целесообразна такая 2степень ав-

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

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

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

в программах и учет версий программ, в которых проведены те или иные корректировки. 21. Комплексная отладка АЭИС задачи комплексной отладки статическая и динамическая комплексная отладка регистрация и об- работка данных при отладке программ 28.1 . Основная задача комплексной отладки программ состоит в за- вершении разработки всей АЭИС и в доведении ее характеристик до значений, заданных требованиями

ТЗ. Должны быть - завершены и проверены сопряжение и взаимодействие по пере- даче управления и по информации всех компонент, входящих в АЭИС - проверена возможность получения в процессе рабочего функ- ционирования АЭИС всех характеристик, заданных требованиями ТЗ, а также вспомогательных, обоснованных в техническом проекте - проверены полнота и состав технической документации, а также точное соответствие ее изделию - АЭИС. Наиболее сложным является обеспечение возможности функциони- рования

АЭИС с характеристиками, заданными требованиями ТЗ и нор- мативными документами. Система должна гарантированно удовлетво- рять всем требованиям не только в диапазоне типичных условий функционирования, но и при предельных, критических сочетаниях значений всех параметров. Это обеспечивает надежность функциони- рования программ при разнообразных произвольных, в т.ч. искажен- ных сочетаниях исходных данных. В процессе комплексной отладки должна быть обеспечена и проверена модернизируемость

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

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

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

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

- информационная схема АЭИС, отражающая реальные связи прог- рамм через глобальные переменные и константы - список всех возможных маршрутов исполнения групп функцио- нальных программ, входящих в состав АЭИС. Первоначальный анализ структурной и информационной схем АЭИС может быть проведен по спецификациям на программы, хранящимся в БД. Последующее уточнение структурной схемы по управлению при не- обходимости может проводиться в процессе

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

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

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

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

комплексов программ 0в реальном времени. Такие прог- раммные имитаторы дают возможность создания тестов во всем много- образии поведения объектов внешней среды данной АЭИС. При программной реализации процессов имитации информации и обработки результатов тестирования необходимо время, затраты ко- торого не должны искажать реальное время функционирования систе- мы. решить эту задачу можно тремя способами При 1первом способе0 предполагается, что затраты времени на генерацию

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

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

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

АЭИС позволяет заранее имитировать основные потоки тестовых данных с высокой интенсивностью и дополнительно учиты- вать обратные связи от тестируемой АЭИС. 1Третий0, стартстопный, 1способ0 позволяет использовать для ими- тации и обработки тестов основную ЭВМ с тестируемой АЭИС, когда невозможно обеспечить решение вспомогательных задач в реальном времени. Для этого реальное время сохраняется только при решении задач отлаживаемой системы, а решение задач

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

Наиболее сложными являются динамическая отладка в реальном времени сложных АЭИС, управляющих реальными объектами, и имитация тестов при следующих требованиях - необходимо формировать большое количество разнородных тес- товых сообщений в ограниченное время - ряд тестовых данных зависит от информации, выдаваемой комплексом программ, и должен формироваться оперативно с учетом обратной связи от результатов обработки предыдущих тестов - необходимо обеспечивать контроль генерируемых тестов, ре-

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

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

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

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

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

функционирования АЭИС в динамике реально- го времени. При этом регистрируется избыточное количество данных, из которых затем отбирается минимум, необходимый для анализа. Другая стратегия - 2сверху 0 2вниз 0- базируется на упорядоченном, иерархическом выделении в первую очередь обобщенных результатов функционирования программ системы с последующим уточнением ре- гистрируемых и анализируемых результатов вплоть до контроля ис- полнения отмеченного программного модуля

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

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

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

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

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

На практике во многих задачах форма распределения повторяемых проверяемых параметров и показа- телей качества оказывается заранее неизвестной. Однако часто в качестве такого распределения можно предположить нормальный закон распределения. Обработка результатов отладки АЭИС может быть разделена на две автономные части оперативную и обобщенную. Оперативная обработка результатов отладки .производится по упрощенным алгоритмам с большой пропускной

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

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

АЭИС. Неко- торые эталонные данные могут быть получены от генераторов тестов. При экспериментах с реальными объектами для получения эталонных данных используются специальные измерительные комплексы. 22. Организация работ по проведению испытаний информационных систем организация проведения приемочных испытаний систем осо- бенности испытаний на надежность систем достоверность определе- ния качества систем при испытаниях исходные и отчетные документы при испытаниях систем 29.1 .

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

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

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

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

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

АЭИС при сопровождении. Для обеспечения полноты приемосдаточных испытаний опытного образца целесообразно выделять категории тестирования. 1Функциональное тестирование.0 - наиболее обширное и труднее всего систематизируемое. Набор испытательных тестов определяется функциональными задачами и сложностью АЭИС. Тесты должны обеспе- чивать проверку и демонстрацию заказчику или пользователю качест- ва решения функциональных задач, сформулированных в ТЗ и конкре- тизированных в документации.

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

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

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

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

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

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

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

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

в зависимости от длительности тестирования. При высокой надежности ИС организуются многочасовые прогоны реального функционирования программ системы в условиях широкого варьирования исходных данных. Такие прогоны позволяют измерить и зафиксировать достигнутые показатели надежности и степень их со- ответствия требованиям ТЗ, а также закрепить их в ТУ на АЭИС. 2Форсированные методы испытаний реальных систем на надежность

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

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

переменных, которые наи- более важны для последующего использования системы. Разработчик контролирует, чтобы планируемое тестирование не выходило из об- ластей, заданных ТЗ. Испытания за пределами ТЗ могут квалифициро- ваться как его расширение или могут исключаться по требованию за- казчика. Важную роль играют оценка и обеспечение близких значений методической и статистической достоверностей испытаний. 1Методическая достоверность 0испытаний

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

воздействия точностью и кор- ректностью регистрации и обработки результатов тестирования, а также сравнения полученных данных с требованиями ТЗ. 1Статистическая достоверность 0испытаний в значительной степе- ни ограничена допустимым объемом и продолжительностью испытаний. Методы теории планирования экспериментов позволяют упорядоченно варьировать исходные данные и наиболее эффективно использовать ограниченные ресурсы тестирования.

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

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

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

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

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

АЭИС в соответствии с ТЗ и план тести- рования для проверки функционирования систем по разделам ТЗ и до- полнительным требованиям, формализованным отдельными решениями - 1мет0о1дики испытаний0, однозначно определяющие все понятия проверяемых характеристик, условия тестирования, средства, ис- пользуемые для испытаний, методики обработки и оценки результатов тестирования по каждому разделу программы испытаний. Большой объем разнородных данных, получаемых при испытаниях

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

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

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

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

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

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

вать его соответствующим тестированием и контролем качества. В результате АЭИС со временем обычно улучшается как по функциональ- ным возможностям, так и по качеству решения отдельных задач. Работы, обеспечивающие контроль и повышение качества, а так- же развитие функциональных возможностей систем, составляют про- цесс сопровождения включающий - 1исправления ошибок 0- корректировка программ, выдающих неп- равильные результаты в условиях, ограниченных

ТЗ и документацией в процессе сопровождения требуют около 20 затрат - регламентированная документами 1адаптация 0к условиям конк- ретного использования, обусловленным характеристикам внешней сре- ды или конфигурацией аппаратных средств, на которой предстоит функционировать программам около 20 общих затрат - 1модернизация 0- расширение функциональных возможностей или улучшение характеристик решения отдельных задач в соответствии с новым или дополненным ТЗ на

АЭИС - до 60 общих затрат. Первый вид изменений является непредсказуемым и его трудно регламентировать. Остальные виды корректировок носят упорядочен- ный характер и проводятся в соответствии с заранее подготавливае- мыми планами и документами. Эти корректировки в наибольшей степе- ни изменяют компоненты системы и требуют наибольших затрат. Со временем, иногда через десятки лет, сопровождение системы прекращается. Это может быть обусловлено разработкой более совер- шенных систем, прекращением использования сопровождаемой

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

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

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

в новой версии и их распространение пользователям возможно ли и насколько сильно влияние изменения на функциональ- ные характеристики остальных компонент данной АЭИС какова сроч- ность извещения пользователей о разработанной корректировке и це- лесообразно ли ее распространять до подготовки очередной версии для какого числа пользователей может быть полезным данное измене- ние как данное изменение отразится на эксплуатации пользователя- ми предыдущих версий насколько

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

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

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

возможностей АЭИС. Такие же предложения могут поступать от разработчиков системы. На базе предложений создается документ - исходные данные для планирования доработок и тестирования системы в процессе сопровождения. Для общения с пользователями и накопления информации о выяв- ляемых недостатках в широко тиражируемых сложных АЭИС целесооб- разно выделение группы специалистов высокой квалификации, овла- девших всеми функциональными возможностями данной

АЭИС, имеющая в своем арсенале весь комплекс тестов, применявшихся при испытаниях опытного образца и предыдущих версий АЭИС для антирегрессионного тестирования Эти тесты накапливаются, упорядочиваются и катало- гизируются в БД тестирования. Для повышения качества очередных версий руководитель сопро- вождения и совет конфигурационного управления анализируют все предлагаемые изменения.

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

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

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

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

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

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

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

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

а также рассматривается воз- можность прекращение сопровождения некоторой ранней версии систе- мы. В результате среди всего множества версий каждой АЭИС образу- ется зона сопровождаемости версий. число таких сопровождаемых эталонных версий или глубина сопровождения практически всегда не более двух версий и редко превышает четыре версии. ля сложных АЭИС это соответствует рациональному жизненному циклу, который составляет 3 5 лет. Полный жизненный цикл каждой версии может составлять 20 30 лет, а суммарное число

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

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

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

ВОПРОСЫ к билетам государственных экзаменов 1994 1995 г. по дисциплине ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ 1. Значение и направления развития проектирования информаци- онных систем, предназначенных для обработки экономической инфор- мации проблемы проектирования автоматизированных экономических информационных систем АЭИС 14.1 . 2. Порядок разработки автоматизированных экономических ин- формационных систем

АЭИС нормативная последовательность этапов разработки АЭИС технические предложения,технические требования или техническое задание эскизный проект технический проект ра- бочий проект 19.1. 3. Организация проектирования автоматизированных экономичес- ких информационных систем принципы планирования разработки АЭИС 15.1 4. Виды поддержки процесса проектирования автоматизированных информационных систем

АЭИС документирование цели проектирова- ния АЭИС 32.1 5. Жизненный цикл эффективность технологии проектирования автоматизированных экономических информационных систем АЭИС 16.1 . 6. Технологические аспекты проектирования автоматизированных экономических информационных систем АЭИС 17.1 . 7. Системотехнические принципы проектирования автоматизиро- ванных экономических информационных систем АЭИС классы систем - объектов проектирования декомпозиция как метод проектирования

сложных АЭИС 18.1 . 8. Принципы структурного проектирования автоматизированных экономических информационных систем АЭИС структурное проекти- рование программных компонент восходящее и нисходящее проектиро- вание АЭИС общие правила структурного построения 20.2 9. Элементарные базовые структуры автоматизированных эконо- мических информационных систем АЭИС структурирование данных АЭИС типовая структура

АЭИС основные режимы функционирования систем 21.1 10. Проектирование аппаратных средств автоматизированных экономических информационных систем АЭИС модульная структура аппаратных средств вопросы экономики при выборе соотношения меж- ду аппаратными и программными средствами 22.1 11. Проектирование программного обеспечения автоматизирован- ных экономических информационных систем АЭИС система языков проектирования программ комплексирование программ средства

ав- томатизации разработки программ 23.1 12. Проектирование программного обеспечения понятие кор- ректности, эталона и сложности программ программные ошибки 24.1 13. Методы распределения ресурсов, эффективность распределе- ния производительности и памяти при проектировании автоматизиро- ванных экономических информационных систем АЭИС . 14. Системы автоматизации проектирования автоматизированных экономических информационных систем

АЭИС состав инструменталь- ных средств для различных уровней автоматизации разработки АЭИС структурная схема комплексной системы автоматизации сложных АЭИС 26.1 15. Основные понятия надежности автоматизированных экономи- ческих информационных систем АЭИС методы повышения надежности функционирования АЭИС методы проектирования систем с заданными надежностью и качеством 25.1 16. Проектирование автоматизированных экономических информа- ционных систем на базе

персональных ЭВМ особенности и технологи- ческие аспекты проектирования АЭИС, создаваемых на основе ПЭВМ обоснование выбора состава автоматизированных функций при созда- нии и проектировании АЭИС 31.1 . 17. Проблемы выбора языка программирования при проектирова- нии АЭИС на базе ПЭВМ фреймовый подход к организации объектной базы. 18. Особенности разработки прикладных информационных систем на основе

ПЭВМ структурирование программ на уровне модулей раз- дельно компилируемые модули библиотеки процедур генерация объ- ектных модулей и загрузочных файлов библиотеки объектных моду- лей реализация сегментированных программ с перекрытиями 4.2 19. Организация взаимодействия программ АЭИС на основе ПЭВМ через прерывания ДОС на языке ассемблера особенности ассемблер- ных процедур резидентные программы связывание программ через потоки ввода вывода 5.2 20.

Автономная отладка и тестирование АЭИС общие задачи от- ладки содержание тестирования систематизация тестов для отлад- ки используемые методы отладки этапы отладки отладка программ- ных модулей тестирование обработки данных планирование отладки системы автоматизации отладки 27.1 . 21. Комплексная отладка АЭИС задачи комплексной отладки статическая и динамическая комплексная отладка регистрация и об- работка данных при отладке программ 28.1 .

22. Организация работ по проведению испытаний информационных систем организация проведения приемочных испытаний систем осо- бенности испытаний на надежность систем достоверность определе- ния качества систем при испытаниях исходные и отчетные документы при испытаниях систем 29.1 . 23. Организация работ по сопровождению информационных сис- тем задачи сопровождения иерархия подготовки и внесения измене- ний в систему тиражирование и использование версий системы 30.1. .