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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Рис.1.

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

                             

 

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

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

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

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

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

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

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

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

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

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

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

 

Заключение:

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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