Подраздел «Проектирование программного обеспечения»



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

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

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

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

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

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

· выполняющие служебные функции;

· управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю;

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

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

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

Описание программных модулей должно включать блок-схемы и описание блок-схем алгоритмов основных расчетных модулей (объемом не менее 400 операторов).

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

Подраздел «Оценка экономической эффективности проектирования и эксплуатации информационной системы»

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

Проблема расчета экономической эффективности упирается в несколько ключевых точек:

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

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

· Разработчик «не видит» по своей вине или по вине заказчика те ключевые точки, которые принципиально важны для реализации проекта и которые оказывают «видимое» влияние на параметры экономических показателей системы.

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


Дата добавления: 2018-11-24; просмотров: 364; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!