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

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

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

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

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

2. определение требований к системе;

3. сбор и анализ требований пользователей;

4. проектирование базы данных:

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

· логическое проектирование базы данных;

· физическое проектирование базы данных;

5. разработка приложений:

· проектирование транзакций;

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

6. реализация;

7. загрузка данных;

8. тестирование;

9. эксплуатация и сопровождение:

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

· адаптация, модернизация и поддержка переработанных вариантов.

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

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

Этап 3. Сбор и анализ требований пользователей. На данном этапе необходимо создать для себя модель движения важных материальных объектов и уяснить процесс документооборота.

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

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

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

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

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

Эту технологию мы использовали на наших лабораторных занятиях.

ER-модель относится к семантическим моделям. Семантическое моделирование данных связано со смысловым содержанием данных и может осуществляться независимо от их представления в компьютере.

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

· Выделение предметных областей информационной системы, соответствующих относительно независимым данным.

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

· Выделение ключевых свойств объектов.

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

· Объединение предметных областей.

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

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

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

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

Этап 5. Разработка приложений. Параллельно с проектированием системы базы данных выполняется разработка приложений. Главные составляющие данного процесса — это проектирование транзакций и пользовательского интерфейса.

Проектирование транзакций заключается в определении:

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

· последовательности действий, составляющих транзакцию;

· выходных данных, формируемых транзакцией;

· степени важности и интенсивности использования транзакции.

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

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

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

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

Этап 8. Тестирование. Для оценки законченности и корректности выполнения приложения базы данных могут использоваться различные стратегии тестирования.

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

· восходящее тестирование,

· нисходящее тестирование,

· тестирование потоков,

· интенсивное тестирование.

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

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

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

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

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

Типы тестов, которые используют для проверки работы программ:

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

Применение основного теста – главный момент тестирования, но помимо него программа должна быть подвергнута и другим тестам.

· Тест граничных значений, или "стрессовый тест" – проверяет работу программы для граничных значений параметров. Часто для граничных значений параметров работа программы носит особый характер, который тем самым требует и особого контроля.

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

• сортируемый массив пуст;
• сортируемый массив содержит только один элемент;
• все элементы в сортируемом массиве одинаковы;
• массив уже отсортирован.

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

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

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