- •230100.62 (09.03.01) «Информатика и вычислительная техника» профиля подготовки «Программное обеспечение вычислительной техники и
- •231000.62 (09.03.04) «Программная инженерия» профиля подготовки «Разработка программно-информационных систем»
- •1) 230100.62 (09.03.01) «Информатика и вычислительная техника»:
- •2) 231000.62 (09.03.04) «Программная инженерия»:
- •Лекция №1. Основные понятия и определения
- •Лекция №2. Прикладной системный анализ при разработке по. Принципы структурного анализа. Процедура требований.
- •2.1 Проблема сложности ис
- •2.2 Основные понятия структурного анализа
- •2.3 Принципы структурного анализа
- •2.4 Группы средств структурного анализа и их взаимоотношения
- •2.5 Краткий список структурных методологий по группам средств моделирования
- •Лекция №3. Моделирование функций по. Нотация idef0. Case-средство bpWin
- •3.1 Диаграммы idef0
- •3.2 Виды связей в idef0
- •3.3 Диаграмма дерева узлов
- •3.4 Case-средство bpWin
- •Лекция №4. Описание динамики системы. Нотация idef3
- •4.1 Основные символы idef3
- •4.2 Виды связей в idef3
- •4.3 Пример диаграммы idef3
- •Лекция №5. Постановка требований к данным. Словари данных. Моделирование данных в нотации idef1x. Case-средство erWin
- •5.1 Словарь данных
- •5.2 Определение структуры данных для информационных потоков
- •5.3 Моделирование данных в нотации idef1x
- •5.3.1 Базовые понятия erd
- •5.3.2 Виды сущностей в idef1x
- •5.3.3 Виды связей в idef1x
- •Лекция №6. Стандарт онтологического исследования idef5
- •6.1 Основные принципы онтологического анализа
- •6.2 Концепции idef5
- •6.3 Язык описания онтологий в idef5
- •6.4 Виды схем и диаграмм idef5
- •Лекция №7. Постановка требований к интерфейсу по. Понятие Usability.
- •7.1 Эргономические цели и показатели качества программного продукта
- •7.2 Проблемы, возникающие на этапе разработки прототипа gui и варианты их решения
- •7.3 Принципы реализации пользовательского интерфейса
- •Лекция №8. Управление требованиями к программному продукту. Case-средство Requisite Pro.
- •8.1 Нормативная основа
- •8.2 Основные положения
- •8.2.1 Цели управления требованиями
- •8.2.2 Участники управления требованиями
- •8.2.3 Политика в области управления требованиями
- •8.3 Обеспечение процессов управления требований
- •8.3.1 Распределение ответственности
- •8.4 Действия по управлению требованиями
- •8.4.1 Анализ требований
- •8.4.2 Разработка материалов проекта на основе требований
- •8.4.3 Контроль изменений требований
- •8.5 Измерения
- •8.6.2 Контроль со стороны руководителя проекта
- •8.6.3 Контроль со стороны гок
- •8.7 Стандарт оформления требований
- •8.7.1 Шаблон для разработки требований
- •8.7.2 Правила оформления требований
- •8.7.3 Структурирование требований
- •8.8 Показатели качества требований
- •8.9 Начало работы с RequisitePro
- •Лекция №9. Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. Case-средства Rational Functional Tester, Rational Performance Tester.
- •9.1 Дестабилизирующие факторы и методы обеспечения высокого качества функционирования по
- •9.2 Использование среды автоматизированного тестирования Platinum testBytes
- •9.3 Методы обеспечения качества и надежности программных средств
- •9.4 Использование case для повышения качества по
- •9.5 Влияние стандартов открытых систем на качество по
- •9.6 Повышение качества по путем тестирования
- •9.6.1 Основные особенности процесса тестирования по
- •9.6.2 Организационные особенности тестирования
- •9.6.3 Сертификация по
- •9.6.4 Организация и планирование тестирования для обеспечения качества по
- •9.7 Важнейшие разделы iso 9003
- •Документирование системы качества
- •Корректирующие действия
- •Лекция №10. Стандарты, регламентирующие разработку по
- •10.1 Стандарт iso 12207:1995
- •10.3 Серия стандартов гост 34-ххх «Информационная технология»
- •Заключение
- •Библиографический список
- •Приложения Приложение а. Перечень ключевых слов
- •660049, Г. Красноярск, пр. Мира, 82
5.2 Определение структуры данных для информационных потоков
Для каждого потока данных возможно указать набор сущностей из соответствующего словаря и выделить в данных сущностях те атрибуты, которые будут использоваться в данном потоке. Таким образом, однозначно идентифицируется структура данных, передающихся по потоку.
BPWin позволяет отслеживать связь между потоками данных и элементами словаря сущностей и атрибутов, включая иерархию потоков при их слиянии и расщеплении. Если какие-либо элементы словаря сущностей и атрибутов подключены к ветвям расщепленного потока, то эти же символы данных могут быть автоматически подключены к общему потоку.
Приведем примеры словаря сущностей и атрибутов для банковской задачи, рассмотренной в предыдущей лекции:
Кредитная карта:
Пароль.
Лимит денег.
Детали клиента.
Протокол обслуживания:
Обработанная документация.
Денежная сумма.
Данные по истории запроса.
5.3 Моделирование данных в нотации idef1x
Цель моделирования данных состоит в обеспечении разработчика концептуальной схемой базы данных в форме одной или нескольких моделей, которые могут быть легко отображены на требуемую систему баз данных.
Диаграммы «сущность-связь» (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними.
Данный подход введен П.Ченом и усовершенствован Р. Баркером.
5.3.1 Базовые понятия erd
Сущность (Entity) – реальный либо воображаемый объект, имеющий существенное значение для предметной области.
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного вида сущности.
Каждая сущность должна обладать следующими свойствами:
Иметь уникальное имя. К одному и тому же имени должна всегда применяться одна интерпретация; интерпретация не может применяться к различным именам, если только они не являются псевдонимами.
Обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются ею через связь.
Обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для предметной области.
Атрибут (Attribute) – любая характеристика сущности, значимая для предметной области и предназначенная для квалификации, идентификации, количественной характеристики или выражения состояния сущности. Атрибут представляет собой тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест, событий и т.п.). Экземпляр атрибута определяется типом характеристики и ее значением (значением атрибута). Экземпляр атрибута – определенная характеристика отдельного элемента множества. В ERD атрибуты ассоциируются с конкретными сущностями. Каждый экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута[27].