Этапы проектирования ис. Учебный курс

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

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

• предпроектное обследование;
• технико-экономическое обоснование;

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

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

ш ведение документации и др.
Данные для выбора технических средств включают в себя:

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

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

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

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

• исходные положения, характеристики и технико-экономические данные об объекте;
• обоснование цели создания ИС;
• обоснование комплекса задач, решаемых в ИС, и ДР.

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

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

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

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

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

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

1. Основные классификации информационных систем

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

• операционные системы,

• ¦ АСУ - автоматизированные системы управления,

• САПР - системы автоматизированного проектирования,
• ГИС - геоинформационные системы,
• Связь и телекоммуникация, "
• Справочно-поисковые системы,
• Системы информационной безопасности,
• Системы подготовки и обработки мультимедийной информации (звука, изображения, видео),
• редакционно-издательские системы.

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

Несмотря на достаточно узкую классификацию по основным направлениям, внутри каждого может быть множество разновидностей.
Одно из разделений - по роду деятельности (машиностроение, торговля, строительство). Например, АСУ могут подразделяться на:

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

Или, САПР делятся на:

• САПР в строительстве,
• САПР в машиностроении,
• САПР в электронной промышленности,
• САПР в авиастроительстве и т.д.

Другое разделение соответствует назначению системы. Так, например, системы САПР могут разделяться на:

• системы подготовки чертежной документации,
• системы расчета на прочность, жесткость и устойчивость,
• системы подготовки проектно-сметной документации,
• системы подготовки документации на конкурс и т.п.

Кроме того, следует рассмотреть деление по возможности пересечения видов деятельности. При этом необходимо рассматривать системы общего и специализированного назначения. Например, такие системы разработки чертежной документации, как AutoCAD и MicroStation являются системами САПР общего назначения. Оперируя общими графическими примитивами (отрезками, дугами, размерными линиями и т.п.), пользователь может подготовить чертежную документацию для любой отрасли промышлен
ности. Наоборот, САПР ArchiCAD, speedikon, ArCON являются специализированными для строительства, и здесь пользователь оперирует не общими, а специализированными примитивами-объектами, как то: стены, окна или проемы, лестницами и т.д. С помощью этих систем можно быстрее и качественнее подготовить проектную документацию по объекту строительства, чем с помощью систем общего назначения. Однако подготовить проектную документацию для строительства корабля или самолета практически невозможно. Аналогично обстоит дело с САПР расчета на прочность. Например, системы ANSYS и NASTRAN - системы общего назначения, с их помощью можно рассчитать хоть здание, хоть самолет. А вот система ProFET amp; Stark ES ориентированна на расчет здания, с ее помощью можно быстрее и более «профильно» рассчитать здание. А вот при расчете самолета эти САПР лучше не использовать.
Заметим, что вокруг оболочки программ САПР общего назначения создаются десятки различных расширений возможностей. Многие компьютерные фирмы разрабатывают подсистемы к программам общего назначения, предоставляющие пользователю больший круг возможностей для использования общей системы в конкретной отрасли промышленности.
Вместе с тем на рынке программных продуктов существует множество различных ИС сходного назначения. Так, для автоматизации бухгалтерского учета сегодня предлагаются системы «1C», «Инфо-бухгалтер», «Парус», «Инотек НТ», «Gendalf», «Овионт информ», «Камин», «Плюс-мик- ро», «СБиС++» и многие другие. Успех той или иной системы на рынке зависит порой не только от качества программного продукта, но и от грамотно организованной маркетинговой и рекламной политики фирмы, от организации разветвленной сети дилеров и технического сопровождения. Аналогичное многообразие программных продуктов наблюдается и в других сферах деятельности человека. экранных форм , отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• будет ли это архитектура "файл-сервер" или "клиент-сервер";
• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
• будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

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

Жизненный цикл информационных систем

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

Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта приня­то разделять на фазы (стадии, этапы}.

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

Можно выделить следующие фазы развития информационной системы:

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

Формирование идеи, постановку целей;

Формирование ключевой команды проекта;

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

Сбор исходных данных и анализ существующего состояния;

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

Сравнительную оценку альтернатив;

Представление предложений, их экспертизу и утверждение;

2. разработка технического задания. Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы:

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

Разработка и утверждение технического задания;

Планирование, декомпозиция базовой структурной модели проекта:

Составление сметы и бюджета проекта, определение потребности в ресурсах;

Разработка календарных планов и укрупненных графиков работ;

Подписание контракта с заказчиком;

Ввод в действие средств коммуникации участников проекта и контроля за хо­дом работ;

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

Выполнение базовых проектных работ;

Разработка частных технических заданий;

Выполнение концептуального проектирования;

Составление технических спецификаций и инструкций;

Представление проектной разработки, экспертиза и утверждение.

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

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

· меню действий – это горизонтальный список объектов на экране, представляющих группу действий, доступных пользователю для выбора;

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

· схема программы отображает последовательность операций в программе;

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

· схема работы системы отображает управление операциями и потоками данных и отражает технологический процесс обработки данных в системе.

4. изготовление. На этой фазе производятся координация и оперативный контроль работ по проек­ту, осуществляется изготовление подсистем, их объединение и тестирование. Ос­новное содержание:

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

Выполнение подготовки к внедрению системы;

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

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

Комплексные испытания;

Подготовка кадров для эксплуатации создаваемой системы;

Подготовка рабочей документации, сдача системы заказчику и ввод ее в экс­плуатацию;

Сопровождение, поддержка, сервисное обслуживание;

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

Разрешение конфликтных ситуаций и закрытие работ по проекту;

Накопление опытных данных для последующих проектов, анализ опыта, состо­яния, определение направлений развития.

Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) - фазами реализации.

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

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

Ошибки в определении интересов заказчика;

Концентрация на маловажных, сторонних интересах;

Неправильная интерпретация исходной постановки задачи;

Неправильное или недостаточное понимание деталей;

Неполнота функциональных спецификаций (системных требований);

Ошибки в определении требуемых ресурсов и сроков;

Редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Под этапами (стадиями или фазами) будем понимать совокупность ступеней развития проекта от возникновения идеи до полного завершения проекта. В определении количества этапов и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее, логика и основное содержание процесса разработки ИС почти во всех случаях являются общими. [Избачков с. 40-43] Обычно выделяют следующие этапы создания проекта ИС [Вендеров]:

Анализ. Задача формирование требований к системе является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки.Анализ деятельности организации, выполняемый на данном этапе, должен помочь в формировании требований к ИС, корректно и точно отражающих цели и задачи организации- заказчика. Наряду с изучением требований пользователя и имеющихся систем на этапе анализа необходимо создать логический проект системы. С помощью логического проектирования необходимо определить концептуальную модель данных, входные данные, процессы и предполагаемые выходные данные. Моделирование данных, выполняемое на данном этапе, включает в себя выявление и описание объектов и их атрибутов, а также связи между сущностями (описание модели в виде ER-диаграммы). Описание и документирование всех преобразований данных (процессов) может быть выполнено с помощью таких средств анализа, как схемы информационных потоков (DFD – data flow diagram) или моделей функций и процессов.Конечной целью моделирования бизнес-процессов, протекающих в организации и реализующих ее цели и задачи является построение моделей организации, описанных в терминах бизнес-процессов и бизнес-функций. На этом же этапе изучаются имеющееся оборудование и программные средства. Результатом анализа должно стать лучшее понимание функционального назначения системы, существующие и потенциальные проблемы, а также сфера ее действия.

На этом этапе конечные пользователи и проектировщики должны работать сообща.

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

Схема БД (на основании ER-модели, разработанной на этапе анализа); - набор спецификаций модулей системы (на базе моделей функций). Также на этапе проектирования определяется: - выбор платформы и ОС (могут быть не единственными); - характеристики архитектуры: ф/с или к/с; количество уровней (1, 2 или 3); централизованная или распределенная БД; однородность или неоднородность БД (по количеству используемых серверов). Этап проектирования заканчивается разработкой технического проекта ИС.

Реализация. На этом этапе осуществляется создание всех компонент ПО ИС, установка технических средств, разработка эксплуатационной документации.

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

А) после завершения разработки отдельного модуля системы выполняют автономный тест , который преследует следующие цели: - обнаружение отказов модуля (жестких сбоев); - соответствие модуля спецификации (наличие всех необходимых функций и отсутствие лишних функций). Б) После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходиттесты связей , которые должны отследить их взаимное влияние. После тестирования на взаимное влияние модулей необходимо выполнить еще ряд тестов: В)тесты на проверку надежности работы: 1) тест имитации отказов, демонстрирующий, насколько хорошо система восстанавливается после сбоев ПО и отказов аппаратного обеспечения; 2) тест наработки на отказ (устойчивость системы при штатной работе для оценки времени безотказной работы системы); 3) системный тест (проверка функциональности системы); 4) приемо-сдаточные испытания (такой тест предусматривает показ ИС заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика). Как правило, тестирование и эксплуатация занимают от 50% до 60% общего времени разработки ИС. V.Ввод в действие. Эксплуатация и сопровождение. После ввода в действия организуется обучение конечных пользователей. Практически сразу после ввода системы в строй конечные пользователи начинают просить внести в нее изменения. Внесение изменений и исправлений выполняется службой сопровождения системы, работающей в трех направлениях: - корректирующее обслуживание – как ответ на возникающие ошибки системы; - адаптивное обслуживание – как ответ на изменение корпоративной среды; - усовершенствование – расширение возможностей системы.

1.2 Этапы проектирования информационно-справочных систем

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

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

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

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

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

Многие предприятия предпочитают разрабатывать АИС собственными силами, так как:

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

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

3. это позволяет обеспечивать значительно более высокий уровень безопасности и независимости от внешних факторов.

4. возможна оперативная реакция на изменения правил игры на рынке.

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

Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам собственные разработки АИС в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД.

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

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

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

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

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

Ориентация на профессиональные СУБД может способствовать достижению следующих целей:

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

2) Надежные средства защиты информации (учитывая стандартную трехзвенную архитектуру защиты на уровне сети - на уровне сервера БД - на уровне клиентской ОС).

3) Эффективные инструменты для разграничения доступа к БД.

4) Поддержка широкого диапазона аппаратно - программных платформ.

5) Реализация распределенной обработки данных.

6) Возможность построения гетерогенных и распределенных сетей.

7) Развитые средства управления, контроля, мониторинга и администрирования сервера БД.

8) Поддержка таких эффективных инструментариев, как: словари данных, триггеры, функции, процедуры, пакеты и т.п.

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

Основные причины ориентации на использования профессиональных СУБД при построении своих АИС :

"ПРОТИВ" - Относительно высокая дороговизна профессиональных СУБД

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

"ПРОТИВ" - Профессиональные СУБД предъявляют высокие требования к аппаратной платформе.

"ЗА" - С резким ростом производительности Intel-ориентированных аппаратных платформ большинство производителей профессиональных СУБД выпустила свои версии и под Intel-сервера, в том числе и под ОС LINUX, а учитывая что LINUX при всей своей мощности UNIX системы практически бесплатная ОС, то и решение на ее основе как правило не повлечет больших финансовых затрат. Это позволяет при построении системы ориентироваться не только на высокопроизводительные многокластерные RISC сервера, но и использовать серверные Intel-платформы.

"ПРОТИВ" - Профессиональные АИС сложны и дороги в администрировании.

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

"ПРОТИВ" - Разработки АИС на промышленной платформе слишком дороги.

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

"ПРОТИВ" - Внедрение систем на профессиональной платформе процесс затяжной и дорогостоящий.

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

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

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

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

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

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

А) Разработка и анализ бизнес - модели

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

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

Аппаратно-технический состав создаваемой АИС.

Б) Формализация бизнес - модели, разработка логической модели бизнес -процессов.

Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.

В) Выбор лингвистического обеспечения, разработка программного обеспечения АИС.

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

Г) Тестирование и отладка АИС

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

Д) Эксплуатация и контроль версий

Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС.

Рис.1.3 Последовательность трансформации бизнес-модели в объекты БД и приложения

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

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

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

Выявление нереализуемых или необычных конструкций в ER-модели и в определениях сущностей;

Разрешение всех дуг, подтипов и супертипов;

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

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

Определение части бизнес-логики, которую следует реализовать в базе данных (пакеты, хранимые процедуры);

Реализация ограничений (ограничений и триггеров), отражающих все централизованно определенные бизнес-правила, генерация ограничений и триггеров;

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

Определение необходимых индексов, кластеров (если таковые реализованы в СУБД), определение горизонтальной фрагментации таблиц (если это реализовано в СУБД);

Оценка размеров всех таблиц, индексов, кластеров;

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

Определение пользователей базы данных, их уровней доступа, разработка и внедрение правил безопасности доступа, аудита (если это необходимо), создание пакетированных привилегий (в зависимости от реализации СУБД это роли или группы), синонимов;

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

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

Информационная система может строиться с применением послойного принципа. Так, в отдельные слои можно выделить специализированное программное обеспечение (офисное, прикладное), непосредственно workflow, систему управления документами, программы поточного ввода документов, а также вспомогательное программное обеспечение для связи с внешним миром и обеспечения доступа к функционалу системы через коммуникационные средства (e-mail, Internet/intranet).

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

ГЛАВА 2. ХАРАКТЕРИСТИКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ГОУ НПО ПУ №33

Рабочим органом, функции который будет выполнять созданный в качестве главного организационного инструмента совершенствования РИС – Аналитический Центр Инновационного Развития (АЦИР). Стратегическая функция АЦИР – организационно-правовое и финансовое сопровождение креативной деятельности в регионе, объединение под единым управлением инновационной и инвестиционной функции. Создатели инноваций (...

Для лучшей освещенности. Во время ухода на перерыв также следует тушить электроприборы, станки, прочие электроприборы. Установка энергосберегающих ламп дневного света Лб 40, Philips -1000. 4.5 Режим работы медницко-радиаторного участка 251 рабочих дней в году. Режим работы: в одну смену с 8:00 до 17:00. Перерыв на обед с 12:00 до 13:00. Технологические перерывы по 10 минут – в 10 часов и...