UNIVERSIDAD AGRARIA DEL ECUADOR

FACULTAD DE CIENCIAS AGRARIAS ESCUELA DE COMPUTACIN E INFORMTICA Electiva Profesional III COBIT 4.1: Adquirir e implementar
INTEGRANTES: LIGA XAVIER MENDOZA SUGEY

 AI1: AI2: AI3:

Identificar soluciones automatizadas

Adquirir y mantener software aplicativo

Adquirir y mantener infraestructura tecnolgica

DESCRIPCIN DEL PROCESO.

Definicin Enfoque Qu se Logra?

Que se Mide?

Este proceso cubre la definicin de las necesidades, considera las fuentes alternativas, realiza una revisin de la factibilidad tecnolgica y econmica, ejecuta un anlisis de riesgo y de costo-beneficio y concluye con una decisin final de desarrollar o comprar.

La identificacin de soluciones tcnicamente factibles y rentables

La definicin de los requerimientos tcnicos y de negocio Realizar estudios de factibilidad como se define en los estndares de desarrollo Aprobar (o rechazar) los requerimientos y los resultados de los estudios de factibilidad

Nmero de proyectos donde los beneficios establecidos no se lograron debido a suposiciones de factibilidad incorrectas Porcentaje de estudios de factibilidad autorizados por el dueo del proceso Porcentaje de usuarios satisfechos con la funcionalidad entregada

OBJETIVOS DE CONTROL.

Definicin y Mantenimiento de los Requerimientos Tcnicos y Funcionales del Negocio

Identificar, dar prioridades, especificar y acordar los requerimientos de negocio funcionales y tcnicos que cubran el alcance completo de todas las iniciativas requeridas para lograr los resultados esperados de los programas de inversin en TI.

Reporte de Anlisis de Riesgos

Identificar, documentar y analizar los riesgos asociados con los requerimientos del negocio y diseo de soluciones como parte de los procesos organizacionales para el desarrollo de los requerimientos.

OBJETIVOS DE CONTROL.

Estudio de Factibilidad y Formulacin de Cursos de Accin Alternativos

Desarrollar un estudio de factibilidad que examine la posibilidad de Implementar los requerimientos. La administracin del negocio, apoyada por la funcin de TI, evala la factibilidad y realiza recomendaciones al patrocinador del negocio.

Requerimientos, Decisin de Factibilidad y Aprobacin

Verificar que el proceso requiere al patrocinador del negocio para aprobar y autoriza los requisitos de negocio, tanto funcionales como tcnicos, y los reportes del estudio de factibilidad en las etapas clave predeterminadas.

DIRECTRICES GENERALES. Entradas / Salidas.

AI1 Identificar Soluciones Automatizadas

Desde
PO1 PO3 PO8 PO10 AI6 DS1 DS3 Planes estratgicos y tcticos de TI

Entradas
Actualizaciones peridicas del estado de la tecnologa; estndares tecnolgicos Estndares de adquisicin y desarrollo Directrices de administracin del proyecto y planes detallados del proyecto Descripcin del proceso de cambio SLAs Plan de desempeo y capacidad (requerimientos)

Salidas
Estudio de factibilidad de los requerimientos del negocio P02 P05

Hacia
P07 AI2 AI3 AI4 AI5

Matriz RACI.

Metas y Mtricas
Definir como los requerimientos funcionales y de control del negocio se traducen a soluciones automatizadas y eficientes. Responder a los requerimientos de negocio de acuerdo con la estrategia del negocio. # de proyectos donde se alcanzaron los beneficios establecidos debido a suposiciones incorrectas de factibilidad. % de usuarios satisfechos con la funcionalidad recibida. Identificar soluciones que satisfagan los requerimientos del usuario. Identificar soluciones que sean tcnicamente factibles y rentables. Tomar la decisin de comprar vs desarrollar que optimice el valor y minimice el riesgo.
Definir los requerimientos tcnicos y de negocio. Realizar estudios de factibilidad como se define en los standares de desarrollo. Considerar los requerimientos de seguridad y control desde el principio. Aprobar o rechazar los requerimientos y los resultados del estudio de factibilidad.

% de interesados satisfechos con la precisin del estudio de factibilidad. Grado en que la definicin de los beneficios cambia desde el estudios de factibilidad hasta la implantacin. % de portafolio aplicativo que no es consistente con la arquitectura. % de estudios de factibilidad entregados a tiempo y en

% de proyectos en el plan anual de TI sujetos a un estudio de factibilidad. % de estudios de factibilidad autorizados por el dueo del proceso del negocio.

MODELO DE MADUREZ.
0 No Existente cuando
La organizacin no requiere de la identificacin de los requerimientos funcionales y operativos para el desarrollo, implantacin o modificacin de soluciones, tales como sistemas, servicios, infraestructura y datos.

1 Inicial / Ad Hoc cuando

Existe conciencia de la necesidad de definir requerimientos y de identificar soluciones tecnolgicas. Grupos individuales se renen para analizar las necesidades de manera informal y los requerimientos se documentan algunas veces

2 Repetible pero Intuitivo cuando

Existen algunos enfoques intuitivos para identificar que existen soluciones de TI y stos varan a lo largo del negocio.

5 Optimizado cuando
La metodologa para la identificacin y evaluacin de las soluciones de TI est sujeta a una mejora continua. La metodologa de adquisicin e implantacin tiene la flexibilidad para proyectos de grande y de

4 Administrado y Medible cuando

Los requerimientos estn bien articulados y de acuerdo con las estructuras predefinidas. Se consideran soluciones alternativas, incluyendo el anlisis de costos y beneficios

3 Definido cuando
El enfoque para la determinacin de las soluciones de TI requiere la consideracin de alternativas evaluadas contra los requerimientos del negocio o del usuario, las oportunidades tecnolgicas, la factibilidad

DESCRIPCIN DEL PROCESO.

Definicin

Este proceso cubre el diseo de las aplicaciones, la inclusin apropiada de controles aplicativos y requerimientos de seguridad, y el desarrollo y la configuracin en s de acuerdo a los estndares. Esto permite a las organizaciones apoyar la operatividad del negocio de forma apropiada con las aplicaciones automatizadas correctas.

Enfoque
Qu se Logra? Que se Mide?

Garantizar que exista un proceso de desarrollo oportuno y confiable

La traduccin de requerimientos de negocio a especificaciones de diseo La adhesin a los estndares de desarrollo para todas las modificaciones La separacin de las actividades de desarrollo, de pruebas y operativas

Nmero de problemas en produccin por aplicacin, que causan tiempo perdido significativo Porcentaje de usuarios satisfechos con la funcionalidad entregada

OBJETIVOS DE CONTROL.

Diseo de Alto Nivel

Traducir los requerimientos del negocio a una especificacin de diseo de alto nivel para la adquisicin de software, teniendo en cuenta las directivas tecnolgicas y la arquitectura de informacin dentro de la organizacin. Tener aprobadas las especificaciones de diseo por gerencia para garantizar que el diseo de alto nivel responde a los requerimientos. Reevaluar cuando sucedan discrepancias significativas tcnicas o lgicas durante el desarrollo o mantenimiento.

Diseo Detallado
Preparar el diseo detallado y los requerimientos tcnicos del software de aplicacin. Definir el criterio de aceptacin de los requerimientos. Aprobar los requerimientos para garantizar que corresponden al diseo de alto nivel. Realizar reevaluaciones cuando sucedan discrepancias significativas tcnicas o lgicas durante el desarrollo o mantenimiento.

OBJETIVOS DE CONTROL.

Control y Posibilidad de Auditar las Aplicaciones

Implementar controles de negocio, cuando aplique, en controles de aplicacin automatizados tal que el procesamiento sea exacto, completo, oportuno, autorizado y auditable.

Seguridad y Disponibilidad de las Aplicaciones

Abordar la seguridad de las aplicaciones y los requerimientos de disponibilidad en respuesta a los riesgos identificados y en lnea con la clasificacin de datos, la arquitectura de la informacin, la arquitectura de seguridad de la informacin y la tolerancia a riesgos de la organizacin

Configuracin e Implantacin de Software Aplicativo Adquirido

Configurar e implementar software de aplicaciones adquiridas para conseguir los objetivos de negocio.

OBJETIVOS DE CONTROL.

Actualizaciones Importantes en Sistemas Existentes

En caso de cambios importantes a los sistemas existentes que resulten en cambios significativos al diseo actual y/o funcionalidad, seguir un proceso de desarrollo similar al empleado para el desarrollo de sistemas nuevos.

Desarrollo de Software Aplicativo

Garantizar que la funcionalidad de automatizacin se desarrolla de acuerdo con las especificaciones de diseo, los estndares de desarrollo y documentacin, los requerimientos de calidad y estndares de aprobacin. Asegurar que todos los aspectos legales y contractuales se identifican y direccionan para el software aplicativo desarrollado por terceros.

OBJETIVOS DE CONTROL.

Aseguramiento de la Calidad del Software

Desarrollar, Implementar los recursos y ejecutar un plan de aseguramiento de calidad del software, para obtener la calidad que se especifica en la definicin de los requerimientos y en las polticas y procedimientos de calidad de la organizacin.

Administracin de los Requerimientos de Aplicaciones

Seguir el estado de los requerimientos individuales (incluyendo todos los requerimientos rechazados) durante el diseo, desarrollo e implementacin, y aprobar los cambios a los requerimientos a travs de un proceso de gestin de cambios establecido.

Mantenimiento de Software Aplicativo

Desarrollar una estrategia y un plan para el mantenimiento de aplicaciones de software.

DIRECTRICES GENERALES.

Entradas / Salidas.
AI1 Identificar Soluciones Automatizadas

Desde
PO2 PO3 PO5 PO8 PO10 AI1 AI6

Entradas
Diccionario de datos; esquema de clasificacin de datos, plan optimizado de sistema del negocio
Actualizaciones peridicas del estado de la tecnologa Reporte de costo/beneficio Estndares de adquisicin y desarrollo Directrices de administracin del proyecto y planes detallados del proyecto Estudio de factibilidad de los requerimientos del negocio Descripcin del proceso de cambio

DIRECTRICES GENERALES. Entradas / Salidas. Salidas

Especificacin de los controles de seguridad de la aplicacin Conocimientos de a aplicacin y el paquete de software Decisiones de adquisicin SLAs de planeados inicialmente Especificaciones de disponibilidad, continuidad y recuperacin DS5 AI4 AI5 DS1 DS3 DS4

Hacia

Matriz RACI.

Metas y Mtricas
Definir como los requerimientos funcionales y de control del negocio se traducen a soluciones automatizadas y eficientes. Adquirir y mantener sistemas de aplicacin integrados y estandarizados.
Adquirir y mantener aplicaciones que satisfagan en forma rentable los requerimientos definidos para el negocio. Adquirir y mantener aplicaciones de acuerdo con la estrategia y la arquitectura de TI. Garantizar que el proceso de desarrollo sea oportuno y rentable.
Traducir los requerimientos del negocio a las especificaciones de diseo. Adherirse a los estndares de desarrollo para todas las modificaciones. Priorizar los requerimientos con base en la relevancia del negocio Separar actividades de desarrollo, pruebas y operacin. Aprovechar la inversin en tecnologa existente

% de proyectos que entregan cambios en el negocio en el marco de tiempo requerido # de proyectos donde se alcanzaron los beneficios establecidos debido al deficiente diseo o desarrollo de la aplicacin. % de usuarios satisfechos

% de proyectos de desarrollo a tiempo y dentro del presupuesto. % del esfuerzo de desarrollo que se gasta en mantenimiento de app existentes. # de problemas de produccin por aplicacin que provocan tiempo perdido notorio. Defectos que se reportan por mes.

% de proyectos de SW aplicativo con plan de aseguramiento de calidad del SW desarrollado y ejecutado. % de proyectos de SW aplicativo con revisin y aprobacin adecuadas de la conformidad con los estndares de desarrollo. Tiempo promedio de entrega de la funcionalidad con base en las medidas como puntos funcionales o lneas de cdigo.

MODELO DE MADUREZ.
0 No Existente cuando
No existe un proceso de diseo y especificacin de aplicaciones. Las aplicaciones se obtienen con base en ofertas de proveedores, en el reconocimiento de la marca o en la familiaridad del personal de TI con productos especficos, considerando poco o nada los requerimientos actuales.

1 Inicial / Ad Hoc cuando

Conciencia de la necesidad de contar con un proceso de adquisicin y mantenimiento de aplicaciones. Los enfoques para la adquisicin y mantenimientos de software aplicativo varan de un proyecto a otro. Se tiene poca consideracin hacia la seguridad y disponibilidad de la aplicacin en el diseo o adquisicin de software aplicativo

2 Repetible pero Intuitivo cuando

Existen procesos de adquisicin y mantenimiento de aplicaciones, con diferencias pero similares, en base a la experiencia dentro de la operacin de TI. El mantenimiento es a menudo problemtico y se resiente cuando se pierde el conocimiento interno de la organizacin.

5 Optimizado cuando
Las prcticas de adquisicin y mantenimiento de software aplicativo se alinean con el proceso definido. La metodologa de adquisicin e implantacin de software aplicativo ha sido sujeta a mejora continua y se soporta con bases de datos internas y externas que contienen materiales de referencia y las mejores prcticas.

4 Administrado y Medible cuando

Existe una metodologa formal y bien comprendida que incluye un proceso de diseo y especificacin, un criterio de adquisicin, un proceso de prueba y requerimientos para la documentacin. Existen mecanismos de aprobacin documentados y acordados, para

3 Definido cuando
Este proceso va de acuerdo con la estrategia de TI y del negocio. Las metodologas son por lo general, inflexibles y difciles de aplicar en todos los casos, por lo que es muy probable que se salten pasos. Las actividades de mantenimiento se planean, programan y coordinan

DESCRIPCIN DEL PROCESO.

Definicin Enfoque

Requiere de un enfoque planeado para adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias tecnolgicas convenidas la

disposicin del ambiente de desarrollo y pruebas

Proporcionar plataformas adecuadas para las aplicaciones del negocio, de acuerdo con la arquitectura definida de TI y los estndares de tecnologa El establecimiento de un plan de adquisicin de tecnologa que se alinea con el plan de infraestructura tecnolgica La planeacin de mantenimiento de la infraestructura La implantacin de medidas de control interno, seguridad y adaptabilidad
El porcentaje de plataformas que no se alinean con la arquitectura de TI definida y los estndares de tecnologa El nmero de procesos de negocio crticos soportados por infraestructura obsoleta (o que pronto lo ser) El nmero de componentes de infraestructura que ya no se pueden soportar (o que ya no se podrn en el futuro cercano)

Qu se Logra?
Que se Mide?

OBJETIVOS DE CONTROL.

Plan de Adquisicin de Infraestructura Tecnolgica

Generar un plan para adquirir, Implementar y mantener la infraestructura tecnolgica que satisfaga los requerimientos establecidos funcionales y tcnicos del negocio, y que est de acuerdo con la direccin tecnolgica de la organizacin. Evaluar los costos de complejidad y la viabilidad comercial del proveedor y el producto al aadir nueva capacidad tcnica.

Proteccin y Disponibilidad del Recurso de Infraestructura

Implementar medidas de control interno, seguridad y auditabilidad durante la configuracin, integracin y mantenimiento del hardware y del software de la infraestructura para proteger los recursos y garantizar su disponibilidad e integridad. Definir y comprender claramente las responsabilidades al utilizar componentes de infraestructura sensitivos por todos aquellos que desarrollan e integran los componentes de infraestructura. Se debe monitorear y evaluar su uso.

OBJETIVOS DE CONTROL.

Mantenimiento de la Infraestructura
Desarrollar una estrategia y un plan de mantenimiento de la infraestructura y garantizar que se controlan los cambios, de acuerdo con el procedimiento de administracin de cambios de la organizacin. Incluir una revisin peridica contra las necesidades del negocio, administracin de parches y estrategias de actualizacin, riesgos, evaluacin de vulnerabilidades y requerimientos de seguridad.

Ambiente de Prueba de Factibilidad

Establecer el ambiente de desarrollo y pruebas para soportar la efectividad y eficiencia de las pruebas de factibilidad e integracin de aplicaciones e infraestructura, en las primeras fases del proceso de adquisicin y desarrollo. Considerar la funcionalidad, la configuracin de hardware y software, pruebas de integracin y desempeo, migracin entre ambientes, control de la versiones, datos y herramientas de prueba y seguridad.

DIRECTRICES GENERALES.

Entradas / Salidas.
AI1 Identificar Soluciones Automatizadas

Desde
PO3 PO8 PO10 AI1 AI6 DS3 PO3

Entradas
Plan de infraestructura de tecnologa; estndares y oportunidades, actualizaciones peridicas del estado de tecnologa Estndares de adquisicin y desarrollo Directrices de administracin de proyecto y planes detallados de proyecto Estudio de factibilidad de los requerimientos del negocio Descripcin del proceso de cambio Plan de desempeo y capacidad (requerimientos) Plan de infraestructura de tecnologa; estndares y oportunidades, actualizaciones peridicas del estado de tecnologa

DIRECTRICES GENERALES. Entradas / Salidas. Salidas

Decisiones de adquisicion Sistema configurado para realizar prueba/instalacin Requerimientos de ambiente fsico Actualizaciones de estndares de tecnologa Requerimientos del monitoreo del sistema Conocimiento de la infraestructura OLAs planeadas inicialmente AI5 AI7 DS1 2 PO3 DS3 AI4 DS1

Hacia

Matriz RACI.

Metas y Mtricas
Adquirir y mantener una infraestructura de TI integrada y estandarizada. Optimizar la infraestructura, recursos y capacidades de TI. Desarrollar la agilidad de TI.
Proporcionar las plataformas adecuadas a las aplicaciones del negocio, de acuerdo con los estndares de arquitectura y tecnologa que define TI. Proporcionar una infraestructura de TI confiable y segura.
Producir un plan de adquisicin de tecnologa que est de acuerdo con el plan de infraestructura de tecnologa. Planear el mantenimiento de la infraestructura. Proporcionar infraestructura y ambiente de desarrollo y prueba. Implementar medidas de control interno, seguridad y auditora. # y tipo de modificaciones de emergencia a componentes de la infraestructura. # de solicitudes de adquisicin sobresalientes. Tiempo promedio para configurar los componentes de la infraestructura.

# de procesos de negocio crticos soportados por infraestructura obsoleta (o que pronto lo ser).

% de plataformas que no estn de acuerdo con los estndares de arquitectura y tecnologa que define TI. # de plataformas de tecnologa distintas por funcin en la empresa. % de componentes de la infraestructura adquiridos por fuera del proceso de adquisiciones. % de componentes de infraestructura que no se pueden

MODELO DE MADUREZ.
0 No Existente cuando
No se reconoce la administracin de la infraestructura de tecnologa como un asunto importante al cual deba ser resuelto.

1 Inicial / Ad Hoc cuando

Se realizan cambios a la infraestructura para cada nueva aplicacin, sin ningn plan en conjunto. La actividad de mantenimiento reacciona a necesidades de corto plazo. El ambiente de produccin es el ambiente de prueba.

2 Repetible pero Intuitivo cuando

No hay consistencia entre enfoques tcticos al adquirir y dar mantenimiento a la infraestructura de TI. La adquisicin y mantenimiento de la infraestructura de TI no se basa en una estrategia definida y no considera las necesidades de las aplicaciones del negocio que se deben respaldar.

5 Optimizado cuando
El proceso de adquisicin y mantenimiento de la infraestructura de tecnologa es preventivo y est estrechamente en lnea con las aplicaciones crticas del negocio y con la arquitectura de la tecnologa. La infraestructura de TI se entiende como el apoyo clave para

4 Administrado y Medible cuando

Se desarrolla el proceso a tal punto que funciona bien, se le da un seguimiento consistente y un enfoque hacia la reutilizacin. Tanto el costo como el tiempo de realizacin para alcanzar el nivel esperado de escalamiento, flexibilidad e integracin se han

3 Definido cuando
El proceso de adquirir y dar mantenimiento respalda las necesidades de las aplicaciones crticas del negocio y concuerda con la estrategia de negocio de TI, pero no se aplica en forma consistente.