Физическое моделирование аис. Модели ЖЦ АИС

I. Блоки построения АИС. Методы и средства проектирования Проектирование - процесс создания проекта-прототипа, прообраза предполагаемого или возможного объекта, его состояния. Современная технология создания АИС - совокупность эффективных средств и методов проектирования, позволяющих упростить данный процесс, уменьшить стоимостные затраты, сократить календарные сроки проектирования системы и, в конечном итоге, за счет возможности более широкого выбора проверенных прогрессивных проектных решений, повысить качество разработки. Основные средства проектирования : -стандартные средства операционных систем, обеспечивающих автоматическое прохождение на ЭВМ определенного класса задач; -процедуры, реализующие типовые процессы обработки данных, например контроль выходной информации и ее сортировку; -инструментальные средства, к которым относится совокупность взаимосвязанных специальных программных средств, предназначенных для инструментальной поддержки отдельных элементов процесса проектирования АИС. Это создание и актуализация словаря данных, документирование проекта, автоматизация контроля проектирования и др.; -типовые компоненты, представленные в виде типовых проектных решений (ТПР) и пакетов прикладных программ (ППП). ТПР - совокупность алгоритмических, программных, инструктивно-методических элементов, обеспечивающих машинную реализацию задач или комплекса с помощью соответствующих технических средств. ТПР - основа создания ППП, к которым относятся комплексы программ, обеспечивающих работу типовых конфигураций вычислительной техники, диалоговых систем при решении типовых функциональных задач; -системы автоматизированного проектирования (САПР), предполагающие использование ЭВМ на всех этапах создания АИС и занимающие высшую ступень в эволюции средств проектирования системы. В методах проектирования различают классы и подклассы: Классы: -оригинальное проектирование . Средства, используемые при этом методе: - стандартные средства операционных систем; - процедуры, реализующие типовые процессы обработки данных. -типовое проектирование . Подклассы: элементы, подсистемы, объектное, групповое. Средства: стандартные средства операционных систем; типовые компоненты (ТПР, ППП); некоторые инструментальные средства. -автоматизированное проектирование . Подклассы: модульное; др. Средства: стандартные средства операционных систем САПР; взаимосвязанный комплекс инструментальных средств. Средства проектирования подразделяются на: -комплексные - это ТПР, ППП, типовые проекты автоматизированных систем, САПР. -локальные - большое разнообразие, в их состав входят системы управления базами данных, телеобработки, инструментальные средства и др. Общие требования к средствам проектирования : -полный охват всего процесса создания АИС; -совместимость, требующая согласованных решений как в процессе создания системы и ее обеспечивающих подсистем, так и в процессе их функционирования; -универсальность в своем классе, допускающем возможность применения одних и тех же средств для различных объектов; -д.б. легко доступными, не требующими особых усилий в освоении и просты в реализации; -возможность организации процесса проектирования в режиме интерактивного взаимодействия разработчика системы, проектировщика и ЭВМ; -д.б. адаптированными и экономически эффективными. Методы оригинального проектирования являются традиционными и ориентированы на одно предприятие. Характерная черта - разработка оригинальных методик обследования объекта, его внедрения, создания необходимой проектной документации в виде индивидуального проекта. Достоинство - отражение в проекте АИС специфических особенностей объекта автоматизации. Недостатки: сравнительно высокая трудоемкость и большие сроки разработки, низкий показатель функциональной надежности и адаптируемости к изменяющимся условиям. Проекты, созданные оригинальным методом, поддаются модернизации, однако в чистом виде этот метод используется редко. При его реализации используются в настоящее время различные средства проектирования и лишь для отдельных частей проекта требуются оригинальные проектные решения. Так, общесистемные проектные решения по разработке информационного обеспечения включают методы сбора, контроля и передачи данных, создание нормативно- справочных массивов информации, по программному обеспечению, определяют версию операционной системы, типовые процедуры обработки информации и т.д. Это несколько сглаживает его недостатки. Этот метод особенно актуален при автоматизации сложных, неординарных объектов. Типовое проектирование - индустриальный метод создания АИС, использующий ТПР и ППП, характеризуется наличием апробированных, типовых организационно-экономических, технических, информационных, математических и программных средств автоматизации управления. Достоинства: уменьшает трудоемкость, снижает стоимость и сокращает сроки проектирования, повышая его качество путем более полного охвата задач функциональных подсистем, строгого соблюдения требований нормативных документов, применения передовых технических решений. Типовое проектирование призвано устранить дублирование проектов, создать основу для расширения обмена готовыми типовыми компонентами, облегчить разработку рекомендаций по изменению организационной структуры и методов управления с учетом отраслевых и внутрихозяйственных особенностей. Процесс типового проектирования заключается в выборе и привязке указанных средств в соответствии с треб-ми конкретной системы. Типовая часть АИС представляет собой комплекс информационного, программного и технического обеспечения. Типовой характер первого достигается путем строгого соблюдения единства структуры информационной базы, состава массивов, форм входных и выходных документов; второго- на использовании ППП, и последнего в результате применения ЭВМ одного или совместных типов. Основами элементного проектирования являются ТПР - результат выполнения нескольких взаимосвязанных технологических операций проектирования, при разработке проекта используется уже готовое решение с небольшими модификациями, а не разрабатывается новое. Комплекс типовых проектных решений подразделяется на три группы: “Техника”, “ Задача”, “ Персонал”. Первая группа служит для выбора и комплектации всех видов технических средств вычислительных центров или др. организационных форм их применения. Вторая - содержит документацию по организационно-экономической сущности каждой задачи, алгоритмы их решения, описание входной и выходной информации, соответствующие программные модули с их описаниями и инструкциями по применению. Третья - должностные инструкции всех категорий работников, определяющие их права и обязанности. ТПР создаются по модульному принципу, когда каждое проектное решение расчленяется на отдельные составные части- модули, которые реализуют определенную часть ТПР. Это позволяет создать проект новой автоматизированной системы путем сочетания отдельных типовых модулей. При использовании подсистемного метода проектирования предполагается более высокая степень интеграции типовых элементов системы, когда для каждой подсистемы создаются проекты решений и пакеты прикладных программ. Выделение подсистем- в зависимости от объекта хозяйственно-производственного процесса. Для каждой из подсистем разрабатывается свое автоматизированное проектное решение и ППП, которые могут быть общесистемного или функционального назначения. К первой группе относятся ППП управления данными, типовых процедур их обработки, методовматематической статистики и дискретного программирования, решения непрерывных задач, например дифференциальных уравнений. Во вторую группу входят пакеты, ориентированные на промышленные предприятия с дискретным или непрерывным характером производства, на непромышленную сферу, отраслевое управление. Важное требование, предъявляемое к ППП,- совместимость, т.к. при проектировании АИС целесообразно использовать сразу несколько пакетов. Проектирование систем с применением ППП фактически сводится к привязке выбранных по определенным параметрам пакетов к конкретным условиям объекта автоматизации. Достоинства: менее трудоемкий процесс, занимает меньше времени по сравнению с оригинальным проектированием, реализует прогрессивные методы обработки данных, упрощает документирование проекта, т.к. используется документация пакетов, повышается надежность проектируемых систем. Метод объектного проектирования базируется на применении типовых проектов автоматизированных систем управления. Применяется недостаточно широко, т.к. слишком много разнообразных объектов, а модификация типового проекта системы в соответствии с конкретными условиями объекта автоматизации требует больших трудовых и материальных затрат. Отдельной группой выделяется метод группового проектирования . Его сущность: предварительно подбирается группа объектов, однотипных по характеристикам их информационных систем, среди них выбирается базовый объект, для которого и разрабатывается проект, причем могут использоваться различные методы и способы проектирования, главное- это обеспечение его высокой адаптивности. Основная сфера применения этого метода- непромышленные объекты (например склады), т.к. они более устойчивы с позиции экономической информационной системы. Среди автоматизированных методов особое место занимают методы модульного проектирования . Создание и использование САПР обеспечивает достаточно высокий уровень функциональной надежности, комплексный охват всех технологических процессов, снижение трудоемкости проектных работ с максимальным учетом интересов объекта автоматизации. Однако этот метод достаточно дорог и требует высококвалифицированных разработчиков. Ключевое требование, предъявляемое к САПР, - возможность построения и поддержания в системе проектирования в адекватном состоянии некоторой глобальной экономической информационной модели объекта автоматизации. Модель - отображение информационных компонентов объекта автоматизации и отношение между ними, заданные в явном виде. Основная цель построения модели - создание соответствующего этой модели проекта АИС, учитывающего и активно использующего все характеристики объекта. Такая модель должна содержать в формализованном виде описание совокупностей информационных компонентов и отношения между ними, включая информационные связи и алгоритмическое взаимодействие. С помощью модульного метода проектирования применяется системный подход, обусловливающий использование ЭВМ не только на всех стадиях создания системы, но и в процессе анализа результатов ее промышленной эксплуатации. Развитие и применение САПР предопределило переход к созданию индивидуальных проектов, но на значительно более высоком уровне, по сравнению с оригинальным методом проектирования. Разработкой, внедрением, сопровождением и эксплуатацией корпоративных информационных систем (или сокращенно КИС) занимаются специалисты по информационным технологиям (ИТ). Информационные технологии являются очень широким понятием, поскольку они определяют методы и средства создания, сбора, регистрации, передачи, обработки, хранения и выдачи информации в информационных системах. В настоящее время наряду с названием Корпоративные информационные системы (КИС) употребляются, например, следующие названия: · Автоматизированные системы управления (АСУ); · Интегрированные системы управления (ИСУ); · Интегрированные информационные системы (ИИС); · Информационные системы управления предприятием (ИСУП). Основные стадии проектирования автоматизированных информационных систем · Перед началом проектирования АИС необходимо детально обосновать необходимость ее создания, подробно описать цели и задачи проекта, ожидаемую прибыль, временные затраты, доступные ресурсы, ограничения и т. д. Такие работы часто называют стратегическим планированием информационной системы, и для их осуществления назначается менеджер проекта. Необходимость разработки любой АИС может быть обусловлена следующими факторами: ростом значимости информационной среды предприятия; комплексностью системы управления предприятием; необходимостью анализа потенциальных возможностей и опасностей предприятия; необходимостью систематизации деятельности предприятия; необходимостью постоянного повышения эффективности использования основных фондов предприятия, улучшения соотношения цены и качества; повышением роли капиталовложений в сферу информатизации предприятия; необходимостью кадрового планирования для адекватного обеспечения развития предприятия; ростом сложности и комплектности существующих ИС, влекущим за собой усложнение функциональных требований к ИС и их развитию. Главная особенность стратегического планирования информационной системы состоит в том, что именно в этот период уточняются потребности организации в информации, что и определяет возможные варианты структуры информационной системы. В зависимости от интенсивности функционирования информационно-технологического комплекса выделяют следующие группы организаций: организации, развитие которых зависит от использования информационных технологий для ежедневной деятельности (банки, страховые компании и т. д.); организации, не зависящие от информационных технологий, но способные в будущем широко их использовать для достижения конкурентных преимуществ; организации, в деятельности которых информационные технологии не могут стать источником конкурентного преимущества; организации, использующие информационные технологии для поддержки деятельности, не являющейся основной. Для каждой из описанных групп разрабатываются информационные системы, автоматизирующие соответствующие участки деятельности организации . Разработка и внедрение любой АИС осуществляется в определенной последовательности в соответствии с техническим заданием. Содержание первой очереди управленческой системы определяется составом задач учета, анализа, планирования и оперативного управления, наиболее поддающихся автоматизации и имеющих существенное значение для принятия управленческих решений в организации. В процессе разработки последующих очередей системы происходит расширение и интеграция информационного, программного и математического обеспечения, модернизация технических средств. Жизненный цикл АИС позволяет выделить четыре основных периода: предпроектный, проектный, внедрение, эксплуатация и сопровождение . Технология проектирования автоматизированных информационных систем в настоящее время определяется действующим ГОСТ 34.601-90, согласно которому весь процесс разбит на стадии и этапы . 1. Стадия «Формирование требований к АИС»: определение объема обоснования, необходимого для создания АИС (сбор данных об объекте автоматизации и осуществляемых видах деятельности, оценка качества его функционирования, выявление проблем, решение которых возможно средствами автоматизации, оценка целесообразности создания АИС); формирование требований пользователя к АИС; оформление отчета о выполненных работах и подача заявки на разработку АИС. 2. Стадия «Разработка концепции АИС»: изучение объекта АИС; проведение необходимых исследовательских и проектных работ; разработка вариантной концепции АИС и выбор варианта, который удовлетворяет требованиям пользователя, оценка преимуществ и недостатков альтернативных вариантов; оформление отчета о выполненной работе. 3. Стадия «Техническое задание»: разработка и оформление технического задания на создание АИС (общие сведения, назначение и цели создаваемой системы, характеристика объекта автоматизации, требования к системе в целом, ее функциям и задачам, видам обеспечения, планам работ по созданию, вводу в действие и приемке). 4. Стадия «Эскизный проект»: разработка предварительных проектных решений по системе и ее частям (функции АИС, ее подсистемы, состав задач, концепция и структура информационной базы, состав и основные характеристики технических средств); разработка документации на АИС и ее элементы. 5. Стадия «Технический проект»: разработка проекта решений по системе и ее элементам, по функциональной, алгоритмической и организационной структуре системы, структуре технических средств, организации и ведения базы данных, по системе классификации и кодирования информации, алгоритму решения задач, используемым языкам программирования и программному обеспечению; разработка документов АИС; разработка и оформление документации на поставку изделий для комплектования АИС и технических требований на их разработку; разработка заданий на проектирование. 6. Стадия «Рабочее проектирование»: разработка рабочей документации на систему и ее части; разработка или адаптация программ. 7. Стадия «Ввод в действие»: подготовка АИС к внедрению; сдача задач и подсистем в опытную эксплуатацию; составление отчета о вводе в действие. 8. Стадия «Сопровождение АИС»: анализ функционирования системы; авторский надзор. Особенность разработки АИС заключается в концентрации сложности и трудоемкости на стадиях предпроектного обследования, так как ошибки, допущенные на этапах обследования, анализа и проектирования, порождают на этапах внедрения и эксплуатации часто неразрешимые проблемы достижения поставленных целей и эффективности использования АИС. Формирование требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т. д. Планирование работ включает предварительную экономическую оценку проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы. На этом этапе осуществляется системный анализ рассматриваемой системы, который включает в себя описание структуры элементов системы и проведение обследования деятельности автоматизируемого объекта; анализ распределения функций по подразделениям и сотрудникам, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий. Fuckyeah. Анализ завершается построением моделей деятельности организации, предусматривающих обработку материалов обследования и построения функциональных и информационных моделей двух видов: модели «as is» («как есть»), отражающей существующее положение дел в организации; модели «to be» («как должно быть»), отражающей представление о новых технологиях и бизнес-процессах организации. По результатам обследования определяется перечень задач, решение которых целесообразно автоматизировать, и очередность их разработки (рис. 8.2). Рис. Результаты обследования Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки АИС и определения уровня экономической эффективности ее внедрения. Содержание и оформление технического задания регламентируются требованиями ГОСТ 34.602-89. Стадия эскизного проектирования предполагает предварительный выбор методов проектирования и оценку ожидаемых результатов, однако зачастую эта стадия вводится в состав технического проектирования . Технический проект разрабатывается в целях определения основных проектных решений по созданию системы. На этом этапе осуществляется комплекс исследовательских работ для выбора наилучших вариантов решений, провіодятся эксперименталь ная оценка проектных решений и расчет экономической эффективности системы. Для каждой задачи, включенной в комплекс первоочередных задач, выполняется детальная постановка задачи и разработка алгоритма ее решения. Целью этой стадии является формирование новой структуры системы и логических взаимосвязей ее элементов, которые будут функционировать на выбранной технологической основе. Построение системной архитектуры предполагает выделение элементов и модулей информационного, технического, программного обеспечения и других обеспечивающих подсистем, определение связей по информации и управлению между выделенными элементами и разработку технологии обработки информации . Рабочее проектирование включает разработку спецификаций каждого компонента и материалов, обеспечивающих эффективную эксплуатацию АИС, которые содержат уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности АИС. Техническая часть рабочего проекта предусматривает определение технических средств, описание технологического процесса обработки данных, расчет и составление графика загрузки комплекса технических средств, описание режима функционирования АИС . Внедрение разработанного проекта предполагает выполнение следующих этапов : подготовка объекта управления к внедрению АИС, опытное внедрение, т. е. проверка работоспособности элементов и модулей проекта и устранение выявленных ошибок, и промышленное внедрение - этап сдачи в эксплуатацию и проверки на уровне функций, контроль соответствия требованиям, сформулированным на стадии системного анализа (рис. 8.3). На стадии эксплуатации и сопровождения собирается статистика о качестве работы каждого из компонентов системы, исправляются обнаруженные недостатки, в некоторых случаях принимается решение о необходимости расширения функциональности системы (рис. 8.4) . В целом процесс проектирования АИС условно включает в свой состав только основные стадии, а реальный набор этапов и технологических операций в значительной степени зависит от выбранного подхода проектирования. Рис. Основные работы, выполняемые на стадии внедрения АИС Рис. Работы, выполняемые на стадии эксплуатации и сопровождения

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

Существует 2 способа описания моделœей:

1) статический, рассматривающий структуру модели, ᴛ.ᴇ. такие её аспекты, в которых можно пренебречь временем;

2) динамический, рассматривающий поток событий, ᴛ.ᴇ. изменение моделируемых явлений во времени, которым нельзя пренебречь с точки зрения решаемых задач.

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

Исполнительный директор должен иметь общую картину: процессы, продукцию, финансы, перспективы и т.д., ᴛ.ᴇ. интегрированную картину в целом. Для того, чтобы управляющий персонал мог принимать правильные решения в любых ситуациях, крайне важно иметь набор моделœей, описывающих разные стороны деятельности фирмы и их взаимоотношения. В моделях, используемых на верхнем уровне управления, самое главное - ϶ᴛᴏ краткость и понятность. В них должны быть подчёркнуты основные моменты, а детали бывают скрыты.

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

Рисунок 1 – Модель иерархически организованной компании

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

Среди известных моделœей жизненного цикла АИС можно выделить каскадные, итерационные и спиральные модели.

Каскадная модель (до 70 ᴦ.ᴦ.) предполагает переход на следующий этап после полного завершения работ предыдущего этапа. Эта модель используется при построении АИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать всœе требования. Это дает разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие.

Рисунок 2 – Схема каскадной модели

Преимущества каскадной модели:

1) на каждом этапе формируется законченный набор проектной документации, отвечающей критериям полноты и согласованности;

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

Недостатки каскадной модели:

1) запоздание с получением результатов;

2) крайне важность возврата к предыдущим этапам.

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

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

Рисунок 3 – Схема поэтапной итерационной модели

Недостатки: Как правило, вследствие большого числа итераций возникают рассогласования в выполненных проектных решениях и документации. Запутанность функциональной и системной архитектуры созданной АИС, трудность в использовании проектной документации вызывают на стадиях внедрения и эксплуатации сразу крайне важность перепроектирования всœей системы. Жизненный длительный цикл разработки АИС заканчивается этапом внедрения, за которым начинается жизненный цикл создания новой АИС.

Спиральной модель (80-90 ᴦ.ᴦ.) – опирается на начальные этапы жизненного цикла: анализ, предварительное и детальное проектирование.

Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта͵ определяется его качество, планируются работы следующего витка спирали. Основная проблема - определœение момента перехода на следующий этап. Для ее решения крайне важно ввести временные ограничения на каждый из этапов ЖЦ. Переход осуществляется в соответствии с планом, который составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Недостатком этого подхода являются нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования. Οʜᴎ могут привести на последующих этапах к проблемам и даже к неуспеху всœего проекта. По этой причинœе анализ и проектирование должны выполняться особенно тщательной

Рисунок 4 – Схема спиральной модели

В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD-технологии (Rapid Application Development – технологии быстрой разработки приложений). Согласно этой технологии АИС разрабатывается путём расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при этой технологии сокращается число итераций и возникает меньше ошибок и несоответствий, которые крайне важно исправлять на последующих итерациях. При этом проектирование АИС идёт более быстро, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной АИС всё большее значение придаётся ведению общесистемного репозитария и использованию САSЕ-технологий.

Жизненный цикл при использовании RAD-технологии предполагает активное участие конечных пользователœей будущей системы на всœех этапах разработки и включает 3 основные стадии информационного реинжиниринга:

1) анализ и планирование информационной стратегии : пользователи вместе со специалистами-разработчиками принимают участие в идентификации проблемной области;

2) проектирование : пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;

3) внедрение : специалисты-разработчики обучают пользователœей работе в среде новой АИС.

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

Существует три класса методологий проектирования АИС:

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

Выявление требований и спецификация информационной системы через ее макетирование;

Системная архитектура программных средств, поддерживаемая инструментальными средствами CASE-технологии (CASE - Computer Aided Software Engineering - технология создания и сопровождения ПО различных систем).

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

Спецификация - точное, полное, ясно сформулированное описание требований для данной задачи.

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

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

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

Модель ЖЦ АИС включает:

Результаты выполнения работ на каждой стадии;

Ключевые события или точки завершения работ и принятия решений.

В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС -каскадную, итерационную, спиральную.

I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.

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

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

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

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

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

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

Последний этап - сдача готового проекта, и главное здесь - убедить заказчика в том, что все его требования выполнены в полной мере.

Рис.1.1 Каскадная модель ЖЦ АИС

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

Преимущества каскадной модели:

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

2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.

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

Недостатки каскадной модели:

Существенная задержка в получении результатов;

Ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата;

Сложность параллельного ведения работ по проекту;

Чрезмерная информационная перенасыщенность каждого из этапов;

Сложность управления проектом;

Высокий уровень риска и ненадежность инвестиций.

Задержка в получении результатов проявляется в том, что последовательном подходе к разработке согласование результатов с заинтересованными сторонами производится только е завершения очередного этапа работ. В результате может оказаться, что разрабатываемая АИС не соответствует требованиям, и такие несоответствия могут возникать на любом этапе разработки; кроме того, ошибки могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязаны хорошо разбираться в тех предметных областях, для которых разрабатывается АИС.

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

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

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

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

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

В случае же обнаружения ошибок в работе необходим возврат к предыдущим этапам; текущая работа тех, кто ошибся, прерывается. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов.

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

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

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

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

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

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

Недостатки итерационной модели:

· время жизни каждого этапа растягивается на весь период работки;

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

· запутанность архитектуры;

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

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

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

Рис. 1.2. Спиральная модель ЖЦ АИС

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

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

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

Преимущества итерационного подхода:

Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

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

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

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

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

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

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

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

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

Модель жизненного цикла и технология проектирования

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

· задачи, состав и последовательность выполняемых работ;

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

· методы и средства, необходимые для выполнения работ;

· роли и ответственность участников;

· иную информацию, необходимую для планирования, организации и управления коллективной разработкой ИС,

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

Этапы и стадии проектирования

Часто смешивают понятия «этап» и «стадия» проектирования. Иногда говорят об этапах или фазах жизненного цикла, шагах проектирования. Возникает вопрос: как правильно?

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

По опубликованным данным каждый этап разработки АИС требует определенных затрат времени. В основном (45-50 %) время уходит на кодирование, комплексное и автономное тестирование. В среднем разработка АИС занимает одну треть всего ЖЦ системы.

Рис. Распределение времени при разработке АИС

Стадии создания АИС (ISO/IEC 15288)

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

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

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

3. Проектирование АИС

На основе разработанных принципов, положений, моделей, методов и средств построения АИС, полученных на стадии исследования, проводится проектирование системы.

Стадия проектирования состоит из следующих этапов:

1) предметное обследование (ПРО) существующей (традиционной) ИС;

2) разработка технического задания на создание системы;

3) разработка технического проекта на создание системы;

4) разработка рабочего проекта на создание системы.

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

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

Этап разработки ТЗ - логическое продолжение этапа ПРО. Материалы, полученные на этапе ПРО используются для разработки ТЗ. Здесь проводится анализ и разработка принципиальных требований, предъявляемых к АИС со стороны конкретного заказчика или потенциальной группы потребителей. Формулируются требования к аппаратным, программным, информационным и организационно-правовым компонентам АИС и др.

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

­ цель, задачи, функции АИС, рассматриваются также внешние условия функционирования системы, распределение функций между ее компонентами;

­ системные параметры АИС - интерфейсы и распределение функций между оператором и системой;

­ конфигурация всех подсистем АИС, образующих её структуру - документационно-информационная, техническая, программно-математическая и организационно-правовая составляющие структуры системы;

­ структура и система управления БД, лингвистические средства, состав информационно-поисковых языков, классификаторов и кодификаторов, методик индексирования документов и запросов;

­ ведомость конфигурации комплекса технических средств АИС и их спецификация;

­ состав и характеристика математических моделей, алгоритмов и программ АИС;

­ схема функционирования АИС, технологического процесса обработки данных и др.;

­ должностные и рабочие инструкции для персонала АИС;

­ уточненное технико-экономическое обоснование проекта.

Основную долю трудоемкости рабочего проектирования составляют работы по разработке алгоритмов и соответствующих программ.

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

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

Методы и средства проектирования АИС. Проектирование АИС может выполняться:

­ сторонней фирмой-разработчиком. Эта фирма имеет штат высококвалифицированных профессионалов. Работа проводится на основании договора между фирмой-разработчиком и фирмой-заказчиком;

­ силами штатных специалистов фирмы-заказчика.

Возможно и компромиссное решение: фирма-заказчик может пригласить консультанта по разработке АИС на контрактной основе.

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

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

На этапе предпроектного обследования используются методы изучения фактического состояния существующей (традиционной) ИС:

­ устный или письменный опрос;

­ письменное анкетирование;

­ наблюдение, измерение и оценка;

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

­ анализ задач;

­ анализ производственных, управленческих и информационных

­ процессов.

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

­ моделирование процессов обработки данных;

­ структурное проектирование;

­ декомпозиция;

­ анализ информационной технологии.

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

4. Автоматизация проектирования АИС

Автоматизированные системы проектирования - эффективное средство улучшения показателей проектирования АИС. В области проектирования сформировалось особое направление - программная инженерия или CASE-технологии (Computer-Aided Software/System Engineering - система компьютерной разработки программного обеспечения). CASE-технологии - это совокупность методов анализа, проектирования, разработки и провождения АИС, поддержанных комплексом взаимосвязанных средств автоматизации. CASE-технологии - это средство для системных аналитиков, разработчиков и программистов, обеспечивающее автоматизацию процессов проектирования АИС различного класса и значения.

Основная цель CASE-технологии - максимально автоматизировать процесс разработки и отделить процесс проектирования от кодирования программных средств АИС.

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

Расчленение сложной системы на части, представляемые как «черные ящики», каждый «черный ящик» реализует определенную функцию системы управления;

Иерархическое упорядочение выделенных элементов системы с определением взаимосвязей между ними;

Использование графического представления взаимосвязей элементов системы.

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

В составе методологий структурного анализа к наиболее распространенным можно отнести следующие:

SADT - технология структурного анализа и проектирования, и ее подмножество - стандарт IDEFO.

DFD - диаграммы потоков данных.

ERD - диаграммы «сущность - связь».

STD - диаграммы переходов состояний.

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

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

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

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

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

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

Объектно-ориентированные методы построения моделей системы управления. Эти методы отличаются от структурных более высоким уровнем абстракции. Они основаны на представлении системы в виде совокупности объектов, взаимодействующих между собой путем обмена данными. В качестве объектов предметной области могут служить конкретные предметы или абстрагированные сущности - заказ, клиент и т.п. Наиболее значим метод Г. Буча. Это техника объектного проектирования с элементами объектного анализа, имеющая четыре этапа:

1) разработка диаграммы аппаратных средств, отображающей процессы, устройства, сети и их соединения;

2) определение структуры класса, описывающей связь между классами и объектами;

3) разработка диаграмм объектов, которые показывают взаимосвязь объекта с другими объектами;

4) разработка архитектуры ПО, описывающей физический проект создаваемой системы.

Подавляющая часть существующих методов объектно-ориентированного анализа и проектирования включает в себя как язык моделирования, так и средства описания процессов моделирования.

Объектно-ориентированный подход не противопоставляется структурному, а может служить его дополнением.

5. Построение и внедрение АИС

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

Определение источников финансирования и выделение средств на закупку необходимого оборудования, предусмотренного проектом, - «Ведомость спецификации оборудования АИС»;

Выбор поставщиков и заключение контрактов на поставку оборудования;

Выделение помещения для дислокации АИС и его подготовка к монтажу оборудования;

Размещение, сборка, монтаж, настройка оборудования АИС в соответствии с проектом;

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

Выполнение работ по проверке качества оборудования (контроль, тестирование). При обнаружении дефектов - оформление и предъявление рекламаций к поставщикам;

Инсталляция ПО и выполнение работ по тестированию программного комплекса АИС. При условии обнаружения дефектов - принятие мер по их устранению;

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

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

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

1) документальное оформление результатов пусконаладочных работ оборудования, а также контрольных испытаний комплекса задач системы;

2) обучение персонала технологии АИС и изучение соответствующих разделов проектной документации;

3) проведение опытной эксплуатации системы, анализ и корректировка проектных ошибок и оформление документации по результатам опытной эксплуатации;

4) сдача АИС в производственную эксплуатацию с оформлением соответствующей документации.

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

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

6. Методика расчета технико-экономической эффективности автоматизированной обработки информации

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

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

Высокой скорости выполнения операций по сбору, передаче, обработке и выдаче информации, быстродействия технических средств;.

Максимального сокращения времени на выполнение отдельных операций;

Улучшения качества обработки данных и получаемой информации.

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

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

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

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

С э = С б – С п (1)

где С э - величина снижения затрат на обработку данных;

С б - затраты при базисном варианте;

С п - затраты при проектируемом варианте.

Относительный показатель экономической эффективности проекта АИС - коэффициент эффективности (К э) затрат и индекс изменения затрат (I з).

К э = С э / С б * 100 % (2)

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

Значение индекса изменения затрат можно определить по формуле:

I з = С э / С б. (3)

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

При внедрении проекта АИС необходимо учитывать дополнительные капитальные затраты, значение которых (К 3) можно определить по формуле:

K 3 = K п – K б (4)

где K п и K б - капитальные затраты соответственно проектируемой и базовой систем обработки данных.

Эффективность капитальных затрат определяется сроком окупаемости (Т) дополнительных капитальных затрат на модернизацию ИС:

Т = K 3 / С э (5)

Е = С э / K 3 = 1 / Т. (6)

Наряду с расчетом стоимостных затрат полезно получение показателей снижения трудовых затрат на обработку данных. Абсолютным показателем снижения трудовых затрат (t) выступает разность между годовыми трудовыми затратами базового и проектируемого вариантов обработки данных:

t = Т б. – Т п (7)

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

Значение относительного показателя снижения трудовых затрат можно отобразить коэффициентом снижения трудовых затрат (К):

K t = t / T б. (8)

Индекс изменения трудовых затрат (I t) характеризует рост производительности труда за счет освоения более трудосберегающего варианта проекта обработки данных, его можно определить по формуле:

I t = Т б / Т п. (9)

Абсолютный показатель снижения трудовых затрат (Р) применяется для определения потенциального высвобождения трудовых ресурсов (исполнителей) из системы обработки данных:

Р = (t / Т ф) * f (10)

где Т ф – годовой фонд времени одного исполнителя, занятого в технологии обработки данных;

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

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

Экономию трудовых затрат (Э тз) при автоматизированной обработке информации по проекту можно определить по формуле

Э тз = Т о6щ – Т сов (11)

где Т о6щ - трудоемкость обработки данных традиционным способом при базовым варианте;

Т сов - трудоемкость автоматизированной обработки данных при проектном варианте.

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

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

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

Наибольшее распространение получили две основные модели ЖЦ:

· каскадная модель (70-85 гг.);

· спиральная модель (86-90 гг.).

Каскадная модель

Каскадный способ - разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис.2).

Положительные стороны применения каскадного подхода:

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

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

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

Рис.2 Схема каскадного подхода

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

Рис.3 Реальный процесс создания ИС на базе каскадной модели

Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model).

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

В спиральной модели жизненного цикла (рис.4) делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.

Рис 4.

Каждый виток спирали соответствует созданию нового фрагмента или версии информационной системы, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также "Продолжающимся проектированием". Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", rapid prototyping approach или "fast-track".

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