
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •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) Понятие требования. Классификация требований. Свойства требований
Iso / iec 15288 - Инженерные системы стандартных охватывающих процессы и этапы жизненного цикла.
Этот стандарт делит процессы на четыре категории:
процессы соглашения;
процессы предприятия;
процессы проекта;
технические процессы.
К процессам соглашения относятся процесс приобретения, используемый организациями для приобретения продукции или получения услуг, и процесс поставки, используемый для поставок продукции или оказания услуг.
Процессы предприятия включают процесс управления средой предприятия, процесс управления инвестициями, процесс управления процессами жизненного цикла системы, процесс управления ресурсами, процесс управления качеством.
К процессам проекта относятся процесс планирования проекта, процесс оценки проекта, процесс контроля проекта, процесс принятия решений, процесс управления рисками, процесс управления конфигурацией, процесс управления информацией.
И, наконец, технические процессы включают процесс определения требований правообладателей, процесс анализа требований, процесс проектирования архитектуры, процесс реализации элементов системы, процесс комплексирования, процесс верификации, процесс передачи, процесс валидации, процесс функционирования, процесс технического обслуживания, процесс изъятия и списания.
Пример стадии жизненного цикла, описанного в документе, являются: концепции, разработки, производства, использования, поддержки и выходом из эксплуатации.
Определение требований заинтересованных сторон процесса (п. 6.4.1)
Анализ требований процесса (п. 6.4.2)
Архитектурный дизайн (п. 6.4.3)
Процесс реализации (п. 6.4.4)
Интеграция процессов (п. 6.4.5)
Процесс проверки (п. 6.4.6)
Переходного процесса (п. 6.4.7)
Процесс проверки (п. 6.4.8)
Процесс эксплуатации (п. 6.4.9)
Техническое обслуживание процесса (п. 6.4.10)
Удаление процесса (п. 6.4.11)
Понятие требования. Классификация требований. Свойства требований.
30) Понятие требования. Классификация требований. Свойства требований
ИС представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации предназначенной для выполнения функций управления.
К ИС предъявляются следующие требования:
Полнота информации для реализации функций управления.
Своевременность предоставления информации.
Обеспечение необходимой степени достоверности информации в зависимости от уровня управления.
Экономичность обработки информации – это значит, что затраты на обработку данных не должны превышать получаемый эффект.
Адаптивность к изменениям информационных требований пользователей (возможность вносить изменения).
Внедрение ИС проводится с целью повышения эффективности производственно-хозяйственной деятельности фирмы за счет принципиально новых методов управления, основанных на моделировании деятельности специалистов фирмы при принятии решений (методы искусственного интеллекта, экспертные системы и т.п.) использование современных средств телекоммуникации (e-mail, теле конференции) и вычислительных систем, а также сокращение времени выполнения типовых операций по обработке различного рода документов.
Требования – это исходные данные, на основании которых проектируются и создаются ИС. Требование – условие или особенность, которой должна удовлетворять ИС.
Требования к системе: - требования к структуре системы; - требования к режимам функционирования системы; - требования к персоналу; - требования к надежности; - требования к безопасности; - требования к эргономике и технической эстетике; - требования к транспортабельности (для подвижных АС); - требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; - требования к защите информации от несанкционированного доступа; - требования к сохранности информации при авариях; - требования к защите от влияния внешних воздействий; - требования к патентной чистоте; - треб-ия к стандартизации и унификации.
Св-ва требований: 1. Полнота. 2. Ясность (краткость, простота, точность, недвусмысленность). 3. Корректность (согласованность, непротиворечивость). 4. Верифицируемость (тестируемость, возможность проверки). 5. Необходимость и полезность при эксплуатации. 6. Осуществимость (выполнимость, реализуемость). 7. Элементарность и трассируемость (прослеживаемость). 8. Независимость (от других требований). 9. Независ-ть от реал-ии (абстрактность). 10. Постоянство (отсутствие конфликтов).
Полнота требования означает, что текст требования не требует дополнительной детализации, то есть, в нем предусмотрены все необходимые нюансы, особенности и детали данного требования. Ясность – недвусмысленность, опред-ть, однозначность спецификаций. Требование обладает свойством ясности, если оно сходным образом воспринимается всеми заинтересованными лицами.Корректность – согласованность, непротиворечивость. Требования не должны противоречить требованиям своего уровня иерархии и требованиям "родительского" уровня.
Если требование содержит факты, эти факты должны быть достоверны.Верифицируемость – пригодность к проверке. Тестеры должны иметь возможность проверить, было ли требование реализовано корректно.Необходимым считается требование, невыполнение которого угрожает работоспособности или эффективности ИС.
В требовании нет необходимости, если:Полезность при эксплуатации – требование, выполнение которого повышает эргономические качества продукта. Осуществимость (выполнимость) – треб-ие должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы.Требование считается элементарным, если оно содержит только один трассируемый элемент, который дает возможность отследить связь между ним и другими элементами информационной системы.Требование является независимым, если для его понимания не нужно знать другие требования.Треб-ия должны быть независ-ми от реал-ии.Требование считается постоянным, если не сущ-ет конфликтов между ним и др. треб-ми.Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации:Косвенный конфликт возникает, когда требования описывают разную функциональность, но выполнить оба этих требования одновременно невозможно.