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

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

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

Диаграмма (Diagram) – это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы (рис.4).

Объектно-ориентированный подход обладает следующими преимуществами:

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

Позволяет избежать создания сложных моделей;

Ориентирован на человеческое восприятие мира.

Рис.4

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

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

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

Функциональная методика IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении. На диаграмме функциональный блок изображается прямоугольником (рис. 5). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

Верхняя сторона имеет значение «Управление» (Control);

Левая сторона имеет значение «Вход» (Input);

Правая сторона имеет значение «Выход» (Output);

Нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. 5. Функциональный блок

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

Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Т.к. каждый процесс должен происходить по каким-то правилам и должен выдавать некоторый результат, иначе его рассмотрение не имеет никакого смысла. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

Рис.6

В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели (рис. 7).

Рис.7

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

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

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram – DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются одним из основных инструментов структурного анализа и проектирования информационных систем, моделирования функциональных требований к проектируемой системе.

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

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

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

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

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

Рис.8

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

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

1) имеет два-три входных и выходных потока;

2) может быть описан в виде преобразования входных данных в выходные;

3) может быть описан в виде последовательного алгоритма.

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

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

К преимуществам методики DFD относятся:

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

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

Функциональная методика ERD

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

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

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

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

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

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

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

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

1) 1*1 (один-к-одному). Используются, как правило, на верхних уровнях иерархии модели данных.

2) 1*n (один-к-многим). Являются наиболее часто используемыми.

3) n*m (многие-к-многим). Используются на ранних этапах проектирования с целью прояснения ситуации.

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

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

Использование этой информации различными приложениями.

Рис. 9

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

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

Тема 2. Методология проектирования ИС

Понятие методологии. 1

Методология разработки ИС.. 1

Выбор методологии создания ИС.. 5

Понятие методологии

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

Рис. 9. Структура методологии

Методология разработки ИС

В настоящее время существует ряд общих методологий разработки ИС.

На настоящий момент специалисты выделяют два подхода и более трех десятков методологий, ориентированных на создание систем комплексной автоматизации или проведения информационных проектов (Рис. 10). В числе наиболее известных методологий можно выделить: Rapid Application Development (RAD), DATARUN, Rational Unified Process (RUP), Oracle Custom Development Method (Oracle CDM) и другие. Такое количество методологий вызвано тем, что для создания различных классов систем используются разные методы их разработки, определяемые типом создаваемой системы и средствами реализации. Перечисленные методологии либо стандартизированы либо воспринимаются в профессиональном сообществе в качестве стандарта "де-факто".

Рис. 10. Подходы к проектированию ИС

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

Рис. 11. Требования к методологии разработки ИС

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

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

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

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

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

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

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

Рис. 12. Задачи методологии проектирования ИС

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

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

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

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

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

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

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

– требуемой пропускной способности системы;

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

– безотказной работы системы;

– необходимого уровня безопасности;

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

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

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

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

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

Выбор методологии создания ИС

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

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

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

2 шаг. Выбор модели жизненного цикла ИС. На этом этапе происходит проверка применимости одной из трех базовых моделей жизненного цикла для конкретного проекта. Целесообразно выполнять эту проверку по методике предложенной Software Engineering Institute (SEI). Выбор модели жизненного цикла и выполненный на предыдущем шаге выбор подхода приводит к сокращению возможных для данного проекта стандартов до единиц.

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

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

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

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

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

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

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

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

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

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

· формирование всех необходимых бухгалтерских проводок, уже агрегированных по балансовым счетам, и автоматическая их передача в базу данных "Автоматизированной бухгалтерии";

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· принцип непротиворечивости – заключается в обоснованности и согласованности элементов;

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

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

· DFD (Data Flow Diagrams) диаграммы потоков данных;

· ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

Методология функционального моделирования SADT. Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

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

– строгость и точность.

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

– ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

– связность диаграмм (номера блоков);

– уникальность меток и наименований (отсутствие повторяющихся имен);

– синтаксические правила для графики (блоков и дуг);

– разделение входов и управлений (правило определения роли данных).

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

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

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

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

– внешние сущности;

– системы/подсистемы;

– процессы;

– накопители данных;

– потоки данных.

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

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

Методология IDEF1. Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия – методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

18. Каноническое проектирование. Состав и содержание стадий и этапов

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

В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Процесс каскадного проектиро­вания в жизненном цикле ЭИС в соответствии с применяемым ГОСТ 34601-90 «Автоматизированные системы ста­дий создания» делится на следующие семь

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

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

Создание эскизного проекта;

Техническое проектирование;

Рабочее проектирование;

Ввод в действие;

Функционирование, сопровождение, модернизация.

В целях изучения взаимосвязанных приемов и методов кано­нического проектирования ЭИС перечисленные 7 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ЭИС (рис. 20).

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

На первой«Предпроектной стадии» принято выделять два основных этапа: сбор материалов обследования; анализ матери­алов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).

Рис. 20. ТСП стадий и этапов канонического проектирования ЭИС

Д1.1 – предметная область; Д1.2 –материалы обследования; Д1.3 –ТЭО, ТЗ на проектирование; Д1.4 – эскизный проект; Д2.1 – техно-рабочий проект (ТРП); Д3.1 – исправленный ТРП, переданный в эксплуатацию; Д3.2 – акт о приемке проекта в промышленную эксплуатацию; Д4.1 – модернизированный ТРП

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

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

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

Вторая стадия«Техно-рабочее проектирование» выпол­няется в два этапа: техническое проектирование и рабочее про­ектирование.

На этапе «Техническое проектирование» выполняются рабо­ты по логической разработке и выбору наилучших вариантов про­ектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реали­зацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Техно-рабочий проект» (ТРП) – Д2.1.

Третья стадия«Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное вне­дрение проекта и сдача его в эксплуатацию.

На этапе «Подготовка объекта к внедрению проекта» осуще­ствляется комплекс работ по подготовке предприятия к внедре­нию разработанного проекта ЭИС. На этапе «Опытное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную докумен­тацию и «Акт о проведении опытного внедрения». На этапе «Сда­ча проекта в промышленную эксплуатацию» осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» (ДЗ. 1) и «Акт приемки проекта в промышленную эксплуатацию» (Д3.2).

Четвертая стадия –«Эксплуатация и сопровождение проекта» включает этапы: эксплуатация проекта; сопровождение и модернизация проекта.

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

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

Важнейшими объектами обследования могут являться:

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

Функциональная структура, состав хозяйственных процессов и процедур;

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

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

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

Материальные потоки и процессы их обработки.

Основной целью выполнения первого этапа предпроект­ного обследования «Сбор материалов» является:

Выявление основных параметров предметной области (напри­мер, предприятия или его части);

Установление условий, в которых будет функционировать про­ект ЭИС;

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

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

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

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

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

CRP. Основные функции MRP-систем.

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

FUNCTION: ELECTRICAL, ELECTRONIC AND CONTROL ENGINEERING AT THE OPERATIONAL LEVEL Функція: Електрообладнання, електронна апаратура і системи управління на рівні експлуатації

II. Методы патогенетической и этиологичес­кой (личностно ориентированной) психотера­пии

II. Общегосударственная система противодействия терроризму

2. Intranet/Internet технологии в геодезии (технологии клиент/сервер).

3. Функциональные модели информационных объектов и бизнес-

Экзаменационный билет n 11

1. Кодирование информации, методы передачи информации, данные.

2. Теодолитная и тахеометрическая съемки.

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

Экзаменационный билет n 12

1. Мировые информационные ресурсы.

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

3. Принципы оценки инженерно-геодезических работ.

Экзаменационный билет n 13

1. Web- ресурсы, методы поиска информации в Internet.

2. Организация хранения информационных ресурсов, вопросы

3. Проекции, применяемые при решении задач геодезии

Экзаменационный билет n 14

1. Операционные системы (ос): классификация, требования к порядку

2. Методы космической геодезии. Методы космической геодезии

3. Автоматизированное проектирование ис.

Экзаменационный билет n 15

1. Сервисы по: драйверы, интерфейсы, редакторы, средства передачи

2. Растровая и векторная графика в геодезии и картографии.

3. Архитектура микропроцессорных и компьютерных систем

1.4. Архитектура микропроцессорных систем

Вопрос 1

Экзаменационный билет n 16

Экзаменационный билет n 17

1. Жизненный цикл по.

2. Организационные методы защиты ис.

3. Фундаментальные геодезические постоянные.

Экзаменационный билет n 18

1. Геодезические приборы для измерений расстояний.

2. Нормативно-правовая база организации защиты информации.

3. Основы построения государственной геодезической сети (ггс) рф.

Экзаменационный билет n 19

2. Информационная инфраструктура предприятия (клиентская сеть).

3. Авторские права на профессиональные базы данных.

Экзаменационный билет n 20

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

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

Экзаменационный билет n 21

1. Средства линейных измерений в ггс.

2. Ис в геодезической и картографической сферах.

3. Порядок решения задач; обработка и хранение результатов, средства

Экзаменационный билет n 22

1. Web – дизайн.

Этапы проектирования Дизайн основной и типовых страниц сайта

2. Определение площадей. Электронные способы измерения площадей.

Экзаменационный билет n 23

1. Web – документы.

2. Автоматизированные ис.

3. Основы построения государственной геодезической сети (ггс) рф.

Экзаменационный билет n 24

1. Организация государственной геодезической службы в России.

2. Основные определения надежности ис.

3. Стандартизация сетей (iso, osi, эмвос – эталонная модель

Эталонная модель

Экзаменационный билет n 25

1. Топографические карты, номенклатура карт и планов.

Разбиение листа 1:1 000 000 на листы масштаба 1:200 000

Разбиение листа 1:1000000 на листы масштаба 1:100000

Приведем соответствие

2. Инженерно-техническая и физическая защита объектов в ис.

3. Клиентские сети; технологии «последней мили», сравнение технологий подключения клиентов.

Экзаменационный билет n 26

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

Азимуты, румбы, дирекционные углы и зависимости между ними

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

Государственный геодезический надзор

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

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

Определения

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

Экзаменационный билет n 27

1. Рельеф местности и его изображение на топографических картах.

Методы изображения рельефа на планах и картах

Горизонтали

Чем меньше высота сечения, тем точнее должна быть выполнена работа по съемке рельефа.

3.Управление интеллектуальной собственностью предприятий и

Управление интеллектуальной собственностью предприятий и организаций.

Виды интеллектуальной собственности Авторское право

Смежные права

Виды нарушений права интеллектуальной собственности

Международная защита интеллектуальной собственности

Законодательство России в сфере интеллектуальной собственности

Экзаменационный билет n 28

1. Электронные способы измерения расстояний. Электронные способы измерения расстояний

Измерение длины линий дальномерами

2. Классификация методов проектирования ис. Классификация методов проектирования ис

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

Экзаменационный билет n 29

1. Понятие, определение информационной системы (ис).

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

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

Классификация по характеру обработки данных

Классификация по сфере применения

Классификация по охвату задач (масштабности)

2. Определение компьютерных сетей, соединительных сетей

Классификация По территориальной распространенности

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

3. Методы оценки точности результатов геодезических измерений.

Экзаменационный билет n 30

1. Структура ис.

2. Основы криптографии, стеганографии, шифрования, хеширования, как способы защиты информации.

3. Ис обработки и представления данных (карты, планы и т.П.)

Экзаменационный билет n 31

Экзаменационный билет n 32

2. Классификация методов проектирования ис. Классификация методов проектирования ис

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

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

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

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

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

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

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

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

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

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

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

Каноническое проектирование.

Типовое проектирование.

Проектирование с помощью Case-технологий.

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

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

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

обследование объекта и обоснование необходимости создания ИС;

формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

изучение объекта автоматизации;

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

разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

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

разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

разработка проектных решений по системе и ее частям;

разработка документации на ИС и ее части;

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

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

Стадия 6. Рабочая документация.

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

разработка и адаптация программ.

Стадия 7. Ввод в действие.

подготовка объекта автоматизации;

подготовка персонала;

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

строительно-монтажные работы;

пусконаладочные работы;

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

проведение опытной эксплуатации;

проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

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

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

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

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

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

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

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

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

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

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

Типовое проектирование ИС.

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение. Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

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

объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

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

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

Критерии оценки ППП делятся на следующие группы:

назначение и возможности пакета;

отличительные признаки и свойства пакета;

требования к техническим и программным средствам;

документация пакета;

факторы финансового порядка;

особенности установки пакета;

особенности эксплуатации пакета;

помощь поставщика по внедрению и поддержанию пакета;

оценка качества пакета и опыт его использования;

перспективы развития пакета.

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

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

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

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

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

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

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

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

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

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

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

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

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

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

установку глобальных параметров системы;

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

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

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

описание интерфейсов;

настройку системы архивирования.

CASE-технологии.

CASE-средства автоматизации – это методологий структурного системного анализа и проектирования ИС . Основные компоненты интегрированного CASE-пакета: 1) средства централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозитарий); 2) средства ввода; 3) средства анализа; 4) средства вывода - требования к компонентам и к их поддержке.

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. Тестирование: обычно оказывается распределœенным во времени. После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

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

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

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

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

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