|
|
|
|
Реферат: Требования, предъявляемые к ЭИС
Реферат: Требования, предъявляемые к ЭИС
Кафедра «Информатика»
Семестровая контрольная работа по курсу
«Информационные системы в экономике»
Требования, предъявляемые к экономическим информационным системам
Выполнил: студент гр. БО‑301 Ковчегин И. А.
Преподаватель: Ноздрина Ю.И.
Содержание
Введение.. 3
Требования, предъявляемые к ЭИС.. 5
Реализация требований, предъявляемых к ЭИС
бухгалтерского учета на примере «ИНФИН-Управление» компании «ИНФИН» 15
Заключение.. 17
Литература.. 19
Современная экономика немыслима без информации. Тысячи предприятий, миллионы
налогоплательщиков, триллионы рублей, биржевые котировки, реестры акционеров
– все эти информационные потоки необходимо оценить, обработать, сделать
необходимые выводы, принять правильное решение. Информация является одним из
основных ресурсов и должна планироваться в масштабах всего предприятия,
информационная система должна проектироваться независимо от текущего
состояния и структуры предприятия.
Современный специалист-экономист должен уметь принимать обоснованные решения.
Для этого наряду с традиционными знаниями, такими как основы менеджмента,
основы внешнеэкономической деятельности, банковское дело, административное
управление, налогообложение он должен владеть информацией по построению
информационных систем.
Сегодня обработка экономической информации стала самостоятельным научно-
техническим направлением с большим разнообразием идей и методов. Отдельные
компоненты процесса обработки данных достигли высокой степени организации и
взаимосвязи, что позволяет объединить все средства обработки информации, на
конкретном экономическом объекте понятием «экономическая информационная
система» (ЭИС).
Согласно существующей классификации проектов, создание ЭИС относится к
техническим инновационным проектам, поскольку здесь главной целью является
разработка и применение новых технологий. По классу и масштабам среди
разработок ЭИС распространены мелкие и средние монопроекты (95% общего числа
разработок). Создаваемые в рамках данных проектов ЭИС – это, в основном,
автоматизированные банковские системы для мелких и средних банков, системы
автоматизации торговых предприятий, бухгалтерские информационные системы и
автоматизированные системы управления предприятиями и организациями, системы
обмена данными и аналитические информационные системы рынка ценных бумаг,
информационные системы для налоговых и страховых учреждений. В не зависимости
от направления ЭИС к ней применяются соответствующие требования, рассмотрение
которых является целью данной контрольной работы.
Необходимость определения требований к ЭИС возникает в следующих случаях:
§ в момент выбора новой информационной системы,
§ при подготовке тендерной документации,
§ при заключении договора на разработку или настройку выбранной
информационной системы,
§ при уточнении (детализации) потребностей бизнеса в процессе
разработки или настройки системы,
§ при необходимости внесения изменений в систему в ходе эксплуатации.
Все существующие сегодня методики определения требований к ИС являются
наследниками 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). На этой
стадии выполняются этапы: эксплуатация проекта системы и модернизация проекта
ЭИС.
Другой характерной чертой жизненного цикла является наличие нескольких
циклов внутри схемы:
§ первый цикл, включающий блоки 1-12 – это цикл первичного
проектирования ЭИС;
§ второй цикл (блоки 7-8, 6-7) – цикл, который возникает
после опытного внедрения, в результате которого выясняются частные ошибки в
элементах проекта, исправляемые начиная с 6-го блока;
§ третий цикл (блоки 9-10, 4-9) возникает после сдачи в
промышленную эксплуатацию, когда выявляются ошибки в функциональной архитектуре
системы, связанные с несоответствием проекта требованиям заказчика, по
составу функциональных подсистем, составу задач и связям между ними;
§ четвертый цикл (блоки 12, 5-12) возникает в том случае,
когда требуется модификация системной архитектуры в связи с необходимостью
адаптации проекта к новым условиям функционирования системы, т.е. новым
требованиям;
§ пятый цикл (блоки 12, 1-12) возникает, если проект
системы совершенно не соответствует требованиям, предъявляемым к
организационно-экономической системе ввиду того, что осуществляется моральное
его старение и требуется полное перепроектирование системы.
Чтобы исключить пятый цикл и максимально уменьшить необходимость
выполнения третьего и четвертого циклов, необходимо выполнять
проектирование ЭИС на всех этапах первого, основного цикла разработки ЭИС в
соответствии с требованиями:
§ разработка ЭИС должна быть выполнена в строгом соответствии со
сформулированными требованиями к создаваемой системе;
§ требования к ЭИС должны адекватно соответствовать целям и задачам
эффективного функционирования экономического объекта;
§ созданная ЭИС должна соответствовать сформулированным требованиям на
момент окончания внедрения, а не на момент начала разработки;
§ внедренная ЭИС должна развиваться и адаптироваться в соответствии с
постоянно изменяющимися требованиями к ЭИС.
Функциональные требования к информационной системе, которые описываются, в
том числе, и с помощью моделей процессов и структур данных, являются только
частью общих требований, которые содержаться в техническом задании. Раздел
требований к информационной системе технического задания может содержать
следующие подразделы:
§ требования к функциональным характеристикам
§ требования к надежности
§ настраиваемость
§ условия эксплуатации
§ требования к информационной и программной совместимости
§ требования к документации
Требования к функциональным характеристикам. В этом разделе должны
быть указаны требования к составу выполняемых функций, организации входных и
выходных данных. При выборе между объектными и структурными методами следует
использовать принцип концептуальной общности, который предполагает следование
единой философии на всех этапах жизненного цикла. Если предполагается
использовать структурное программирование, то и на этапе анализа следует
использовать структурный подход, а в случае использования
объектно-ориентированных языков разработки – объектный анализ и объектное
проектирование. При необходимости структурный и объектный подходы могут
использоваться одновременно.
Требования к надежности. В разделе должны быть определены
требования к обеспечению надежного функционирования: контроль входной и
выходной информации, время и механизмы восстановления после программных и
аппаратных отказов. В этом разделе описывается организация системы
безопасности, включая подсистемы контроля доступа, шифрования и т. п.
Настраиваемость. Определяются требования к адаптационным
возможностям ПО, то есть указывается, какие изменения в методах управления и
бизнес процессах должны быть предусмотрены.
Условия эксплуатации. В этом разделе описывается необходимое
обслуживание, которое требуется для работы системы, например, создание
резервных копий, реиндексерование баз и т. п., а так же требования к
квалификации персонала (пользователей и обслуживающего персонала).
Требования к составу и параметрам технических средств. Указывается
необходимый состав технических средств с указанием их основных технических
характеристик. Могут указываться требования к помещениям, в которых будет
находиться оборудование. В этом разделе указываются требования к переносимости
системы.
Требования к информационной и программной совместимости.
Требования к информационным структурам на входе и выходе, методам решения,
исходным кодам, языкам программирования и программным средствам, используемым
программой.
Требования к программной документации. В этом разделе указывается
предварительный состав программной документации, и при необходимости,
специальные требования к ней.
Еще раз необходимо подчеркнуть, что состав разделов технического задания
определяется особенностями проекта, например, в случае внедрения существующей
ЭИС требования к надежности, информационной и программной совместимости,
документации и т. п. имеют номинальное значение, поскольку эти характеристики
уже заложены в систему и указываются лишь как часть обязательств в рамках
контракта, не влияя на фактический объем работ. В случае разработки заказной
системы эти требования необходимо учесть при проектировании, они определят
состав работ и структуру проекта.
Динамика изменения требований зависит от выбранной модели жизненного цикла, в
каскадной (последовательной) модели*
требования определяются один раз в начале проекта, а в спиральной
(итерационной)** – уточняются в ходе
выполнения проекта. Во втором случае должна быть предусмотрена процедура
управления требованиями. Одним из возможных подходов является представление
совокупности требований в виде набора атомарных требований – утверждений, между
которыми выявляются отношения зависимости. При использовании каскадной модели
все требования содержаться в техническом задании, затем они преобразуются в
архитектурное решение в техническом проекте, в этом случае процедура управления
требованиями упрощается, ведь предполагается, что требования не будут меняться
в ходе проекта.
Описание хранимой и обрабатываемой информации в ЭИС делается с разной
степенью детализации. Используются три уровня детализации представлений
ЭИС, показанные на рисунке 2.
Рис. 2. Детализация представлений ЭИС
Единственное требование к данной детализации состоит в возможности
взаимно-однозначного преобразования внешнего представления в
концептуальное. Состав единиц информации и отношений в каждом внешнем
представлении определяется потребностями пользователей. В концептуальном
представлении эти структурные зависимости могут быть изменены.
Минимальный состав концептуального представления должен включать
описания экономических объектов, сведения о которых содержатся в ЭИС, отношений
между этими объектами и операций формирования производной информации.
Дополнительно могут указываться средства обеспечения целостности данных и
некоторые другие.
Уровень внешнего представления оказывается достаточным для применения ряда
прикладных программ, которые можно охарактеризовать как генераторы отчетов.
Генерация отчетов предполагает преобразование потока входной информации в
выходной поток. Само преобразование включает группировку информации,
подведение итогов и т.д. Результат оформляется в виде отчетов, удобных для
использования специалистами.
Концептуальное представление описывает полное информационное содержание базы
данных в более абстрактной форме по сравнению со способом физического
хранения данных. Оно может полностью отличаться от вариантов описания
информационных потребностей отдельными пользователями, в частности
использовать другую систему понятий, обозначений и правил описания. В
концептуальном описании необходимы не только сведения о структуре
обрабатываемой информации, но и сведения о технологии ее обработки –
применяемые методы контроля информации, описание использования потоков
информации в подразделениях предприятия, описание ограничений на доступ к
информации и ряд других.
К концептуальному представлению предъявляются требования устойчивости,
абстрактности и конструктивности.
Требование устойчивости означает, что ряд изменений в предметной области
не должен приводить к обязательной корректировке концептуального представления.
Концептуальное представление должно быть достаточно абстрактным, т.е. не
содержать ограничений, вытекающих из программной реализации требуемых методов
обработки данных.
Одним из существенных требований к концептуальной модели является ее
конструктивность, которая означает, что информации, зафиксированной в ней,
должно быть достаточно для последовательного формализованного перехода от
концептуальной модели к действующей системе машинной обработки данных.
В ряде случаев применение стандартных систем управления базами данных не
позволяет реализовать все требования к ЭИС (например, не обеспечиваются
требуемые режимы обработки данных или получено недостаточно высокое
быстродействие программ). Тогда для поддержки внутреннего уровня описания
системы потребуется разработка уникальных программ доступа к данным,
программ, обеспечивающих нестандартные методы обработки данных, и т. п.
Если структура хранимой базы данных изменяется (например, с целью ускорения
доступа к данным), то должны обеспечиваться все требования концептуального
описания системы, существовавшие до начала изменений.
При создании системы «ИНФИН-Управление» было уделено особое внимание
требованиям, которые предъявляют к программным комплексам отделы АСУ
(автоматизации систем управления). Как правило, именно от того, насколько
удобно и просто будет работать с программой сотрудникам отделов АСУ, зависит
успешное внедрение и безупречная работа любой системы на средних и крупных
предприятиях.,
Система «ИНФИН-Управление» представляет собой так называемый «коробочный»
программный продукт, несложный в эксплуатации и доработке. Она очень легкая
для понимания и обучения, каждый режим работы снабжен подробными подсказками.
Сотрудникам отдела АСУ не потребуется тратить свое время на объяснение
менеджерам и бухгалтерам основ программирования, система максимально
адаптирована под конечного пользователя и оперирует исключительно
экономическими и финансовыми терминами и понятиями.
В системе «ИНФИН-Управление» вся информация о ресурсах предприятия
(финансовых, материальных, кадровых, информационных) хранится в единой базе
данных, что позволяет получать объективные сведения о текущем состоянии дел в
реальном времени.
В системе «ИНФИН-Управление» представлены широкие возможности по составлению
самых различных аналитических отчетов, планов, бюджетов, как по отдельным
подразделениям, так и в целом по предприятию или группе предприятий. Система
позволяет осуществить анализ эффективности различных видов деятельности
предприятия, оценить работу конкретных отделов или сотрудников,
прогнозировать поступления денежных средств, отслеживать структуру доходов и
затрат, производить калькуляцию себестоимости и решать проблемы
ценообразования.
Высшее руководство сможет всегда оперативно получать ответы на вопросы типа:
§ какова прибыль на сегодняшний день,
§ каковы издержки по направлениям затрат и по местам возникновения,
§ какие ожидаются поступления и очередные платежи,
§ каковы отклонения фактических затрат от планируемых,
§ какие товары залежались на складе, а какие быстро реализуются,
§ сколько платить персоналу и т. п.
Система «ИНФИН-Управление» освободит сотрудников от рутинной работы, позволит
руководителям подразделений осуществлять оперативное управление, а высшему
руководству предоставит возможность заняться стратегическим планированием.
В комплексе предусматривается мощная система безопасности и разграничения
прав доступа. Система имен и паролей интегрирована с системой защиты
используемой СУБД. Предлагается гибкий и удобный механизм добавления,
корректировки и удаления пользователей системы. Каждому пользователю можно
установить уровень доступа к учетной информации строго в соответствии с его
компетенцией. Система запоминает автора каждой проведенной операции.
Система «ИНФИН-Управление» характеризуется высокой степенью надежности.
Разработан механизм контроля над случайными ошибками, нарушающими ведение
финансового или оперативного учета. Отслеживаются типы полей ввода, ссылочная
целостность. Исключена возможность частичного сохранения вводимой информации
или искажение информации при записи в систему.
Для упрощения администрирования, часть функций по управлению базой данных
продублировано интерфейсными средствами системы «ИНФИН-Управление».
Максимально упрощен механизм создания и восстановления страховых копий.
Администратору нет необходимости выходить на работу ночью или
приостанавливать работу в программе для всего предприятия. В системе «ИНФИН-
Управление» можно создавать страховые копии в многопользовательском режиме в
любое удобное время.
Разработанные в системе «ИНФИН-Управление» конструкторы позволяют быстро и
просто адаптировать программу к постоянно меняющимся требованиям, создавать
новые настройки или даже специализированные АРМы (автоматизированные рабочие
места). Они позволят адаптировать систему в соответствии с требованиями
текущего момента как силами сотрудников отделов АСУ, так любого опытного
пользователя. Использование конструкторов не требует знания программирования,
но если на предприятии работают квалифицированные программисты, то «ИНФИН-
Управление» предлагает широкий спектр средств разработки новых функциональных
возможностей и приложений системы. Отделам АСУ предоставляется возможность
самостоятельно автоматизировать любые бизнес-процессы на своем предприятии,
оставив программистам компании «ИНФИН» лишь работу по совершенствованию
конструкторов и других системных частей программного комплекса.
В заключении хотелось бы проанализировать типичные ошибки при определении
требований к информационной системе:
§ неполнота требований (структура). Определяются только
часть требований, например функциональные требования, при этом не указываются
требования к надежности, производительности, программной совместимости и т.д.
Применение стандарта на программную документацию (техническое задание) поможет
избежать эту проблему.
§ ошибки или неполнота описания бизнес-логики. Описывается
только основной поток процесса, а многочисленные альтернативные потоки не
исследуются. При этом количество и сложность альтернативных потоков значительно
превосходит количество и сложность основных потоков. Пример: фрагмента
основного потока процесса: прибыл заказанный товар на склад, количество и
номенклатура совпадают с заказанным, товар отправлен покупателю. Для этого
потока существует несколько альтернативных потоков: прибыл заказанный товар, но
количество отличается от заказанного (варианты, в большую, меньшую сторону),
отличается номенклатура товара (отклонения по размеру, цвету, сортности).
Проводится согласование с покупателем. Покупатель согласен (не согласен)
получить товар в ином количестве (ассортименте). Пример можно продолжить, но
наша задача лишь показать сложность и количество альтернативных потоков.
Выявление альтернативных потоков важно и по той причине, что мониторинг
отклонения процесса от основного потока, сбор статистики, является важной
функций управления.
§ избыточность требований. Избыточность требований
встречается так же часто, как и неполнота, как правило, они соседствуют в одном
документе. Основные признаки избыточности: описываемые требования реализуются
автоматически благодаря используемой технологии разработки или выбранной
архитектуре, требования не влияют на архитектуру информационной системы, ее
бизнес-логику (например, требования к содержанию данных, вместо требований к
структуре и объему информации), требования повторяются многократно в различных
частях документа (дублирование). Основная опасность избыточности требований в
отвлечении внимания, создании иллюзии полноты выявленных требований.
1. Калянов Г.Н. Подходы к реорганизации деятельности предприятия //
Экономика и производство. – 1998. – №11
2. Колтунова Е. Требования к информационной системе и модели жизненного
цикла // Сеть Интернет. – http://silicontaiga.ru/home.asp?artId=2142
3. Королев Д. Инновационный цикл в разработке проектов // Сеть Интернет.
– 2000. – http://www.bizcom.ru/.
4. Мишенин А.И. Теория экономических информационных систем. – М.:
Финансы и статистика, 2002.
5. Патрушина С.М. Информационные системы в экономике. – М.: МарТ, 2004.
6. Сеть Интернет, официальный сайт компании «ИНФИН». – http://www.infin.ru/
7. Сеть Интернет. – http://city.tomsk.net/~teis/1x8.htm
8. Сеть Интернет. – http://www.testpro.pisem.net/TEIS/cycle.htm
* В соответствии с каскадной моделью
переход на следующий этап может происходить только после завершения
предыдущего.
** Спиральная модель предполагает
циклическое выполнение всех этапов каскадной модели, в результате чего
реализуемость технических решений проверяется с помощью прототипов. Каждый
виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются
цели и характеристики проекта, определяется его качество и планируются работы.
|
|
|
|
|
