данных

Основания и методологии создания ИС
Разработал Дубаков А.А.
1
Основания создания ИС




Проблемы – нежелательные ситуации,
которые мешают организации полностью
достичь ее цели и/или выполнению ее задач.
Возможности – потенциал улучшения
организации даже при отсутствии
конкретных проблем.
Директивы – новые требования, которые
установлены руководством, правительством
или другим внешним воздействием.
Проблемы и возможности – две стороны
одной медали. Система разрабатывается в
Проблемы, возможности
ответ на одно из оснований.
и директива могут быть
как запланированными,
так и внеплановыми.
2
Причины изменения ИС в организациях








Изменения в потребностях
пользователей или предприятия
Изменения в технологии
Улучшение бизнес-процессов
Получение преимуществ в
конкурентной борьбе
Прирост производительности
Расширение организации
Сокращение эксплуатационных
затрат
Улучшение качества продукции и
услуг
3
Выявление проблемы


Выявление проблемы – это процесс
осознания реальных проблем ИС и
потребностей пользователя и
предложения решений для разрешения
этих проблем.
ИС создается и предназначена для
разрешения бизнес-проблем путем
применения информационных
технологий и автоматизации обработки
информации.
4
ПИЭКЭО основа выявления проблемы
Производительность, Информация, Экономика,
Контроль, Эффективность, Обслуживание
П потребность в улучшении производительности
И потребность в улучшении информации (и данных)
Э потребность в улучшении экономики, управлении
издержками или увеличении дохода
К потребность в улучшении контроля или
безопасности
Э потребность в повышении эффективности людей и
процессов
О потребность в улучшении обслуживания клиентов,
поставщиков, партнеров, служащих и т.п.
5
ПРОИЗВОДИТЕЛЬНОСТЬ


Производительность – количество
работы, выполняемой в период
времени (обработки документов).
Время ответа – средняя задержка
между запуском операции или
запросом и ответом на эту операцию
или запрос.
6
ИНФОРМАЦИЯ (и данные)
А. Выходы







Недостаток любой информации
Недостаток необходимой информации
Недостаток существенной информация
Слишком много информации –
«информационная перегрузка»
Информация отсутствует в полезном
формате
Неточная информация
Несвоевременная информация
7
ИНФОРМАЦИЯ (и данные)

Входы







Данные не собираются
Данные не собираются своевременно для
использования
Данные собираются не точно – содержат
ошибки
Данные собираются с трудом
Данные собираются избыточно – одни и те же
данные собираются более чем один раз
Собирается слишком много данных
Собирается искаженные данные
8
ИНФОРМАЦИЯ (и данные)

Хранение данных






Данные хранятся избыточно в
нескольких файлах и/или базах данных
Хранимые данные не точные
Данные не безопасны случайно или
намерено
Данные не правильно организованы
Данные негибкие – трудно
удовлетворить новые информационные
потребности из имеющихся данных
Данные не доступны
9
ЭКОНОМИКА

Недостаточно безопасности или управляемости







Входные данные не редактируются адекватно
Совершаются преступление (или могут произойти) по
отношению к данным
 Обман
 Хищение
Нарушается этические нормы применения данных или
информации – неавторизованные люди получают доступ к
данным или информации
Избыточное хранение данных является противоречивым в
различных файлах или базах данных
Нарушаются (или могут быть нарушены) управляемость или
авторские права данных
Совершаются ошибки обработки (людьми, устройствами или
программным обеспечением)
Совершаются ошибки принятия решений сотрудниками в
организации
10
ЭКОНОМИКА

Слишком много защиты или
регулирования - наоборот



Бюрократическая волокита замедляет
процессы в организации
Процесс управления причиняют
неудобства заказчикам или сотрудникам
Чрезмерное регулирование вызывает
задержки обработки
11
ЭФФЕКТИВНОСТЬ




Люди, оборудование или компьютеры используются
избыточно
 Данные излишне вводятся и копируются
 Данные излишне обрабатываются
 Информация производится в избыточном
количестве
Люди, устройства или компьютеры избыточно
расходуют материалы и оборудование
Трудоемкость, требуемая для решения задач
избыточна
Материалы, требуемые для решения задач
избыточны
12
ОБСЛУЖИВАНИЕ








Система производит неточные результаты
Система производит несогласованные
результаты
Система производит ненадежные
результаты
Система трудно изучается
Система трудна в использовании
Система неудобна для использования
Система негибкая для новых или
непредусмотренных ситуаций
Система негибкая к изменениям
13
Еще раз о методологии




Методология это материальное воплощение
логического жизненного цикла, которая
объединяет:(1) пошаговую деятельность для каждой
фазы, (2) персональные и групповые роли,
выполняемые в каждой деятельности, (3) результаты и
стандарты качества для каждого вида деятельности и
(4) инструментальные средства и технологии,
используемые для каждого вида деятельности.
Настоящая методология должна сопровождать весь
жизненный цикл разработки системы.
Большинство современных методологий объединяет
использование нескольких инструментальных средств
и технологий разработки.
В зависимости от ситуации методологии могут
предполагать различные реализации
14
Преимущества методологии




Правильные методологии гарантируют, что
согласованный, воспроизводимый подход
применяется ко всем проектам.
Методологии сокращают риск, связанный с
незавершенностью и ошибками.
Методологии производят полную и
согласованную документацию от проекта к
проекту.
Освоение и правильное применение методов
и средств создания ПО позволяет повысить
его качество, обеспечить управляемость
процесса проектирования ПО и увеличить
срок его жизни.
15
Варианты методологий




Разработка, основанная на
моделировании : Model-Driven
Development (MDD)
Rapid Application Development (RAD)
Приобретение готового ПО
Commercial Off-the-Shelf Software
(COTS)
Комбинация трех упомянутых
16
Разработка, основанная на моделировании


Моделирование – выполнение одной или
нескольких диаграмм, представляющих систему.
Моделирование – технология взаимодействия,
основанная на известном высказывании «Рисунок
заменяет тысячу слов».
Разработка, основанная на моделировании
– процесс, основанный на разработке
графических моделей, помогающих представлять
и анализировать проблемы, определять
требования бизнеса и проектировать ИС.
17
Состав моделей


Моделирование не является целью
разработки ПО, а лишь средство
Состав моделей, используемых в каждом
конкретном проекте, и степень их
детальности в общем случае зависят от
следующих факторов:




сложности проектируемой системы;
необходимой полноты ее описания;
знаний и навыков участников проекта;
времени, отведенного на проектирование.
18
Если рисунок заменяет 1,000 слов...
Модель процессов заменяет 1,000 рисунков.
BPwin, используемый в
Министерстве обороны
США, позволил
идентифицировать
более 1000 скрытых
процессов!
19
Разработка, основанная на моделировании



Структурный анализ и проектирование
системы(Structured systems analysis and design) —
ориентация на процессы (process-centered)
Инфотехника (Information engineering (IE) —
ориентация на информацию (data-centered)
Объектно-ориентированный анализ и
проектирование) Object-oriented analysis and
design (OOAD) — ориентация на объекты
(object-centered) (объединение данных and
процессов)
20
Структурный анализ и
проектирование системы


Состоит из этапов Структурного
анализа и Структурного
проектирования.
Представляет собой совокупность
правил и процедур, предназначенных
для построения функциональной
модели объекта какой-либо
предметной области на основе
которой проектируется система.
21
Предмет структурного анализа и
проектирования

Функциональная структуру системы;



Последовательность выполняемых действий;
Передача информации между
функциональными процессами;
Отношения между данными.
22
Модели структурного анализа и проектирования

Функциональная модель SADT
(Structured Analysis and Design
Technique);



Функциональные модели IDEF0, IDEF3;
DFD (Data Flow Diagrams) – диаграммы
потоков данных.
Entity Relationship Model – ERМ
23
Функциональная модель



Отображает функциональную структуру
объекта, т.е. производимые им действия и
связи между этими действиями.
Каждая система может быть разложена на
составляющие системы
Декомпозиция есть последовательное
изложение деталей системы

Применяются одинаковые законы границы,
входа, выхода, управления и механизма
(ICOM)
24
25
Работы раскладываются на другие работы
26
IDEF3


Модели IDEF3 могут использоваться для
детализации функциональных блоков
IDEF0, не имеющих диаграмм
декомпозиции
Описывают сценарий процесса, который
выделяет последовательность действий и
подпроцессов анализируемой системы.
27
Пример IDEF3-диаграммы
28
Data Flow Diagrams


Data Flow Diagrams – DFD представляют собой иерархию
функциональных процессов,
связанных потоками данных.
Цель - продемонстрировать, как
каждый процесс преобразует свои
входные данные в выходные, а также
выявить отношения между этими
процессами.
29
Пример DFD
30
Модель данных


Средством моделирования данных
(предметной области) является модель
«сущность-связь» (Entity Relationship
Model – ERМ)
Используется в структурном анализе и
проектировании, однако, по существу,
представляет собой подмножество
объектной модели предметной области.
31
Структурное проектирование
Cтруктурное проектирование ориентированная на процессы техника для
разбиения большой программы на иерархию
модулей в результате чего программа легче
реализуется и сопровождается(изменяется).
Синоним, (хотя технически неточный)программирование сверху вниз (нисходящее) и
структурное программирование.
Модель ПО, полученная структурным
проектированием называется «структурная
схема» structure chart.
32
SYSTEM
MODULE
1
DA TA A
3
2
DA TA B
5
MODULE
A
6
MODULE
B
4
4
FLAG A
5
DA TA A
6
FLAG B
FLAG B
DA TA B
MODULE
C
DA TA C
MODULE
D
MODULE
E
7
DA TA B
LIBRARY
MODULE
A
DA TA D
MODULE
F
DA TA B
AND C/D
MODULE
G
Структурное проектирование




Структурное проектирование отыскивает факторы
программы в нисходящей иерархии модулей, которые
имеют следующие свойства:
Модули должны иметь сильную внутреннюю связность
(highly cohesive); Каждый модуль должен выполнять
одну и только одну функцию. Это позволяет
многократно использовать (reusable) модули в будущих
программах.
Модули должны быть слабо связаны между собой
(loosely coupled); иными словами, модули должны быть
минимально зависимы между собой. Это минимизирует
эффект влияния будущих изменений одного модуля на
другой.
Группировать все модули (или процессы) вызванный
одной операций для формирования операционного
центра. Например, все задачи, выполняемые при
получении заказа от поставщика, связаны. Как
правило, центр управления служит как модуль
управления.
34
Information engineering


Инфотехника (Information engineering) основанная на моделировании
процедура, ориентированная на
данные, но чувствительная к процессам
техника планирования, анализа и
проектирования ИС. IE модели
являются диаграммами, которые
иллюстрируют и синхронизируют
данные и процессы системы.
Недостает процесса проектирования
35
Information engineering




Строится модель данных(сущности, атрибуты ,
ключи, связи). Формируется словарь данных,
нормализация.
Формулируются эксплуатационные процедуры
(добавление, удаление, корректировка, чтение,
запись (CRUD) и т.п.) ведения данных, а также
атрибуты файлов(r/o, rw, w)
Определяются характеристики использования
данных(производительность, время доступа,
размер файла, число записей в каждом файле).
Принимаются решения о технологии испытаний,
спецификации аппаратных и программных
средств, стратегии разработки, разрабатывать
или покупать.
36
Information engineering (прод.)




Рассматриваются факторы концепции архитектуры
системы (централизация или распределение), анализ и
проектирование сети, потребность в удаленном доступе
и использовании Интернета. Используются такие
инструменты как моделирование сети и связности
узлов.
Присваиваются имена базе данных и выполняется
проектирование экранных форм и отчетов.
Методология проектирования рекомендует
использовать непроцедурные языки четвертого
поколения (CASE генераторы, экранные генераторы,
генераторы отчетов, объектно-ориентированные языки,
html, Java и т.д.) для разработки системы.
Формирование спецификаций программ, в процессе
которой детально определяются спецификации вывода
(запрос или отчет), физические связи между
различными файлами и точная структура меню (иконки,
сокращенные полные и названия).
37
Принципы и понятия ООАП








Абстрагирование - существенные
параметры,
инкапсуляция,
наследование,
полиморфизм;
объект,
класс, атрибут,
операция,
интерфейс и др.
38
Object-oriented analysis (OOA)

Объектно-ориентированный анализ
(Object-oriented analysis - OOA)
основанная на моделировании
процедура, которая интегрирует данные
и процессы в конструкцию, называемую
объектами. OOA модели диаграммы,
которые представляют объекты системы
с различных точек зрения, таких как
структурной (данные) и поведенческой
(методы).
39
Object-oriented design (OOD)
Object-oriented design – современная
концепция проектирования и
является расширением objectoriented analysis.
Представляет собой технику,
используемую для повышения
качества определения требований
объектов, выявленных ранее во
время анализа и определении
реализации определенных объектов.
40
Варианты использования
Вариант использования
представляет собой
последовательность
действий (транзакций),
выполняемых системой в
ответ на событие,
инициируемое некоторым
внешним объектом
(действующим лицом)
41
Диаграмма классов
моделируют
статическую
структуру классов
системы и связи
между классами
42
Диаграмма состояний
Когда объект
находится в
каком-то
конкретном
состоянии,
могут
выполняться
различные
процессы.
Диаграммы состояний
моделируют поведение
объектов.
Определяют все возможные
состояния, в которых может
находиться конкретный
объект, а также процесс
смены состояний объекта в
результате наступления
некоторых событий.
43
Диаграмма последовательности
Диаграммы
последовательности
отражают временную
последовательность
событий, происходящих
в рамках варианта
использования
44
Коммуникационная диаграмма
Внимание
сконцентрировано на
связях между объектами.
Из них легче понять связи
между объектами, однако,
труднее уяснить
последовательность
событий.
45
Пример Component Diagram
Drawing Library
Client Source Code
Comment
Comment
(drawing.dll)
dependency
(client.exe)
Диаграмма компонентов является разновидностью
диаграммы реализации и используется для графического
изображения физической архитектуры системы. М.б.
использованы для показа разделения на модули и
взаимодействие между ними.
46
Пример Deployment Diagram
Client Workstation
HP Kayak XU-400
Application Server Compaq PIII 500
TCP/IP
SAP R/3
Comment
Client Source Code
Comment
(client.exe)
TCP/IP
Database Server Compaq PIII 500
Oracle 8
Comment
Диаграмма развертывания является также разновидностью
диаграммы реализации, которая описывает физическую
архитектуру аппаратной и программной системы. Они
отображают программные компоненты процессоры и
устройства, которые входят в архитектуру.
47
Rapid application development

Rapid application development (RAD)
техника, основанная на экстенсивном
вовлечении пользователей в быструю и
эволюционную разработку работающего
прототипа или системы для ускорения
процесса разработки системы.
RAD основывается на построении
прототипов, которые развиваются в
законченную систему или выбрасываются

Используются временные рамки
48
Rapid application development (6.4)



Прототип неполномасштабная, представительная
или работающая модель (программная)
требований пользователя или предлагаемый
проект для желаемой ИС. Прототип удовлетворяет
способу мышления «Я буду знать что я хочу,
когда увижу это», который является
характеристикой большинства пользователей и
руководителей.
Временные рамки (time box) – нерасширяемый
период времени, обычно 60-120 дней, в течение
которого кандидат должен быть внедрен в
эксплуатацию.
Ускоренный анализ использует прототип для
ускорения выявления требований бизнеса и и
пользователей к новой системе.
49
Принципы RAD




Разработка приложений итерациями;
Необязательность полного завершения работ на каждом
из этапов жизненного цикла;
Обязательное вовлечение пользователей в процесс
разработки ИС;
Необходимое применение CASE-средств, обеспечивающих
целостность проекта;






Применение средств управления конфигурацией, облегчающих
внесение изменений в проект и сопровождение готовой системы;
Необходимое использование генераторов кода;
Использование прототипирования, позволяющее полнее
выяснить и удовлетворить потребности конечного
пользователя;
Тестирование и развитие проекта, осуществляемые
одновременно с разработкой;
Ведение разработки немногочисленной хорошо
управляемой командой профессионалов;
Грамотное руководство разработкой системы, четкое
планирование и контроль выполнения работ.
50
Преимущества прототипирования







Прототипирование поощряет и требует активного
участия пользователей.
Повтор и изменения – естественная
последовательность разработки системы, при этом
конечные пользователи меняют свою точку зрения.
Часто говорится, что конечные пользователи
полностью не знают их требований пока не увидят их в
применении.
Прототип активная, а не пассивная модель, которую
пользователь может видеть, соприкасаться, оценивать
и опробовать.
Принятый прототип – рабочий эквивалент
спецификации проекта с ранним обнаружением
ошибок.
Прототипирование может увеличивать творчество,
поскольку ускоряет обратную связь, что приводит к
улучшению решений.
Прототипирование ускоряет несколько фаз ЖЦ,
возможно исключая программирование.
51
Недостатки прототипирования







Прототипирование поощряет возврат к ЖЦ
“программирование, применение и исправление”.
Прототипирование не устраняет потребность фаз
обследования и изучения.
Нельзя полностью заменить прототипом
спецификацию на бумаге.
Огромное количество проблем проекта не
представляется прототипированием.
Прототипирование часто ведет к
преждевременному переходу к проектированию.
Во время прототипирования масштаб и сложность
системы могут быстро перерасти первоначальные
планы.
Прототипирование может сокращать творчество в
проектах.
52
Commercial off-the-shelf (COTS) software

Commercial off-the-shelf (COTS)
software – ПО или решение, которое
покупается для поддержки одной или
более бизнес-функций или ИС.
53