Проектирование информационных систем

Введение

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

Заключение

Литература

Введение

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

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

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

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

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

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

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

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

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

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

· требуемую пропускную способность системы;

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

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

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

· необходимую безопасность.

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

Проектирование информационных систем охватывает три основные области:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· будет ли это архитектура «файл-сервер» или «клиент-сервер»;

· будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

· будет ли база данных централизованной или распределенной.

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

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

· будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB).

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

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

· обнаружение отказов модуля (жестких сбоев);

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

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

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

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

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

Обычно выделяют следующие этапы создания ИС:

1. формирование требований к системе,

2. проектирование,

3. реализация,

4. тестирование,

5. ввод в действие,

6. эксплуатация и сопровождение.

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

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

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

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

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

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

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

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

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

2. Понятие «архитектура информационной системы»

Рассмотрим определение «архитектуры информационной системы», которое дают различные источники:

Архитектура – это организационная структура системы.

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

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

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

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

Если все эти определения объединить, то получим следующее:

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

Под архитектурой программных систем будем понимать совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему и их интерфейсов;

· поведения этих элементов во взаимодействии с другими элементами;

· объединение этих элементов в подсистемы;

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

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

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

Основные понятия и определения

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

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

Каждая ИС включает компоненты:

— структура системы – множество элементов системы и взаимосвязей между ними (например, организационная и производственная структура фирмы);

— функции каждого элемента системы;

— вход и выход каждого элемента системы (материальные или информационные потоки, поступающие в систему или выводимые ею);

— цели и ограничения системы.

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

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

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

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

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

— требуемую пропускную способность системы;

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

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

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

— необходимую безопасность.

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

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

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

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

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

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

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

Этапы проектирования ИС

⇐ ПредыдущаяСтр 8 из 15Следующая ⇒

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

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

2. Логическое проектирование
цель: создание логической модели привязанной к конкретному программному средству
результат – даталогическая модель

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

Совокупность процедур проектирования информационной системы можно разделить на 4 этапа:

Этап формулирования и анализа требований;

II. Этап концептуального проектирования;

III. Этап логического проектирования;

IV. Этап физического проектирования.

I. На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Все требования документируются в форме, доступной конечному пользователю и проектировщику БД.

II. Цель и задача концептуального проектирования состоит в описании и синтезе информационных требований пользователей к проекту информационной системы (ИС). На выходе должна быть составлена спецификация сущностей и связей и её называют «диаграмма сущность-связь» (Entity-Relationship).

Различают нисходящее и восходящее проектирование.

Методология нисходящего проектирования – анализ сущностей с дальнейшей специализацией:

1) моделирование представлений;

2) объединение представлений.

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

· общее представление (требование отчётности, необходимые проверки, управляющее воздействие, меры по обеспечению секретности);

· прикладное представление (все виды обработки БД, т.е. какие программы, приложения должны быть);

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

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

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

Объединение представлений. Многоуровневая диаграмма в виде информационной структуры:

1) согласование наименований (идентификация синонимов и омонимов среди элементов данных);

2) согласование идентификаций;

3) согласование агрегации (ограничение различных групп элементов на структурном уровне или операций над значениями элементов на уровне экземпляров);

4) уточнение допустимых подмножеств;

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

6) устранить противоречия в ограничении целостности.

Date: 2015-07-24; view: 448; Нарушение авторских прав

Понравилась страница? Лайкни для друзей:

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

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

— большая длительность процесса структурирования

— трудность учета и согласования изменений, сделанных в системе несколькими разработчиками

— ограничения сроков на разработку системы

— и т.д.

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

Такая технология получила название CASE (Computer Aided Software Engeneering — создание программного обеспечения с помощью компьютера). Основные черты CASE — технологии:

— использование методологии структурного проектирования «сверху-вниз»

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

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

— поддержка репозитария, хранящего спецификации проекта информационной системы на всех этапах ее разработки

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

— автоматизация различных стандартных действий по проектироваанию и реализации приложения

Как правило, CASE-системы поддерживают следующие этапы процесса разработки:

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

Концептуальное моделирование — создание модели «сущность-связь» на основе перечня объектов, полученного на предыдущем этапе. Здесь уточняются характеристики каждого объекта (атрибуты), устанавливаются связи между объектами.

Реляционное моделирование — преобразование модели «сущность-связь» в соответствии с требованиями реляционной модели. Правила порождения реляционных отношений из модели «сущность-связь» Генерация схемы базы данных. Результатом выполения данного этапа является набор SQL-операторов, описывающих создание схемы базы данных (CREATE TABLE, CREATE INDEX,…), с учетом особенностей целевой СУБД.

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

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

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

В общем случае стратегия выбора СП для конкретного применения зависит от следующих факторов:

— характеристик моделируемой предметной области;

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

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

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

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

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

— иерархическую структуру взаимосвязей компонентов, обеспечивающую устойчивость функционирования системы;

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

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

— необходимость достаточно длительного сосуществования старых приложений и вновь разрабатываемых БД и приложений;

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

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

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

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

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

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

— пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

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

На выбор СП могут существенно повлиять следующие особенности методологии проектирования:

— ориентация на создание уникального или типового проекта;

— итерационный характер процесса проектирования;

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

— жесткая дисциплина проектирования и разработки при их коллективном характере;

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

Критерии выбора

Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое внимание уделялось особенностям реализации той или иной методологии анализа предметной области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство изобразительных и описательных средств дает возможность на этапах стратегического планирования и анализа построить наиболее полную и адекватную модель предметной области.

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

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

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

Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.

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

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

— декомпозиция проекта на составные части и интеграция составных частей;

— проектирование моделей приложений (логики приложений и пользовательских интерфейсов);

— прототипирование приложений;

— проектирование баз данных;

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

— разработка распределенных баз данных (с выбором оптимальных вариантов распределения);

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

— адаптация к различным системно-техническим платформам и СУБД;

— тестирование и испытания;

— сопровождение, внесение изменений и управление версиями и конфигурацией ИС;

— интеграция с существующими разработками (включая реинжиниринг приложений, конвертирование БД);

— администрирование ИС (оптимизация эксплуатационных характеристик);

— управление разработкой и сопровождением ИС (планирование, координация и контроль за ресурсами и ходом выполнения работ);

— прогнозирование и оценка трудоемкости, сроков и стоимости разработки.

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

Добавить комментарий

Закрыть меню