Требования, предъявляемые к экономической информации

Введение:

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

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

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

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

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







1.1.Понятие экономической информации, её классификация и  структура.

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

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

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

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

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





	Все задачи, входящие в СППО, можно классифицировать по нескольким признакам:

	характеру переработки информации;

	назначению;

	уровню применения.

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

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

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

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

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

	В свою очередь, расчетные задачи подразделяются на вычислительные задачи и математические модели.

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

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

	По назначению информационные и расчетные задачи подразделяются на штатные и исследовательские.

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

	Штатные информационные и расчетные задачи (ИРЗ) бывают одноуровневые (используемые в звеньях управления одного уровня, например - задачи предприятия) и многоуровневые (используемые в звеньях управления нескольких уровней, например - на предприятии, объединении и в министерстве).

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

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

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

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

	

2.1.Требования, предъявляемые к  экономической информации (ЭИС)

Необходимость определения требований к ЭИС возникает в следующих случаях:

		в момент выбора новой информационной системы,

		при подготовке тендерной документации,

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

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

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

Все существующие сегодня методики определения требований к ИС являются наследниками BSP (Business System Planning – планирование бизнес-систем), используют предложенные в ней методы сбора информации, подходы в определении приоритетов требований, обеспечении полноты и непротиворечивости требований. Методика BSP определяется как «подход, помогающий предприятию определить план создания информационных систем, удовлетворяющих его ближайшие и перспективные информационные потребности».

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

Экономические информационные системы характеризуются следующими показателями:

		конкретным типом решаемых задач; 

		степенью связи решаемых задач с реальным масштабом времени или допустимой длительностью ожидания результатов решения задачи; 

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

		необходимыми характеристиками качества и надежности; 

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

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

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

		предполагаемым тиражом производства и применения программ; 

		степенью необходимой документированности программ.

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

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

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

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





















































Рис.1. 



 



Обобщенная блок-схема стадий и этапов разработки и внедрения ЭИС

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

Внедрение разработанного проекта (блоки 7-10) начинается с опытного внедрения (блок 7), заключающегося в проверке работоспособности элементов и модулей проекта, устранении ошибок на уровне элементов и связей между ними. 

Этап сдачи в промышленную эксплуатацию (блок 9) заключается в организации проверки проекта на уровне функций и контроля соответствия его требованиям, сформулированным на стадии системного анализа.

Эксплуатация и сопровождение проекта (блоки 11-12). На этой стадии выполняются этапы: эксплуатация проекта системы и модернизация проекта ЭИС.

Другой характерной чертой жизненного цикла является наличие нескольких циклов внутри схемы:

	15. первый цикл, включающий блоки 1-12 – это цикл первичного проектирования ЭИС; 

		второй цикл (блоки 7-8, 6-7) – цикл, который возникает после опытного внедрения, в результате которого выясняются частные ошибки в элементах проекта, исправляемые начиная с 6-го блока; 

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

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

		пятый цикл (блоки 12, 1-12) возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы. 

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

		разработка ЭИС должна быть выполнена в строгом соответствии со сформулированными требованиями к создаваемой системе; 

	21. требования к ЭИС должны адекватно соответствовать целям и задачам эффективного функционирования экономического объекта; 

		созданная ЭИС должна соответствовать сформулированным требованиям на момент окончания внедрения, а не на момент начала разработки; 

		внедренная ЭИС должна развиваться и адаптироваться в соответствии с постоянно изменяющимися требованиями к ЭИС. 

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

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

		требования к надежности 

		настраиваемость 

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

		требования к информационной и программной совместимости 

		требования к документации

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

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

Настраиваемость. Определяются требования к адаптационным возможностям ПО, то есть указывается, какие изменения в методах управления и бизнес процессах должны быть предусмотрены.

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

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

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

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

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

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



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



Рис.2.                                 ПОЛЬЗОВАТЕЛИ

                 

А1

Аn

B1

Bk

Внешнее представление А

Внешнее представление В

       Концептуальное представление

            Внутреннее представление                       















Детализация представлений ЭИС

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

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

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

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

К концептуальному представлению предъявляются требования устойчивости, абстрактности и конструктивности.

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

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

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

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

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































































Заключение:

В заключении хотелось бы проанализировать типичные ошибки при определении требований к информационной системе:

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

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

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




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

Основная литература:

	Информатика: Учебник. / Под редакцией Макаровой Н.В. – М.: Финансы и статистика,   2004.

	Ясенев В.Н. Информационная безопасность в экономических системах: Учебное пособие – Н. Новгород: Изд-во ННГУ, 2006

		Могилев А.В. и др. Информатика. Под ред. Хеннера Е.К.. – 2-е изд., стер. – М.: Изд. центр «Академия», 2001. – 816 с.

		Информатика: Практикум по технологии работы на компьютере.- 3- е перераб. Изд./ Под ред. Н.В. Макаровой. – М.: Финансы и статистика, 2003. – 256 с.

		Патрушина С.М. Информационные системы в экономике. – М.: Маар Т, 2004.



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

		

		Росс Г.В., Дулькин В.Н. и др. Основы информатики: Учебное пособие. – М.: ПРИОР, 1999.

		Вычислительные системы, сети и телекоммуникации: Учебник / Под редакцией Пятибратова А.П. – М.: Финансы и статистика, 2003.

	Титоренко Г.А. Автоматизированные информационные технологии в экономике. – М.: Юнити, 2006

		Практикум по экономической информатике. Учебное пособие. Ч. I / Под ред. Е.Л. Шуремова, Н.А. Тимаковой, Е.А. Мамонтовой. – М.: Изд-во  “Перспектива”, 2000.

		Практикум по экономической информатике. Учебное пособие. Ч. II / Под ред. В.П.

		Косарева, Г.А. Титоренко, Е.А. Мамонтовой. – М.: Финансы  и статистика; Перспектива, 2002

		Острейковский В.А. Информатика: Учебник. – М.: Высшая школа, 2004.

		Экономическая информатика: Учебник / Под ред. В.П. Косарева. – М: Финансы и статистика, 2004.

		Попов В.Б. Основы компьютерных технологий. – М.: Финансы и статистика, 2002. – 704 с.: ил.











1