Similar presentations:
Информационные технологии
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. Дочерняя диаграмма
11
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)