Этапы проектирования информационной обучаемой системы

2. Этапы проектирования информационной обучаемой системы

 

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

·      требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

·      требуемую пропускную способность системы;

·      требуемое время реакции системы на запрос;

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

·      простоту эксплуатации и поддержки системы;

·      необходимую безопасность.

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

Проектирование информационных обучающихся систем охватывает три основные области:

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

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

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

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

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

Рассмотрим основные этапы проектирования обучающихся информационных систем.

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

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

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

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

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

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

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

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

·      сущности, необходимые для выполнения функций системы;

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

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

·      что не будет реализовано в рамках проекта.

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

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

Вся информация о системе, собранная на этапе определения стратегии, формализуется и уточняется на этапе анализа.

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

·      функции – информация о событиях и процессах, которые происходят в бизнесе;

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

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

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

·      модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

·      диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;

·      диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;

·      диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

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

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

·      схема базы данных (на основании ER-модели, разработанной на этапе анализа);

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

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

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

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

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

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

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

На этапе определения спецификации модулей решаются следующие задачи:

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

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

·      определение средств разработки для каждого модуля (или выделенных групп модулей), если используются несколько средств разработки в одном проекте;

·      определение последовательности реализации модулей и зависимостей модулей.

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

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

·           обнаружение отказов модуля (жестких сбоев);

·           соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

Заключение

 

В завершении работы отметим, что в целом информационные обучающиеся системы определяется следующими свойствами:

1) любая информационная система может быть подвергнута анализу, построена и управляема на основе общих принципов построения систем;

2) информационная система является динамичной и развивающейся;

3) при построении информационной системы необходимо использовать системный подход;

4) выходной продукцией информационной системы является информация, на основе которой принимаются решения;

5) информационную систему следует воспринимать как человеко-машинную систему обработки информации.

Внедрение информационных обучающихся систем может способствовать:

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

·     освобождению работников от рутинной работы за счет ее автоматизации;

·     обеспечению достоверности информации;

·     совершенствованию структуры информационных потоков (включая систему документооборота);

·     предоставлению потребителям уникальных услуг;

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

Литература

 

1.   Проектирование информационных обучающихся систем. // www.interface.com.

2.   Федотов А.М. Введение в технологии ИС, Институт вычислительных технологий СО РАН, Новосибирск.

3.   Фридланд А.Я. Информатика: Процессы, системы, ресурсы. – М., 2003.

4.   www.ipservis.ru

5.   www.promosite.ru