
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •Bcnf - нормальная форма Бойса-Кодда вводит дополнительное ограничение в сравнении с 3нф.
- •Анализ информационной связности действий и систем.
- •Анализ функциональной связности данных и систем.
- •Анализ производительности ис
- •Психологические аспекты принятия решений в процессе проектирования.
- •Организационные формы управления проектами
- •Архитектура корпоративных информационных систем (кис)
- •Mrp/erp системы. Современная структура модели mrp/erp
- •Тестирование. Методы тестирования. Категории тестов и оценок системы. Планирование тестирования и оценки системы.
- •Тестирование программного обеспечения
- •Уровни тестирования
- •Верификация и валидация – цели и задачи. V – модель как основа организации процесса верификации.
- •Основные принципы
- •Достоинства
- •Ограничения
- •Аутсорсинг и определение поставщиков.
- •Язык uml (Unificed Moeling Language). Основные модели uml (схема). Виды диаграмм.
- •Диаграмма вариантов использования. Виды отношений между актерами и вариантами использования. Отношения ассоциации, расширения, включения, обобщения
- •Диаграмма классов
- •Диаграмма состояний
- •Диаграмма деятельности. Диаграммы взаимодействия
- •Диаграмма последовательности. Диаграмма кооперации
- •Диаграмма компонентов. Диаграмма развертывания
- •23) Языки и среды моделирования архитектуры предприятия. Языки моделирования предприятий. Idеf, dfd- технология, aris, bpml.
- •24) Структурный (функциональный) и процессный подходы к разработке информационных систем
- •25) Управление требованиями к информационной системе. ГосТы и методология rup.
- •Принципы
- •Жизненный цикл разработки
- •1. Начало (Inception)
- •2. Уточнение (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •Автоматизированное создание документов серии гост 34 и 19 с помощью инструментальных средств фирмы ibm Rational
- •26) Моделирование потоков данных. Основные компоненты диаграмм
- •1. Внешние сущности
- •2. Системы и подсистемы
- •3. Процессы
- •4. Накопители данных
- •5. Потоки данных
- •6. Построение иерархии диаграмм потоков данных
- •27) Диаграмма «сущность–связь» (erd). Сущность (Entity). Связь (Relationship). Атрибут. Виды идентификации. Подтипы и супертипы
- •28) Стадии разработки информационных систем. Модели представления для описания проектных решений. Уровни детализации, регламентирующие методики проектирования. Этапы создания информационных систем
- •29) Модели жизненного цикла программного продукта. Виды и особенности. Процессы жизненного цикла систем по iso 15288:2002
- •V модель (разработка через тестирование)
- •Iso / iec 15288 - Инженерные системы стандартных охватывающих процессы и этапы жизненного цикла.
- •30) Понятие требования. Классификация требований. Свойства требований
Анализ производительности ис
Актуальность исследования. Одной из ключевых характеристик современного программного обеспечения (ПО) является производительность. Низкая производительность может обуславливать неэффективность работы пользователей и, как следствие, негативную реакцию на программный продукт, потерю прибыли и клиентуры, доли рынка; перерасход средств вследствие затрат на модификации и перепроектирование. Более того, переработка кода с целью увеличения производительности с большой вероятностью может разрушить первоначальную структуру системы, сводя на нет преимущества от использования объектно-ориентированного подхода. Наконец, маловероятно, что переработанный код сможет довести производительность системы до уровня, на котором она могла бы быть в случае изначального проектирования с учетом вопроса производительности. В худшем случае, будет невозможно достичь поставленных целей простой модификацией исходного кода системы, что обусловит необходимость полного перепроектирования или остановки проекта. Очевидно, что большинство серьезных проблем с производительностью ПО вызвано недооценкой этого вопроса на ранних стадиях процесса разработки, в частности на этапе проектирования. Низкая производительность чаще всего обусловлена недостатками проектирования, а не реализации. Однако в объектно-ориентированном сообществе распространена тенденция откладывать рассмотрение вопроса производительности до момента, когда система реализована.
Слабым местом существующих решений по анализу производительности программного обеспечения является необходимость создания и поддержки отдельной модели производительности в дополнение к уже существующим моделям (таким как модель проектирования, модель данных и т.д.). Кроме того, большинство подобных подходов рассчитано на непосредственное использование специализированных математических моделей, что повышает требование к подготовке участников команды разработки и, тем самым, снижает эффективность внедрения.
Таким образом, несмотря на активные разработки в данной области, проблема создания эффективного подхода к анализу производительности в процессе разработки ПО до конца не решена. Для того, чтобы было возможно учитывать вопросы производительности в течение всего процесса разработки, начиная с ранних стадий, должна быть создана технология, позволяющая, не нарушая сложившийся подход к проектированию ПО, оценивать те или иные архитектурные решения с точки зрения производительности. При этом должны быть минимизированы издержки использования подобной технологии, для чего она должна опираться в основном на уже существующие артефакты проектирования и не требовать математической подготовки от участников коллектива разработчиков. Под артефактами проектирования понимаются данные моделирования, управления проектами, системной конфигурации, т. е. компоненты информационных систем, которые описывают информационные системы. Чаще всего используется объектно-ориентированный подход, поэтому стоит познакомиться с ним поближе.
Этот подход не даётся легко, поскольку объектно-ориентированная разработка требует хорошего знания объектной технологии. Без глубокого понимания тонкостей объектной технологии разработчик не сможет правильно применять язык UML в качестве универсального и привычного средства моделирования. Основная трудность изучения объектной технологии связана с отсутствием очевидной отправной точки и ясного направления исследования. Это не хорошо известные нам подходы к изучению систем «сверху-вниз» или «снизу-вверх». По существу, рассматриваемый подход представляет собой что-то неподобное «всё время со средины». Независимо от того, насколько мы продвинулись в процесс изучения, кажется, что мы всегда находимся посередине этого процесса (поскольку всё время возникают новые вопросы). Можно считать, что в процессе изучения достигнут первый успех, когда читатель осознаёт глубинный смысл того факта, что в объектно-ориентированной системе «всё есть объект»
При этом одновременно используются два способа подачи материала. Во-первых, здесь объясняются основы объектной технологии. Во-вторых, проводится «обучение на примерах» и даётся наставление по моделированию анализа с использованием приложения Internet-магазин, относящегося к известной прикладной области – «Электронная торговля». Основы объектной технологии Для объяснения сути объектной ориентации ИС воспользуемся аналогией с объектами реального мира. Окружающий мир состоит из объектов, пребывающих в состоянии, которое определяется текущими значениями атрибутов объекта.