Разработанные в системе «ИНФИН-Управление» конструкторы позволяют быстро и просто адаптировать программу к постоянно меняющимся требованиям, создавать новые настройки или даже специализированные АРМы (автоматизированные рабочие места). Они позволят адаптировать систему в соответствии с требованиями текущего момента как силами сотрудников отделов АСУ, так любого опытного пользователя. Использование конструкторов не требует знания программирования, но если на предприятии работают квалифицированные программисты, то «ИНФИН-Управление» предлагает широкий спектр средств разработки новых функциональных возможностей и приложений системы. Отделам АСУ предоставляется возможность самостоятельно автоматизировать любые бизнес-процессы на своем предприятии, оставив программистам компании «ИНФИН» лишь работу по совершенствованию конструкторов и других системных частей программного комплекса.

Заключение

В заключении хотелось бы проанализировать типичные ошибки при определении требований к информационной системе:

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

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

§ избыточность требований. Избыточность требований встречается так же часто, как и неполнота, как правило, они соседствуют в одном документе. Основные признаки избыточности: описываемые требования реализуются автоматически благодаря используемой технологии разработки или выбранной архитектуре, требования не влияют на архитектуру информационной системы, ее бизнес-логику (например, требования к содержанию данных, вместо требований к структуре и объему информации), требования повторяются многократно в различных частях документа (дублирование). Основная опасность избыточности требований в отвлечении внимания, создании иллюзии полноты выявленных требований.

Литература

1. Калянов Г.Н. Подходы к реорганизации деятельности предприятия // Экономика и производство. – 1998. – №11

2. Колтунова Е. Требования к информационной системе и модели жизненного цикла // Сеть Интернет. – http://silicontaiga.ru/home.asp?artId=2142

3. Королев Д. Инновационный цикл в разработке проектов // Сеть Интернет. – 2000. – http://www.bizcom.ru/.

4. Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 2002.

5. Патрушина С.М. Информационные системы в экономике. – М.: МарТ, 2004.

6. Сеть Интернет, официальный сайт компании «ИНФИН». – http://www.infin.ru/

7. Сеть Интернет. – http://city.tomsk.net/~teis/1x8.htm

8. Сеть Интернет. – http://www.testpro.pisem.net/TEIS/cycle.htm

* В соответствии с каскадной моделью переход на следующий этап может происходить только после завершения предыдущего.

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