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

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

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

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

       Журнал  проектирования

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

       Такой журнал может вестись как на этапе  анализа, так и на этапе разработки и тестирования.

       Планирование  этапа проектирования

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

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

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

       Определить  зависимости между задачами, а также последовательность завершения задач.

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

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

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

       Перепланирование

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

       3 Заключительные стадии  проектирования, схема  базы данных 

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

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

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

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

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

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

       Схема базы данных

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

       ER-модель и ее отображение на схему данных.

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

• В информационной модели описаны три сущности — A, B, C. Сущности B и C содержат внешние ключи, ссылающиеся на сущность A. В СУБД поддерживается возможность определения внешнего ключа только для первичного ключа, а для возможного ключа определить декларативную ссылочную целостность нельзя. В этом случае отображение ER-модели на физическую модель данных невозможно без изменения информационной модели;
• В информационной модели описан внешний ключ с каскадным удалением и модификацией. В СУБД поддерживаются внешние ключи только для варианта действия no action (то есть каскадные изменения в явном виде не поддерживаются). Реализация ссылочной целостности посредством триггеров ограничена уровнем каскадирования триггеров (например, 32 вызовами триггера). В этом случае потребуется также изменение информационной модели;
• В информационной модели определен атрибут, представляющий собой строку длиной в 500 символов. По этому атрибуту часто осуществляется поиск в информационной системе; объем данных велик. В СУБД можно индексировать строки символов не длиннее чем 128 или 256 символов. Если осуществлять поиск без индекса, то время ответа информационной системы существенно превышает допустимое, вследствие чего придется изменить описание сущности;
• В информационной модели описана сущность A, которая содержит по крайней мере два атрибута BLOB (например, требуется отдельно хранить и звук и изображение). В СУБД невозможно создать таблицу с двумя атрибутами BLOB и в этом случае нужно изменить описание сущности. Из отношения A исключаются два атрибута BLOB, и добавляется один атрибут AK типа integer. Добавляются две дополнительные сущности — и . Каждая из них будет содержать один атрибут BLOB и один ключевой атрибут K типа integer, который станет внешним ключом у каждого из новых отношений и будет ссылаться на атрибут AK в отношении A (тип внешнего ключа — on delete cascade, on update cascade);
• Жизненный цикл сущности определен в информационной модели соответствующей диаграммой. В описании сущности отсутствует атрибут, который отражает изменение состояния сущности. В этой ситуации проектировщики добавляют атрибут status, для которого определяется ограничение допустимых значений (из списка допустимых состояний), а изменение состояния сущности описывается триггером, проверяющим допустимость сочетания нового и старого значения атрибута;
• Две диаграммы потока данных описывают различные бизнес-процессы, работающие над одними и теми же данными. Допустим, первая диаграмма описывает выписку товара со склада, а вторая — сложный отчет, отражающий состояние склада. Один процесс интенсивно модифицирует данные, второй работает в режиме чтения данных, но требует согласованности данных в течение длительного времени. Каждый из процессов описывается транзакцией над данными. В СУБД уровни изолированности транзакций реализованы так, что читающие транзакции конфликтуют с модифицирующими транзакциями. Это приводит к остановке выписки товаров со склада на время выполнения отчета, что неприемлемо для заказчика. Здесь может потребоваться очень серьезное изменение информационной модели.

       Подобных  примеров, когда не только ER-модель, но и другие продукты анализа не могут быть перенесены автоматически  на модель данных, можно привести множество. Каждый такой случай инициирует изменение информационной модели. Решение проблемы определяется возможностями СУБД, выбранной для реализации проекта. Если проблем, не разрешаемых в рамках данной СУБД, накапливается очень много, то проектировщики могут поставить вопрос о смене СУБД. Такой вопрос поднимается именно на стадии проектирования, поскольку если уже разработчики столкнутся с подобными проблемами, то цена смены СУБД будет выше. Ясно, что одинаковых СУБД не бывает: то, что хорошо работает в одной, может плохо работать или вообще не работать в другой, несмотря на уверения производителей СУБД в поддержке стандартов SQL. Что касается хранимых процедур и триггеров, то здесь вообще трудно говорить о поддержке SQL92/PSM.

       Вопросы производительности информационной системы  также влияют на отображение ER-модели на модель данных. За счет мощного сервера баз данных можно добиться большей скорости реакции системы, но мощность аппаратного комплекса ограниченна. Производительность системы в целом зависит в том числе и от нормализации. Часто до 80% запросов к базе данных являются выборками данных, а соединение по тому или иному атрибуту относится к затратным операциям, в первую очередь соединение по нечисловым атрибутам. Увеличить производительность системы можно посредством введения избыточной информации — денормализации. Следует отметить, что решение об этом не принимается на основе одной ER-модели — требуется внимательно проанализировать потоки данных. Критичные процессы являются хорошими кандидатами для денормализации: по времени выполнения, по частоте выполнения, по большому объему обрабатываемых данных, по частоте изменения обрабатываемой информации, по явному приоритету. Часто к денормализации прибегают в целях ускорения выполнения отчетов. Для проверки эффективности той или иной денормализации привлекаются тестеры.  
 
 
 

Заключение 

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

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

       Целевое назначение информационной системы сводится к достижению следующих целей:

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

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

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

 
 
 
 
 

Список используемой литературы 

    

1. Гринберг  А.С., Король И.А.: Информационный менеджмент 2003г;
2. Д.В. Александров, А.В. Костров, Р.И. Макаров, Е.Р. Хорошева: Методы и модели информационного менеджмента: учеб. пособие 2007г;
3. Багриновский К.А., Матюшок В.М.: Экономико-математические методы и модели: Учеб. Пособие 2000г;
4. Кабушкин Н.И. Основы менеджмента: Учебное пособие 5-изд. 2002г;
5. Петров В.Н.: Информационные системы 2003г;
6. Ю.С.Избачков,В.Н.Петров: Информационные системы: Учебник для вузов 2006г;
7. Б.Я. Советов, В.В. Цехановский: Информационные технологии 2006г;