Реферат: Обучающиеся информационные системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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