Cообщи

Такое у нас э-государство: Госконтроль счел неудачными несколько госпроектов по разработке ПО

Обращаем ваше внимание, что статье более пяти лет и она находится в нашем архиве. Мы не несем ответственности за содержание архивов, таким образом, может оказаться необходимым ознакомиться и с более новыми источниками.
Редактор: rus.postimees.ee
Copy
Компьютер. Иллюстративное фото.
Компьютер. Иллюстративное фото. Фото: Kacper Pempel/Reuters/Scanpix

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

Аудит показал, что из проверенных девяти проектов по разработке программного обеспечения четыре проекта оказались неудачными: Эстонская научная информационная система (ETIS2), информационная система для проведения судебными исполнителями исполнительного производства (e-Täitur), вторая версия информационной системы социальной защиты (SKAIS2), информационная система Департамента полиции и пограничной охраны для установления личности и ведения производства (UUSIS). Неудавшимся проект считался в том случае, когда он не был проведен в соответствии с предусмотренным бюджетом, в установленное время и с необходимой функциональностью.

Если обобщить, проекты не удались по следующим причинам:

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

· E-Täitur – руководитель проекта по разработке не учел потребностей пользователей, роли и задачи участников проекта не были четко определены, у сторон проекта имелись проблемы в части сотрудничества.

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

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

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

Наиболее распространенные риски:

■ Цели ставятся и формулируются неправильно или в недостаточной мере.

■ Содержание программы неясно, люди, которые занимаются содержательной стороной разработки, не знают точно, чего от них хотят.

■ Пожелания людей, занимающихся содержательной стороной разработки, никто не может точно описать.

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

■ Знания руководителя проекта заказчика или руководителя проекта исполнителя, или обоих, недостаточны.

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

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

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

■ Недостаточное финансирование проекта.

■ Численность команды недостаточна, знания членов команды не на должном уровне, члены команды сменяются.

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

■ Риски, связанные с тестированием и приемом, недостаточное управление версией, проблемы в связи с выкладыванием результатов разработки.

■ Действующий план проекта отсутствует или игнорируется.

Обобщенно на базе оценки девяти проектов можно указать следующие факторы успеха в разработке программного обеспечения:

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

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

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

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

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

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

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

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

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

При поддержке пособий Европейского союза в бюджетный период 2007–2013 были завершены в общей сложности 232 проекта в сфере информационных и коммуникационных технологий (ИКТ) на общую сумму 53,4 млн евро. В соответствии с последним прогнозом бюджета государственной программы развития информационного общества, в период 2014–2020 на ИКТ-решения должно быть затрачено в общей сложности 223 миллиона евро. Например, пособия Европейского союза в нынешний бюджетный период можно использовать для разработки разумной инфраструктуры услуг на общую сумму 46 миллионов евро и на разработку предложения общественных услуг на общую сумму 99 миллионов евро.

По данным Государственной системы управления информационными системами (RIHA), в общественном секторе используется около тысячи информационных систем, предлагающих жителям и должностным лицам различные э-услуги. В настоящее время описано более 1500 услуг. Услуги должны быть указаны в находящемся в сфере управления MKM каталоге услуг, и, по возможности, на сайте предлагающего услугу учреждения.

В ходе аудита Госконтроль проанализировал девять случаев разработки информационных систем в сферах управления девяти министерств: Регистр строений, или EHR, государственную систему управления информационными системами, или RIHA (Министерство экономики и коммуникаций), Эстонскую научную информационную систему, или ETIS (Министерство образования и науки), программу для проведения судебными исполнителями исполнительного производства, или e-Täitur (Министерство юстиции), информационную систему решений по окружающей среде, или KOTKAS (Министерство окружающей среды), систему пособий на развитие сельской жизни, или MATS (Министерство сельской жизни), регистр госзакупок, или RHR (Министерство финансов), информационную систему социальной защиты, или SKAIS (Министерство социальных дел), а также информационную систему Департамента полиции и пограничной охраны для установления личности и ведения производства, или UUSIS (Министерство внутренних дел). Кроме того, была рассмотрена организация разработки программного обеспечения в Министерстве культуры и Министерстве иностранных дел.

Наверх