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

7.2. Приобретение и поддержка программных приложений

Приведем определение программного приложения из COBIT. Программное приложение (Application program) – компьютерная программа, осуществляющая обработку бизнес-данных, в частности, ввод данных, обновление и запрос. Бизнес-приложение отличается от системных программ (таких как операционная система или программа контроля сети) и от сервисных программ (таких как копирование и сортировка данных)[1] .Разработка и приобретение программных приложений требуют формирования требований к контролю и безопасности, а также обеспечение их соответствия существующим стандартам и требованиям бизнеса. Первостепенными для данного процесса являются результативность и эффективность информации, вторичными – целостность и достоверность. Процесс работает с приложениями в ключевых областях управления ИТ Соответствие стратегии и Полезность. Первостепенное значение имеет результативность и эффективность информации (рис.7.2).

Рис. 7.2. Процесс "Приобретение и поддержка программных приложений"

Приобретение и поддержка программных приложений

удовлетворяет следующим требованиям к ИТ:

обеспечение соответствия доступных приложений требованиям бизнеса при условиях своевременности и разумных затрат.

сосредоточено на:

своевременном и эффективном с точки зрения затрат процессе разработки

достигается с помощью:

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

результаты оцениваются с помощью следующих показателей:

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

В таблице 7.5 представлена информация, необходимая для процесса и ее источники.

В таблице 7.6 приведены результаты процесса и то, куда они должны поступить.

Таблица 7.7 содержит таблицу ОУКИ для процесса, а таблица 7.8 – цели и показатели.

Цели контроля:

• AI 2.1. Общий дизайн приложений

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

  Подготовить детальный дизайн приложений и технические требования к программному обеспечению. Определить критерии приемки этих требований. Утвердить требования, чтобы гарантировать их соответствие общему дизайну приложений. Провести пересмотр дизайна в случае существенных технических и логических несоответствий, выявленных в процессе разработки и эксплуатации.
• AI 2.3. Меры контроля приложений и проверяемость

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

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

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

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

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

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

  Отслеживать статус конкретных требований в процессе проектирования, разработки, внедрения, проводить утверждение требований в соответствии с установленным процессом управления изменениями.
• AI 2.10. Поддержка приложений

  Разработать стратегию и план поддержки приложений

Рассмотрим процесс на примере издательства из предыдущего пункта. Допустим, CEO решил, что издательство не будет покупать систему на стороне, а создаст ее силами собственных программистов. Прежде чем они начнут создавать код, архитектор (или руководитель проекта) должен определить высокоуровневые аспекты дизайна, которые впоследствии очень трудно изменить (и даже невозможно):

• язык программирования, который будет использован (например,C или Java);
• модель распределения (например, браузер, сервер приложений и база данных);
• …

При этом архитектор должен обратиться к процессу "Определение направления технологического развития" для того, чтобы выяснить, какие технологические стандарты используются в организации. Если принято использовать C, то он не должен использовать Java в этом проекте. После определения всех технологических требований и функционала программисты начинают создавать код. Необходимо предусмотреть контроль качества. Для этого CIO должен:

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

Это процедуры оценки всей системы. Хорошо было бы предусмотреть проверку качества отдельных компонентов системы и их взаимосвязей. Для этого необходимо:

• нанять хороших разработчиков и правильно управлять ими;
• часто проверять дизайн (например, пересматривать код);
• осуществлять автоматическое тестирование отдельных компонентов.

Основная идея в том, что для того, чтобы вся система была качественной, ее отдельные компоненты также должны быть качественными.

Будут ли инвесторы довольны, если их первоначальные требования будут выполнены? Нет. Они будут довольны, когда увидят реальную прибыль от проекта или решение какой-то проблемы. Поэтому при проектировании системы необходимо всегда за технологическими требованиями видеть требования бизнеса. Например:

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

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

Чтобы решить эту проблему, CIO необходимо:

• убедиться, что менеджер проектов правильно определил "добавленную" стоимость и время. Если требование заменяет другое требования или не требует значимых трудовых затрат, оно может не учитываться;
• донести до инвестора (или другого лица, принимающего решение) о дополнительных временных и стоимостных затратах. Инвестор должен принять окончательное решение о необходимости выполнения изменения.

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

Когда пользователи начнут работать с системой, появятся пожелания о доработках - мелких (увеличить кнопку "login") и крупных (поддержка e-book). Вы, как CIO, должны будете взаимодействовать с инвесторами, чтобы определить необходимость доработок и расставить приоритеты.

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