Так роль бухгалтера в информационной системе по расчету заработной платы заключается в задании исходных данных. Информационная система обрабатывает их по заранее известному алгоритму с выдачей результатной информации в виде ведомости, напечатанной на принтере.
Информационные обучающиеся системы можно классифицировать и по характеру использования информации. Информационно-решающие системы осуществляют все операции переработки информации по определенному алгоритму. Среди них можно провести классификацию по степени воздействия выработанной результатной информации на процесс принятия решений и выделить два класса – управляющие и советующие системы.
Управляющие информационные системы вырабатывают информацию, на основании которой человек принимает решение. Для этих систем характерен тип задач расчетного характера и обработка больших объемов данных. Примером могут служить система оперативного планирования выпуска продукции, система бухгалтерского учета.
Советующие информационные системы вырабатывают информацию, которая принимается человеком к сведению и не превращается немедленно в серию конкретных действий. Эти системы обладают более высокой степенью интеллекта, так как для них характерна обработка знаний, а не данных. Так например существуют медицинские информационные системы для постановки диагноза больному и определения предполагаемой процедуры лечения. Врач может принять к сведению полученную информацию, но и предложить иное решение по сравнению с рекомендуемым системой.
По направлению деятельности различают следующие информационные обучающиеся системы:
производственные системы;
административные системы (человеческих ресурсов);
финансовые и учетные системы;
системы маркетинга.
Производственные системы в свою очередь подразделяются на:
автоматизированные системы управления производством;
автоматизированные системы управления технологическими процессами;
автоматизированные системы управления техническими средствами.
2. Этапы проектирования информационной обучаемой системы
Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить:
· требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;
· требуемую пропускную способность системы;
· требуемое время реакции системы на запрос;
· безотказную работу системы в требуемом режиме, иными словами – готовность и доступность системы для обработки запросов пользователей;
· простоту эксплуатации и поддержки системы;
· необходимую безопасность.
Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.
Проектирование информационных обучающихся систем охватывает три основные области:
· проектирование объектов данных, которые будут реализованы в базе данных;
· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
· учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
В реальных условиях проектирование – это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений.
К любому проекту предъявляется ряд абсолютных требований, например максимальное время разработки проекта, максимальные денежные вложения в проект и т.д. Одна из сложностей проектирования состоит в том, что оно не является такой структурированной задачей, как анализ требований к проекту или реализация того или иного проектного решения.
Рассмотрим основные этапы проектирования обучающихся информационных систем.
Определение стратегии предполагает обследование системы. Основная задача обследования – оценка реального объема проекта, его целей и задач, а также получение определений сущностей и функций на высоком уровне.
Результатом этапа определения стратегии является документ, где четко сформулировано, что получит заказчик, если согласится финансировать проект; когда он получит готовый продукт (график выполнения работ); сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе должны быть отражены не только затраты, но и выгода, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
В документе обязательно должны быть описаны:
· ограничения, риски, критические факторы, влияющие на успешность проекта, например время реакции системы на запрос является заданным ограничением, а не желательным фактором;
· совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, предоставляемые системе, внешние условия ее функционирования, состав людей и работ, которые обеспечивают бесперебойное функционирование системы;
· сроки завершения отдельных этапов, форма сдачи работ, ресурсы, привлекаемые в процессе разработки проекта, меры по защите информации;
· описание выполняемых системой функций;
· будущие требования к системе в случае ее развития, например возможность работы пользователя с системой с помощью Интернета и т.п.;
· сущности, необходимые для выполнения функций системы;
· интерфейсы и распределение функций между человеком и системой;
· требования к программным и информационным компонентам ПО, требования к СУБД (если проект предполагается реализовывать для нескольких СУБД, то требования к каждой из них, или общие требования к абстрактной СУБД и список рекомендуемых для данного проекта СУБД, которые удовлетворяют заданным условиям);
· что не будет реализовано в рамках проекта.
Выполненная на данном этапе работа позволяет ответить на вопрос, стоит ли продолжать данный проект и какие требования заказчика могут быть удовлетворены при тех или иных условиях. Может оказаться, что проект продолжать не имеет смысла, например из-за того, что те или иные требования не могут быть удовлетворены по каким-то объективным причинам. Если принимается решение о продолжении проекта, то для проведения следующего этапа анализа уже имеются представление об объеме проекта и смета затрат.
Этап анализа предполагает подробное исследование бизнес-процессов (функций, определенных на этапе выбора стратегии) и информации, необходимой для их выполнения (сущностей, их атрибутов и связей (отношений)). На этом этапе создается информационная модель, а на следующем за ним этапе проектирования – модель данных.
Вся информация о системе, собранная на этапе определения стратегии, формализуется и уточняется на этапе анализа.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
· функции – информация о событиях и процессах, которые происходят в бизнесе;
· сущности – информация о вещах, имеющих значение для организации и о которых что-то известно.
Двумя классическими результатами анализа являются:
· иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);
· модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.
Три наиболее часто применяемые методологии структурного анализа это:
· диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
· диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
· диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.
На этапе анализа привлекаются группы тестирования, например для получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения. Кроме того, на данном этапе определяется план работ по обеспечению надежности информационной системы и ее тестирования.
На этапе проектирования формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:
· схема базы данных (на основании ER-модели, разработанной на этапе анализа);
· набор спецификаций модулей системы (они строятся на базе моделей функций).
Для проектирования и реализации необходимы аппаратные ресурсы и специальное программное обеспечение. Кроме того, требуется механизм, позволяющий контролировать создаваемую документацию и код. Эти вопросы лучше решать на ранних стадиях проектирования, а не на стадии разработки.
На этапе анализа уже разработан перечень функций, которые будут реализованы. На этапе проектирования этот перечень еще раз анализируется и корректируется. Однозначное соответствие между функцией и модулем вряд ли возможно. Дело в том, что на этапе анализа функции организованы по бизнес-категориям, а на этапе проектирования их придется реорганизовывать для упрощения разработки. Проектировщики могут принять решение объединить несколько функций, обладающих общими свойствами, или выделить какое-то общее свойство (или их набор) в отдельный модуль, а также разбить сложную функцию на несколько модулей.