Дзюбенко А.Л., Ильин А.А., Мишин П.Н. и др. Информационные технологии управления: Учебное пособие

Подождите немного. Документ загружается.

101

го программного кода на 10 - 15%, однако сам процесс оптимизации тре-

бует значительных временных затрат.

В результате компиляции создается

объектный модуль, представ-

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

ную программу еще невозможно, так как в ней не указаны конкретные ад-

реса используемых ячеек оперативной памяти (при запуске программы на

выполнение она предварительно переписывается в ОЗУ). Поэтому объект-

ный модуль должен быть обработан специальной программой –

редакто-

ром связей

, в результате чего создается загрузочный модуль с относи-

тельными адресами памяти. При размещении загрузочного модуля в опе-

ративной памяти, начиная с определенной ячейки памяти, все необходи-

мые для работы адреса могут быть определены на основе имеющихся от-

носительных адресов. При необходимости редактор связей дополнительно

подключает в загрузочный модуль готовые последовательности

машинных

команд, реализующие конкретные операции. Время компиляции программ

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

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

При этом непосредственно в процессе выполнения программы в машин-

ный код приходится вставлять множество дополнительных проверок, ана-

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

процессе

выполнения программы) их захватывать и освобождать и др. В

результате эффективность полученного в результате компиляции машин-

ного кода значительно снижается.

В целом для компиляторов характерны следующие особенности:

• откомпилированная программа работает на несколько порядков

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

интерпретатора;

• в отличие от интерпретатора, компилятор при выполнении про-

граммы не занимает место в ОЗУ (выгружается оттуда после завершения

компиляции);

• программа в виде загрузочного модуля может быть перенесена на

другие компьютеры (со схожими наборами машинных команд).

На практике находят применение трансляторы, реализованные в виде

интерпретатора-компилятора, позволяющего на этапе разработки и отлад-

ки программ преобразовывать отдельные операторы в режиме интерпрета-

тора, а по завершении отладки исходная программа транслируется полно-

стью в

объектный модуль в режиме компиляции. Подобный подход позво-

ляет сократить время отладки и обеспечить эффективное исполнение про-

граммы.

102

5.2. Технологии системного проектирования

программных средств

Выбор технологии разработки конкретных приложений определяется

рядом факторов, важнейшими из которых являются:

• степень взаимосвязи приложения с другими приложениями (при-

ложение зачастую является элементом единой системы автоматизирован-

ной обработки информации);

• тип используемых программно-инструментальных средств;

• сложность решаемой задачи.

Достаточно простой и широко распространенный на практике под-

ход предполагает разработку автономного приложения, практически не

учитывающего или слабо учитывающего информационное взаимодейст-

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

ным до начала 70-х годов; он предполагает использование в качестве про-

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

Схема

процесса разработки приложения для решения экономической за-

дачи с таким подходом включает в себя ряд этапов (рис.5.2).

На первом этапе осуществляется

постановка задачи, представляю-

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

нием входной и выходной информации. При этом формулируется цель и

периодичность решения задачи; конкретизируются состав и формы пред-

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

ляется необходимость контроля значений различных реквизитов и др.

Необходимая для решения задачи входная информация

может быть

представлена в виде первичных документов как ручного, так и машинного

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

формации), приходящих по каналам связи сообщений. При их описании

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

вольный, дата и др.) и его разрядность (достаточная для ввода потенци-

ально самого

“длинного” значения); необходимая точность описания рек-

визита (посредством задания числа десятичных знаков после запятой);

возможный диапазон изменения значений реквизитов. Аналогичная ин-

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

103

Постановка

задачи

Экономико-

математичекое

описание

Разработка

алгоритма

Программирование

Тестирование и

отладка

Приемно-сдаточные

испытания

Опытная

эксплуатация

Промышленная

эксплуатация

Рис. 5.2. Обобщенная схема процесса разработки приложения

Кроме того, при подготовке приложения, предполагающего его по-

следующее использование в интерактивном режиме работы с управлением

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

ние уделяется организации иерархического меню и отображению различ-

ного рода элементов управления (в окнах для Windows-приложений).

Только тесное взаимодействие постановщика задачи

(он же, как правило,

и есть будущий пользователь создаваемого приложения) и программиста

(исполнителя) способно обеспечить формирование эффективного пользо-

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

димо реализовать в приложении, а программисту известны типовые, ши-

роко используемые в практике разработки приложений, решения.

Значительна роль пользователя при постановке задачи

и при задании

контрольного примера, предполагающего формирование выходных дан-

ных (выходных документов, массивов, сообщений и др.) в соответствии с

используемыми входными данными. В целом формирование контрольно-

го примера носит компромиссный характер, поскольку при достаточно

кратком его описании (представлении) необходимо адекватно отобразить

многообразие возможных изменений входных данных. При этом пользо-

ватель

должен акцентировать внимание программиста на возможности

возникновения тех или иных нештатных ситуаций, которые могут про-

явиться в процессе решения задачи, а также конкретизировать характер

действий пользователя при их появлении.

Следует отметить большую роль пользователя на этапе постановки

задачи в процессе разработки требуемого приложения. Именно пользова-

тель, выступающий в роли постановщика задачи

, знает ее специфические

особенности (говорят, что хорошо поставленная задача – это уже полови-

на успеха). Однако, как правило, пользователь значительно хуже ориенти-

руется в современном инструментарии программирования, представляя

лишь простейшие возможности его использования. В свою очередь, про-

граммист во многих случаях не способен самостоятельно учесть потенци-

ально возможные нюансы, невнимание к

которым на этапе разработки

приложения способно значительно снизить впоследствии потребитель-

104

скую ценность приложения. Практика показывает, что изначальная поста-

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

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

приложений. При этом, зачастую, пользователь считает, что отсутствую-

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

многих случаях постановка задачи (как этап разработки приложения) пре-

вращается в

итерационную процедуру взаимодействия пользователя и

программиста. Недопонимание между пользователем и программистом на

этапе постановки задачи может повлечь за собой серьезные последствия,

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

следующих этапах разработки приложения. Для своевременного устране-

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

полноты постановки задачи с опорой на формализованные

процедуры,

предполагающие формирование однозначно трактуемых описаний.

Второй этап разработки приложения связан с

экономико-

математическим описанием

задачи и выбором метода ее решения. Для

простых вариантов подлежащих решению экономических задач возможно

вырождение данного этапа, если вид входных данных и результатов их

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

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

граммы. Однако, во многих случаях, особенно при разработке проектов

автоматизированных

ин6формационных систем, определение адекватной

модели, описывающей поведение многосвязных динамических процессов,

может оказаться наиболее сложным и трудоемким этапом разработки. При

этом к выполнению проекта приходится подключать квалифицированных

специалистов (группы специалистов) в области математики, системного

проектирования и моделирования, управления и др.

В целом при разработке экономико-математической модели и опре-

делении метода

решения задачи часто используют несколько классов мо-

делей:

• аналитические (вычислительные);

• матричные (балансовые);

• графические и др.

Грамотный выбор модели и метода решения являются основой

уменьшения трудоемкости решения задачи с обеспечением требуемой

точности результатов обработки. При выборе метода решения из ряда

возможных принимают во внимание ряд факторов:

• возможность обеспечения решения задачи с заданной точностью

при любых возможных значениях входных данных;

• возможность реализации метода решения задачи с использовани-

ем ранее разработанного программного обеспечения (как типового, так и

узко специализированного);

• время решения задачи;

105

• стоимость приобретения, при необходимости, программных

средств.

Результатом завершения работ по данному этапу разработки прило-

жения является получение формализованного описания задачи, содержа-

щего логико-математические зависимости, связывающие результаты обра-

ботки с входными данными.

Третий этап технологического процесса создания приложения связан

с разработкой

алгоритма решения задачи. Алгоритм решения задачи от-

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

гические условия, соотношения для контроля правильности полученных

результатов. Алгоритм должен учитывать все возможные ситуации, кото-

рые могут возникнуть при решении задачи.

Следует отметить, что очевидность алгоритма (отсутствие других

вариантов) характерна только для элементарных задач. В подавляющем

большинстве случаев (

даже и для простых задач), как правило, существует

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

нями сложности и, соответственно, различными объемами выполняемых

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

тов и другими свойствами. Программная реализация различных алгорит-

мов решения одной и той же задачи отличается временем решения задачи

и, зачастую, предполагает

использование различных объемов памяти.

В практике решения задач в сфере экономической деятельности,

предполагающих получение многовариантных решений (при различных

значениях входных данных и влияющих условий) широкое применение

находят таблицы решений. В общем случае они выглядят как электронные

таблицы; при этом совокупность строк и столбцов позволяет задать (опре-

делить) все множество значений

различных комбинаций реквизитов (ре-

зультатов их обработки, условий, ограничений и др.), для каждого из кото-

рых в отдельной ячейке (т.е. для определенных значений данных и ограни-

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

ния таблиц решений являются электронные таблицы.

Этап программирования связан с непосредственным формирова-

нием исполняемой программы (приложения); он заключается в преобразо-

вании алгоритма решения задачи в конкретную последовательность ма-

шинных команд. Характерной особенностью этого этапа является стрем-

ление разработчика (программиста) к максимальной автоматизации про-

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

системы программирования, имеющие средства для трансляции

разрабо-

танной на языке высокого уровня программы в машинные коды, отладчик,

редактор связей, ряд библиотек с готовыми решениями, средства оптими-

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

ность процессу программирования (с позиции сокращения времени на раз-

работку и создания дружественного пользовательского интерфейса) обес-

106

печивает применение систем программирования, ориентированных на реа-

лизацию визуального программирования. При использовании визуального

программирования подавляющая часть обеспечивающего реализацию

пользовательского интерфейса (окна, кнопки и др.) машинного кода гене-

рируется автоматически, а на разработчика возлагается функция компо-

новки схемы интерфейса (выбор конкретных элементов из имеющихся на-

боров готовых элементов, определение места их

расположения и др.) и на-

писание на языке высокого уровня небольшого количества операторов,

выполняющих непосредственную обработку данных при активизации тех

или иных событий.

Следует отметить, что в зависимости от сложности и характера ре-

шаемой задачи разработчик имеет возможность помимо языков програм-

мирования использовать инструментальные средства, встроенные в пакеты

прикладных программ

и, в первую очередь, в электронные таблицы (непо-

средственный ввод формул, формирование макросов и др.) и системы

управления базами данных (язык структурированных запросов SQL, раз-

личного рода конструкторы и мастера и др.).

Непосредственно с этапом программирования связан

этап отладки

и тестирования

. Под отладкой понимается совокупность действий, ори-

ентированных на обнаружение и устранение ошибок, возникающей в про-

цессе разработки программы. В целом программирование и отладка со-

ставляет единое целое, поскольку они являются двумя составляющими

итерационной (многократно повторяющейся) процедуры внесения допол-

нительной совокупности операторов на языке высокого уровня и проверки

их работоспособности. Все современные подходы

программирования

предполагают разделение общей задачи на множество относительно само-

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

из которых осуществляется посредством самостоятельных итерационных

процессов программирования и отладки. После завершения отладки от-

дельных модулей программы осуществляется отладка программы в целом,

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

нирования входящих в ее состав модулей.

После получения

работающей версии программы, позволяющей ре-

шать поставленную задачу, осуществляется процесс ее

тестирования,

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

на проверку правильности работы программы во всем допустимом диапа-

зоне изменения входных данных, а при наличии в ней операций взаимо-

действия с внешней средой (прием и передача данных и др.) и коррект-

ность выполнения этих операций. При этом возникновение нештатных си-

туаций (некорректные данные, их

отсутствие и др.) не должно нарушать

работоспособность программы и, напротив, должно вызывать формирова-

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

вателю в определении его последующих действий. Тестирование выполня-

107

ется на большом количестве примеров, обеспечивающих выполнение всех

возможных направлений развития процесса обработки данных при реше-

нии задачи.

На практике тестирование дополняет итерационную последователь-

ность фаз программирование–отладка, поскольку обнаружение факторов

неправильной работы программы сопровождается внесением необходимых

изменений в программу. С учетом высокой трудоемкости тестирования (до

десятков процентов от общего

объема трудозатрат на разработку) широко

применяют специализированные программные средства тестирования, на-

пример, генераторы тестовых данных. Однако, даже у известных фирм,

связанных с разработкой широко используемых в мировой практике при-

ложений, в процессе эксплуатации этих приложений обнаруживается су-

щественные изъяны (например, “бреши” в системе защиты ресурсов), сни-

жающие доверие к производителю.

Завершение разработки приложения сопровождается формированием

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

телю инструктивные материалы для работы с приложением. Как правило,

в состав этой документации входят материалы, регламентирующие дейст-

вия пользователя при эксплуатации приложения, определяющие возмож-

ности и конкретные действия по внесению изменений и дополнений и др.

Передача разработанного программного обеспечения в

эксплуатацию со-

провождается актом приемки-передачи, удостоверяющим факт выполне-

ния работы в соответствии с ранее сформулированными требованиями как

заказчиком (пользователем), так и разработчиком. Как правило, начальный

этап эксплуатации (экспериментальная эксплуатация) предполагает на-

блюдение за работой переданного программного средства со стороны раз-

работчика с быстрым устранением выявляемых недоработок. После устра-

нения

всех выявленных в процессе экспериментальной эксплуатации не-

доработок программное средство передается в промышленную эксплуата-

цию.

Описанные в разделе этапы в целом характеризуют жизненный цикл

программного обеспечения, обычно включающий в себя:

• формирование требований к программному обеспечению;

• проектирование;

• реализацию;

• тестирование;

• ввод в действие;

• эксплуатацию и сопровождение;

• снятие с эксплуатации.

Они характерны как для небольших приложений, создаваемых од-

ним разработчиком в течение нескольких дней, так и для проектов значи-

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

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

108

ких лет (при создании крупных систем автоматизации, разработки опера-

ционных систем и др.). Разработка сложных, трудоемких проектов предпо-

лагает использование высокопроизводительного инструментария для реа-

лизации технологий системного проектирования программных средств.

При проектировании современных экономических информационных

систем основная доля трудозатрат приходится на разработку прикладного

программного обеспечения и баз данных. Еще в

70-х годах в США возник

кризис программирования, проявившийся в том, что большие проекты ста-

ли выполняться со значительным отставанием от запланированных сроков

разработки и/или с заметным превышением сметы расходов. Во многих

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

сти и уровень производительности при эксплуатации программного про-

дукта.

В целом

причинами возможных неудач являются: неполное форму-

лирование требований к разрабатываемому программному продукту, а, за-

частую, и изменение требований и спецификаций непосредственно по ходу

разработки; недостаточный объем задействованных при разработке ресур-

сов (финансовых, людских и др.); неудовлетворительное планирование и

недостаточная компетентность управления проектом; слабая поддержка со

стороны высшего руководства и др. Особенно

следует отметить влияние

временного фактора, практически всегда приводящего к возникновению

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

гими производителями программных продуктов.

Необходимость контроля процесса создания программного обеспе-

чения, гарантированной оценки стоимости разработки и сроков ее выпол-

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

ли объективную потребность перехода к индустриальным

способам созда-

ния ПО. Соответствующее направление создания ПО получило название

программная инженерия (software engineering). В процессе его становления

и развития явно выделяются два этапа: период 70-80-х годов, когда систе-

матизация и стандартизация процессов создания ПО осуществлялась на

основе структурного подхода; период 90-х годов, во время которого на-

чался переход к сборочному способу создания

ПО на основе объектно-

ориентированного, а затем и визуально-ориентированного подходов. Ос-

новой реализации второго этапа явилось резкое увеличение производи-

тельности средств вычислительной техники и массовое распространение

компьютерных сетей.

Для современных крупных проектов в области экономических ин-

формационных систем, как правило, характерны следующие особенности:

• сложность описания систем ввиду большого количества процес-

сов, элементов данных и взаимосвязей между ними;

109

• взаимодействие значительного числа входящих в состав системы

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

лей;

• необходимость интеграции с ранее разработанными и используе-

мыми приложениями;

• отсутствие полных аналогов, что даже в простейших случаях

предполагает “привязку” типового решения к реальным условиям;

• необходимость совмещения в системе регламентных (периодиче-

ски решаемых) и не регламентных (разовые запросы произвольной формы)

задач;

• функционирование разрабатываемого программного обеспечения

в среде с разнотипными средствами вычислительной техники;

• длительный период проектирования и внедрения результатов в

связи со сложностью задач и различной степенью готовности отдельных

структурных подразделений организации-заказчика к внедрению и др.

Успешная реализация проекта изначально предполагает разработку пол-

ных и непротиворечивых моделей

архитектуры ПО, отражающих сово-

купность взаимосвязанных структурных элементов системы, а также ие-

рархию подсистем, объединяющих структурные элементы. Модели явля-

ются основой визуализации, описания, проектирования и документирова-

ния архитектуры системы.

Адекватные модели служат основой взаимодействия всех участников про-

екта и в значительной степени гарантируют корректность архитектуры.

Важная роль в процессе реализации проекта отводится

языку моделирова-

ния, который содержит в своем составе элементы модели - базовые кон-

цепции моделирования и их семантику, нотацию - визуальное представле-

ние элементов моделирования, руководство по использованию – правила

применения элементов в рамках построения тех или иных типов моделей

программного обеспечения. Нотация представляет собой совокупность

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

является

синтаксисом языка моделирования. Большинство существующих методов

объектно-ориентированного анализа и проектирования включает в себя как

язык моделирования, так и описания процесса моделирования. Язык моде-

лирования – это нотация (в основном графическая), которая используется

методом для описания проектов. Необходимо отметить, что в отличие от

широко трактуемого понимания сущности моделирования, конечной це-

лью

разработки ПО является создание эффективно работающих приложе-

ний (написание совокупности взаимодействующих программ), поэтому

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

фических моделей, описывающих различные аспекты архитектуры ПО

(как статическую структуру, так и динамику поведения системы).

Наглядность и формализм структурного и объектно-

ориентированного подходов соответствовали целям использования графи-

110

ческих моделей, создавая возможности разработчикам и заказчикам (бу-

дущим пользователям системы) взаимодействия при анализе возможных

технических решений непосредственно с момента начала проектирования.

Реализация таких подходов требовала соответствующих программно-

технологических средств, позволяющих, в отличие от традиционной (руч-

ной) разработки ПО, значительно снизить вероятность появления ошибок в

проектных решениях и просчетов при

тестировании разработанной систе-

мы, повысить качество документации, сократить сроки проектирования и

др.

Результатом поиска в области создания программно-

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

мационных систем явилось создание CASE-средств, охватывающих весь

комплекс задач по созданию и сопровождению программного обеспечения

для таких систем. В целом CASE-технология представляет собой совокуп-

ность

методов проектирования ЭИС и инструментальных средств, позво-

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

ровать эту модель на всех этапах разработки и сопровождения ЭИС и раз-

рабатывать приложения в соответствии с запросами пользователей.

Одним из базовых понятий программной инженерии является поня-

тие

жизненного цикла программного обеспечения, определяемого как пе-

риод времени, начинающийся с момента принятия решения о необходимо-

сти создания ПО и заканчивающийся в момент его полного изъятия из экс-

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

ментируется международным стандартом ISO/IEC 12207:1995 “Information

Technology – Software Life Cycle Processes” (ISO – International Organization

for Standardization – Международная организация по стандартизации, IEC –

International Electrotechnical Commission – Международная комиссия по

электротехнике). Стандарт определяет структуру

жизненного цикла, со-

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

во время создания ПО. Понятие

программного продукта в нем определе-

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

ним документации и данных. Положения стандарта являются общими для

любых моделей жизненного цикла, методов и технологий разработки ПО,

однако они не конкретизируют особенности реализации процессов.

В состав жизненного цикла ПО обычно включают следующие этапы:

• формирование требований к программному обеспечению;

• проектирование и тестирование;

• ввод в действие;

• эксплуатацию и сопровождение;

• снятие с эксплуатации.