Классификация информационных систем по характеру использования информации

Классификация информационных систем по степени автоматизации

Основные понятия технологии проектирования

Лекция № 1

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Лекции по предмету информационных систем (ИС)

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

· хранение

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

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

Информационная система состоит:

o источника информации,

o аппаратной части ИС,

o программной части ИС,

o потребителя информации.

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

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС:

1. Традиционные архитектурные решения основаны на использовании выделенных файл-серверов (File-server) или серверов баз данных (Client-server).

2. Корпоративные информационные системы , базируются на технологии Internet (Intranet-приложения).

3. "Хранилища данных" (DataWarehouse) - интегрированные информационные среды, включающие разнородные информационные ресурсы.

4. Архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода, которые используются для построения глобальных распределенных информационных приложений (Service Oriented architecture SOA).

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

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

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

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

Согласно статистическим данным , собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

• каскадная модель (характерна для периода 1970-1985 гг.);
• спиральная модель (характерна для периода после 1986.г.).

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

Методология проектирования ИС охватывает три основные области :

• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения цели проекта.

Цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя следующие пункты:

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

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

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

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

Конечными продуктами этапа проектирования являются:

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

· технический проект ИС (техническое задание), эскизный проект, рабочая документация.

3. Реализация: На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.

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

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

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

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

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

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

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

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

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

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

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

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

Проектирование ИС охватывает три основные области:

проектирование объектов данных, которые будут реализованы в базе данных;

проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

Требуемой функциональности системы и уровня ее

адаптивности к изменяющимся условиям функционирования;

требуемой пропускной способности системы;

требуемого времени реакции системы на запрос;

безотказной работы системы;

Необходимого уровня безопасности;

Простоты эксплуатации и поддержки системы.

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

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

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

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

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

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

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

Формы участия исполнителей в разработке проекта:

1) каждый соисполнитель выполняет проектные работы от начала до конца для какой-либо части разрабатываемой системы (обычно это комплекс задач управления)

2) отдельные соисполнители выполняют работы на отдельных этапах процесса проектирования.

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

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

1. по степени автоматизации:

метод ручного проектирования, при котором проектирование компонентов ИС осуществляется без использования специальных программных средств, а программирование – на алгоритмических языках;

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

2. по степени использования типовых проектных решений :

метод оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля»;

метод типового проектирования, когда ИС создается из готовых типовых проектных решений (программных модулей).

3. по степени адаптивности проектных решений :

метод реконструкции, когда адаптация проектных решений выполняется путем перепрограммирования программных модулей;

метод параметризации, когда проектные решения настраиваются в соответствии с изменяемыми параметрами;

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

Средства проектирования ИС делятся на два класса:

без использования ЭВМ

с использованием ЭВМ

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

Средства проектирования с использованием ЭВМ делят на четыре подкласса.

1 подкласс – это операционные средства, которые поддерживают проектирование операций обработки информации:

алгоритмические языки;

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

средства расширения функций операционных систем (утилиты);

средства для тестирования и отладки программ.

2 подкласс – это средства, поддерживающие проектирование отдельных компонентов проекта ИС:

системы управления базами данными (СУБД);

методо-ориентированные пакеты прикладных программ (решение задач дискретного программирования, математической статистики и т.п.);

табличные процессоры;

статистические ППП;

оболочки экспертных систем;

графические редакторы;

текстовые редакторы;

интегрированные ППП.

3 подкласс – это средства, поддерживающие проектирование разделов проекта ИС.

типовые проектные решения;

функциональные пакеты прикладных программ;

4 подкласс – это средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования. К данному классу относится подкласс средств автоматизации проектирования ИС (CASE-средства).

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

В таблице 1.2 приведен перечень наиболее популярных в настоящее время программных продуктов для реализации ИС организационного управления различных классов.

Таблица 1.2. Классификация рынка информационных систем

Локальные системы	Малые интегрированные системы	Средние интегрированные системы	Крупные интегрированные системы (IC)
Инотек Инфософт Супер-Менеджер Турбо-Бухгалтер Инфо-Бухгалтер	Concorde XAL Exact NS-2000 Platinum PRO/ MIS Scala SunSystems БЭСТ-ПРО 1C-Предприятие БОСС-Корпорация Галактика Парус Ресурс Эталон	Microsoft-Business Solutions - Navision, Axapta J D Edwards (Robertson & Blums) MFG-Pro (QAD/BMS) SyteLine (COKAП/SYMIX)	SAP /R3 ( SAP AG) Baan (Baan) BPCS (ITS/ SSA ) OEBS (Oracle E-Business Suite)

Существует классификация ИС в зависимости от уровня управления , на котором система используется.

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

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

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

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

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

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

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet ( Intranet -приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "хранилища данных" (DataWarehouse) - интегрированной информационной среды , включающей разнородные информационные ресурсы. И, наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода .

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

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

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

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

Тема 2. Методология проектирования ИС

Понятие методологии. 1

Методология разработки ИС.. 1

Выбор методологии создания ИС.. 5

Понятие методологии

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

Рис. 9. Структура методологии

Методология разработки ИС

В настоящее время существует ряд общих методологий разработки ИС.

На настоящий момент специалисты выделяют два подхода и более трех десятков методологий, ориентированных на создание систем комплексной автоматизации или проведения информационных проектов (Рис. 10). В числе наиболее известных методологий можно выделить: Rapid Application Development (RAD), DATARUN, Rational Unified Process (RUP), Oracle Custom Development Method (Oracle CDM) и другие. Такое количество методологий вызвано тем, что для создания различных классов систем используются разные методы их разработки, определяемые типом создаваемой системы и средствами реализации. Перечисленные методологии либо стандартизированы либо воспринимаются в профессиональном сообществе в качестве стандарта "де-факто".

Рис. 10. Подходы к проектированию ИС

Главное во всех этих методологиях – единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС (Рис. 11).

Рис. 11. Требования к методологии разработки ИС

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

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

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

– обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;

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

– поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

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

Рис. 12. Задачи методологии проектирования ИС

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

Проектирование ИС охватывает три основные области:

– проектирование объектов данных, которые будут реализованы в базе данных ;

– проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

– учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.

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

– требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

– требуемой пропускной способности системы;

– требуемого времени реакции системы на запрос;

– безотказной работы системы;

– необходимого уровня безопасности;

– простоты эксплуатации и поддержки системы.

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

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

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

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

Выбор методологии создания ИС

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

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

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

2 шаг. Выбор модели жизненного цикла ИС. На этом этапе происходит проверка применимости одной из трех базовых моделей жизненного цикла для конкретного проекта. Целесообразно выполнять эту проверку по методике предложенной Software Engineering Institute (SEI). Выбор модели жизненного цикла и выполненный на предыдущем шаге выбор подхода приводит к сокращению возможных для данного проекта стандартов до единиц.

3 шаг. Выбор стандарта/стандартов для реализации проекта. На этом этапе оставшиеся в рассмотрении стандарты проверяются на применимость с учетом специфики конкретного проекта и принимается окончательное решение о принятии за основу какого-либо из них. Иногда возникает ситуация, когда требуется комбинировать стандарты, создавая тем самым новый – гибридный вариант. Примером такой комбинации служит достаточно часто применяемая в практике отечественных консалтинговых компаний комбинация плана Уайта и ГОСТ 34.601-90. Необходимость такой комбинации вызвана тем, что ГОСТ более проработан в части проектирования ИС и имеет детально описанные требования к документированию проекта, а план Уайта – в части реализации и внедрения типовых проектных решений.

2. Intranet/Internet технологии в геодезии (технологии клиент/сервер).

3. Функциональные модели информационных объектов и бизнес-

Экзаменационный билет n 11

1. Кодирование информации, методы передачи информации, данные.

2. Теодолитная и тахеометрическая съемки.

3. Практический менеджмент информационных продуктов и

Экзаменационный билет n 12

1. Мировые информационные ресурсы.

2. Internet как транспортная среда для корпоративных информационных

3. Принципы оценки инженерно-геодезических работ.

Экзаменационный билет n 13

1. Web- ресурсы, методы поиска информации в Internet.

2. Организация хранения информационных ресурсов, вопросы

3. Проекции, применяемые при решении задач геодезии

Экзаменационный билет n 14

1. Операционные системы (ос): классификация, требования к порядку

2. Методы космической геодезии. Методы космической геодезии

3. Автоматизированное проектирование ис.

Экзаменационный билет n 15

1. Сервисы по: драйверы, интерфейсы, редакторы, средства передачи

2. Растровая и векторная графика в геодезии и картографии.

3. Архитектура микропроцессорных и компьютерных систем

1.4. Архитектура микропроцессорных систем

Вопрос 1

Экзаменационный билет n 16

Экзаменационный билет n 17

1. Жизненный цикл по.

2. Организационные методы защиты ис.

3. Фундаментальные геодезические постоянные.

Экзаменационный билет n 18

1. Геодезические приборы для измерений расстояний.

2. Нормативно-правовая база организации защиты информации.

3. Основы построения государственной геодезической сети (ггс) рф.

Экзаменационный билет n 19

2. Информационная инфраструктура предприятия (клиентская сеть).

3. Авторские права на профессиональные базы данных.

Экзаменационный билет n 20

2. Система государственной кодификации информационных ресурсов в

3. Проектирование гис.

Экзаменационный билет n 21

1. Средства линейных измерений в ггс.

2. Ис в геодезической и картографической сферах.

3. Порядок решения задач; обработка и хранение результатов, средства

Экзаменационный билет n 22

1. Web – дизайн.

Этапы проектирования Дизайн основной и типовых страниц сайта

2. Определение площадей. Электронные способы измерения площадей.

Экзаменационный билет n 23

1. Web – документы.

2. Автоматизированные ис.

3. Основы построения государственной геодезической сети (ггс) рф.

Экзаменационный билет n 24

1. Организация государственной геодезической службы в России.

2. Основные определения надежности ис.

3. Стандартизация сетей (iso, osi, эмвос – эталонная модель

Эталонная модель

Экзаменационный билет n 25

1. Топографические карты, номенклатура карт и планов.

Разбиение листа 1:1 000 000 на листы масштаба 1:200 000

Разбиение листа 1:1000000 на листы масштаба 1:100000

Приведем соответствие

2. Инженерно-техническая и физическая защита объектов в ис.

3. Клиентские сети; технологии «последней мили», сравнение технологий подключения клиентов.

Экзаменационный билет n 26

1. Ориентирование. Ориентирные углы, связь между ними.

Азимуты, румбы, дирекционные углы и зависимости между ними

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

Государственный геодезический надзор

О строительных допусках

3. Структура методов информационной безопасности.

Определения

Стандарты в области информационной безопасности

Экзаменационный билет n 27

1. Рельеф местности и его изображение на топографических картах.

Методы изображения рельефа на планах и картах

Горизонтали

Чем меньше высота сечения, тем точнее должна быть выполнена работа по съемке рельефа.

3.Управление интеллектуальной собственностью предприятий и

Управление интеллектуальной собственностью предприятий и организаций.

Виды интеллектуальной собственности Авторское право

Смежные права

Виды нарушений права интеллектуальной собственности

Международная защита интеллектуальной собственности

Законодательство России в сфере интеллектуальной собственности

Экзаменационный билет n 28

1. Электронные способы измерения расстояний. Электронные способы измерения расстояний

Измерение длины линий дальномерами

2. Классификация методов проектирования ис. Классификация методов проектирования ис

3. Методологические основы описания системы, как объекта исследования или инженерной деятельности.

Экзаменационный билет n 29

1. Понятие, определение информационной системы (ис).

Классификации информационных систем Классификация по архитектуре

Классификация по степени автоматизации

Классификация по характеру обработки данных

Классификация по сфере применения

Классификация по охвату задач (масштабности)

2. Определение компьютерных сетей, соединительных сетей

Классификация По территориальной распространенности

По типу функционального взаимодействия

3. Методы оценки точности результатов геодезических измерений.

Экзаменационный билет n 30

1. Структура ис.

2. Основы криптографии, стеганографии, шифрования, хеширования, как способы защиты информации.

3. Ис обработки и представления данных (карты, планы и т.П.)

Экзаменационный билет n 31

Экзаменационный билет n 32

2. Классификация методов проектирования ис. Классификация методов проектирования ис

Информационная система (ИС) - это система, предназначенная для сбора, хранения и обработки информации.

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

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

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

поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

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

Проектирование ИС охватывает три основные области:

проектирование объектов данных, которые будут реализованы в базе данных;

проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

Существует три основных метода проектирования ИС:

Каноническое проектирование.

Типовое проектирование.

Проектирование с помощью Case-технологий.

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

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

Стадия 1. Формирование требований к ИС.

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

обследование объекта и обоснование необходимости создания ИС;

формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

изучение объекта автоматизации;

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

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

оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

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

разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

разработка проектных решений по системе и ее частям;

разработка документации на ИС и ее части;

разработка и оформление документации на поставку комплектующих изделий;

разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

разработка рабочей документации на ИС и ее части;

разработка и адаптация программ.

Стадия 7. Ввод в действие.

подготовка объекта автоматизации;

подготовка персонала;

комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

строительно-монтажные работы;

пусконаладочные работы;

проведение предварительных испытаний;

проведение опытной эксплуатации;

проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

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

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

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

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

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

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

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

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

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

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

Типовое проектирование ИС.

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение. Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

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

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

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

Критерии оценки ППП делятся на следующие группы:

назначение и возможности пакета;

отличительные признаки и свойства пакета;

требования к техническим и программным средствам;

документация пакета;

факторы финансового порядка;

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

особенности эксплуатации пакета;

помощь поставщика по внедрению и поддержанию пакета;

оценка качества пакета и опыт его использования;

перспективы развития пакета.

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

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

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

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

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

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

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

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

Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

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

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

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

Реализация типового проекта предусматривает выполнение следующих операций:

установку глобальных параметров системы;

задание структуры объекта автоматизации;

определение структуры основных данных;

задание перечня реализуемых функций и процессов;

описание интерфейсов;

настройку системы архивирования.

CASE-технологии.

CASE-средства автоматизации – это методологий структурного системного анализа и проектирования ИС . Основные компоненты интегрированного CASE-пакета: 1) средства централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозитарий); 2) средства ввода; 3) средства анализа; 4) средства вывода - требования к компонентам и к их поддержке.

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

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

Помимо перечисленных основополагающих принципов графической ориентации, интеграции и

локализации всей проектной информации в репозитарии в основе концептуального построения

CASE-средств лежат следующие положения:

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

Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др).

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

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

Доступность для разных категорий пользователей.

Рентабельность.

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

Интегрированный CASE-пакет содержит четыре основные компонента:

Средства централизованного хранения всей информации о проектируемом ПО в течении всего

ЖЦ (репозитарий) являются основой CASE-пакета. Соответствущая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

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

Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.

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

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

Все перечисленные компоненты в совокупности должны: