Требования, предъявляемые к экономической информации (стр. 2 из 3)

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. требования к документации

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

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

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

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

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