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

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

Рисунок AI2.1 – Процесс «Приобретение и поддержка программных приложений»

Приобретение и поддержка программных приложений удовлетворяет следующим требованиям к ИТ:

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

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

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

• преобразования требований бизнеса в спецификации разработки;

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

• разделения работ по разработке, тестированию и сопровождению.

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

• число проблем в расчете на приложение, приводящих к ощутимым простоям;

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

На рисунке AI2.2 представлена информация, необходимая для процесса и ее источники.

Рисунок AI2.2 - Входящая информация для процесса

На рисунке AI2.3 приведены результаты процесса и то, куда они должны поступить.

Рисунок AI2.3 - Выходящая информация для процесса

Рисунок AI2.4 содержит таблицу ОУКИ для процесса.

Рисунок AI2.4 - Таблицу ОУКИ для процесса.

В таблице AI2.1 описаны цели и показатели процесса.

Таблица AI2.1 – цели и показатели

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

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

• 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. Поддержка приложений. Разработать стратегию и план поддержки приложений

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

• нанять хороших разработчиков и правильно управлять ими;

• часто проверять дизайн;

• осуществлять автоматическое тестирование отдельных компонентов.

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

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

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

Чтобы решить эту проблему, менеджеру автоматизации необходимо:

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

• донести до инвестора о дополнительных временных и стоимостных затратах. Инвестор должен принять окончательное решение о необходимости выполнения изменения.

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

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

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