Термины 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

    • предпроектное обследование;
    • технико-экономическое обоснование;
    я составление технического задания;
    я техническое проектирование;
    я рабочее проектирование.
    Две последние стадии могут для небольших проектов быть объединены одну - технорабочее проектирование.
    Прежде чем начинать проектирование, необходимо выполнить обследование объекта, для которого создается ИС. Это достаточно важный этап, так как позволяет выделить характерные особенности объекта, которые следует учесть в характеристиках разрабатываемой ИС и которые определяют дальнейшую работу по проектированию. Любой процесс проектирования (и проектирования ИС в частности) является итерационным процессом, когда неоднократно приходится возвращаться на предыдущие этапы проектирования коррекции имеющихся результатов. От качества предпроектного обследования во многом зависит, придется ли в дальнейшем пересматривать основные концепции создаваемой ИС и вносить в нее принципиальные изменения, что всегда является трудоемкой задачей. На этапе предпроектного обследования следует сразу же настраиваться на то, что любое предприятие имеет свою специфику в производственных и бизнес-процессах. Поэтому знания о других предприятиях и о стандартных правилах организации этих процессов могут служить в большей части подспорьем в изучении предприятия, но отнюдь не являться целью внедрения. Обследование сводится к анализу существующей системы и объекта, для которого создается система. В частности, при этом следует уделять
    особое внимание общению на предприятии с экспертами и специалистами в интересующей предметной области, а также анализу документов и их движения. Обследование (сбор материалов) выполняется по двум основным направлениям: обоснованию эффективности создаваемой системы и выбору технических средств.
    Материалы для обоснования эффективности создаваемой системы включают в себя:
    • структуру существующей системы;
    • объемы выполняемой работы и трудозатраты;
    • качество выполняемой работы;
    • методы выполнения работы;
    ш ведение документации и др.
    Данные для выбора технических средств включают в себя:
    • структуру объекта;
    • технологию передачи информации, системы оперативной и диспетчерской связи;
    • сбор исходных данных;
    • наличие вычислительной техники;
    • систематизацию и оформление документов.
    В результате обследования должны быть получены и отражены в пояснительной записке следующие материалы, которые затем будут использованы в процессе проектирования:
    • общая характеристика объекта, для которого создается ИС;
    • функции, выполняемые в системе: периодичность выполнения, трудозатраты на их выполнение и т. д.;
    • характеристика используемой информации;
    • существующие принципы действия системы;
    • быстродействие системы;
    • структурные схемы существующей системы (организационная, функциональная, алгоритмическая и др.);
    • необходимые информационные потоки: виды документов, маршруты их движения и т. д.
    На основании изучения объекта формируется перечень задач, которые должна решать ИС. Обычно процесс создания ИС является многоэтапным, и должны быть предусмотрены возможности ее развития. Предпроектное обследование позволяет наметить состав первой очереди системы и дальнейшие пути ее совершенствования.
    Технико-экономическое обоснование создания ИС содержит следующие моменты:
    • исходные положения, характеристики и технико-экономические данные об объекте;
    • обоснование цели создания ИС;
    • обоснование комплекса задач, решаемых в ИС, и ДР.
    Технический проект содержит материалы, дающие представление о составе и функционировании ИС, и включает в себя: ,
    • общую характеристику объекта, для которого создается ИС;
    • организацию управления в условиях использования ИС;
    • используемый комплекс технических средств;
    • описание и постановку решения задач, входящих в ИС;
    • описание стандартного программного обеспечения;
    • описание организации информационной базы и т. д.
    Главное назначение технического проекта - определение основных направлений действия создаваемой системы, затрат, экономической эффективности, требуемых технических и программных средств, штатов обслуживающего персонала.
    Рабочий проект включает в себя документацию, необходимую для внедрения и функционирования системы:
    • документацию по используемым и разработанным программам (кстати, документация по разработанным программам может послужить прообразом справочной системы - см. 12);
    • инструкции по обработке данных (сбор, регистрация, обработка и передача информации);
    • должностные инструкции персонала и т. д.
    Следует обратить внимание на инструкцию для администратора БД - технического специалиста, который будет поддерживать работоспособность БД. В ней, кроме операций по архивированию, регистрации новых пользователей и т. п., обязательно должны быть описаны действия при различных сбоях в работе БД - от полного выхода из строя компьютера, где находится БД, до проблем, возникающих у пользователя при подключении БД. Кроме того, администратор обязательно должен знать структуру БД, поэтому желательно создавать ее с подробным, включая комментарии, описанием всех таблиц и их полей.
    Технический и рабочий проекты включают в себя следующие собственные этапы, которые, как правило, выполняются в указанной ниже последовательности:
    • выбор технических средств и стандартного программного обеспечения с учетом следующих особенностей;
    • используемых в организации программных и аппаратных средств, а также других информационных систем;
    • перспектив развития информационных технологий в организации (например, переход к работе с помощью Internet-технологий);
    • структуры организации и требований к безопасности информации;
    • уровня знаний и возможностей разработчиков;
    • создание ИС и БД;
    • создание программного обеспечения:
    • создание средств ввода, корректировки и удаления информации;
    • создание средств поиска информации;
    • создание средств отображения информации, включая формирование отчетов;
    • обеспечение контроля вводимой информации (выполняется параллельно с другими этапами создания программного обеспечения);
    • создание средств администрирования БД;
    • обеспечение работы программного обеспечения в сети;
    • создание справочной системы (желательно выполнять параллельно с другими этапами технорабочего проектирования);
    • локализация программного обеспечения;
    • формирование рабочего варианта программного обеспечения (удаление отладочной информации, создание ярлыка программы и т. д.);
    • разработка системы сбора информации;
    • создание инструкций по работе с системой. Безусловно, на количество и объем приведенных здесь этапов влияет, пожалуй, один из самых важных критериев - стоимость разработки.
    1. Основные классификации информационных систем
    Несмотря на значительное количество различных информационных систем, общая классификация их по назначению достаточно узкая.
    В общем можно выделить следующие направления ИС:
    • операционные системы,
    • ¦ АСУ - автоматизированные системы управления,
    • САПР - системы автоматизированного проектирования,
    • ГИС - геоинформационные системы,
    • Связь и телекоммуникация, "
    • Справочно-поисковые системы,
    • Системы информационной безопасности,
    • Системы подготовки и обработки мультимедийной информации (звука, изображения, видео),
    • редакционно-издательские системы.
    В отдельных системах могут сочетаться различные комбинации базовых. Например, АСУ магистральных газопроводов будет включать в себя и ГИС, и АСУ ТП (автоматизированную систему управления технологическими процессами), и элементы телекоммуникаций и т.п.

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

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

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

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

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

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

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

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

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

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

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

    Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС(например, Price Waterhouse, Jet Info, Consistent Software и др.).

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

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

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

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

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

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

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

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

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

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

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

    Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

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

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

    II этап - проектный (составление технического и рабочего проектов);

    III этап - внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);

    IV этап - анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).

    Рис.1.

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

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

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

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

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

    групповое обсуждение;

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

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

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

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

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

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

    В процессе постановки задачи раскрываются:

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

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

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

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

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

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

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

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

    Лекция № 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. Тестирование: обычно оказывается распределенным во времени. После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

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

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

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

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

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