2.19M

Categories:

informatics

software

Проектирование информационных систем. Введение в проектирование. Жизненный цикл ИС

1.

Проектирование
информационных систем
к.т.н., доцент
Набатов Александр Нурович
6-224

Введение в проектирование. Жизненный цикл ИС
Жизненный цикл информационных
систем
• основные процессы ЖЦ ПО (приобретение,
поставка, разработка, эксплуатация,
сопровождение);
• вспомогательные процессы, обеспечивающие
выполнение основных процессов
(документирование, управление конфигурацией,
обеспечение качества, верификация, аттестация,
оценка, аудит, решение проблем);
• организационные процессы (управление
проектами, создание инфраструктуры проекта,
определение, оценка и улучшение самого ЖЦ,
обучение)

3.

Введение в проектирование. Жизненный цикл ИС
Модели жизненного цикла ПО
каскадная модель (70-85 г.г.)

4.

Введение в проектирование. Жизненный цикл ИС
Модели жизненного цикла ПО
Модифицированная каскадная модель

5.

Введение в проектирование. Жизненный цикл ИС
Модели жизненного цикла ПО
спиральная модель (86-90 г.г.)

6.

Введение в проектирование. Жизненный цикл ИС
Методологии и технологии
проектирования ИС
• RUP
• RAD
• XP
• FDD
• Lean
• Cleanroom SE
• OpenUP
• MSF
• DSDM
• TDD

7.

Проектирование информационных систем
Классификация информационных систем
Классификация ИС:
по признаку структурированности задач
–
–
–
по характеру представления и логической организации хранимой информации
–
–
–
фактографические информационные системы - накапливают и хранят данные в виде множества
экземпляров одного или нескольких типов структурных элементов (информационных объектов),
которые отражают сведения по какому-либо факту, событию и пр., отделенному от других сведений
документальные информационные системы - единичным элементом информации является документ
и информация на вводе (входной документ). При создании информационной базы процесс
структуризации не производится или производится в ограниченном виде
геоинформационные информационные системы- данные организованы в виде отдельных
информационных объектов, привязанных к общей электронной топографической основе
(электронной карте)
по выполняемым функциям и решаемым задачам
–
–
–
–
структурированные (формализуемые) задачи, где известны все ее элементы и взаимосвязи между
ними, удается выразить ее содержание в форме математической модели, имеющей точный алгоритм
решения
неструктурированные (неформализуемые) задачи– задачи, в которых невозможно выделить
элементы и установить между ними связи. Решение таких задач из-за невозможности создания
математического описания и разработки алгоритма связано с большими трудностями
частично структурированные задачи - известна часть элементов и связей между ними
справочные информационные системы
информационно-поисковые информационные системы
расчетные информационные системы
технологические информационные системы
по характеру обработки информации на различных уровнях управления предприятием
–
–
–
системы обработки данных (EDP – Electronic Data Processing)
информационные системы управления (MIS – Management Information System)
системы поддержки принятия решений (DSS – Decision Support System)

8.

Проектирование информационных систем
Классификация информационных систем
Классификация ИС:
по уровням управления
–
–
–
–
по функциональному признаку
–
–
–
–
–
производственные системы
системы маркетинга
финансовые и учетные системы
системы кадров по подбору и расстановке специалистов и ведению служебной документации
системы управления вспомогательным производством
по сфере применения
–
–
–
–
информационные системы оперативного (операционного) уровня - (бухгалтерские, банковские,
обработки заказов и пр.) поддерживают специалистов, обрабатывая данные о сделках и событиях
(счета, накладные, зарплата, кредиты, поток сырья и материалов)
информационные системы специалистов - помогают пользователям повысить продуктивность и
производительность. Их задача – интеграция новых сведений и помощь в обработке бумажных
документов
информационные системы для менеджеров среднего звена - используются для мониторинга,
контроля, принятия решений и администрирования
стратегические информационные системы - обеспечивают поддержку принятия решений по
реализации стратегических перспективных целей развития организации и помогают высшему звену
управленцев осуществлять долгосрочное планирование
информационные системы организационного управления
информационные системы управления технологическими процессами
информационные системы автоматизированного проектирования
корпоративные информационные системы
по степени распределенности
–
–
настольные (desktop), или локальные ИС
распределённые (distributed) ИС

9.

Проектирование информационных систем
Предпроектная стадия
Уровень целеполагания и задач организации:
• Разработка целей организации и
согласование со концепцией
автоматизации
• Формирование задач организации
• Покрытие задач информационной
системой(ами) организации

10.

Предпроектное документирование
Выбор исполнителей:
• Создание конкурсной документации
• Критерии конкурсного отбора (вопрос
«информационной иглы»)
• Проведение конкурса и подведение итогов
(использование подрядчиков «в темную»)

11.

Проектирование информационных систем
Предпроектная стадия
Согласование требований и разработка спецификаций:
• Сбор требований (опрос – анкетирование –
подгонка под существующее)
• Анализ и согласование требований
• Выработка и согласование спецификаций
(концептуальная, функциональная,
техническая, кадровая, методическая часть)

12.

Проектирование информационных систем
Предпроектная стадия
Экономическая модель предварительного этапа:
• Экономическая модель заказчика
• Экономическая модель исполнителя/
подрядчика

13.

Проектирование информационных систем
Три уровня критичности ИС:
• Критическая ИС - для нее проявление дефекта при
испытаниях или возникновение отказовой ситуации
прекращает безопасное функционирование системы
обработки информации и резко увеличивает риск для
жизни и здоровья людей или риск аварии оборудования с
большим ущербом.
• Важная ИС - для нее проявление дефекта или
возникновение отказовой ситуации может существенно
снизить качество выпускаемой продукции и заметно
увеличить риск и цену грубых ошибок при обработке
информации.
• Ординарная ИС - для нее ошибки или отказовые ситуации
отражаются только на качестве и надежности выходных
результатов и не могут привести к значительному ущербу
в объектах внешней среды или к потерям у
пользователей.

14.

Проектирование информационных систем
Подбор команды
• Состав команды:
– руководство (МП, тимлиды, архитекторы)
– группа аналитики
– группа разработки
– группа тестирования
– группа документирования (техписатели)
– группа внедрения
– группа сопровождения (хотлайнеры, хелпдеск)
– группа обучения (лекторы, тьюторы, коучи)

15.

Проектирование информационных систем
Подбор команды
• Психология и совместимость:
– анкетирование
– опрос/собеседование
– рекрутинговые агентства
• История и совместимость:
– недостатки старых команд (старые конфликты, старые
интриги, отторжение нового и т.д.)
– преимущества старых команд (знания, умения и навыки)
– недостатки новых команд («не притертость» коллектива,
распыление команды на не профильные задачи)
– преимущества новых команд

16.

Проектирование информационных систем
Подбор команды
• Воспитание команды:
– «чувство победителя»
– командные тренинги
– неформальное общение
– групповая «накачка» от начальства (Тойота)
– действия «от противного» (противостояние с
руководством и/или его частью)
• Документы:
– кадровые
– менталитет и документы
– ОРД и последствия (буквальное следование ГОСТу)

17.

Проектирование информационных систем
Стандарты кодирования
Стандарт оформления кода (стандарт кодирования, стиль программирования)
(coding standards, coding convention или programming style) — набор правил и
соглашений, используемых при написании исходного кода на некотором языке
программирования. Наличие общего стиля программирования облегчает
понимание и поддержание исходного кода, написанного более чем одним
программистом, а также упрощает взаимодействие нескольких человек при
разработке программного обеспечения.
Стандарт оформления кода описывает:
• способы выбора названий и используемый регистр символов для имён
переменных и других идентификаторов:
– запись типа переменной в её идентификаторе (венгерская нотация) и
– регистр символов (нижний, верхний, «верблюжий», «верблюжий» с малой буквы),
использование знаков подчёркивания для разделения слов;
стиль отступов при оформлении логических блоков — используются
ли символы табуляции, ширина отступа;
способ расстановки скобок, ограничивающих логические блоки;
использование пробелов при оформлении логических и арифметических
выражений;
стиль комментариев и использование документирующих комментариев.

18.

Проектирование информационных систем
Стандарты кодирования
Венгерская нотация в программировании — соглашение об именовании переменных, констант и
прочих идентификаторов в коде программ. Своё название венгерская нотация получила
благодаря программисту компании Microsoft венгерского происхождения Чарльзу Симони,
предложившему её ещё во времена разработки первых версий MS-DOS. Эта система стала
внутренним стандартом Майкрософт.
Суть венгерской нотации сводится к тому, что имена идентификаторов предваряются заранее
оговорёнными префиксами, состоящими из одного или нескольких символов. При этом, как
правило, ни само наличие префиксов, ни их написание не являются требованием языков
программирования, и у каждого программиста (или коллектива программистов) они могут быть
своими.
Применяемая система префиксов зависит от многих факторов:
• языка программирования (чем более «либеральный» синтаксис, тем больше контроля
требуется со стороны программиста, а значит, тем более развита система префиксов. К тому
же использование в каждом из языков программирования своей терминологии также вносит
особенности в выбор префиксов);
• стиля программирования (объектно-ориентированный код может вообще не требовать
префиксов, в то время как в «монолитном» для разборчивости они зачастую нужны);
• предметной области (например, префиксы могут применяться для записи единиц
измерения);
• доступных средств автоматизации (генератор документации, навигация по
коду, предиктивный ввод текста, автоматизированный рефакторинг и т. д.).

19.

Проектирование информационных систем
Стандарты кодирования
Спагетти-код — плохо спроектированная, слабо структурированная, запутанная и трудная для
понимания программа, особенно содержащая много операторов GOTO (особенно переходов
назад), исключений и других конструкций, ухудшающих структурированность. Самый
распространённый антипаттерн программирования.
Спагетти-код назван так, потому что ход выполнения программы похож на миску спагетти, то есть
извилистый и запутанный. Иногда называется «кенгуру-код» (kangaroo code) из-за множества
инструкций jump.
Спагетти-код обычно возникает:
• от неопытности разработчиков;
• от серьёзного прессинга по срокам, как установленного руководством (например, в принятой
в компании системе мотивации на работу быстрее), так и установленного разработчиком
самому себе (желание все сделать наиболее быстрым способом).
CamelCase ( Верблю́ жийРеги́стр, также Горба́тыйРеги́стр, Сти́льВерблю́ да) — стиль написания
составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое
слово пишется с заглавной буквы. Стиль получил название CamelCase, поскольку заглавные буквы
внутри слова напоминают горбы верблюда.
CamelCase широко используется в языках программирования:
• В языке Java принято использовать UpperCamelCase для наименования классов и
lowerCamelCase — для наименования экземпляров классов и методов.
• В Microsoft .NET принято использовать UpperCamelCase для наименования классов и методов.
Магическое число, или сигнатура — целочисленная константа, используемая для
однозначной идентификации ресурса или данных. Такое число само по себе не несёт никакого
смысла, и может вызвать недоумение, встретившись в коде программы без соответствующего
контекста или комментария, при этом попытка изменить его на другое, даже близкое по
значению, может привести к абсолютно непредсказуемым последствиям. По этой причине
подобные числа были иронично названы магическими.

20.

Проектирование информационных систем
Экономика разработки
• Стартап экономика
• Венчурный капитал
• Гранты и субсидии
• Программирование и кредиты
• Программирование и бюджет

21.

Проектирование информационных систем
Разработка и ошибки программирования
Классификация ошибок (на примере в web-разработки)
По степени критичности (Severity):
• Блокирующие (Blocker) – Ошибки, из-за которых дальнейшая работа с
системой становится невозможной. Пример: Работа на сайте доступна только
зарегистрированным пользователям, а вход возможен только после
подтверждения e-mail, указанного при регистрации. На почту не приходит
письмо. Работа с системой, соответственно, невозможна.
• Важные (Major) — Из-за таких ошибок система, в целом, работает, но что-то
работает не так. Например, опять же, беря в пример наш абстрактный сайт, на
сайт можно загрузить аватар, но файл не сохраняется на сервере. Либо
письмо для активации приходит, но в неверной кодировке.
• Обычные (Normal) — Как правило, к этой категории баги относят очень
редко. В качестве примера, могу написать что-то вроде не работает кнопка
«Запомнить меня» на сайте.
• Малозначимые (Minor) — к таким, как правило, относятся небольшие баги,
типа опечаток, «плавания» вёрстки в IE6 на определенной странице в
админке и т.п. Редко исправляются по одному, собираются в несколько
десятков/сотен/тысяч в зависимости от продукта и фиксятся «пачкой»

22.

Проектирование информационных систем
Разработка и ошибки программирования
Классификация ошибок (на примере в web-разработки)
По приоритету (Priority, как быстро надо пофиксить тот или
иной баг):
• FIX IN RELEASE — Пофиксить в новой версии продукта. Как
правило, относится к багам, обнаруженным в процессе
тестирования нового функционала.
• MUST FIX — Пофиксить как можно быстрее. Как правило
включает в себя блокирующие баги, которые должны быть
исправлены в специальном сервис паке, до выхода новой
версии.
• FIX IF TIME — «Пофиксить, если есть врёмя» — к этой категории
как правило относятся минорные баги.
• NEVER FIX — «Не фиксить никогда». Например, какая та фича
будет удалена из следующей версии продукта, либо найдена в
продукте, который уже более не поддерживается, или его
поддержка прекратится в ближайшее время.

23.

Проектирование информационных систем
Разработка и ошибки программирования
Классификация ошибок
По месту и направлению:
• Ошибки пользовательского интерфейса;
• Системы обработки ошибок;
• Ошибки, связанные с граничными условиями;
• Ошибки вычислений;
• Ошибки управления потоком;
• Ошибки обработки или интерпретации данных;
• При ситуации «гонок»;
• Повышение нагрузки;
• Ошибки контроля версии и индентификаторов;
• Ошибки тестирования.

24.

Проектирование информационных систем
Разработка и ошибки программирования
Типы ошибок (альтернативная классификация):
• Тип 1. Ошибки в программном комплексе, допущенные при
разработке и не обнаруженные при его тестировании
• Тип 2. Ошибки, возникающие при вводе в компьютер неверных
данных
• Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу
компьютера и выполняемую им программу
• Тип 4. Выход из строя элементов компьютера и обслуживающих
его систем
• Тип 5. Выход из строя или сбои в работе измерительных
приборов и датчиков, используемых при управлении какимилибо техническими системами и технологическими процессами
• Тип 6. «Злая воля человека», носителем которой чаще всего
выступает либо программист, либо оператор

25.

Проектирование информационных систем
Разработка и ошибки программирования
Методика поиска тяжелых ошибок :
• Повторить ошибку
• Добиться точного воспроизведения на своем
компьютере
• Использовать обычные методы отладки (пошаговое
выполнение программы, установка обычных
брейкпойнтов, установка условных брейкпойнтов)
• Оптимизация и ошибки
• Закон больших чисел
• Деление интервала пополам

26.

Проектирование информационных систем
Классификация видов тестирования ИС:
• По объекту тестирования
• Функциональное тестирование
• Тестирование производительности
– Нагрузочное тестирование
– Стресс-тестирование
– Тестирование стабильности
Конфигурационное тестирование
Юзабилити-тестирование
Тестирование интерфейса пользователя
Тестирование безопасности
Тестирование локализации
Тестирование совместимости

27.

Проектирование информационных систем
Классификация видов тестирования ИС:
По знанию системы
• Тестирование чёрного ящика
• Тестирование белого ящика
• Тестирование серого ящика
По степени автоматизации
• Ручное тестирование
• Автоматизированное тестирование
• Полуавтоматизированное тестирование
По времени проведения тестирования
• Альфа-тестирование
Дымовое тестирование (smoke testing)
Тестирование новой функции (new feature testing)
Подтверждающее тестирование
Регрессионное тестирование
Приёмочное тестирование
• Бета-тестирование
По признаку позитивности сценариев
• Позитивное тестирование
• Негативное тестирование
По степени подготовленности к тестированию
• Тестирование по документации (формальное тестирование)
• Интуитивное тестирование (ad hoc testing)

28.

Проектирование информационных систем
Уровни тестирования ИС:
• Компонентное или Модульное тестирование (Component or Unit Testing)
проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут
быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо
проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для
модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило
исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking
System).
Интеграционное тестирование (Integration Testing)
Интеграционное тестирование предназначено для проверки связи между компонентами, а также
взаимодействия с различными частями системы (операционной системой, оборудованием либо
связи между различными системами).
Системное тестирование (System Testing)
Основной задачей системного тестирования является проверка как функциональных, так и не
функциональных требований в системе в целом. При этом выявляются дефекты, такие как
неверное использование ресурсов системы, непредусмотренные комбинации данных
пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии
использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
Приемочное тестирование или Приемо-сдаточное испытание (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и
проводится с целью:
–
–
определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или
нет.

29.

Проектирование информационных систем
Подходы к интеграционному тестированию ИС:
• Снизу вверх (Bottom Up)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем
тестируются. После чего собирается следующий уровень модулей для проведения
интеграционного тестирования. Данный подход считается полезным, если все или
практически все модули, разрабатываемого уровня, готовы. Также данный подход
помогает определить по результатам тестирования уровень готовности приложения.
• Сверху вниз (Top Down)
Вначале тестируются все высокоуровневые модули, и постепенно один за другим
добавляются низкоуровневые. Все модули более низкого уровня симулируются
заглушками с аналогичной функциональностью, затем по мере готовности они
заменяются реальными активными компонентами. Таким образом мы проводим
тестирование сверху вниз.
Большой взрыв ("Big Bang")
Все или практически все разработанные модули собираются вместе в виде
законченной системы или ее основной части, и затем проводится тестирование. Такой
подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты
записаны не верно, то сам процесс интеграции сильно осложнится, что станет
преградой для команды тестирования при достижении основной цели тестирования

30.

Проектирование информационных систем
Этапы внедрения:
1. Выработка стратегии (цели, критерии успеха,
критические точки, риски) – перевод стратегии в план
(календарные, сетевые, проектные, оформление
договорных обязательств) – определение тактики
(этапы, инструкции, программы обучения)
2. Организация финансового обеспечения проекта
3. Пилотная часть (не обязательный этап) - Оценка
пилотной части - Коррекция по пилотной части
4. Полномасштабное внедрение
5. Оценка и обсуждение результатов

31.

Проектирование информационных систем
Определение критериев успешного внедрения

32.

Проектирование информационных систем
Основные риски внедрения
1.Финансы
2.Время
3.Кадры
4.Качество / Реальный результат

33.

Проектирование информационных систем
Классификация стратегий
Оценка того или иного варианта стратегии производится
сравнительным позиционированием различных вариантов по
отношению друг к другу.
р
и
с
к
и
+
Низкая
эффективность
Высокая
эффективность
Минимальные
риски
Минимальные
риски
Низкая
эффективность
Высокая
эффективность
Максимальные
риски
Максимальные
риски
-
эффективность +

34.

Проектирование информационных систем
Элементы стратегии внедрения внедрения:
• - Внедрение посредством внешнего партнера
- Внедрение собственными силами предприятия
- Оптимизация бизнес – процессов
- Сохранение "старых" бизнес – процессов в ИС
• - Адаптация ИС под особенности бизнеса
- Изменения бизнес – процессов под логику системы
• - Организация выделенного проекта
- Внедрение в рамках текущей схемы управления
предприятием
• - Полнофункциональный проект «под ключ»
- Поэтапное внедрение по модулям

35.

Проектирование информационных систем
Модели обучения персонала
1. С отрывом /На рабочем месте
Альтернативное качество: Отрыв от рутины или, с другой
стороны, отрыв от конкретики.
2. С обучателем/Самостоятельное
Альтернативное качество: Скорость освоения материала
или, с другой стороны, глубина освоения.
3. Индивидуальное/Групповое обучение
Альтернативное качество: Качество или, с другой стороны,
количество.
4. Классическая схема/Сетевая(вирусная) схема
Альтернативное качество: Качество или, с другой стороны,
количество.

36.

Проектирование информационных систем
Экономика внедрения:
• Внедрение как самостоятельный вид
коммерческой деятельности
– Скидки от поставщика
– Доработки/адаптация/локализация
– Обучение
• Отказ от «остаточного» принципа в случае
если используется «котловой» метод
• Экономика гарантийного и постгарантийного
обслуживания

37.

Проектирование информационных систем
Задачи сопровождения:

38.

Проектирование информационных систем
Корректирующее сопровождения:
• Организация службы хотлайн поддержки
– Сбор, классификация и парирование ошибок
(«невыполнимые обязательства»)
– Кадровый состав (иерархия, квалификация, CRM)
– Методы работы (опосредовано, удаленно, лично)
– Экономика хотлайна
• Оптимизация работы (регламенты, ЧаВо,
мануалы, обмен опытом)
• Организация работы с баг-трекенгом

39.

Проектирование информационных систем
Развитие ИС:
• Сбор статистики работы
• Модернизация КТС и развитие ИС
(массовый переход, медленное улучшение)
• Модернизация ОС и СПО
• Модернизация ИС
– Новый функционал
– Сервисные функции
– Обновление релизов, версий
• Комплексное развитие ИС

40.

Проектирование информационных систем
Сопровождение данных:
• Контроль целостности данных
• Актуализация данных (безопасность, сайты,
регламентные документы, поздравления)
• Резервирование данных(настройка бэкапа, архивов,
регламент работы со старыми данными «точка
запрета редактирования»)
• Восстановление данных
– Актуальность копии
– Частичное восстановление и актуализация
– Проблемы материальных носителей
• Обмен данными с другими системами

41.

Проектирование информационных систем
Сопровождение пользователей:
• Онлайн и оффлайн поддержка пользователей:
– Скорость реакции
– Полнота данных (пользователя и хелпдеска)
• Обучение пользователей
– Обучение новых пользователей
– Обучение новым возможностям старых пользователей
– Онлайн обучение (дистанционное, личное)
– Оффлайн обучение
• Тренинг пользователей
– Отработка приёмов оптимальной работы
– Разбор критических ситуаций
– Командная работа

42.

Проектирование информационных систем
Проблема «информационной иглы»:
• Способы подсадки
– «Поставщик двора его величества»
– Фирма сопроводитель
– Мелкие работы
• Проблемы отказа от «ИТ-фирмы»
– Связь ближе чем просто поставщик и контрагент
– Передача дел
– Трудности адаптации
– Критический вариант с несколькими фирмами (кого слушать, «одеяло на
себя»)
• Трудности внутренней ИТ-службы
– Специалисты по «тушению пожара»
– Финансовые трудности
– «Совещательный» голос
– «Из-за деревьев не видно леса»

43.

Проектирование информационных систем
Экономика сопроводителей:
• Схема с по-часовкой
– Простота в расчетах
– Удобство сторон (при актировании указываются часы)
– Привлечение своих сотрудников (для свои нет, а для чужих надо – как
спортзал)
– Удобство с мелкими задачами
• Схема со сдельной работой
– Простота в расчетах, но сложность в определении начального объема
работ
– Понятность работ для сторон
– Отказ от работ (как в гарантийном ремонте)
– Удобство с большими объемами
• Схема с внутренним сопровождением
– Заказ-наряды, бюджетные схемы
– Проблема срочных работ
– Проблема простоев

44.

Проектирование информационных систем
Характеристики облачных технологий:
Самообслуживание по требованию (self service on demand) — потребитель самостоятельно
определяет и изменяет вычислительные потребности, такие как серверное время, скорости
доступа и обработки данных, объём хранимых данных без взаимодействия с представителем
поставщика услуг;
Универсальный доступ по сети — услуги доступны потребителям по сети передачи данных
вне зависимости от используемого терминального устройства;
Объединение ресурсов (resource pooling) — поставщик услуг объединяет ресурсы для
обслуживания большого числа потребителей в единый пул для динамического
перераспределения мощностей между потребителями в условиях постоянного изменения
спроса на мощности; при этом потребители контролируют только основные параметры услуги
(например, объём данных, скорость доступа), но фактическое распределение ресурсов,
предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители
всё-таки могут управлять некоторыми физическими параметрами перераспределения,
например, указывать желаемый центр обработки данных из соображений географической
близости);
Эластичность — услуги могут быть предоставлены, расширены, сужены в любой момент
времени, без дополнительных издержек на взаимодействие с поставщиком, как правило, в
автоматическом режиме;
Учёт потребления — поставщик услуг автоматически исчисляет потреблённые ресурсы на
определённом уровне абстракции (например, объём хранимых данных, пропускная
способность, количество пользователей, количество транзакций), и на основе этих данных
оценивает объём предоставленных потребителям услуг.

45.

Проектирование информационных систем
Облачные технологии:

46.

Проектирование информационных систем
Модели развёртывания облачных технологий:
Частное облако (private cloud) — инфраструктура, предназначенная для использования одной
организацией, включающей несколько потребителей (например, подразделений одной
организации), возможно также клиентами и подрядчиками данной организации. Частное
облако может находиться в собственности, управлении и эксплуатации как самой
организации, так и третьей стороны (или какой-либо их комбинации), и оно может физически
существовать как внутри, так и вне юрисдикции владельца.
Публичное облако (public cloud) — инфраструктура, предназначенная для свободного
использования широкой публикой. Публичное облако может находиться в собственности,
управлении и эксплуатации коммерческих, научных и правительственных организаций (или
какой-либо их комбинации). Публичное облако физически существует в юрисдикции
владельца — поставщика услуг.
Общественное облако (community cloud) — вид инфраструктуры, предназначенный для
использования конкретным сообществом потребителей из организаций, имеющих общие
задачи (например, миссии, требований безопасности, политики, и соответствия различным
требованиям). Общественное облако может находиться в кооперативной (совместной)
собственности, управлении и эксплуатации одной или более из организаций сообщества или
третьей стороны (или какой-либо их комбинации), и оно может физически существовать как
внутри, так и вне юрисдикции владельца.
Гибридное облако (hybrid cloud) — это комбинация из двух или более различных облачных
инфраструктур (частных, публичных или общественных), остающихся уникальными
объектами, но связанных между собой стандартизованными или частными технологиями
передачи данных и приложений (например, кратковременное использование ресурсов
публичных облаков для балансировки нагрузки между облаками).

47.

Проектирование информационных систем
Модели обслуживания облачных технологий:
Программное обеспечение как услуга (SaaS, Software-as-a-Service) — модель, в которой
потребителю предоставляется возможность использования прикладного программного
обеспечения провайдера, работающего в облачной инфраструктуре и доступного из
различных клиентских устройств или посредством тонкого клиента, например,
из браузера (например, веб-почта) или посредством интерфейса программы. Контроль и
управление основной физической и виртуальной инфраструктурой облака, в том числе сети,
серверов, операционных систем, хранения, или даже индивидуальных возможностей
приложения (за исключением ограниченного набора пользовательских настроек
конфигурации приложения) осуществляется облачным провайдером.
Платформа как услуга (PaaS, Platform-as-a-Service) — модель, когда потребителю
предоставляется возможность использования облачной инфраструктуры для размещения
базового программного обеспечения для последующего размещения на нём новых или
существующих приложений (собственных, разработанных на заказ или приобретённых
тиражируемых приложений). В состав таких платформ входят инструментальные средства
создания, тестирования и выполнения прикладного программного обеспечения — системы
управления базами данных, связующее программное обеспечение, среды исполнения
языков программирования — предоставляемые облачным провайдером.
Инфраструктура как услуга (IaaS, Infrastructure-as-a-Service) предоставляется как
возможность использования облачной инфраструктуры для самостоятельного управления
ресурсами обработки, хранения, сетями и другими фундаментальными вычислительными
ресурсами, например, потребитель может устанавливать и запускать произвольное
программное обеспечение, которое может включать в себя операционные системы,
платформенное и прикладное программное обеспечение. Потребитель может
контролировать операционные системы, виртуальные системы хранения данных и
установленные приложения, а также обладать ограниченным контролем за набором
доступных сетевых сервисов (например, межсетевым экраном, DNS). Контроль и управление
основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов,
типов используемых операционных систем, систем хранения осуществляется облачным
провайдером.

48.

Проектирование информационных систем
Традиционные и облачные технологии:

49.

Проектирование информационных систем
Модели обслуживания облачных технологий:
• Бизнес-процесс как сервис (BPaaS, Business-Process-as-a-Service): Эти
предложения представляют следующий после SaaS уровень
абстракции. Они предоставляют часть или целый бизнес-процесс, как
противоположность отдельному приложению, и могут даже
объединять вместе сервисы разных поставщиков. Компании, такие
как ADP (бухгалтерские услуги, прим. переводчика), предлагают
подобные услуги уже десятилетия. Преимущества облачной
масштабируемости и адаптации делают дальнейший рост BPaaS
интересным объектом для наблюдений. И еще, представьте себе
возможность простой смены поставщика одной из частей бизнеспроцесса на другого. Это тот тип маневренности, который BPaaS
может предоставлять в будущем.
• Данные как сервис (DaaS, Data-as-a-Service): Через веб-сервисы и
стандарты, такие как Open Data Protocol (OData), DaaS предоставляет
доступ к необработанным данным (например, к данным переписи
населения), которые приложения могут извлекать, анализировать,
визуализировать и т.д. Провайдер отвечает за качество данных, тогда
как клиент имеет доступ по требованию за приемлемую цену.
Организации могут монетизировать данные, размещая их на
облачных платформах, таких как Windows Azure Marketplace
DataMarket.

50.

Проектирование информационных систем
Облачные технологии:

51.

Проектирование информационных систем
Информационная безопасность и облачных технологий:
• Преимущества:
– Защиту обеспечивают профессионалы
– Надежность КТС выше
– Доступность информации гарантируется облаком и провайдером
Облако (информация) = Банк (финансы)
• Недостатки:
– Не владелец облака – не владелец информации.
– Нет защиты от следующего уровня иерархии (государство
принимает закон запрещающий использовать облако с
зарубежным размещением)
– Проблема финансов – проблема с ИТ (другая форма «ИТ иглы»)
• Компромисс – Частное облако:
– Нужен масштаб чтобы выпятить преимущества и нивелировать
недостатки.
– Преимущества и недостатки централизации (тот же ВЦ только на
следующем витке эволюции вычислений и связи)
– Проблема провайдера (связи) остается.

52.

Проектирование информационных систем
Основные термины и понятия:
Источник угрозы - это потенциальные антропогенные, техногенные или
стихийные носители угрозы безопасности.
Угроза (действие) [Threat]- это возможная опасность (потенциальная или
реально существующая) совершения какого-либо деяния (действия или
бездействия), направленного против объекта защиты (информационных
ресурсов), наносящего ущерб собственнику, владельцу или
пользователю, проявляющегося в опасности искажения и потери
информации.
Фактор (уязвимость) [Vulnerability]- это присущие объекту
информатизации причины, приводящие к нарушению безопасности
информации на конкретном объекте и обусловленные недостатками
процесса функционирования объекта информатизации, свойствами
архитектуры автоматизированной системы, протоколами обмена и
интерфейсами, применяемыми программным обеспечением и
аппаратной платформой, условиями эксплуатации.
Последствия (атака) - это возможные последствия реализации угрозы
(возможные действия) при взаимодействии источника угрозы через
имеющиеся факторы (уязвимости).

53.

Проектирование информационных систем
Классификация угроз информационной безопасности:
По аспекту информационной безопасности, на который направлены угрозы:
– Угрозы конфиденциальности (неправомерный доступ к информации).
– Угрозы целостности (неправомерное изменение данных).
– Угрозы доступности (осуществление действий, делающих невозможным или
затрудняющих доступ к ресурсам информационной системы).
По степени преднамеренности действий:
– Случайные (неумышленные действия, например, сбои в работе систем, стихийные
бедствия).
– Преднамеренные (умышленные действия, например, шпионаж и диверсии).
По расположению источника угроз:
– Внутренние (источники угроз располагаются внутри системы).
– Внешние (источники угроз находятся вне системы).
По размерам наносимого ущерба:
– Общие (нанесение ущерба объекту безопасности в целом, причинение значительного
ущерба).
– Локальные (причинение вреда отдельным частям объекта безопасности).
– Частные (причинение вреда отдельным свойствам элементов объекта безопасности).
По степени воздействия на информационную систему:
– Пассивные (структура и содержание системы не изменяются).
– Активные (структура и содержание системы подвергается изменениям).

54.

Проектирование информационных систем
Проявления возможного ущерба ИБ:
• моральный и материальный ущерб деловой репутации
организации;
• моральный, физический или материальный ущерб, связанный с
разглашением персональных данных отдельных лиц;
• материальный (финансовый) ущерб от разглашения
защищаемой (конфиденциальной) информации;
• материальный (финансовый) ущерб от необходимости
восстановления нарушенных защищаемых информационных
ресурсов;
• материальный ущерб (потери) от невозможности выполнения
взятых на себя обязательств перед третьей стороной;
• моральный и материальный ущерб от дезорганизации
деятельности организации;
• материальный и моральный ущерб от нарушения
международных отношений.

55.

Проектирование информационных систем
Преступления, определяемых УК РФ относящиеся к ИБ:
Хищение - совершенные с корыстной целью противоправные безвозмездное изъятие и (или)
обращение чужого имущества в пользу виновного или других лиц, причинившее ущерб
собственнику или владельцу имущества.
Копирование компьютерной информации - повторение и устойчивое запечатление
информации на машинном или ином носителе.
Уничтожение - внешнее воздействие на имущество, в результате которого оно прекращает
свое физическое существование либо приводятся в полную непригодность для использования
по целевому назначению. Уничтоженное имущество не может быть восстановлено путем
ремонта или реставрации и полностью выводится из хозяйственного оборота
Уничтожение компьютерной информации - стирание ее в памяти ЭВМ.
Повреждение - изменение свойств имущества при котором существенно ухудшается его
состояние, утрачивается значительная часть его полезных свойств и оно становится полностью
или частично непригодным для целевого использования.
Модификация компьютерной информации - внесение любых изменений, кроме связанных
с адаптацией программы для ЭВМ или баз данных.
Блокирование компьютерной информации - искусственное затруднение доступа
пользователей к информации, не связанное с ее уничтожением.
Несанкционированное уничтожение, блокирование модификация, копирование
информации - любые не разрешенные законом, собственником или компетентным
пользователем указанные действия с информацией.
Обман (отрицание подлинности, навязывание ложной информации) - умышленное
искажение или сокрытие истины с целью ввести в заблуждение лицо, в ведении которого
находится имущество и таким образом добиться от него добровольной передачи имущества,
а также сообщение с этой целью заведомо ложных сведений.

56.

Проектирование информационных систем
Виды мер противодействия угрозам безопасности:
• Правовые (законодательные)
К правовым мерам защиты относятся действующие в стране законы, указы и другие нормативноправовые акты, регламентирующие правила обращения с информацией, закрепляющие права и
обязанности участников информационных отношений в процессе ее получения, обработки и
использования, а также устанавливающие ответственность за нарушения этих правил, препятствуя
тем самым неправомерному использованию информации и являющиеся сдерживающим
фактором для потенциальных нарушителей. Правовые меры защиты носят в основном
упреждающий, профилактический характер и требуют постоянной разъяснительной работы с
пользователями и обслуживающим персоналом системы.
• Морально-этические
К морально-этическим мерам защиты относятся нормы поведения, которые традиционно
сложились или складываются по мере распространения информационных технологий в обществе.
Эти нормы большей частью не являются обязательными, как требования нормативных актов,
однако, их несоблюдение ведет обычно к падению авторитета или престижа человека, группы
лиц или организации. Морально-этические нормы бывают как неписаные (например,
общепризнанные нормы честности, патриотизма и т.п.), так и писаные, то есть оформленные в
некоторый свод (устав, кодекс чести и т.п.) правил или предписаний. Морально-этические меры
защиты являются профилактическими и требуют постоянной работы по созданию здорового
морального климата в коллективах пользователей и обслуживающего персонала АС.
• Технологические
К данному виду мер защиты относятся разного рода технологические решения и приемы,
основанные обычно на использовании некоторых видов избыточности (структурной,
функциональной, информационной, временной и т.п.) и направленные на уменьшение
возможности совершения сотрудниками ошибок и нарушений в рамках предоставленных им прав
и полномочий. Примером таких мер является использование процедур двойного ввода
ответственной информации, инициализации ответственных операций только при наличии
разрешений от нескольких должностных лиц, процедур проверки соответствия реквизитов
исходящих и входящих сообщении в системах коммутации сообщений, периодическое
подведение общего баланса всех банковских счетов и т.п.

57.

Проектирование информационных систем
Виды мер противодействия угрозам безопасности:
• Организационные
Организационные меры зашиты - это меры административного и процедурного
характера, регламентирующие процессы функционирования системы обработки
данных, использование ее ресурсов, деятельность обслуживающего персонала, а
также порядок взаимодействия пользователей и обслуживающего персонала с
системой таким образом, чтобы в наибольшей степени затруднить или
исключить возможность реализации угроз безопасности или снизить размер
потерь в случае их реализации.
• Меры физической защиты
Физические меры защиты основаны на применении разного рода механических,
электро-или электронно-механических устройств и сооружений, специально
предназначенных для создания физических препятствий на возможных путях
проникновения и доступа потенциальных нарушителей к компонентам системы и
защищаемой информации, а также средств визуального наблюдения, связи и
охранной сигнализации. К данному типу относятся также меры и средства
контроля физической целостности компонентов АС (пломбы, наклейки и т.п.).
• Технические
Технические меры защиты основаны на использовании различных электронных
устройств и специальных программ, входящих в состав АС и выполняющих
(самостоятельно или в комплексе с другими средствами) функции защиты.

58.

Проектирование информационных систем
Основные механизмы защиты компьютерных систем:
Идентификация (именование и опознавание), аутентификация
(подтверждение подлинности) пользователей системы;
Разграничение доступа пользователей к ресурсам системы и авторизация
(присвоение полномочий) пользователям;
Регистрация и оперативное оповещение о событиях, происходящих в системе;
(аудит)
Криптографическое закрытие хранимых и передаваемых по каналам связи
данных;
Контроль целостности и аутентичности (подлинности и авторства) данных;
выявление и нейтрализация действий компьютерных вирусов;
Затирание остаточной информации на носителях;
Выявление уязвимостей (слабых мест) системы;
Изоляция (защита периметра) компьютерных сетей (фильтрация трафика,
скрытие внутренней структуры и адресации, противодействие атакам на
внутренние ресурсы и т.д.);
Обнаружение атак и оперативное реагирование.
Резервное копирование
Маскировка.

59.

Проектирование информационных систем
Формальные модели безопасности (модель Диона):
• Метки безопасности субъекта:
– абсолютная метка конфиденциальности (ACL) присваивается субъекту
во время создания и остается постоянной во все время его
существования. Обычно в качестве ACL используется метка пользователяинициатора процесса;
– метка конфиденциальности чтения (RCL) - максимальный (в смысле
отношения доминирования меток) уровень конфиденциальности, с
которого субъекту разрешено читать информацию;
– метка конфиденциальности записи (WCL) - минимальный уровень
конфиденциальности, на который субъекту разрешено записывать
информацию;
– абсолютная метка целостности (AIL);
– метка целостности чтения (RIL) - минимальный уровень целостности, с
которого субъекту разрешено читать информацию;
– метка целостности записи (WIL) - максимальный уровень целостности, на
который субъекту разрешено записывать информацию.
• Для каждого субъекта s должны выполняться следующие
соотношения:
WCL(s) <= ACL(s) <= RCL(s)
RIL(s) <= AIL(s) <= WIL(s)

60.

Проектирование информационных систем
Формальные модели безопасности (модель Диона):
• Метки безопасности объекта:
– абсолютная метка конфиденциальности (ACL) присваивается объекту во
время создания и остается постоянной на все время его существования.
Характеризует конфиденциальность данных, хранящихся в объекте;
– метка конфиденциальности чтения из объекта (RCL) - максимальный
уровень конфиденциальности, на который могут мигрировать данные,
хранящиеся в объекте;
– метка конфиденциальности записи в объект (WCL) - минимальный
уровень конфиденциальности, с которого данные могут записываться в
объект;
– абсолютная метка целостности (AIL);
– метка целостности чтения из объекта (RIL) - минимальный уровень
целостности, на который могут мигрировать данные, хранящиеся в
объекте;
– метка целостности записи в объект (WIL) - максимальный уровень
целостности, с которого данные могут записываться в объект.
• Для каждого объекта o должны выполняться следующие
соотношения:
WCL(o) <= ACL(o) <= RCL(o)
RIL(o) <= AIL(o) <= WIL(o)

61.

Проектирование информационных систем
Экономика ИБ:
• Соотношение средства на защиту - ущерб.
• Оптимизация затрат на безопасность.
• «Паранойя» безопасности – путь к возможным
убыткам.
• Разделение информации по ИБ признаку:
– Защищаемая государством и законом.
– Коммерческая тайна.
– ДСП и другие уровни.
• Профиль затрат на ИБ
– приобретение (разовые)
– периодические (ЗП, платежи, страховки)
– экстренный фонд

62.

Проектирование
информационных систем
к.т.н., доцент
Набатов Александр Нурович
6-224

63.

64.

65.

66.

Проектирование информационных систем
Классификация информационных систем

67.

Проектирование информационных систем
Классификация информационных систем
Подсистема
маркетинга
Производственные
подсистемы
Исследование
рынка и
прогнозирование
продаж
Планирование
объемов работ и
разработка
календарных
планов
Управление
продажами
Оперативный
контроль и
управление
производством
Финансовые и
Подсистема кадров Прочие подсистемы
учетные
(человеческих
(например, ИС
подсистемы
ресурсов)
руководства)
Управление
Анализ и
Контроль за
портфелем заказов прогнозирование деятельностью фирмы
потребности в
трудовых ресурсах
Управление
кредитной
политикой
Ведение архивов
записей о
персонале
Выявление оперативных
проблем
Рекомендации по Анализ
Разработка
Анализ и
Анализ управленческих
производству новой работы оборудован финансового плана планирование
и стратегических
продукции
ия
подготовки кадров ситуаций
Анализ и
Участие в
установление цены формировании
заказов
поставщикам
Финансовый
анализ и
прогнозирование
Учет заказов
Контроль бюджета,
бухгалтерский учет
и расчет зарплаты
Управление
запасами
Обеспечение процесса
выработки
стратегических решений

68.

Проектирование информационных систем
Классификация информационных систем
Локальные
системы
Малые
Средние
Крупные
интегрированные интегрированные интегрированные Локальные системы
системы
системы
системы (IC)
•БЭСТ
•Concorde
•Microsoft•SAP/R3 (SAP AG)
•Инотек
XAL Exact
Business Solutions •Baan (Baan)
•Инфософт
•NS-2000 Platinum - Navision, Axapta •BPCS (ITS/SSA)
•СуперPRO/MIS
•J D Edwards
•OEBS (Oracle EМенеджер
•Scala SunSystems (Robertson &
Business Suite)
•Турбо-Бухгалтер •БЭСТ-ПРО
Blums)
•Инфо-Бухгалтер •1C-Предприятие •MFG-Pro
•БОСС(QAD/BMS)
Корпорация
•SyteLine
•Галактика
(COKAП/SYMIX)
•Парус
•Ресурс
•Эталон
•БЭСТ
•Инотек
•Инфософт
•Супер-Менеджер
•Турбо-Бухгалтер
•Инфо-Бухгалтер

69.

70.

Проектирование информационных систем
Методологии проектирования
Цель методологии проектирования заключается в регламентации
процесса проектирования ИС и обеспечении управления этим процессом с тем,
чтобы гарантировать выполнение требований как к самой ИС, так и к
характеристикам процесса разработки. Основными задачами, решению которых
должна способствовать методология проектирования корпоративных ИС,
являются следующие:
• обеспечивать создание корпоративных ИС, отвечающих целям и задачам
организации, а также предъявляемым требованиям по автоматизации
деловых процессов заказчика;
• гарантировать создание системы с заданным качеством в заданные сроки и в
рамках установленного бюджета проекта;
• поддерживать удобную дисциплину сопровождения, модификации и
наращивания системы;
• обеспечивать преемственность разработки, т.е. использование в
разрабатываемой ИС существующей информационной инфраструктуры
организации (задела в области информационных технологий).
Внедрение методологии должно приводить к снижению сложности
процесса создания ИС за счет полного и точного описания этого процесса, а
также применения современных методов и технологий создания ИС на всем
жизненном цикле ИС - от замысла до реализации.

71.

Проектирование информационных систем
Методологии проектирования
Проектирование
информационной
системы охватывает три основные области:
• проектирование объектов данных, которые будут
реализованы в базе данных;
• проектирование программ, экранных форм,
отчетов, которые будут обеспечивать выполнение
запросов к данным;
• учет конкретной среды или технологии, а именно:
топологии сети, конфигурации аппаратных
средств, используемой архитектуры (файлсервер
или
клиент-сервер),
параллельной
обработки, распределенной обработки данных и
т.п.

72.

Проектирование информационных систем
Методологии проектирования
Проектирование информационных систем всегда
начинается с определения цели проекта. В общем виде
цель проекта можно определить как решение ряда
взаимосвязанных задач, включающих в себя обеспечение
на момент запуска системы и в течение всего времени ее
эксплуатации:
• требуемой функциональности системы и уровня ее
адаптивности
к
изменяющимся
условиям
функционирования;
• требуемой пропускной способности системы;
• требуемого времени реакции системы на запрос;
• безотказной работы системы;
• необходимого уровня безопасности;
• простоты эксплуатации и поддержки системы.

73.

Проектирование информационных систем
Методологии проектирования
Процесс создания ИС делится на ряд этапов,
ограниченных некоторыми временными рамками и
заканчивающихся выпуском конкретного продукта
(моделей, программных продуктов, документации и
пр.).
Обычно выделяют следующие этапы создания ИС:
• формирование требований к системе,
• проектирование,
• реализация,
• тестирование,
• внедрение

74.

Проектирование информационных систем
Методологии проектирования
Начальным этапом процесса создания ИС является моделирование бизнеспроцессов, протекающих в организации и реализующих ее цели и задачи. Модель
организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет
сформулировать основные требования к ИС. Это фундаментальное положение
методологии обеспечивает объективность в выработке требований к проектированию
системы. Множество моделей описания требований к ИС затем преобразуется в
систему моделей, описывающих концептуальный проект ИС. Формируются модели
архитектуры ИС, требований к программному обеспечению (ПО) и информационному
обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются
корпоративные БД и отдельные приложения, формируются модели требований к
приложениям и проводится их разработка, тестирование и интеграция.
Целью начальных этапов создания ИС, выполняемых на стадии анализа
деятельности организации, является формирование требований к ИС, корректно и
точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать
процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко
сформулировать, в чем заключаются эти потребности. Для этого необходимо
определить требования заказчиков к ИС и отобразить их на языке моделей в
требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и
задачам организации.

75.

76.

Проектирование информационных систем
Методологии проектирования
Задача формирования требований к ИС является одной из наиболее
ответственных, трудно формализуемых и наиболее дорогих и тяжелых для
исправления в случае ошибки. Современные инструментальные средства и
программные продукты позволяют достаточно быстро создавать ИС по
готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков,
требуют многочисленных доработок, что приводит к резкому удорожанию
фактической стоимости ИС. Основной причиной такого положения является
неправильное, неточное или неполное определение требований к ИС на этапе
анализа.
На этапе проектирования прежде всего формируются модели данных.
Проектировщики в качестве исходной информации получают результаты
анализа. Построение логической и физической моделей данных является
основной частью проектирования базы данных. Полученная в процессе
анализа информационная модель сначала преобразуется в логическую, а
затем в физическую модель данных.

77.

Проектирование информационных систем
Методологии проектирования
Параллельно с проектированием схемы базы данных выполняется
проектирование процессов, чтобы получить спецификации (описания) всех
модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть
бизнес-логики обычно реализуется в базе данных (ограничения, триггеры,
хранимые процедуры). Главная цель проектирования процессов заключается в
отображении функций, полученных на этапе анализа, в модули
информационной системы. При проектировании модулей определяют
интерфейсы программ: разметку меню, вид окон, горячие клавиши и
связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
• схема базы данных (на основании ER-модели, разработанной на этапе
анализа);
• набор спецификаций модулей системы (они строятся на базе моделей
функций).

78.

Проектирование информационных систем
Методологии проектирования
Кроме того, на этапе проектирования осуществляется также
разработка архитектуры ИС, включающая в себя выбор платформы (платформ)
и операционной системы (операционных систем). В неоднородной ИС могут
работать несколько компьютеров на разных аппаратных платформах и под
управлением различных операционных систем. Кроме выбора платформы, на
этапе проектирования определяются следующие характеристики архитектуры:
• будет ли это архитектура "файл-сервер" или "клиент-сервер";
• будет ли это 2/3/4-уровневая архитектура;
• будет ли база данных централизованной или распределенной;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных
продуктами одного и того же производителя;
• будут ли для достижения должной производительности использоваться
параллельные серверы баз данных (например, Oracle Parallel Server, DB2
UDB и т.п.).
Этап проектирования завершается разработкой технического проекта ИС.

79.

Проектирование информационных систем
Каноническое проектирование ИС
Организация канонического проектирования ИС ориентирована на
использование главным образом каскадной модели жизненного цикла ИС.
Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
В зависимости от сложности объекта автоматизации и набора задач,
требующих решения при создании конкретной ИС, стадии и этапы работ могут
иметь различную трудоемкость.
Стадии и этапы создания ИС, выполняемые организациямиучастниками, прописываются в договорах и технических заданиях на
выполнение работ:
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
• обследование объекта и обоснование необходимости создания ИС;
• формирование требований пользователей к ИС;
• оформление отчета о выполненной работе и тактико- технического задания
на разработку.

80.

Проектирование информационных систем
Каноническое проектирование ИС
Стадия 2. Разработка концепции ИС.
• изучение объекта автоматизации;
• проведение необходимых научно-исследовательских работ;
• разработка вариантов концепции ИС, удовлетворяющих требованиям
пользователей;
• оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
• разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
• разработка предварительных проектных решений по системе и ее частям;
• разработка эскизной документации на ИС и ее части.

81.

Проектирование информационных систем
Каноническое проектирование ИС
Стадия 5. Технический проект.
• разработка проектных решений по системе и ее частям;
• разработка документации на ИС и ее части;
• разработка и оформление документации на поставку комплектующих
изделий;
• разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
• разработка рабочей документации на ИС и ее части;
• разработка и адаптация программ.
Стадия 7. Внедрение.
Стадия 8. Сопровождение/эксплуатация ИС.
Стадия 9. Вывод из эксплуатации.

82.

Проектирование информационных систем
Каноническое проектирование ИС
Технико-экономическое обоснование проекта это документ, где четко
сформулировано, что получит заказчик, если согласится финансировать проект,
когда он получит готовый продукт (график выполнения работ) и сколько это
будет
стоить
(для
крупных
проектов
должен
быть
составлен график финансирования на разных этапах работ).
Ориентировочное содержание этого документа:
ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
совокупность условий, при которых предполагается эксплуатировать будущую систему:
архитектура системы, аппаратные и программные ресурсы, условия функционирования,
обслуживающий персонал и пользователи системы;
сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы,
меры по защите информации;
описание выполняемых системой функций;
возможности развития системы;
информационные объекты системы;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам ПО, требования к СУБД;
что не будет реализовано в рамках проекта.

83.

Проектирование информационных систем
Каноническое проектирование ИС
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
функции - информация о событиях и процессах, которые происходят в бизнесе;
сущности - информация о вещах, имеющих значение для организации и о которых что-то
известно.
При изучении каждой функциональной задачи управления определяются:
наименование задачи; сроки и периодичность ее решения;
степень формализуемости задачи;
источники информации, необходимые для решения задачи;
показатели и их количественные характеристики;
порядок корректировки информации;
действующие алгоритмы расчета показателей и возможные методы контроля;
действующие средства сбора, передачи и обработки информации;
действующие средства связи;
принятая точность решения задачи;
трудоемкость решения задачи;
действующие формы представления исходных данных и результатов их обработки в виде
документов;
потребители результатной информации по задаче.

84.

Проектирование информационных систем
Каноническое проектирование ИС
Одной из наиболее трудоемких, хотя и хорошо формализуемых задач
этого этапа является описание документооборота организации. При
обследовании документооборота составляется схема маршрута движения
документов, которая должна отразить:
• количество документов;
• место формирования показателей документа;
• взаимосвязь документов при их формировании;
• маршрут и длительность движения документа;
• место использования и хранения данного документа;
• внутренние и внешние информационные связи;
• объем документа в знаках.
По результатам обследования устанавливается перечень задач
управления, решение которых целесообразно автоматизировать, и
очередность их разработки.

85.

Проектирование информационных систем
Каноническое проектирование ИС
На этапе обследования следует классифицировать планируемые
функции системы по степени важности. Один из возможных форматов
представления такой классификации - MuSCoW.
Эта аббревиатура расшифровывается так:
• Must have - необходимые функции;
• Should have - желательные функции;
• Could have - возможные функции;
• Won't have - отсутствующие функции.
Функции первой категории обеспечивают критичные для успешной
работы системы возможности.
Реализация функций второй и третьей категорий ограничивается
временными и финансовыми рамками: разрабатывается то, что необходимо, а
также максимально возможное в порядке приоритета число функций второй и
третьей категорий.
Последняя категория функций особенно важна, поскольку необходимо
четко представлять границы проекта и набор функций, которые будут
отсутствовать в системе.

86.

Проектирование информационных систем
Каноническое проектирование ИС
Модели деятельности организации создаются в двух видах:
• модель "как есть" ("as-is")- отражает существующие в организации бизнеспроцессы;
• модель "как должно быть" ("to-be") - отражает необходимые изменения
бизнес-процессов с учетом внедрения ИС.
На этапе анализа необходимо привлекать к работе группы
тестирования для решения следующих задач:
• получения сравнительных характеристик предполагаемых к использованию
аппаратных платформ, операционных систем, СУБД, иного окружения;
• разработки плана работ по обеспечению надежности информационной
системы и ее тестирования.
Привлечение тестировщиков на ранних этапах разработки является
целесообразным. Если проектное решение оказалось неудачным и это
обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе
внедрения в эксплуатацию), то исправление ошибки проектирования
обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в
информационной системе, тем ниже стоимость сопровождения системы.

87.

Проектирование информационных систем
Каноническое проектирование ИС
Техническое задание - это документ, определяющий цели, требования
и
основные
исходные
данные,
необходимые
для
разработки
автоматизированной системы управления.
При разработке технического задания необходимо решить следующие
задачи:
• установить общую цель создания ИС, определить состав подсистем и
функциональных задач;
• разработать и обосновать требования, предъявляемые к подсистемам;
• разработать и обосновать требования, предъявляемые к информационной
базе, математическому и программному обеспечению, комплексу
технических средств (включая средства связи и передачи данных);
• установить общие требования к проектируемой системе;
• определить перечень задач создания системы и исполнителей;
• определить этапы создания системы и сроки их выполнения;
• провести предварительный расчет затрат на создание системы и
определить уровень экономической эффективности ее внедрения.

88.

Проектирование информационных систем
Типовые требования к составу и содержанию технического задания
№
п\
Раздел
п
1 Общие сведения
Содержание
•полное наименование системы и ее условное обозначение
•шифр темы или шифр (номер) договора;
•наименование предприятий разработчика и заказчика системы,
их реквизиты
•перечень документов, на основании которых создается ИС
•плановые сроки начала и окончания работ
•сведения об источниках и порядке финансирования работ
•порядок оформления и предъявления заказчику результатов
работ по созданию системы, ее частей и отдельных средств
2 Назначение и цели •вид автоматизируемой деятельности
создания (развития) •перечень объектов, на которых предполагается использование
системы
системы
•наименования и требуемые значения технических,
технологических, производственно-экономических и др.
показателей объекта, которые должны быть достигнуты при
внедрении ИС

89.

Проектирование информационных систем
Типовые требования к составу и содержанию технического задания
№
п\
Раздел
п
3 Характеристика
объектов
автоматизации
4 Требования к
системе
Содержание
•краткие сведения об объекте автоматизации
•сведения об условиях эксплуатации и характеристиках
окружающей среды
Требования к системе в целом:
•требования к структуре и функционированию системы
(перечень подсистем, уровни иерархии, степень
централизации, способы информационного обмена, режимы
функционирования, взаимодействие со смежными системами,
перспективы развития системы)
•требования к персоналу (численность пользователей,
квалификация, режим работы, порядок подготовки)
•показатели назначения (степень приспособляемости системы к
изменениям процессов управления и значений параметров)
•требования к надежности, безопасности, эргономике,
транспортабельности, эксплуатации, техническому
обслуживанию и ремонту, защите и сохранности информации,
защите от внешних воздействий, к патентной чистоте, по
стандартизации и унификации

90.

Проектирование информационных систем
Типовые требования к составу и содержанию технического задания
№
п\
Раздел
п
4 Требования к
системе
Содержание
Требования к функциям (по подсистемам) :
•перечень подлежащих автоматизации задач
•временной регламент реализации каждой функции
•требования к качеству реализации каждой функции, к форме
представления выходной информации, характеристики
точности, достоверности выдачи результатов
•перечень и критерии отказов

91.

Проектирование информационных систем
Типовые требования к составу и содержанию технического задания
№
п\
Раздел
п
4 Требования к
системе
Содержание
Требования к видам обеспечения:
•математическому (состав и область применения мат. моделей и
методов, типовых и разрабатываемых алгоритмов)
•информационному (состав, структура и организация данных,
обмен данными между компонентами системы,
информационная совместимость со смежными системами,
используемые классификаторы, СУБД, контроль данных и
ведение информационных массивов, процедуры придания
юридической силы выходным документам)
•программному (независимость программных средств от
платформы, качество программных средств и способы его
контроля, использование фондов алгоритмов и программ)
•организационному (структура и функции эксплуатирующих
подразделений, защита от ошибочных действий персонала)
•методическому (состав нормативно-технической документации)

92.

Проектирование информационных систем
Типовые требования к составу и содержанию технического задания
№
п\
Раздел
Содержание
п
5 Состав и содержание •перечень стадий и этапов работ
работ по созданию •сроки исполнения
системы
•состав организаций — исполнителей работ
•вид и порядок экспертизы технической документации
•программа обеспечения надежности
•программа метрологического обеспечения
6 Порядок контроля и •виды, состав, объем и методы испытаний системы
приемки системы
•общие требования к приемке работ по стадиям
•статус приемной комиссии

93.

Проектирование информационных систем
Типовые требования к составу и содержанию технического задания
№
п\
Раздел
Содержание
п
7 Требования к составу •преобразование входной информации к машиночитаемому
и содержанию работ виду
по подготовке
•изменения в объекте автоматизации
объекта
•сроки и порядок комплектования и обучения персонала
автоматизации к
вводу системы в
действие
8 Требования к
•перечень подлежащих разработке документов
документированию •перечень документов на машинных носителях
9 Источники
документы и информационные материалы, на основании
разработки
которых разрабатывается ТЗ и система

94.

Проектирование информационных систем
Каноническое проектирование ИС
Эскизный проект предусматривает разработку предварительных
проектных решений по системе и ее частям.
Выполнение стадии эскизного проектирования не является строго
обязательной. Если основные проектные решения определены ранее или
достаточно очевидны для конкретной ИС и объекта автоматизации, то эта
стадия может быть исключена из общей последовательности работ.
Содержание эскизного проекта задается в ТЗ на систему. Как правило,
на этапе эскизного проектирования определяются:
• функции ИС;
• функции подсистем, их цели и ожидаемый эффект от внедрения;
• состав комплексов задач и отдельных задач;
• концепция информационной базы и ее укрупненная структура;
• функции системы управления базой данных;
• состав вычислительной системы и других технических средств;
• функции и параметры основных программных средств.

95.

Проектирование информационных систем
Каноническое проектирование ИС
На основе технического задания (и эскизного проекта)
разрабатывается технический проект ИС. Технический проект системы - это
техническая документация, содержащая общесистемные проектные решения,
алгоритмы решения задач, а также оценку экономической эффективности
автоматизированной системы управления и перечень мероприятий по
подготовке объекта к внедрению.
На этом этапе осуществляется комплекс научно-исследовательских и
экспериментальных работ для выбора основных проектных решений и расчет
экономической эффективности системы.

96.

Проектирование информационных систем
Состав и содержание технического проекта
№
п\
Раздел
п
1 Пояснительная
записка
2 Функциональная и
организационная
структура системы
Содержание
•основания для разработки системы
•перечень организаций разработчиков
•краткая характеристика объекта с указанием
основных технико-экономических показателей его
функционирования и связей с другими объектами
•краткие сведения об основных проектных решениях по
функциональной и обеспечивающим частям системы
•обоснование выделяемых подсистем, их перечень и
назначение
•перечень задач, решаемых в каждой подсистеме, с краткой
характеристикой их содержания
•схема информационных связей между подсистемами и между
задачами в рамках каждой подсистемы

97.

Проектирование информационных систем
Состав и содержание технического проекта
№
п\
Раздел
Содержание
п
3 Постановка задач и •организационно-экономическая сущность задачи
алгоритмы решения •экономико-математическая модель задачи
•входная оперативная информация
•нормативно-справочная информация ( НСИ)
•информация, хранимая для связи с другими задачами
•информация, накапливаемая для последующих решений
данной задачи
•информация по внесению изменений
•алгоритм решения задачи
•контрольный пример

98.

Проектирование информационных систем
Состав и содержание технического проекта
№
п\
Раздел
п
4 Организация
информационной
базы
Содержание
•источники поступления информации и способы ее передачи
•совокупность показателей, используемых в системе
•состав документов, сроки и периодичность их поступления
•основные проектные решения по организации фонда НСИ
•состав НСИ, включая перечень реквизитов, их определение,
диапазон изменения и перечень документов НСИ
•перечень массивов НСИ, их объем, порядок и частота
корректировки информации
•структура фонда НСИ с описанием связи между его
элементами; требования к технологии создания и ведения
фонда
•методы хранения, поиска, внесения изменений и контроля
•определение объемов и потоков информации НСИ
•контрольный пример по внесению изменений в НСИ
•предложения по унификации документации

99.

Проектирование информационных систем
Состав и содержание технического проекта
№
п\
Раздел
Содержание
п
5 Альбом форм
документов
6 Система
•обоснование структуры математического обеспечения
математического
•обоснование выбора системы программирования
обеспечения
•перечень стандартных программ
7 Принцип
•описание и обоснование схемы технологического процесса
построения
обработки данных
комплекса
•обоснование и выбор структуры комплекса технических
технических средств средств и его функциональных групп
•обоснование требований к разработке нестандартного
оборудования
•комплекс мероприятий по обеспечению надежности
функционирования технических средств

100.

Проектирование информационных систем
Состав и содержание технического проекта
№
п\
Раздел
п
8 Расчет
экономической
эффективности
системы
Содержание
•сводная смета затрат, связанных с эксплуатацией систем
•расчет годовой экономической эффективности, источниками
которой являются оптимизация производственной структуры
хозяйства (объединения), снижение себестоимости продукции
за счет рационального использования производственных
ресурсов и уменьшения потерь, улучшения принимаемых
управленческих решений
9 Мероприятия по
•перечень организационных мероприятий по
подготовке объекта совершенствованию бизнес-процессов
к внедрению
•перечень работ по внедрению системы, которые необходимо
системы
выполнить на стадии рабочего проектирования, с указанием
сроков и ответственных лиц
10 Ведомость
документов

101.

Проектирование информационных систем
Типовое проектирование ИС
Типовое проектирование ИС предполагает создание системы из готовых
типовых элементов. Основополагающим требованием для применения методов
типового проектирования является возможность декомпозиции проектируемой ИС на
множество составляющих компонентов (подсистем, комплексов задач, программных
модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на
рынке типовые проектные решения, которые настраиваются на особенности
конкретного предприятия.
Типовое проектное решение (ТПР) - это тиражируемое (пригодное к
многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются
следующие классы ТПР:
• элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения
задачи (информационному, программному, техническому, математическому,
организационному);
• подсистемные ТПР - в качестве элементов типизации выступают отдельные
подсистемы, разработанные с учетом функциональной полноты и минимизации
внешних информационных связей;
• объектные ТПР - типовые отраслевые проекты, которые включают полный набор
функциональных и обеспечивающих подсистем ИС.

102.

Проектирование информационных систем
Типовое проектирование ИС
Класс ТПР
Достоинства
Реализация ТПР
Элементные
•обеспечивается применение модульного подхода к
ТПР
проектированию и документированию ИС
Библиотеки
методоориентированных
программ
Недостатки
•большие затраты времени на сопряжение разнородных
элементов вследствие информационной, программной и
технической несовместимости
•большие затраты времени на доработку ТПР отдельных
элементов
Подсистемные
ТПР
Пакеты
прикладных
программ
•достигается высокая степень интеграции элементов ИС •адаптивность ТПР недостаточна с позиции непрерывного
•позволяют осуществлять: модульное проектирование; инжиниринга деловых процессов
параметрическую настройку программных компонентов •возникают проблемы в комплексировании разных
на различные объекты управления
функциональных подсистем, особенно в случае
•обеспечивают: сокращение затрат на проектирование и использования решений нескольких производителей
программирование взаимосвязанных компонентов;
программного обеспечения
хорошее документирование отображаемых процессов
обработки информации
Объектные ТПР
Отраслевые
проекты ИС
•комплексирование всех компонентов ИС за счет
методологического единства и информационной,
программной и технической совместимости
•открытость архитектуры — позволяет
устанавливать ТПР на разных программно-технических
платформах
•масштабируемость — допускает конфигурацию ИС для
переменного числа рабочих мест
•конфигурируемость — позволяет выбирать
необходимое подмножество компонентов
•проблемы привязки типового проекта к конкретному
объекту управления, что вызывает в некоторых случаях
даже необходимость изменения организационноэкономической структуры объекта автоматизации

103.

Проектирование информационных систем
Шаблон потокового процессного описания

104.

Проектирование информационных систем
Организационно-функциональной модель компании

105.

Проектирование информационных систем
Двухуровневая модель деятельности предприятия

106.

Проектирование информационных систем
Цикл управления ресурсами
В основе цикла управления ресурсами лежит расчет или имитационное
моделирование и контроль результатов:
• выбор (или получение от системы верхнего уровня) целевого критерия оценки
качества решения;
• сбор информации о ресурсах предприятия или возможностях внешней среды;
• просчет вариантов (с различными предположениями о возможных значениях
параметров);
• выбор оптимального варианта — принятие решения (= ресурсного плана);
• учет результатов (и отчетность);
• сравнение с принятым критерием оценки ( = контроль результатов);
• анализ причин отклонений и регулирование (возврат к 1, 2 или 3).

107.

Проектирование информационных систем
Цикл организационного менеджмента
В основе цикла организационного менеджмента лежит структурное или
процессное моделирование и процедурный контроль:
• определение состава задач (обособленных функций, операций);
• выбор исполнителей (- распределение зон и степени ответственности);
• проектирование процедур (последовательности и порядка исполнения);
• согласование и утверждение регламента исполнения (- процесса, плана
мероприятий);
• отчетность об исполнении;
• контроль исполнения (- процедурный контроль);
• анализ причин отклонений и регулирование (возврат к 1, 2 или 3).

108.

Проектирование информационных систем
Структурная модель предметной области
В основе проектирования ИС лежит моделирование предметной области. Для
того чтобы получить адекватный предметной области проект ИС в виде системы
правильно работающих программ, необходимо иметь целостное, системное
представление модели, которое отражает все аспекты функционирования будущей
информационной системы. При этом под моделью предметной области понимается
некоторая система, имитирующая структуру или функционирование исследуемой
предметной области и отвечающая основному требованию – быть адекватной этой
области.
К моделям предметных областей предъявляются следующие требования:
• формализация, обеспечивающая однозначное описание структуры предметной
области;
• понятность для заказчиков и разработчиков на основе применения графических
средств отображения модели;
• реализуемость, подразумевающая наличие средств физической реализации модели
предметной области в ИС;
• обеспечение оценки эффективности реализации модели предметной области на
основе определенных методов и вычисляемых показателей.

109.

Проектирование информационных систем
Структурная модель предметной области
Структурный аспект предполагает построение:
• объектной структуры, отражающей состав взаимодействующих в процессах
материальных и информационных объектов предметной области;
• функциональной структуры, отражающей взаимосвязь функций (действий) по
преобразованию объектов в процессах;
• структуры управления, отражающей события и бизнес-правила, которые
воздействуют на выполнение процессов;
• организационной структуры, отражающей взаимодействие организационных
единиц предприятия и персонала в процессах;
• технической структуры, описывающей топологию расположения и способы
коммуникации комплекса технических средств.
Такая система моделей отражает структурный и оценочный аспекты
функционирования предметной области.
Главный критерий адекватности структурной модели предметной
области заключается в функциональной полноте разрабатываемой ИС.

110.

Проектирование информационных систем
Функционально-ориентированные и объектноориентированные методологии описания предметной
области
Функциональная методика IDEF0
В основе методологии лежат четыре основных понятия: функциональный
блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую
конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта
название каждого функционального блока должно быть сформулировано в глагольном
наклонении.
Интерфейсная дуга (Arrow) отображает элемент системы, который
обрабатывается функциональным блоком или оказывает иное влияние на функцию.
Интерфейсные дуги часто называют потоками или стрелками.

111.

Проектирование информационных систем
Функционально-ориентированные и объектноориентированные методологии описания предметной
области
Функциональная методика IDEF0
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0.
Принцип декомпозиции применяется при разбиении сложного процесса на
составляющие его функции. При этом уровень детализации процесса определяется
непосредственно разработчиком модели.
Модель IDEF0 всегда начинается с представления системы как единого целого
– одного функционального блока с интерфейсными дугами, простирающимися за
пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком
называется контекстной диаграммой.
Точка зрения определяет основное направление развития модели и уровень
необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить
модель, отказавшись от детализации и исследования отдельных элементов, не
являющихся необходимыми, исходя из выбранной точки зрения на систему.
Правильный выбор точки зрения существенно сокращает временные затраты на
построение конечной модели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее
создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть
организованы новые проекты, нацеленные на производство изменений в модели.

112.

Проектирование информационных систем
Функционально-ориентированные и объектноориентированные методологии описания предметной
области
Функциональная методика потоков данных (DFD)
При создании диаграммы потоков данных используются четыре основных
понятия: потоки данных, процессы (работы) преобразования входных потоков
данных в выходные, внешние сущности, накопители данных (хранилища).
Потоки
данных
являются
абстракциями, использующимися
для
моделирования передачи информации (или физических компонент) из одной части
системы в другую. Потоки на диаграммах изображаются именованными стрелками,
ориентация которых указывает направление движения информации.
Назначение процесса (работы) состоит в продуцировании выходных потоков
из входных в соответствии с действием, задаваемым именем процесса. Имя процесса
должно содержать глагол в неопределенной форме с последующим дополнением.
Хранилище (накопитель) данных позволяет на указанных участках
определять данные, которые будут сохраняться в памяти между процессами.
Фактически хранилище представляет "срезы" потоков данных во времени.
Внешняя сущность представляет собой материальный объект вне контекста
системы, являющейся источником или приемником системных данных.

113.

Проектирование информационных систем
Функционально-ориентированные и объектно-ориентированные
методологии описания предметной области
Объектно-ориентированная методика
Принципиальное отличие между функциональным и объектным подходом
заключается в способе декомпозиции системы. Объектно-ориентированный подход
использует объектную декомпозицию, при этом статическая структура описывается в
терминах объектов и связей между ними, а поведение системы описывается в
терминах обмена сообщениями между объектами. Целью методики является
построение бизнес-модели организации, позволяющей перейти от модели сценариев
использования к модели, определяющей отдельные объекты, участвующие в
реализации бизнес-функций.
Объект — предмет или явление, имеющее четко определенное поведение и
обладающие состоянием, поведением и индивидуальностью. Структура и поведение
схожих объектов определяют общий для них класс. Класс – это множество объектов,
связанных общностью структуры и поведения. Следующую группу важных понятий
объектного
подхода
составляют
наследование
и
полиморфизм.
Понятие полиморфизм может быть интерпретировано как способность класса
принадлежать более чем одному типу. Наследование означает построение новых
классов на основе существующих с возможностью добавления или переопределения
данных и методов.

114.

Проектирование информационных систем
Функционально-ориентированные и объектно-ориентированные
методологии описания предметной области
Объектно-ориентированный
подход
обладает
следующими
преимуществами:
• Объектная декомпозиция дает возможность создавать модели меньшего размера
путем использования общих механизмов, обеспечивающих необходимую экономию
выразительных средств. Использование объектного подхода существенно повышает
уровень унификации разработки и пригодность для повторного использования, что
ведет к созданию среды разработки и переходу к сборочному созданию моделей.
• Объектная декомпозиция позволяет избежать создания сложных моделей, так как
она предполагает эволюционный путь развития модели на базе относительно
небольших подсистем.
• Объектная модель естественна, поскольку ориентирована на человеческое
восприятие мира.
К недостаткам объектно-ориентированного подхода относятся высокие
начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его
применения сказывается после разработки двух–трех проектов и накопления повторно
используемых компонентов. Диаграммы, отражающие специфику объектного подхода,
менее наглядны.

115.

Проектирование информационных систем
Функционально-ориентированные и объектно-ориентированные
методологии описания предметной области
Синтетическая методика
Идея синтетической методики заключается в последовательном применении
функционального и объектного подхода с учетом возможности реинжиниринга
существующей ситуации.
Рассмотрим применение синтетической методики на примере разработки
административного регламента.
При построении административных регламентов выделяются следующие стадии:
1. Определение границ системы. На этой стадии при помощи анализа потоков данных выделяют
внешние сущности и собственно моделируемую систему.
2. Выделение сценариев использования системы. На этой стадии при помощи критерия
полезности строят для каждой внешней сущности набор сценариев использования системы.
3. Добавление системных сценариев использования. На этой стадии определяют сценарии,
необходимые для реализации целей системы, отличных от целей пользователей.
4. Построение диаграммы активностей по сценариям использования. На этой стадии строят
набор действий системы, приводящих к реализации сценариев использования;
5. Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики
IDEF0.
6. Формальное описание отдельных функциональных активностей в виде административного
регламента (с применением различных нотаций ).

116.

Проектирование информационных систем
Моделирование информационного обеспечения
Одной
из
основных
частей
информационной
системы является информационная база. Информационная база (ИБ) представляет
собой совокупность данных, организованную определенным способом и хранимую в
памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются
информационные потребности управленческих процессов и решаемых задач.
Разработка БД выполняется с помощью моделирования данных. Цель моделирования
данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных
в форме одной модели или нескольких локальных моделей, которые относительно
легко могут быть отображены в любую систему баз данных. Наиболее
распространенным средством моделирования данных являются диаграммы
"сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей
данных DFD – диаграммы, а также документируются информационные аспекты бизнессистемы, включая идентификацию объектов, важных для предметной
области ( сущностей), свойств этих объектов ( атрибутов ) и их связей с другими
объектами (отношений).

117.

Проектирование информационных систем
Моделирование информационного обеспечения
Базовые понятия ERD
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов
(людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами
или характеристиками. Любой объект системы может быть представлен только одной
сущностью, которая должна быть уникально идентифицирована. При этом имя
сущности должно отражать тип или класс объекта, а не его конкретный экземпляр
(например, АЭРОПОРТ, а не ВНУКОВО).
Каждая сущность должна обладать уникальным идентификатором. Каждый
экземпляр сущности должен однозначно идентифицироваться и отличаться от всех
других экземпляров данного типа сущности. Каждая сущность должна обладать
некоторыми свойствами:
• иметь уникальное имя; к одному и тому же имени должна всегда применяться одна
и та же интерпретация; одна и та же интерпретация не может применяться к
различным именам, если только они не являются псевдонимами;
• иметь один или несколько атрибутов, которые либо принадлежат сущности, либо
наследуются через связь ;
• иметь один или несколько атрибутов, которые однозначно идентифицируют
каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими
сущностями модели.

118.

Проектирование информационных систем
Моделирование информационного обеспечения
Базовые понятия ERD
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая
для рассматриваемой предметной области. Связь — это ассоциация между
сущностями, при которой каждый экземпляр одной сущности ассоциирован с
произвольным (в том числе нулевым) количеством экземпляров второй сущности, и
наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой
предметной области и предназначенная для квалификации, идентификации,
классификации, количественной характеристики или выражения состояния сущности .
Атрибут представляет тип характеристик или свойств, ассоциированных с множеством
реальных или абстрактных объектов (людей, мест, событий, состояний, идей,
предметов и т.д.).
Экземпляр атрибута — это определенная характеристика отдельного элемента
множества. Экземпляр атрибута определяется типом характеристики и ее значением,
называемым значением атрибута. На диаграмме "сущность-связь" атрибуты
ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности
должен обладать единственным определенным значением для ассоциированного
атрибута.

119.

Проектирование информационных систем
Моделирование информационного обеспечения
Базовые понятия ERD
Связь изображается линией, проводимой между сущностью-родителем и сущностьюпотомком, с точкой на конце линии у сущности-потомка. Мощность связей может
принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р —
один или более. По умолчанию мощность связей принимается равной N.
Идентифицирующая связь между сущностью-родителем и сущностью-потомком
изображается сплошной линией. Сущность-потомок в идентифицирующей связи
является зависимой от идентификатора сущностью. Сущность-родитель в
идентифицирующей связи может быть как независимой, так и зависимой от
идентификатора сущностью (это определяется ее связями с другими сущностями ).
Пунктирная линия изображает неидентифицирующую связь.

120.

Проектирование информационных систем
Моделирование информационного обеспечения
Базовые понятия ERD
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты,
определяющие первичный ключ, размещаются наверху списка и отделяются от других
атрибутов горизонтальной чертой.
Сущности могут иметь также внешние ключи (Foreign Key), которые могут
использоваться в качестве части или целого первичного ключа или неключевого
атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена
атрибутов, после которых следуют буквы FK в скобках.

121.

Проектирование информационных систем
Моделирование информационного обеспечения
Базовые понятия ERD
Логический уровень — это абстрактный взгляд на данные, когда данные
представляются так, как выглядят в реальном мире, и могут называться так, как
они называются в реальном мире, например "Постоянный клиент", "Отдел" или
"Фамилия сотрудника". Объекты модели, представляемые на логическом уровне,
называются сущностями и атрибутами. Логическая модель данных может быть
построена на основе другой логической модели, например на основе модели
процессов. Логическая модель данных является универсальной и никак не связана с
конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически
являясь отображением системного каталога. В физической
модели содержится информация обо всех объектах БД. Поскольку стандартов на
объекты БД не существует (например, нет стандарта на типы данных), физическая
модель зависит от конкретной реализации СУБД. Следовательно, одной и той
же логической модели могут соответствовать несколько разных физических
моделей. Если в логической модели не имеет значения, какой конкретно тип
данных имеет атрибут, то в физической модели важно описать всю информацию о
конкретных физических объектах — таблицах, колонках, индексах, процедурах и т.д.

122.

Проектирование информационных систем
Моделирование информационного обеспечения
Базовые понятия ERD
Иерархия наследования (или иерархия категорий) представляет собой особый тип
объединения сущностей, которые разделяют общие характеристики.
Обычно иерархию наследования создают, когда несколько сущностей имеют общие по
смыслу атрибуты, либо когда сущности имеют общие по смыслу связи.
Для каждой категории можно указать дискриминатор — атрибут родового предка,
который показывает, как отличить одну категориальную сущность от другой.

123.

Проектирование информационных систем
Моделирование информационного обеспечения
Ключи
Как было сказано выше, каждый экземпляр сущности должен быть уникален и должен
отличаться от других атрибутов.
Первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно
идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не
требуют специального обозначения — это те атрибуты, которые находятся в списке
атрибутов выше горизонтальной линии.
В одной сущности могут оказаться несколько атрибутов или наборов атрибутов,
претендующих на роль первичного ключа. Такие претенденты называются
потенциальными ключами (candidate key).
Ключи могут быть сложными, т. е. содержащими несколько атрибутов. Сложные
первичные ключи не требуют специального обозначения — это список атрибутов,
расположенных выше горизонтальной линии.
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду
требований:
Уникальность. Два экземпляра не должны иметь одинаковых значений возможного
ключа.
Компактность. Сложный возможный ключ не должен содержать ни одного атрибута,
удаление которого не приводило бы к утрате уникальности.

124.

Проектирование информационных систем
Унифицированный язык визуального моделирования
Unified Modeling Language (UML)
Унифицированный язык объектно-ориентированного моделирования
Unified Modeling Language (UML) явился средством достижения компромисса между
этими подходами. Существует достаточное количество инструментальных средств,
поддерживающих с помощью UML жизненный цикл информационных систем, и,
одновременно, UML является достаточно гибким для настройки и поддержки
специфики деятельности различных команд разработчиков.
UML представляет собой объектно-ориентированный язык моделирования,
обладающий следующими основными характеристиками:
• является языком визуального моделирования, который обеспечивает разработку
репрезентативных моделей для организации взаимодействия заказчика и
разработчика ИС, различных групп разработчиков ИС;
• содержит механизмы расширения и специализации базовых концепций языка.

125.

Проектирование информационных систем
Синтаксис и семантика основных объектов UML
Классы
Классы — это базовые элементы любой объектно-ориентированной системы. Классы
представляют собой описание совокупностей однородных объектов с присущими им
свойствами — атрибутами, операциями, отношениями и семантикой.
В рамках модели каждому классу присваивается уникальное имя, отличающее его от
других классов. Если используется составное имя (в начале имени добавляется имя
пакета, куда входит класс ), то имя класса должно быть уникальным в пакете.
Атрибут — это свойство класса, которое может принимать множество значений. Атрибут
имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех
объектов данного класса. Класс может иметь произвольное количество атрибутов.
Операция — реализация функции, которую можно запросить у любого объекта класса.
Операция показывает, что можно сделать с объектом. Исполнение операции часто
связано с обработкой и изменением значений атрибутов объекта, а также изменением
состояния объекта.

126.

Проектирование информационных систем
Диаграммы классов
Классы в UML изображаются на
диаграммах классов, которые позволяют
описать систему в статическом состоянии —
определить типы объектов системы и
различного рода статические связи между
ними.
Классы отображают типы объектов системы.
Между
классами
возможны
различные
отношения, представленные на рис. 11.2:
• зависимости,
которые
описывают
существующие между классами отношения
использования;
• обобщения, связывающие обобщенные
классы со специализированными;
• ассоциации,
отражающие структурные
отношения между объектами классов.

127.

Проектирование информационных систем
Диаграммы использования
Диаграммы использования описывают функциональность ИС, которая будет
видна пользователям системы. "Каждая функциональность" изображается в виде
"прецедентов использования" (use case) или просто прецедентов. Прецедент — это
типичное взаимодействие пользователя с системой, которое при этом:
• описывает видимую пользователем функцию,
• может представлять различные уровни детализации,
• обеспечивает достижение конкретной цели, важной для пользователя.

128.

Проектирование информационных систем
Диаграммы последовательностей
Этот вид диаграмм используется для точного определения логики сценария
выполнения прецедента. Диаграммы последовательностейотображают типы
объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они
посылают друг другу, и любые возвращаемые значения, ассоциированные с этими
сообщениями. Прямоугольники на вертикальных линиях показывают "время жизни"
объекта. Линии со стрелками и надписями названий методов означают вызов метода у
объекта.
вводятся строки заказа;
по каждой строке проверяется наличие товара;
если запас достаточен — инициируется поставка;
если запас недостаточен — инициируется дозаказ (повторный заказ).

129.

Проектирование информационных систем
Диаграммы состояний
Диаграммы состояний используются для описания поведения сложных
систем. Они определяют все возможные состояния, в которых может находиться
объект, а также процесс смены состояний объекта в результате некоторых событий. Эти
диаграммы обычно используются для описания поведения одного объекта в
нескольких прецедентах.

130.

Проектирование информационных систем
Диаграммы деятельности
Диаграмма деятельности — это частный случай диаграммы состояний. На
диаграмме деятельности представлены переходы потока управления от одной
деятельности к другой внутри системы. Этот вид диаграмм обычно используется для
описания поведения, включающего в себя множество параллельных процессов.
овалы, изображающие действия объекта;
линейки синхронизации, указывающие на необходимость завершить или начать
несколько действий (модель логического условия "И");
ромбы, отражающие принятие решений по выбору одного из маршрутов
выполнения процесса (модель логического условия "ИЛИ");
стрелки — отражают последовательность действий, могут иметь метки условий.

131.

Проектирование информационных систем
Диаграммы компонентов
Диаграммы компонентов позволяют изобразить модель системы на
физическом уровне.
Элементами диаграммы являются компоненты — физические замещаемые
модули системы. Каждый компонент является полностью независимым элементом
системы. Разновидностью компонентов являются узлы. Узел — это элемент реальной
(физической) системы, который существует во время функционирования
программного комплекса и представляет собой вычислительный ресурс, обычно
обладающий как минимум некоторым объемом памяти, а часто еще и способностью
обработки. Узлы делятся на два типа:
• устройства — узлы системы, в которых данные не обрабатываются.
• процессоры — узлы системы, осуществляющие обработку данных.

132.

Проектирование информационных систем
Особенности методологии ARIS
Методология ARIS является наиболее объемной и содержит около
100 различных моделей, используемых для описания, анализа
и оптимизации различных аспектов деятельности организации.
Эта концепция имеет два основных преимущества:
• позволяет выбрать методы и интегрировать их, опираясь на
основные особенности моделируемого объекта;
• служит базой для управления сложными проектами, поскольку
благодаря структурным элементам содержит встроенные
модели процедур для разработки интегрированных
информационных систем.
Кроме того большим преимуществом методологии ARIS является
эргономичность и высокая степень визуализации моделей, что
делает данную методологию удобной и доступной в
использовании всеми сотрудниками компании

133.

Проектирование информационных систем
В виду большого количества моделей методология
ARIS делит их на 4 группы:
1. Информация (информационные модели). Состоит из моделей
с помощью которых описывается информация, используемая в
деятельности организации.
2. Функции (функциональные модели).Состоит из моделей,
используемых для описания стратегических целей компании,
функций и прочих элементов функциональной деятельности
организации.
3. Оргструктура (организационные модели). Состоит из моделей
с помощью которых описывается организационная структура
компании, а также другие элементы внутренней
инфраструктуры организации.
4. Процессы (модели управления). Состоит из моделей,
используемых для описания бизнес-процессов, а также
различных взаимосвязей между структурой, функциями и
информацией.

134.

Проектирование информационных систем
Группы моделей методологии ARIS.

135.

Проектирование информационных систем
Архитектура ARIS

136.

Проектирование информационных систем
Каждая из этих групп разделяется ещё на три
уровня:
• Уровень определения требований. На данном уровне
разрабатываются модели, описывающие то, что должна делать
система - как она организована, какие деловые процессы в ней
присутствуют, какие данные при этом используются.
• Уровень проектной спецификации. Этот уровень
соответствует концепции информационной системы,
определяющей основные пути реализации предъявленных на
втором этапе требований.
• Уровень описания реализации. На данном этапе жизненного
цикла создания информационных систем происходит
преобразование спецификации в физическое описание
конкретных программных и технических средств. Это
заключительный этап проектирования систем, за которым
следует этап физической реализации (программирования).

137.

Проектирование информационных систем
ARIS Toolset – инструментальная среда,
разработанная компанией IDS Scheer AG.
Методология ARIS позиционирует себя как конструктор, из
которого под конкретный проект в зависимости от его целей и
задач разрабатывается локальная методология, состоящая из
небольшого количества требуемых бизнес-моделей и
объектов.
ARIS Express - бесплатная версия программы поддерживает
только базовые типы диаграмм, не имеет
многопользовательской поддержки, не использует базу
данных, не содержит инструментов для формирования отчётов
и средств анализа модели. ARIS Express не поддерживает связи
между создаваемыми объектами в отличие от полноценной
платной версии, то есть отсутствует контроль целостности и
непротиворечивости модели.

138.

Проектирование информационных систем
ARIS Express
Архитектура программы базируется на Java Runtime Environment
(JRE)
ARIS Express поддерживает следующие типы моделей:
• Организационная диаграмма (Organizational chart)
• Бизнес-процесс (Business process)
• ИТ-инфраструктура (IT infrastructure)
• Карта процессов (Process landscape)
• Модель данных (Data model)
• Карта систем (System landscape)
• Доска (Whiteboard)
• BPMN диаграмма версии 2.0 (BPMN diagram)
• Общие диаграммы (General diagram)

139.

Проектирование информационных систем
Организационная модель
Моделирование и анализ организационной структуры должен
проводиться с целью выявления:
• обоснованного количества уровней иерархии;
• наличия более чем 5-6 подчиненных подразделений у одного
руководителя;
• наличие малого количества подчиненных у одного
руководителя;
• подчинения одних и тех же сотрудников различным
руководителям.
В модели организационной структуры целесообразно показывать:
подразделения предприятия;
наименование должностей и фамилии руководителей
подразделений;
физическое местоположение отделов на предприятии.

140.

Проектирование информационных систем

141.

Проектирование информационных систем
Предметная область «Предприятие по сборке и
продаже компьютеров».
Организационная модель.
• В модель верхнего уровня включаются самостоятельные
подразделения, входящие в структуру организации: Отдел
управления, Отдел по продажам и маркетингу, Отдел по сборке
и тестированию, Отдел по отгрузке и снабжению.
• Уровни структурных подразделений:
для Отдела по сборке и тестированию это - Управление сборкой
и тестированием, Сборка, Тестирование
для Отдела по отгрузке и снабжению это - Снабжение
необходимыми комплектующими, Хранилище комплектующих
и собранных компьютеров, Отгрузка готовой продукции.
• Низшим уровнем является описание подразделений на уровне
должностей – штатных единиц, занимаемых конкретными
сотрудниками.

142.

Проектирование информационных систем

143.

Проектирование информационных систем
Функциональная модель
Функция – описание элемента работы, образующего один
логический этап в рамках процесса. В методологии ARIS
используется диаграмма «Дерево функций», посредством
которой функции могут быть описаны с различными уровнями
детализации. При этом функции представляются
необязательно в хронологическом порядке.
На самом верхнем уровне описываются наиболее сложные
функции, представляющие собой отдельный бизнес-процесс
или процедуру. Детализация функций образует иерархическую
структуру их описаний

144.

Проектирование информационных систем
Предметная область «Предприятие по сборке и
продаже компьютеров».
Бизнес процесс предприятия делится на функции:
• «Управление», «Заключение договора»,
• «Сборка и тестирование»,
• «Отгрузка и снабжение».
Они в свою очередь деляться еще на ряд функций.
Функция «Получить запрос клиента» подразумевает, что клиент
делает заказ на сборку компьютера.
Функция «Сформировать заказ» подразумевает оформление
договора с заказчиком.
Функция «Согласовать заказ» подразумевает проверку договора и
его подписание.
Функция «Принять заказ к выполнению» подразумевает отправку
копии договора в отдел сборки и тестирования.
Функция «Получить договор на сборку» означает, что с отдела по
продажам поступил договор.

145.

Проектирование информационных систем
Предметная область «Предприятие по сборке и
продаже компьютеров».
Функция «Получить необходимые комплектующие»
подразумевает под собой оформление заказа на снабжение и
его отправка в отдел отгрузки и снабжения.
Функции «Сборка» и «Тестирование» означают сборку
компьютера и его тестирование соответственно.
Функция «Получить заказ на снабжение» означает, что с отдела
«Сборка и тестирование» пришел список необходимых
комплектующих.
Функция «Заказать комплектующие» означает, что
комплектующие, которые указаны в заказе на снабжение и не
хранящиеся на складе, заказываются.
Функция «Отправить комплектующие на сборку» подразумевает,
что необходимые комплектующие есть на складе и их
отправляем в отдел «Сборки и тестирования». Функция
«Отправить готовую продукцию» подразумевает, что готовая
подукция отправляется заказчику.

146.

Проектирование информационных систем

147.

Проектирование информационных систем
Информационная модель (модель данных).
Базовая модель ERM Формулировка требований в рамках модели данных включает
описание семантической модели данных в рассматриваемой предметной области.
Модель сущность-отношение (ERM) Чена является наиболее широко
распространненым методом создания семантических моделей. Сущность – это
реальный или абстрактный объект, представляющий интерес для задач в
конкретной области деятельности. Атрибуты – это свойства, описывающие типы
сущностей.
Процессная модель. Диаграмма цепочек добавления качества.
Диаграмма цепочек добавленного качества описывает функции организации,
которые непосредственно влияют на реальный выход ее продукции. Эти функции
создают последовательность действий, формируя добавленные значения:
стоимость, количество, качество и т.д. Построение диаграммы цепочки
добавленного качества целесообразно начать с обзорного представления
взаимосвязанных частей процесса путем расположения элементов процесса
согласно временной последовательности их выполнения. На следующем этапе
рекомендуется отразить взаимозависимость различных элементов процесса путем
нанесения соответствующих связей. После отображения в модели структуры
процесса каждый из элементов процесса рассматривается с точки зрения
необходимости его детализации. Если это необходимо, то элемент детализируется
на соответствующие блоки. На завершающем этапе в модель процесса добавляют
элементы организационной структуры, отвечающие за выполнения процесса или
участвующие в процессе, а также документы, используемые в процессе.

148.

Проектирование информационных систем
Элементы управления информационной модели

149.

Проектирование информационных систем
Пример модели ERM

150.

Проектирование информационных систем
Пример диаграммы цепочек добавления качества

151.

Проектирование информационных систем
Диаграмма eEPC (событийная цепочка процесса)
Модель предназначена для детального описания процессов,
выполняемых в рамках одного подразделения, несколькими
подразделениями или конкретными сотрудниками.
Она позволяет выявлять взаимосвязи между организационной и
функциональной моделями.
Модель eEpc отражает последовательность действий в рамках
одного бизнес-процесса, которые выполняются
организационными единицами, а также ограничения по
времени, налагаемые на отдельные функции. Для каждой
функции могут быть определены начальное и конечное
события, ответственные исполнители, материальные и
документарные потоки (входы, выходы, ресурсы),
сопровождающие модель, а также проведена декомпозиция
на более низкие функции (подфункции и т.д.).
Модель eEPC является наиболее информативной и удобной при
описании деятельности подразделений организации.