26.5.6. Тотальный контроль До сих пор мы рассматривали только системные вызовы для работы с сообщениями очереди, сейчас рассмотрим системный вызов msgctl(), предназначенный для контроля самой очереди.int msgctl(int msgqid, int cmd, struct msqid_ds *buf);Первый аргумент - это ID очереди, второй -

26.6.3. Контроль семафора Для контроля семафора используется системный вызов semctl():int semctl(int semid, int semnum, int cmd, union semun arg);Первый аргумент - это идентификатор семафора, второй - номер семафора во множестве семафоров (нумерация начиняется с 0). В отличие от очереди сообщений, где

Организация ролика Процесс организации ролика более важен для программиста на Action Script, чем для Flash-аниматоров. Символам в библиотеке должны быть присвоены содержательные имена. При необходимости их надо систематизировать по каталогам. Слои на главной временной шкале

Подготовка ролика к публикации Независимо от того, является ли ваш ролик простой анимацией или сложным приложением, после окончания работы над ним его необходимо экспортировать в swf-файл. Это можно сделать при помощи команды File ? Publish (Файл? Опубликовать).Перед этим,

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

Жизненный цикл информационных систем

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

Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта приня­то разделять на фазы (стадии, этапы}.

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

Можно выделить следующие фазы развития информационной системы:

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

Формирование идеи, постановку целей;

Формирование ключевой команды проекта;

Изучение мотивации и требований заказчика и других участников;

Сбор исходных данных и анализ существующего состояния;

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

Сравнительную оценку альтернатив;

Представление предложений, их экспертизу и утверждение;

2. разработка технического задания. Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы:

Разработка основного содержания проекта, базовой структуры проекта;

Разработка и утверждение технического задания;

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

Составление сметы и бюджета проекта, определение потребности в ресурсах;

Разработка календарных планов и укрупненных графиков работ;

Подписание контракта с заказчиком;

Ввод в действие средств коммуникации участников проекта и контроля за хо­дом работ;

3. проектирование. На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характер­ные работы этой фазы:

Выполнение базовых проектных работ;

Разработка частных технических заданий;

Выполнение концептуального проектирования;

Составление технических спецификаций и инструкций;

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

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

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

· меню действий – это горизонтальный список объектов на экране, представляющих группу действий, доступных пользователю для выбора;

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

· схема программы отображает последовательность операций в программе;

· схема взаимодействия программ показывает путь активации программ и взаимодействий с соответствующими данными;

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

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

Выполнение работ по разработке программного обеспечения;

Выполнение подготовки к внедрению системы;

Контроль и регулирование основных показателей проекта.

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

Комплексные испытания;

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

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

Сопровождение, поддержка, сервисное обслуживание;

Оценка результатов проекта и подготовка итоговых документов;

Разрешение конфликтных ситуаций и закрытие работ по проекту;

Накопление опытных данных для последующих проектов, анализ опыта, состо­яния, определение направлений развития.

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

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

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

Ошибки в определении интересов заказчика;

Концентрация на маловажных, сторонних интересах;

Неправильная интерпретация исходной постановки задачи;

Неправильное или недостаточное понимание деталей;

Неполнота функциональных спецификаций (системных требований);

Ошибки в определении требуемых ресурсов и сроков;

Редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

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

I. Исследование предметной области.

II. Разработка архитектуры системы.

III. Реализация проекта.

IV. Внедрение системы.V. Сопровождение системы.

I. Исследование предметной области предусматривает следующие

1. Спецификацию деятельности в предметной области.

2. Анализ деятельности в предметной области.

2.1. Структурно-логический анализ деятельности.

2.1.1. Анализ путей.

2.1.2. Анализ связности (прочности и сцепления) компонентов

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

2.2. Анализ производительности.

2.3. Экономический анализ.

II. Разработка архитектуры системы включает в себя разработку

следующих компонентов:

1. Спецификации требований к проектируемой системе.

2. Конструирование концептуальной модели предметной области.

3. Спецификации обработки данных в проектируемой системе.

4. Спецификации пользовательского интерфейса системы.

5. Спецификации деятельности в предметной области с учетом

внедрения системы.

Процесс проектирования ИС базируется на моделях представления

проектных решений (рис. 1.18).Рис. 1.18. Модели представления проектных решений

Модель классификации ориентирована на группирование объектов

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

и важность тех или иных свойств этих объектов.

Модель декомпозиции ориентирована на описание систем, способных

выполнять действия над данными. Различают виды декомпозиции действий

на основе:

Состава выходных данных;

Входных данных;

Представлений о промежуточных результатах;

Представлений о фазах обработки;

Представлений об альтернативных действиях.

Модели потоков отражают движение различных видов носителей

(материальных, финансовых, информационных и др.).

Модель данных предметной области ориентирована на описание

структуры информационных объектов, их функциональных взаимосвязей,

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

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

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

характеристик модели классов можно выделить отношения наследования,

включения или использования. В основе лежит объектно-ориентированный

подход, основой которого является представление о предметной области как

совокупности взаимодействующих друг с другом объектов, рассматриваемых

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

наследования. Объектно-ориентированный подход содержится в

современных языках высокого уровня Smalltalk, Object Pascal, C++, Java.

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

взаимодействий пользователей с проектируемой системой, состава форм

представления и команд управления заданиями.

Модели логики ориентированы на описание потока управления

(последовательности выполнения) операторов программной системы и

действий пользователей.

Для отображения результатов проектирования на различных этапах

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

1. Схемы первичной классификации.

2. Схемы вторичной классификации.

3. Схемы детализации.

4. Схемы спецификации функциональных возможностей.

5. Схемы локальных моделей данных.

6. Схемы потоков.

7. Диаграммы переходов.

8. Схемы спецификации пользовательского интерфейса.9. Схемы распределенной обработки данных.

10. Структурированные карты объектов.

Схема классификации описывает многомерную одноуровневую

классификацию одного элемента. Каждый признак (основание)

классификации имеет глобальный идентификатор и имя:

саt.<ид. признака классификации>–<имя признака классификации>.

Дуги на схеме классификации помечаются соответствующими

элементами типа cat.

По способу формирования будем различать первичные и вторичные

варианты оснований классификации.

Первичные основания характеризуют, как правило, наличие различных

существенных отличительных свойств у каждого подкласса

рассматриваемого класса элементов.

Вторичные основания классификации элемента формируются в

соответствии с основаниями классификации элементов, которые сильно

связаны с данным элементом.

Схемы потоков являются средством более детальной спецификации

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

потоков будем различать схемы:

Материальных потоков;

Финансовых потоков;

Информационных потоков;

Потоков событий;

Отражающие сразу несколько типов потоков.

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

Вся схема строится для одного исходного функционального или

организационного элемента;

Каждый функциональный и организационный элементы

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

Каждый поток должен иметь тип, уникальный идентификатор и,

возможно, спецификацию;

Каждый поток, кроме потока событий, должен связывать

накопитель соответствующего вида и функциональный элемент, или такие

элементы должны быть специфицированы в организационных элементах,

связанных потоком;

Накопителями информационных потоков в зависимости от их

вида являются базы данных (информационные объекты) или папки

документов:

Накопителями финансовых потоков являются счета

бухгалтерского учета;

Накопителями материальных потоков являются места

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

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

идентификатором этого элемента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными работами, выполняемыми на стадиях и этапах проектирования, можно считать:

I стадия - предпроектное обследование:

1-й этап - сбор материалов для проектирования -формирование требований, изучение объекта проектирования, разработка и выбор варианта концепции системы;

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

II стадия - проектирование:

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

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

III стадия - ввод системы в действие:

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

2-й этап - проведение опытных испытаний всех компонентов системы перед передачей в промышленную эксплуатацию, обучение персонала;

3-й этап (завершающая стадия создания АИС и АИТ) - сдача в промышленную эксплуатацию; оформляется актами приема-сдачи работ.

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

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

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

Каскадная модель (70-85 г.г.);

Спиральная модель (86-90 г.г.).

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

Рисунок 1 - Каскадная схема разработки ПО.

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

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

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

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

Рисунок 2 - Реальный процесс разработки ПО по каскадной схеме

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

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

Рисунок 3 - Спиральная модель ЖЦ

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

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

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

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

4. Организационном - как описание документооборота и регламента деятельности аппарата управления.

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

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

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

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

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

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

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

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

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

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

Названные свойства АИТ обеспечиваются применением современных высокоразвитых аппаратно-программных комплексов, средств связи и формулируются в процессе проектирования разработчиками системы. Такие пользователи-разработчики относятся к классу профессионалов. Для них существует множество инструментальных средств, облегчающих создание АИТ. Например, можно назвать системы Oraclе, Visual C++, Gupta SQL, Windows, CA-Visual Objects, а также CASE-технологии, позволяющие конструировать сложные компьютерные системы из отдельных стандартизированных программных модулей.

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

Автоматизированные системы проектирования - быстроразвивающийся путь ведения проектировочных работ. В области автоматизации проектирования АИС и АИТ за последнее десятилетие сформировалось новое направление - CASE (Computer-Aided Software/System Engineering). Дальнейшее развитие работ в этом направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации вариантов, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые получили название CASE-систем или CASE-технологий.

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

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

Конец работы -

Эта тема принадлежит разделу:

Информационные технологии в юридической

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

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

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

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

Классификация информационных систем по степени автоматизации

Основные понятия технологии проектирования

Лекция № 1

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Лекции по предмету информационных систем (ИС)

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

· хранение

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

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

Информационная система состоит:

o источника информации,

o аппаратной части ИС,

o программной части ИС,

o потребителя информации.

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

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС:

1. Традиционные архитектурные решения основаны на использовании выделенных файл-серверов (File-server) или серверов баз данных (Client-server).

2. Корпоративные информационные системы , базируются на технологии Internet (Intranet-приложения).

3. "Хранилища данных" (DataWarehouse) - интегрированные информационные среды, включающие разнородные информационные ресурсы.

4. Архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода, которые используются для построения глобальных распределенных информационных приложений (Service Oriented architecture SOA).

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

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

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

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

Согласно статистическим данным , собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

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

• каскадная модель (характерна для периода 1970-1985 гг.);
• спиральная модель (характерна для периода после 1986.г.).

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

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

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

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

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

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

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

Методология проектирования ИС охватывает три основные области :

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

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

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

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

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

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

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

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

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

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

· технический проект ИС (техническое задание), эскизный проект, рабочая документация.

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

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

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

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

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

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

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