- •Проектирование информационных систем
- •Для студентов пятого курса специальности 071900 – Информационные системы в технике и технологиях
- •1Введение
- •1.1Классификация методов проектирования
- •1.2Виды информационных систем
- •1.2.1Системы обработки данных
- •1.2.2Системы управления
- •1.2.3Офисные системы
- •1.2.4Системы поддержки принятия решений
- •1.2.5Экспертные системы
- •1.3Структура информационной системы
- •1.4Архитектура системы
- •1.4.1Общее понятие системной архитектуры
- •1.4.2Архитектурные уровни
- •2Проектирование информационных систем на основе объектно-ориентированного подхода
- •2.1Представления системы
- •2.2Uml-модель информационной системы
- •2.3Представления системы в rational rose
- •2.4Проектирование в rational rose
- •2.5Моделирование предметной области
- •2.5.1Моделирование организационной структуры
- •2.5.2Моделирование бизнес-процессов
- •2.5.3Моделирование бизнес-функций
- •2.5.4Моделирование документов и бизнес-сущностей
- •2.6Использование бизнес-модели на этапах разработки
- •2.7Диаграмма вариантов использования – use case diagram
- •2.7.1Обозначения в диаграмме вариантов использования
- •2.7.2Идентификация актёров и вариантов использования
- •2.7.3Категории вариантов использования
- •2.7.4Абстрактные варианты использования
- •2.7.5Конкретные варианты использования
- •2.7.6Запись актёров и вариантов использования
- •2.7.7.4Альтернативные потоки событий
- •2.7.7.5Постусловия варианта использования
- •2.8Диаграммы взаимодействия – interaction diagrams
- •2.8.1Идентификация объектов
- •2.8.2Использование диаграмм взаимодействия
- •2.8.3Диаграмма последовательности – Sequence diagram
- •2.8.4Подход к разработке диаграммы последовательности
- •2.8.5Диаграмма кооперации – Collaboration Diagram
- •2.9Диаграммы классов – class diagrams
- •2.9.1Классы
- •2.9.1.1Параметризованный класс – parameterized class
- •2.9.1.2Класс-наполнитель – instantiated class
- •2.9.1.3Утилита - utility
- •2.9.1.4Метакласс – metaclass
- •2.9.1.5Абстрактный класс – abstract class
- •2.9.2Стереотип класса
- •2.9.2.1Пограничные классы – boundary classes
- •2.9.2.2Управляющие классы – control classes
- •2.9.2.3Классы-сущности – entity classes
- •2.9.3Видимость класса – Visibility
- •2.9.4Пакеты – packages
- •2.9.5Диаграммы классов
- •2.9.6Создание диаграммы классов
- •2.9.6.1Идентификация программных классов
- •2.9.6.2Идентификация атрибутов
- •2.9.6.3Идентификация операций
- •2.9.6.4Идентификация ассоциаций
- •2.10Диаграммы состояний – statechart diagrams
- •2.10.1Основные сведения о диаграмме состояний
- •2.10.2События
- •2.10.2.1Сигнал
- •2.10.2.2С обытие вызова
- •2.10.2.3События времени и изменения
- •2.10.3Правила построения диаграммы состояний
- •2.10.4Диаграммы состояний для вариантов использования
- •2.10.5Классы и типы для диаграммы состояний
- •2.11Диаграммы компонентов – component diagrams
- •2.11.1Компоненты
- •2.11.2Основные виды компонентов
- •2.11.3Основные стереотипы компонентов
- •2.11.4Диаграмма компонентов
- •2.11.5Правила построения диаграммы компонентов
- •2.12Диаграмма развёртывания – deployment diagram
- •2.12.1Узлы - Nodes
- •2.12.2Соединения
- •2.12.3Диаграмма развёртывания
- •2.12.4Использование диаграмм развёртывания
- •2.12.4.1Встроенные системы
- •2.12.4.2Клиент-серверные системы
- •2.12.4.3Распределённые системы
- •3Системное проектирование сложных систем
- •3.1Цель и задачи системного проектирования
- •3.1.1Цель системного проектирования
- •3.1.2Задачи системного проектирования
- •3.2Структура и содержание документов системного проекта
- •3.2.1Техническое задание
- •3.2.2Описание архитектуры программного и информационного обеспечения системы
- •3.2.3Описание жизненного цикла, технологии и инструментария проектирования программного средства и базы данных
- •3.2.4Планы управления рабочими проектами
- •3.2.5Техническое задание на рабочее проектирование
- •3.2.6Системный проект
- •3.2.7Акт завершения работ и утверждения системного проекта
- •3.2.8Основные компоненты договора на детальное проектирование
- •3.3Работы и нормативные документы по системному проектированию информационной системы
- •3.4Стандарты в жизенном цикле информационных систем
- •3.4.1Нормативно-методическое обеспечение
- •3.4.2Рекомендуемые стандарты
- •4Проектирование систем как часть жизненного цикла
- •4.1Стадии и этапы жизненного цикла
- •4.1.1Исследование
- •4.1.2Проработка
- •4.1.3Создание
- •4.1.4Переходный период
- •4.2Процесс проектирования
- •4.2.1Концептуальное проектирование
- •4.2.2Логическое проектирование
- •4.2.3Физическое проектирование
3.4Стандарты в жизенном цикле информационных систем
Существует две альтернативы: стандарты и хаос. Можно выбрать хаос – бесконечные совещания, оригинальные интерфейсы-преобразователи, интересный “творческий” процесс, напряжённый поиск на экране кнопки <Выход>. Несмотря на такие широкие перспективы, лучше выбрать стандарты.
Стандарты – это зафиксированный лучший опыт практической деятельности по разработке систем.
Следование стандартам в производстве позволяет наладить массовое изготовление продукции, повысить её качество. Использование стандартов помогает снизить квалификационные требования к персоналу, сформировать чёткие программы обучения, лучше подготовить персонал к решению практических задач. В равной степени всё это можно отнести и к разработке информационных систем.
Стандартизация выгодна всем: и производителям информационных систем (ИС), и потребителям ИС.
Использование стандартов для разработчиков ИС:
повышает качество информационных систем;
обеспечивает совместимость с другими системами;
является базой для повторного использования решений;
снижает трудоёмкость и себестоимость работ;
повышает качество работ.
Использование стандартов для потребителей ИС:
экономит средства на приобретение техники (не нужно покупать нестандартное оборудование);
упорядочивает деятельность (пропадают “незаменимые” сотрудники);
предоставляет возможность выбора поставщиков, которые предлагают стандартизованные решения.
3.4.1Нормативно-методическое обеспечение
Нормативно-методическое обеспечение (НМО) представляет собой комплекс документов, регламентирующих:
порядок разработки, сопровождения, внедрения и развития программной системы (ПС) и базы данных (БД) ИС;
общие требования к составу и связям между ПС и БД;
виды и состав документации.
Цель НМО – установление общих правил ведения и оформления разработки ПС и БД, которые обеспечивают единую нормативную и методическую основу для взаимодействия участников проектной группы и пользователей на всех этапах жизненного цикла.
Задачи НМО:
Регламентация общего порядка, состава и содержания процессов создания, сопровождения, внедрения и развития ИС.
Регламентация общих требований к ПС и БД для обеспечения качества, унификации проектирования, оформления, повторного использования.
Формирование методических материалов, обеспечивающих различным участникам проектной группы возможность использовать наиболее эффективные приёмы и методы работы, выполнять их по единой схеме и получать единообразные результаты.
Р егламентация состава, содержания и форм проектных материалов и программной документации.
Все, входящие в состав НМО документы, должны быть определены по следующим параметрам:
Вид регламентации (стандарт, руководящий документ, положение, инструкция и т.д.).
Статус (международный, отраслевой, предприятия).
Область действия документа.
Объект регламентации (стандартизации).
Любой регламентирующий документ (в частности стандарт) имеет два важнейших параметра:
Область действия.
Объект регламентации (стандартизации).
Областью действия НМО может быть вся организация-разработчик, либо отдельный проект.
В качестве объектов, подлежащих регламентации, могут выступать:
Компоненты архитектуры ИС – архитектура, интерфейсы, протоколы.
Стадии работ и их результаты (промежуточные релизы).
Процессы жизненного цикла и их отдельные элементы (задачи, работы).
Этапы работ по стадиям и процессам.
Регламенты выполнения работ и отдельные процедуры.
Роли персонала, их обязанности и ответственность за конечный результат.
Результаты работ (проектные и программные документы).
Метрики измерения сложности, качества и трудоёмкости работ.
Нормативно-справочная документация должна поддерживать этапы жизненного цикла ИС по ГОСТ Р ИСО/МЭК 12207-99, в первую очередь этап проектирования. Следует заметить, что не все документы НМО являются стандартами. БОльший объём составляют руководящие и методические документы. Если какие-либо объекты и/или процессы проходят длительную апробацию и проверку временем, то документация по ним может быть закреплена как стандарт предприятия. Однако это не значит, что документация может быть составлена без соблюдения действующих стандартов.
Методическое обеспечение должно поддерживать комплексную методологию ведения работ по проекту. Желательно, чтобы эта методология максимально охватывала весь жизненный цикл. Например, RUP (Rational Unified Process). Наибольший эффект достигается, когда методическое обеспечение поддерживается инструментальными средствами. Например, SoDA (IBM Rational).