- •1.2.Начало 70-х годов - “software crisis” (кризис по)
- •3.Категории современных проектов
- •4. Проблемы сегодняшнего дня
- •5. Экстремальные проекты
- •6. Сопровождение
- •7. Принципы оценки технологий (Agile Software Development)
- •8. Модель смм
- •9.Основные направления развития современных технологий
- •11.Жизненный цикл по. Процессы и модели
- •13. Процесс разработки по
- •14. Процесс управления конфигурацией (configuration management process) –
- •15. Процесс обеспечения качества (quality assurance process)
- •16. Модель жц по
- •17. Состав стадий полного жц по
- •18 Каскадная модель жц по (waterfall)
- •21.Подход rad (Rapid Application Development) – ibm, James Martin, середина 80-х годов
- •23А. Модели и их роль в создании систем
- •23. Графическое моделирование - средство преодоления сложности больших систем
- •24. Язык моделирования:
- •26. Диаграммы uml (версия 1.Х)
- •27. Технологии создания программного обеспечения
- •28. Технология Rational Unified Process (rup)
- •29. Стадии жизненного цикла по
- •30. Понятие бизнес-процесса
- •31.Области применения бизнес-моделей:
- •32.Многообразие средств моделирования
- •33.Метод sadt
- •34.Преимущества и недостатки idef0
- •35.Метод idef3
- •36.37.Моделирование потоков данных (процессов)
- •38.39.Erd (Entity-Relationship Diagrams) – диаграммы “сущность-связь”
33.Метод sadt
Назначение - моделирование искусственных систем средней сложности
Создание - 1969 г., Дугласс Росс
Стандартизация - Министерство обороны США (семейство стандартов IDEF), Федеральный стандарт США (IDEF0, http://www.idef.com)
Метод SADT - совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области
Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями
Основные концепции SADT:
графическое представление блочного моделирования
связность диаграмм, уникальность меток и наименований, синтаксические правила для графики, разделение входов и управлений
отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель
Методика моделирования
Сбор информации об объекте, определение его границ
Определение цели и точки зрения модели
Построение, обобщение и декомпозиция диаграмм
Критическая оценка, рецензирование и комментирование
Синтаксис диаграмм
Диаграммы содержат блоки и дуги
Блоки представляют функции
Блоки имеют доминирование
Дуги изображают наборы объектов
Дуги изображают взаимосвязи между блоками:
выход-управление
выход-вход
обратная связь по управлению
обратная связь по входу
выход-механизм
Правило «3-6» - ограничение мощности краткосрочной памяти человека
Типы связей между функциями
Случайная - связь между функциями незначительна или полностью отсутствует
Логическая - данные и функции попадают в общий класс или набор элементов
Временная - функции, связанные во времени
Процедурная - функции выполняются в течение одной и той же части цикла или процесса
Коммуникационная - функции используют и/или производят одни и те же данные
Последовательная - выход одной функции служит входными данными для следующей функции
Функциональная - все элементы функции влияют на выполнение одной и только одной функции
Стратегии декомпозиции
Функциональная декомпозиция
декомпозиция в соответствии с функциями, которые выполняют люди или организация
Декомпозиция в соответствии с известными стабильными подсистемами
Декомпозиция по физическому процессу
выделение функциональных стадий, этапов завершения или шагов выполнения
Определение момента прекращения декомпозиции
Достаточная детализированность блока
Изменение уровня абстракции (диаграмма начинает описывать, как функционирует блок, вместо описания того, что блок делает)
Изменение точки зрения
Сходные функции
Тривиальные функции
Принципы формирования модели бизнес-процессов верхнего уровня декомпозиции
следует избегать чрезмерной детализации (модель бизнес-процесса верхнего уровня должна содержать не более 6-8 блоков функций)
следует использовать реально существующие названия функций или работ
не следует пытаться детально отразить всю существующую логику процесса (это будет сделано при формировании детальных моделей)
важно отразить общую последовательность работ, подразделения участвующие в их исполнении, ключевые ресурсы
важно отразить основную логику процесса