Этапы проектирования информационных систем. Стадии создания и функционирования автоматизированной информационной системы. Учебный курс

Введение

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

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

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

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

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

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

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

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

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

Рис. 1. Cхема «водопада»

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

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

Ниже мы рассмотрим некоторые схемы разработки проекта.

«Водопад» - схема разработки проекта

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

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

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

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won’t have - отсутствующие функции.

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

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

Двумя классическими результатами анализа являются:

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

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

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

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

ER-диаграммы

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

Рис. 2. Пример ER-диаграммы

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

Отношение изображается линией между двумя сущностями (синие линии на рисунке).

Одиночная линия справа (рис. 3) означает «один», «птичья лапка» слева - «многие», а отношение читается вдоль линии, например «один ко многим». Вертикальная черта означает «обязательно», кружок - «не обязательно», например для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

Рис. 3. Элемент ER-диаграммы

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

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

Рис. 4. ER-диаграмма рефлексивного отношения

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

Дуги

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

Рис. 5. Дуга

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность делится на типы по категориям: «для физического лица» и «для юридического лица». Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 6.

Рис. 6. Подтипы (справа) и супертип (слева)

Нормализация

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

Допустимые типы связей. При ближайшем рассмотрении связи типа «один к одному» (рис. 7) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Рис. 7. Связи «один к одному»

Связи «многие к одному» представлены на рис. 8.

Рис. 8. Связи «многие к одному»

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

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

III - применяется редко. Как A, так и B могут существовать без связи между ними.

Связи «многие ко многим» представлены на рис. 9.

Рис. 9. Связи «многие ко многим»

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

II - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рис. 10).

Рис. 10. Рекурсивные связи

I - редко, но имеет место. Отражает связи альтернативного типа.

II - достаточно часто применяется для описания иерархий с любым числом уровней.

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

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь «многие ко многим» (рис. 11) и ряд рекурсивных связей (рис. 12).

Рис. 11. Недопустимые связи «многие ко многим»

Обязательная связь «многие ко многим» в принципе невозможна. Такая связь означала бы, что ни одно из вхождений A не может существовать без B, и наоборот. На деле каждая подобная конструкция всегда оказывается ошибочной.

Рис. 12. Недопустимые рекурсивные связи

Диаграммы потоков данных

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

Рис. 13. Пример DFD

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

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

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

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

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

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

Диаграммы изменения состояний STD

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

Рис. 14. Пример диаграммы жизненного цикла

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

Некоторые принципы проверки качества и полноты информационной модели
(источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

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

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

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

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

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

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

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

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

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

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

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

Качество связи

Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями.

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

• Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?
• Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

• Заданы ли степень связи и обязательность для каждой стороны?
• Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

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

Для исключающей связи:

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

Функции системы

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

Рис. 15. Пример декомпозиции

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

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

Уточнение стратегии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ. Задача формирование требований к системе является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки.Анализ деятельности организации, выполняемый на данном этапе, должен помочь в формировании требований к ИС, корректно и точно отражающих цели и задачи организации- заказчика. Наряду с изучением требований пользователя и имеющихся систем на этапе анализа необходимо создать логический проект системы. С помощью логического проектирования необходимо определить концептуальную модель данных, входные данные, процессы и предполагаемые выходные данные. Моделирование данных, выполняемое на данном этапе, включает в себя выявление и описание объектов и их атрибутов, а также связи между сущностями (описание модели в виде ER-диаграммы). Описание и документирование всех преобразований данных (процессов) может быть выполнено с помощью таких средств анализа, как схемы информационных потоков (DFD – data flow diagram) или моделей функций и процессов.Конечной целью моделирования бизнес-процессов, протекающих в организации и реализующих ее цели и задачи является построение моделей организации, описанных в терминах бизнес-процессов и бизнес-функций. На этом же этапе изучаются имеющееся оборудование и программные средства. Результатом анализа должно стать лучшее понимание функционального назначения системы, существующие и потенциальные проблемы, а также сфера ее действия.

На этом этапе конечные пользователи и проектировщики должны работать сообща.

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

Схема БД (на основании ER-модели, разработанной на этапе анализа); - набор спецификаций модулей системы (на базе моделей функций). Также на этапе проектирования определяется: - выбор платформы и ОС (могут быть не единственными); - характеристики архитектуры: ф/с или к/с; количество уровней (1, 2 или 3); централизованная или распределенная БД; однородность или неоднородность БД (по количеству используемых серверов). Этап проектирования заканчивается разработкой технического проекта ИС.

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

Этап тестирования обычно оказывается распределенным по времени.

А) после завершения разработки отдельного модуля системы выполняют автономный тест , который преследует следующие цели: - обнаружение отказов модуля (жестких сбоев); - соответствие модуля спецификации (наличие всех необходимых функций и отсутствие лишних функций). Б) После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходиттесты связей , которые должны отследить их взаимное влияние. После тестирования на взаимное влияние модулей необходимо выполнить еще ряд тестов: В)тесты на проверку надежности работы: 1) тест имитации отказов, демонстрирующий, насколько хорошо система восстанавливается после сбоев ПО и отказов аппаратного обеспечения; 2) тест наработки на отказ (устойчивость системы при штатной работе для оценки времени безотказной работы системы); 3) системный тест (проверка функциональности системы); 4) приемо-сдаточные испытания (такой тест предусматривает показ ИС заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика). Как правило, тестирование и эксплуатация занимают от 50% до 60% общего времени разработки ИС. V.Ввод в действие. Эксплуатация и сопровождение. После ввода в действия организуется обучение конечных пользователей. Практически сразу после ввода системы в строй конечные пользователи начинают просить внести в нее изменения. Внесение изменений и исправлений выполняется службой сопровождения системы, работающей в трех направлениях: - корректирующее обслуживание – как ответ на возникающие ошибки системы; - адаптивное обслуживание – как ответ на изменение корпоративной среды; - усовершенствование – расширение возможностей системы.

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

• предпроектное обследование;
• технико-экономическое обоснование;

• структуру существующей системы;
• объемы выполняемой работы и трудозатраты;
• качество выполняемой работы;
• методы выполнения работы;

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

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

• исходные положения, характеристики и технико-экономические данные об объекте;
• обоснование цели создания ИС;
• обоснование комплекса задач, решаемых в ИС, и ДР.

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

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

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

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

• операционные системы,

• ¦ АСУ - автоматизированные системы управления,

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

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

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

• САПР в строительстве,
• САПР в машиностроении,
• САПР в электронной промышленности,
• САПР в авиастроительстве и т.д.

• системы подготовки чертежной документации,
• системы расчета на прочность, жесткость и устойчивость,
• системы подготовки проектно-сметной документации,
• системы подготовки документации на конкурс и т.п.

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