Software & Systems

Одним из важнейших этапов при реализации проектов внедрения информационных систем корпоративного уровня является управление требованиями заказчика. Согласно утверждению Ф. Брук­са, автора классических публикаций по теории и практике построения программных систем, «самой сложной задачей при создании программной системы является точное определение того, что требуется создать. Ни одна иная решаемая задача не приносит такого же вреда конечной системе в случае ошибки. И нет ни одной задачи настолько же сложной в исправлении последствий» [1].

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

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

К наиболее явным причинам, определяющим сложность задачи управления требованиями, можно отнести следующие:

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

-     широкий диапазон типов требований, каждое из которых требует детального описания и различной степени проработки;

-     необходимость формирования четких приоритетов исполнения предъявляемых требований;

-     потребность в трассировке требований, установлении связей между ними;

-     обязательное отслеживание изменений требований в ходе реализации проекта.

Самые распространенные причины срыва сроков и увеличения бюджета проектов:

-     не все требования были услышаны, зафиксированы, выявлены;

-     услышанные, зафиксированные, выявленные требования были недостаточно четко сформулированы;

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

В государственных учреждениях проблема управления требованиями к системам стоит наиболее остро. Так, например, пункт 2 статьи 34 Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения го- сударственных и муниципальных нужд» гласит: «При заключении контракта указывается, что цена контракта является твердой и определяется на весь срок исполнения контракта, а в случаях, установленных Правительством Российской Федерации, указываются ориентировочное значение цены контракта либо формула цены и максимальное значение цены контракта, установленные заказчиком в документации о закупке. При заключении и исполнении контракта изменение его условий не допускается, за исключением случаев, предусмотренных настоящей статьей и статьей 95 настоящего Федерального закона» (http://www.consultant.ru/document/ cons_doc_LAW_144624/). Это означает, что практически во всех случаях любое изменение требования, внесенного в подписанный договор, является нарушением. Например, в учреждение поступило распоряжение руководителя на разработку какого-либо специального ПО (СПО). После анализа будущего СПО и конкурсных процедур был определен победитель, который стал исполнителем по договору.

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

В России в качестве методологической базы создания информационных систем используются стандарты в соответствии с ГОСТом 34 (http:// www.prj-exp.ru/gost-34), где первой стадией жизненного цикла системы определяется процедура формирования требований к автоматизированной системе (АС). ГОСТ 34 достаточно хорошо справляется со своими задачами и по сей день, хотя идет непрерывное развитие информационных технологий и расширяются сферы их применения в системах обработки, хранения и предоставления информации. Эффективность этой методологии признается не только в РФ, так, например, разработчики некоторых инструментов управления требованиями внедряют поддержку этой методологии в свои продукты, в том числе пытаются автоматизировать разработку документации, основываясь на приня- тых шаблонах и справочниках.

Таким образом, наиболее ответственной стадией жизненного цикла системы является ее проектирование [2]. Однако очень часто на этой стадии процессы работы с требованиями не выделяются в качестве полноценного этапа. Локальные нормативно-правовые акты (ЛНПА), издаваемые на разных уровнях, практически никогда не содержат информацию о стадиях разработки. Предполагается, что сотрудники сами распределят выделенное время на проектирование, разработку, проведение испытаний и принятие в эксплуатацию. Это и есть самое большое упущение. Задача каждого сотрудника учреждения заключается в достижении поставленных перед ним задач, закрепленных должностной инструкцией и разного рода ЛНПА. Поэтому, если в должностной инструкции или ЛНПА отсутствует процесс управления требованиями, то попытка навязать его будет встречена сопротивлением. Все остальные процессы, закрепленные законодательно, будут неукоснительно выполнены даже в том случае, если в них нет никакой необходимости. Подобное поведение – не отказ от инноваций и тотальный консерватизм, а вполне адекватная реакция на попытку увеличить рабочую нагрузку. Дело в том, что сотрудники государственных учреждений имеют достаточно плотную занятость, увеличение нагрузки, как правило, не поощряется материально, соответственно, отсутствует и мотивация.

Решить подобную проблему можно разными способами, однако первое, что необходимо сделать, это закрепить процесс управления требованиями нормативно, как обязательный этап, проводимый с использованием методологии ГОСТ 34. Управление требованиями будет выделено в полноценную стадию жизненного цикла системы, а обязательность данного процесса приведет к необходимости отчитываться за выполнение перед надзорными органами. В свою очередь, Трудовой кодекс РФ не позволит руководству учреждений перегружать своих сотрудников и потребует увеличения штатной численности. Но даже такой шаг не сумеет оспорить положительного влияния процесса управления требованиями к информационной системе на результат по оптимизации бюджетных ресурсов, необходимых для ее создания.

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

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

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

Основные проблемы с процессом управления требованиями, возникающие в государственных учреждениях, довольно схожи с аналогичными проблемами в бизнес-среде: возникает недопонимание руководства и экспертов в области информационных технологий. Согласно Л. Мацяшеку [5], анализ и проектирование информационных систем, формирование и управление требованиями предпо- лагают наличие у участников процесса определенного социального, коммуникативного и управленческого опыта. Действительно, так и есть, но только тогда, когда процесс управления требованиями вообще присутствует как полноценный этап проектирования, модернизации и сопровождения информационной системы.

Неотъемлемой частью процесса управления требованиями является также визуализация требований. Визуальное моделирование [6] должно присутствовать во всех типах документации. В первую очередь необходимо визуализировать требования к продукту. Визуальное моделирование требований – это своеобразный мост между разработчиками и управленцами. Его отсутствие, как правило, приводит к тому недопониманию, которое только доказывает индивидуальность каждого отдельно взятого человека [7].

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

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

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

Литература

1.     Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы; [пер. с англ.]. СПб: СимволПлюс, 2007. 304 с.

2.     Business process model and notation (BPMN). Vers. 2.0, 2011. OMG Publ., 538 p.

3.     Кознов Д.В. Визуальное моделирование информацион- ных e-сервисов в публичной сфере. СПб: Изд-во СПб ун-та, 2014. 144 с.

4.     Амелин Р.В. О разграничении полномочий в сфере правового регулирования федеральных информационных систем // Гражданское право. 2015. № 2. С. 42–54.

5.     Мацяшек Л. Анализ и проектирование информационных систем с помощью UML 2.0; [пер. с англ.]. М.: Вильямc, 2008. 816 с.

6.     Martínez Yu., Cachero C., Meliá S. MDD vs. traditional software development: A practitioner’s sub subjective perspective. Inform. and Soft. Tech., 2013, vol. 55, iss. 2, pp. 189–200.

7.     Gurin J. Open Data Now: the secret to hot startups, smart investing, savvy marketing, and fast innovation. McGraw-Hill Publ., 2013, 272 p.

8.     Solis-Martinez J., Espada J., G-Bustello B., Lovelle J. BPMN MUSIM: Approach to improve the domain expert’s efficiency in business processes modeling for the generation of specific software applications. Expert Systems with Applications, 2014, vol. 41, iss. 4, part 2, pp. 1864–1874.

References

1. Brooks Ph. The Mythical Man-Month: Essays on Software Engieneering. Addison-Wesley Professional Publ., 1995,
   336 p. (Russ. ed.: St. Petersburg, SimvolPlus Publ., 2007, 304 p.).
2. Business process model and notation (BPMN). Version 2.0. 2011, OMG Publ., 538 p.
3. Koznov D.V. Vizualnoe modelirovanie informatsionnykh e-servisov v publichnoy sfere [Visual Modeling of Information E-services in the Public Sphere]. St. Petersburg Univ. Publ., 2014, 144 p.
4. Amelin R.V. On delimitation of powers in the legal regulation of federal information systems. Grazhdanskoe pravo [Civil Law]. 2015, no. 2, pp. 42–54 (in Russ.).
5. Maciaszek L.A. Requirements Analysis and Systems Design. Addison Wesley Publ., 2001, 378 p. (Russ. ed.:
   St. Petersburg, Viliams Publ., 2008, 816 p.).
6. Martínez Yu., Cachero C., Meliá S. MDD vs. traditional software development: A practitioner’s sub subjective perspective. Information and Software Technologies. 2013, vol. 55, iss. 2, pp. 189–200.
7. Gurin J. Open data now: the secret to hot startups, smart investing, savvy marketing, and fast innovation. McGraw-Hill Publ., 2013, 272 p.
8. Solis-Martinez J., Espada J., G-Bustello B., Lovelle J. BPMN MUSIM: Approach to improve the domain expert’s efficiency in business processes modeling for the generation of specific software applications. Expert Systems with Applications. 2014, vol. 41, iss. 4, part 2, pp. 1864–1874.