Проектирование информационных систем. Часть 3
Этапы разработки проекта: заключительные стадии проектирования, схема базы данных
Заключительные стадии проектирования
Проектирование процесса тестирования
Требования к безопасности, доступу, обслуживанию системы
ER-модель и ее отображение на схему данных
Обмен данными с внешними системами
Заключительные стадии проектирования
Проектирование процесса тестирования
Проектирование процесса тестирования, как правило, следует за процессом функционального проектирования и проектирования схемы базы данных. На этом этапе можно использовать сложные схемы тестирования, а можно ограничиться и простыми. Здесь мы приведем некоторые принципы, которых нужно придерживаться при проектировании любой информационной системы.
Когда генерация модуля завершена, выполняют автономный тест, который преследует две основные цели:
- обнаружение отказов модуля (жестких сбоев);
- соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
После того как автономный тест прошел успешно, группа сгенерированных модулей проходит тесты связей, которые должны отследить взаимное влияние модулей.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
Затем весь комплект модулей проходит системный тест — тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы — приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
 |
|
Требования к безопасности, доступу, обслуживанию системы
Каждая информационная система содержит определенные требования к защите от несанкционированного доступа, к регистрации событий системы, аудиту, резервному копированию, восстановлению информации, которые в начале проектирования должны быть формализованы аналитиками. Проектировщики строят стратегию безопасности системы. В частности, ими должны быть определены категории пользователей системы, которые имеют доступ к тем или иным данным посредством соответствующих компонентов. Кроме того, определяются объекты и субъекты защиты. Следует отметить, что стратегия безопасности не ограничивается только ПО — это должен быть целый комплекс мер и правил ведения бизнеса. Нужно четко определить, какой уровень защиты данных необходим для каждого из компонентов информационной системы, и выделить критичные данные, доступ к которым строго ограничен. Пользователи информационной системы регистрируются, поэтому проектируются модули, отвечающие за идентификацию и аутентификацию пользователя. В большинстве СУБД реализована дискреционная защита данных, то есть регламентирован доступ к объектам данных (например, к таблицам, представлениям). Если же требуется ограничение доступа собственно к данным (к отдельным записям в таблице, к отдельным полям записи в таблице и т.п.), то следует реализовать мандатную защиту. Проектировщики должны иметь четкое представление о том, какой уровень защиты той или иной единицы информации является необходимым, а какой достаточным.
Вопросы восстановления, хранения резервных копий базы данных, архивов базы данных относятся к мероприятиям поддержки бесперебойного функционирования информационной системы. Необходимо внимательно изучить возможности, предоставляемые СУБД, а затем проанализировать, как следует использовать возможности СУБД для обеспечения требуемого уровня бесперебойной работы системы.
|
|
Составление спецификаций
Результаты проектирования отражаются в документе — функциональной спецификации. Этот документ пишется для заказчика, чтобы получить его санкцию на завершение проектирования и начало разработки, и обычно не содержит большого количества технических деталей. Второй документ — техническая спецификация, являющаяся основным документом для разработчиков моделей и групп тестирования, и здесь описаны детали проекта. Если использовались CASE-средства, то техническая спецификация обязательно содержит ряд отчетов из репозитария.
|
|
Полнота проектирования
Перед началом разработки модулей нужно еще раз проверить полноту проектирования. Один из полезных инструментов — матрица использования таблиц схемы базы данных по модулям.
|
|
Переход к реализации
Итак, начата реализация модулей. Означает ли это, что работа проектировщиков на этом завершена полностью? На практике это далеко не так. Довольно часто разработчик сталкивается с медленно работающими или не реализуемыми в данной схеме запросами. Подобные ситуации инициируют изменение модели данных, а значит, и информационной модели. Однако изменение информационной модели производится не только по этой причине. Хорошему проектировщику необходим практический опыт работы с аппаратным и программным обеспечением — вот одна из причин участия проектировщиков в составе групп разработчиков. Нередко ведущие сотрудники групп разработчиков одновременно являются проектировщиками.
Как можно использовать проектировщиков на этапе разработки? Приведем некоторые примеры:
- Проектировщик, написавший спецификацию модуля, проводит семинар с разработчиками и демонстрирует необходимые прототипы (семинар предполагает диалог двух сторон).
- Когда модуль передан разработчику, проектировщик может участвовать в его пересмотре, а также выполнять контрольные функции по реализации проектных решений.
- Для крупных проектов характерно поэтапное выполнение работ, так что вполне вероятно, что после завершения реализации группы модулей и сдачи очередного этапа процесс проектирования будет продолжен для новой группы модулей.
- Проектировщики должны обеспечить быстрое реагирование на возможные изменения требований заказчика, поскольку своевременная обработка такой информации является их обязанностью. Кроме того, необходимо и участие системных аналитиков, так как именно они общаются с заказчиком проекта.
