- •1.Термин информационная система (ис) используется как в широком, так и в узком смысле.
- •4. Классификация по архитектуре
- •1Ис оперативного (опреационного) уровня
- •2Ис для менеджеров среднего звена
- •3Стратегические ис
- •1Ис специалистов
- •2. Управленческие ис
- •7. Подсистемы кис
- •8. Подсистемы кис
- •Методы, используемые в условиях определенности;
- •Методы, используемые в условиях риска.
- •Основные определения системного подхода
- •Аспекты системного подхода
- •22. Деловое покупательское поведение: продажи на деловых (в2в) рынках
- •5 Или 10 (принципиально возможно создание Центра общественного доступа
- •25. Классификация математических моделей
- •Разновидности
- •29. Унифицированная система документации - система документации, созданная по единым правилам и требованиям, содержащая информацию, необходимую для управления в определенной сфере деятельности.
- •Концепция erp
- •Функции erp-систем
- •Особенности внедрения
- •Достоинства
- •Недостатки
- •33. Виды корпоративных информационных систем
- •34. Информационные технологии кис несколько отличаются от традиционных информационных технологий информационных систем меньшего масштаба или ограниченной функциональности.
- •Корпоративная информационная система как комплекс ис
- •Принципы организации хранилища
- •Дизайн хранилищ данных
- •Процессы работы с данными
- •41. Проекти́рование — процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния. Существует вариант проектирования - реконструкция.
- •Источники
- •42. Целью данного обзора является введение в особенности современных методов и средств проектирования информационных систем, основанных на использовании case-технологии.
- •Структура
- •Компоненты сапр
- •Выбор сапр
- •Периодика
- •Isicad — электронный журнал о сапр, plm и erp, выходящий с 2004 года.
- •47. Каноническое проектирование опирается на совокупность российских стандартов, позволяет упорядочить состав документации, разрабатываемой при проектировании ис, определяет состав этапов разработки.
- •48. Состав и содержание работ предпроектной стадии создания эис
- •2. Раздел описания "Назначение, цели создания системы" состоит из двух подразделов:
- •3. В разделе "Характеристика объекта автоматизации " приводятся:
- •3. Интерпретация, или («обратный») перевод полученных в результате окончательных формальных выражений и их истолкование на естественном языке.
- •1. Непротиворечивость формализованного представления изучаемого материала.
- •3. Адекватность: то, что в содержательно представленном материале является истинным, соответствует фактам, должно быть в формализованном представлении выводимым, доказуемым, вычислимым и т. Д.
- •Сущность системного анализа
- •Классификация проблем
- •Методы решения
- •Процедура принятия решений
- •Технорабочий проект
- •В рамках технорабочего проекта разрабатываются следующие документы:
- •56. Признак классификации — свойство или характеристика объекта классификации, по которому проводится классификация.
- •1. Невозможность внесения изменений в классификатор (добавление или удаление классификационных признаков, изменение последовательности их применения) после его создания.
- •2. Трудоемкий поиск информации по произвольному сочетанию признаков классификации.
- •58. Единая система классификации и кодирования
- •61. Документ может иметь несколько экранных форм, некоторые из которых назначаются в качестве основных
- •2139-Я базовая группа
- •3431-Я базовая группа
- •Электроника
- •Программное обеспечение
- •Декомпиляция с помощью декомпилятора — процесс создания исходного кода на некотором языке программирования высокого уровня. Базы данных
- •Военная промышленность
- •Анализ исходного кода
- •67. Этап 1. Постановка задачи.
- •Этап 2. Разработка модели.
- •Этап 3. Компьютерный эксперимент.
- •Этап 4. Анализ результатов моделирования.
- •4. Целый ряд задач назван оценкой. Сложность задач данного типа определяется сложностью оцениваемых объектов и неполнотой имеющейся информации.
- •Классификация
- •Типологии организационных структур
- •Основные параметры проектирования организационной структуры
- •Механизмы координации в организации
- •Визуализация организационной структуры
- •76. Техническая структура саз
- •6) По типу операционной системы (ос): работающие под управлением windows 3.11 и выше; работающие под управлением unix и работающие под управлением различных ос (windows, unix, os/2 и др.).
- •79. Сущность структурного подхода. Принципы, на которых базируется структурный подход. Метод sadt. Метод dfd.
- •Количество связей между отдельными подсистемами должно быть минимальным.
- •Связность отдельных частей внутри каждой подсистемы должна быть максимальной.
- •Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - dfd или sadt (idef0).
- •Диаграммы, моделирующие данные и их отношения (erd).
6) По типу операционной системы (ос): работающие под управлением windows 3.11 и выше; работающие под управлением unix и работающие под управлением различных ос (windows, unix, os/2 и др.).
В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями (такие, как редакторы диаграмм), так и дорогостоящие системы для больших ЭВМ.
Современные CASE-системы охватывают обширную область поддержки различных технологий проектирования и программирования: от простых средств анализа и документирования ИС до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС.
Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию баз данных и пользовательских интерфейсов.
Генерация интерфейсов с базами данных и возможность преобразования (конвертирования) между различными концептуальными схемами и моделями данных увеличивает мобильность прикладных систем при переходе в другие операционные среды. Генерация кода и (или) таблиц, описывающих интерфейс прикладной системы с базой данных, не только позволяет сократить время разработки, но и дает возможность отделить разработку приложений от ведения архива проектной документации.
Наиболее трудоемкими этапами разработки ЭИС являются этапы анализа и проектирования, поэтому CASE-системы, как правило, предназначены для автоматизации отслеживания качества принимаемых проектных решений и подготовки документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил.
Стратегия выбора CASE-систем для конкретного применения зависит как от целей и потребностей самого проекта, так и от квалификации вовлеченных в процесс проектирования специалистов. В большинстве случаев одно средство не может обеспечить все потребности проекта. Разработчики, как правило, применяют набор средств. Например, одно средство наилучшим образом подходит для анализа, а другое - для проектирования систем. В общем случае при выборе CASE-системы необходимо учитывать следующие аспекты.
∙ Наличие базы проектных данных, архива или словаря. СУБД и словари данных обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной информации между различными этапами проекта и выполняемыми операциями.
∙ Интерфейсы с другими CASE-системами. В процессе проектирования ЭИС могут использоваться различные методологии, поэтому важно, чтобы используемые CASE-системы предоставляли возможности для эффективного использования нескольких методов. При этом должна быть обеспечена терминологическая совместимость различных методологий.
∙ Возможности экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования и кодирования для одной ЭИС, могут быть использованы для проектирования другой системы. Повторное проектирование и кодирование могут быть обеспечены при помощи средств экспорта/импорта спецификаций в различные CASE-системы.
Многопользовательский резким. Развитые CASE-системы должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект.
Открытая архитектура. Открытая к доступу проектировщиков информация об используемых форматах файлов и интерфейсах должна позволять безболезненно переходить от одной CASE-системы к другой.
Расширение новыми методологиями. Как и любое программное средство, CASE-система должна обладать возможностью совершенствоваться с учетом появления новых требований или новых предметных областей.
Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графическом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений.
∙ Обеспечение качества проектной документации. Это требование относится к возможностям CASE-системы анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной документации, находящейся в архиве или словаре.
Автоматическая генерация отчетов о проектных решения
Решения (спецификации), созданные в процессе проектирования, служат источником документирования системы. Час то возникает потребность получения твердой копии спецификаций в текстовой или графической форме.
Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД.
Планирование и управление проектом. Использование CASE -систем не исключает потребности в эффективном управлении проектом. Многие развитые CASE-системы имеют в своем составе средства планирования и управления проектом. Спецификации, которые используются этими средствами, представляют собой опорные точки управления, позволяющие определять сроки разработки.