Опубликован: 12.11.2012 | Доступ: свободный | Студентов: 1828 / 318 | Длительность: 18:27:00
Лекция 7:

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

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 7.5.
Источник Входящая информация
PO 2 Справочник данных, схема классификации данных, оптимизированный план бизнес-систем
PO 3 Регулярные обновления состояния технологий, технологические стандарты
PO 5 Отчеты о затратах и выгодах
PO 8 Стандарты в области приобретения и разработки
PO 10 Рекомендации по управлению проектами и детальные планы проектов
AI 1 ТЭО
AI 6 Описание процесса внесения изменений

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

Таблица 7.6.
Результаты В процессы
Спецификации мер контроля безопасности приложений DS 5
Знания в области приложений и программных пакетов AI 4
Решения по закупкам AI 5
Первоначально запланированные соглашения об уровне сервиса DS 1
Спецификация по доступности, непрерывности и восстановлению DS 3 DS 4

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

Таблица 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, должны будете взаимодействовать с инвесторами, чтобы определить необходимость доработок и расставить приоритеты.

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

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >
Максим Цапко
Максим Цапко

Я наконец закончил курс "Управление ИТ-проектами". Как получить документ об окончании курса.

Дмитрий Лобанов
Дмитрий Лобанов

Управление ИТ на основе COBIT 4.1

: в перечне литературы, п.15 - отсутствует документ по ссылке https://www.rusonyx.ru/support/agreements/

Алексей Янов
Алексей Янов
Россия, Москва, МГТУ им Н.Э.Баумана, 2002
Сергей Уткин
Сергей Уткин
Россия