Структуризация проекта информационной системы. Проектирование информационной системы

Методы проектирования информационной системы и функциональный анализ деятельности организации

ВВЕДЕНИЕ

Глава 1. Анализ структурных функциональных методов проектирования информационной системы

1 SADT-методология

2. IDEF0-методология

3. IDEF1Х-методология

4. DFD-методология

Глава 3. Практическая часть

ЗАКЛЮЧЕНИЕ

Список использованных источников

ВВЕДЕНИЕ

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

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

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

Глава 1. Анализ структурных функциональных методов проектирования информационной системы

1 SADT-методология

SADT-методология - методология <#"justify">SADT возникла в конце 60-х годов в ходе революции, вызванной структурным программированием. Когда большинство специалистов билось над созданием программного обеспечения, немногие старались разрешить более сложную задачу создания крупномасштабных систем, включающих как людей и машины, так и программное обеспечение, аналогичных системам, применяемым в телефонной связи, промышленности, управлении и контроле за вооружением.

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

1)анализ <#"justify">В основе методологии SADT лежат два основных принципа.

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

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

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

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

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

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

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

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

1.2 IDEF0-методология

IDEF0 - методология <#"justify">Методология IDEF0 может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.

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

Преимущества методологии IDEF0:

1)долгая история его использования для решения различных задач государственных и коммерческих предприятий;

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

)глобальная информатизация общества только усиливает спрос на возможности, которые обеспечиваются IDEF0;

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

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

)успешное моделирование различных аспектов деятельности предприятия позволяет формально выявить и собрать требования к проектируемой системе, а затем вести разработку системы, которая удовлетворяет этим требованиям;

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

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

)влияние внешней среды предприятия или системы может быть также объектом моделирования и исследования;

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

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

1.3 IDEF1X-методология

Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.

В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. Она разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).

В IDEF1X могут быть выражены следующие мощности связей:

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

) каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

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

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

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

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

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

1.4 DFD-методология

DFD - общепринятое сокращение от англ. <#"justify">Нотация DFD - удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.

Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.

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

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

2)определение и анализ данных, необходимых для выполнения каждой функции процесса;

)подготовка к созданию модели структуры данных организации, так называемой ERD-модели (IDEF1X);

)выделение основных и вспомогательных бизнес-процессов организации.

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

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

Глава 2. Функциональный анализ деятельности организации

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

Помимо самого процесса продаж, к деятельности дилера также относятся:

)работа с поставщиками;

)обеспечение безопасности интернет ресурсов;

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

Рассмотрим диаграмму А0, представленную на рисунке 1. Основной деятельностью является «продажа товара». Входные данные: информация о покупателях, информация о товаре. Управляющей информацией являются закон о правах потребителей и устав магазина, управляющим механизмом - обслуживающий персонал. Выходные данные представляются в виде сопроводительной документации.

Рис. 1. Диаграмма А0

Теперь проведем декомпозицию полученной диаграммы.

Деятельность «продажа товара» можно представить как последовательность следующих действий (рис. 2):

1)предподготовка;

2)оформление;

)получение;

)постсервис.

Рис. 2. Декомпозиция диаграммы А0

Проведем дальнейшую декомпозицию. Деятельность «предподготовка» включает следующие действия (рис. 3):

1)консультация;

2)выбор товара;

)проверка наличия на складе.

Рис. 3. Декомпозиция деятельности «предподготовка»

Проведем декомпозицию «оформление». Деятельность «оформление» включает следующие действия (рис. 4):

1)оплата;

2)заявка на склад;

)оформление документации.

Рис. 4. Декомпозиция деятельности «оформление»

В «получение» входят функции (рис 5):

1)передача товара;

2)оформление гарантии;

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

Рис. 5. Декомпозиция деятельности «получение»

В «постсервис» входят функции (рис. 6):

)проверка наличия неисправностей;

2)осуществление ремонта;

)проверка гарантии;

)выдача товара.

Рис. 6. Декомпозиция деятельности «постсервис».

После построения информационной модели сформируем древо целей (рис. 7):

Рис. 7. Древо целей информационной системы.

Глава 3. Практическая часть

Разработка логической и физической модели начинается с проведения процесса системного моделирования для предметной области с помощью инструментальной среды CA Erwin Process Modeler.

Процесс построения информационной модели состоит из следующих шагов:

1)определение сущностей;

2)определение атрибутов сущностей;

)задание первичных и альтернативных ключей;

)определение зависимостей между сущностями;

)приведение модели к требуемому уровню нормальной формы;

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

)генерация базы данных.

CA Erwin Process Modeler создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако CA Erwin Process Modeler далеко не только инструмент для рисования. CA Erwin Process Modeler автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

Основные компоненты диаграммы CA Erwin Process Modeler - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Построение модели данных предполагает определение сущностей и атрибутов.

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

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

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

В модели дилера продажи товара я выделил следующие сущности и атрибуты:

1)«Информация о товаре» с атрибутами: код товара, стоимость, наименование, характеристики, срок гарантии, комплектация, наличие на складе.

2)«Накладная» с атрибутами: номер накладной, код товара, дата, ФИО кассира, поставщик, количество товара.

)«Информация о покупателе» с атрибутами: код покупателя, ФИО покупателя, паспортные данные, адрес.

)«Гарантийный талон» с атрибутами: номер талона, код покупателя, наименование продавца, ФИО покупателя, производитель товара, срок гарантии.

)«Чек» с атрибутами: номер чека, код товара, количество товара, сумма, дата.

Рисунок 8 - Логическая модель ИС дилер по продаже товаров.

ЗАКЛЮЧЕНИЕ

В данном курсовом проекте была реализована система организации на примере дилера по продаже товара при использовании инструментальных средств CA Erwin Process Modeler, AllFusion Process Modeler. Разработанная система позволяет осуществлять полноценное функционирование как отдельно взятого дилера, так и целой сети. Разработка информационной системы была разделена на следующие этапы:

1)углубленное изучение предметной области,

)создание логической и физической модели информационной системы.

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.Балабанов И.Т. Современные моделирования./ И.Т. Балабанов - СПб: Питер, 2002. - 120 с.: ил. - (серия Основы).

2.Венчковский Л.Б. Разработка сложных программных изделий. - электронный вариант.

3.Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебное пособие. - М.: Финансы и статистика, 2002 электронный вариант

4.Журнал Opensys № 11, 2008 г. - «Управление организацией»

5.Пахчанян А. Обзор информационных систем // Директор информационной службы. - 2001.

6.CA Erwin Process Modeler [Электронный ресурс]:[справочный листок]. - ЕрВин, 2011. - Режим доступа:

7.CA Erwin Process Modeler [Электронный ресурс]:[справочный листок]. - Информационные Системы, 2011. - Режим доступа: http:// www.v8.1c.ru

8.ITru [Электронный ресурс]:[справочный листок]. - Моделировании ИС, 2011. - Режим доступа: http:// www.it.ru /

9.INTERFACE [Электронный ресурс]:[справочный листок]. - Моделирование бизнеса и архитектура информационной системы, 2011. - Режим доступа: http://www.interface.ru /

Optima WorkFlow [Электронный ресурс]:[справочный листок]. - ОПТИМА, 2011. - Режим доступа:

Введение

Заключение

Литература

Введение

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

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

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

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

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

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

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

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

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

· требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

· требуемую пропускную способность системы;

· требуемое время реакции системы на запрос;

· безотказную работу системы в требуемом режиме, иными словами - готовность и доступность системы для обработки запросов пользователей;

· простоту эксплуатации и поддержки системы;

· необходимую безопасность.

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

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

· проектирование объектов данных, которые будут реализованы в базе данных;

· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

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

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

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

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

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

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

Конечными продуктами этапа проектирования являются:

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

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

· будет ли это архитектура "файл-сервер" или "клиент-сервер";

· будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

· будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

· будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB).

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

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

· обнаружение отказов модуля (жестких сбоев);

· соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

курсовая работа , добавлен 10.07.2014

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

дипломная работа , добавлен 03.07.2015

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

курсовая работа , добавлен 04.01.2011

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

дипломная работа , добавлен 20.07.2014

Рассмотрение создания модели информационной системы с помощью AllFusion Process Modeler 4.1 (Bpwin4.1) в стандарте IDEF0. Описание диаграммы дерева узлов. Анализ создания модели данных склада. Характеристики информационной модели в нотации IDEF1X.

курсовая работа , добавлен 10.04.2015

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

дипломная работа , добавлен 17.07.2012

Виды, классификация и состав информационных систем. Понятия "производственный процесс" и "бизнес-процесс". Анализ структуры управления и состояния информатизации компании ООО "Грин Строй", разработка информационной системы на основе процессного подхода.

курсовая работа , добавлен 24.02.2014

Выработка практических навыков по разработке информационной системы предприятия на основе процессного подхода. Основные термины, применяемые при реализации процессного подхода. Структура управления компании ООО "Грин", состояние информатизации компании.

контрольная работа , добавлен 20.02.2012

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

Часть 1. Этапы разработки проекта: стратегия и анализ

Введение "Водопад" - схема разработки проекта Стратегия Анализ ER-диаграммы Дуги Нормализация Диаграммы потоков данных Некоторые принципы проверки качества и полноты информационной модели Качество сущностей Качество атрибутов Качество связи Функции системы Уточнение стратегии

Введение

требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

требуемую пропускную способность системы;

требуемое время реакции системы на запрос;

безотказную работу системы в требуемом режиме, иными словами - готовность и доступность системы для обработки запросов пользователей;

простоту эксплуатации и поддержки системы;

необходимую безопасность.

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

проектирование объектов данных, которые будут реализованы в базе данных;

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

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

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

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

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

Рис. 1. Cхема «водопада»

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

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

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

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

Ниже мы рассмотрим некоторые схемы разработки проекта.

В начало

"Водопад" - схема разработки проекта

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

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

В начало

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

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

описание выполняемых системой функций;

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

сущности, необходимые для выполнения функций системы;

интерфейсы и распределение функций между человеком и системой;

требования к программным и информационным компонентам ПО, требования к СУБД (если проект предполагается реализовывать для нескольких СУБД, то требования к каждой из них, или общие требования к абстрактной СУБД и список рекомендуемых для данного проекта СУБД, которые удовлетворяют заданным условиям);

что не будет реализовано в рамках проекта.

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

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - 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-диаграмма содержит информацию о сущностях системы и способах их взаимодействия, включает идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Во многих случаях информационная модель очень сложна и содержит множество объектов.

Рис. 2. Пример ER-диаграммы

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом, являются ключевыми (так Title Identity - ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа (рис. 3 ) означает "один", "птичья лапка", слева - "многие", а отношение читается вдоль линии, например "один ко многим". Вертикальная черта означает "обязательно", кружок - "не обязательно", например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Рис. 3. Элемент ER-диаграммы

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

Рис. 4. ER-диаграмма рефлексивного отношения

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

Атрибуты сущностей могут быть ключевыми - они выделяются полужирным шрифтом; обязательными - перед ними ставится знак "*", то есть их значение всегда известно, необязательными (optional) - перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными.

В начало

Дуги

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

Рис. 5. Дуга

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность делится на типы по категориям: "для физического лица" и "для юридического лица". Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 6 .

Рис. 6. Подтипы (справа) и супертип (слева)

В начало

Нормализация

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

Допустимые типы связей. При ближайшем рассмотрении связи типа "один к одному" (рис. 7 ) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Рис. 7. Связи «один к одному»

Связи "многие к одному" представлены на рис. 8 .

Рис. 8. Связи «многие к одному»

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

II - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

III - применяется редко. Как A, так и B могут существовать без связи между ними.

Связи "многие ко многим" представлены на рис. 9 .

Рис. 9. Связи «многие ко многим»

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

II - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10 ).

Рис. 10. Рекурсивные связи

I - редко, но имеет место. Отражает связи альтернативного типа.

II - достаточно часто применяется для описания иерархий с любым числом уровней.

III - имеет место на ранних этапах. Часто отражает структуру "перечня материалов" (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь "многие ко многим" (рис. 11 ) и ряд рекурсивных связей (рис. 12 ).

Рис. 11. Недопустимые связи «многие ко многим»

Рис. 12. Недопустимые рекурсивные связи

Обязательная связь "многие ко многим" в принципе невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной.

В начало

Диаграммы потоков данных

Логическая DFD (рис. 13 ) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм.

Рис. 13. Пример DFD

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

позволяют представить систему с точки зрения данных;

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

позволяют представить как автоматизированные, так и ручные процессы системы;

выполняют ориентированное на данные секционирование всей системы.

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

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

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

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например "Клиент". Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

В начало

Диаграммы изменения состояний STD

Жизненный цикл сущности относится к классу STD-диаграмм (рис. 14 ). Эта диаграмма отражает изменение состояния объекта с течением времени. Например, рассмотрим состояние товара на складе: товар может быть заказан у поставщика, поступить на склад, храниться на складе, проходить контроль качества, может быть продан, забракован, возвращен поставщику. Стрелки на диаграмме показывают допустимые изменения состояний.

Рис.14. Пример DFD

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

В начало

Некоторые принципы проверки качества и полноты информационной модели (источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

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

В начало

Качество сущностей

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

Список проверочных вопросов для сущности:

Отражает ли имя сущности суть данного объекта?

Нет ли пересечения с другими сущностями?

Имеются ли хотя бы два атрибута?

Всего атрибутов не более восьми?

Есть ли синонимы/омонимы данной сущности?

Сущность определена полностью?

Есть ли уникальный идентификатор?

Имеется ли хотя бы одна связь?

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

Ведется ли история изменений?

Имеет ли место соответствие принципам нормализации данных?

Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?

Не имеет ли сущность слишком общий смысл?

Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

Отсутствуют ли пересечения с другими подтипами?

Имеет ли подтип какие-нибудь атрибуты и/или связи?

Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?

Имеется ли исчерпывающий набор подтипов?

Не является ли подтип примером вхождения сущности?

Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

В начало

Качество атрибутов

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

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

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?

Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?

Имеет ли атрибут только одно значение в каждый момент времени?

Отсутствуют ли повторяющиеся значения (или группы)?

Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?

Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?

Не может ли он быть пропущенной связью?

Есть ли необходимость в истории изменений?

Зависит ли его значение только от данной сущности?

Если значение атрибута является обязательным, всегда ли оно известно?

Есть ли необходимость в создании домена для этого и ему подобных атрибутов?

Зависит ли его значение только от какой-то части уникального идентификатора?

Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Введение

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

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

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

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

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

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

Ниже мы рассмотрим некоторые схемы разработки проекта.

«Водопад» - схема разработки проекта

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

Стратегия

В документе обязательно должны быть описаны:

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

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won’t have - отсутствующие функции.

Анализ

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

Двумя классическими результатами анализа являются:

иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);
модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа:

диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

Нормализация

Допустимые типы связей. При ближайшем рассмотрении связи типа «один к одному» (рис. 7) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Связи «многие к одному» представлены на рис. 8 .

III - применяется редко. Как A, так и B могут существовать без связи между ними.

Связи «многие ко многим» представлены на рис. 9 .

II - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10).

I - редко, но имеет место. Отражает связи альтернативного типа.

II - достаточно часто применяется для описания иерархий с любым числом уровней.

III - имеет место на ранних этапах. Часто отражает структуру «перечня материалов» (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь «многие ко многим» (рис. 11) и ряд рекурсивных связей (рис. 12).

Обязательная связь «многие ко многим» в принципе невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной.

Диаграммы потоков данных

Логическая DFD (рис. 13) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ER-диаграмм.

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

Хранилище данных (data storage) позволяет на ряде участков определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информацию, которую оно содержит, можно использовать в любое время после ее определения, при этом данные могут выбираться в произвольном порядке. Имя хранилища должно идентифицировать его содержимое. В случае когда поток данных входит (выходит) в (из) хранилище и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например «Клиент». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

Некоторые принципы проверки качества и полноты информационной модели
(источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

Качество сущностей

Список проверочных вопросов для сущности:

Отражает ли имя сущности суть данного объекта?
Нет ли пересечения с другими сущностями?
Имеются ли хотя бы два атрибута?
Всего атрибутов не более восьми?
Есть ли синонимы/омонимы данной сущности?
Сущность определена полностью?
Есть ли уникальный идентификатор?
Имеется ли хотя бы одна связь?
Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
Ведется ли история изменений?
Имеет ли место соответствие принципам нормализации данных?
Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
Не имеет ли сущность слишком общий смысл?
Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

Отсутствуют ли пересечения с другими подтипами?
Имеет ли подтип какие-нибудь атрибуты и/или связи?
Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?
Имеется ли исчерпывающий набор подтипов?
Не является ли подтип примером вхождения сущности?
Знаете ли вы какие-нибудь атрибуты, связи и условия, отличающие данный подтип от других?

Качество атрибутов

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

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
Имеет ли атрибут только одно значение в каждый момент времени?
Отсутствуют ли повторяющиеся значения (или группы)?
Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?

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

Список проверочных вопросов для связи:

Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?
Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

Заданы ли степень связи и обязательность для каждой стороны?
Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

Не является ли она избыточной?
Не изменяется ли она с течением времени?
Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

данном примере

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

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

Уточнение стратегии

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

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

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

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

КомпьютерПресс 9"2001