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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

восходящее тестирование,
нисходящее тестирование,
тестирование потоков,
интенсивное тестирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи к прочтению:

3.1. Жизненный цикл и фазы жизненного цикла проекта

Похожие статьи: