Минфин Свердловской области 2001-2003гг Что хотел Заказчик

21.08.2013 at 17:00 1 комментарий

Продолжаю о задаче 2003 года. Начало

начальник отдела АСУ Назаров С.И.Начать было решено с нуля. При этом представители Заказчика (в большей степени это были специалисты отдела АСУ, но не только) буквально «писали систему вместе» с разработчиками, искали оптимальные варианты реализации требований.

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

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

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

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

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

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

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

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

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

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

Реклама

Entry filed under: Копилка Мастерской, Мемуары ЦИФТ. Tags: , .

Минфин Свердловской области — задача 2003 года — 1 Какие ИТ профстандарты будут разработаны в 2013 году

1 комментарий Add your own

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Подписка на новости сайта

Подпишитесь на новости сайта (RSS)

RSS

Архивы

Рубрики

Главные книги аналитика

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

Требования для программного обеспечения: рекомендации по сбору и документированию |Илья Корнипаев
Анализ требований к автоматизированным информационным системам | Юрий Маглинец
Пользовательские истории. Гибкая разработка программного обеспечения |Майк Кон


%d такие блоггеры, как: