- •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
2.5 Краткий список структурных методологий по группам средств моделирования
Не описывая пока детально каждую из методологий структурного моделирования систем приведем, тем не менее, их список и укажем их место в группах средств. В качестве примера рассмотрим 3 больших группы нотаций – IDEF и UML.
Семейство методологий IDEF создавалось в рамках программы автоматизации производства – ICAM (Integrated Computer-Aided Manufacturing), предложенной ВВС США. Методологии этого семейства предназначены для решения задач моделирования сложных систем, позволяя проводить формальное описание и анализ моделей широкого спектра сложных систем в различных разрезах. Охват и глубина проработки моделей определяется аналитиками, что позволяет избегать перегрузки создаваемых моделей избыточными подробностями. Поскольку при разработке моделей семейства ставилась задача эффективного обмена информацией между всеми участниками программы ICAM, оно помимо названия Icam DEFinition, получило второе название – Integrated DEFinition. В настоящий момент в состав IDEF входит 7 стандартизованных методологий и 5 востребованных, начатых разработкой, но пока не полностью доработанных.
Не рассматривая весь список методологий IDEF остановимся на трех.
IDEF0 (Function Modeling) – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов;
IDEF1x (Data Modeling) – методология моделирования баз данных на основе модели «сущность-связь»;
IDEF3 (Process Description Capture) – дискретно-событийная методология документирования процессов, происходящих в системе (например, на предприятии), описывающая сценарий и последовательность выполнения операций для каждого процесса.
В рамках общего подхода IDEF эти методологии образуют интегрированную группу (рисунок 5). Функциональное описание системы (включая поддержание иерархической декомпозиции описания функциональных подсистем) обеспечивает методология IDEF0, описание динамики выполнения функций на нижних уровнях декомпозиции – дискретно-событийная модель IDEF3, а семантические модели потоков материалов и информации строятся при помощи методологии IDEF1x.
UML (Unified Modeling Language – унифицированный язык моделирования) – язык графических описаний систем. Наиболее широкое применение UML получил в разработке программного обеспечения. Вместе с тем, применение UML не ограничивается разработкой программного обеспечения, он является языком широкого профиля, открытый стандартом графического описания абстрактных моделей систем.
В действующей на момент написания данной работы версии языка – UML 2.2. – содержится 15 нотаций. Они (несмотря на постоянно делающийся упор на различие между объектными и структурными методологиями) также делятся на три группы – структурные диаграммы (Structure Diagrams), диаграммы поведения (Behavior Diagrams) и выделяющиеся в этой группе диаграммы взаимодействия (Interaction Diagrams).
Рисунок 5 – Комбинация нотаций IDEF в рамках модели системы
Таким образом, и здесь можно говорить об описании системы в виде трех аспектов – функционального, семантического и динамического. Аналогично предыдущим двум методологиям проиллюстрируем, как сочетание нотаций UML, принадлежащих к трем аспектам моделирования, позволяют описывать системы. Для этого рассмотрим три нотации:
Use case diagram – диаграмма прецедентов, диаграмма вариантов использования – диаграмма, на которой отражены отношения, существующие между актёрами (участниками деятельности) и вариантами использования (функциями системы);
Class diagram – диаграмма классов, представляет собой статическую структурную диаграмму, описывающую состав классов системы, их свойства и возможные действия (методы), а также демонстрирует отношения между классами;
Sequence diagram – диаграмма последовательности, демонстрирующая взаимодействие объектов, последовательность их участия в процессе и содержащая взаимодействующие объекты и сообщения, которыми они обмениваются.
Как и в IDEF, эти нотации образуют набор, позволяющий создавать интегрированные модели сложных систем (рисунок 6).
Рисунок 6 – Комбинация нотаций UML при описании системы
Таким образом, какую бы методологию структурного описания систем мы не рассматривали, всюду встречаемся с тем, что они построены на отражении трех основных аспектов моделирования – функциональные описания, семантические описания и динамические модели.
Перечисленные средства дают полное описание системы независимо от того, является ли она существующей или разрабатываемой с нуля. Таким образом строится логическая функциональная спецификация - подробное описание того, что должна делать система, освобожденное насколько это возможно от рассмотрения путей реализации. Это дает проектировщику четкое представление о конечных результатах, которые следует достигать.
На протяжении первых трех фаз (стадия разработки) закладываются характеристики качества будущего ПИ, проявляющиеся на стадии его эксплуатации. Этот факт можно проиллюстрировать таблицей 1, отражающей распределение трудозатрат по этапам ЖЦ ПО.
Таблица 1 - Распределение трудозатрат по этапам ЖЦ ПО
Способ разработки |
Анализ |
Проекти-рование |
Коди-рование |
Тести-рование |
Традиционная разработка |
20% |
15% |
20% |
45% |
Использование структурных методологий |
30% |
30% |
15% |
25% |
Использование CASE-технологий |
40% |
40% |
5% |
15% |
Вопросы
1) Предмет системного анализа
2) Проблема сложности ИС. Структурный анализ
3) Группы средств моделирования систем. Их взаимоотношения
Дополнительная информация
1)http://victor-safronov.narod.ru/systems-analysis/lectures/zhivickaya/03.html
2) http://dis.ru/library/detail.php?ID=23311
3) http://www.twirpx.com/files/informatics/sa/
4) http://examen.od.ua/upravlen/page107.html
5) http://www.ligis.ru/psylib/090417/books/marko01/txt01.htm
