Информационные технологии
Сложность ПО
Сложные системы
Сложные системы
Сложные системы
Сложные системы
Сложные системы
Модели качества процессов
Модели качества процессов
Модели качества процессов
Модели качества процессов
Модели зрелости СММ
Модели зрелости СММ
Модели зрелости СММ
Модели качества процессов
Диаграммные нотации
Графические диаграммы
Диаграммные нотации
Диаграммные нотации
Диаграммные нотации
Функциональная модель
Функциональная модель
Функциональная модель
Графические диаграммы
Графические диаграммы
Графические диаграммы
IDEF0 Семантика
IDEF0
IDEF0
IDEF0 Блок
IDEF0 Блок
IDEF0 Стрелки
IDEF0 Семантика
IDEF0 Семантика
Контекстная диаграмма
Дочерняя диаграмма
Графические диаграммы
Ветвление стрелок
Ветвление стрелок
Ветвление стрелок
Ветвление стрелок
Отношение в блоках
Отношение в блоках
Отношение в блоках
Отношение в блоках
Отношение в блоках
Отношение в блоках
Отношение в блоках
Отношение в блоках
551.50K
Category: informaticsinformatics

Информационные технологии

1. Информационные технологии

2. Сложность ПО

Сложность вызывается четырьмя основными
причинами:
сложностью реальной предметной области, из
которой исходит заказ на разработку;
трудностью управления процессом разработки;
необходимостью обеспечить достаточную гибкость
программы;
неудовлетворительными способами описания
поведения больших дискретных систем

3. Сложные системы

Признак 1
Сложные системы часто являются
иерархическими и состоят из
взаимозависимых подсистем,
которые в свою очередь также
могут быть разделены на
подсистемы, и т.д., вплоть до
самого низкого уровням."

4. Сложные системы

Признак 2
Выбор, какие компоненты в данной
системе считаются
элементарными, относительно
произволен и в большой степени
оставляется на усмотрение
исследователя.

5. Сложные системы

Признак 3
Внутрикомпонентная связь обычно
сильнее, чем связь между
компонентами. Это
обстоятельство позволяет
отделять "высокочастотные"
взаимодействия внутри
компонентов от "низкочастотной"
динамики взаимодействия между
компонентами

6. Сложные системы

Признак 4
Иерархические системы обычно
состоят из немногих типов
подсистем, по-разному
скомбинированных и
организованных

7. Сложные системы

Признак 5
Любая работающая сложная
система является результатом
развития работавшей более
простой системы... Сложная
система, спроектированная "с
нуля", никогда не заработает.
Следует начинать с работающей
простой системы

8. Модели качества процессов

Исследование, проведенное в 2003 году
группой Standish (US), показало, что 66%
информационных проектов полностью
закрыты или не соответствуют показателям
бюджета, масштаба, времени или качества
(т.е. 'поставлены под сомнение').
Аналогичное исследование в
Великобритании, выполненное Computer
Weekly, показывает, что 84% проектов
потерпели неудачу или были поставлены
под сомнение.

9. Модели качества процессов

Стандарты на процесс разработки ПО
ISO 9001:2000
ISO/IEC15504
Модель зрелости процесса разработки
ПО (Capability Maturity Model)

10. Модели качества процессов

Состояние зрелости в значительной
степени отражает преобладающую
культуру производства.

11. Модели качества процессов

Модель зрелости управления проектами в
организации рассматривается как
способность:
ясно формулировать успех проекта,
измерять эффективность выполнения проекта,
делать осуществление проектов более
предсказуемым,
способствовать совместной работе проектов
вместо конкуренции между собой в
многопроектной среде.

12. Модели зрелости СММ

Уровни:
1.
НАЧАЛЬНЫЙ Зависит от таланта
конкретных разработчиков (низший)
2.
ПОВТОРЯЕМЫЙ Процесс
планируется и отслеживается
3.
ОПРЕДЕЛЕННЫЙ Все уровни
закреплены, стандартизованы и
закреплены (не зависит от
способностей конкретного
разработчика)

13. Модели зрелости СММ

Уровни:
4.
УПРАВЛЯЕМЫЙ Принят контроль
качества, количественное
управление
5.
ОПТИМИЗИРУЮЩИЙ Постоянное
улучшение и повышение
эффективности процессов
разработки ПО

14. Модели зрелости СММ

15. Модели качества процессов

Цели моделирования:
способствовать пониманию целей и
методов проекта между различными
группами, реализующим проект;
измерять эффективность выполнения
проекта;
делать осуществление проектов более
предсказуемым.

16. Диаграммные нотации

Нотации моделирования:
функциональная модель,
Информационная модель,
Поведенческая (событийная)
модель.

17. Графические диаграммы

Модель бизнеса нужна, чтобы управлять
развитием компании систематически, а
не полагаться на случай и везение

18. Диаграммные нотации

функциональная модель:
описывает совокупность выполняемых
системой функций
характеризует морфологию системы (ее
построение) — состав подсистем
их взаимосвязи;

19. Диаграммные нотации

Информационная модель
отображает отношения между
элементами системы в виде структур
данных (состав и взаимосвязи)

20. Диаграммные нотации

Поведенческая (событийная) модель
описывает информационные процессы
(динамику функционирования), в ней
фигурируют такие категории, как
состояние системы,
событие,
переход из одного состояния в другое, условия
перехода, последовательность событии.
Используется в основном для систем реального
времени

21. Функциональная модель

Начало разработки диаграмм функционального
моделирования относится к середине 1960-х годов,
когда Дуглас Т. Росс предложил специальную
технику моделирования, получившую название
SADT (Structured Analysis & Design Technique).
1970-е годы ВВС США интеграции компьютерных и
промышленных технологий
(Integrated Computer Aided Manufacturing , ICAM) и
назвали ее IDEF (Icam DEFinition)
или (Integeration DEfenition for Function modeling)
Д.А. Марка, К. МакГоуэн Методология структурного анализа и проектированияSADT. Москва, 1993.

22. Функциональная модель

IDEF0 - для документирования процессов
производства и отображения информации
об использовании ресурсов на каждом из
этапов проектирования систем 1980.
IDEF1 - для документирования
информации о производственном
окружении систем (ERD) 1993.
IDEF2 - для документирования поведения
системы во времени.
IDEF3 - специально для моделирования
бизнес-процессов

23. Функциональная модель

IDEF4 реализует объектно-ориентированный анализ больших
систем. Он предоставляет пользователю графический язык для изображения
классов, диаграмм наследования, таксономии методов.
IDEF5 направлен на представление онтологической информации
приложения в удобном для пользователя виде. Для этого используются
символические обозначения (дескрипторы) объектов, их ассоций, ситуаций и
схемный язык описания отношений классификации, "часть-целое", перехода
и т. п. В методике имеются правила связывания объектов (термов) в
предложения и аксиомы интерпретации термов.
IDEF6 направлен на сохранение рационального опыта проектирования
информационных систем, что способствует предотвращению структурных
ошибок.
IDEF8 предназначен для проектирования диалогов человека и технической
системы.
IDEF9 предназначен для анализа имеющихся условий и ограничений (в том
числе физических, юридических, политических) и их влияния на
принимаемые решения в процессе реинжиниринга.
IDEF14 предназначен для представления и анализа данных при
проектировании вычислительных сетей на графическом языке с описанием
конфигураций, очередей, сетевых компонентов, требований к надежности и
т.п.

24. Графические диаграммы

Первый шаг при построении
определение назначения модели:
набора вопросов на которые должна
отвечать модель;
Определение границ моделирования;
Определение целевой аудитории;
Другими словами указывается точка
зрения: учитывает границы
моделирования и назначение.

25. Графические диаграммы

Основные аспекты модели:
Цель моделирования
• Почему моделируется данный процесс?
• Что выявит данная модель?
• Как ознакомившиеся с этой моделью
смогут ее применить?
Точка зрения
Граница моделирования
ширина охвата
глубина детализации

26. Графические диаграммы

Модели:
As-Is
To-Be

27. IDEF0 Семантика

IDEF0-модели состоят из трех типов документов:
графических диаграмм,
текста
краткий комментарий к содержанию диаграммы.Текст
используется для объяснений и уточнений характеристик,
потоков, внутриблочных соединений и т.д.
глоссария.
компонент IDEF0-модели, содержащий блоки, стрелки,
соединения блоков и стрелок и ассоциированные сними
отношения
определяет понятия и термины, которые должны быть
одинаково понимаемы всеми участниками разработки
презентационные FEO-диаграммы
(For Exhibition Only) Проиллюстрировать другие точки
зрения или детали, выходящие за рамки традиционного
синтаксиса IDEFO

28. IDEF0

Графический язык –
полное и выразительное средство, способное наглядно
представлять широкий спектр деловых, производственных и
других процессов и операций предприятия на любом уровне
детализации.
обеспечивает точное и лаконичное описание моделируемых
объектов, удобство использования и интерпретации этого
описания.
облегчает взаимодействие и взаимопонимание системных
аналитиков, разработчиков и персонала изучаемого
объекта (фирмы, предприятия), т.е. служит средством
«информационного общения» большого числа специалистов
и рабочих групп, занятых в одном проекте, в процессе
обсуждения, рецензирования, критики и утверждения
результатов.

29. IDEF0

Синтаксис: Структурные
компоненты или характеристики
языка и правила, которые
определяют отношения между ними.
Семантика: значение синтаксических
компонентов языка.
Компоненты синтаксиса IDEF0 –
блоки, стрелки, диаграммы и
правила

30. IDEF0 Блок

Блоки представляют функции,
определяемые как деятельность,
процесс, операция, действие или
преобразование
•Имя функции –глагол
или глагольный оборот
•Показан номер блока
РАЗРАБОТАТЬ МОДЕЛЬ
1

31. IDEF0 Блок

Размеры блоков должны быть
достаточными для того, чтобы
включитьимя блока.
Блоки должны быть прямоугольными, с
прямыми углами.
Блоки должны быть нарисованы
сплошными линиями.
РАЗРАБОТАТЬ МОДЕЛЬ
1

32. IDEF0 Стрелки

Ломаные стрелки изменяют направление
только под углом 90 град.
Стрелки должны быть нарисованы
сплошными линиями различной толщины.
Стрелки могут состоять только из
вертикальных или горизонтальных
отрезков; отрезки, направленные по
диагонали , не допускаются.
Концы стрелок должны касаться внешней
границы функционального блока, но не
должны пересекать ее.
Стрелки должны присоединяться к блоку
на его сторонах. Присоединение в углах
не допускается

33. IDEF0 Семантика

ICOM нотация
Управление
(С – Control)
Управление
(O – Output)
Вход (I – Input)
ИМЯ ФУНКЦИИ
Механизм
(M – Mechanism)
Вызов

34. IDEF0 Семантика

Сегменты стрелок, за исключением стрелок вызова, должны
помечаться существительным или оборотом существительного,
если только единственная метка стрелки несомненно не
относится к стрелке в целом.
Чтобы связать стрелку с меткой, следует использовать
"тильду" (
).
В метках стрелок не должны использоваться следующие
термины: функция, вход, управление, выход, механизм, вызов.
конструкторские
требования
Чертеж общего вида
ВЫПОЛНИТЬ
ДЕТАЛИРОВКУ
инженерконструктор
Комплект
детальных
чертежей

35. Контекстная диаграмма

Контекстный блок — функциональный
блок самого высокого уровня

36. Дочерняя диаграмма

1
1
0
2
2
A-0
A0
A3
A3
A32
3
3

37. Графические диаграммы

38. Ветвление стрелок

39. Ветвление стрелок

40. Ветвление стрелок

41. Ветвление стрелок

42. Отношение в блоках

В пределах одной диаграммы:
доминирование;
управление;
выход - вход;
обратная связь по управлению;
обратная связь по входу;
выход – механизм.

43. Отношение в блоках

44. Отношение в блоках

45. Отношение в блоках

46. Отношение в блоках

47. Отношение в блоках

48. Отношение в блоках

49. Отношение в блоках

ICOM - коды,
связывающие
граничные
стрелки этих
диаграмм со
стрелками их
родительских
блоков
I (Input)
C (Control)
O (Output)
M (Mechanism)
English     Русский Rules