- •Методы проведения обследования.
- •Понятие информационного процесса.
- •Понятие и классификация case-средств. Особенности case-средств.
- •Методы сбора данных при обследовании.
- •Измерение количества информации.
- •Особенности case-средства Erwin. Области применения, среда.
- •Основные характеристики
- •Стандарты графического описания бп.
- •Критерии ценности информации и минимума эвристик.
- •Современные методы моделирования ис. Особенности, области применения.
- •Анализ модели бизнес-процесса.
- •Аксиома теории управления.
- •Основные принципы структурной методологии проектирования.
- •Сущность структурного подхода
- •Методы проектирования нового бизнес-процесса.
- •Быстрый анализ
- •Бенчмаркинг
- •Перепроектирование
- •Реинжиниринг
- •Принцип необходимого разнообразия Эшби.
- •Понятие методологии, методов и технологии моделирования ис. Требования, предъявляемые к современным технологиям моделирования ис. Визуальное моделирование
- •Методы структурного анализа и проектирования по
- •Методы объектно-ориентированного анализа и проектирования по. Язык uml
- •Внедрение нового бизнес-процесса.
- •Документарное оформление нового бизнес-процесса.
- •1 1 Имеет
- •Проблемы при внедрении новых бизнес-процессов.
- •Понятие функционально-стоимостного анализа.
- •Понятие сложной системы. Неоднородные связи в системе.
- •Понятие связи и типы связей. Степень связи. Типы связей и отражение связей в среде Erwin. Окно «Свойство связи».
- •Практический подход к проведению фса.
- •Система сбалансированных показателей.
- •Реинжиниринг и реструктуризация предприятия.
- •Существо модели
- •Обратный инжиниринг.
- •Сферы применения обратной разработки Электроника
- •Программное обеспечение
- •Базы данных
- •Промышленность
- •Военная промышленность
- •Для анализа исходного кода
- •Нежелательные элементы при проведении анализа на этапе логического проектирования.
- •Условия успешного проведения инжиниринга.
- •Принцип Парето. Множество Парето.
- •Понятие ограничения целостности. Типы требований по ограничению целостности. Стратегии при ограничении ссылочной целостности. Назначение стратегии в среде Erwin.
- •Типичные ошибки при проведении реинжиниринга.
- •Этапы проектирования базы данных. Цель и виды работ на этапе концептуального проектирования базы данных.
- •Концепция врм.
- •Критерии оценки решений Аналитики Gartner выделяют как основные следующие критерии оценки bpm-решений:
- •Цели внедрения bpm Концепция предполагает внедрение bpm-решения для достижения следующих целей:
- •Основные участники управления бизнес-процессами
- •Оценивание сложный систем в условиях определенности.
- •Этапы проектирования базы данных. Цель и виды работ на этапе логического проектирования базы данных.
- •Цели внедрения концепции врм.
- •Критерии оценки решений
- •Цели внедрения bpm
- •Этапы проектирования базы данных. Цель и виды работ на этапе физического проектирования базы данных. Этапы проектирования данных
Основные принципы структурной методологии проектирования.
Методы и инструментальные средства проектирования (CASE-средства) являются основой проекта любой ИС. Метод проектирования представляет собой организованную совокупность процессов создания ряда моделей, которые описывают различные аспекты разрабатываемой системы с использованием четко определенной нотации.
В качестве концепций и теоретических основ метода проектирования могут выступать структурный или объектно-ориентированный подход. В качестве нотаций, используемых для построения моделей статистической структуры и динамики поведения проектируемой системы обычно используются графические диаграммы, поскольку они наиболее наглядны и просты в восприятии (диаграммы потоков данных и диаграммы «сущность-связь» для структурного подхода, диаграммы вариантов использования, диаграммы классов и др. – для объектно-ориентированного подхода).
Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла ИС.
Технология проектирования ИС определяется как совокупность технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ИС. Современная технология проектирования должна обеспечивать:
поддержку всех процессов жизненного цикла;
гарантированное достижение целей разработки ИС в рамках установленного бюджета, с заданным качеством и в установленное время;
возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3-7 человек), - с последующей интеграцией составных частей;
минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем.
Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков. При этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта внедрение ИС зачастую идет последовательно по отдельным подсистемам;
независимость получаемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования);
поддержка комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Сущность структурного подхода
Главной проблемой, которую приходится решать при создании больших и сложных систем любой природы, в том числе и ИС является проблема сложности Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т. д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как "разделяй и властвуй" (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем. Понятие "правильная" по отношению к декомпозиции означает следующее:
количество связей между отдельными подсистемами должно быть минимальным;
связность отдельных частей внутри каждой подсистемы должна быть максимальной.
Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:
каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Инкапсуляция позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
На сегодняшний день в программной инженерии существуют два основных подхода к разработке ИС, принципиальное различие между которыми обусловлено разными способами декомпозиции систем. Первый подход называют функционально-модульным или структурным. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.
Итак, сущность структурного подхода к разработке ИС заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:
принцип "разделяй и властвуй;
принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются:
принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
принцип непротиворечивости — обоснованность и согласованность элементов системы;
принцип структурирования данных — данные должны быть структурированы и иерархически организованы.
В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются:
· DFD (Data Flow Diagrams) — диаграммы потоков данных;
· SADT (Structured Analysis and Design Technique — метод структурного анализа и проектирования) — модели и соответствующие функциональные диаграммы;
· ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".
Диаграммы потоков данных и диаграммы "сущность-связь" — наиболее часто используемые в CASE-средствах виды моделей.
Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ИС.
На стадии формирования требований к ИС SADT-модели и DFD используются для построения модели "как есть" и модели "как должно быть", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ИС). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).
На стадии проектирования DFD используются для описания структуры проектируемой системы, при этом они могут уточняться, расширяться и дополняться новыми конструкциями. Аналогично ERD уточняются и дополняются новыми конструкциями, описывающими представление данных на логическом уровне, пригодном для последующей генерации схемы базы данных. Данные модели могут дополняться диаграммами, отражающими системную архитектуру, структурные схемы программ, иерархию экранных форм и меню и др.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли система существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от сложности системы и необходимой полноты ее описания.
БИЛЕТ №_____8___
