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

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)