- •1. Основные концепции системного анализа и проектирования в ssadm
- •1.1. Цели и концепции
- •1.1.1. Пользователи.
- •1.1.2. Менеджеры.
- •1.2.4. Обозначения структурной модели
- •1.1.3. Разработчики.
- •1.2 Структурная модель ssadm, ее назначение, роль и состав.
- •1.2.1 Модули.
- •1.2.2. Входы модулей.
- •1.2.3 Выходы модулей.
- •Информационная шина.
- •Организационные действия.
- •Соглашения, принятые для облегчения понимания схем.
- •1.2.5 Описания действий.
- •1.3. Жизненный цикл разработки систем
- •1.3.1. Модуль fs - описание действия "анализ реализуемости".
- •Краткое изложение.
- •Участники.
- •Предусловия.
- •1.3.2. Модуль rа - описание действия "анализ требований".
- •Краткое изложение.
- •Участники.
- •Предусловия.
- •1.3.3. Модуль rs - описание действия "спецификация требований".
- •Участники.
- •Предусловия.
- •1.3.4 Модуль ls-определение действия "спецификация логической системы".
- •Краткое изложение.
- •Участники.
- •Предусловия.
- •Участники.
- •Предусловия.
- •1.4. Ключевые понятия и философия
- •1.4.1. Три вида модели.
- •1.4.2. Ориентация на требования.
- •1.4.3. Пользователь, функция и моделирование данных.
- •1.4.4. Варианты организационного управления.
- •1.5. Сценарий применения методов
- •1.5.1. Применение методов в жизненном цикле.
- •1.5.2. Взаимозависимости между методами.
- •1.5.2.1. Взаимодействие методов в модуле fs (Анализ реализуемости).
- •1.5.2.2. Взаимодействие методов в модуле ка (Анализ требований).
- •"Определение требований".
- •"Моделирование потоков данных".
- •1.5.2.3. Взаимодействие методов в модуле rs (Спецификация требований).
- •"Моделирование потоков данных".
- •"Логическое моделирование данных".
- •"Определение функций".
- •"Реляционный анализ данных".
- •"Объектно-событийное моделирование".
- •"Спецификация прототипирования".
- •"Проектирование диалога".
- •Организационное управление.
- •Проектирование базы данных.
- •Проектирование физических процессов.
- •Интерфейс процесс - данные.
- •1.6 Достоинства инвариантности к реализации проектов
- •1.7. Информационно-технологическая поддержка
- •2 Моделирование потоков данных
- •2.1. Назначение метода
- •2.2 Обзор
- •2.3. Место метода моделирования потоков данных в процессе проектирования
- •2.3.1 Этапы
- •2.3.2.Взаимосвязь с другими методами.
- •2.4. Входы мпд
- •2.5 Выходы мпд
- •2.6. Основные понятия и обозначения метода моделирования потоков данных.
- •2.6.1. Обозначения, применяемые при построении схем потоков данных.
- •2.6.1.1. Внешний объект
- •2.6.1.2. Процесс
- •2.6.1.3. Хранилища данных.
- •2.6.1.4. Поток данных
- •2.6.1.5. Двунаправленный поток
- •2.6.1.6. Поток данных между внешними объектами
- •2.6.1.7. Поток ресурса
- •2.6.1.8. Разрешенные спд - соединения
- •2.6.2. Спд - иерархия
- •2.6.3. Правила декомпозиции процесса.
- •2.6.5.Декомпозиция других элементов спд
- •2.7 Техника моделирования потоков данных
- •2.7.1. Модель потоков данных существующей системы (мпд сс)
- •2.7.1.1. Начало моделирования
- •2.7.1.2. Спд нижних уровней
- •2.7.1.3. Контекстные схемы, схемы документопотоков и схемы ресурсопотоков
- •2.7.1.4. Построение и использование контекстной схемы
- •2.7.1.5. Построение и использование схем документопотоков
- •2.7.1.6. Разработка схем документопотоков
- •2.7.1.7. Составление схемы ресурсопотоков
- •2.7.2. Логическая модель потоков данных (лмпд)
- •2.7.2.1. Процедуры приведения мпд сс к логической мпд
- •2.7.2.2. Рационализация хранилищ данных
- •2.7.2.3. Рационализация процессов нижнего уровня
- •2.7.2.4. Реконструирование иерархии
- •2.7.2.5. Общие функциональные признаки
- •2.7.2.6. Проверки полноты и согласованности
- •2.7.2.7. Идентификаторы процесса.
- •2.7.2.8. Избегайте интуитивного синтеза лмпд
- •2.7.4. Мпд тс
- •2.7.4.1. Мпд тс и определение функций
- •1.9. Реальные ограничения
- •2.7.2.9. Спд и варианты бизнес-системы.
- •2.7.4.2. Связь между потоками данных и событиями
- •2.7.4.3. Проверка правильности по другим продуктам технологии
- •2.8. Заключение
- •3. Логическое моделирование данных
- •3.1. Назначение
- •3.2. Обзор
- •3.3. Использование лмд в ssadm – технологии
- •3.3.1. Этапы.
- •3.3.2. Связь с другими методами.
- •3.4. Входы логического моделирования данных
- •3.5 Выходы логического моделирования данных
- •3.6. Основные понятия и обозначения метода логического моделирования данных
- •3.6.1. Объекты.
- •3.6.2. Связи
- •3.6.3. Степень связи.
- •3.6.4. Жесткость.
- •3.6.5. Идентификаторы связи.
- •3.6.6. Фраза-описатель связи.
- •3.6.7. Группы исключающих связей.
- •3.6.8. Рекурсивные связи.
- •3.6.9. Разбиения.
- •3.7. Понятия логического моделирования данных, не изображаемые на лсд
- •3.7.1 Мобильные и немобильные объекты.
- •3.7.3. Обязательные и необязательные атрибуты.
- •3.7.4. Сгруппированные домены.
- •3.7.5. Уникальные идентификаторы.
- •3.8. Вспомогательные понятия
- •3.8.1. Главные и вспомогательные объекты.
- •3.8.2. Ключи.
- •3.8.3. Ссылочные объекты.
- •3.8.4. Простые иерархические ключи.
- •3.8.5 Составные ключи.
- •3.8.6. Более сложные ключи.
- •3.9. Использование метода в процессе проектирования
- •3.9.3. Идентификация связей.
- •3.9.4. Формирование лсд.
- •3.9.5. Присвоение имен связям.
- •3.9.6. Нормализация лмд.
- •3.9.7. Проверка правильности лмд.
- •3.9.8. Удаление лишних связей из лсд.
- •3.9.9. Раскрытие связей типа m:n.
- •3.9.10. Раскрытие связей типа 1:1.
- •Связь 1:1 с одним необязательным концом.
- •Связь 1:1 с двумя необязательными концами.
- •Связь 1:1 с двумя обязательными концами.
- •3.9.11. Определение путей доступа запросов к данным.
- •Б) Уточнение триггера запроса.
- •В) Уточнение пути доступа запроса к данным.
- •3.9.12. Представление лмд пользователю.
- •3.9.13. Документирование лмд.
- •3.10. Краткое изложение процедуры
- •Приложение 1
- •2.2. Руководство по заполнению формы – «Описание объекта» – Часть 2
- •2.3. Руководство по заполнению формы – «Описание связи».
- •2.4. Руководство по заполнению формы – «Описание Атрибут/Элемент данных».
- •2.5. Руководство по заполнению формы «Описание сгруппированного домена».
Участники.
Группа анализа реализуемости составляется из специалистов-консультантов и опытных пользователей, обладающих способностями к организационному управлению проектом и анализу.
Предусловия.
Организационные полномочия:
• договор об объеме исследований;
• исходные данные, определяющие проблему;
• вариант, выбранный для анализа реализуемости.
Входы:
• документы, инициирующие проект.
Ссылки:
• бизнес-цели;
• бизнес-планы;
• принципы стратегии в области информационных систем;
• рабочие документы по планированию стратегии информационной системы;
• схемы организации;
• портфель проекта.
Продукты:
• отчет по анализу реализуемости.
Действия:
• анализ реализуемости.
1.3.2. Модуль rа - описание действия "анализ требований".
Цели:
• определить назначение системы;
• определить способ интеграции компонент информационной технологии с другими элементами системы;
• сформировать мнение о себестоимости и прибыльности системы в целом;
• подтвердить возможность длительной эксплуатации системы;
• удовлетворить требования пользователей.
Краткое изложение.
"Анализ требований" вытекает из необходимости определения требований к системе и формирования набора вариантов бизнес-системы. Исследования проводятся в контексте будущей системы. Выявленные требования документируются в "Каталоге Требований" и формулируются для достижения системных целей. Они обосновываются уровнями обслуживания, соображениями безопасности (защиты информации) и общим функциональным наполнением системы. Каждое из них по возможности выражается в виде количественной оценки, что способствует организации проверки пользователями приемлемости всех разработанных группой продуктов.
"Каталог требований" поддерживается моделями существующей системной среды: моделью потоков данных в существующем функциональном наполнении и логической моделью данных, используемых в службах существующей системы.
Варианты бизнес-системы представляются для того, чтобы в рамках требуемого функционального наполнения обеспечить выбор и оценить их планируемую стоимость.
Участники.
К анализу требований привлекаются аналитики, обладающие знаниями как в области SSADM, так и в области бизнеса, а также пользователи, поставщики средств информационной технологии и штатные сотрудники организации-заказчика.
Предусловия.
Организационные полномочия:
• документы, инициирующие проект;
• модульные планы анализа требований;
• управление анализом требований.
Входы:
• документы, инициирующие проект;
• отчет по анализу реализуемости;
• отчеты по ранее проведенным исследованиям.
Ссылки:
• бизнес-цели;
• описания данных для существующей среды;
• формы и документы, действующие в существующей среде;
• организационная и техническая политики;
• описание процедур из существующей среды.
Продукты:
• анализ требований;
• варианты бизнес-системы;
• выбранный вариант бизнес-системы;
• масштабы проекта и анализа.
Действия:
• исследования действующей среды;
• варианты бизнес-системы.
1.3.3. Модуль rs - описание действия "спецификация требований".
Цель.
Представить организации-пользователю на рассмотрение «Спецификацию требований», определяющую масштабы системы, соответствующее обеспечение и критерии оценки приемлемости проектных решений, а также обеспечить возможность согласованной разработки спецификации логической системы группой проектировщиков. Жизненно важным является то, что «Спецификация требований» содержит соответствующий текущему моменту времени полный набор требований, определенных при непосредственном участии пользователя и согласованных с ним.
Краткое изложение.
Результаты анализа требований пересматриваются с учетом особенностей выбранного варианта бизнес-системы и использованием методов определения требований, моделирования потоков данных и логического моделирования данных с целью уточнения и детализации "Каталога требований", моделей данных и процессов.
Схемы потоков данных последовательно трансформируются в функции и формально специфицированные структуры ввода-вывода. Логическая модель данных обогащается и приближается к реальности с помощью методов реляционного анализа данных и анализа истории жизни объектов.
Детально специфицируются и определяются события в терминах взаимодействия эффектов. Они, а также пути доступа запросов к данным, дают подробный набор требований по доступу к данным достаточный для окончательного построения полной логической модели данных.
Цель состоит в детальном выражении требований в "Каталоге требований" и объективной связи их с компонентами "Спецификации требований" (определениями функций и логической моделью данных).
