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


Оглавление (нажмите, чтобы открыть):

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

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

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

Лекция 1
Лекция 2 Жизненный цикл программного обеспечения ИС.

Понятие жизненного цикла ПО ИС. Процессы жизненного цикла: основные, вспомогательные, организационные. Содержание и взаимосвязь процессов жизненного цикла ПО ИС. Модели жизненного цикла: каскадная, модель с промежуточным контролем, спиральная. Стадии жизненного цикла ПО ИС. Регламентация процессов проектирования в отечественных и международных стандартах.

Лекция 3 Организация разработки ИС.

Каноническое проектирование ИС. Стадии и этапы процесса канонического проектирования ИС. Цели и задачи предпроектной стадии создания ИС. Модели деятельности организации («как есть» и «как должно быть»). Состав работ на стадии технического и рабочего проектирования. Состав проектной документации. Типовое проектирование ИС. Понятие типового проекта, предпосылки типизации. Объекты типизации. Методы типового проектирования. Оценка эффективности использования типовых решений. Типовое проектное решение (ТПР). Классы и структура ТПР. Состав и содержание операций типового элементного проектирования ИС. Функциональные пакеты прикладных программ (ППП) как основа ТПР. Адаптация типовой ИС. Методы и средства прототипного проектирования ИС.

Лекция 4 Анализ и моделирование функциональной области внедрения ИС.

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

Лекция 5 Спецификация функциональных требований к ИС.

Процессные потоковые модели. Процессный подход к организации деятельности организации. Связь концепции процессного подхода с концепцией матричной организации. Основные элементы процессного подхода: границы процесса, ключевые роли, дерево целей, дерево функций, дерево показателей. Выделение и классификация процессов. Основные процессы, процессы управления, процессы обеспечения. Референтные модели. Проведение предпроектного обследования организации. Анкетирование, интервьюирование, фотография рабочего времени персонала. Результаты предпроектного обследования.

Лекция 6 Методологии моделирования предметной области.

Методологии моделирования предметной области. Структурная модель предметной области. Объектная структура. Функциональная структура. Структура управления. Организационная структура. Функционально-ориентированные и объектно-ориентированные методологии описания предметной области. Функциональная методика IDEF. Функциональная методика потоков данных. Объектно-ориентированная методика. Сравнение существующих методик. Синтетическая методика.

Лекция 7 Моделирование бизнес-процессов средствами BPwin.

Case-средства для моделирования деловых процессов. Инструментальная среда BPwin. Принципы построения модели IDEF0: контекстная диаграмма, субъект моделирования, цель и точка зрения. Диаграммы IDEF0: контекстная диаграмма; диаграммы декомпозиции; диаграммы дерева узлов; диаграммы только для экспозиции (FEO). Работы (Activity). Стрелки (Arrow). Туннелирование стрелок. Нумерация работ и диаграмм. Каркас диаграммы. Слияние и расщепление моделей. Создание отчетов.

Лекция 8 Моделирование бизнес-процессов средствами BPwin.

Стоимостный анализ: объект затрат, двигатель затрат, центр затрат. Свойства, определяемые пользователем (UDP). Диаграммы потоков данных (Data Flow Diagramming): работы, внешние сущности (ссылки), потоки работ, хранилища данных. Метод описания процессов IDEF3: работы, связи, объекты ссылок, перекрестки. Имитационное моделирование: источники и стоки, очереди, процессы.

Лекция 9 Информационное обеспечение ИС.

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

Лекция 10 Моделирование информационного обеспечения.

Моделирование данных. Метод IDEFI. Отображение модели данных в инструментальном средстве ERwin. Интерфейс ERwin. Уровни отображения модели. Создание логической модели данных: уровни логической модели; сущности и атрибуты; связи; типы сущностей и иерархия наследования; ключи, нормализация данных; домены. Создание физической модели: уровни физической модели; таблицы; правила валидации и значение по умолчанию; индексы; триггеры и хранимые процедуры; проектирование хранилищ данных; вычисление размера БД; прямое и обратное проектирование. Генерация кода клиентской части с помощью ERwin: расширенные атрибуты; генерация кода в Visual Basic. Создание отчетов. Генерация словарей.

Лекция 11 Унифицированный язык визуального моделирования Unified Modeling Language (UML).

Диаграммы в UML. Классы и стереотипы классов. Ассоциативные классы. Основные элементы диаграмм взаимодействия — объекты, сообщения. Диаграммы состояний: начального состояния, конечного состояния, переходы. Вложенность состояний. Диаграммы внедрения: подсистемы, компоненты, связи. Стереотипы компонент. Диаграммы размещения.

Лекция 12 Этапы проектирования ИС с применением UML.

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

Лекция 13 Практикум: Учебный проект: «Разработка ИС предприятия оптовой торговли лекарственными препаратами»

Методика выполнения учебного задания основана на опыте ряда успешных проектов внедрения КИС Navision и Axapta.

Практическое задание позволяет изучить состав, содержание и процедуры формирования основных документов, которые создаются в процессе типового проектирования ИС (см. раздел «Организация разработки ИС»), приобрести навыки разработки диаграмм бизнес-процессов на основе их вербального описания, которое получается в результате обследования деятельности предприятий.

Работа 1 Моделирование бизнес-процессов средствами BPwin: Принципы построения модели IDEF0. Методы описания процессов IDEF3.
Работа 2

Отображение модели данных в инструментальном средстве ERwin: Метод IDEFI.

Работа 3 Проектирование ИС с применением языка моделирования UML в среде Rational Rose.

Проектирование ИС с применением языка моделирования UML в среде Rational Rose.

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

1. Предпроектная стадия

1.1 Описание предметной области

1.2 Разработка функциональной модели предметной области

1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer

2. СТАДИЯ ПРОЕКТИРОВАНИЯ

2.1 Выбор программных средств разработки

2.2 Разработка логической модели

2.3 Разработка физической модели

3. РЕАЛИЗАЦИЯ ПРОЕКТА

3.1 Серверная часть

3.2 Клиентская часть

3.3 Реализация запросов

4. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ ПРОЕКТА

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Введение

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

Цели курсовой работы:

· применение на практике знаний, полученных в процессе изучения курса «Проектирование ИС»;

· получение практических навыков создания АИС, основанных на БД.

Задачи курсовой работы:

· получение представлений о методах и средствах проектирования современных ИС;

· приобретение навыков использования CASE-систем проектирования ИС;

· развитие самостоятельности при разработке ИС на базе программных продуктов AllFusion Process Modeler r7, AllFusion Data Modeler r7 и СУБД SQL Server 2005.

Курсовая работа состоит из следующих частей:

· Построение функциональной модели предметной области в программной среде AllFusion Process Modeler r7, что включает в себя 3 вида диаграмм:

o диаграммы IDEF0;

o диаграмма DFD;

o диаграмма IDEF3.

· Построение UML диаграмм в среде Pacestar UML diagrammer;

· Проектирование логической и физической модели данных в программной среде AllFusion Data Modeler r7;

· Разработка клиентского приложения ИС в среде Access с использованием БД, находящихся в СУБД MySQL Server 5.1.

1. ПРЕДПРОЕКТНАЯ СТАДИЯ

1.1 Описание предметной области

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

Технологический процесс состоит из следующих стадий, представленных на рис. 2.

Технологический процесс предприятия заключается в последовательном выполнении шагов на различных стадиях выполнения заказа. Выполнение заказа начинается с правильной подготовки автомобиля или детали к окраске. Сначала автомобиль тщательно и неоднократно моется водой, а после сушиться в специальной камере при температуре 90 0С. Затем с автомобиля снимают все декоративные детали с гальваническим покрытием, резиновые прокладки. Затем кузов разбирается на части для чего снимается капот, крышка багажника, двери и в некоторых случаях крылья. Если деталь деформирована, то ее выправляют и придают ей нужную форму. Затем производится зачистка поверхности от старой краски и ржавчинами путем обработки ее наждачной бумагой и стальными щетками с различного рода растворами. Затем поверхность кузова обезжиривается уайт-спиртом. Проверка качества обезжиривания проводится с помощью фильтровальной бумаги: если на бумаге остаются следы жира или грязи, то поверхность необходимо промыть растворителем еще раз (а возможно, и не раз — пока она не будет полностью обезжирена). Затем поверхность выравнивается с помощью шпатлевки. Толщина слоя шпатлевки не должна превышать 0,3 мм. Время сушки зашпатлеванной поверхности должно выдерживаться в соответствии с техническими условиями на используемую шпатлевку. После высыхания шпатлевки следует загрунтовать зашпатлеванные места. После проведения подготовительных работ приступают к следующему этапу.

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

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

Разрабатываемая ИС должна позволять вести обработку, учет и контроль информации по работе предприятия. Обработка – добавление, удаление и изменение данных о работающих сотрудниках, расходных материалах. Учетом является быстрый поиск информации по базе данных. Контроль осуществляется над остатками расходных материалов, при их поставке учитывается их количество, дата прихода и их стоимость, а также качеством выполняемой сотрудниками работы.

Система создается для обслуживания следующих групп пользователей:

· Работники склада расходных материалов

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

Материальные потоки подразумевают документооборот предприятия. В данной предметной области документооборот включает в себя информацию о следующих компонентах:

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

Организационная структура управления предприятием, которая включает состав подразделений, приведена на рис.3.

Рассмотрим каждый участок подробнее. Участок работы с клиентами. Его работа заключается в приеме заказов, работе с клиентами (заказчиками), подбор работ, удовлетворяющих требованиям заказчика.

Затем заказ передается на следующий участок предварительных работ. На данном этапе рабочие разбирают автомобиль на окрашивающиеся детали и проводят над ними подготовительные работы к нанесению краски. Учитываются стандарты и правила выполнения работ, требования заказчика.

Детали с этого участка передаются в участок окрасочных работ, где детали окрашиваются красками различных сортов в зависимости от желаемого заказчиком цвета.

Покрашенные детали передаются в участок заключительных работ, где рабочие собирают автомобиль и доводят его до требуемого вида.

Затем изделие переходит в участок контроля качества. Контроль качества заключается в осмотре внешнего вида, проверке качества сборки автомобиля, проверки качества покраски автомобиля. Эксперты составляют отчет по результатам проверки и вырабатывают рекомендации для выполнения последующих заказов.

Система сквозного контроля за работой предприятия дает возможность полностью отслеживать технологическую цепочку от поступления автомобиля на участок предварительных работ, до его одобрения на участке контроля качества. Это обеспечивает неизменное качество для конечного потребителя, контролируя качество окраски автомобиля по стандартам и технологиям официально предписанными мировыми автокорпорациями как VAG (Audi, VW, Skoda ), PAG (Ford, Volvo, Porsche) BMV RT (BMV, MINI) GM (Opel, Сhevrolet), Toyota, Daimler-Chrysler специально для выполнения ремонтных кузовных и окрасочных работ.

Контроль и обеспечение высокого качества окраски автомобилей — это целый комплекс мероприятий, включающий в себя контроль производимых работ после обработки детали на предварительном этапе и после ее окрашивания. Также происходит контроль качества сборки окрашенного автомобиля. Сквозной контроль проводится с целью предотвращения реализации некачественных работ, не соответствующих требованиям, установленным нормативными документами по стандартизации (ISO/TS 16949).

Сквозной контроль позволяет своевременно пресекать случаи реализации работ низкого качества, а также удовлетворять потребности покупателей в высококачественных и надежных услугах; привлечение клиентов за счет улучшения качества окраски автомобилей и уровня сервиса.

Основными задачами системы сквозного контроля качества работ являются:

1. разработка, внедрение и поддержание систем менеджментана предприятии;

2. разработка и совершенствование схем контроля качества производимых работ;

3. контроль технического состояния, обеспечение своевременной поверки производимых работ;

4. обеспечение фонда нормативных документов;

5. обеспечение бесперебойной работы всех участков;

6. организация подготовки, повышения квалификации и обучения сотрудников предприятия.

На предприятии существует тир участка проведения сквозного контроля: контроль качества предварительной обработки детали к окраске; контроль качества окраски детали; контроль качества всех проделанных работ;

На этапе контроля качества предварительной обработки детали к окраске главный технолог проверяет качество обезжиривания загрунтованной детали с помощью фильтровальной бумаги, а также следит за тем, чтобы слой грунтовки не превышал 0,3 мм. В случае нахождения выполнения некачественной работы, главный технолог направляет деталь на повторный курс работ на данном этапе.

На этапе контроля качества окраски детали главный технолог проверяет соответствие выполненных работ заказу и желанию клиента. Так же проверяется непосредственно качество выполненной окраски и ее соответствие установленным стандартам.

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

Для обслуживания деятельности данного коммерческого предприятия будет разработана автоматизированная информационная система (АИС), предназначенная для быстрой и качественной обработки, учета и контроля задействованной в данной предметной области информации.

Под обработкой понимается добавление, изменение и удаление данных об участках цеха, заказах, клиентах.

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

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

В соответствии с предметной областью система строиться с учетом следующих особенностей:

· Каждый этап работ осуществляется на определенном участке цеха;

· Работы выполняются согласно характеристикам, оговоренным с заказчиком при оформлении заказа;

· Основные виды работ проходят контроль качества для перехода на следующий этап;

· Выполненный фронт работ соответствует определенному заказу;

· Заказ определяет клиента;

· Реализация работ осуществляется согласно данным клиента;

· Ведение БД (запись, чтение, модификация, удаление);

· Обеспечение логической непротиворечивости БД;

· Реализация наиболее часто встречающихся запросов в готовом виде;

· Получение информации об этапах прохождения заказа;

· Получение информации о клиентах и заказах;

· Получение списка расходных материалов: их наименования и количества;

· Получение информации о прохождении заказа стадий контроля;

1.2 Разработка функциональной модели предметной области

Наиболее широко используемой методологией описания бизнес-процессов является стандарт IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (BPWin, ProCap, IDEF0/EM Tool и др.) Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управлении процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 позволяют существенно упростить работа аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество состоит в возможности описывать управление процессами организации.

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью система представляется в виде иерархии компонентов (процессов), связанных потоками данных. Главная цель такого представления — продемонстрировать, как каждый процесс преобразует входные данные в выходные, а также выявить отношения между этими процессами. Диаграмма IDEF3 — методология моделирования, использующая графическое описание информационных потоков, взаимодействий между процессами обработки информации и объектов, являющихся частью этих процессов. Методология описания IDEF3 очень близка к алгоритмическим методам построения блок-схем.

В настоящее время для описания бизнес-процессов используется несколько методологий. К числу наиболее распространенных относятся методологии моделирования бизнес-процессов (Business Process Modeling), методологии описания потоков работ (Work Flow Modeling) и методологии описания потоков данных (Data Flow Modeling).

Наиболее широко используемой методологией описания бизнес-процессов является стандарт IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (BPWin, ProCap, IDEF0/EM Tool и др.) Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управлении процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 позволяют существенно упростить работа аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество состоит в возможности описывать управление процессами организации.

Второй важнейшей методологией описания процессов является методология IDEF3. Формально эта методология называется Work Flow Modeling, что отражает ее сущность. Стандарт IDEF3 предназначен для описания рабочих процессов или, говоря другими словами, потоков работ. Методология описания IDEF3 очень близка к алгоритмическим методам построения схем процессов стандартными средствами построения блок-схем (построение блок-схемы в MS Word). Основа методологии IDEF3 состоит в построении моделей процессов по принципу последовательно выполняемых во времени работ.

Еще одной группой методологий, активно используемых на практике, являются нотации DFD (Data Flow Diagramming). Эти нотации предназначены для описания потоков данных. Они позволяют отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами. Кроме того, нотация DFD позволяет описывать потоки документов (документооборот) и потоки материальных ресурсов (движение материалов от одной работы к другой). С помощью схемы процессов в DFD выявляют основные потоки данных. Это важно для последующего создания моделей структуры данных и разработки требований к информационной системе организации.

Для модели, разработанной в курсовой работе, все виды диаграмм представлены в Приложении 1. Также был произведён стоимостной анализ проекта, результаты которого представлены в Приложении 2. Общая стоимость проекта составила 11 850 руб.

В результате того, что диаграмма IDEF0 была дополнена диаграммами DFD и IDEF3, была получена смешанная диаграмма, которая со всех сторон описывает процесс деятельности предприятия (рис. 1.1).

Рис 1.1. Смешанная диаграмма

1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

UML позволяет создавать диаграммы, такие как:

1. Диаграмма вариантов использования.

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

1. Диаграмма взаимодействия.

Это диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

2. Кооперативная диаграмма.

Это диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

3. Диаграмма классов.

Это статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами. На рис.1.5 показана общая структура системы согласно функционированию предприятия.

4. Диаграмма состояний.

Диаграмма состояний, State Machine diagram (диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями. Конечный автомат — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

5. Диаграмма пакетов.

Это структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

6. Диаграмма деятельности.

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

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

7. Диаграмма компонентов.

Это статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Структура ИИС представлена на рис.1.9.

2. СТАДИЯ ПРОЕКТИРОВАНИЯ

2.1 Выбор программных средств разработки

программный разработка приложение access

Оболочка клиента будет разработана при помощи Acess, в связи с его тотальным распространением, так как данный продукт является интегрированным в ОС Windows. Не смотря на все увеличивающийся спрос на ОС написанных на ядре Linux подовляющее большинство пользователей работают на различных версиях операционной системы от компании Microsoft. Серверная часть проекта будет базироваться на СУБД MySQL. MySQL имеет двойное лицензирование. MySQL может распространяться в соответствии с условиями лицензии GPL. Однако по условиям GPL, если какая-либо программа включает исходные коды MySQL, то она тоже должна распространяться по лицензии GPL. Это может расходиться с планами разработчиков, не желающих открывать исходные тексты своих программ. Для таких случаев предусмотрена коммерческая лицензия, которая также обеспечивает качественную сервисную поддержку. MySQL также является кроссплатформенным приложением, данная СУБД удобна в использовании, логична, легка в понимании. MySQL является надежным инструментом для управлениями БД. В данной курсовой работе будет использоваться версия MS SQL Server 2005.

Итак, комплекс технических средств для функционирования данной ИС должен отвечать следующим минимальным системным требованиям:

1. Процессор: х86-совместимый процессор, желательно класса Intel Celeron IV и выше; частота от 1800 Mhz;

2. Оперативная память – от 512 Мб;

3. Видеоадаптер: любая современная видеокарта, от 64Мб ОЗУ;

4. ОС: Windows: 2000/XP/2003 server x86 .

5. СУБД: MS SQL Server 2005.

6. MS office Access 2003 и выше

2.2 Разработка логической модели

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

В данной предметной сущности выделяются следующие базовые сущности, образующие структуру проектируемой ИС:

· Клиент. Атрибуты клиента – код клиента, ФИО, телефон, адрес;

· Заказ. Атрибуты заказа – код заказа, дата заказа, автомобиль наименование детали, вид работы, цвет, стоимость;

· Материалы. Атрибуты Материалов – код материала, тип материалов, наименование, количество, стоимость, сумма;

· Персонал. Атрибуты персонала — код работника, ФИО, адрес, телефон, должность;

· Этап работы. Атрибуты этапа работы — код этапа работы, наименование этапа, дата начала этапа;

· Контроль. Атрибуты контроля – код контроля, дата контроля;

· Вид контроля. Атрибуты вида контроля – вид контроля, комментарии;

· Оценка. Атрибуты оценки – оценка, комментарии;

· Реализация. Атрибуты реализации – код реализации, дата реализации, стоимость всего заказа;

Рис 2.1. Логическая модель данных

2.3 Разработка физической модели

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах — таблицах, колонках, индексах, процедурах и т.д. Полученная физическая модель для СУБД MS SQL Server 2005представлена на рис.2.2.

Физическая модель генерируется в СУБД MS SQL Server 2005, где создается БД с таблицами и полями, которые не содержат записей.

Рис 2.2. Физическая модель данных

3. РЕАЛИЗАЦИЯ ПРОЕКТА

3.1 Серверная часть

Серверная часть проекта базируется на СУБД SQL Server 2005. SQL Server — система управления реляционными базами данных, разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия.

Для обеспечения доступа к данным Microsoft SQL Server поддерживает Open Database Connectivity (ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Компания Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

Для создания серверной части была создана новая база данных Avers. Размер файла данных обозначен в 20 мб, файл лога в 3 мб. Имеется возможность работать сразу нескольким пользователям с таблицами БД. Данная БД совместима только с SQL Server 2005. Все остальные параметры были оставлены по умолчанию.

В следствии использования для клиентской части MS Access 2007, AllFusion ERwin Data Modeler не имел возможности перенести данные в данную версию (ERwin интегрирует данные в MS Access 2000/2002/2003). В результате не было возможности использовать AllFusion ERwin Data Modeler для переноса данных и таблицы. В результате в БД были созданы новые таблицы, идентичные таблицам в AllFusion ERwin Data Modeler.

Для создания таблицы, необходимо открыть раздел «Tables» и вызвать меню «New Table. «. В Microsoft SQL Server получили необходимые таблицы(рис.3.1.1). Ключевые поля полностью соответствуют аналогичным полям в ERwin. Все поля, кроме ключевых, не должны иметь пустых значений.

Рис.3.1.1. Перенесенные таблицы.

Затем между таблицами были обозначены и проведены связи(рис. 3.1.2).

Рис.3.1.2 Диаграмма связей между таблицами.


Для установки и использования этой БД, необходимо скопировать файлы «Avers.mdf» и » Avers_log.ldf» в директорию местонахождения БД в SQL Server. По умолчанию это C:\Program Files\Microsoft SQL Server\MSSQL.1\ MSSQL\Data. Затем необходимо запустить SQL Server, выбрать раздел «Database» и в контекстном меню выбрать пункт «Attach». В появившемся окне необходимо нажать кнопку «Add» и выбрать файл «Avers.mdf» и нажать «Ok» (рис 3.1.3).

Рис.3.1.3 Импорт БД.

3.2 Клиентская часть

Для клиентской части использовался MS Access 2003. Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Клиентская часть получает данные из БД, расположенной на SQL Server, обрабатывая и посылая запросы пользователя. Для этого, в приложение были внесены связанные таблицы ODBC, благодаря которым и происходит взаимодействие двух частей программного средства.Рис

Все таблицы связаны связями типа «один-ко-многим» или «один – к -одному» с обеспечением целостности данных(рис.3.1).

Рис 3.1. Связи между таблицами

При запуске АИС пользователь оказывается в главном меню программы (рис. 3.2).

Рис 3.2. Главное окно программы

Менеджер, работая с программой, может внести информацию о новом клиенте, добавить новый заказ, а так же редактировать ранее введенную информацию. Чтобы добавить нового клиента, следует щелкнуть на соответствующей кнопке. Откроется окно добавления нового клиента (рис. 3.3):

Рис 3.3. Окно добавления нового клиента

При нажатии на кнопку «Оформить заказ» внизу окна происходит переход на форму внесения данных о новом заказе (рис. 3.4):

Рис 3.3. Ввод нового заказа

В случае, если с системой работает работник цеха, то он может внести данные о этапе работы с заказом нажав на кнопку «Внести данные о этапе» в главном меню программы (рис 3.4)

Рис 3.4. Ввод данных о этапе выполнения заказа

Работник так же может вносить данные об используемых для выполнения заказа на этапах материалах. Для этого необходимо перейти на форму внесения материалов, нажав на кнопку «Оформить материалы» в главном меню, или на кнопку «Внести материалы» с формы заполнения данных о этапе работы (рис.3.5).

Рис 3.5. Ввод данных об используемых материалах

После заполнения полей о количестве и стоимости одной штуки материалов следует нажать на кнопку «рассчитать сумму», что приведет к автоматическому заполнению поля «сумма» данными, рассчитанными с использованием данных из ранее упомянутых полей.

Главный технолог предприятия, работая с данным приложением, может вносить данные о результатах сквозного контроля качества выполнения этапов заказа. Для этого в главном меню необходимо нажать кнопку «Внести данные о контроле» после чего откроется форма внесения данных о контроле(рис.3.6).

Рис 3.6. Ввод данных об используемых материалах

При нажатии кнопки «Отчет о контроле» будет открыто окно предварительного просмотра выводимого на печать отчета о прохождении заполненного контроля.(рис.3.7).

Рис 3.7. Отчет о прохождении контроля

Так же главный технолог может вносить данные о реализации заказа, перейдя по кнопке «Реализация» главного меню.(рис3.8).

Рис.3.8. Ввод данных о реализации.

При нажатии кнопки «Отчеты» откроется форма с возможными отчетами (рис.3.9)

Рис 3.9. Форма отчеты

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

3.3 Реализация запросов

В АИС «Аверс» организованны запросы, по результатам которых строятся разнообразные отчеты, часть которых представлена на форме «Отчеты».При реализации запрос обращается к БД, которые хранится на сервере(серверная часть приложения), затем перерабатывает информацию, в результате чего находит удовлетворяющие запросу данные, которые и выводит в отчеты через клиентскую часть приложения.

Запрос «Выполненные заказы» (рис.3.10) находит информацию о всех реализованных заказах. Результат запроса представлен в виде формы, просмотреть которую можно нажав на кнопку «Выполненные заказы» формы «Отчеты»(рис.3.11).

Рис.3.10.Запрос «Выполненные заказы»

Рис.3.11.Форма «Выполненные заказы»

Запрос по оценке контроля (рис.3.12.) ищет все работы, оценка контроля которых соответствует выбранному варианту на форме «Отчеты». После выбора интересующей оценки на данной форме и нажатия кнопки «Отчет по оценки контроля» предоставляется отчет(рис.3.13) с соответствующей информацией.

Рис3.12.Запрос по оценке контроля

Рис.3.13.Отчет по оценке контроля

Так же представлены отчеты предоставляющие список используемых материалов как для всего заказа в целом (рис.3.14.) так и для отдельного этапа заказа (рис.3.15.)

Рис.3.14. Отчет «Материалы для заказа»

Рис.3.15.Отчет «материалы для этапа заказа»

Эти отчеты основаны на запросах материалы для заказа (рис.3.16.) и материалы для этапа заказа (рис.3.17).

Рис.3.16.Запрос «Материалы для заказа»

Рис.3.17.Запрос материалов на этап закзаза

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

Рис3.18.Запрос «Оформление заказа»

Рис.3.19.Запрос «Реализация заказа»

Рис.3.20.Отчет об оформлении заказа

Рис.3.21.Отчет о реализации заказа.

Так же реализован запрос о прохождении стадий контроля определенным заказом (рис.3.22). Интересующий заказ выбирается на форме «Отчеты» и после нажатия на кнопку «Прохождение заказом контроля» будет предоставлен отчет в виде формы (рис.3.23.).

Рис.3.22.Запрос о прохождении стадий контроля

Рис.3.23.Очет о прохождении заказом стадий контроля

В АИС «Аверс» для расчета полной стоимости заказа необходимо определить стоимость используемых для выполнения заказа материалов, для этого устраивается запрос «стоимость материалов» основанные на запросе «материалов для заказа»(рис.3.16), результаты которого находятся в форме (рис3.24.).

Рис.3.24.Стоимость используемых для заказа материалов

4. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ ПРОЕКТА

АИС «Аверс» имеет элементарный и легкодоступный интерфейс, что упрощает работу с ней.

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

В ходе выполнения курсовой работы были достигнутые поставленные цели, такие как: применение на практике знаний, полученных в процессе изучения курса «Проектирование ИС» и получение практических навыков создания автоматизированных информационных систем (АИС), основанных на БД.

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. –Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.1 – 146 с.

2. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. –Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.2 – 132 с.

3. Мартин Ф., Кендалл С. UML Основы / Ф.Мартин, С.Кендалл. – СПб.:Символ-Плюс, 2002. – 192 с.

4. Бланшет Ж., Саммерфилд М. Qt 4: программирование GUI на C++ / Ж. Бланшет, М.Саммерфилд. – М.:КУДИЦ-ПРЕСС, 2008. – 736 с.

5. Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс / Д. Арлоу, И. Нейштадт. – СПб.: Символ-Плюс, 2007. – 624 с.

Презентация на тему: УЧЕБНЫЙ КУРС «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ»

Первый слайд презентации

УЧЕБНЫЙ КУРС «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ»

Слайд 2

2 РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. 2-е изд., перераб. и доп. М.: Финансы и статистика, 2006. Гвоздева Т.В. Проектирование информационных систем: учеб. пособие /Т.В. Гвоздева, Б.А. Баллод. – Ростов н/Д: Феникс, 2009. Козлов А.С. Проектирование и исследование бизнес-процессов : учеб. пособие /А.С. Козлов. 2-е изд., перераб. и доп. М.: Флинта: МПСИ, 2006. Проектирование информационных систем: курс лекций: учеб пособие для студентов вузов, обучающихся по специальностям в области информ. технологий /В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. М.: Интернет-Университет Информ. технологий, 2005. Смирнова Г.Н. Проектирование экономических информационных систем : учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов ; под ред. Ю.Ф. Тельнова. М. : Финансы и статистика, 2005. Материалы сайта www.intuit.ru (сайт Интернет-университета информационных технологий)

Слайд 3

3 1. Основные понятия проектирования информационных систем. Структура проекта информационной системы Цель дисциплины «Проектирование информационных систем» – овладение теоретическими знаниями и практическими навыками в области проектирования современных информационных систем, предназначенных для решения задач в различных сферах деятельности предприятий. Основные понятия Проект информационной системы – совокупность проектно-конструкторской и технологической документации, в которой представлено описание проектных решений по созданию и эксплуатации информационной системы в конкретной программно-технической среде. Разработка этой проектной документации представляет собой процесс проектирования информационной системы. Проектирование информационной системы – процесс преобразования информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии со стандартами в проект ИС.

Слайд 4

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

Слайд 5

5 Информационное обеспечение ИС – совокупность единой системы классификации и кодирования технико-экономической информации, унифицированной системы документации и информационной базы.

Слайд 6

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

Слайд 7

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

Слайд 8

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

Слайд 9

9 Схема организации проектных работ с использованием организаций-соисполнителей разных уровней иерархии Заказчик Головная организация Организация- соисполнитель 1-го уровня Организация- соисполнитель 2-го уровня Положение о взаимодействии соисполнителей Техническое задание Договор Частный договор Частный договор Частное техническое задание Частное техническое задание

Слайд 10

10 Проектирование информационной системы можно рассматривать как технологический процесс, состоящий из ряда взаимосвязанных технологических операций. Согласно стандарту ГОСТ Р ИСО/МЭК 12207 «Процессы жизненного цикла программных средств» в процессе анализа требований заказчика и проектирования информационной системы можно выделить следующие этапы:

Слайд 11

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

Слайд 12

12 Контрольные вопросы: Дайте определение понятию проект информационной системы. Что является объектом проектирования? Что является субъектом проектирования? Какой документ проекта информационной системы включает расчет экономической эффективности разрабатываемой системы? Какие этапы можно выделить в процессе анализа требований заказчика и проектирования информационной системы согласно стандарту ГОСТ Р ИСО/МЭК 12207 «Процессы жизненного цикла программных средств»? Назовите основные документы, регулирующие отношения заказчика и исполнителя работ по проектированию информационных систем? Каковы отличительные особенности проекта как вида деятельности проектирующей организации? Какие компоненты включает в себя внемашинное информационное обеспечение? Какие компоненты включает в себя внутримашинное информационное обеспечение? Назовите виды программных документов.

Слайд 13

13 2. Понятие консалтинга в области информационных технологий. Основные цели и этапы разработки консалтинговых проектов ИТ-консалтинг – деятельность специалиста или целой фирмы, занимающихся стратегическим планированием проекта, анализом и формализацией требований к информационной системе, созданием системного проекта, проектированием приложений, но все это до этапа собственно программирования или настройки типовых корпоративных информационных систем. В понятие ИТ-консалтинга не входит системная интеграция. ИТ-консалтинг – широкое понятие, которое подразумевает большое число разных видов работ. Далее рассмотрим перечень видов работ, выполняемых специалистами в области информационных технологий. ЗАДАНИЕ Требуется определить, какие виды работ из следующего перечня можно отнести к услугам ИТ-консалтинга.

Слайд 14

14 ВИДЫ РАБОТ, ВЫПОЛНЯЕМЫХ СПЕЦИАЛИСТАМИ В ОБЛАСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Профессиональная ИT-сертификация – проверка, оценка знаний и умений, в результате которой выдается документ, позволяющий предоставить работодателям и клиентам доказательство индивидуального уровня специализации и полномочий. Сертификация включает работы на составление тестов, проведение тестирования и аттестации. Обучение техническим навыкам – тренинг в области профессиональной подготовки, включающий подготовку и образование в области разработки, установки и/или использования оборудования, программного обеспечения, систем и сетей. Телефонная поддержка – подразумевает консультирование по телефону пользователей, решение проблем, а также оказание помощи в устранении ошибок. Уровень поддержки определяется временем суток или днем недели, необходимой срочностью решения проблемы, а также типом вопросов.

Слайд 15

15 Анализ пользовательских интерфейсов – включает работы по проведению и анализу юзабилити -тестов по разрабатываемым или внедряемым приложениям. Цель таких работ состоит в том, чтобы проверить систему пользовательского интерфейса или другой части приложения на интуитивность, простоту использования и оценить степень ее влияния на бизнес-результаты. Подготовка документации – составление инструкций по эксплуатации системы или приложения. Миграция ИТ-системы – это обеспечение перехода от существующей вычислительной среды к новой или модифицированной. Поддержка перебазирования – это помощь организации по переводу сотрудников, бизнес-отделов, производственных и сервисных подразделений или целой организации из одного места в другое. Услуги включают деинсталляцию и реинсталляцию ИТ-систем. Интеграция интерфейсов приложений – преобразование данных из одного формата в другой, который может быть прочитан другим приложением.

Слайд 16

16 Кастомизация коробочного программного обеспечения – инструктирование по настройке программного обеспечения. Разработка программного обеспечения под заказ – представляет собой деятельность, которая связана с написанием приложений для конкретного предприятия с учетом местных бизнес- или системных требований. Реинжиниринг программного обеспечения – должен обеспечить повышение качества и эффективности старых приложений (тех, что являются наследством устаревшей ИТ-инфраструктуры), чтобы либо усовершенствовать их, либо обеспечить базу для внедрения новых приложений и их развития. ИT-инсталляция – распаковка, инспектирование, а также сборка и подключение элементов системы. Установка может включать настройку, тестирование и конфигурирование. Конфигурирование системы – включает все задачи, решение которых необходимо для запуска системы в эксплуатацию. Это подразумевает проверку кабельных подключений, силовых установок, отсутствия конфликтов совместимости, а также гарантию производительности всей системы.

Слайд 17

17 Тестирование и отладка ИТ-систем – гарантирует, что элементы системы согласованы и настроены таким образом, что обеспечивают заданный уровень производительности, который отвечает потребностям пользователей. Обычно данный вид работ включает проведение стресс-теста (Stress tests), который выполняется для проверки работы системы в режиме пиковых нагрузок. Управление проектом – подразумевает ответственность и надзор за сроками сдачи проекта. Обычно эта деятельность включает разработку сетевого графика проекта и обеспечение следования ему. Анализ поставщиков – подразумевает консалтинговую деятельность, в рамках которой консультант производит оценку сильных и слабых сторон продуктов, вендоров и поставщиков услуг и дает рекомендации относительно наилучших практик. Проектирование информационной системы – предполагает определение ресурсов и спецификаций для построения информационной системы в рамках определенного проекта. Проектирование включает анализ ИТ-архитектуры, технологии, требуемых навыков персонала и оценку готовности предприятия к внедрению того или иного решения.

Слайд 18

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

Слайд 19

19 Разработка ИТ-стратегии – включает анализ деятельности организации, ее текущих ИT-возможностей и потребностей в ИТ в будущем, работу по созданию тактического плана действий в области ИТ для достижения заданной бизнес-стратегии. Услуги по разработке ИТ-стратегии требуют знания современных тенденций в области перспективных ИТ-архитектур. Оценка потребностей в ИТ – это процесс определения требуемых технологий, навыков персонала, организации информационных потоков, рабочих помещений и анализ необходимых поставщиков этих ресурсов для перехода с текущих ИТ-систем на те, которые смогут обеспечить реализацию необходимой бизнес-стратегии. Анализ функционирования ИТ-системы – подразумевает применение методик оценки и анализа бизнес-процессов, организационной структуры, навыков ИТ-специалистов и других элементов информационных систем. В результате комплексной оценки этих элементов делается вывод о том, насколько эффективно компания использует ИТ-ресурсы.

Слайд 20

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

Слайд 21

Слайд 22

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

Слайд 23

23 Наиболее часто ИТ-консультантами выполняются два вида работ: Бизнес-консалтинг = бизнес-анализ + реструктуризация (реинжиниринг бизнес-процессов) Бизнес-консалтинг – деятельность, направленная на то, чтобы разобраться в функционировании бизнес-процессов (деятельностей, имеющих ценность для клиента), построить соответствующие модели и на их основе выдвинуть предложения по улучшению бизнес-процессов. Системный анализ и проектирование Основными этапами системного анализа являются следующие: Анализ функционирования экономического объекта (системы) с целью выявления недостатков существующей информационной системы. Формулирование потребностей совершенствования работы объекта и создания новой информационной системы. Выбор направлений совершенствования объекта на основе выбора программно-технических средств. Выявление и согласование требований заказчика приводит к пониманию того, что действительно необходимо сделать. За этим следует проектирование или выбор готовой системы, удовлетворяющей требованиям заказчика в наиболее полном объеме.

Слайд 24

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

Слайд 25

25 Основные этапы разработки консалтинговых проектов в сфере ИТ: Анализ первичных требований и планирование работ. Проведение обследования деятельности предприятия. Построение моделей деятельности предприятия. Разработка системного проекта. Разработка предложений по автоматизации. Разработка технического проекта. Разработка новой системы или настройка существующей системы. Рассмотрим содержание каждого этапа на отдельном слайде.

Слайд 26

26 1. Анализ первичных требований и планирование работ Данный этап предваряет инициацию работ над проектом. Его основными задачами являются: анализ первичных бизнес-требований, предварительная экономическая оценка проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы.

Слайд 27

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

Слайд 28

28 3. Построение моделей деятельности предприятия На основе результатов обследования осушествляется построение моделей деятельности предприятия следующих типов: модели «как есть» ( AS IS ), представляющей собой «снимок» положения дел на предприятии (организационно-штатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, как функционирует предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации; модели «как должно быть» ( TO BE ), интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.

Слайд 29

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

Слайд 30

30 4. Разработка системного проекта На этом этапе требования заказчика уточняются, формализуются и документируются. На этом этапе определяются: архитектура системы, ее функции, внешние условия ее функционирования, распределение аппаратной и программной частей; интерфейсы и распределение функций между человеком и системой; требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонентов системы, их интерфейсы; состав людей и работ, имеющих отношения к системе; ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации). Системный проект строится на основе модели «как должно быть» и включает : функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3); информационную модель (например, в соответствии со стандартом IDEF1X); техническое задание на создание автоматизированной системы.

Слайд 31

31 5. Разработка предложений по автоматизации На основе системного проекта осуществляются: составление перечня автоматизированных рабочих мест (АРМ) и способов взаимодействия между ними; анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору готовой системы; совместное с заказчиком принятие решения о выборе конкретной системы или разработке собственной системы; разработка требований к техническим и программным средствам; разработка предложений по этапам и срокам реализации.

Слайд 32

32 6. Разработка технического проекта На основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Этот этап подразделяется на два подэтапа: проектирование архитектуры системы, включающее: разработку структуры и интерфейсов ее компонентов, определение информационных потоков между основными компонентами, связей между ними; детальное проектирование каждого компонента, включающее: разработку спецификаций каждого компонента, разработку требований к тестам, разработку плана интеграции компонентов, построение моделей иерархии программных модулей, проектирование внутренней структуры модулей.

Слайд 33

33 7. Разработка новой системы или настройка существующей системы В случае разработки собственной системы последующие этапы являются традиционными: по спецификациям технического проекта осуществляется программирование модулей, их тестирование и отладка. Настройка существующей системы осуществляется по этапам: наполнение системы фактическими данными; построение процедур их обработки; интеграция процедур внутри автоматизированных рабочих мест; интеграция автоматизированных рабочих мест в систему.

Последний слайд презентации: УЧЕБНЫЙ КУРС «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ»

34 Контрольные вопросы: Какопы основные задачи этапа «Анализ первичных требований и планирование работ» разработки консалтингового проекта? Для чего предназначен ИТ-бенчмаркинг? Что представляет собой системный проект? Что представляет собой технический проект? Что представляет собой модель «как есть»? Что представляет собой модель «как должно быть»? Каким образом может быть осуществлен переход от модели «как есть» к модели «как должно быть»? Назовите основные этапы системного анализа. Назовите основные цели консалтинговых проектов в сфере ИТ. Назовите основные этапы разработки консалтинговых проектов в сфере ИТ.

Лекции курса — Проектирование ИС — файл 1.doc

Доступные файлы (1):

Название: Проектирование информационных систем
Раздел: Рефераты по информатике, программированию
Тип: курсовая работа Добавлен 23:56:48 03 марта 2011 Похожие работы
Просмотров: 17037 Комментариев: 14 Оценило: 7 человек Средний балл: 4.7 Оценка: 5 Скачать
1.doc 626kb. 18.11.2011 22:22 скачать

содержание

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

ЛЕКЦИИ: Проектирование информационных систем
Основная задача любого проекта заключается в том, чтобы на момент запуска системы, и в течение всего срока её эксплуатации можно было обеспечить следующие задачи:

  1. Обеспечить необходимую функциональность и адаптируемость к изменяющимся условиям.
  2. Необходимая пропускная способность системы.
  3. Время наработки системы на отказ.
  4. Простота эксплуатации и поддержки системы.
  5. Обеспечение необходимой безопасности.

Проектирование ИС охватывает три основные области:

  1. Проектирование объектов данных
  2. Проектирование программ, экранных форм и диалогов с пользователем, которые обеспечивают взаимодействие с БД.
  3. Учет конкретной среды или топологии сети.

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

  1. Пошаговая процедура, которая определяет последовательность выполнения проектирования.
  2. Набор критериев и правил, которые используются для оценки результатов выполнения технологических операций.
  3. Набор графических и текстовых средств, которые используются для описания проектируемой системы.

Технология проектирования, разработки и сопровождения системы должна удовлетворять следующим правилам:

  1. Поддержка полного жизненного цикла программного обеспечения.
  2. Гарантия достижения целей разработки программного обеспечения.
  3. Выполнение крупных систем в виде мелких подсистем.
  4. Возможность ведения работы отдельных подсистем малыми группами разработчиков.
  5. Минимальное время получения работающей системы, готовой к реализации.
  6. Возможность управления конфигурацией проекта.
  7. Независимость выполнения проектных решений.
  8. Поддержка комплекса согласованных CASE-средств.

Реальное проектирование, разработка и сопровождение ИС невозможно без выработки ряда стандартов, которые будут выполняться участниками проекта. Выделяют три группы стандартов:

  1. Стандарты проектирования:

а) Набор необходимых моделей для каждой стадии проектирования.

б) Правила фиксации готовых проектных решений.

в) Требование к конфигурации рабочего места разработчика

г) Механизм обеспечения совместной работы

  1. Стандарты оформления проектной документации

а) Необходимая комплектность документации на каждой стадии проектирования.

б) Необходимые требования по оформлению документации.

  1. Стандарт пользовательского интерфейса

а) Правила оформления экранных форм

б) Правила использования клавиатуры и мыши

в) Правила оформления помощи

г) Перечень стандартных сообщений
Жизненный цикл программного обеспечения
Жизненный цикл представляет собой модель создания ПО и его использования. Это непрерывный процесс, который начинается с принятия решения о создании и заканчивается моментом изъятия из эксплуатации. Основным документом, который регламентирует жизненный цикл, является стандарт ISO/IEC 12207.

Структура ЖЦ по данному стандарту на трех группах процессов:

  1. Основные процессы ЖЦ (приобретение, поставка, проектирование)
  2. Вспомогательные процессы (оценка качества)
  3. Организационные процессы (управление проектом)
  1. Стратегия – подразумевает собой обследование системы, оценку объема проекта, определение его целей и задач, а также получение сущностей и функций на высоком уровне. Итогом этапа определения стратегии является документ, где четко сформулированы следующие факты:

а) Необходимый объём работ по выполнению проекта

б) График и сроки выполнения работы

г) Срок окупаемости проекта и ожидаемый экономический эффект

д) Ограничения, накладываемые на проект, риски, связанные с выполнением проекта

е) Критические сроки завершения этапов разработки

ж) Наличие потенциального развития системы.

Данный этап выполняется один раз при проектировании, является наиболее трудоемким и наиболее длительным.

  1. Анализ – предполагает подробное исследование бизнес-процессов системы. На данном этапе получается информационная модель. Вся информация, собранная на предыдущем этапе, уточняется и формализуется. Результатом является иерархия функций системы (разбиение на подсистемы) и модель «сущность – связь» (ER — модель). Помимо этого в результаты включены диаграммы потоков данных, диаграммы жизненных циклов, реализация на языке UML (язык для описания предметной области).
  2. Проектирование – формируется модель данных. Эта модель строится на основе модели, полученной на этапе анализа. Конечным итогом этого этапа является схема БД и набор спецификаций модулей системы. На данном этапе начинает формироваться план тестирования системы. Общими задачами этого проектирования является:
    1. Рассмотрение результатов анализа и проверки их полноты
    2. Определение критических участков системы
    3. Принятие решения об использовании программных продуктов сторонних организаций
    4. Проектирование хранилища данных
    5. Проектирование процессов и кода программного продукта
    6. Определение требований безопасности системы
  3. Реализация – группа разработчиков, получив тех. Проект, начинает писать код модулей системы. Основная их задача состоит в том, чтобы уяснить спецификацию системы, т.е. проектировщик написал, что необходимо сделать, разработчик определяет, как это сделать. На данном этапе происходит тесное взаимодействие групп проектировщиков, разработчиков и тестеров. Необходимо отметить, что на данном этапе существует необходимость выделенного рабочего места, где происходит сборка сего проекта. Должно быть организовано хранилище готовых версий продукта. Контролировать данный процесс должен один человек. На данном этапе создаются 2 хранилища: для модулей, прошедших функциональное тестирование и для модулей, прошедших тестирование связей.
  4. Тестирование – группы тестеров привлекаются к сотрудничеству уже на более ранних этапах. На этом этапе происходит полное тестирование системы. При тестировании используется системы хранения ошибок, которая обеспечивает следующие функции:
    1. Хранение сообщений об ошибке
    2. Система уведомления о новых ошибках
    3. Информация об ошибке и её история

Все тесты системы разделяются на несколько категорий:

  1. Автономные тесты модулей
  2. Тесты связей компонентов системы
  3. Системный тест
  4. Тесты производительности и нагрузки

В тесты каждой категории входят тесты моделирования отказов системы. Они также включают несколько категорий тестов:

1. Отказ отдельного компонента

2. Отказ группы компонентов

Эти тесты позволяют оценить качество подсистемы восстановления корректного состояния системы и служат источником для разработки стратегии предотвращения последствий при сбое системы в промышленной эксплуатации.

  1. Внедрение – система редко вводится в эксплуатацию полностью. Как правило, этот процесс является постепенным или итерационным, и проходит как минимум 3 стадии:
    1. Первоначальная загрузка информации
    2. Накопление информации
    3. Выход на проектную мощность



Первоначальная загрузка информации выявляет довольно узкий спектр ошибок. В основном они касаются согласования данных при загрузке и ошибок самих загрузчиков данных.

В период накопления информации выявляется наибольшее количество ошибок. В основном эти ошибки связаны с многопользовательским доступом, и остальная часть касается модификации интерфейса пользователя.

На выходе на проектную мощность устраняются мелкие, не исправленные ранее ошибки, и очень редко серьезные ошибки.

  1. Эксплуатация и техническая поддержка. На данном этапе завершается оформление документов, основным из которых является документ технической приемки. Данный документ определяет необходимый персонал, условия эксплуатации продукта и ответственности сторон, также, если проект долгосрочный, то он содержит условия технической поддержки.

Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предполагает конкретной модели ЖЦ. Он описывает структуру процессов, но не конкретизирует детали, как реализовать и выполнить действия, включенные в процесс ЖЦ.

Под моделью ЖЦ понимается структура, которая определяет последовательность выполнения и взаимосвязи процессов, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от условий и назначения ИС.

В настоящее время распространены три модели ЖЦ:

1. Модель «водопад» или каскадная модель

2. Модель «водоворот» или поэтапная модель с промежуточным контролем.

3. Модель «спираль» или спиральная модель

Основной характеристикой данной модели является разбиение всей разработки на этапы, причем переход с этапа на этап возможен после того, как полностью завершена работа на предыдущем. Данная модель предполагает следующие свойства взаимодействия этапов:

  1. Этапы не перекрываются во времени
  2. Возврат к предыдущему этапу не предусмотрен
  3. Исправление ошибок выполняется только на стадии проектирования
  4. Результат появляется только в конце разработки

Каждый этап завершается выпуском документации, достаточной для того, чтобы работа могла быть продолжена другой командой разработчиков.

Плюсы:

  1. На каждом этапе формируется законченный набор документации
  2. Выполняемые работы позволяют планировать сроки получения готовой системы

Минусы:

  1. Существенное запаздывание получения результатов работы
  2. Как правило, информационные и функциональные модели системы устаревают с момента их утверждения

Данную модель ЖЦ использую при построении систем реального времени.
Поэтапная модель с промежуточным контролем

Модель характеризуется следующими свойствами взаимодействия этапов:

  1. Каждый этап имеет обратную связь с предыдущим
  2. Исправление ошибок происходит на каждом этапе, т.е. выполняется промежуточный контроль
  3. Этапы перекрываются во времени за счет наличия обратной связи
  4. Результат появляется только в конце разработки

«+» и «-» аналогичны каскадной модели.
Спиральная модель
Данная модель является самой молодой. По ней ведутся коммерческие разработки. На ней же реализованы методологии RUP и MSF.

  1. Анализ
  2. Проектирование
  3. Реализация
  4. Тестирование
  5. Внедрение
  6. Эксплуатация

Результат разработки появляется на каждом витке спирали, он является промежуточным, он анализируется, выявляются недостатки, которые становятся поводом появления нового витка спирали. Спираль завершается, когда клиент и разработчик приходят к согласию относительно результата.

Свойства взаимодействия этапов:

  1. Внутри витка спирали этапы не имеют обратной связи
  2. Исправление ошибок происходит на этапе тестирования, на каждом витке спирали
  3. Этапы могут перекрываться во времени в пределах одного витка спирали
  4. Результат появляется в конце каждого витка спирали и подвергается подробному анализу
  5. При переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов

Основная особенность данной модели состоит в концентрации сложностей на этапах анализа и проектирования, при этом сложность и трудоёмкость последующих этапов в пределах этого витка относительно не высокие. Основной проблемой данной модели является определение момента перехода на следующий этап. Для решения этой проблемы вводят временные ограничения, поэтому переход осуществляется в соответствие с планом, даже в том случае, если не вся работа закончена.
Методологии разработки программных средств
Методология XP
Основоположником данной методологии является Кент Бекк. ХР является молодой методологией, основными принципами которой является:

  1. Простота решения
  2. Разработка малыми группами (до 10 человек)
  3. Обратная связь с клиентом
  4. Достаточная степень смелости и желание идти на риск

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

Второй фактор ускорения – наличие малых групп. Парное программирование преследует цели стабилизации проекта, т.к. при данной методологии высок риск потери кода, по причине ухода программиста. В этом случае второй программист их этой пары играет роль наследника кода.

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

ХР характеризуют набором из 12 действий (практик), которые необходимо выполнять для достижения результата.

Практики ХР не определяют сам процесс ХР, но ХР определяет эти практики, т.е. выполнение практик не гарантирует результата.

  1. Планирование процесса. На данном этапе определяются свойства системы, способы реализации и трудоемкость
  2. Тесное взаимодействие с заказчиком. Заказчик является членом команды, им пишутся пользовательские истории, им решаются, какие особенности будут реализованы на каждом витке разработки
  3. Метафора системы. Под метафорой понимается простота именования классов и переменных. Команда разработчиков должна иметь единые правила именования
  4. Простая архитектура. Любое свойство системы должно быть реализовано как можно проще. За счет этого правила экономится время разработки
  5. Стандарты кодирования. Данные стандарты необходимы для обеспечения других действий: коллективное владение ядром системы, для парного программирования и для рефакторинга
  6. Рефакторинг. Это оптимизация существующего кода в сторону упрощения и сохранения прозрачности кода. Рефакторинг нельзя совмещать с дизайном
  7. Парное программирование. При разработке программ все программисты должны работать в парах, поэтому необходимо размещать программистов в одном месте, чаще всего на территории заказчика
  8. 40 часовая рабочая неделя. Программист не должен работать более 8 часов в день. Сверхурочная работа – это индикатор проблемы на данном направлении, которую нужно устранить
  9. Коллективное владение кодом. Каждый программист должен иметь доступ к коду системы, при этом соблюдается одно правило – если после внесения корректировок система работает не корректно, то программист, внесший изменения, должен выявить и исправить данную ошибку
  10. Частая смена версий. Общее правило для выпуска версий касается временного интервала. Минимальный срок – 1 день, максимальный – 1 месяц. Чем чаще выпускаются релизы, тем больше будет выявления ошибок
  11. Непрерывная интеграция. Интеграция новых частей системы должна выполняться как можно чаще, как минимум – раз за несколько часов. Частая интеграция позволяет быстрее получить готовую систему
  12. Тестирование. Тестирование в данной методологии – одна из важнейших составляющих. Необходимые тесты пишутся еще до написания кода системы

Данная методология обладает высокой адаптацией к часто изменяющимся требованиям. Её основным недостатком является зависимость от человеческого фактора, поэтому в результате проект получается либо экстремально хорошим, либо плохим.
МетодологияRUP
Рациональный унифицированный процесс (RUP или РУП) – одна из спиральных методологий разработки ПО.

Данная методология официально поддерживается компанией Rational Software, обновляется два раза в год. В качестве языка программирования используется язык UML.

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

Процесс разработки предполагает эволюционирование модели, т.е. каждый цикл соответствует определенной версии модели.

Для успешного процесса разработки необходимо 3 составляющих:

  1. Процесс
  2. Нотация
  3. Набор утилит

Процесс описывает, что мы делаем, в каком порядке и каким образом. Нотация является средством общения. Набор утилит позволяет автоматизировать процесс и управлять им.

В этой методологии представлены все три компоненты.

Функции нотации

  1. Осуществляет «склеивание» процессов в единое целое
  2. Является языковым средством принятия решений
  3. Представляет семантику для наглядности решений
  4. Предлагает форму для принятия и манипуляции данными

Нотация охватывает разработку ПО, начиная с анализа и заканчивая внедрением программного продукта.

В данной методологии в качестве нотации используется UML.

Методология РУП предоставляет структурный подход к разработке ПО и подразделяет процессы разработки на 4 основные фазы:

  1. Исследование (начало)
  2. Уточнение плана
  3. Конструирование (построение)
  4. Переход

Целями каждой из фаз является:

  1. Начало – фаза сбора информации, анализа требований, определение образа проекта
  2. Уточнение плана – фаза анализа требований проектирования системы, планирование действий и ресурсов, спецификации процедур, разработка особенностей дизайна
  3. Конструирование – фаза разработки, кодирования, создание бета-версий программы
  4. Переход – фаза создания конечной версии продукта, внедрение продукта и поставка конечному пользователю

Методология РУП основана на основных 9 потоках, которые являются основными элементами итераций ЖЦ.

  1. Бизнес-анализ – предполагает анализ требований на данной итерации ЖЦ, определение необходимых параметров системы и нужд пользователей.
  2. Требования, т.е. формализация образа системы – предполагает сбор сведений и перевод требования в функциональные спецификации.
  3. Анализ и моделирование, т.е. перевод собранных требований в программную модель.
  4. Реализация и кодирование, т.е. написание кода программы.
  5. Тестирование – на данном этапе происходит тестирование продукта
  6. Внедрение – на данном этапе предполагается внедрение продукта у заказчика, подготовка персонала, запуск системы и приемо-сдаточные испытания.

Особенностью методологии являются временные этапы, а именно на каких итерациях будут доминировать те или иные потоки, а также наличие специального языка и набора утилит, которые позволяют описать процесс разработки.
МетодологияMSF (Microsoft Solution Framework)
Данная методология разрабатывается компанией Майкрософт, базируется на опыте компаний по созданию больших проектов, их дальнейшему сопровождению. Особенности данной методологии заключаются в гибкости и отсутствии жестких процедур разработки.

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

На фазе выработки концепции происходит создание проектной группы, подготовка документов описания проекта, выработка бизнес-требований.

Веха «Концепция утверждена» — главная веха выработки концепции. К моменту её достижения заказчик и проектная группа должны прийти к общему соглашению о задачах проекта и его временных рамках. Результатами данной фазы являются:

  1. Общее описание проекта
  2. Документ оценки риска
  3. Описание структуры проекта

Фаза планирования – на ней выполняется функциональная спецификация, разрабатывается дизайн, оцениваются затраты и сроки разработки.

Существует три уровня процесса проектирования:

  1. Концептуальный дизайн
  2. Логический дизайн
  3. Физический дизайн

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

Результатами фазы планирования являются:

  1. Функциональная спецификация
  2. План управления
  3. Календарный план (график) проекта

Фаза разработки – на данной фазе создается программный код. Часть команды разработчиков принимает участие в тестировании готовых модулей. Данная фаза завершается вехой «Разработка завершена». К моменту ее наступления создание всех составляющих проекта завершено. Проект полностью готов к тестированию.

Результатами фазы разработки являются:

  1. Исходный и скомпилированный код приложения
  2. Скрипты установки и конфигурирования
  3. Окончательная, функциональная спецификация
  4. Материалы сопровождения и поддержки решения
  5. Спецификации и сценарии тестирования

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

Результатами фазы стабилизации являются:

  1. Окончательный продукт
  2. Документация выпуска
  3. Материалы поддержки решений
  4. Инструментарий тестирования
  5. Исходный и исполняемый код приложения
  6. Проектная документация

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

Результатами фазы внедрения являются:

  1. Система поддержки
  2. Отчеты и журналы протоколов
  3. Версии проектных документов
  4. Отчет о завершении проекта
  5. Показатели качества от заказчика

МетодологияRAD (Rapid Application Development)
Одним из важнейших подходов спиральной методологии разработки ПО является методология быстрой разработки (РАД). Под этим термином понимается процесс разработки, который содержит 3 элемента:

  1. Небольшая группа программистов (до 10 человек)
  2. Короткий производственный график
  3. Повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, реализуют в нем требования заказчика

ЖЦ по данной методологии состоит из 4-х фаз:

  1. Фаза анализа и планирования требований
  2. Фаза проектирования
  3. Фаза построения
  4. Фаза внедрения

Фаза анализа и планирования требований – на данном этапе пользователи системы определяют функции, которые должны реализовываться, выделяют из них наиболее приоритетные для внеочередной реализации. Также выясняется возможность реализации проекта в рамках установленного бюджета.

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

  1. Информационная модель системы
  2. Функциональные модели системы и подсистемы
  3. Интерфейсы взаимодействия между подсистемами
  4. Прототипы экранов, отчетов и диалогов

Фаза построения — на данном этапе происходит самая быстрая разработка. Ускорение разработки достигается за счет использования автоматически сгенерированных кусков программного кода при помощи CASE – средств. По окончании работ над отдельной подсистемой происходит ее интеграция в систему. Также на данном этапе выполняется тестирование системы.

Результатом данного этапа является:

  1. Физическое проектирование БД
  2. Определение требований к аппаратным ресурсам
  3. Определение способов повышения производительности
  4. Завершение разработки документации проекта

Фаза внедрения – на данном этапе происходит обучение пользователей, полный переход на новую систему, окончательная готовая документация по системе в целом.

Основные принципы методологии РАД:

  1. Разработка приложений итерациями
  2. Необязательность завершения работ на каждом этапе
  3. Обязательность привлечения пользователей к разработке
  4. Использование CASE – средств для обеспечения целостности проекта
  5. Использование средств управления конфигурацией
  6. Использование генераторов кода
  7. Использование прототипов
  8. Тестирование выполняется одновременно с разработкой

Методологии и средства структурного анализа
Наиболее перспективным направлением применения для проектирования является структурный подход. Данный подход заключается в декомпозиции системы на автоматизируемые функции, т.е. система разбивается над подсистемы. Все распространенные методологии базируются на ряде общих принципов:

  1. Принцип решения сложных проблем путем их разбиения на более мелкие
  2. Принцип иерархического упорядочения, т.е. упорядочение составных частей в древовидные структуры
  3. Принцип абстрагирования, т.е. выделение наиболее существенных, характерных черт системы
  4. Принцип формализации, т.е. необходимость строгого методичного подхода
  5. Принцип непротиворечивости, т.е. согласованность элементов
  6. Принцип структурирования данных, т.е. данные должны быть организованы иерархически

На текущий момент широкое распространение получили следующие модели структурного анализа:

  1. SADT
  2. DFD
  3. ERD

Методология функционального моделирования SADT
Данная методология разработана Дугласом Россом. На ее основе построена методология IDEF0. SADT представляет собой совокупность методов, правил и процедур и используется для построения функциональной модели какой-либо предметной области. Построенная модель отображает структуру объекта, производимые им действия и связи между ними.

Методология SADT базируется на двух основных принципах:

  1. Графическое представление блочного моделирования
  2. Связи в модели должны подчиняться точности и строгости:

а) Ограничение количества блоков на каждом уровне

б) Связность диаграмм

в) Уникальность меток и наименований

г) Разделение входов и управлений

Состав функциональной модели.

Функциональная модель состоит из диаграмм, фрагментов текста и глоссария, которые имеют ссылки друг на друга.

Диаграммы – это главные компоненты модели. Все функции системы для них представлены в виде блоков и дуг. Управляющая информация входит в блок сверху. Информация, которая подвергается обработке, рисуется слева, результаты операций – справа. Механизм, который осуществляет выполнение операций, рисуется дугой, которая входит в блок снизу.

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

  1. Каждая подфункция может содержать только те же элементы, которые входят в исходную функцию.
  2. Модель не может опускать какие-либо элементы для сохранения целостности системы.

Тип связей между функциями

  1. Тип случайной связности – возникает, когда конкретная связь между функциями мала или полностью отсутствует
  2. Тип логической связности – возникает, когда данные и функции собираются вместе по причине того, что попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не существует.
  3. Тип временной связности – элементы данного типа возникают вследствие того, что они представляют функции, связанные по времени, когда данные используются одновременно, или функции включаются параллельно, а не последовательно.
  4. Тип процедурной связности – возникает вследствие того, что функции выполняются в течение одной и той же части цикла или процесса.
  1. Тип коммуникационной связности – диаграммы демонстрируют такие связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные или производят одни и те же выходные данные.
  1. Тип последовательной связности – при данном типе связи выход одной функции служит входными данными для следующей функции.
  1. Тип функциональной связности – диаграммы данного типа отражают полную функциональную связность при наличии полной зависимости одной функции от другой.

Моделирование потоков данных (DFD).
В основе DFD лежит построение модели анализируемой системы в виде иерархии диаграмм потоков данных, которые описывают асинхронный процесс преобразования информации с момента её ввода в систему до момента её выдачи.

Диаграммы верхних уровней иерархии определяют основные процессы с внешними системами. Данные диаграммы детализируются при помощи диаграмм нижнего уровня.

Внешние сущности – это материальные объекты, которые представляют собой источники или приемники информации, свойства данных объектов находятся за пределами рассматриваемой системы.

Системы и подсистемы – при построении сложных систем система может быть представлена в самом общем виде, либо декомпозирована на подсистемы.

1 – Номер системы

3 – Имя проектировщика

Процессы – это преобразование входных потоков данных в выходные, в соответствии с определенным алгоритмом. На практике процесс может быть реализован в виде подразделения организации, которая выполняет обработку входных документов и выпускает отчеты. Изображается как подсистема, но в названии присутствует глагол.

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

DN – обязательно присутствует, N – порядковый номер накопителя.

Потоки данных – определяют информацию, подаваемую через какое-либо соединение от источника к приемнику.

Первым шагом при построении является построение диаграмм. Если система простая, то строится единственная диаграмма со звездообразной топологией.

Признаки сложной системы:

  1. Наличие большого числа внешних сущностей
  2. Распределенная природа системы
  3. Многофункциональность системы

При детализации диаграмм должны выполняться следующие условия:

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

Детализация завершается при выполнении следующих условий:

  1. Наличие у процесса небольшого количества входных и выходных потоков
  2. Возможность описания процессов системы в виде одного законченного алгоритма
  3. Выполнение процессом логических функций из входной в выходную

Метод Чена-Баркера
Суть моделирования по этому методу состоит в обеспечении разработчика концептуальной схемой БД в форме одной или нескольких моделей, которые могут быть легко отображены в систему БД любого типа.

Наиболее распространенным средством моделирования являются диаграммы ERD (диаграммы сущность — связь). С их помощью определяются, важные для предметной области БД, объекты (сущности) их свойства (атрибуты) и отношения друг с другом (связи). С помощью этих диаграмм проектируются реляционные БД.

Рассматривается деятельность компании по торговле автомобилями. Выделяются три основных лица персонала: главный менеджер – он должен знать, сколько заплачено за машину и какие расходы. На основе этих данных он устанавливает нижнюю цену продажи. Второе лицо – продавец. Ему необходимо знать, какую цену запрашивать, какая нижняя цена, и основную информацию о машине. Третье лицо – администратор. Его задача – составление контракта. Для этого ему нужна информация о покупателе, машине и продавце.

Первый шаг моделирования – извлечение информации и выделение сущностей.

Сущность – реальный или воображаемый объект, который имеет существенные значения для рассматриваемой области, информация о которой подлежит хранению.

Каждая сущность обладает свойствами:

  1. Уникальное имя
  2. Наличие атрибутов
  3. Наличие связей с другими сущностями

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

Различают несколько типов связей и обязательностей.

Следующим этапом моделирования является описание атрибутов системы. Атрибут – это любая характеристика сущности, значимая для рассматриваемой области и предназначенная для идентификации или классификации сущностей.

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

Атрибуты, которые определяют первичный ключ, размещаются вверху списка и выделяются знаком #.

Помимо перечисленных основных конструкций, модель данных может содержать ряд дополнительных характеристик. Существуют понятия подтипов и супертипов, т.е. одна сущность является обобщающей для группы подобных её сущностей.

Рекурсивная связь – сущность может быть связана сама с собой.

Неперемещаемая связь – т.е. экземпляр сущности не может быть перенесен из одного узла связи в другой.

МетодологииIDEF1X
Данный метод разработан Рамэем. Основан на подходе Чена и позволяет построить модель, эквивалентную данных реляционной модели в третьей нормальной форме. В настоящее время на основе методологии IDEF1 разработана IDEF1X, к которой были предъявлены следующие требования:

  1. Простота изучения
  2. Возможность автоматизации

На основе IDEF1X построен ряд CASE – средств, таких, как Erwin, Designer.

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

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

В методологии выделяют различные типы мощности связи:

1. Каждый экземпляр сущности – родителя может иметь 0, 1 или более связанных с ним сущностей экземпляров – потомков.

2. Каждый экземпляр сущности – родителя должен иметь не менее одного связанного с ним сущности – потомка.

3. Каждый экземпляр сущности – родителя связан с некоторым числом сущностей – потомков.

Пунктирный элемент изображает не идентифицирующую связь. Сущность – потомок в таком типе связи будет не зависимой от идентификатора при условии, что она является сущностью – потомком какой-либо идентифицирующей связи.

Идентифицирующая связь изображается сплошной линией. Сущность – потомок в таком типе связи является зависимой от идентификатора сущности.

Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, располагаются вверху и отделяются от других атрибутов горизонтальной чертой.

Сущности могут также иметь внешние ключи (FK), которые могут использоваться в качестве части или целого первичного ключа.

Архитектура ИС
Файл-серверная архитектура
Данная архитектура наиболее распространена по следующим причинам:

— сокращение автономности ПО клиента

— сохранение привычных условий для пользователя

При всей простоте организации необходимо учитывать особенности:

— при работе с БД необходимо учитывать особенности каждой выбранной СУБД;

— необходимо учитывать особенности поддержания целостности и надежности хранимой БД. Для этого должно выполняться:

  • Наличие транзакционного управления
  • Хранение избыточных данных
  • Возможность введения ограничений целостности и их проверку

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

  • На стороне «клиент» выполняется ввод приложения, в который обязательно входят компоненты, поддерживающие интерфейс с пользователем;
  • Клиентская часть приложения взаимодействует с клиентской частью СУБД, которая является представителем СУБД для приложения.

Интерфейс (ИФ) между клиентской частью приложения и клиентской частью сервера БД основан на использовании языка SQL. Функции предварительной обработки, предназначенные для запросов к БД или формирования конечных отчетов, выполняются в коде приложения. Клиентская часть сервера БД, используя средства сетевого доступа, обращается к серверу БД, передавая ему текст на языке SQL. На стороне сервера БД происходит компиляция полученных операторов на языке SQL, далее выполняются операторы, результаты обработки передаются клиентской части приложения и в конечном итоге – пользователю.

В клиент-серверной архитектуре клиенты могут быть достаточно «тонкими», а сервер д.б. настолько «толстым», чтобы удовлетворить запросы всех клиентов.

С другой стороны, пользователи данной архитектуры часто бывают не удовлетворены, в виду постоянно растущих сетевых расходов. Но на практике, как правило, пользователю необходим какой-то кусок БД, что приводит к идее поддержки локального кэша общей БД.

Концепция локального кэширования является частным случаем концепции реплицирования данных. Для поддержки локального кэша необходим компонент СУБД, который должен обеспечивать однопользовательский режим.

Для поддержки локального кэша необходимо выполнять его синхронизацию с основной БД. Это достигается двумя путями:

— автоматическая синхронизация, путем использования триггеров (через определенные промежутки времени)

— в ручном режиме

Архитектура клиент-сервер является более дорогой по сравнению с файл-серверной, требуется более мощная аппаратура для сервера и более развитые СУБД.

Однако наряду с этим недостатком, существует основное достоинство данной архитектуры, заключающееся в масштабируемости системы и способности к развитию.
Internet– приложение
IntraInternet – архитектура базируется на протоколе http. Данная служба получила широкое распространение по ряду причин:

  • Достаточно просто разработать ИС, а затем осуществить доступ по данному методу
  • Наличие готовых клиентских частей (браузеры)

Наряду с этими достоинствами существует ряд ограничений:

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

На настоящий момент логика приложения реализуется с помощью двух подходов: CGI, API. Оба подхода основываются на наличии специальных конструкций, информирующих клиента браузера, что ему следует послать веб-серверу специальное сообщение. При получении сообщения сервер должен вызвать внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном виде.

Данный метод доступа используется для обеспечения доступа к БД в Интернет системах. Язык HTML позволяет вставлять в документ необходимые формы. Когда браузер встречает форму, он предлагает пользователю заполнить её, а затем посылает серверу сообщение, которое содержит введенные параметры. Как правило, к сообщению приписывается внешняя процедура сервера. При получении сообщения от клиента сервер вызывает указанную процедуру и передает ей параметры, введенные пользователем. Таким образом, процедура играет роль шлюза между веб-сервером и сервером БД.

Системы оперативной обработки данных (OLAP — системы)
OLAP системы – аналитические системы, помогающие принимать бизнес-решения за счет динамически проводимых анализов моделирования или прогнозирования данных.

Данные системы использую в случаях:

  1. Если основным источником информации является деятельность какой-либо корпорации
  2. Если для оперативной обработки требуются свежие данные
  3. Если одновременно существуют несколько ОС
  4. Если БД являются сильно изменчивыми
  5. Если информация БД настолько критична для корпорации, что для ее защиты требуются более тонкие приемы защиты.

Склады данных (Data Ware Housing)
Хранилища такого типа наиболее актуальны. Они характеризуются большим объемом редко изменяемых данных. Хранилища могут обмениваться информацией с другими хранилищами (VLBD – очень большие хранилища данных)

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

Хранилища используются для прогнозирования развития бизнеса. Они оснащаются средствами аналитической обработки информации. Хранилища состоят из:

  1. Программное обеспечение источников данных
  2. Загрузочная секция (отвечает за трансформацию информации)
  3. Программное обеспечение трансформации данных (пересылка, проверка на корректность)
  4. Хранилища данных (несколько параллельных серверов БД, которые обеспечивают переработку информации и хранение)
  5. Интерфейс клиента

Истоки возникновения Case средств

Современные проекты характеризуются следующими особенностями:

  1. Сложность описания данных и взаимосвязи между ними
  2. Наличие совокупности тесно взаимосвязанных компонентов
  3. Отсутствие прямых аналогов
  4. Функционирование в неоднородной аппаратной среде

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

  1. Неадекватная спецификация требований
  2. Неспособность обнаруживать ошибки в проектных решениях
  3. Низкое качество документации
  4. Затяжной цикл и не удовлетворительные результаты тестирования

Первоначальное значение термина Case средства ограничено вопросами автоматизации.

Case технология представляет собой методологию, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать её и сопровождать.

В связи с применением Case средств необходимо учитывать:

1. Case средства не дают немедленный эффект внедрения

2. Реальные затраты на внедрение Case средств превышают затраты на приобретение

3. Case средства обеспечивают возможность для получения выгоды только после успешного их внедрения.

Для успешного внедрения Case средства организация должна обладать определенными качествами, особенно в следующих областях:

  1. Область технологии, т.е. понимание ограниченных возможностей и способность принять новую технологию
  2. Область культуры, т.е. готовность к внедрению новых процессов и взаимоотношений между персоналом
  3. Область управления, т.е. четкое руководство и организованность

Если организация не обладает хотя бы одним качеством, то внедрение закончится неудачей, не смотря на тщательность следования указанию по внедрению.

При внедрении Case средств необходимо отметить ряд проблем:

  1. Отсутствие полного соответствия между процессами и методами, которые поддерживают Case средства и которые используются в организации.
  2. Некоторые Case средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте
  3. Негативное отношение персонала к использованию новых Case средств

Основные понятия Case технологий
Case технологии включают в себя методы, с помощью которых строятся диаграммы, которые поддерживаются инструментальной средой.

^ Метод — процедура или техника генерации описания компонентов системы.

Нотация – отображение структуры системы, элементов данных, этапов обработки, а также описание проекта системы на формальных и естественных языках.

^ Инструментальные средства Case – это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Архитектура Case средств

  • Ядром системы является репозиторий. Он представляет собой специализированную БД, которая используется для отображения состояния системы в любой момент времени. Репозиторий содержит информацию о всех объектах проектной ИС. В репозитории хранятся описания следующих объектов:
  1. Имена проектировщиков и их права доступа
  2. Организованные структуры
  3. Компоненты диаграмм и диаграммы в целом
  4. Структуры данных
  5. Взаимосвязи между диаграммами
  6. Программные модули, процедуры и библиотеки модулей
  • ГРД используется для отображения в графическом виде заданной нотации проектной ИС. Он позволяет выполнять следующие операции:
  1. Создавать элементы диаграмм и взаимосвязи между ними
  2. Задавать описание элементов диаграмм

  3. Редактирование элементов диаграмм и их взаимосвязь
  • Верификатор диаграмм – используется для контроля правильности построения диаграмм заданной методологии проектирования. Он выполняет следующие функции:
  1. Мониторинг правильности построения диаграмм
  2. Диагностика и выдача сообщений об ошибках
  3. Выделение на диаграмме ошибочных элементов
  • Документатор – позволяет получить информацию о состоянии объекта в виде различных отчетов.
  • Администратор проекта – инструменты, необходимые для выполнения следующих функций:
  1. Инициализация проекта
  2. Задание начальных параметров проекта
  3. Назначение и изменение прав доступа к объектам проекта
  • Сервис – набор системных утилит для обслуживания репозитория.

В область Case средств попадают как относительно дешевые системы с ограниченными возможностями, так и дорогостоящие системы, которые охватывают целиком процесс создания системы.

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

  1. Наличие БД, архива или словаря
  2. Интерфейсы с другими Case системами
  3. Возможности экспорта и импорта информации
  4. Открытая архитектура
  5. Наличие необходимых методологий
  6. Графические средства поддержки проекта
  7. Генерация кода программа
  8. Планирование и управление проектом

К Case средствам относят любое ПО, автоматизирует совокупность ЖЦ и обладает следующими характеристиками:

1. Мощное графическое средство для описания ИС, которое обеспечивает удобство работы пользователя

2. Интеграция отдельных компонентов с Case средства

3. Использование организованного хранилища проектных метаданных
Классификация Case средств
Все Case средства могут быть классифицированы по типам и категориям. Классификация по типам отражает функциональность Case средств. Классификация по категориям отражает степень интегрированности.

  • Современные Case системы классифицируются по следующим категориям:

1. По поддерживаем методологиям

— функциональный или структурно-ориентированный

2. По поддерживаем графическим нотациям

3. По степени интегрированности

4. По типу и архитектуре вычислительной техники

5. По типу коллективной разработки

6. По типу операционной среды

  • Классификация по типам:
  1. Средства анализа (Design, BpWin)
  2. Средства анализа и проектирования (Designer 2000 — Oracle)
  3. Средства проектирования БД (ErWin, Designer 2000 — Oracle)
  4. Средства разработки приложений (Developer 2000 – Oracle, Delphi)
  5. Средства реинженеринга (ErWin, Rational Rose)

Оценка и выбор Case средств
Процесс оценки и выбора может преследовать несколько целей:

— оценка нескольких Case средств и выбор одного

— оценка нескольких Case средств и сохранение результата для последующей оценки

— выбор одного или нескольких Case средств с использованием результатов предыдущих оценок.

1 – уточнение критериев

2 – оценка Case средств

3 – выбор Case средств

4 – список критериев

5 – пользовательские потребности

6 – цели предположения и ограничения

7 – доступные Case средства

8 – уточненный список критериев

9 – потребность в дополнительной информации

10 – результаты оценки

11 – рекомендуемое решение
Входной информацией для процесса оценки является:

  1. Определение пользовательских потребностей
  2. Цели и ограничения проекта
  3. Данные о доступных Case средствах
  4. Список критериев, используемых для оценки

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

Определение списка критериев основано на пользовательских требованиях и включает:

1. Выбор критериев для использования из приведенного списка

2. Определение области использования каждого критерия

3. Назначение удельного веса каждому критерию
Процесс оценки
Целью процесса оценки – является определение функционирования и качества Case средств для последующего выбора. Оценка выполняется в соответствии с выбранными критериями и включает в себя следующие действия:

1. Формулировка задачи

2. Определение критериев оценки

3. Определение средств кандидатов

4. Оценка средств кандидатов на основе критериев

5. Подготовка отчета по результатам оценки

Список Case средств формируется на основе информации из различных источников. Следующим шагом является получение информации о каждом Case средстве.

Все выбранные Case средства оцениваются по двум критериям:

        1. Объективные критерии, оценка выполняется путем воспроизведения процедуры с той целью, чтобы любой специалист мог получить те же результаты.
        2. Субъективные критерии. Case средства оцениваются группой специалистов, которые используют одни и те же критерии.

Данный этап заканчивается заключением в виде оценки Case средств. Выполняется в виде отчета, который содержит:

  1. выбранные подходы и оценки
  2. информация о Case средствах кандидатах
  3. этапы оценки
  4. конкретные результаты оценки
  5. выводы и заключения

Процесс выбора
Процесс выбора включает следующие действия:

  1. формулировка задачи выбора
  2. выполнение всех необходимых действия по выбору
  3. выполнение необходимого количества итераций с целью выбора Case средств имеющих схожие результаты
  4. подготовка отчета по результатам выбора

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

1. числовые меры в широком диапазоне

2. числовые меры в ограниченном диапазоне

3. двоичные меры

4. меры, которые могут принимать одно или более значений

2 – простота использования

5 – общие критерии

7 – функциональные характеристики

8 – среда функционирования

9 – проектная среда

11 – технологическая среда

12 – функции, ориентированные на фазы ЖЦ

16 – общие функции

18 – управление конфигурацией

19 – управление проектом
Выполнение пилотного проекта
Перед масштабным внедрением выбранного Case средства в организации выполняется пилотный проект. Целью такого проекта является экспертная проверка правильности решений, принятых на предыдущих этапах, и начальная подготовка к внедрению.

Пилотный проект представляет собой первоначальное реальное использование Case средства, он преследует следующие цели:

1. подтверждение результатов оценки

2. сбор необходимой информации для внедрения Case средств

3. накопление собственного опыта в использовании Case средств

1 – определение характеристик ПП

2 – планирование ПП

3 – выполнение ПП

5 – принятие решения о внедрении

6 – внедрение Case средств

7 – выполнение дополнительного ПП

8 – отказ от внедрения

ПП должен обладать следующими характеристиками:
1. Требуемая область применения

6. Характеристики проектной мощности
Планирование ПП должно по возможности вписываться в процесс разработки организации. План должен содержать следующие пункты:

1. Цели, задачи, критерии оценки

3. Процедуры и соглашения

5. График и ресурсы

После завершения ПП, его результаты необходимо оценить и сопоставить с начальными потребностями организации.

В результате оценки организация должна определиться в ответах на следующие вопросы:

1. Целесообразно ли внедрять Case средства

2. Какие конкретные особенности ПП привели к его успеху

3. Какие проекты или подразделения организации могли получить выгоду от внедрения Case средств

После ответа на них, принимается решение о внедрении Case средства. Варианты могут быть следующими:

1. Внедрить Case средство

2. Выполнить дополнительный ПП

3. Отказаться от внедрения Case средства

4. Отказаться от использования Case средства вообще

После оценки результатов внедрения Case средства, организация оценивает – реально ли повысилась производительность разработки ПО. Для оценки используются следующие критерии:

  1. Используемое время
  2. Время, выданное для конкретного специалиста
  3. Размер, сложность и качество ПО
  4. Удобство сопровождения ПО

Конспект лекций по дисциплине «Проектирование информационных систем»

ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра компьютерного моделирования и дизайна

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

Лекция1. Теоретические основы проектирования АИС

1 Основные понятия дисциплины и их взаимосвязь.

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

Понятие «проект» является основным в дисциплине «Управление проектами».

«Проект — это ограниченное во времени целенаправленное изменение отдельной системы с установленными требованиями к качеству результатов, возможными рамками расхода средств и ресурсов и спецификой организации». Т. е. под проектом понимается некоторый процесс изменения. Разработка и внедрение ИС относятся к классу инновационных проектов.

Итак, существуют различные определения и понимание термина «проект», как комплекса документации и как процесса.

В случае разработки и внедрения информационных систем (ИС) происходит изменение некоторой предметной области с целью повышение эффективности ее функционирования. Следовательно, понятия «проект» и «проектирование» используются в более широком смысле, чем при разработке технических систем.

В [1] дается следующее определение, которое будем считать основным в случае разработки ИС.

“Под проектом ИС будем понимать проектно-конструкторскую и технологическую документацию, в которой представлено описание проектных решений по созданию и эксплуатации ИС в конкретной программно-технической среде.”.

“Под проектированием ИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект ИС”.

Необходимо дать определение ИС. Cледует отметить, что не существует общепринятого определения ИС.

В литературе чаще всего встречаются следующие термины: «информационная система», «экономическая информационная система», «автоматизированная система управления’, ‘автоматизированная информационная система». Существует множество определений этих понятий, используемых в различных источниках. Рассмотрим эти понятия применительно к экономическим объектам.

Определение, приведенное в учебнике по данной дисциплине [1], будем рассматривать в качестве основного.

«Информационная система (ИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления».

В следующей лекции мы рассмотрим также и некоторые другие определения.

ИС моделирует предметную область или экономическую систему (ЭС).

Процесс проектирования должен обеспечить выполнение требований к ИС. Наиболее общими являются следующие требования к ИС:

удовлетворяет функциональным требованиям (возможно неформальным); имеет приемлемую цену; удовлетворяет требованиям по эксплуатационным харак­теристикам (явным и неявным); удовлетворяет критериям дизайна (явным и неявным); удовлетворяет требования к самому процессу разработки, таким, например, как стоимость и продолжительность.

Итак, возникает вопрос, что именно необходимо проектировать, т. е. какова структура объекта проектирования.

Объектом проектирования может быть корпоративная ИС, ее отдельные элементы или подсистемы. В общем виде в ИС выделяют два вида подсистем: функциональные и обеспечивающие. Функциональные способствуют реализации цели экономической системы, обеспечивающие — обеспечивают их функционирование. Состав функциональных подсистем определяется особенностями экономической системы. Примером функциональных подсистем является «Управление персоналом», «Бухгалтерский учет» и т. д. Примером обеспечивающих подсистем является «информационное обеспечение», «программное обеспечение» и т. д. Всего в соответствии с ГОСТ34.003-90 выделяют 9 видов обеспечения. Документы проекта должны описывать проектные решения по разрабатываемым подсистемам и видам обеспечения.

Рассмотрим экономическую систему (ЭС), моделью которой является ИС. Любая ЭС является целенаправленной, т. е. реализует некоторую цель. Целенаправленная деятельность невозможна без управления. ИС поддерживает выполнение функций управления: прогнозирование, планирование, учет, анализ, контроль и регулирование. Цель ЭС реализуется в некоторых процессах, которые называют бизнес-процессами, хозяйственными процессами и др.

«Под бизнес-процессом будем понимать совокупность взаимосвязанных операций (работ) по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов».

В структуре ЭС мы выделяем, прежде всего, структуру бизнес-процессов, функциональную и организационную. Основной эффект дает не автоматизация существующих бизнес-процессов, а разработка новых на основе использования возможностей НИТ (новых информационных технологий). Это направление называется «Реинжиниринг бизнес-процессов».

Разработка ИС должна сопровождаться анализом существующих процессов и их улучшением, насколько это возможно. Необходима модель бизнес-процессов для разработки ИС. На практике часто отсутствует описание существующих процессов и проектирование необходимо начинать с изучения текущего состояния ЭС.

Мы рассмотрели очень коротко представление о том «ЧТО» проектировать, и переходим к вопросу »КАК», т. е. о процессе проектирования. Определение было дано выше.

Основным в процессе проектирования является понятие жизненного цикла (ЖЦ).

«Жизненный цикл — совокупность стадий и этапов, которые проходит ИС в своем развитии, от момента принятия решений о создании системы, до момента прекращения функционирования».

Практически во всех подходах выделяют следующие стадии разработки:

1) планирование и анализ требований (предпроектная стадия);

2) проектирование (техническое, логическое);

3) реализация (рабочее проектирование);

5) эксплуатация (сопровождение, модернизация).

Осуществление проектирования предполагает использование проектировщиками определенной технологии проектирования, соответствующей масштабам и особенностям разрабатываемого проекта.

Технология проектирования ИС — это совокупность методологии и средств проектирования, а также методов и средств организации и управления процессом проектирования. В основе технологии проектирования лежит технологический процесс, который определяет проектные операции, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих операций. Технологии должны давать ответы на вопросы не только «ЧТО» должно быть сделано, но и «КАК «, «КЕМ» и в «КАКОЙ» последовательности.

Требования, предъявляемые к технологии:

1) созданный с помощью этой технологии проект должен удовлетворять требованиям заказчика

2) технология должна максимально отражать все этапы жизненного цикла

3) должна обеспечивать минимизацию трудовых и стоимостных затрат на проектирование и сопровождение

4) должна быть основой связи между проектировщиками и сопровождением проекта

5) должна способствовать росту производительности труда проектировщиков

6) должна обеспечивать надежность процесса проектирования и эксплуатации

7) должна способствовать надежному ведению проектной документации

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

Существуют различные методы проектирования: ручное и автоматизированное, оригинальное и типовое и т. д.

Существуют два основных класса методологий проектирования: структурные и объектные. Эти методологии отличаются способами декомпозиции системы: функциональной и объектной.

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

Различают каноническую и индустриальные технологии проектирования. Каноническая означает использование методов ручного, индивидуального проектирования. Индустриальные технологии подразделяются на автоматизированные и типовые.

Существуют различные средства автоматизации — от языков программирования, СУБД и до CASE-систем.

Современный этап развития методов проектирования — это автоматизация процесса проектирования, на основе применения CASE-систем (Computer Aide System Engineering).

В настоящее время продолжается развитие методологий и технологий проектирования в связи с усложнением систем и изменением требований к ним. Одним из направлений является моделирование и перепроектирование процессов бизнеса, которые поддерживают информационные системы (реинжиниринг бизнес-процессов), на основе использования новых сетевых информационных технологий, таких как «Клиент-сервер» и «Интранет».

2 Определение основных понятий дисциплины

Для нас основными являются понятия, которые входят в название дисциплины и прежде всего понятия «информационная система», « экономическая информационная система ». С понятиями «проект» и «проектирование» и некоторыми другими мы познакомились ранее.

В литературе чаще всего встречаются следующие термины: «информационная система», «экономическая информационная система», «автоматизированная система управления’, ‘автоматизированная информационная система». Существует множество определений этих понятий, используемых в различных источниках. Рассмотрим эти понятия применительно к экономическим объектам.

Система: совокупность элементов, объединенная связями между ними и обладающая определенной целостностью.

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

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

Экономическая информационная система (ИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления.

Это определение, приведенное в учебнике по данной дисциплине [1], будем рассматривать в качестве основного.

Рассмотрим также и другие определения.

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


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

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

В ГОСТ 34.003-90 «Комплекса стандартов и руководящих документов на автоматизированные системы» дается определение автоматизированной системы.

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

Это определение применимо к различным сферам деятельности — управлению, проектированию, управлению технологическими процессами.

В области организационного управления используется следующее определение:

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

Можно также привести некоторые другие определения, используемые в литературе.

Информационная система (ИС)- система, предназначенная для хранения, поиска, обработки и выдачи информации по запросам пользователей.

Экономическая информационная система — система, предназначенная для хранения, поиска, обработки и выдачи экономической информации по запросам пользователей.

Информационная система — система, реализующая автоматизированный сбор, обработку и манипулирование данными и включающая технические средства обработки данных, программное обеспечение и соответствующий персонал.

Информационная технология: приемы, способы и методы применения средств вычислительной техники при выполнении функций сбора, хранения, обработки и использования данных.

2. Классификация АИС

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

2.1. По функциональному назначению

Информационные системы целесообразно разделить на три группы:

1) системы информационного обеспечения

2) системы, имеющие самостоятельное значение

3) интеллектуальные системы.

Системы информационного обеспечения являются компонентами автоматизированных систем управления в любой области. Они отображают информацию о предметной области, обеспечивают информационные потребности управления. Являются наиболее динамичными и сложными. Среди них выделяют системы-OLTP (оперативной обработки транзакций) и OLAP(оперативной аналитической обработки).

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

К системам, использующим достижения в области искусственного интеллекта относятся:

4) поддержки принятия решений;

2.2. По виду управляемого процесса:

1) АСОУ — автоматизированные системы организационного управления;

2) АСУТП — автоматизированные системы управления технологическими процессами;

3) АСУГПС — автоматизированные системы управления гибкими производственными системами.

2.3. В зависимости от сферы автоматизации АС подразделяются (в соответствии РД 50-680-88 »Автоматизированные системы. Основные положения»):

1) автоматизированные системы управления (АСУП, АСУТП, АСУГПС, ОАСУ и др.) ;

2) системы автоматизированного проектирования (САПР);

3) автоматизированные системы научных исследований (АСНИ);

4) АС обработки и передачи информации (АСОИ);

5) АС технологической подготовки производства (АСТПП);

6) АС контроля и испытаний (АСК);

7) системы, автоматизирующие сочетание различных видов деятельности.

2.4. По виду объекта управления

Понимается принадлежность к определенной сфере деятельности (отрасли экономики):

1) промышленность (АСУП, ОАСУ, КИС и т. д.);

2) сельское хозяйство;

3) строительство (АСУС);

4) транспорт ( ж-д, авто, авиа);

5) финансово-экономические (банки, страховые компании и др.);

8) образование (школы, ВУЗы, др.);

9) коммерческие (торговля, обслуживание и др.);

10) административные (органов гос. управления);

11) общественно — политические;

13) оборонные(ПВО, Военкоматы, др.).

2.5. По уровню управления

1) государственные, федеральные (статистика, выборы и т. д.);

3) региональные (территориальные);

6) отдельных объектов;

2.6. По степени автоматизации

Делятся на два класса: автоматические и автоматизированные. В автоматических все операции управления осуществляются без помощи человека. Человек только контролирует. В автоматизированных, часть функций выполняет человек, часть — компьютер.

2.7. По уровню автоматизации

Делят на три класса:

В информационно-управляющих автоматизируются информационные процессы и некоторые процессы принятия решений. Самонастраивающиеся способны менять алгоритмы принятия решений при изменении условий, способны учитывать опыт. Самообучающиеся могут менять структуру самой системы.

2.8. В зависимости от охвата уровней и функций управления

Классификация выполняется на уровне отдельных объектов. Различают корпоративные (интегрированные) и локальных ИС.

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

2. Локальная ИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ИС может быть однопользовательской, функционирующей в отдельном подразделении.

2.9. По характеру обработки информации на различных уровнях управления экономической системой

Выделяют три уровня управления — оперативный, тактический и стратегический.

В соответствии с характером обработки данных на различных уровнях управления выделяют следующие типы ИС:

1. Системы обработки данных (СОД, EDP-electronic data processing), предназначенные для решения задач оперативного управления деятельностью экономического объекта;

2. Информационные системы управления (ИСУ, MIS — Management information system) — ориентированы на тактический уровень управления. Например, на среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев). Предназначены для руководства различных служб и используют оперативные данные, накапливаемые в системах СОД(OLTP).

3. Системы поддержки принятия решений (СППР, DSS — desigion suuport system) — используются в основном на верхнем уровне управления (руководством фирм, предприятий и организаций), для решения задач, имеющих стратегическое значение. Например, формирование стратегических целей, планирование привлечения ресурсов и т. д.

Лекция 2. Архитектура АИС

1 Особенности сложных экономических систем

Основными объектами экономики являются предприятия, банки, учреждения, административные органы и т. д. Все они являются сложными экономическими системами. Сложные экономические системы характеризуются:

1. Большим количеством составных элементов, связанных между собой каналами передачи информации.

2. Иерархической структурой.

3. Целенаправленностью. Общей целью (или несколькими целями) для всей системы, частными целями для систем более низкого порядка.

4. Наличием людей в качестве основных элементов управления, принятия решений и контроля исполнения, т. е. способностью к управлению и самоуправлению.

5. Изменением структуры и процесса функционирования системы с течением времени.

6. Эмерджентность, которая означает что свойства системы не сводятся к сумме свойств ее элементов.

2 Состав и структура экономической системы (ЭС)

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

1)планирование — функция, определяющая цель функционирования ЭС на различные периоды времени (стратегическое, тактическое, оперативное планирование);

2) учет — функция, отображающая состояние объекта управления в результате выполнения хозяйственных операций;

3)контроль — функция, с помощью которой определяются отклонения учетных данных от плановых целей и нормативов;

4)оперативное управление — функция, осуществляющая регулирование всех хозяйственных процессов с целью исключения возникающих отклонений в плановых и учетных данных;

5) анализ — функция, определяющая тенденции в работе экономической системы и резервы, которые учитываются при планировании на следующий временной период.

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

Структура экономической системы (промышленного предпри­ятия, торговой организации, коммерческого банка, государствен­ного учреждения и т. д.) с позиций кибернетики представлена на рис. 1.1, где основные информационные потоки между внешней средой, объектом и системой управления помечены метками над стрелками ИП1, ИП2, ИПЗ, ИП4 и связаны с поддерживающей их экономической информационной системой (ИС).

Экономическая информационная система (ИС) — представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления.

ИС связывает ОУ и СУ между собой и с внешней средой при помощи информационных потоков (ИП):

ИП1- из внешней среды в систему управления. Представляет собой поток законодательной и нормативной информации, а также о конъюнктуре рынка, создаваемой конкурентами, потребителями и поставщиками;

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

ИП3- информационный поток из системы управления на объект управления (прямая кибернетическая связь), представляет совокупность плановой, нормативной и распорядительной информации для осуществления хозяйственной деятельности;

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

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

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

2 Структура АИС.

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

Организационная структура определяет наличие подразделений различного уровня и их взаимное административное подчинение.

Управление обычно основано на разделении управленческого труда по группам функций.

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

Подсистемой называют выделенную по определенному признаку часть системы.

Функциональной подсистемой называют часть системы, выделенную по функциональному признаку.

Функциональная подсистема ИС представляет собой комплекс экономических задач с высокой степенью информационных обменов (связей) между задачами.

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

В функциональных подсистемах создаются условия для реализации цели системы.

Обеспечивающие подсистемы являются общими для всей ИС и обеспечивают функционирование ИС. Их называют видами обеспечения. В общем случае выделяют следующие виды обеспечения (ГОСТ34.003-90):

Организационное Методическое Информационное Программное Математическое Лингвистическое Техническое Правовое Эргономическое. Технологическое (нет в ГОСТе)

3 Виды обеспечения АС

Определения видов обеспечения даются согласно ГОСТ34.003-90.

3.1 Организационное обеспечение (ОО)

Совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала АС в условиях функционирования, проверки и обеспечения работоспособности АС.

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

В составе ОО ИС выделяют 4 группы компонентов:

1. Первая группа включает важнейшие методические материалы, регламентирующие процесс создания и функционирования системы:

общеотраслевые руководящие методические материалы по созданию ИС; типовые проектные решения; методические материалы по организации и проведению предпроектного обследования на предприятии; методические материалы по вопросам создания и ведения проектной документации.

2. Вторым компонентом в структуре организационного обеспечения ИС является совокупность средств, необходимых для эффективного проектирования и функционирования ИС (комплексы задач управления, включая типовые пакеты прикладных программ, типовые структуры управления предприятием, унифицированные системы документов, общесистемные и отраслевые классификаторы и т. д.).

3. Третьим компонентом подсистемы организационного обеспечения является техническая документация, получаемая в процессе обследования, проектирования и внедрения системы: технико-экономическое обоснование, техническое задание, технический и рабочий проекты и документы, оформляющие поэтапную сдачу системы в эксплуатацию.

4. Четвертым компонентом подсистемы организационного обеспечения является «Персонал», где представлена организационно-штатная структура проекта, определяющая, в частности, состав главных конструкторов системы и специалистов по функциональным подсистемам управления.

Совокупность документов, описывающих технологию функционирования АС, методы выбора и применения пользователями технологических приемов для получения конкретных результатов при функционировании АС.

3.3 Информационное обеспечение (ИО)

Совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой, а АС при ее функционировании.

В [1] дается следующее определение. Подсистема “Информационное обеспечение” (ИО) – это совокупность единой системы классификации и кодирования технико-экономической информации, унифицированной системы документации и информационной базы. В составе ИО выделяют внемашинное ( классификаторы ТЭИ и документы) и внутримашинное информационное обеспечение (экранные формы, файлы, базы данных). Центральным компонентом ИО является база данных, которая обеспечивает интегрированное использование различных информационных объектов в функциональных подсистемах.

Программное обеспечение (ПО)

Совокупность программ на носителях данных и программных документов, предназначенных для отладки, функционирования и проверки работоспособности АС.

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

Совокупность математических методов, моделей и алгоритмов, применяемых в АС.

Лингвистическое обеспечение (ЛО)

Совокупность средств и правил для формализации естественного языка, используемый при общении пользователей и эксплуатационного персонала АС с комплексом средств автоматизации при функционировании АС.

Языковые средства, включенные в подсистему ЛО, делятся на две группы: традиционные языки (естественные, математические, алгоритмические языки, языки моделирования) и языки, предназначенные для диалога с ЭВМ (информационно-поисковые языки, языки СУБД, языки операционных сред, входные языки пакетов прикладных программ )

Совокупность всех технических средств, используемых при функционировании АС.

В состав комплекса технических средств входят ЭВМ, средства подготовки данных, средства сбора и регистрации информации, средства передачи данных по каналам связи, средства накопления и хранения данных и выдачи результатной информации, вспомогательное оборудование и организационная техника.

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

Подсистема “Правовое обеспечение” (ПРО) предназначена для регламентации процесса создания и эксплуатации ИС, которая включает совокупность юридических документов с констатацией регламентных отношений в процессе функционирования системы.

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

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

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

3.10 Технологическое обеспечение ИС

Подсистема «Технологическое обеспечение ИС» соответствует разделению ИС на подсистемы по технологическим этапам обработки различных видов информации:

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

Все обеспечивающие подсистемы связаны между собой и с функциональными.

Не все виды обеспечения выделяют в отдельную часть и оформляют на нее проектную документацию. Чаще всего организационное и методическое обеспечение разрабатываются вместе (ОМО) и оформляют единый документ. Математическое обеспечение включают в программное. Проектные документы оформляются только на виды обеспечения по которым были приняты какие-либо проектные решения.

Лекция 3. Принципы создания АИС. Этапы развития АИС и методов их разработки. Классификация методов и технологий проектирования

1 Принципы создания АИС

Рассмотренные особенности предопределяют сложность разработки ИС. Невозможно построить модель сложного объекта. В настоящее время сформулированы основные принципы, которыми необходимо руководствоваться при разработке АИС. Принципы формулировались в течение всего периода создания АИС.

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

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

1.1 Общесистемные принципы

К общесистемным относятся:

Системный подход Системная адаптация и непрерывность развития Межсистемная и внутрисистемная совместимость Соответствие управляющей и управляемой систем Рациональная централизация и децентрализация Человеко-машинное функционирование

1.1.1 Системный подход

Является важнейшим при создании любой сложной системы. Системный подход определяет методологию построения любой сложной системы. В соответствии с этим подходом разработка любой сложной системы должна включать следующие этапы:

Определение цели системы Определение функций Рассмотрение внешних связей Определение структуры. Определение состава и взаимосвязей элементов (подсистем) Определение конструкции или внутреннего устройства каждой подсистемы Каждый элемент может рассматриваться как система и к ней применимы предыдущие этапы системного подхода

Системный подход позволяет производить многоуровневую декомпозицию, строить иерархические структуры, моделировать систему. В современных системах проектирования АИС широко используются методологии структурного системного анализа и проектирования.

1.1.2 Принцип адаптации и непрерывного развития

Любая система, чтобы быть жизнеспособной должна учитывать изменение внешних и внутренних условий, быть гиб ой и адаптивной.

Адаптация-это процесс приспосабливания системы к8изменению внешних условий, обеспечивающий наиболее эффективный точки зрения цели системы режим ее функционирования.

При разработке системы необходимо учитывать перспективы развития всех составляющих информационной системы и предметной области.

1.1.3 Принцип межсистемной и внутрисистемной совместимости

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

1.1.4 Соответствие управляющей и управляемой систем

Управляющая система должна учитывать особенности объекта управления. Если есть противоречия между объектом и системой управления, то неизбежны потери, снижение эффективности вплоть до полной остановки функционирования.

1.1.5 Рациональная централизация и децентрализация управления

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

1.1.6 Человеко-машинное функционирование

Процесс принятия решений нельзя автоматизировать полностью. Решения должны вырабатываться в процессе взаимодействия человека и компьютера.

1.2 Организационные принципы

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

К организационным принципам относятся следующие:

Принцип первого руководителя Обязательное участие заказчика в работах по созданию системы Поэтапная разработка и внедрение Приведение в соответствие организационной структуры с потребностями АС Подготовка персонала к работе в новых условиях Принцип разумной типизации

1.2.1 Принцип первого руководителя

Этот принцип был сформулирован на основе анализа опыта разработки АСУП. Согласно этому принципу, руководство работами по созданию, внедрению и совершенствованию АИС должен возглавлять первый руководитель и это руководство не должно быть чисто формальным. Если же руководитель лишь формально наблюдает за ходом работ, большого эффекта ожидать трудно. В этом случае автоматизируется решение не самых главных задач, а тех, которые легче поддаются автоматизации. Может быть также случай, когда инициативный руководитель более низкого ранга (например, главный бухгалтер) ориентирует систему на решение локальных задач в соответствии со своими представлениями. Главный руководитель рассматривает объект как единое целое, определяет перспективы развития, принимает ответственные решения, согласует цели отдельный подразделений. Применение новых информационных технологий неизбежно приводит к перераспределению обязанностей и ответственности работников, вносит изменения в систему и методы работы. Наибольшие возможности по проведению в жизнь изменений имеет руководитель.

1.2.2 Обязательное участие заказчика в работах по созданию системы

АИС создается для конечных пользователей. Конечный эффект зависит от пользователей, а не от разработчиков АИС. Разработчики должны обеспечить, например, эффективность обработки данных.

1.2.3 Поэтапная разработка и внедрение

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

1.2.4 Приведение в соответствие структуры управления потребностям АСУ

При автоматизации управления происходит переход от старой к новой модели управления. Необходимо привести организационную структуру аппарата управления в соответствии с новой моделью.

1.2.5 Подготовка персонала к работе в новых условиях

Процесс подготовки персонала должен сопровождать весь ход разработки АИС. В процессе разработки должно осуществляться:

совместное формулирование задач управления конечными пользователями и разработчиками; непрерывное информирование о ходе работ, трудностях и результатах; обучение пользователей новым методам работы; совместное экспериментальное решение задач; знакомится с опытом внедрения аналогичных систем.

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

1.2.6 Принцип разумной типизации

В технике типизация и унификация изделий и их отдельных частей позволяет снизить затраты и повысить их производства. Затраты на проектирование тоже можно сократить, использовав типовой проект, разработанный для данного класса организаций и предприятий. Можно говорить о типовой АИС каждого класса объектов, о типовой организационной и информационной моделях, типовом программном, информационном и техническом обеспечении. Труднее всего поддаются типизации процессы принятия решений.

1.3 Экономические принципы

Экономические основы создания АИС раскрываются в экономических принципах. К ним относятся следующие:

1.3.1. Обеспечение ведущей роли экономики.

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

1.3.2. Принцип оптимальности.

Означает ориентацию на достижение максимальной эффективности за счет оптимизации принимаемых решений. База оптимизации состоит в использовании экономико-математических методов, моделирования.

1.3.3. Обоснование экономической эффективности.


Затраты должны окупаться.

1.3.4. Социально-психологические принципы

Необходимо обеспечить заинтересованность коллектива, а также учитывать индивидуальные особенности пользователей.

2 Этапы развития АСУ (АИС) и методов их разработки

Всего в развитии АИС можно выделить 4 этапа, в соответствии с этапами развития ЭВМ, ПО и концепции АСУ.

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

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

Таким образом, первый этап характеризуется появлением методов индивидуального и типового проектирования. Он завершился в начале 70-х годов с появлением Общеотраслевых Руководящих Материалов по созданию АСУ (ОРММ), в которых обобщался опыт разработки некоторых разработчиков.

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

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

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

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

Объектное (модельное) проектирование заключается в создании типовой АСУ для определенного класса объектов. Система создается для некоторого обобщенного объекта определенного класса, что требует создания модели объектов данного класса. Например, в АСУ «Сигма», разработанной для класса предприятий с дискретным характером производства, был выделен набор параметров, с помощью которых выполнялась настройка на параметры конкретного предприятия.

Третий этап характеризуется появлением персональных ЭВМ, развитием теории реляционных БД, появлением концепции интегрированных, комплексных автоматизированных систем, объединяющих в единое целое АСУ, АСУТП и ГПС. Автоматизация распространялась в непромышленные области. Централизовваныые системы и централизованная обработка информации перестают удовлетворять пользователей. Появляется понятие АРМ, как программно-технического комплекса АС, предназначенного для автоматизации деятельности определенного вида. Процесс проектирования систем является сложным и трудоемким и требует автоматизации. В это время разрабатываются методологии структурного анализа и проектирования и на их основе создаются системы автоматизированного проектирования или CASE-системы (Computer Aided System/Software Engineering). Отметим ряд особенностей систем автоматизированного проектирования.

Изобразительные средства специфичны для каждой системы. Модель используется на всех этапах процесса проектирования и функционирования системы. Комплексный охват всех этапов процесса проектирования Возможность интерактивного взаимодействия на всех этапах Машинное документирование проекта

К недостаткам можно отнести малый опыт использования, сложность эксплуатации, высокую стоимость таких систем.

Таким образом, развитие методов типового проектирования привело к созданию конкретных (индивидуальных) систем, но на значительно более высоком уровне по сравнению с индивидуальными методами. К итогам третьего этапа развития методов проектирования можно отнести появление методов автоматизированного проектирования.

Четвертый, современный этап, характеризуется появлением новых сетевых технологий, таких, как «клиент-сервер», « Интернет», « Интранет» , а также «Реинжиниринг бизнес процессов». Появились реальные возможности проведения качественных изменений способов ведения бизнеса при поддержке новых технологий. Сложность процессов проектирования приводит к необходимости дальнейшего развития методов автоматизированного проектирования. Необходима разработка новых методов, методологий, технологий и инструментальных средств проектирования ИС на различных этапах, а также их интеграция в Case-системах. Появилась концепция открытых систем, что требует использования международных стандартов в процессе проектирования.

Лекция 4. Жизненный цикл АИС

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

Существуют различные определения ЖЦ:

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

2. В ГОСТ 34.003-90 дается следующее определение:

Жизненный цикл АС: совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации.

3. В учебнике по данной дисциплине дается следующее определение[1]:

«Совокупность стадий и этапов, которые проходит ИС в своем развитии, от момента принятия решения о создании системы, до момента прекращения функционирования системы, называется ЖЦ ИС».

4. В международном стандарте ISO/IEC 12207[2]:

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

Жизненный цикл может быть описан с различной степенью детализации. В самом общем виде ЖЦ АИС может быть описан тремя последовательными фазами: разработка стратегии автоматизации, создание и внедрение, сопровождение (см. рис.1) .

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

Вторая фаза – собственно создание АИС и ее внедрение, — может быть построена по-разному в зависимости от принятой модели ЖЦ. Главную роль играет разработчик. Сопровождается разработкой проектной документации.

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

Более детально содержание жизненного цикла разработки ИС в раз­личных подходах одинакова и сводится к выполнению следую­щих стадий:

Планирование и анализ требований (предпроектная стадия) —
системный анализ. Исследование и анализ существующей инфор­мационной системы, определение требований к создаваемой ИС,
оформление технико-экономического обоснования (ТЭО) и тех­нического задания (ТЗ) на разработку ИС. Проектирование (техническое проектирование, логическое
проектирование). Разработка в соответствии со сформулирован­ными требованиями состава автоматизируемых функций (функциональная архитектура) и состава обеспечивающих подсистем
(системная архитектура), оформление технического проекта ИС. Реализация (рабочее проектирование, физическое проекти­рование, программирование). Разработка и настройка программ,
наполнение баз данных, создание рабочих инструкций для пер­сонала, оформление рабочего проекта. Внедрение (тестирование, опытная эксплуатация). Комплек­сная отладка подсистем ИС, обучение персонала, поэтапное вне­дрение ИС в эксплуатацию по подразделениям экономического
объекта, оформление акта о приемо-сдаточных испытаниях ИС. Эксплуатация ИС (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании ИС, исправление ошибок и недоработок, оформление требований к модернизации ИС и ее выполнение (повторение стадий 2 — 5). Часто второй и третий этапы объединяют в одну стадию, называемую техно-рабочим проектированием или системным синтезом.. На рис.1 представлена обобщенная блок-схема жизненного цикла ИС.

2 Блок-схема стадий и этапов ЖЦ ИС

На рис.1 представлена обобщенная блок-схема жизненного цикла ИС. Рассмотрим основное содержание стадий и этапов на представленной схеме.

Системный анализ. К основным целям процесса относится следующее:

    сформулировать потребность в новой ИС (идентифицировать недостатки существующей); выбрать направление и определить экономическую целесообразность проектирования ИС.

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

Системный синтез. Этот процесс предполагает:

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

Этап по составлению функциональной архитектуры (ФА), представляющий собой совокупность функциональных подсистем и связей между ними (блок 4), является наиболее ответственным с точки зрения качества всей последующей разработки.

Построение системной архитектуры (СА) на основе ФА (блок 5) предполагает выделение элементов и модулей информационно­го, технического, программного обеспечения и других обеспечи­вающих подсистем, определение связей по информации и управ­лению между выделенными элементами и разработку техноло­гии обработки информации.

Этап конструирования (физического проектирования систе­мы) включает разработку инструкций пользователям и программ, создание информационного обеспечения, включая наполнение баз данных (блок 6).

Внедрение разработанного проекта (блоки 7 — 10). Процесс предполагает выполнение следующих этапов: опытное внедрение и промышленное внедрение.

Этап опытного внедрения (блок 7) заключается в проверке работоспособности элементов и модулей проекта, устранении ошибок на уровне элементов и связей между ними.

Этап сдачи в промышленную эксплуатацию (блок 9) заклю­чается в организации проверки проекта на уровне функций и кон­троля соответствия его требованиям, сформулированным на ста­дии системного анализа.

Эксплуатация и сопровождение проекта. На этой стадии (бло­ки 11 и 12) выполняются этапы: эксплуатация проекта системы и модернизация проекта ИС.

Важной чертой жизненного цикла ИС является его повто­ряемость «системный анализ — разработка — сопровождение — системный анализ». Это соответствует представлению об ИС как о развивающейся, динамической системе. При первом выпол­нении стадии «Разработка» создается проект ИС, а при повтор­ном выполнении осуществляется модификация проекта для под­держания его в актуальном состоянии.

Необ­ходимо выполнять проектирование ИС на всех этапах перво­го, основного цикла разработки ИС в соответствии с требова­ниями:

разработка ИС должна быть выполнена в строгом соответ­ствии со сформулированными требованиями к создаваемой
системе; требования к ИС должны адекватно соответствовать целям
и задачам эффективного функционирования экономического
объекта; созданная ИС должна соответствовать сформулированным
требованиям на момент окончания внедрения, а не на момент
начала разработки;

• внедренная ИС должна развиваться и адаптироваться в соответствии с постоянно изменяющимися требованиями к ИС.

Выполнение этих требований во многом зависит от модели ЖЦ, используемой в процессе разработки системы

3 Модели жизненного цикла

Модель ЖЦ определяет порядок выполнения и взаимосвязи стадий и этапов процесса разработки системы.

В стандарте ISO/IEC-12207 дается следующее определение модели ЖЦ: «Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ».

Стандарт не предлагает конкретных моделей ЖЦ и методов их разработки. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Рассмотрим некоторые модели ЖЦ. Все модели образуют ряд, на противоположных концах которого находятся так называемые каскадная и спиральная модели жизненного цикла. Рассмотрим эти две модели более подробно, а затем коротко охарактеризуем другие модели.

3.1 Каскадная модель

Каскадная модель (см. рис.1) характеризуется строгой упорядоченностью стадий, из которых состоят фазы создания и внедрения АС. Такая упорядоченность предполагает, что работы на каждой стадии должны выполнятся настолько тщательно, чтобы не возникло необходимости пересмотра ранее принятых решений, то есть возврат к предыдущей стадии недопустим. Модель содержит один цикл, включающий стадию сопровождения. Все изменения вносятся в техническое задание. Состав и название технологических стадий у различных авторов, описывающих каскадную модель различаются в некоторых деталях, но по сути дела совпадают. Аналогичные стадии установлены Американским стандартом DOD-STD-2167A определяющим общий порядок создания АС военного назначения. Действующий в Великобритании стандарт SSADM почти идентичен нашему ГОСТУ. В нашем комплексе стандартов ГОСТ34.601-90 отсутствует стадия планирования как отдельная, так как она является управленческой, а не инженерной.

3.2 Спиральная модель

Спиральная модель (см. рис.2) предусматривает многократное прохождение одних и тех же стадий разработки до тех пор, пока созданный продукт не будет удовлетворять заказчика. Эта модель отражает итерационный характер действительно присущий процессу создания АС сложных объектов. На каждой итерации создают действующий прототип, который подвергают критической оценке. На заключительной итерации прототип принимают за окончательный вариант системы.

3.3 Сравнение моделей

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

Спиральная модель свободна от этого недостатка, поскольку на каждом витке спирали имеется возможность убедится в том, что изменившиеся требования учтены при разработке очередного прототипа. К преимуществам спиральной модели относятся:

накопление и повторное использование проектных решений, средств проектирования, моделей и прототипов; ориентация на развитие и модификацию системы в процессе проектирования; анализ риска и издержек в процессе проектирования.

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

3.4 Некоторые другие модели жизненного цикла АС

Промежуточное положение между каскадной и спиральной моделями занимают некоторые другие, нашедшие практическое применение:

метод быстрого прототипа; метод последовательного наращивания функций; эволюционная модель;

3.4.1 Метод быстрого прототипа

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

3.4.2 Метод последовательного наращивания функций

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

3.4.3 Эволюционная модель

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

Технология проектирования ИС – это совокупность методологии и средств проектирования, а также методов и средств организации проектирования (управление процессом создания и модернизации ИС).

Предметом любой выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проек­тирования на всех стадиях жизненного цикла ИС.

К основным требованиям, предъявляемым к выбираемой тех­нологии проектирования, относятся следующие:

созданный с помощью этой технологии проект должен отве­чать требованиям заказчика; выбранная технология должна максимально отражать все эта­пы цикла жизни проекта; выбираемая технология должна обеспечивать минимальные
трудовые и стоимостные затраты на проектирование и сопро­вождение проекта; технология должна быть основой связи между проектирова­нием и сопровождением проекта; технология должна способствовать росту производительнос­ти труда проектировщика; технология должна обеспечивать надежность процесса про­ектирования и эксплуатации проекта; технология должна способствовать простому ведению проект­
ной документации.

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

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

1 Формализация технологии проектирования ИС

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

В наибольшей степени задаче формализации технологии про­ектирования ИС соответствует аппарат технологических сетей проектирования, разработанный и развитый .

Основой формализации технологии проектирования ИС является формальное определение технологической операции (ТО) проектирования в виде:

То = (V — Вход, W — Выход, П — Преобразователь, R — Ресурсы, S – Средства)

Графическая интерпретация технологической операции представлена на рис. 2.3. Технологические операции графичес­ки представляются в виде блоков-прямоугольников, внутри ко­торых даются наименование ТО, перечень используемых средств проектирования и ссылки на используемые ресурсы. Входы и выходы ТО представляются идентификаторами внутри кружков, от которых и к которым идут стрелки, указывающие входные и выходные потоки.

Рассмотрим детально компоненты формального определе­ния ТО.

В качестве компонентов входа и выхода используются мно­жества документов D, параметров Р, программ G, универсаль­ных множеств (универсумов) U. Для любых компонентов входа и выхода должны быть заданы формы их представления в виде твер­дой копии или электронном виде.

Документ D — это описатель множества взаимосвязанных фак­тов. С помощью документов описываются объекты материальных и информационных потоков, организационной структуры, техни­ческих средств, необходимые для

Рнс. 2.3. Графическая интерпретация технологической операции

проектирования и внедрения ИС. Документы определяют или исходные данные проектирова­ния, или конечные результаты проектирования для реализации новой информационной системы, или промежуточные результа­ты, которые используются временно для выполнения последующих ТО. Конечные документы одновременно могут быть и промежу­точными. Конечные документы должны быть оформлены в соот­ветствии со стандартами представления проектной документации.

Параметр Р — это описатель одного факта. В принципе пара­метр рассматривается как частный случай документа. Параметры выступают, как правило, в роли ограничений или условий про­цесса проектирования, например объем финансирования, срок разработки, форма предприятия и т. д. Параметры могут быть и варьируемыми с позиции анализа влияния их значений на резуль­тат проектирования ИС.

Программа G — частный случай документа, представляющего описание алгоритма решения задачи, которое претерпевает свое изменение по мере изменения жизненного цикла ИС: от специ­фикации программы до машинного кода.

Универсум U — это конечное и полное множество фактов (до­кументов) одного типа. Обычно с помощью универсума описы­вается множество альтернатив, выбор из которого конкретного экземпляра определяет характер последующих проектных реше­ний.

Преобразователь П — это некоторая методика или формализо­ванный алгоритм, или машинный алгоритм преобразования вхо­да технологической операции в ее выход. Соответственно используются ручные, автоматизированные и автоматические методы реализации преобразователей. Для формализации преобразовате­лей используются математические модели, эвристические прави­ла, блок-схемы, псевдокоды.

Ресурсы R — набор людских, компьютерных, временных и фи­нансовых средств, которые позволяют выполнить технологичес­кую операцию.

Средства проектирования S — это специальный вид ресурса, включающий методические и программные средства выполнения технологической операции. Если преобразователь является руч­ным, то средство проектирования представляет методику выпол­нения работы и в описании ТО дается ссылка на соответствующий бумажный или электронный документ. Если преобразователь яв­ляется автоматизированным или автоматическим, в описании ТО указывается ссылка на название и описание программного сред­ства, а также руководство по его эксплуатации, которое должно быть ориентировано на методику ра­боты проектировщика с помощью данного программного средства.

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

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

Рис. 2.4. Технологическая сеть проектирования

Для укрупнения ТСП применяются технологические операции-агрегаты, которым соответствуют фрагменты канонической ТСП. Например, ТО «Проектирование схемы базы данных» декомпо­зируется на ряд взаимосвязанных ТО: «Нормализация таблиц», «Установление связей», «Отображение в схеме DDL СУБД» и т. д.

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

Для конкретного проектировщика-исполнителя относящаяся к его компетенции технологическая операция-агрегат всегда может быть раскрыта в виде фрагмента канонической сети.

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

КАНОНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ ИС.

СОДЕРЖАНИЕ И МЕТОДЫ КАНОНИЧЕСКОГО ПРОЕКТИРОВАНИЯ

1 Состав стадий и этапов канонического проектирования ИС

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

В основе канонического проектирования лежит каскадная модель жизненного цикла ИС. Процесс каскадного проектиро­вания в жизненном цикле ИС в соответствии с применяемым в нашей стране ГОСТ 34601-90 «Автоматизированные системы ста­дий создания» делится на следующие семь стадий:

· исследование и обоснование создания системы;

· разработка технического задания;

· создание эскизного проекта;

· функционирование, сопровождение, модернизация.

В целях изучения взаимосвязанных приемов и методов кано­нического проектирования ИС перечисленные 7 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ИС (рис. 1):

Рис. 1. ТСП стадий и этапов канонического проектирования ИС:

Д1.1 — предметная область; Д1.2 — материалы обследования;

Д1.3 — ТЭО, ТЗ на проектирование; Д1.4 — эскизный проект;

Д2.1 — техно-рабочий проект (ТРП); Д3.1 — исправленный ТРП,

переданный в эксплуатацию; Д3.2 — акт о приемке проекта в промышленную эксплуатацию; Д4.1 — модернизированный ТРП

Традиционно этапы исследования предметной области — пред­приятия, обоснование проекта ИС для него и разработки тех­нического задания объединяют термином «Предпроектная ста­дия» («Предпроектное обследование»), поскольку результаты вы­полнения работ на данных этапах не являются законченным проектным решением. Основное назначение «Предпроектной ста­дии» заключается в обосновании экономической целесообразно­сти создания ИС и формулировании требований к ней.

На п е р в о й «Предпроектной стадии» принято выделять два основных этапа: сбор материалов обследования; анализ матери­алов обследования и разработка технико-экономического обосно­вания (ТЭО) и технического задания (ТЗ).

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

После выполнения второго этапа проектировщики по­лучают количественные и качественные характеристики инфор­мационных потоков, описание их структуры и мест обработки, объемов выполняемых операций и трудоемкости их обработки. На основе этих материалов разрабатываются два документа: «Тех­нико-экономическое обоснование проектных решений» (ТЭО), со­держащее расчеты и обоснование необходимости разработки ИС для предприятия и выбираемых технологических и проектных ре­шений (Д1.3), и «Техническое задание» (ТЗ), в состав которого вхо­дят требования к создаваемой системе и ее отдельным компонен­там: программному, техническому и информационному обеспече­нию и целевая установка на проектирование новой системы (Д 1.4). Эти документы являются основными для последующего проекти­рования ИС в соответствии с заданными требованиями.

Для сложных ИС иногда на этой стадии включают третий этап – разработку «Эскизного проекта». На этапе «Эскизного проекта» сформулированные ранее требования служат основой для разработки предварительных решений по ИС в целом и от­дельным видам обеспечения. Эти решения прорабатываются на логическом уровне, включая алгоритмы обработки информации, описание информационных потребностей пользователей на уров­не названий документов и показателей.

Вторая стадия «Техно-рабочее проектирование» выпол­няется в два этапа: техническое проектирование и рабочее про­ектирование.

На этапе «Техническое проектирование» выполняются рабо­ты по логической разработке и выбору наилучших вариантов про­ектных решений, в результате чего создается «Технический про­ект». Этап «Рабочее проектирование» связан с физической реали­зацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Техно-рабочий проект» (ТРП) — Д2.1.

Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное вне­дрение проекта и сдача его в промышленную эксплуатацию.

На этапе «Подготовка объекта к внедрению проекта» осуще­ствляется комплекс работ по подготовке предприятия к внедре­нию разработанного проекта ИС. На этапе «Опытное внедре­ние» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную докумен­тацию и «Акт о проведении опытного внедрения». На этапе «Сда­ча проекта в промышленную эксплуатацию» осуществляют комп­лексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» (Д3.1) и «Акт приемки проекта в промышленную эксплуатацию» (Д3.2).

Четвертая стадия — «Эксплуатация и сопровождение проекта» включает этапы: эксплуатация проекта; сопровождение и модернизация проекта.

На этапе «Эксплуатация проекта» получают информацию о работе всей системы в целом и отдельных ее компонентов и соби­рают статистику о сбоях системы в виде рекламаций и замечаний, которые накапливаются для выполнения следующего этапа. На этапе «Сопровождение проекта» выполняются два вида работ: лик­видируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта, а также осуще­ствляется модернизация проекта. В процессе модернизации проект либо дорабатывается, т. е. расширяется по составу подсистем и за­дач, либо производится перенос системы на другую программную или техническую платформу с целью адаптации ее к изменяющим­ся внешним и внутренним условиям функционирования, в резуль­тате чего получают документы модернизированного «Техно-ра­бочего проекта» (Д4.1).

Лекция 6. Каноническое проектирование АИС(продолжение)

2 Состав и содержание работ на предпроектной стадии создания ИС

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

Важнейшими объектами обследования могут являться:

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

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

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

• материальные потоки и процессы их обработки.
Основной целью выполнения первого этапа предпроектного обследования «Сбор материалов» является:

выявление основных параметров предметной области (напри­мер, предприятия или его части); установление условий, в которых будет функционировать про­ект ИС; выявление стоимостных и временных ограничений на процесс
проектирования.

На этом этапе проектировщиками выполняется ряд техноло­гических операций и решаются следующие задачи: предваритель­ное изучение предметной области; выбор технологии проекти­рования; выбор метода проведения обследования; выбор метода сбора материалов обследования; разработка программы обсле­дования; разработка плана-графика сбора материалов обследо­вания; сбор и формализация материалов обследования. Техно­логическая сеть проектирования представлена на рис. 3.2.

Рис. 3.2. ТСП ра выполняемых на этапе «Сбор материалов обследования»:

Д 1.1 — общие сведения об объекте; Д 1.2 — примеры разработок проектов ИС для аналогичных систем; U 2.1 — универсум техноло­гий проектирования; Д

2.1 — ресурсы; Д 2.2 — описание выбранной технологии, методов и средств проектирования; U 3.1 — универсум методов проведения обследования; Д 3.1 — описание выбранного метода; U 4.1 — универсум методов сбора материалов обследования; Д 4.1 — описание выбранного метода; Д 5.1 — программа обследования; Д 6.1 — план-график выполнения работ на предпроектной стадии; U 7.1 — универсум методов формализации; Д 7.1 — общие параметры (характеристики) экономической системы; Д 7.2 — методы и методики управления (алгоритм расчета экономических показателей); Д 7.3 — организационная структура экономической системы; Д 7.4 — параметры информационных потоков; Д 7.5 — параметры материальных потоков

Выполнение операции «Предварительное изучение предметной области» (П1) имеет своей целью на основе общих сведений об объекте (Д1.1) выявить предварительные размеры объемов ра­бот по проектированию и состав стоимостных и временных ог­раничений на процессы проектирования, а также найти примеры разработок проектов ИС для аналогичных систем (Д1.2).

Важной операцией, определяющей все последующие работы по обследованию объекта и проектированию ИС, является «Выбор технологии проектирования» (П2). В настоящее время в универсум (U2.1) входит несколько типов технологий проекти­рования: технология оригинального, типового, автоматизирован­ного и смешанного вариантов проектирования.

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

Основными ограничениями при выборе технологии из неко­торого универсума технологий (U2.1) могут служить: наличие де­нежных средств на приобретение и поддержку выбранной техно­логии, ограничения по времени проектирования, доступность со­ответствующих инструментальных средств и возможность обеспечения поддержки их эксплуатации собственными силами, наличие специалистов соответствующей квалификации (Д2.1). Ре­зультатом выполнения этой операции служит получение описания выбранной технологии, методов и средств проектирования (Д2.2).

Перед началом работ по проведению обследования необхо­димо выбрать метод проведения обследования (ПЗ). Все методы (U3.1) можно объединить в группы по следующим признакам (рис. 3.3):

• по цели обследования выделяют метод организации локаль­ного проведения обследования, используемый для разработ­ки проекта отдельной задачи или для комплекса задач, и метод системного обследования объекта, применяемый для изу­чения всего объекта с целью разработки для него проекта ИС

по числу исполнителей, проводящих обследование, применя­ется индивидуальное обследование, осуществляемое одним проектировщиком, и бригадное с выделением ряда бригад — исполнителей, изучающих все подразделения предприятия, и одной координирующей бригады; по степени охвата предметной области применяют метод
сплошного обследования, охватывающего все подразделения
экономической системы, и выборочное, применяемое при на­личии типовых по структуре подразделений (например, це­хов или складов); по степени одновременности выполнения работ первого и вто­рого этапов предпроектной стадии выделяют метод последо­вательного проведения работ, при котором проектировщики сначала собирают данные о предметной области, а затем их изучают (часто применяют при отсутствии опыта в выполне­нии такого рода работ), и метод параллельного выполнения работ, когда одновременно со сбором происходит изучение полученных материалов обследования, что значительно со­кращает время на проведение работ на предпроектной ста­дии и повышает качество получаемых результатов.

Выполнение работ по обследованию предметной области в каком-либо подразделении и сбору материалов можно проводить на основе предварительного проведения выбора методов сбора материалов обследования (П4), универсум которых (U4.1) мож­но разделить на две группы (рис. 3.4):

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

1) Метод бесед и консультаций с руководителями чаще всего проводится в форме обычной беседы с руководителями предпри­ятий и подразделений или в форме деловой консультации со спе­циалистами по вопросам, носящим глобальный характер и отно­сящимся к ‘определению проблем и стратегий развития и управ­ления предприятием.

2) Метод опроса исполнителей на рабочих местах используется в процессе сбора сведений непосредственно у специалистов пу­тем бесед, которые требуют тщательной подготовки. Заранее со­ставляют список сотрудников, с которыми намереваются бесе­довать, разрабатывают перечень вопросов о роли и назначении работ в деятельности объекта, порядке их выполнения.

3) Метод анализа операций заключается в расчленении рассмат­риваемого делового процесса, работы на ее составные части, за­дачи, расчеты, операции и даже их элементы. После этого анали­зируется каждая часть в отдельности, выявляются повторяемость отдельных операций, многократное обращение к одной и той же операции, их степень зависимости друг от друга.

4) Метод анализа предоставленного материала применим в ос­новном при выяснении таких вопросов, на которые нельзя полу­чить ответ от исполнителей.

5) Метод фотографии рабочего дня исполнителя работ предпо­лагает непосредственное участие проектировщиков и примене­ние рассчитанного для регистрации данных наблюдения специ­ального листа фотографии рабочего дня и распределения его между работами.

6) Метод выборочного хронометража отдельных работ требу­ет предварительной подготовки, известных навыков и наличия специального секундомера. Данные хронометража позволяют установить нормативы на выполнение отдельных операций и со­брать подробный материал о технике осуществления некоторых работ.

7) Метод личного наблюдения применим, если изучаемый вопрос понятен по существу и необходимо лишь уточнение деталей без существенного отрыва исполнителей от работы.

8) Метод документальной инвентаризации управленческих работ заключается в том, что на каждую работу в отдельности откры­вается специальная карта обследования, в которой приводятся все основные данные о регистрируемой работе или составляемых документах.

9) Метод ведения индивидуальных тетрадей-дневников. Записи в дневнике производятся исполнителем в течение месяца ежеднев­но, сразу же после выполнения очередной работы.

10) Метод самофотографии рабочего дня заключается в том, что наблюдение носит более детальный характер и происходит в ко­роткий срок. Этот метод дает сведения о наиболее трудоемких или типичных отдельных работах, которые используются для определения общей трудоемкости выполнения всех работ.

11) Расчетный метод применяется для определения трудоемкос­ти и стоимости работ, подлежащих переводу на выполнение с помощью ЭВМ, а также для установления объемов работ по от­дельным операциям.

12) Метод аналогии основан на отказе от детального обследова­ния какого-либо подразделения или какой-либо работы. Исполь­зование метода требует наличия тождественности и не исключа­ет общего обследования и выяснения таких аспектов, на которые аналогия не распространяется.

При выборе метода следует учитывать следующие критерии:

степень личного участия проектировщика в сборе материала; временные, трудовые и стоимостные затраты на получение
сведений в подразделениях.

Проектировщику необходимо знать и в каждом конкретном случае применять наиболее экономичный, обеспечивающий нуж­ную полноту сведений метод сбора материалов обследования.

Обследование проводится по заранее разработанной програм­ме (Д5.1), составляемой во время выполнения операции П5. по форме, содержащей перечень вопро­сов, ответы на которые дадут полное представление о деятельности изучаемого объекта и будут учтены при создании проекта ИС. Вопросы можно систематизировать по трем основным на­правлениям исследования объекта.

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

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

Третье направление предусматривает изучение и опи­сание структуры информационных и(или) материальных потоков: состава и структуры компонентов потоков, частоты их возник­новения, объемов за определенный период, направления дви­жения потоков, процедур обработки, в которых участвуют эти компоненты. Источником сведений являются получаемые от спе­циалистов предметной области интервью, экономическая доку­ментация и результаты расчетов. Описание информационной структуры выполняется на уровне экономических документов и показателей.

Для организации труда проектировщиков во время выполне­ния сбора материалов обследования и его последующего анали­за необходимо выполнение операции П6 — разработка «Плана-графика выполнения работ на предпроектной стадии» (Д6.1). «План-график» служит инструментом для планирования и оперативного управления выполнением работ на предпроектной стадии.

Последней операцией (П7), выполняемой проектировщиками на этом этапе, является «Проведение сбора и формализации мате­риалов обследования», в процессе которой члены бригад должны проинтервьюировать специалистов подразделений изучаемой предметной области; собрать сведения обо всех объектах обсле­дования, в том числе о предприятии в целом, функциях управле­ния, методах и алгоритмах реализации функций, составе обраба­тываемых и рассчитываемых показателей; собрать формы доку­ментов, отражающих хозяйственные процессы и используемые классификаторы, макеты файлов, сведения об используемых тех­нических средствах и технологиях обработки данных; проконт­ролировать вместе с пользователем их правильность, сформиро­вать «Отчет об обследовании» и выполнить другие работы.

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

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

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

Описание материальных потоков (Д7.5) предполагает отобра­жение маршрутов движения средств, предметов и продуктов тру­да, рабочей силы между подразделениями производственной структуры и будет включать: описание видов продукции или ус­луг, ресурсов; описание технологических операций, их частоту и длительность выполнения; объемы перемещаемых ресурсов, про­дукции или услуг, используемые средства транспортировки.

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

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

Третья группа документов содержит описание компо­нентов каждого информационного потока, включая документы, информационные файлы, процедуры обработки и характеристи­ки этих компонентов.

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

Лекция 6. Каноническое проектирование ИС(продолжение)

3 Выполнение этапа «Анализ материалов обследования»


На основе формализованного описания предметной области выполняется этап «Анализ материалов обследования», целью ко­торого являются:

сопоставление всей собранной об объекте информации с теми
требованиями, которые предъявляются к объекту, определе­ние недостатков функционирования объекта обследования; выработка основных направлений совершенствования рабо­ты объекта обследования на базе внедрения проекта ИС,

выбор направлений проектирования (выбор инструментария) и оценка эффективности применения выбранного инструментария;

• обоснование выбора решений по основным компонентам про­екта ИС и определение общесистемных, функциональных и локальных требований к будущему проекту и его частям.

Рассмотрим технологическую сеть анализа материалов обсле­дования (рис. 3.1), в которой в каждой из технологических опе­раций используются документы обследования (Д1.1 — Д1.5).

Анализ материалов обследования позволяет проектировщи­кам выделить и составить список автоматизируемых подразде­лений (П1). На выбор объектов автоматизации оказывает влия­ние ряд факторов (U1.1), например, таких, как:

количество формализуемых функций в каждом конкретном подразделении; количество связей этого подразделения с другими подразде­лениями; важность этого подразделения в процессах управления объек­том; степень подготовленности подразделения для внедрения ЭВМ и др.

Согласно этим факторам выделяют список наиболее важных подразделений (Д1.6). Например, для предприятия такими под­разделениями являются отделы технико-экономического плани­рования, оперативного управления основным производством, тех­нической подготовки производства, материально-технического снабжения, реализации и сбыта готовой продукции, бухгалтерия.

При выявлении списка автоматизируемых задач (Д2.1) на опе­рации П2, для которых необходимо разработать проекты, про­ектировщики принимают к сведению следующие факторы, пред­ставленные универсумом (U2.1):

важность решения задачи для выполнения основных функций управления, деловых процессов и процедур в данном подраз­делении; трудоемкость и стоимость расчета основных показателей дан­ной задачи за год; сильная информационная связь рассматриваемой задачи с другими задачами; недостаточная оперативность расчета показателей; низкая достоверность получаемых данных; недостаточное количество аналитических показателей, получаемых на базе первичных документов;

Рис. 3. Технологическая сеть выполнения процесса работ на этапе «Анализ материалов обследования»:

Д 1.1 — общие параметры (характеристики) экономической системы; Д 1.2 — методы и методики управления (алгоритм расчета экономических показателей); Д 1.3 — организационная структура экономической системы; Д 1.4 — параметры информационных потоков; Д 1.5 — параметры материальных потоков; U 1.1 — универсум факторов выбора; Д 1.6 — обоснование и список объектов автоматизации; U 2.1 — универсум факторов выбора задач; Д 2.1 — обоснование списка задач по каждому подразделению (объекту автоматизации); U 3.1 — универсум технических средств; U 3.2 — факторы отбора КТС; Д 3.1 — обоснование выбора КТС; U 4.1 — универсум операционных систем; U 4.2 — факторы выбора ОС; Д 4.1 — обоснование выбора ОС и алгоязыков; U 5.1 — универсум способов организации ИБ; U 5.2 — универсум программных средств ведения ИБ; U 5.3 — факторы выбора; Д 5.1 — обоснование выбора и описание организации ИБ и программного средства; U 6.1 — универсум методов и программных средств разработки; Д 6.1 — обоснование выбора метода проектирования и инструментального средства; Д 7,1 — ТЭО; Д 7.2 — ТЗ

Кроме того, на этой операции осуществляется выявление оче­редей проектирования решаемых задач. К задачам первой очере­ди относят самые трудоемкие задачи и задачи, обеспечивающие информацией все остальные задачи комплексов и подсистем (на­пример, задачи планирования и бухгалтерского учета). Общим требованием к первоочередным задачам является получение нор­мативного коэффициента окупаемости капитальных затрат.

Далее выполняется операция, связанная с анализом всех по­лученных ранее результатов, исходных универсумов и предвари­тельным выбором комплекса технических средств (Д3.1) на опе­рации ПЗ из универсума U3.1.

Далее следует выполнение операции П4 — «Выбор типа опера­ционных систем» (Д4.1). из универсума U4.1 Следующей операцией (П5) является операция «Выбор спосо­ба организации информационной базы (ИБ) и программного сред­ства ведения ИБ» (Д5.1). Информационная база может иметь несколько способов организации (U5.1). Программные средства ведения ИБ выбираются исходя из класса систем хранения данных из универсума U5.2.

При выполнении следующей операции (П6) осуществляется «Выбор методов и средств проектирования программного обеспе­чения системы», который напрямую зависит от выбранной тех­нологии проектирования. В универсум методов проектирования (U6.1), используемых при каноническом подходе, входят такие, как метод структурного проектирования, модульного проекти­рования и другие.

Выполнение всех этих операций завершается составлением ТЭО (Д7.1) и формированием ТЗ (Д1.2) на операции П7.

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

Организационные параметры ИС дифференцируют по техно­логическим операциям процесса обработки информации: сбора, регистрации, передачи, хранения, обработки и выдачи информа­ции. Для подготовительного этапа технологии обработки инфор­мации параметрами могут быть: вид связи между источником информации и ЭВМ, территориальное размещение технических средств, способ обеспечения достоверности информации и т. п.

К информационным параметрам относятся такие, как досто­верность, периодичность сбора, форма представления, периодич­ность обработки информации и т. д.

К экономическим параметрам ИС относятся: показатели годового экономического эффекта, коэффициента эффективнос­ти затрат и т. п.

Параметризация позволяет определить требования к систе­ме, оценить существующую информационную систему, опреде­лить пригодность типовых решений в проекте ИС, выбрать про­ектные решения в соответствии с предъявляемыми требования­ми к ИС.

К основным компонентам ТЭО относятся:

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

На основе ТЭО разрабатываются основные требования к бу­дущему проекту ИС и составляется «Техническое задание» со­гласно ГОСТ 34.602 — 89 «Техническое задание на создание авто­матизированной системы»(ТЗ).

В состав «Технического задания» входят следующие основные разделы.

В разделе «Общие сведения о проекте» указывают: полное
наименование системы, код системы, код договора, наименова­ние предприятия-разработчика и предприятия-заказчика, пере­чень документов, на основе которых создается система, плано­вые сроки начала и окончания работ по созданию системы, све­дения об источниках финансирования, порядок оформления и предъявления заказчику результатов работ по созданию системы
(ее частей). Раздел описания «Назначение, цели создания системы» со­стоит из двух подразделов:

в подразделе «Назначение системы» даются вид автоматизи­руемой деятельности и перечень объектов автоматизации, на ко­торых предполагается ее использовать;

в подразделе «Цели создания системы» указываются наиме­нования и требуемые значения технических, технологических, производственно-экономических и других показателей объекта автоматизации, которые будут достигнуты в результате внедре­ния ИС.

В разделе «Характеристика объекта автоматизации» при­водятся: краткие сведения об объекте автоматизации; сведения об условиях эксплуатации объекта и характеристиках окружаю­щей среды. Раздел «Требования к системе» состоит из следующих под­
разделов: требования к системе в целом; требования к функциям
(задачам), выполняемым системой; требования к видам обеспе­чения.

В подразделе «Требования к системе в целом» указывают тре­бования к структуре и функционированию системы; к численно­сти квалифицированных работников; к надежности и безопасно­сти работы системы; к эргономике и технической эстетике, эксп­луатации, техническому обслуживанию, ремонту системы; к защите информации от несанкционированного доступа; требо­вания по сохранности информации при авариях; к защите от внеш­ней среды; к патентной чистоте проектных решений; требования по унификации и стандартизации.

В подразделе «Требования к функциям (задачам), выполняемым системой», комплексам задач и отдельным задачам приводят по каждой подсистеме перечень функций, задач или их комплексов, подлежащих автоматизации; распределение их по очередям создания; временной регламент реализации каждой функции, за­дачи или комплекса; требования к качеству реализации каждой функции, задачи, комплекса, к форме представления выходной информации; характеристики необходимой точности и времени выполнения, достоверности выдачи результата.

В подразделе «Требования к видам обеспечения» содержатся требования к математическому, программному, техническому, лингвистическому, информационному и методическому обеспе­чению ИС.

Раздел «Состав и содержание работ по созданию системы»
должен содержать: перечень стадий и этапов работ по созданию
системы в соответствии с ГОСТ 34.601 — 90; сроки выполнения;
перечень организаций-исполнителей; перечень документов по
ГОСТ 34.201 — 89 «Виды, комплектность и обозначение докумен­тов при создании автоматизированных систем», предъявляемых
по окончании работ; вид и порядок проведения экспертизы тех­нической документации и др. В разделе «Порядок контроля приемки системы» указыва­ют: виды, состав, методы испытания системы и ее частей; общие
требования к приемке работ по стадиям; порядок утверждения
приемных документов; статус приемочной комиссии. В разделе «Требования к составу и содержанию работ по
подготовке объекта автоматизации к вводу системы в действие»
необходимо привести перечень необходимых мероприятий и их
исполнителей, которые следует выполнять при подготовке объек­та к вводу ИС в действие: приведение информации, поступаю­
щей в систему, к виду, пригодному для ввода в ЭВМ; создание
условий функционирования объекта, при которых гарантирует­ся соответствие создаваемой системы требованиям, содержащим­ся в ТЗ; создание необходимых для функционирования системы
подразделений и служб; сроки и порядок комплектования шта­тов и обучения персонала. В разделе «Требования к документированию» приводят:
перечень подлежащих разработке комплектов и видов докумен­тов, соответствующих требованиям ГОСТ 34.201 — 89 и научно-
технической документации отрасли заказчика. В разделе «Источники разработки» должны быть перечис­лены документы и информационные материалы (ТЭО, отчеты о
законченных научно-исследовательских разработках, информа­ционные материалы на отечественные, зарубежные системы-ана­логи и др.).

10. В состав ТЗ при наличии утвержденных методик включа­ют приложения, содержащие расчеты экономической эффектив­ности системы; оценку научно-технического уровня системы.

Лекция 6. Каноническое проектирование ИС(продолжение 3)

3 Состав и содержание работ на стадии техно-рабочего проектирования

Работы на стадии «Техно-рабочего проектирования» выполня­ются на основе утвержденного «Технического задания». Разра­батываются основные положения проектируемой системы, прин­ципы ее функционирования и взаимодействия с другими систе­мами; определяется структура системы; разрабатываются проектные решения по обеспечивающим частям системы.

На стадии «Техно-рабочего проектирования» выполняются два этапа работ: техническое и рабочее проектирование, технологичес­кая сеть которых приведена на рис. 3.7 и 3.9. На первом из них -«Техническое проектирование» осуществляется логическая про­работка функциональной и системной архитектуры ИС, в про­цессе которой строится несколько вариантов всех компонентов

Рис. 3.7. ТСП выполнения работ на этапе технического проектирования:

Д 1.1 — ТЗ; Д 1.2 — основные положения по ИС; Д 2.1 — описание организационной структуры; Д 3.1 — описание функциональной структуры; Д 4.1 — принципы органи­зации информационного обеспечения; Д 5.1 — постановка задачи; Д 6.1 — формы

первичных и результатных документов; Д 6.2 — система ведения документов; Д 7.1 — классификаторы; Д 8.1 — структуры сообщений; Д 9.1 — описание макетов и структур файлов; Д 10.1 — системы технологических процессов обработки данных; Д 11.1 — ТЭО; Д 11.2- описание состава и характеристика периферийной техники; Д 12.1 — АП; Д 13.1 — проектно-сметная документация; Д 14.1 — показатели эконо­мической эффективности; Д 15.1 — план мероприятий по подготовке объекта к внедрению проекта ИС; Д 16.1 — технический проект

системы; проводится оценка вариантов по показателям: стоимос­ти, трудоемкости, достоверности получаемых результатов, и со­ставляется «Технический проект» системы.

Все работы первого этапа можно разбить на две группы. К первой группе относится разработка общесистемных проект­ных решений, в том числе:

разработка общесистемных положений по ИС (П1); изменение организационной структуры (П2); определение функциональной структуры (ПЗ); разработка проектно-сметной документации и расчет эконо­мической эффективности системы (П13), (П14);

• разработка плана мероприятий по внедрению ИС (П15).
При разработке основных положений по системе (П1) уточня­ются цели создания ИС и выполняемые ею функции; устанав­ливается ее взаимосвязь с другими системами и формируется до­кумент Д1.2 «Основные положения». Далее уточняется и изменя­ется организационная структура (П2) и получается описание организационной структуры (Д2.1).

Наиболее принципиальной в данном комплексе работ явля­ется разработка функциональной архитектуры ИС (ПЗ) Д3.1 на базе универсума U3.1 принципов выделения функциональных подсистем (модулей, контуров): предметного, функционального, смешанного (предметно-функционального) и проблемного.

Ко второй группе работ, выполняемых на этапе техническо­го проектирования, относятся разработки локальных проектных решений, к числу которых относят следующие операции:

разработка «Постановки задачи» для задач, входящих в со­став каждой функциональной подсистемы (П5), включающей
основные компоненты описания задачи и служащей основа­нием для разработки проектных решений по задаче; проектирование форм входных и выходных документов, сис­темы ведения документов и макетов экранных форм докумен­тов (П6, П9); проектирование классификаторов экономической информа­ции и системы ведения классификаторов (П7); разработка структуры входных и выходных сообщений (П8); проектирование состава и структур файлов информационной
базы (П4); проектирование внемашинной и внутримашинной технологии
решения каждой задачи (П10); уточнение состава технических средств (ПИ), (П12).

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

Результатом работ на данной стадии является утвержденный «Технический проект», состав и содержание которого регла­ментируются стандартом (ГОСТ 34.201 — 89).

На втором этапе – «Рабочем проектировании»осуществ­ляется техническая реализация выбранных наилучших вариантов и разрабатывается документация «Рабочий проект» (рис. 3.9).

Большую роль в деле эффективного использования разрабо­танного проекта ИС играет качественная технологическая до­кументация, входящая в состав «Рабочего проекта». Эта часть проекта разрабатывается на операции П2 и предназначена для использования специалистами в своей деятельности на каждом автоматизированном рабочем месте.

Рис. 3.9. ТСП работ, выполняемых на этапе рабочего проектирования:

Д 1.1 — технический проект; Д 1.2 — документы программного обеспечения;

Д 2.1 — технические документы и инструкции; Д 3.1 — правовые инструкции;

Д 4.1 — рабочий проект

В состав технологической документации (Д2.1) входят: тех­нологические карты, разрабатываемые на процессы обработки информации при решении задач каждого класса, и инструкцион­ные карты, составляемые на каждую технологическую операцию.

Технологическая документация разрабатывается в соответ­ствии с требованиями ГОСТ 3.11.09 — 82 «Система технологичес­кой документации Термины и определения основных понятий», и составляет содержание технологического обеспечения ИС, ко­торое можно разделить на несколько типов в соответствии с вы­делением следующих классов задач, решаемых в ИС:

системы обработки данных (СОД); системы поддержки принятия решений (СППР); системы автоматизированного проектирования новой продук­ции (САПР) и т. д.

К числу работ, выполняемых на этом этапе, относится «Раз­работка правовых инструкций» (Д1.2) (П1), определяющих права и обязанности специалистов, работающих в условиях функцио­нирования на предприятии компонентов ИС.

Заключительной операцией служит «Оформление документации Рабочего проекта» (Д4.2) согласно ГОСТам (Д4.1) на операции П4.

3.4 Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта

На стадии «Внедрение проекта» проводятся подготовка и по­степенное освоение разработанной проектной документации ИС заказчиками системы. В процессе выполнения работ на этой стадии осуществляется выявление частных и системных принци­пиальных недоработок в предлагаемом для внедрения проектном решении.

Внедрение может осуществляться с использованием следую­щих методов:

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

Внедрение проекта осуществляется в течение трех этапов:

подготовка объекта к внедрению; опытное внедрение;

• сдача проекта в промышленную эксплуатацию.
Первый этап — «Подготовка объекта к внедрению». На

этом этапе осуществляются следующие операции:

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

На вход этого этапа поступают компоненты «Технического проекта» в части «Плана мероприятий по внедрению», решения по техническому и информационному обеспечению, техноло­гические и инструкционные материалы «Рабочего проекта». В результате выполнения этапа составляется «Акт готовности объекта к внедрению» проекта ИС. Затем формируется состав приемной комиссии, разрабатывается «Программа проведения опытного внедрения» и издается «Приказ о начале опытного вне­дрения».

Второй этап — «Опытное внедрение». На этом этапе вне­дряются проекты нескольких задач в нескольких подсистемах. В процессе опытного внедрения выполняются следующие работы:

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

В случае обнаружения ошибок осуществляются поиск причин и источников ошибок, внесение коррективов в программы, в тех­нологию обработки информации, в работу технических средств, в исходные оперативные данные и в файлы с условно-постоян­ной информацией. Кроме того, выявляется неквалифицирован­ная работа операторов, что служит основанием для проведения комплекса мер по улучшению подготовки кадров.

После устранения ошибок получают «Акт о проведении опыт­ного внедрения», который служит сигналом для начала выпол­нения следующего этапа.

На третьем этапе «Сдача проекта в промышленную эксп­луатацию» используют следующую совокупность документов:

• «Приказ на разработку ИС»;

• исправленный «Техно-рабочий проект»;

• «Приказ о начале промышленного внедрения»;

«Программа проведения испытаний»; «Требования к научно-техническому уровню проекта системы».

В процессе сдачи проекта в промышленную эксплуатацию осуществляются следующие работы:

проверка соответствия выполненной работы договорной до­кументации по времени выполнения, объему проделанной ра­боты и затратам денежных средств; проверка соответствия проектных решений по ИС требова­ниям ТЗ; проверка соответствия проектной документации гостам и ос­
там; проверка технологических процессов обработки данных по
всем задачам и подсистемам; проверка качества функционирования информационной базы,
оперативности и полноты ответов на запросы;

• выявление локальных и системных ошибок и их исправление.
Кроме того, приемная комиссия определяет научно-техничес­кий уровень проекта и возможности расширения проектных ре­шений за счет включения новых компонентов. В результате вы­полнения работ на данном этапе осуществляется доработка «Тех­но-рабочего проекта» за счет выявления системных и локальных
ошибок и составляется «Акт сдачи проекта в промышленную эк­сплуатацию».

На четвертой стадии «Эксплуатация и сопровождение проекта» выполняются следующие этапы:

эксплуатация проекта; сопровождение и модернизация проекта.

На этой стадии решается вопрос о том, чьими силами (персо­налом объекта-заказчика или организации-разработчика) будут осуществляться эксплуатация и сопровождение проекта, и в слу­чае выбора второго варианта заключается «Договор о сопровож­дении проекта».

В процессе выполнения этапа «Эксплуатация проекта» осуще­ствляются исправления в работе всех частей системы при возник­новении сбоев, регистрация этих случаев в журналах, отслежива­ние технико-экономических характеристик работы системы и на­копление статистики о качестве работы всех компонентов системы.

На этапе «Сопровождение и модернизация проекта» выполня­ется анализ собранного статистического материала, а также ана­лиз соответствия параметров работы системы требованиям ок­ружающей среды. Анализ осуществляет создаваемая для этих це­лей комиссия. Результаты анализа позволяют:

• сделать заключение о необходимости модернизации всего про­екта или его частей;

• определить объемы доработок, сроки и стоимость выполне­ния этих работ с целью получения «Техно-рабочего проекта», прошедшего модернизацию.

В случае выявления факта морального старения проекта ко­миссией принимается решение о целесообразности проведения его утилизации или разработки нового проекта для данного объекта.

Лекция 7. Технологии автоматизированного проектирования ИС

Возрастающая сложность разработки ИС, повышение требований приводят к необходимости применения новых технологий разработки, прежде всего CASE-технологий.

Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное зна­чение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоя­щее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при исполь­зовании структурных методологий проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т. д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоя­тельными, они только обеспечивают, высокую эф­фективность, а в некоторых случаях и принципи­альную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объек­тно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями систе­мы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и мо­делирования технических средств.

Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколь­ко порядков превышает цену ошибок, выявленных на более по­здних этапах разработки.

В [Вендров] дается следующее определение CASE-технологии.

CASE-технология представляет собой совокупность методов проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей.

Преимущества CASE-технологии по сравнению с традицион­ной технологией оригинального проектирования сводятся к сле­дующему:

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

CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нота­ции строятся диаграммы, поддерживаемые инструментальной средой.

Методология определяет шаги и этапность реализации про­екта, а также правила использования методов, с помощью кото­рых разрабатывается проект.

Метод — это процедура или техника генерации описаний ком­понентов ИС (например, проектирование потоков и структур данных).

Нотация — отображение структуры системы, элементов дан­ных, этапов обработки с помощью специальных графических сим­волов диаграмм, а также описание проекта системы на формаль­ных и естественных языках.

Инструментальные средства CASE — специальные програм­мы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.

2 Архитектура CASE-средств

Рассмотрим архитектуру CASE-средства, которая представ­лена на рис. 1.

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

Репозиторий содержит информацию об объектах проектиру­емой ИС и взаимосвязях между ними, все подсистемы обмени­ваются данными с ним. В репозитории хранятся описания следу­ющих объектов:

проектировщиков и их прав доступа к различным компонен­там системы; организационных структур; диаграмм; компонентов диаграмм; связи между диаграммами; структур данных; программных модулей; процедур; библиотеки модулей и т. д.

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

Графический редактор диаграмм предназначен для отобра­жения в графическом виде в заданной нотации проектируемой ИС. Он позволяет выполнять следующие операции:

создавать элементы диаграмм и взаимосвязи между ними; задавать описания элементов диаграмм; задавать описания связей между элементами диаграмм; редактировать элементы диаграмм, их взаимосвязи и описания.

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

мониторинг правильности построения диаграмм; диагностику и выдачу сообщений об ошибках; выделение на диаграмме ошибочных элементов.
Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут стро­иться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:

инициализации проекта; задания начальных параметров проекта; назначения и изменения прав доступа к элементам проекта; мониторинга выполнения проекта.

Сервис представляет собой набор системных утилит по об­служиванию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория.

3 Классификация CASE-систем

Современные CASE-системы классифицируются по следую­щим признакам:

1)по поддерживаемым методологиям проектирования: функ­ционально (структурно) — ориентированные, объектно-ориентиро­ванные и комплексно-ориентированные (набор методологий про­ектирования);

по поддерживаемым графическим нотациям построения ди­аграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями; по степени интегрированности: tools (отдельные локальные средства), toolkit (набор не интегрированных средств, охватыва­ющих большинство этапов разработки ИС) и workbench (пол­ностью интегрированные средства, связанные общей базой про­ектных данных — репозиторием); по типу и архитектуре вычислительной техники: ориенти­рованные на ПЭВМ, ориентированные на локальную вычисли­тельную сеть (ЛВС), ориентированные на глобальную вычисли­тельную сеть (ГВС) и смешанного типа; по режиму коллективной разработки проекта: не поддер­живающие коллективную разработку, ориентированные на ре­жим реального времени разработки проекта, ориентированные на режим объединения подпроектов; по типу операционной системы (ОС): работающие под уп­равлением WINDOWS, работающие под управле­нием UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.); по этапам процесса проектирования ИС: выделяют системы поддерживающие

7.1 Анализ и проектирование (BPWin, Rational Rose, Silverrun);

7.2 Проектирование БД и файлов (ERWin, Silverrun — ERX, PowerDesigner);

7.4 Сопровождение и реинжиниринг(ИС);

7.5 Окружение (платформа);

7.6 Управление проектом (MS Project);

7.7 Реинжиниринг бизнес процессов (BPWin).

В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными воз­можностями (такие, как редакторы диаграмм), так и дорогостоя­щие системы для больших ЭВМ.

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

Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на про­ектирование и генерацию баз данных и пользовательских интер­фейсов. Генерация интерфейсов с базами данных и возможность пре­образования (конвертирования) между различными концепту­альными схемами и моделями данных увеличивает мобильность прикладных систем при переходе в другие операционные сре­ды. Генерация кода и (или) таблиц, описывающих интерфейс прикладной системы с базой данных, не только позволяет со­кратить время разработки, но и дает возможность отделить раз­работку приложений от ведения архива проектной докумен­тации.

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

5 Методологии проектирования ИС

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

В основу функционально-ориентированного положен принцип функциональной декомпозиции. Структура системы описывается в терминах иерархии функций системы и передачи информации между отдельными функциональными элементами.

Объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение, в терминах обмена сообщениями между ними.

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

Различными авторами разработано большое количество структурных методологий, которые основаны на одних и тех же принципах, но отличаются нотациями и другими деталями. Наибольшее распространение получили методологии и соответствующие нотации Йодана — де Марко, Гейна-Сарсона, названные именами авторов и использующие разновидности диаграмм потоков данных (DFD) для построения моделей функционирования систем, и модель «Сущность-связь» (E-R) для проектирования баз данных. Кроме того, широко известна методология SADT (Structured analysis and Design Technique), предложенная в 1973 году Д. Россом и некоторые другие.

Большое распространение получили IDEF-технологии, ориентированные на поддержку, в основном, структурных методологий проектирования информационных систем организационного типа. Семейство стандартов IDEF в настоящее время насчитывает 14 моделей. Среди них методология IDEF0 предназначена для функционального моделирования и реализует методику SADT. Стандарты IDEF1 и IDEF1X реализуют методики проектирования баз данных. Многие CASE-средства обеспечивают поддержку стандартных методологий IDEF.

При использовании объектного подхода широкое распространение получил стандартный язык объектного моделирования UML и поддерживающие его CASE-системы (PationalRose).

Рассмотрим более подробно основные структурные методологии проектирования.

Тема: Методологии структурного анализа и проектирования ИС

Структурные методологии основаны на использовании принципов и методов структурного системного анализа и проектирования (ССА).

Структурным анализом принято называть метод иссле­дования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую струк­туру со все большим числом уровней.

Для структурных методов характерно:

разбиение на уровни абстракции с ограниче­нием числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; рассмотрение дан­ных в совокупности с операциями над ними; использование строгих фор­мальных правил описания элементов системы; последовательное приближение к конечному результату.

2.1 Принципы ССА

Все методологии структурного анализа базируются на ряде общих принципов. В качестве базовых принципов используются следующие:

1) декомпозиции («разделяй и вла­ствуй»). Состоит в разбиении исследуемого процесса на функциональные бло­ки — подпроцессы.

2) принцип иерархического упорядочивания. Означает возможность детализации (декомпо­зиции) любых нужных нам процессов в виде так называемых «иерархических структур»;

3) использования графических нотаций с возможностью «тек­стового» поясняющего дополнения.

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

Использование графических нотаций обеспечивает наглядность, легкость и простоту понимания.

Кроме базовых принципов необходимо руководствоваться также рядом нижеследующих. Можно отметить, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта).

1. Принцип абстрагирования — заключается в вы­делении существенных с некоторых позиций ас­пектов системы и отвлечение от несущественных с целью представления проблемы в простом об­щем виде.

2. Принцип формализации — заключается в необ­ходимости строгого методического подхода к ре­шению проблемы.

3. Принцип упрятывания — заключается в упрятыва­нии несущественной на конкретном этапе ин­формации: каждая часть «знает» только необходимую ей информацию.

4. Принцип концептуальной общности — заключа­ется в следовании единой философии на всех этапах ЖЦ (структурный анализ — структурное проектирование — структурное программирова­ние — структурное тестирование).

5. Принцип полноты — заключается в контроле на присутствие лишних элементов.

6. Принцип непротиворечивости — заключается в обоснованности и согласованности элементов.

7. Принцип логической независимости — зак­лючается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.

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

9. Принцип структурирования данных — заключается в том, что данные должны быть структуриро­ваны и иерархически организованы.

10.Принцип доступа конечного пользователя — зак­лючается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без прог­раммирования).

Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независи­мо от типа разрабатываемой системы и используемых при этом методологий. Руководствуясь всеми принципами в комплексе, можно на более ранних стадиях разработки понять, что будет представлять собой создаваемая система, обнаружить промахи и недоработки, что, в свою оче­редь, облегчит работы на последующих этапах ЖЦ и по­низит стоимость разработки.

2.2 Средства структурного анализа

Прежде чем подробно рассмотреть каждое из основ­ных инструментальных средств структурного анализа, необходимо обсудить их в общем виде и продемонстри­ровать их взаимосвязи.

Для целей моделирования систем вообще, и структур­ного анализа в частности, используются три группы средств, иллюстрирующих:

• функции, которые система должна выполнять;

• отношения между данными;

• зависящее от времени поведение системы (аспекты реального времени).

Среди всего многообразия средств решения данных за­дач в методологиях структурного анализа наиболее час­то и эффективно применяемыми являются следующие:

IDEF0 — (Function Modelling Method) — диаграммы функционального моделирования;

• DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов ;

• ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» ;

• STD (State Transition Diagrams) — диаграммы пе­реходов состояний.

Все они содержат графические и текстовые средства моделирования: первые — для удобства демонстрирования основных компонентов модели, вторые — для обеспечения точного определения ее компонентов и связей.

Лекция 8. Методологии структурного проектирования ИС (продолжение)

1 Методология IDEF0

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT — Structured Analysis and Design Technique. В дальнейшем это подмножество SADT было принято в качестве международного стандарта под наиме­нованием IDEF0. Методология отражает такие общесистемные характеристики как управление, обратная связь, исполнители, необходимые для представления различных систем, что обеспечивает широкую сферу применения.

2 Основные понятия IDEF-технологии

В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объек­тов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

Элементарной единицей представления информации является блок (графический прямоугольник), моделирующий некоторые работы (действия, функции, процессы) системы. Взаимодействие системы с окружающим миром опи­сывается как вход (нечто, что перерабатывается системой), выход (резуль­тат деятельности системы), управление (стратегии и процедуры, под управ­лением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.

Входы, управление и выходы определяют интерфейсы между блоками и представляются стрелками имеющие четко определенное направление. Стрелка входа всегда направлена в левую сторону блока, выход — от правой стороны, управление — в верхнюю сторону, а механизм в нижнюю.


Каждый блок может быть подвергнут декомпозиции.

Под моделью в IDEF0 понимают описание системы (текстовое и графи­ческое), которое должно дать ответ на некоторые заранее определенные вопросы.

Формальное определение: M есть модель системы S, если M может быть использована для получения ответов на вопросы относительно S c точностью A. Таким образом, каждая модель имеет назначение, называемое целью.

2 Этапы моделирования

В самом общем виде в процессе построения модели IDEF можно выделить три этапа:

1) подготовительный (определение контекста);

2) определение данных для построения модели;

3) построение IDEF-диаграмм.

2.1 Подготовительный (определение контекста)

Процесс моделирования какой-либо системы в IDEF0 начинается с оп­ределения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.

2.1.1 Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматри­вать как компоненты системы, а что как внешнее воздействие. На опреде­ление субъекта системы будет существенно влиять позиция, с которой рас­сматривается система, и цель моделирования — вопросы, на которые по­строенная модель должна дать ответ. Другими словами, первоначально не­обходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначаль­но, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необ­ходимо учитывать два компонента — широту и глубину. Широта подразуме­вает определение границ модели — мы определяем, что будет рассматри­ваться внутри системы, а что снаружи. Глубина определяет, на каком уров­не детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии от глубины деком­позиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объ­екты модели взаимосвязаны, внесение нового объекта может быть не про­сто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема «плава­ющей области»).

2.1.2 Цель моделирования (Purpose). Модель не может быть построена без чет­ко сформулированной цели. Цель должна отвечать на следующие вопросы:

Почему этот процесс должен быть моделирован? Что должна показывать модель? Что может получить читатель?

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

2.1.3 Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит сис­тему в нужном для моделирования аспекте. Точка зрения должна соответ­ствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответствен­ного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.

IDEFO-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

2.2 Определение данных для построения модели IDEF0

Определение данных для построения модели состоит из следующих работ:

1) Сбор информации о системе;

2) Выбор варианта декомпозиции;

3) Определение состава функций.

2.2.1 Сбор информации о системе. После того как определены цель, субъект и точка зрения, необходимо собрать данные о моделируемой системе, необходимые для построения модели. При этом используются наиболее подходящие в каждой конкретной ситуации методы сбора [Смирнова]. Наиболее часто используемыми являются изучение внутренней документации, наблюдение, анкетирование, опросы экспертов, использование собственного опыта и другие. На данном этапе выявляются основные потоки данных, как информационные, так и ресурсные.

2.2.2 Выбор варианта декомпозиции. Для корректного и точного описания системы и ее функций важное значение имеет выбор варианта декомпозиции, т. е. принципа выделения функциональных подсистем. Чаще всего предполагается декомпозиция по функциям управления и декомпозиция, основанная на функциональных взаимоотношениях в системе.

2.2.3 Определение состава функций. На данном этапе необходимо построить дерево функций системы со степенью детализации, соответствующей цели моделирования.

Процесс моделирования является итерационным, с участием различных экспертов и специалистов. Таким образом, в процессе моделирования дерево основных функций уточняется и конкретизируется.

2.3 Построение IDEF — диаграмм. Процесс построения диаграмм начинается после определения основных потоков данных и функций модели. Диаграмма является основным рабочим элементом при создании модели и имеет собственные правила построения, собственный графический язык.

3 Диаграммы IDEFO.

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диа­грамм. Каждая диаграмма является единицей описания системы и распо­лагается на отдельном листе.

Модель может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна кон­текстная диаграмма); диаграммы декомпозиции; диаграммы дерева узлов; диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаи­модействия с внешней средой.

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

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

Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.

3.1 Объекты диаграмм

Основными объектами IDEF-диаграмм являются работы (функциональные блоки) и стрелки (дуги), которые отражают взаимодействие и связи между ними.

3.1.1 Работы (Activity) ‘

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

Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обес­печения наглядности и лучшего понимания моделируемых процессов реко­мендуется использовать от трех до шести блоков на одной диаграмме.

Работы на диаграммах декомпозиции обычно располагаются по диаго­нали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое рас­положение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ

Каждая из работ на диаграмме декомпозиции может быть в свою оче­редь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом ниж­нем углу. В левом верхнем углу изображается небольшая диагональная чер­та, которая показывает, что данная работа не была декомпозирована.

3.1.2 Стрелки (Arrow)

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и имену­ются существительными (например: «Заготовка», «Изделие», «Заказ»)

В IDEF0 различают пять типов стрелок:

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

Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. «Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. Например, стрелки «Задание» и «Чертеж»- управ­ление для работы «Изготовление изделия». Управление влияет на работу, но не преобразуется работой. Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.

Выход (Output) — материал или информация, которые производятся ра­ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка вы хода рисуется как исходящая из правой грани работы. Например, стрелка «Готовое изделие» является выходом для работы «Изготовление изделия».

Механизм (Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. Например, стрелка «Персонал предприятия» является механизмом для работы «Изготовление изделия». По усмотрению аналитика стрелки механизма могут не изображаться в модели.

Вызов (Call) — специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.

В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

Граничные стрелки. Стрелки на контекстной диаграмме служат для опи­сания взаимодействия системы с окружающим миром. Они могут начи­наться у границы диаграммы и заканчиваться у работы, или наоборот. Та­кие стрелки называются граничными.

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, ра­бота на диаграмме верхнего уровня в IDEF0 — это не элемент управления нижестоящими работами. Работы нижнего уровня — это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня — это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) — коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С. О или М), и порядковый номер. BPwin вносит ICOM-коды автоматически.

Внутренние стрелки. Для связи работ между собой используются внут­ренние стрелки, т. е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.

В IDEF0 различают пять типов связей работ.

Связь по входу (output-input), когда стрелка выхода вышестоящей рабо­ты (далее — просто выход) направляется на вход нижестоящей (например, стрелка «Заказы» связывает работы «Прием заказа» и » Выписка счета»

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает до­минирование вышестоящей работы. Данные или объекты выхода выше­стоящей работы не меняются в нижестоящей. На рис. 1.15 стрелка «Чертеж» связывает работы «Создание чертежа детали» и «Изготовление детали**), при этом чертеж не претерпевает изменений в процессе изготов­ления деталей.

Обратная связь по входу (output-input feedback), когда выход нижестоя­щей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. Например, стрелка «Брак» связывает работы «Переработка сырья» и «Контроль качества», при этом выявлен­ный на контроле брак направляется на вторичную переработку.

Обратная связь по управлению (output-control feedback), когда выход ни­жестоящей работы направляется на управление вышестоящей (стрелка «Рекомендации», рис. 1.17). Обратная связь по управлению часто свидетель­ствует об эффективности бизнес — процесса. На рис. 1.17 качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы «Контроль качества».

Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже ос­тальных и показывает, что одна работа подготавливает ресурсы, необходи­мые для проведения другой работы.

Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в не­скольких других работах. С другой стороны, стрелки, порожденные в раз­ных работах, могут представлять собой одинаковые или однородные дан­ные или объекты, которые в дальнейшем используются или перерабатыва­ются в одном месте. Для моделирования таких ситуаций в IDEF0 исполь­зуются разветвляющиеся и сливающиеся стрелки.

Смысл разветвляющихся и сливающихся стрелок передается именова­нием каждой ветви стрелок. Существуют определенные правила именова­ния таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления.

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответст­вуют именованию. Если при этом какая-либо ветвь после разветвления ос­талась неименованной, то подразумевается, что она моделирует те же дан­ные или объекты, что и ветвь до разветвления.

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

Правила именования сливающихся стрелок полностью аналогичны — ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей.

Тоннелирование стрелок. Вновь внесенные граничные стрелки на диа­грамме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня

Тоннелирование может быть применено для изображения малозначи­мых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо на­править на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутст­вует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое тоннелирование называется «не-в-родительской-диаграмме».

Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исклю­чения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть затоннелирована, а в коммента­рии к стрелке или в словаре можно указать, что механизм будет использо­ваться во всех работах дочерней диаграммы декомпозиции. Такое тоннели­рование называется «не-в-дочерней-работе».

4. Рекомендации по рисованию диаграмм

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, раз­ветвляться и пресекаться. Такие диаграммы могут стать очень плохо читае­мыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих пра­вил BPwin поддерживает автоматически, выполнение других следует обес­печить вручную.

Прямоугольники работ должны располагаться по диагонали с левого
верхнего в правый нижний угол (порядок доминирования). При создании новой диаграммы декомпозиции BPwin автоматически располагает
работы именно в таком порядке. В дальнейшем можно добавить новые
работы или изменить расположение существующих, но нарушать диагональное расположение работ по возможности не следует. Порядок до­
минирования подчеркивает взаимосвязь работ, позволяет минимизировать изгибы и пересечения стрелок. Следует максимально увеличивать расстояние между входящими или
выходящими стрелками на одной грани работы. Если включить опцию
Line Drawing: Automatically space arrows на закладке Layout диалога
Model Properties (меню Edit/Model Properties), BPwin будет располагать
стрелки нужным образом автоматически. Следует максимально увеличить расстояние между работами, поворота­ми и пересечениями стрелок. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и назвать единым термином. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению — «верхней». BPwin автоматически ри­сует обратные связи нужным образом. Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwin не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала соз­дать обычную связь по входу, затем разветвить стрелку, направить но­вую ветвь обратно ко входу работы-источника и, наконец, удалить ста­рую ветвь стрелки выхода. Следует минимизировать число пересечений, петель и поворотов стре­лок. Это ручная и, в случае насыщенных диаграмм, творческая работа. Если нужно изобразить связь по входу, необходимо избегать «нависания» работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существую­щей организации работы — AS-IS (как есть). На основе модели AS-IS дос­тигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыг­нуть на то, «что мы будем делать завтра». Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состо­ять преимущества новых бизнес-процессов и насколько глубоким измене­ниям подвергнется существующая структура организации бизнеса. Детали­зация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Призна­ками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный до­кумент не оказывается в нужном месте в нужное время), отсутствие обрат­ных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при созда­нии модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных (лучших) пу­тей выполнения работы и документирования того, как компания будет де­лать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS — это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного испол­нителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную ин­формацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-1S, ее анализ и улучшение бизнес процессов, т. е. создание модели ТО-ВЕ. и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «вес оставить

как есть, только чтобы компьютеры стояли», т. е. ИС автоматизирует несо­вершенные бизнес процессы и дублирует, а не заменяет существующий Документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая про­цесс перехода от начального к конечному состояния системы, поскольку такой переход — это тоже бизнес-процесс.

Лекция 9. Диаграммы потоков данных (DFD)

1 Средства структурного анализа и их взаимосвязи

Прежде чем подробно рассмотреть каждое из основ­ных инструментальных средств структурного анализа, необходимо обсудить их в общем виде и продемонстри­ровать их взаимосвязи.

Для целей моделирования систем вообще, и структур­ного анализа в частности, используются три группы средств, иллюстрирующих:

    функции, которые система должна выполнять; отношения между данными; зависящее от времени поведение системы (аспекты реального времени).

Среди всего многообразия средств решения данных за­дач в методологиях структурного анализа наиболее час­то и эффективно применяемыми являются следующие:

    DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов ; ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» ; STD (State Transition Diagrams) — диаграммы пе­реходов состояний.

Все они содержат графические и текстовые средства моделирования: первые — для удобства демонстрирования основных компонентов модели, вторые — для обеспечения точного определения ее компонентов и связей.

Логическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, иден­тифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопи­тели) данных, к которым осуществляется доступ. Структу­ры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помо­щью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реаль­ного времени DFD дополняется средствами описания зави­сящего от времени поведения системы, раскрывающимися с помощью STD. Эти связи показаны на рис. 1.1.

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

Рис. 1.1. Компоненты логической модели

2 Диаграммы потоков данных

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процес­сы) и. представляются в виде сети, связанной потоками данных. Главная цель таких средств — продемонстриро­вать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для изображения DFD традиционно используются две различные нотации: Иодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Иодана, все исключения будут предварительно оговариваться.

2.1 Основные символы DFD

Основные символы DFD изображены на рис.2.1. Опи­шем их назначение. На диаграммах функциональные требования представляются с помощью процессов и храни­лищ, связанных потоками данных.

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

2. Назначение процесса(Process) состоит в преобразовании входных потоков в выходные в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, вычислить максимальную высоту). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

3. Хранилище (накопитель, Store) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет “срезы” потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

3. Внешняя сущность (External entity) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, СКЛАД ТОВАРОВ. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

Рис. 2.1. Основные символы диаграмм потоков данных

2.2 Контекстная диаграмма и детализация процессов

Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня.

Важную специфическую роль в модели играет специальный вид DFD — контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. Каждый проект должен иметь только одну контекстную диаграмму, при этом нет необходимости в нумерации ее единственного процесса.

DFD первого уровня строится как декомпозиция пр оцесса, который присутствует на контекстной диаграмме.

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

При таком построении иерархии DFD каждый пр оцесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Та к, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощь DFD, содержащей три процесса, то их номера буд ут иметь следующий вид: 2.1, 2.2 и 2.3. При необходим ости можно перейти на следующий уровень, т. е. для процесса 2.2 получим 2.2.1, 2.2.2 и т. д.

2.3 Построение модели

Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясны­ми и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесо­образно пользоваться следующими рекомендациями:

• Размещать на каждой диаграмме от 3 до 6-7 про­цессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и пони­мания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по сооб­ражениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

Не загромождать диаграммы несущественными на данном уровне деталями.

Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов.

Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм.

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

В соответствии с этими рекомендациями процесс посгроения модели разбивается на следующие этапы:

1. Расчленение множества требований и организация их в основные функциональные группы.

2. Идентификация внешних объектов, с которыми система должна быть связана.

3. Идентификация основных видов информации циркулирующей между системой и внешними объектами.

4. Предварительная разработка контекстной диаграм­мы, на которой основные функциональные группы представляются процессами, внешние объекты — внешними сущностями, основные виды ин­формации — потоками данных между процес­сами и внешними сущностями.

5. Изучение предварительной контекстной диаграм­мы и внесение в нее изменений по результатам ответов на возникающие вопросы по всем ее частям.

6. Построение контекстной диаграммы путем объ­единения всех процессов предварительной диаг­раммы в один процесс, а также группирования потоков.

7.Формирование DFD первого уровня на базе про­цессов предварительной контекстной диаграммы.

8. Проверка основных требований по DFD первого уровня.

9. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спе­цификации процесса.

Проверка основных требований по DFD соот­ветствующего уровня.

11.Добавление определений новых потоков в сло­варь данных при каждом их появлении на ди­аграммах.

12.Параллельное (с процессом декомпозиции) изу­чение требований (в том числе и вновь пос­тупающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.

13.После построения двух-трех уровней проведение ревизии с целью проверки корректности и улуч­шения понимаемости модели.

14.Построение спецификации процесса (а не про­стейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить ком­бинацией процессов.

2.4 Пример банковской задачи

В качестве примера создания модели рассмотрим фрагмент проекта системы, организующей работу банкомата по обслуживанию клиента по его кредитной карте. Этот пример будет строиться поэтапно, на нем будут продемонстрированы базовые техники структурного анализа и проектирования по мере их определения. На рис. 2.3 приведена контекстная диаграмма системы единственным процессом ОБСЛУЖИТЬ, идентифицирующая внешние сущности КЛИЕНТ и КОМПЬЮТЕР БАНКА, хранящий информацию о счетах всех клиентов. Опишем потоки данных, которыми обменивается проектируемая система с внешними объектами. Для банковского обслуживания клиенту необходимо предоставить системе свою КРЕДИТНУЮ КАРТУ для автоматического считывания с нее информации (ПАРОЛЬ, ЛИМИТ ДЕНЕГ, ДЕТАЛИ КЛИЕНТА), а также сообщить свои КЛЮЧЕВЫЕ ДАННЫЕ, а именно ПАРОЛЬ, ЗАПРОС НА ОБСЛУЖИВАНИЕ, т. е. требуемую ему услугу (например, снятие со счета наличных денег). Банковское обслуживание с позиций клиента, в свою оче­редь, должно обеспечить следующее:

• выдать СООБЩЕНИЕ, приглашающее клиента вве­сти КЛЮЧЕВЫЕ ДАННЫЕ;

• выдать клиенту ДЕНЬГИ;

• выдать клиенту ВЫПИСКУ по проведенному обслу­живанию, включающую ВЫПИСКУ О ДЕНЬГАХ, ВЫПИСКУ ПО БАЛАНСУ и ВЫПИСКУ ПО ОПЕ­РАЦИИ, проведенной банком.

Контекстный процесс и КОМПЬЮТЕР БАНКА долж­ны обмениваться следующей информацией:

• ДАННЫЕ ПО СЧЕТУ клиента в банке;

• ПРОТОКОЛ ОБСЛУЖИВАНИЯ, включающий ин­формацию об ОБРАБОТАННОЙ ДОКУМЕНТА­ЦИИ, изымаемой ДЕНЕЖНОЙ СУММЕ и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.

Контекстный процесс может быть детализирован DFD первого уровня как показано на рис. 2.4. Эта диаг­рамма содержит 4 процесса и хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ, которое изображено дважды на диаграмме с целью избежания пересечений линий пото­ков данных.

Процесс 1.1 (ПОЛУЧИТЬ ПАРОЛЬ) осуществляет при­ем и проверку пароля клиента и имеет на входе/выходе следующие потоки:

• внешний выходной поток СООБЩЕНИЕ для инфор­мирования клиента о готовности принять пароль;

• входной поток ВВЕДЕННЫЙ ПАРОЛЬ как элемент внешнего потока КЛЮЧЕВЫЕ ДАННЫЕ;

* входной поток ПАРОЛЬ из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ для проверки вводимого кли­ентом пароля.

Процесс 1.2 (ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИ­ВАНИЕ) осуществляет прием и проверку запроса клиента на проведение необходимой ему банковской операции и на входе/выходе следующие потоки:

• внешний выходной поток СООБЩЕНИЕ для инфор­мирования клиента о своей готовности принять запрос на обслуживание;

• входной поток ЗАПРОС НА ОБСЛУЖИВАНИ как элемент внешнего потока КЛЮЧЕВЫЕ ДАННЫЕ;

* входной поток ЛИМИТ ДЕНЕГ из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ для контроля наличия денег на счете клиента.

Процесс 1.3 (ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУ ЖИВАНИЕ) имеет внешний входной поток ДАННЫЕ ПО СЧЕТУ (из внешней сущности КОМПЬЮТЕР БАНКА), входной поток ДЕТАЛИ КЛИЕНТА (из хранилища), а также внешние выходные потоки ВЫПИСКА, ДЕНЬГИ и ПРОТОКОЛ ОБСЛУ ЖИВАНИЯ.

Процесс 1.4 (ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ) осуществляет считывание информации с кредитной карты и имеет на входе внешний поток КРЕДИТНАЯ КАРТА а на выходе поток ДАННЫЕ КРЕДИТНОЙ КАРТЫ. Отметим, что нет необходимости в идентификации последнего потока, т. к. идентифицировано соответствую шее хранилище.

Процессы 1.1, 1.2 и 1.4 являются элементарными, поэтому нет необходимости в их детализации с помощью DFD уровня 2 (они будут раскрыты с помощью спецификаций процессов ). Процесс 1.3 может быть детализирован с помощью DFD второго уровня как показано на рис. 2.5. Эта диаграмма содержит 4 элементарных процесса, спецификации которых также буду приведены в главе 4.

Процесс 1.3.1 (ОБРАБОТАТЬ ДОКУМЕНТАЦИИ БАНКА) осуществляет обработку внутренней банковской документации по клиенту и имеет входной поток ДЕТАЛИ КЛИЕНТА и выходной поток ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ (часть внешнего поток ПРОТОКОЛ СДЕЛКИ).

Процесс 1.3.2 (РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТЫ выдает справку по истории счета клиента и по баланс клиента. Входные потоки — ДЕТАЛИ КЛИЕНТА ДАННЫЕ ПО БАЛАНСУ (часть внешнего потока ДАННЫЕ ПО СЧЕТУ), выходные потоки — ВЫПИСКА ПО БАЛАНСУ (часть внешнего потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть внешней потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Процесс 1.3.3 (ПРИГОТОВИТЬ ДЕНЬГИ КЛИЕНТУ) обеспечивает выдачу наличных денег и информирование компьютера банка об изъятых из банка деньгах. Он имеет входные потоки ДЕНЕЖНАЯ СУММА и ДЕТАЛИ КЛИЕНТА, и выходные потоки ДЕНЬГИ и ДЕНЕЖ­НАЯ СУММА (часть потока ПРОТОКОЛ ОБСЛУЖИ­ВАНИЯ).

Процесс 1.3.4 (РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА) выдает справку по истории счета и уведомление по проведенной операции. Входные потоки ДАННЫЕ ПО СЧЕТУ и ДЕТАЛИ КЛИЕНТА, выходные потоки — ВЫПИСКА ПО ОПЕРАЦИИ (часть потока ВЫПИС­КА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Рис 2.4. Детализация процесса ОБСЛУЖИТЬ

Рис.2.5. Детализация процесса ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ

Лекция 9 Технологическая сеть проектирования ИС на основе исполь­зования функционально-ориентированной Case-технологии

Технологическая сеть проектирования ИС на основе исполь­зования функционально-ориентированной Case-технологии представлена на рис. 13.7.

Технологические операции с преобразователями П1, П2, ПЗ, П4, П5, П6, П7 выполняются на стадии технического проекти­рования.

Преобразователь П1 «Инициализация проекта» используется для инициализации нового проекта ИС. На основании докумен­та D1 «Материалы обследования» создается новый репозиторий G1 для проектируемой системы.

Преобразователем П2 «Задание начальных параметров проек­та» из универсума методологий проектирования U1 выбирается Case-методология проектирования и в рамках выбранной ме­тодологии определяется нотация на основе универсума U2. Пе­речень проектировщиков и их прав доступа к проекту D2 служит для описания коллектива разработчиков проекта. Результатом выполнения операции является описание начальных параметров проекта в репозитории D3.

Технологические операции с преобразователями ПЗ, П4, П5 и П6 выполняются последовательно-параллельно и взаимно уточ­няются в ходе выполнения.

На основе «Материалов обследования» D1 и универсума кон­структивных элементов диаграмм иерархии функций U3 выпол­няется технологическая операция с преобразователем ПЗ «Пост­роение диаграммы иерархии функций».

Выполнение преобразователя ПЗ сводится к выполнению сле­дующих работ:

отображению основной функции; декомпозиции основной функции на подфункции ; дальнейшей декомпозиции подфункций до необходимой сте­пени детализации; контролю правильности построенной диаграммы.
Выходом преобразователя служит описание в репозитории

дерева функций проекта D4.

Входом технологической операции с преобразователем П4 «Построение диаграммы потоков данных» являются:

материалы обследования (D1); диаграмма иерархии функций (D4); диаграмма «сущность-связь» (D6); универсум конструктивных элементов диаграмм потоков дан­ных U4.

Построение ДПД можно свести к следующим шагам.

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

Выходом данной операции является описание в репозитории диаграммы потоков данных D5.

Преобразователь технологической операции П5 «Построение диаграммы переходов состояний» описывает возможные состоя­ния проектируемой системы и переходы между ними.

При построении ДПС рекомендуется следовать перечислен­ным ниже правилам:

начинать построение ДПС на высоком уровне детализации
ДПД; строить наиболее простые диаграммы, содержащие 4-6 состояний; по возможности включать детализацию в виде подчинен­ных шагов состояния (детализация на другом уровне); использовать те же приемы наименования состояний, со­бытий и действий, что и при наименовании процессов и потоков.

Применяются 2 способа построения ДПС:

первый способ заключается в том, что выявляются возмож­ные состояния системы и далее выявляются переходы из од­ного состояния в другое; при втором способе сначала строится начальное состояние,
затем осуществляется переход в очередное состояние и т. д.
(последовательный переход).,

В результате получаем предварительную ДПС. Затем она про­веряется на корректность ее построения. Когда число состояний и переходов достаточно велико, эта диаграмма может быть пред­ставлена в табличной форме «Матрица переходов состояний» (рис. 13.8).

Входом преобразователя являются:

материалы обследования (D1); диаграмма иерархии функций (D4);

Рк. 13.8. Графы матрицы переходов состояний

диаграмма потоков данных (D5); диаграмма «сущность-связь» (D6); универсум конструктивных элементов диаграмм переходов
состояний (U6).

Выход данной операции представлен интегрированным опи­санием в репозитории функций, потоков данных и состояний проектируемой системы (D7).

Технологическая операция с преобразователем П6 «Постро­ение диаграммы «Сущность-связь» моделирует структуры данных, которые будут храниться в БД. Для ее выполнения необходима следующая входная информация:

материалы обследования (D1); диаграмма потоков данных (D5); универсум конструктивных элементов диаграмм «сущность-
связь» (U5).

Построение ER-диаграмм сводится к следующим этапам.

Идентифицируются все, сущности, их атрибуты, а также первичные ключи. Идентифицируются отношения между сущностями и ука­зывается мощность этих отношений. Если на втором этапе были выявлены отношения N:N, та­кие отношения являются неспецифическими для реляционных, и их нужно преобразовать либо в 1:М, либо в 1:1. Как правило, это делается с помощью добавления новой сущности.

Выход данной операции представлен описанием в репозито­рии диаграммы «сущность-связь» (D6).

Технологическая операция с преобразователем П7 «Пост­роение системной структурной диаграммы» используется для построения структуры программного приложения ИС (D8).

На вход преобразователя подаются:

диаграмма иерархии функций (D4); диаграмма потоков данных (D5); диаграмма «сущность-связь» (Dб); диаграмма переходов состояний(D7); универсум конструктивных элементов программного прило­жения (U7).

Выходом преобразователя служит описание в репозитории структуры программного приложения (D8).


Этапы построения системной структурной диаграммы.

В диаграмме бизнес-функций необходимо выделить функ­ции, которые будут реализованы в программном виде. Взять диаграмму потока данных (соответствующие уровни DFD) для выделенных функций и подфункций и проанализиро­вать ее с учетом входных и выходных потоков данных. Определить структуру потоков данных, задав список атри­бутов сущностей из ER-диаграммы. На диаграмме переходов состояний определить состояния, переходы и события их вызывающие, которые реализуют бизнес-функции. Задать программную реализацию каждого состояния в виде библиотечного модуля Case-системы или модуля, написанного на другом языке. Нарисовать эскиз системной структурной диаграммы для каждой выделенной функции. Объединить построенные системные структурные диаграм­мы в одну исходя из диаграммы бизнес-функции. Проконтролировать, если позволяют Case-средства, по­строенную системную структурную диаграмму. Если во время контроля ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной структурной диаграммы.

10. Для каждого модуля необходимо выбрать шаблон интер­фейса из встроенной библиотеки либо в режиме конструктора создать шаблон, либо написать программный модуль на встро­енном языке программирования.

Таким образом, перед генерацией все элементы системной структурной диаграммы должны быть определены с учетом ин­терфейса и связи с таблицами ER-модели.

Технологические операции с преобразователями П8 – П11 отражают процесс кодогенерации проекта.

Преобразователь П8 «Генерация описания схемы БД».

На ос­нове диаграммы «сущность-связь» (D6) и системной структурной диаграммы (D8), а также универсума целевых СУБД (U8) проис­ходит выбор СУБД и генерация для нее описания схемы БД (D9).

Преобразователь П9 «Генерация модуля описания системы БД (DDL)». Входом для технологической операции с преобразова­телем П9 служат: описание схемы БД (D9);

структура программного приложения (D8); универсум языков определения данных (DDL) (U9).

В результате процесса генерации получаем исходные тексты программ на языке выбранной среды (D9). Генерация может быть двух видов:

Неполная генерация заключается в том, что на основе ди­аграммы «сущность-связь» и выбранной целевой СУБД генери­руются модули описания данных DDL на языке описания дан­ных. В результате выполнения неполной генерации на выбран­ном языке определения данных (SQL и т. п.) создается модуль описания данных (D10). Полная генерация включает в себя: генерацию на языке описания данных; выбор среды, в которой будет приведен исходный код, полу­ченный во время генерации; запуск процесса генераций.

Преобразователь П10 «Генерация приложения (DDM) ». На ос­нове системной структурной диаграммы (D8) и универсума язы­ков определения модулей DDM (U10) происходит генерация мо­дулей программного приложения П10. Результатом генерации яв­ляются модули программного приложения, реализующего ИС (D10).

Преобразователь П11 «Интеграция модулей приложения».

В ре­зультате выполнения технологической операции с преобразова­телем П11 происходит интеграция полученных ранее модулей D10 и D11, что приводит к получению готового программного при­ложения, реализующего ИС (G2).

Лекция 10. Структурные методологии проектирования (продолжение).

1 Расширения реального времени

Расширения реального времени используется для дополнения модели функционирования системы (иерархии DFD) средствами описания управляющих аспектов в системах реального времени. Для этих целей используются следующие объекты(см. рис):

1) управляющий процесс. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени. Его имя указывает на тип управля. щей деятельности. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные. Точное описание этого преобразования должно задаваться в спецификациях управления.

2) Управляющее хрпнилище. Представляет собой срез управляющего потока во времени. Содержащаяся в нем управляющая информация может быть использована в любое время после занесения в хранилище. Имя хранилища должно идентифицировать ее содержание.

3) Управляющий поток представляет собой средство, мспользуемое для моделирования передачи управляющей информации. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например сигнал, представляющий состояние или вид операции.

Логически управляющий процесс есть некоторый командный пункт, реагирующий на изменение внешних условий, передаваемых ему управдяющими потоками и генерирующий команды, выполняемые процессами.

Существуют три управляющих потоков:

а) Т – поток (Trigger flow). Является потоком управления процессом, который может вызывать выполнение процесса. При этом процесс как бв включается одной короткой операцией. Это аналог выключателя светаединственным нажатием которого запускается процесс горения лампы.

б) А – поток (Activator flow). Является потоком управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока “включен” поток. С “выключением” потока выполнение процесса завершается. Это аналог переключателя лампы, которая может быть как включена, так и выключена.

3) E/D – поток (Enabe/Disable flow). Является потоком управления процессом, который может переключать выполнение отдельного процесса. Течение по Е-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это аналог выключателя с двумя кнопками: одной для включения, другой для выключения.

Дополним приведенную выше модель банкомата управляющим процессом и управляющими потоками, позволяющими описать функционирование в реальном времени (см. рис).

Управляющий процесс 1.5 (УПРАВЛЕНИЕ ОБСЛУЖИВАНИЕМ), получив информацию о том, что кредитная карта введена (поток ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА), вызывает выполнение процесса 1.1 (поток А: ПОЛУЧИТЬ ПАРОЛЬ). Получив информацию о веденном пароле (поток КОРРЕКТНЫЙ ПАРОЛЬ), процесс 1.5 информирует процесс 1.4 онеобходимости удаления кредитной карты (поток УДАЛЕННАЯ КРЕДИТНАЯ КАРТА) и с помощью потока T: ОБЕСПЕЧИТЬ ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ вызывает выполнение процесса 1.2, затем процесса 1.3 (поток ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ). Последний управляющий поток на детализирующей процесс 1.3 диаграмме разветвляется на четыре подпотока, каждый из которых вызывает выполнение процессов 1.3.1 — 1.3.4 , соответственно.

2 Диаграммы переходов состояний (STD)

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

STD состоит из следующих объектов (см. рис):

1. Состояние — может рассматриваться как условие устойчивости для системы. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система. Например: “Ожидание”, “Обработка”.

2. Начальное состояние — это узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет только одно начальное состояние, соответствующее состоянию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.

3. Переход — определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока(сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия.

Например: “Кнопка нажата”, “Счетчик = 99” и т. д.

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

На диаграмме STD состояния представлены узлами, а переходы — дугами.

Существует два способа построения STD. Первый заключается в идентификации всех возможных состояний и анализе всех имеющих смысл переходов между ними. По второму способу сначала определяется начальное состояние, затем следующее за ним и т. д.

Результатом является предварительная STD, которая затем контролируется. Контроль заключается в ответе на следующие вопросв:

1) все ли состояния определены и имеют уникальное имя;

2) все ли состояния достижимы;

3) все ли состояния имеют вход;

4) для каждого состояния проверяется реакция на все возможные условия (особенно неноррмальные);

5) все ли входные и выходные потоки управляющего процесса отражены в условиях и действиях на STD.

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

В качестве примера таблицы переходов состояний приведена таблица 2.1, соответству­ющая рассмотренной диаграмме переходов состояний (рис. 2.2). Первая колонка таблицы содержит список всех состояний проектируемой системы, во второй колонке для каждого состояния приведены все условия, вызывающие пе — реходы в другие состояния, а в третьей колонке — совер­шаемые при этих переходах действия. Четвертая колонка содержит соответствующие имена состояний, в которые осуществляется переходизрассматриваемого состояния при выполнении определенного условия.

Текущее Условие Действие Следующее состояние состояние

Проектирование информационных систем: Учебный курс

Год публикации: 2009

Для того, чтобы оценить ресурс, необходимо авторизоваться.

В представленном курсе изучаются принципы проектирования и разработки информационных систем (баз данных) с использованием Microsoft SQL Server 2005 и Microsoft Visual Studio 2005 (Visual Basic 2005). Рассматриваются основные понятия и виды информационных систем, их основные составляющие. Более того в рамках данного курса представлен комплексный подход к интеграции приложений разработанных в Microsoft Visual Studio 2005 в базы данных Microsoft SQL Server 2005. Данные материалы входят в состав «Библиотеки учебных курсов», формирование которой ведется в рамках программы академического сотрудничества MSDN Academic Alliance (MSDN AA).

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

Торговый код: 661451

Проектирование информационных систем: Учебник / В.В. Белов, В.И. Чистякова. — М.: КУРС, 2020 — 400 с.

Описание

Учебник создан в соответствии с Федеральным государственным образовательным стандартом высшего образования по направлению подготовки 09.03.03 Прикладная информатика (квалификация «Бакалавр»).
Содержит изложение методов и средств организации проектных работ, начиная с обследования предметной области и формулировки требований к создаваемой системе. Рассмотрены средства автоматизации проектирования, поддерживающие функционально-ориентированную, объектно-ориентированную и процессно-ориентированную методологии. Приведены примеры применения методологий IDEF, UML, BPMN. Рассмотрены вопросы оценки затрат проекта и методы управления портфолио IT-проектов.
Для студентов учреждений высшего образования.

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

Социально-экономическое значение проблемы надежности информационных систем в современном обществе. Методы получения оценок надежности технических систем. Модель надежности невосстанавливаемого и восстанавливаемого элемента. Методы резервирования в ИС.

Подобные документы

Основные понятия теории информационных систем (ИС) в экономике. Классификация ИС по признаку структурированности задач. Основные функции и структура информационных экономических систем. Методы и этапы проектирования ИС, понятие жизненного цикла.

курсовая работа, добавлен 09.06.2020

Рассмотрение процессов разработки отдельных проектных решений, анализа, апробации и внедрения. Влияние компьютеризации информационных потоков на эффективность управления. Цели реинжиниринга бизнес-процессов. Методы проектирования информационных систем.

реферат, добавлен 20.04.2020

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

контрольная работа, добавлен 19.12.2020

Классификация информационных систем по масштабу и архитектуре. Функции информационных систем для различных уровней специалистов. Этапы проектирования автоматизированных информационных систем. Создание программного обеспечения информационной системы.

реферат, добавлен 20.10.2008

Различия информационных систем по функциям, архитектуре и реализации. Области применения и реализации информационных систем. Изучение требований, предъявляемых к информационным системам. Рассмотрение основных фаз проектирования информационных систем.

контрольная работа, добавлен 23.12.2015

Основные компоненты технологии проектирования информационных систем. Структуризация и параметризация экономических информационных систем. Процесс формирования структуры технологического процесса проектирования экономических информационных систем.

реферат, добавлен 10.04.2015

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

статья, добавлен 29.06.2020

Характеристика организационной структуры предметной области. Анализ аналогичных информационных систем. Описание информационных функций и требований к функционированию информационных систем. Логическое и физическое проектирование информационных систем.

курсовая работа, добавлен 13.04.2020

Основные понятия, проблемы, области применения и реализации информационных систем и информационных ресурсов организации. Общие свойства для различных информационных систем, их классификация. Взаимосвязь информационных систем и информационных технологий.

контрольная работа, добавлен 03.07.2013

Структурная методология, предоставляющая в распоряжение разработчиков формализованные методы описания информационных систем и принимаемых технических решений. Структурный подход к автоматизированному проектированию информационных систем CASE средствами.

Кандидат технических наук, доцент Грекул Владимир Иванович Учебный курс Проектирование информационных систем Лекция 9. — презентация

Презентация была опубликована 9 лет назад пользователемMEL1971

Похожие презентации

Презентация на тему: » Кандидат технических наук, доцент Грекул Владимир Иванович Учебный курс Проектирование информационных систем Лекция 9.» — Транскрипт:

1 кандидат технических наук, доцент Грекул Владимир Иванович Учебный курс Проектирование информационных систем Лекция 9

2 2 Моделирование документов (бизнес-объектов)

3 3 Цель моделирования документов – описать атрибуты документов, их типы, значения, правила формирования для: 1.Проектирования пользовательского интерфейса системы; 2.Проектирования Базы данных системы; 3.Формирования альбома выходных форм системы;

4 4 Моделирование сценария исполнения функции («Регистрация в картотеке») Цель — проектирование сценариев работы пользователя с будущей системой и описание функций системы.

5 5 Моделирование состояний бизнес — объектов Цель – проектирование пользовательского интерфейса и БД системы.

6 6 Разработка требований к системе Преобразование бизнес-модели в модель системных прецедентов Элементы бизнес-моделиЭлементы модели системных прецедентов Бизнес-прецедентыПодсистемы Внешние исполнителиИсполнители Внутренние исполнителиИсполнители или прецеденты Процессы, выполняемые внутренними исполнителями Прецеденты

7 7 Бизнес-прецеденты отображаются в подсистемы Подсистема складского учета

8 8 Процессы, выполняемые внутренними исполнителями отображаются в системные функции Формирование приемного акта Внутрисетевой обмен Ведение картотеки

9 9 Проектирование ИС с применением UML

10 10 Rational Unified Process Rational Unified Process это процесс разработки решения, который обеспечивает упорядоченный подход к распределению задач и обязанностей в организации- разработчике. Rational Unified Process это продукт процесса, разработанный корпорацией Rational Software (база знаний). Rational Unified Process это контур процесса, который можно адаптировать для удовлетворения требований принявшей его организации.

11 11 Концепции RUP

12 12 Архитектура RUP

13 13 Этапы работ в соответствии с RUP 1. Бизнес-моделирование Выделение бизнес-процессов – диаграммы прецедентов (определяет цели системы и разбиение на подсистемы) Описание бизнес-процессов – диаграммы деятельности (определяет модули подсистем и их функции) Описание бизнес-сущностей – диаграммы классов (определяет входные-выходные формы,пользовательский интерфейс, базу данных) Описание состояний бизнес-сущностей – диаграммы состояний (определяет скрытые атрибуты бизнес-сущностей) Роли и виды деятельности – диаграммы классов и прецедентов (определяет функции системы) Структура предприятия — диаграммы классов и прецедентов (определяет функции системы) Бизнес-правила – диаграммы классов и деятельности (определяет правила системы)

14 14 2. Определение требований Функции системы – диаграммы прецедентов Экранные формы – диаграммы классов Сценарии работы пользователя с системой – диаграммы деятельности 3. Анализ и проектирование Модель размещения – диаграммы развертывания Модель данных – диаграммы классов Модель анализа – диаграммы классов Модель проекта – диаграммы классов, деятельности, последовательности, взаимодействия 4. Реализация Модель реализации – диаграммы компонентов 5. Тестирование Модель тестирования – диаграммы классов, деятельности 6. Размещение Модель размещения – диаграммы развертывания

15 15 Взаимосвязи моделей

16 16 Модель Rational Unified Process описывает кто выполняет, что выполняет, как и когда Этапы деятельности: размышления, исполнения, рецензирования.

17 17 Артефакты проекта вещественные продукты проекта: объекты, порождаемые или используемые проектом при работе над окончательным продуктом

18 18 Схема процессов бизнес- моделирования

19 19 Бизнес-прецеденты Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде. Модель бизнес-прецедентов описывает бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на деятельность организации извне.

20 20 Свойства бизнес-прецедентов прецедент должен описывать ЧТО нужно делать, а не КАК; прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ; прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ; последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИМУЮ цепочку.

21 21 Разработка модели бизнес-прецедентов Общая диаграмма деятельности медицинского центра по обслуживанию пациента Внешний исполнительВнутренний исполнитель

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

23 23 Разработка описаний прецедентов Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента. Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами. Представляется в виде диаграмм последовательности (sequence diagrams) или кооперативных диаграмм (collaboration diagrams). Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

24 24 Диаграмма видов деятельности для прецедента «Оказание медицинской помощи» Штатный специалист Вх\Вых информация Деятельность Роль Подразделение Должность Бизнес-правило

25 25 Разработка модели бизнес- объектов Модель бизнес-объектов отражает выполнение бизнес-процессов организации ее внутренними исполнителями. Основными компонентами моделей бизнес- объектов являются внешние и внутренние исполнители (бизнес-субъекты), а также бизнес-сущности, отображающие все, что используют внутренние исполнители для реализации бизнес-процессов

26 26 Выявление бизнес-субъектов Врач (суперкласс) Специалист- совместитель Штатный специалист Центр привлекает к своей деятельности как штатных специалистов, так и экспертов-специалистов из внешних организаций Отношение обобщения Появление суперкласса «ВРАЧ»

27 27 Иерархия классов бизнес-субъектов Обобщение классов Врач Специалист- совместитель Штатный специалист

28 28 Модификация модели бизнес- прецедентов Модель бизнес-прецедентов, составляющих обслуживание пациента

29 29 Разработка модели бизнес- объектов

30 30 Выявление скрытых атрибутов бизнес- сущностей

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

Введение

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

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

Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

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

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

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

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

Считается, что сложную систему невозможно описать в принципе. Это, в частности, касается систем управления предприятием. Одним из основных аргументов является изменение условий функционирования системы, например директивное изменение тех или иных потоков информации новым руководством. Еще один аргумент — объемы технического задания, которые для крупного проекта могут составлять сотни страниц, в то время как технический проект может содержать ошибки. Возникает вопрос: а может, лучше вообще не проводить обследования и не делать никакого технического проекта, а писать систему «с чистого листа» в надежде на то, что произойдет некое чудесное совпадение желания заказчика с тем, что написали программисты, а также на то, что все это будет стабильно работать?

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

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

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

Ниже мы рассмотрим некоторые схемы разработки проекта.

«Водопад» — схема разработки проекта

Очень часто проектирование описывают как отдельный этап разработки проекта между анализом и разработкой. Однако в действительности четкого деления этапов разработки проекта нет — проектирование, как правило, не имеет явно выраженного начала и окончания и часто продолжается на этапах тестирования и реализации. Говоря об этапе тестирования, также следует отметить, что и этап анализа, и этап проектирования содержат элементы работы тестеров, например для получения экспериментального обоснования выбора того или иного решения, а также для оценки критериев качества получаемой системы. На этапе эксплуатации уместен разговор и о сопровождении системы.

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

Стратегия

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

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

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

Результатом этапа определения стратегии является документ, где четко сформулировано, что получит заказчик, если согласится финансировать проект; когда он получит готовый продукт (график выполнения работ); сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе должны быть отражены не только затраты, но и выгода, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).

В документе обязательно должны быть описаны:

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

Выполненная на данном этапе работа позволяет ответить на вопрос, стоит ли продолжать данный проект и какие требования заказчика могут быть удовлетворены при тех или иных условиях. Может оказаться, что проект продолжать не имеет смысла, например из-за того, что те или иные требования не могут быть удовлетворены по каким-то объективным причинам. Если принимается решение о продолжении проекта, то для проведения следующего этапа анализа уже имеются представление об объеме проекта и смета затрат.

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации — MoSCoW — предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Эта аббревиатура расшифровывается так: Must have — необходимые функции; Should have — желательные функции; Could have — возможные функции; Won’t have — отсутствующие функции.

Функции первой категории обеспечивают критичные для успешной работы системы возможности.

Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатываем то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий.

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

Анализ

Этап анализа предполагает подробное исследование бизнес-процессов (функций, определенных на этапе выбора стратегии) и информации, необходимой для их выполнения (сущностей, их атрибутов и связей (отношений)). На этом этапе создается информационная модель, а на следующем за ним этапе проектирования — модель данных.

Вся информация о системе, собранная на этапе определения стратегии, формализуется и уточняется на этапе анализа. Особое внимание следует уделить полноте переданной информации, анализу информации на предмет отсутствия противоречий, а также поиску неиспользуемой вообще или дублирующейся информации. Как правило, заказчик не сразу формирует требования к системе в целом, а формулирует требования к отдельным ее компонентам. Уделите внимание согласованности этих компонентов.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

  • функции — информация о событиях и процессах, которые происходят в бизнесе;
  • сущности — информация о вещах, имеющих значение для организации и о которых что-то известно.

Двумя классическими результатами анализа являются:

  • иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);
  • модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

Эти результаты являются необходимыми, но не достаточными. К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей. Довольно часто ошибки анализа возникают при попытке показать жизненный цикл сущности на диаграмме ER.

Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа:

  • диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
  • диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
  • диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

ER-диаграммы

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

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом1, являются ключевыми (так Title Identity — ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа (рис. 3) означает «один», «птичья лапка» слева — «многие», а отношение читается вдоль линии, например «один ко многим». Вертикальная черта означает «обязательно», кружок — «не обязательно», например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Приведем также пример (рис. 4) изображения рефлексивного отношения «сотрудник», где один сотрудник может руководить несколькими подчиненными и так далее вниз по иерархии должностей.

Следует обратить внимание на то, что такое отношение всегда является необязательным, в противном случае это будет бесконечная иерархия.

Атрибуты сущностей могут быть ключевыми — они выделяются полужирным шрифтом; обязательными — перед ними ставится знак «*», то есть их значение всегда известно, необязательными (optional) — перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными.

Если сущность имеет набор взаимоисключающих отношений с другими сущностями, то говорят, что такие отношения находятся в дуге. Например, банковский счет может быть оформлен или для юридического лица, или для физического лица. Фрагмент ER-диаграммы для такого типа отношений приведен на рис. 5.

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности — сущность делится на типы по категориям: «для физического лица» и «для юридического лица». Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 6.

Нормализация

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

Допустимые типы связей. При ближайшем рассмотрении связи типа «один к одному» (рис. 7) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Связи «многие к одному» представлены на рис. 8.

I — достаточно сильная конструкция, предполагающая, что вхождение сущности B не может быть создано без одновременного создания по меньшей мере одного связанного с ним вхождения сущности A.

II — это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

III — применяется редко. Как A, так и B могут существовать без связи между ними.

Связи «многие ко многим» представлены на рис. 9.

I — такая конструкция часто имеет место в начале этапа анализа и означает связь — либо понятую не до конца и требующую дополнительного разрешения, либо отражающую простое коллективное отношение — двунаправленный список.

II — применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10).

I — редко, но имеет место. Отражает связи альтернативного типа.

II — достаточно часто применяется для описания иерархий с любым числом уровней.

III — имеет место на ранних этапах. Часто отражает структуру «перечня материалов» (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь «многие ко многим» (рис. 11) и ряд рекурсивных связей (рис. 12).

Обязательная связь «многие ко многим» в принципе невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной.

Диаграммы потоков данных

Логическая DFD (рис. 13) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм.

В частности, в DFD не показываются процессы, которые управляют собственно потоком данных и не приводятся различия между допустимыми и недопустимыми путями. DFD содержат множество полезной информации, а кроме того:

  • позволяют представить систему с точки зрения данных;
  • иллюстрируют внешние механизмы подачи данных, которые потребуют наличия специальных интерфейсов;
  • позволяют представить как автоматизированные, так и ручные процессы системы;
  • выполняют ориентированное на данные секционирование всей системы.

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

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

Хранилище данных (data storage) позволяет на ряде участков определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информацию, которую оно содержит, можно использовать в любое время после ее определения, при этом данные могут выбираться в произвольном порядке. Имя хранилища должно идентифицировать его содержимое. В случае когда поток данных входит (выходит) в (из) хранилище и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например «Клиент». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

Диаграммы изменения состояний STD

Жизненный цикл сущности относится к классу STD-диаграмм (рис. 14). Эта диаграмма отражает изменение состояния объекта с течением времени. Например, рассмотрим состояние товара на складе: товар может быть заказан у поставщика, поступить на склад, храниться на складе, проходить контроль качества, может быть продан, забракован, возвращен поставщику. Стрелки на диаграмме показывают допустимые изменения состояний.

Существует несколько различных вариантов изображения подобных диаграмм, на рисунке приведен лишь один из них.

Некоторые принципы проверки качества и полноты информационной модели
(источник — Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

Если вы хотите создать качественную модель, то придется прибегать к помощи аналитиков, хорошо владеющих CASE-технологией. Однако это не означает, что построением и контролем информационной модели должны заниматься только аналитики. Помощь коллег также может оказаться весьма полезной. Привлекайте их к проверке поставленной цели и к детальному изучению построенной модели как с точки зрения логики, так и с точки зрения учета аспектов предметной области. Большинство людей легче находят недостатки в чужой работе.

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

Качество сущностей

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

Список проверочных вопросов для сущности:

  • Отражает ли имя сущности суть данного объекта?
  • Нет ли пересечения с другими сущностями?
  • Имеются ли хотя бы два атрибута?
  • Всего атрибутов не более восьми?
  • Есть ли синонимы/омонимы данной сущности?
  • Сущность определена полностью?
  • Есть ли уникальный идентификатор?
  • Имеется ли хотя бы одна связь?
  • Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
  • Ведется ли история изменений?
  • Имеет ли место соответствие принципам нормализации данных?
  • Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
  • Не имеет ли сущность слишком общий смысл?
  • Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

  • Отсутствуют ли пересечения с другими подтипами?
  • Имеет ли подтип какие-нибудь атрибуты и/или связи?
  • Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?
  • Имеется ли исчерпывающий набор подтипов?
  • Не является ли подтип примером вхождения сущности?
  • Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

Качество атрибутов

Следует выяснить, а действительно ли это атрибуты, то есть описывают ли они тем или иным образом данную сущность.

Список проверочных вопросов для атрибута:

  • Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
  • Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
  • Имеет ли атрибут только одно значение в каждый момент времени?
  • Отсутствуют ли повторяющиеся значения (или группы)?
  • Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
  • Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
  • Не может ли он быть пропущенной связью?
  • Нет ли где-нибудь ссылки на атрибут как на «особенность проекта», которая при переходе на прикладной уровень должна исчезнуть?
  • Есть ли необходимость в истории изменений?
  • Зависит ли его значение только от данной сущности?
  • Если значение атрибута является обязательным, всегда ли оно известно?
  • Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
  • Зависит ли его значение только от какой-то части уникального идентификатора?
  • Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество связи

Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями.

Список проверочных вопросов для связи:

  • Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?
  • Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

  • Заданы ли степень связи и обязательность для каждой стороны?
  • Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

  • Не является ли она избыточной?
  • Не изменяется ли она с течением времени?
  • Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

  • Все ли концы связей, покрываемые исключающей дугой, имеют один и тот же тип обязательности?
  • Все ли из них относятся к одной и той же сущности?
  • Обычно дуги пересекают разветвляющиеся концы — что вы можете сказать о данном случае?
  • Связь может покрываться только одной дугой. Так ли это?
  • Все ли концы связей, покрываемые дугой, входят в уникальный идентификатор?

Функции системы

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

Очевидно, что операция выбора и расчета скидок может быть также разбита на более мелкие операции, например на расчет скидок за приверженность (клиент покупает товары в течение долгого времени) и на расчет скидок за количество покупаемого товара. Атомарные функции описываются подробно, например с помощью DFD и STD. Очевидно, что такое описание функций не исключает и дополнительное словесное описание (например, комментарии).

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

Уточнение стратегии

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

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

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

Уточняются также ограничения, риски, критические факторы. Если какие-либо требования не могут быть удовлетворены в информационной системе, реализованной с использованием СУБД и программных средств, выбранных на этапе определения стратегии, то это также инициирует уточнение и изменение получаемых данных (в конечном итоге сметы затрат и планов работ, а возможно, и изменение требований заказчика к системе, например их ослабление). Более подробно описываются те возможности, которые не будут реализованы в системе.

Мастер Йода рекомендует:  Искусственный интеллект от Baidu теперь обучается новому так же, как мы это делали в детстве
Добавить комментарий