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

Реферат Тема: «СРВ в информационных системах. Проектирование информационных систем» СОДЕРЖАНИЕ: Введение 1. Информационная система 1. Этапы развития информационных систем 2. Классификация информационных систем по архитектуре 3. Классификация информационных систем по степени автоматизации4. Классификация информационных систем по характеру обработки данных 11 1.5.

Классификация информационных систем по сфере применения 6. Классификация информационных систем по охвату задач (масштабности) 2. Структура информационной системы 1. Типы обеспечивающих подсистем 2. Информационное обеспечение 3. Техническое обеспечение 4. Математическое и программное обеспечение 5. Организационное обеспечение 18 2.6.

Правовое обеспечение 3. Информационные системы реального времени 1. Многозадачность 2. Управление процессами 3. Проблемы создания 4. Использование ООП 4. Проектирование информационных систем 24 4.1. «Водопад» - схема разработки проекта 2. Стратегия 3. Анализ 29 4.4. ER – диаграмма 5. Дуги 31 4.6.

Нормализация 7. Диаграммы потоков данных 8. Диаграммы изменения состояний STD 9. Некоторые принципы проверки качества и полноты информационной системы 10. Качество сущностей 11. Качество атрибутов 12. Качество связи 13. Функции системы 14. Уточнение стратегии 5. Заключение: опыт использования информационных систем 43 6.

Библиографический список 44 ВВЕДЕНИЕ Мы постоянно слышим о том, что российские предприятия не могут конкурировать с западными производителями, что у нас не настолько развиты технологии, и что качество российской продукции слишком уступает зарубежным аналогам. Проблема в том, что российские управленцы стали сталкиваться, по крайней мере, с двумя проблемами в управлении: • выясняется, что показатели и процедуры, которые ранее использовались для анализа и планирования

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

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

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

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

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

смысле. В широком смысле информационная система есть совокупность технического, программного и организационного обеспечения, а также персонала, предназначенная для того, чтобы своевременно обеспечивать надлежащих людей надлежащей информацией[1]. Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите информации» даёт следующее определение: «информационная система — совокупность содержащейся в базах

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

рамках конкретной предметной области. Современные ИС де-факто немыслимы без использования баз данных и СУБД, поэтому термин «информационная система» на практике сливается по смыслу с термином «система баз данных». Этапы развития информационных систем История развития информационных систем и цели их использования на разных периодах представлены в таблица 1. Таблица 1.1 Изменение подхода к использованию информационных систем

Период времени Концепция использования информации Вид информационных систем Цель использования 1950 - 1960 гг. Бумажный поток расчетных документов Информационные системы обработки расчетных документов на электромеханических бухгалтерских машинах Повышение скорости обработки документов Упрощение процедуры обработки счетов и расчета зарплаты 1960 - 1970 гг. Основная помощь в подготовке отчетов Управленческие информационные системы для производственной

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

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

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

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

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

внимания. Основной «деятельностью» такой системы является учет материалов. Следующий этап усовершенствования материального учета был ознаменован системами планирования производственных или материальных (в зависимости от направления деятельности организации) ресурсов. Эти системы, вошедшие в стандарт, а вернее два стандарта (MRP – Material Requirements Planning и MRP II – Manufacturing

Requirements Planning), очень широко распространены на Западе и давно и успешно используются предприятиями, в первую очередь производственных отраслей. Основные принципы, которые легли в основу систем стандарта MRP, включают • описание производственной деятельности как потока взаимосвязанных заказов; • учет ограничения ресурсов при выполнении заказов; • минимизацию производственных циклов и запасов; • формирование заказов

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

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

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

показатели. Главная задача систем ERP состоит в отслеживании текущего состояния дел на предприятии и сигнализации руководителям обо всех опасных изменениях в производственной деятельности. Процессы, которыми управляет информационная система стандарта ERP, изображены на рис. 1.2: Классификация информационных систем по архитектуре По степени распределённости отличают: • настольные (desktop), или локальные

ИС, в которых все компоненты (БД, СУБД, клиентские приложения) работают на одном компьютере; • распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам. Распределённые ИС, в свою очередь, разделяют на • файл-серверные ИС (ИС с архитектурой «файл-сервер»); • клиент-серверные ИС (ИС с архитектурой «клиент-сервер»). В файл-серверных

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

Клиентские приложения обращаются к СУБД напрямую. В многозвенных (multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Классификация информационных систем по степени автоматизации

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

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

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

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

группы или подразделения. • Корпоративная информационная система в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности, безизбыточности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия. СТРУКТУРА ИНФОРМАЦИОННОЙ СИСТЕМЫ Типы обеспечивающих подсистем Структуру информационной системы составляет совокупность отдельных ее частей, называемых подсистемами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

с договорными отношениями разработчика и заказчика и правовым регулированием отклонений от договора. Правовое обеспечение этапов функционирования информационной системы включает: • статус информационной системы; • права, обязанности и ответственность персонала; • правовые положения отдельных видов процесса управления; • порядок создания и использования информации и др. ИНФОРМАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ Компьютерные системы реального времени находят применение

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

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

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

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

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

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

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

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

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

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

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

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

(соотноше¬ние работа/ожидание для определенного процессора), то пользователь может скорректировать распределение программных модулей между процессорами. Разработка таких систем непосредственно связана с новым направлением – параллельные вычисления с использованием объектно-ориентированного подхода и представляет большой интерес для развития ИИС реального времени. Использование ООП Использование языков высокого уровня в процессе создания систем реального времени позволяет облегчить

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

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

Рис. 3.1. Схема многозадачности, реализованная аппаратными средствами (соединение нескольких микропроцессоров) Рис. 3.2. Многозадачность, реализованная программными средствами ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить: • требуемую функциональность системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Один из возможных форматов представления такой классификации - MoSCoW - предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994. Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции;

Won't have - отсутствующие функции. Функции первой категории обеспечивают критичные для успешной работы системы возможности. Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатываем то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий. Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.

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

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

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

К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей. Довольно часто ошибки анализа возникают при попытке показать жизненный цикл сущности на диаграмме ER. Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа: • диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях; • диаграммы потоков данных

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

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

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

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

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

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

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

а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 4.6. Рис. 4.6. Подтипы (справа) и супертип (слева) Нормализация Чтобы не допустить аномалий при обработке данных, используют нормализацию.

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

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

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

4.9. Рис. 4.9. Связи "многие ко многим" I - такая конструкция часто имеет место в начале этапа анализа и означает связь - либо понятую не до конца и требующую дополнительного разрешения, либо отражающую простое коллективное отношение - двунаправленный список. II - применяется редко. Такие связи всегда подлежат дальнейшей детализации. Рассмотрим теперь рекурсивные связи (рис. 4.10). Рис.

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

КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ. Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь "многие ко многим" (рис. 4.11) и ряд рекурсивных связей (рис. 4.12). Рис. 4.11. Недопустимые связи "многие ко многим" Рис. 4.12. Недопустимые рекурсивные связи Обязательная связь "многие ко многим" в принципе

невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной. Диаграммы потоков данных Логическая DFD (рис. 4.13) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется

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

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

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

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

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

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

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

Существует несколько различных вариантов изображения подобных диаграмм, на рисунке приведен лишь один из них. Некоторые принципы проверки качества и полноты информационной модели (источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990) Если вы хотите создать качественную модель, то придется прибегать к помощи аналитиков, хорошо владеющих CASE-технологией. Однако это не означает, что построением и контролем информационной

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

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

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

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

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

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

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

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

Качество связи Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями. Список проверочных вопросов для связи: • Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис? • Участвуют ли в ней только две стороны? Не является ли связь переносимой? • Заданы ли степень связи и обязательность для каждой стороны? •

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

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

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

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

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

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

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

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

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

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

СУБД и программных средств, выбранных на этапе определения стратегии, то это также инициирует уточнение и изменение получаемых данных (в конечном итоге сметы затрат и планов работ, а возможно, и изменение требований заказчика к системе, например их ослабление). Более подробно описываются те возможности, которые не будут реализованы в системе. ОПЫТ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ Многие крупные компании

США и Европы уже несколько лет назад перешли на использование информационных систем стандарта ERP. Про страны Азии такого сказать пока нельзя. Большинство финансовых менеджеров азиатских компаний едва ли слышали о таких системах, не говоря уж об их внедрении. Хотя есть компании, которые решились перейти на ERP-системы. Разработчики информационных систем, в частности SAP,

Baan, Oracle, PeopleSoft и J.D.Edwards, довольно агрессивно рекламируют свои продукты, что создает впечатление у плохо осведомленных в данной области людей впечатление, что эти программы способны решить все проблемы их компаний. Статистика же показывает, что большая часть попыток внедрить информационную систему окончились неудачами, большими потерями, либо банкротством. Например, руководство компании FoxMeyer утверждает, что ошибочное внедрение

ERP-системы привело ее к банкротству. Компания обвиняет в этом создателей системы и консультантов. Такая же участь постигла и компании Dell Computer, Dow Chemical и Kellogg’s. Но существуют также примеры успешного использования ERP-систем. Так, например