Читайте также:
|
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
· принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
· принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
К структурному подходу относятся такие методы проектирования как idef0, idef3, dfd, er
Принципиальное различие между структурным и объектно-ориентированным (ОО) подходом заключается в способе декомпозиции системы (рис.2). ОО подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами
К объектно-ориентированному подходу относят такую методологию как UML
4. Методологии проектирования ИС. CASE-технологии, их содержание и классификации. Инструментальные средства реализации.
CASE-технологии – это программные средства, поддерживающие методологию проектирования информационных систем, а также набор инструментальных средств, поддерживающих процессы создания и сопровождения информационных систем, моделирование предметной области, включая анализ и формулировку требований, проектирование процессов и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом.
Использование CASE-технологий позволяет:
- улучшить качество создаваемого программного обеспечения за счет средств автоматического контроля;
- ускорить процесс проектирования и разработки;
- обеспечить поддержку сопровождения разработки;
- обеспечить поддержку технологий повторного использования
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
· интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
В состав интегрированного CASE-средства (или комплексf средств, поддерживающих полный ЖЦ ПО) входят следующие элементы:
- репозиторий, позволяет обеспечить сохранность вариантов проекта и его определенных компонентов, синхронизацию информации от разных разработчиков в процессе групповой разработки, проверка метаданных на полноту и непротиворечивость;
- средства разработки приложений, с использованием языков 4GL и генераторов кодов;
- средства тестирования;
- средства документирования;
- графические средства анализа и проектирования, которые дают возможность создавать и редактировать иерархически связанные диаграммы (DFD, ERдиаграмма и др.), создающие модели информационных систем;
- средства реинжиниринга.
- средства конфигурационного управления;
- средства управления проектом.
CASE-инструменты классифицируются по типам и категориям.
Классификация по типам отражает функциональную ориентацию средств на те или иные процессы жизненного цикла разработки программного обеспечения, и, в основном, совпадают с компонентным составом крупных интегрированных CASE-систем, и включает следующие типы:
· средства анализа — предназначены для построения и анализа предметной области (BPwin Logic Works).;
· средства проектирования баз данных (ERwin)
· средства разработки приложений (PowerBuilder);
· средства реинжиниринга процессов (изменение процессов (полное)) (Vantage Team Builder, ERwin).;
· средства планирования и управления проектом;
· средства тестирования;
· средства документирования.
Классификация по категориям определяет степень интегрированности по выполняемым функциям и включают — отдельные локальные средства, решающие небольшие автономные задачи, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла и полностью интегрированных средств, охватывающий весь жизненный цикл информационной системы и связанных общим репозиторием.
Типичными CASE-инструментами являются:
· инструменты управления конфигурацией;
· инструменты моделирования данных;
· инструменты анализа и проектирования;
· инструменты преобразования моделей;
· инструменты редактирования программного кода;
· инструменты рефакторинга кода (делать код проще для понимания, не меняя его поведения);
· генераторы кода;
· инструменты для построения UML-диаграмм.
Именно BPwin (All Fusion Process Modeler) и ERwin (All Fusion ERwin Data Modeler) на сегодняшний день являются наиболее популярными CASE- средствами, входящими в пакет AllFusion Modeling Suite – интегрированный комплекс CASE-средств, обеспечивающий все потребности компаний-разработчиковпрограммного обеспечения. Данный пакет служит для проектирования и анализа баз данных, бизнес-процессов и информационных систем и включает продукты:
BPwin, ERwin,AllFusion Data Model Validator (инструмент для проверки структуры баз данных и создаваемых в ERwin моделей), AllFusion Model Manager (среда для работы группы проектировщиков на ERwin и BPwin), AllFusion Component Modeler (моделирования компонентов программного обеспечения и генерации объектного кода приложений на основе созданных моделей).
Правильный выбор и грамотное применение CASE-средств при автоматизации процессов проектирования позволяет произвести оптимизацию информационных систем, значительно повысить их эффективность, снизить вероятность ошибок, а также сократить издержки.
Основными методологиями, реализованными в CASE – средствах являются:
SADT (Structured Analysis and Design Technique) – методология структурного анализа и проектирования. Основана на понятиях функционального моделирования. Отражает такие системные характеристики, как управление, обратная связь и исполнитель.
IDEF0 (Integrated Definition Function Modeling) – методология функционального моделирования. Используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями. Является подмножеством методологии SADT.
DFD (DataFlow Diagram) – методология моделирования потоков данных. Применяется для описания обмена данными между рабочими процессами.
IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы.
IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы.
IDEF3 – методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса.
IDEF1X (IDEF1 Extended) – методология описания данных. Применяется для построения баз данных. Относится к типу методологий «Сущность-связь» и используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе.
IDEF4 – объектно-ориентированная методология. Отражает взаимодействие объектов. Позволяет наглядно отображать структуру объектов и заложенные принципы их взаимодействия. Удобна для создания программных продуктов на объектно-ориентированных языках.
IDEF5 – методология онтологического исследования сложных систем. Системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени.
ARIS – описывает бизнес-процесс в виде потока последовательно выполняемых работ.
UML – (Unified Modeling Language) язык визуального моделирования, основанный на объектно-ориентиро- ванном подходе, позволяют описать статическую структуру системы и ее динамическое поведение.
5. Каноническое проектирование ИС. Стадии и этапы процесса проектирования ИС. Состав проектной документации.
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС, которая подразумевает полное завершение некоторого типа работ перед переходом к следующему этапу на котором выполняется другой тип работ. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
• обследование объекта и обоснование необходимости создания ИС;
• формирование требований пользователей к ИС;
• оформление отчета о выполненной работе и тактико-технического задания на разработку.
Стадия 2. Разработка концепции ИС.
• изучение объекта автоматизации;
• проведение необходимых научно-исследовательских работ;
• разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
• оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
• разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
• разработка предварительных проектных решений по системе и ее частям;
• разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект.
• разработка проектных решений по системе и ее частям;
• разработка документации на ИС и ее части;
• разработка и оформление документации на поставку комплектующих изделий;
• разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
• разработка рабочей документации на ИС и ее части;
• разработка и адаптация программ.
Стадия 7. Ввод в действие.
• подготовка объекта автоматизации;
• подготовка персонала;
• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-
техническими комплексами, информационными изделиями);
• строительно-монтажные работы;
• пусконаладочные работы;
• проведение предварительных испытаний;
• проведение опытной эксплуатации;
• проведение приемочных испытаний.
Стадия 8. Сопровождение ИС.
• выполнение работ в соответствии с гарантийными обязательствами;
• послегарантийное обслуживание.
6. Состав работ на предпроектной стадии, стадии технического и рабочего проектирования, стадии ввода в действие ИС, эксплуатации и сопровождения.
В процессе проектирования ИС можно выделить 3 укрупненные стадии проектирования ИС:
■ Предпроектную, включающую стадии 1-3
■ Проектную, включающую стадии 4-6
■ Послепроектную стадию, включающую стадии 7-8.
| Стадии | Этапы работ |
| 1. Формирование требований к АС | 1.1. Обследование объекта и обоснование необходимости создания АС.
|
| 2. Разработка концепции АС. | 2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. · На этапах 2.1 и 2.2 организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. · проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; определение порядка оценки качества и условий приёмки системы; оценку эффектов, получаемых от системы 2.4. Оформление отчёта о выполненной работе. · подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии описания и обоснования предлагаемого варианта концепции системы. |
| 3. Техническое задание. | Разработка и утверждение технического задания на создание АС. · проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС. |
| 4. Эскизный проект. | 4.1. Разработка предварительных проектных решений по системе и её частям. · определяются: функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепция информационной базы, её укрупнённая структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств. 4.2. Разработка документации на АС и её части. · проводят разработку, оформление, согласование и утверждение документации в объёме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС |
| 5. Технический проект. | 5.1. Разработка проектных решений по системе и её частям. · обеспечивает разработку общих решений по системе и её частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решения задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению. 5.2. Разработка документации на АС и её части. (аналогично пункту 4.2) 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. · проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготовляемых серийно 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. · осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС. |
| 6. Рабочая документация. | 6.1. Разработка рабочей документации на систему и её части. · осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение 6.2. Разработка или адаптация программ. · проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101. |
| 7. Ввод в действие. | 7.1. Подготовка объекта автоматизации к вводу АС в действие.
|
| 8. Сопровождение АС | 8.1. Выполнение работ в соответствии с гарантийными обязательствами.
· осуществляются работы по устранению недостатков, выявленных при эксплуатации АС в течении установленных гарантийных сроков, внесению необходимых изменений в документацию по АС.
8.2. Послегарантийное обслуживание.
|
7. Особенности проектирования интегрированных ИС. Система управления информационными потоками как средство интеграции приложений ИС.
Интегрированная (корпоративная) информационная система (КИС) представляет собой объединение информационных систем в различных сферах деятельности одного или нескольких хозяйствующих субъектов.
Интегрированные (корпоративные) ИС — используются для автоматизации всех функций фирмы и охватывают весь цикл работ от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности.
Принятие управленческих решений и поиск верных направлений развития компании невозможны без обладания полной информацией о состоянии ключевых показателей деятельности предприятия. Обычно такие сведения поступают из внутренних учетных регистров и из внешних источников. Для оперативного использования данный объем информации должен быть консолидирован в единой системе управленческого учета. Эффективная система управления должна обеспечивать полную прозрачность деятельности всех подразделений предприятия на всех уровнях, автоматизировать бизнес-процессы любой сложности и отображать целостную картину.
Такой системой является информационная система класса ERP, внедрение которой позволяет получать оперативную и консолидированную информацию о деятельности подразделений, проводить планирование ресурсов, контролировать выполнение планов.
Проект внедрения ERP системы включает в себя следующие виды работ:
· анализ задач руководства компании, описание бизнес-процессов предприятия, определение объема и рамок проекта
· анализ технической базы проекта: наличие необходимой компьютерной техники и сетевого оборудования, формирование требований к аппаратному обеспечению с учетом перспектив развития системы
· разработка рекомендаций по построению или корректировке бизнес-процессов предприятия
· поставка аппаратного обеспечения, разработка и реализация сетевых решений
· установка, настройка и адаптация программного обеспечения
· конфигурация рабочих мест, обучение специалистов заказчика
· создание дополнительной функциональности системы по требованию заказчика
· сопровождение и сервисное обслуживание системы
· поставка лицензий
При внедрении ERP-системы общая архитектура решения формируется на основании полного пакета сформированных функциональных требований. Это имеет два важных следствия. Во-первых, в идеальном случае на момент запуска ERP-системы в эксплуатацию архитектура решения оптимальна, т.е. подобран наилучший из доступных вариантов реализации функциональных требований. Во-вторых, при проектировании решения функциональные требования согласованы и увязаны между собой, что ведет к полноте и внутренней непротиворечивости функционала.
При развитии системы возникает обратная ситуация. Во-первых, возникает необходимость навешивать новые требования на не предназначенную для этого архитектуру. Соответственно, любое требование должно анализироваться не только с точки зрения экономической целесообразности, но и технологической допустимости. Во-вторых, непосредственно при проектировании требуется учитывать влияние новых модификаций на существующий функционал, причем по мере разрастания системы эта задача становится все более актуальной.
Перечисленные выше психологические, экономические и технологические причины указывают на тот факт, что, несмотря на значительное сходство проектов по внедрению и проектов по развитию ERP-систем, у последних существует определенная специфика, требующая несколько иной расстановки акцентов в работе. Именно поэтому методология проектов развития ERP-систем заслуживают отдельного анализа и формализации.
8. Типовое проектирование ИС. Понятие типового элемента. Технологии параметрически-ориентированного и модельно-ориентированного проектирования.
типовое проектирование АИС предполагает создание системы из готовых типовых элементов.
При том основным требованием метода является возможность декомпозиции проектируемой АИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т. д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Под типовым проектным решением (ТПР) понимается представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию.
В качестве проектного решения может выступать реализация как отдельных компонентов ИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ИС в целом). Типовые проектные решения также называют тиражируемыми продуктами.
ТПР классифицируются по уровням декомпозиции системы.
Приняты следующие классы: •
· элементные ТПР. Типовое решение задачи или отдельного вида обеспечения задачи (информационного, программного, технического, технологического, математического, организационного);
· подсистемные ТПР. Решение является отдельной функционально полной подсистемой;
· объектные ^ ТПР. Типовой проект, включающий полный набор функциональных и обеспечивающих подсистем АИС (для вида деятельности, отрасли и т. п.).
ТПР должно содержать не только функциональные элементы (программные или аппаратные), но и документацию с детальным описанием состава компонентов и процедуры настройки в соответствии с задачами проекта.
Требования, выдвигаемые к типовым проектным решениям:
Спросить у Долгиной http://www.bgtu-ief.com/index.php?option=com_content&view=article&id=578:3-&catid=45:2011-11-26-08-13-08&Itemid=64
9. Методы и алгоритмы, инструментальные средства, используемые при оценке эффективности управления проектами ИС.
Важнейшей задачей является анализ экономической эффективности внедряемой системы. Ее своевременное решение дает возможность сравнивать различные варианты автоматизации и установить оптимальный вариант, оценить его влияние на изменение показателей деятельности организации.
Эффективность внедрения автоматизированной системы обуславливается действием ряда факторов организационного, информационного и экономического характера.
Организационный эффект проявляется в освобождение работников от рутинных операций по систематизации и группировке учетных данных, записей в реестры и другую документацию.
Информационный фактор эффективности выражается в повышение уровня информированности персонала.
Экономический фактор проявляется в том, что учетная информация, имеющая целью полное и своевременное отражение и состояние объекта и причин, влияющих на его развитие, в конечном счете направлена на улучшение использование ресурсов.
Опыт эксплуатации комплексов задач показал, что в процессе автоматизации достигается снижение трудоемкости отдельных операций, рост производительности и улучшений условий труда отдельных работников, повышение оперативности достоверности, включая подготовку отчетности при постоянно растущем объеме без увеличения численности персонала и т.д.
Итак, для обоснования экономической эффективности разработки и внедрения ИС необходимо:
· Произвести расчет экономии труда за счет внедрения ИС и рост производительности труда.
· Произвести расчет затрат на разработку необходим для обоснования экономической эффективности системы
· Оценить срок окупаемости проекта
Внедрение информационной системы сопряжено с капитальными вложениями как на приобретение техники, так и на разработку проекта, выполнение подготовительных работ и подготовку кадров.
Обобщенным критерием экономической эффективности является минимум затрат живого и овеществленного труда
Экономический эффект от внедрения вычислительной и организационной техники подразделяется на прямой и косвенный.
Под прямой экономической эффективностью понимают экономию материально-трудовых ресурсов и денежных средств, полученную в результате сокращения численности управленческого персонала, фонда заработной платы.
Срок окупаемости затрат вычисляется по формуле
Где:
З0 - затраты на техническое оборудование;
П0 - затраты на программное обеспечение.
С0 – Затраты до внедрения проекта
С1 – Затраты после внедрения проекта
J = С1/С0
10. Технологии проектирования распределенных информационных систем. Стандартные методы совместного доступа к базам и программам в сложных информационных системах.
Одной из важнейших сетевых технологий является распределенная обработка данных, позволяющая повысить эффективность удовлетворения информационной потребности пользователя и, обеспечить гибкость и оперативность принимаемых им решений.
Достоинствами распределенной обработки информации является:
При распределенной обработке производится работа с базой, т.е. представление данных, их обработка, работа с базой на логическом уровне осуществляется на компьютере клиента, а поддержание базы в актуальном состоянии - на сервере. При наличии распределенной базы данных база размещается на нескольких серверах. В настоящее время созданы базы данных по всем направлениям человеческой деятельности: экономической, финансовой, кредитной, статистической, научно-технической, маркетинга, патентной информации, электронной документации и т.д.
Создание распределенных баз данных (РБД) было вызвано двумя тенденциями обработки данных, с одной стороны - интеграцией, а с другой - децентрализацией.
Интеграция подразумевает централизованное управление и ведение баз данных. Децентрализация обеспечивает хранение данных в местах их возникновения или обработки, при этом скорость обработки повышается, стоимость снижается, увеличивается степень надежности системы.
Распределенная база данных - база данных, части которой размещены на отдельных ЭВМ, входящих в сеть. При этом некоторые данные могут дублироваться. При проектировании РБД осуществляется разбиение объекта на несколько частей (фрагментов) и размещение каждого фрагмента на один или несколько компьютеров.
Распределенная структура БД предполагает независимость конечных пользователей и программ от способа размещения информации на рабочих станциях сети, т.е. формулирование запросов к РБД производится аналогично запросам к централизованной БД. Совместный доступ к данным подразумевает модификацию одних и тех же данных несколькими пользователями не нарушая целостности РБД.
Интернет, видимо, является одной из самых известных в настоящее время распределенных систем.
Другим примером распределенной системы является Итранет. Под интранетом обычно понимают сообщество сетей, объединенных по какому – либо признаку (сети крупного предприятия, например).
Также примером распределенных систем могут служить Кластеры. Под кластером обычно понимают несколько вычислительных узлов, объединенных с помощью быстрой технологии передачи данных и с установленным специальным программным обеспечением.
Задачи, которые пытаются решать с применением технологии кластеризации две.
Первая связана с резервированием некоторых критических сервисов. Для этого применяются кластера, настроенные таким образом, что при сбое одного из узлов, входящих в кластер, сервисы, обслуживаемые этим узлом, автоматически загружаются на другом узле кластера. Такой подход позволяет существенно минимизировать время простоя системы, а для некоторых видов сервисов к тому же абсолютно прозрачен для клиентов. Кластеры, построенные по такому принципу, называются отказоустойчивыми кластерами. Вторая задача, которую решают путем кластеризации состоит в увеличении производительности системы. При таком подходе один сервис запускается на нескольких узлах кластера (реализация этого может быть различной – на каждом из узлов запускается копия сервиса, сервис запускается на одном узле, а часть его процедур размещается на других узлах, и т.д.), при этом количество одновременно обрабатываемых заданий увеличивается. Кластеры, решающие задачи такого вида называются высокопроизводительными.
11. Автоматизированное проектирование ИС с использованием CASE-технологий, конструкции и их реализация в современных программно-аппаратных средствах.
CASE-технология (Computer Aided Software Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
· интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
В состав интегрированного CASE-средства (или комплексf средств, поддерживающих полный ЖЦ ПО) входят следующие элементы:
- репозиторий, позволяет обеспечить сохранность вариантов проекта и его определенных компонентов, синхронизацию информации от разных разработчиков в процессе групповой разработки, проверка метаданных на полноту и непротиворечивость;
- средства разработки приложений, с использованием языков 4GL и генераторов кодов;
- средства тестирования;
- средства документирования;
- графические средства анализа и проектирования, которые дают возможность создавать и редактировать иерархически связанные диаграммы (DFD, ERдиаграмма и др.), создающие модели информационных систем;
- средства реинжиниринга.
- средства конфигурационного управления;
- средства управления проектом.
CASE-инструменты классифицируются по типам и категориям.
Классификация по типам отражает функциональную ориентацию средств на те или иные процессы жизненного цикла разработки программного обеспечения, и, в основном, совпадают с компонентным составом крупных интегрированных CASE-систем, и включает следующие типы:
· средства анализа — предназначены для построения и анализа предметной области (BPwin Logic Works).;
· средства проектирования баз данных (ERwin)
· средства разработки приложений (PowerBuilder);
· средства реинжиниринга процессов (изменение процессов (полное)) (Vantage Team Builder, ERwin).;
· средства планирования и управления проектом;
· средства тестирования;
· средства документирования.
Классификация по категориям определяет степень интегрированности по выполняемым функциям и включают — отдельные локальные средства, решающие небольшие автономные задачи, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла и полностью интегрированных средств, охватывающий весь жизненный цикл информационной системы и связанных общим репозиторием.
Типичными CASE-инструментами являются:
· инструменты управления конфигурацией;
· инструменты моделирования данных;
· инструменты анализа и проектирования;
· инструменты преобразования моделей;
· инструменты редактирования программного кода;
· инструменты рефакторинга кода (делать код проще для понимания, не меняя его поведения);
· генераторы кода;
· инструменты для построения UML-диаграмм.
Именно BPwin (All Fusion Process Modeler) и ERwin (All Fusion ERwin Data Modeler) на сегодняшний день являются наиболее популярными CASE- средствами, входящими в пакет AllFusion Modeling Suite – интегрированный комплекс CASE-средств, обеспечивающий все потребности компаний-разработчиковпрограммного обеспечения. Данный пакет служит для проектирования и анализа баз данных, бизнес-процессов и информационных систем и включает продукты:
BPwin, ERwin,AllFusion Data Model Validator (инструмент для проверки структуры баз данных и создаваемых в ERwin моделей), AllFusion Model Manager (среда для работы группы проектировщиков на ERwin и BPwin), AllFusion Component Modeler (моделирования компонентов программного обеспечения и генерации объектного кода приложений на основе созданных моделей).
Правильный выбор и грамотное применение CASE-средств при автоматизации процессов проектирования позволяет произвести оптимизацию информационных систем, значительно повысить их эффективность, снизить вероятность ошибок, а также сократить издержки.
Основные черты CASE-технологии:
· Назначение: автоматизация проектирования сложных информационных систем. Изначально CASE-средства были ориентированы на разработку ПО. Сейчас чаще всего под такими средствами подразумевают любые средства проектирования ИС и/или моделирования предметной области.
· CASE-средства охватывают все стадии ЖЦ ИС (анализ, проектирование, разработка, сопровождение).
· Не создают новых методологий, а повышают эффективность использования существующих – за счет автоматизации.
Цели использования CASE-технологии в индустриальном проектировании ИС:
· Улучшение качества разрабатываемой ИС за счет автоматического контроля и генерации отдельных элементов;
· Возможность повторного использования компонентов разработки;
· Повышение уровня адаптивности и качества сопровождения ИС;
· Использование методологии прототипного проектирования;
· Ускорение работы за счет автоматизированной генерации кода и автоматизированного документирования проекта;
· Возможность коллективной разработки ИС в режиме реального времени.
12. Содержание и особенности RAD-технологии прототипного создания приложений ИС.
На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и запросов пользователей (чему в значительной степени способствовал прогресс в области вычислительной техники, а также появление удобного графического интерфейса пользователя в системном программном обеспечении) потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения – инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем.
Методология создания информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений (Rapid Application Development, RAD). Данная методология охватывает все этапы жизненного цикла современных информационных систем.
Методология RAD – это комплекс специальных инструментальных средств, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
• небольшой команде программистов (обычно от 2 до 10 человек);
• тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок разработки (от 2 до 6 мес);
• итерационной модели разработки, основанной на тесном взаимодействии с заказчиком – по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком
Принципы RAD технологии:
· Инструментарий должен быть нацелен на минимизацию времени разработки.
· Создание прототипа для уточнения требований заказчика.
· Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
· Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
· Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
· Управление проектом должно минимизировать длительность цикла разработки.
При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:
· фаза анализа и планирования требований;
· фаза проектирования;
· фаза построения;
· фаза внедрения.
Несмотря на все свои достоинства, методология RAD тем не менее (как, впрочем, и любая другая методология) не может претендовать на универсальность. Ее применение наиболее эффективно при выполнении сравнительно небольших систем, разрабатываемых для вполне определенного предприятия.
При разработке же типовых систем, не являющихся законченным продуктом, а представляющих собой совокупность типовых элементов информационной системы, большое значение имеют такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Это связано с тем, что типовые системы обычно централизованно сопровождаются и могут быть адаптированы к различным программно-аппаратным платформам, системам управления базами данных, коммуникационным средствам, а также интегрироваться с существующими разработками. Поэтому для такого рода проектов необходим высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
13. Экспертные системы и системы поддержки принятия решения. Особенности, структура. Инструментальные средства реализации.
В последние годы доминирующим направлением в применении вычислительной техники в человеко-машинных системах стали «экспертные системы».
Экспертная система — это «воплощение в ЭВМ компоненты опыта эксперта, основанной на знаниях в такой форме, что машина может дать интеллектуальный совет или принять интеллектуальное решение относительно обрабатываемой функции. Желательно дополнительное свойство (которое многие считают главным) — способность системы по требованию объяснять ход своих рассуждений понятным пользователю образом. Обеспечиваются эти свойства в результате программирования, основанного на формальных правилах».
Экспертные системы в сущности моделируют поведение эксперта при принятии решения в конкретной предметной области. Исходя из этого необходимым условием является то, что должны быть известны люди, которые справляются с поставленными задачами. Затем их предметная деятельность изучается для определения необходимых знаний. База знаний представляет собой связанные между собой сведения, факты и правила, заранее структурированные и интерпретированные.
Типичная статическая ЭС состоит из следующих основных компонентов
База данных (рабочая память) предназначена для хранения исходных и промежуточных данных решаемой в текущий момент задачи.
База знаний (БЗ) в ЭС предназначена для хранения долгосрочных данных, описывающих рассматриваемую область (а не текущих данных), и правил, описывающих целесообразные преобразования данных этой области.
Решатель, используя исходные данные из рабочей памяти и знания из БЗ, формирует такую последовательность правил, которые, будучи примененными к исходным данным, приводят к решению задачи.
Компонент приобретения знаний автоматизирует процесс наполнения ЭС знаниями, осуществляемый пользователем-экспертом.
Объяснительный компонент объясняет, как система получила решение задачи (или почему она не получила решение) и какие знания она при этом использовала, что облегчает эксперту тестирование системы и повышает доверие пользователя к полученному результату.
Диалоговый компонент ориентирован на организацию дружественного общения с пользователем как в ходе решения задач, так и в процессе приобретения знаний и объяснения результатов работы.
В разработке ЭС участвуют представители следующих специальностей:
эксперт в проблемной области определяет знания (данные и правила), характеризующие проблемную область, обеспечивает полноту и правильность введенных в ЭС знаний;
инженер по знаниям - помогает эксперту выявить и структурировать знания, необходимые для работы ЭС; осуществляет выбор того ИС, которое наиболее подходит для данной проблемной области, и определяет способ представления знаний в этом ИС; выделяет и программирует (традиционными средствами) стандартные функции (типичные для данной проблемной области), которые будут использоваться в правилах, вводимых экспертом
программист по разработке инструментальных средств (ИС), разрабатывает ИС (если ИС разрабатывается заново), содержащее в пределе все основные компоненты ЭС, и осуществляет его сопряжение с той средой, в которой оно будет использовано
В режиме приобретения знаний общение с ЭС осуществляет эксперт. эксперт, используя компонент приобретения знаний, наполняет систему знаниями, которые позволяют ЭС в режиме решения самостоятельно решать задачи из проблемной области.
В режиме консультации общение с ЭС осуществляет конечный пользователь, которого интересует результат и (или) способ его получения. Необходимо отметить, что в зависимости от назначения ЭС пользователь может не быть специалистом в данной проблемной области (в этом случае он обращается к ЭС за результатом, не умея получить его сам), или быть специалистом (в этом случае пользователь может сам получить результат, но он обращается к ЭС с целью либо ускорить процесс получения результата, либо возложить на ЭС рутинную работу).
Особенностью ИТ поддержки принятия решений (ППР) является метод организации взаимодействия человека и компьютера. Выработка решения является основной целью этой технологии, происходит в результате итерационного процесса (рис.8.1.), в котором участвуют:
· 
система поддержки принятия решений в роли вычислительного звена и объекта управления;
· человек как управляющее звено, задающее входные данные и оценивающее полученный результат вычислений на компьютере.
Окончание итерационного процесса происходит по воле человека. Информационная система способна совместно с пользователем создавать новую информацию для принятия решений.
В состав системы поддержки принятия решений входят три главных компонента: база данных, база моделей и программная подсистема, которая состоит из системы управления базой данных (СУБД), системы управления базой моделей (СУБМ) и системы управления интерфейсом между пользователем и компьютером.
Наиболее широкой сферой практического применения СППР являются планирование и прогнозирование для различных видов управленческой деятельности.
Примеры: Project Expert, БЭСТ-Маркетинг
14. Методологии проектирования программного обеспечения. CASE-технологии, их содержание и классификации.
Вопрос 4 +
Существует 2 подхода к проектированию ИС:
Дата добавления: 2015-11-16; просмотров: 60 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Электронная почта 4 страница | | | Виды мер противодействия угрозам безопасности |