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

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

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

На предприятии работают квалифицированные специалисты с многолетним опытом работы. Директор руководит всей работой предприятия.

Адрес предприятия:

Пермский край, г. Кунгур, ул. Ленина 66

Режим работы:

ПН-ПТ: 10 - 19 без обеда

ВС: выходной.

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

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

Формирование базовых документов по управлению проектом информационной системы

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

Управление проектом (Project Management) - использование знаний, навыков, методов, средств и технологий при выполнении проекта с целью достижения или превышения ожиданий участников проекта.

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

Устав проекта

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

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

Присутствует устав проекта.

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

Устав проекта должен содержать следующую информацию:

Требования к проекту и продукту проекта, в достаточно общем виде;

Цель проекта;

Информация о назначенном менеджере проекта и уровне его полномочий;

Расписание контрольных событий;

Отношения между участниками проекта;

Функциональные организации и их участие;

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

Ограничения относительно организации и окружения, а также внешние ограничения;

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

Бюджет проекта.

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

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

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

План управления проектом

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

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

1 Вспомогательные планы управления проектом, в число которых входят:

План управления содержанием проекта;

План управления расписанием проекта;

План управления стоимостью проекта;

План управления качеством проекта;

План управления обеспечением персоналом;

План управления коммуникациями проекта;

План управления рисками проекта;

План управления конфигурацией.

2 Базовая линия проекта, состоящая из:

Базового расписания проекта;

Базового плана по стоимости;

Базового плана по качеству;

Базового плана по конфигурации;

Реестра рисков.

3 Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта.

Для проекта информационной системы «Учёт оказываемых услуг» создан план управления проектом. (Приложение Б)

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование управления рисками - выбор подходов и планирование деятельности по управлению рисками проекта.

1 Идентификация рисков - определение рисков, способных повлиять на проект, и документирование их характеристик.

2 Качественная оценка рисков - качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

3 Количественная оценка - количественный анализ вероятности возникновения и влияния последствий рисков на проект.

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

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

План управления рисками представлен. (Приложение В)

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

Разработка базовой документации по управлению проектом информационной системы «Учёт оказываемых услуг» позволила описать часть документов для качественной и благополучной реализации управления проекта в MS Project. Залогом успеха является понимание необходимости данных документов в процессе управления проектами. Результатом данной работы стали, разработанные устав проекта и план управления проектом, которые будут использованы в дальнейшей работе.

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

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

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

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

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

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

В начало

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В начало

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При такой постановке задачи нужно решить две проблемы 1 сформировать структуру целей основных направлений развития системы, определяющих ее деятельность в соответствующий период сyщecтвoвaния 2 выбрать подход к оценке степени влияния информации на достижение целей. Для обеспечения полноты анализа деятельности предприятия организации при формировании структуры целей следует применять методики структуризации целей и функций, выбор которых определяется предварительно разработанной концепцией его развития. Для оценки степени целесоответствия можно использовать вероятностную меру, т. е. оценивать вероятность того, что данный информационный ресурс будет использован при достижении подцели. Такие оценки можно получать, как оценки относительной важности, относительного вклада информационного ресурса в реализацию соответствующей подцели, однако при этом возникает проблема, связанная с тем, что одна и та же информация может влиять не на одну подцель. Можно использовать информационную меру степени влияния ресурса на реализацию подцелей, которая позволяет учесть не только вероятность достижения подцели p, но и вероятность q того, что данная информация будет использована лицом, принимающим решение, при реализации подцели. Оценка информационного потенциала H удобнее оценок относительной важности их можно суммировать можно учесть не только p но и q понятие информационного потенциала лучше воспринимается управленческими работниками. В реальных условиях могут быть использованы более сложные способы.

Введение

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

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

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

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

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