70603

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

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-10-22

42.33 KB

3 чел.

Лекция 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


 

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

31805. Технология принятия решений в условиях поведенческого риска 23 KB
  Формируется когда существуют др лица принимающие решение и основное ЛПР опасается их т.к либо интересы основного ЛПР столкнулись с интересами др ЛПР либо сущ различия в позициях точках зрения традиций основного лица и др ЛПР либо ЛПР считает природу в кот принимаемое решение неопределенной непредсказуемой и поэтому агрессивной.
31806. Формы разработки и реализации управленческих решений 36.5 KB
  Указание решение носящее методический технологический характер. Акт решение широкого круга государственных и общественных организаций. Приказ письменный или устный это решение руководителя обличенного властью в организации или крупном ее подразделении. Распоряжение это решение руководителя не наделенного административными функциями.
31807. Сущность, функции, виды и методы контроля управленческого решения 30 KB
  Контроль организации исполнения УР система наблюдения проверки оценки и коррекции положения дел на основе критерия. Виды контроля: 1Постоянный ежедневно 2Регулярный еженедельно 3Промежуточный ежемесячно 4Переодический составление отчета 5Детальный 6Факторный Контроль как функция управления. Контроль УР как на стадии разработки так и на стадии реализации является важнейшей функцией управления. Контроль может осуществляться в двух вариантах: по результатам и по упреждению.
31808. Сущность и виды ответственности руководителей за принятие управленческого решения 30.5 KB
  Ответственность мера соответствия действий человека групп людей или обва взаимным требованиям нормам. Ответственность это необходимость обязанность отдавать комулибо отчет в своих действиях поступках. Ответственность может быть официальная и личная чувство ответственности как черта характера. Виды ответственности: 1Внутрифирменная: аадминистративная выговор бэкономическая лишение премии впрофессиональная понижение в должности 2Внешняя: аюридическая арест бсоциальная вморальная Юридическая ответственность частично или...
31809. Планирование и прогнозирование в процессе принятия управленческих решений 25 KB
  Метод прогнозирования способ исследования объекта прогноза направленный на разработку прогнозов. Состояние объекта в будущем определяется закономерностями выявленным по частным результатам опыта его проведения в прошлом и настоящем. Осущся от имеющегося уровня знаний а конечные результаты развития объекта составляют содержание прогноза. Ориентирован на то что задается цель развития объекта в будущем а содержанием прогнозов становится определение частных путей.
31810. Экспертные методы прогнозирования решения 27 KB
  Экспертные методы базируются на информации которую поставляют специалистыэксперты в процессе систематизированных процедур выявления и обобщения этого мнения. Например при проведении экспертного опроса участникам представляют цифровую информацию об объекте или фактографические прогнозы либо наоборот при экстраполяции тенденции наряду с фактическими данными используют экспертные оценки. Экспертные методы разделяются на два подкласса. Прямые экспертные оценки строятся по принципу получения и обработки независимого обобщенного мнения...
31811. Фактографические методы прогнозирования решения 26 KB
  Фактографические методы прогнозирования решения. Фактографические методы базируются на фактически имеющемся информационном материале об объекте прогнозирования и его прошлом развитии. Экспертные методы базируются на информации которую поставляют специалистыэксперты в процессе систематизированных процедур выявления и обобщения этого мнения. Комбинированные методы выделены в отдельный класс чтобы можно было относить к нему методы со смешанной информационной основой в которых в качестве первичной информации используются фактографическая и...
31812. Комплексные системы прогнозирования решения 30.5 KB
  Позволяет: Выбрать объект прогноза выявить внутренние закономерности его развития написать сценарий сформулировать задачи и генеральную цель прогноза провести анализ иерархии и декомпозицию цели принять внутреннюю и внешнюю структуру объекта прогнозирования провести анкетирование выполнить математическую обработку данных анкетного опроса количественно оценить структуру верифицировать результаты разработать алгоритм распределения ресурсов провести распределение ресурсов оценить распределение ресурсов Методика примечательна тем что сочетает...
31813. Модели процесса принятия решений 27 KB
  2политические система предпочтений лица принимающего решение 3организационные в большинстве организаций есть организованные анархии процесс принятия решений в которых обладает особенностями. 4 Три типа ППР 1Сначала думаю: определение проблемы диагностика проектирование решениевыбор 2Сначала вижу: подготовка инкубирование проектирование верификация 3Сначала делаю: действие выбор закрепление 5 Классификация процессов взаимодействия руководителя со своими подчиненными: 1 Вы решаете задачу самостоятельно используя ту...