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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

на основе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

документов:

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

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

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

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

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

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

1.2 Этапы проектирования информационно-справочных систем

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

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

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

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

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

Многие предприятия предпочитают разрабатывать АИС собственными силами, так как:

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

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

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

4. возможна оперативная реакция на изменения правил игры на рынке.

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

Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам собственные разработки АИС в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД.

Во-вторых, использование при разработке современного инструментария.

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

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

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

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

Ориентация на профессиональные СУБД может способствовать достижению следующих целей:

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

2) Надежные средства защиты информации (учитывая стандартную трехзвенную архитектуру защиты на уровне сети - на уровне сервера БД - на уровне клиентской ОС).

3) Эффективные инструменты для разграничения доступа к БД.

4) Поддержка широкого диапазона аппаратно - программных платформ.

5) Реализация распределенной обработки данных.

6) Возможность построения гетерогенных и распределенных сетей.

7) Развитые средства управления, контроля, мониторинга и администрирования сервера БД.

8) Поддержка таких эффективных инструментариев, как: словари данных, триггеры, функции, процедуры, пакеты и т.п.

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

Основные причины ориентации на использования профессиональных СУБД при построении своих АИС :

"ПРОТИВ" - Относительно высокая дороговизна профессиональных СУБД

"ЗА" - Как правило, поставщиками практически всех профессиональных СУБД сейчас предлагаются масштабируемые решения для средних и малых систем, причем цена последних сравнима с ценами на локальные СУБД.

"ПРОТИВ" - Профессиональные СУБД предъявляют высокие требования к аппаратной платформе.

"ЗА" - С резким ростом производительности Intel-ориентированных аппаратных платформ большинство производителей профессиональных СУБД выпустила свои версии и под Intel-сервера, в том числе и под ОС LINUX, а учитывая что LINUX при всей своей мощности UNIX системы практически бесплатная ОС, то и решение на ее основе как правило не повлечет больших финансовых затрат. Это позволяет при построении системы ориентироваться не только на высокопроизводительные многокластерные RISC сервера, но и использовать серверные Intel-платформы.

"ПРОТИВ" - Профессиональные АИС сложны и дороги в администрировании.

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

"ПРОТИВ" - Разработки АИС на промышленной платформе слишком дороги.

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

"ПРОТИВ" - Внедрение систем на профессиональной платформе процесс затяжной и дорогостоящий.

"ЗА" - Затяжка внедрения, как правило, обусловлена либо недостатком опыта фирмы поставщика по установке таких систем, либо недостаточной готовностью самого внедряемого продукта. Ориентировочный срок установки типовой АИС четвертого поколения под СУБД Oracle при отлаженном технологическом процессе составляет несколько недель.

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

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

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

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

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

А) Разработка и анализ бизнес - модели

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

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

Аппаратно-технический состав создаваемой АИС.

Б) Формализация бизнес - модели, разработка логической модели бизнес -процессов.

Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.

В) Выбор лингвистического обеспечения, разработка программного обеспечения АИС.

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

Г) Тестирование и отладка АИС

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

Д) Эксплуатация и контроль версий

Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС.

Рис.1.3 Последовательность трансформации бизнес-модели в объекты БД и приложения

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

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

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

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

Разрешение всех дуг, подтипов и супертипов;

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

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

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

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

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

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

Оценка размеров всех таблиц, индексов, кластеров;

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

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

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

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

Информационная система может строиться с применением послойного принципа. Так, в отдельные слои можно выделить специализированное программное обеспечение (офисное, прикладное), непосредственно workflow, систему управления документами, программы поточного ввода документов, а также вспомогательное программное обеспечение для связи с внешним миром и обеспечения доступа к функционалу системы через коммуникационные средства (e-mail, Internet/intranet).

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

ГЛАВА 2. ХАРАКТЕРИСТИКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ГОУ НПО ПУ №33

Введение

Заключение

Литература

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основная

Г.Н. Смирнова, А.А.Сорокин, Ю.Ф. Тельнов Проектирование экономических информационных систем. Учебник. М., «Финансы и статистика»,2002

Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., «Финансы и статистика»,2000

Маклаков С.В. Создание ИС с AllFusion Modelling Suite. М., «Диалог-МИФИ», 2003

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование ИС. Учебное пособие. Интернет-университет, М., 2005

Дополнительная

Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. М.,СИНТЕГ, 2000

Калянов Г.Н. Структурный системный анализ.

М., Лори, 1996

Марка Д.А., МакГоуэн К. SADT – методология структурного анализа и проектирования., М., Метатехнология, 1993

Г. Буч Д. Рамбо А. Джекобсон Язык UML. Руководство пользователя, 1999

М. Фаулер К. Скотт Основы UML

Т. Кватрани Rational Rose 2000 и UML. Визуальное моделирование. Москва, 2001

Дополнительная

Колтунова Е. Требования к информационной системе и модели жизненного цикла. Carabi Solutions , www.carabisolutions.sp.ru

Автоматизированные Системы Стадии создания. ГОСТ 34.601-90 Комплекс стандартов на автоматизированные системы. ИПК издательство стандартов, М., 1997

ISO/IEC 12207:1995

Thiele D. Life cycle management using life cycle process standards. Abstract. http://www.fostas.ru/library/show_article.php? id=22

Проектирование и разработка корпоративных информационных систем. http://zeus.sai.msu.ru:7000/cfin/prcorpsys/index.sht ml.

Основные понятия

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

1. Цели и содержание методологии проектирования ИС

2. Жизненный цикл ИС

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

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

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

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

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

Подсистемы ИС

Информационное обеспечение совокупность

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

Этапы развития технологий проектирования ИС

1. Метод "снизу-вверх" - не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Успешно автоматизируются отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривается недостаточно хорошо, особенно в перспективе.

(«Лоскутная автоматизация»)

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

Этапы развития технологий проектирования

(продолжение)

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

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

Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС(например, Price Waterhouse, Jet Info, Consistent Software и др.).

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

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

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

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

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

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

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

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

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

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

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

Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

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

I этап - предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);

II этап - проектный (составление технического и рабочего проектов);

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

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

Рис.1.

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

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

устный и письменный опрос;

письменное анкетирование;

наблюдение, измерение, оценка;

групповое обсуждение;

анализ задач;

анализ производственных, управленческих и информационных процессов.

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

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

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

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

В процессе постановки задачи раскрываются:

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

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

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

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

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