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

     Как и во всех проектах, для удачного завершения разработки ЭИС необходимым  условием является тщательная организация  и проработка начальных этапов (инновационного цикла проекта). Недостаточный анализ предметной области, обоснование требований к проекту «на скорую руку», нечеткое определение целей проекта, ошибки в оценке трудоемкости, стоимости и длительности создания ЭИС приводят к тому, что результаты проекта оказываются ниже намеченных, а сами проекты не укладываются в графики и бюджет разработки. Проектирование ЭИС в России регулируется ГОСТ 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.                                ПОЛЬЗОВАТЕЛИ

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

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

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

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

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

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

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

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