UCV Gobierno de TI_Sesion 10

Gobierno de Tecnologías de

Información Facultad de Ingeniería de Sistemas

Sesión 1

Ing. Jesús Valdiviezo Saravia

Gobierno de TI

El Gobierno de las TI es una responsabilidad del más alto nivel directivo y se encuentra en lo más alto de una pirámide que estaría basada en las operaciones de TI y la gestión de TI.

El éxito del Gobierno de las TI va a estar ligado a la comprensión y apoyo que obtenga por parte del Equipo de Dirección. Según la norma internacional ISO 38500, el Gobierno de las TI tiene como principal objetivo evaluar, dirigir y monitorizar las TI para que estas proporcionen el máximo valor posible a la organización.


Gobierno de TI


Gobierno de TI

Un elemento crítico para el éxito y la supervivencia de las organizaciones, es la administración efectiva de la información y de las Tecnologías de la Información (TI) relacionadas.


Gobierno de TI

“El Gobierno de las TI es el sistema a través del cual se dirige y controla la utilización de las TI actuales y futuras. Supone la dirección y evaluación de los planes de utilización de las TI que den soporte a la organización y la monitorización de dicho uso para alcanzar lo establecido en los planes de la organización. Incluye las estrategias y políticas de uso de las TI dentro de la organización.”

• “El Gobierno de las TI debe ocuparse de tres cuestiones:

• 1. Qué decisiones deben tomarse para asegurar la gestión y el uso efectivo de las TI.

• 2. Quienes deben tomar estas decisiones.

• 3. Cómo serán ejecutadas y monitorizadas.”


Gobierno de TI

• “Las ventajas de implementar completamente un sistema de Gobierno de las TI son:

• • Se consigue estrechar la relación entre las áreas directivas y funcionales y el área de TI.

• • Reduce la ineficiencia y los riesgos. • • Aumenta la calidad y la eficiencia de los servicios TI. • • Promueve el uso eficiente de los recursos internos y externos. • • Disminuye los problemas en el desarrollo de los proyectos

(sobrecostes, errores funcionales, retrasos, etc.). • • Promueve que baje la complejidad de las TI y la integración de los

grandes sistemas de la organización. • • Consigue realizar un proceso de planificación estratégica de las TI

más eficiente.”


Gobierno de TI

• Muchas organizaciones reconocen los beneficios potenciales que la tecnología puede proporcionar. Las organizaciones punteras, sin embargo, también comprenden y administran los riesgos asociados con la implementación de nuevas tecnologías.


Gestión de la Calidad de Software


La calidad es relativa a las personas, a su edad, a las circunstancias de trabajo, el tiempo…

FERRARI


Se define la calidad como: “Totalidad de características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implicitas”.

Concepto de Calidad

GESTIÓN DE LA CALIDAD

La consecución de la calidad puede tener tres orígenes: Calidad Realizada: La que es capaz de obtener la persona que realiza el trabajo. Calidad Programada: La calidad que se ha pretendido obtener. Calidad Necesaria: La calidad que el cliente exige con mayor o menor grado de concreción.


,

Cada sistema de producción se calibra y debe producir una y otra vez productos de alta calidad. Sin embargo el software no se manufactura si no se diseña.

El desarrollo de software es un proceso más creativo que mecánico donde la experiencia y habilidades individuales son importantes.

Calidad de proceso y producto

Definir Proceso

Desarrollar Producto

Valorar la calidad del Producto

Mejora el Proceso

Calidad Ok

Estandarizar proceso

SI NO


Las pruebas contribuyen a mejorar la fiabilidad, pero no la garantizan totalmente debido a varios factores:

La especificación puede no reflejar los requisitos de los usuarios. Las pruebas pueden contener errores. Las pruebas pueden suponer patrones de uso que son incorrectos.

Proceso de Mejora del Software


Herramientas de Calidad:

• HERRAMIENTAS BÁSICAS

• HERRAMIENTAS DE GESTIÓN

• HERRAMIENTAS DE CREATIVIDAD

• HERRAMIENTAS ESTADÍSTICAS

• HERRAMIENTAS DE DISEÑO

• HERRAMIENTAS DE MEDICIÓN


Herramientas de Calidad: Básicas

• Diagrama de flujo

• Diagrama causa-efecto

• Diagrama de Pareto

• Hoja de chequeo(Mejora Continua)

• Histograma

• Diagrama de dispersión


Control de Calidad: • Implica vigilar el proceso de desarrollo de software para asegurar

que se siguen los procedimientos de garantía de calidad.

• En el proceso de control de calidad del proyecto se comprueba que las entregas cumplan los estándares definidos.

Existen dos enfoques:

• 1.- Revisiones de la Calidad.- Donde el software, su documentación y los proceso utilizados en su desarrollo sean revisados por un grupo de personas , estas personas se encargan de comprobar que se han seguido los estándares del proyecto y el software.

• 2.- Valoración Automática del Software.-Es en la que el software y los documentos se procesan por algún programa y se compraran con los estándares que se aplican a ese proyecto.


Control de Calidad


Estándares de Documentación: • Los estándares de documentación en un proyecto de software son

documentos muy importantes ya que son la única forma tangible de representar al software y su proceso .

• Los documentos estandarizados tienen una apariencia, estructura y calidad consistente y , por o tanto, son mas fáciles de leer y de comprender.

• Existen tres tipos de estándares de documentación:

• 1.-Estandares del proceso de documentación.- Define el proceso a seguir para la producción del documento.

• 2.-Estandares del documento.- Gobiernan la estructura y presentación de los documentos.

• 3.-Estandares para el intercambio de documentos.- Aseguran que todas las copias electrónicas de los documentos sean compatibles.


Mejora de Procesos de Software: • El proceso de mejora continua es la forma más efectiva de mejora

de la calidad y la eficiencia en las organizaciones. El éxito de cualquier método que actualmente utilizan las organizaciones para gestionar aspectos tales como calidad (ISO 9000), depende del compromiso hacia la mejora de todos los niveles, especialmente de la alta dirección, y permite desarrollar políticas, establecer objetivos y procesos, y tomar las acciones necesarias para mejorar su rendimiento.


ISO 9000: • Un conjunto de estándares internacionales que se puede utilizar en el

desarrollo de un sistema de gestión de calidad en todas las industrias es ISO 9000.

• ISO 9001 es el mas general de estos estándares y se aplica en organizaciones interesadas en el proceso de calidad de diseño, desarrollo y mantenimiento de productos.

• ISO 9001 no es un estándar especifico para desarrollo de software, pero define principios generales que pueden aplicarse al software.


ISO 9126 :

ISO 9126 La versión de la norma ISO 9126-1996 ha sido remplazada por dos estándares relacionados: la ISO 9126-2001 (Calidad del Producto de Software) y la ISO 14598 (Evaluación del Producto de Software). Se propone el modelo de calidad ISO 9126 como una herramienta útil para la evaluación de estos sistemas. El modelo ISO 9126


Puntos Claves:

La gestión de la calidad del software permite señalar si éste tiene un escaso número de defectos y si alcanza los estándares requeridos de mantenibilidad, fiabilidad, portabilidad. Las actividades de la gestión de la calidad comprenden la garantía de la calidad que establece los estándares para el desarrollo de software, la planificación de la calidad y el control de la calidad que comprueba el software con respecto a los estándares definidos. Un manual de calidad organizacional debe documentar un conjunto de procedimientos de garantía de la calidad. Éste puede basarse en los modelos genéricos sugeridos en los estándares ISO 9000. Los estándares de software son importantes para garantizar la calidad puesto que representan una identificación de as mejores practicas. El proceso de control de calidad implica comprobar que el proceso de software y el software a desarrollar concuerdan con estos estándares.


Puntos Claves: Las revisiones de los productos a entregar por e proceso del software incumben

a un equipo de personas os cuales comprobarán que se han seguido los estándares de calidad. Las revisiones son a técnica mas utilizada para valorar la calidad . Las mediciones de software se utilizar para recoger datos cuantitativos acerca de software y sus procesos. Los valores de a métricas de software recogidas se utilizan para hacer inferencias de la calidad del producto y del proceso. Las métricas de calidad del producto son de gran valor para resaltar los componentes anómalos que tienen problemas de calidad. Estos componentes se deberán analizar con mas detalle. No existen métricas de software estandarizadas y aplicables universalmente. Las organizaciones deben seleccionar métricas y analizar mediciones basadas en e conocimiento y circunstancias locales.



Sesión 2



El Modelo COBIT 5 :

COBIT es un marco de gobierno de las tecnologías de información que proporciona una serie de herramientas para que la gerencia pueda conectar los requerimientos de control con los aspectos técnicos y los riesgos del negocio. COBIT permite el desarrollo de las políticas y buenas prácticas para el control de las tecnologías en toda la organización. COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio


EVOLUCIÓN DE COBIT


- Compendio de mejores prácticas aceptadas internacionalmente

- Orientado al gerenciamiento de las tecnologías

- Complementado con herramientas y capacitación

- Gratuito

- Respaldado por una comunidad de expertos.

- En evolución permanente.

- Mantenido por una organización sin fines de lucro, con reconocimiento internacional.

- Mapeado con otros estándares.

- Orientado a Procesos, sobre la base de Dominios de Responsabilidad.

COBIT HOY


COBIT contribuye a reducir las brechas existentes entre los objetivos de negocio, los beneficios, riesgos, necesidades de control y aspectos técnicos propios de los proyectos y operaciones de TI. El marco referencial conceptual de la metodología COBIT proporciona una visión integral, capaz de responder a las necesidades de directivos, usuarios claves de TI y auditores (internos y externos).

Marco de Referencia: Principios, Dominios y procesos de TI.

EVOLUCIÓN DE COBIT


OBJETIVOS:

COBIT 5: bienvenido a la familia…


COBIT 5 – La nueva versión

• COBIT 5 es producto de la mejora estratégica de ISACA( Information Systems Audit and Control Association) impulsando la próxima generación de guías sobre el Gobierno y la Administración de la información y los Activos Tecnológicos de las Organizaciones.(Organizacion lider en Auditoria de Sistemas y Seguridad de los Activos de Informacion.)

• Construido sobre más de 15 años de aplicación práctica, ISACA desarrolló COBIT 5 para cubrir las necesidades de los interesados, y alinearse a las actuales tendencias sobre técnicas de gobierno y administración relacionadas con la TI


OBJETIVOS:

Describir cómo la gestión de TI afecta a la organización. Comprender la necesidad de un marco de control del gobierno de TI. Relacionar cómo COBIT cumple los requerimientos del marco de gobernabilidad requerido por TI. Comprender cómo COBIT se relaciona con otros estándares y buenas prácticas.


COBIT 5 – Integra los anteriores marcos referenciales de ISACA

• Val IT es un marco de referencia de gobierno que incluye principios rectores generalmente aceptados y procesos de soporte relativos a la evaluación y selección de inversiones de negocios de TI

• Risk IT es un marco de referencia normativo basado en un conjunto de principios rectores para una gestión efectiva de riesgos de TI.

• BMIS (Business Model for Information Security) una aproximación holística y orientada al negocio para la administración de la seguridad informática

• ITAF (IT Assurance Framework) un marco para el diseño, la ejecución y reporte de auditorias de TI y de tareas de evaluación de cumplimiento.


COBIT 5 – El marco

• La publicación inicial, define y describe los componentes que forman el Marco COBIT

– Principios

– Arquitectura

– Facilitadores

– Guía de implementación

– Otras publicaciones futuras de interés



Marco Integrador

Conductores de valor para los Interesados

Enfoque al Negocio y su Contexto para toda la organización

Fundamentado en facilitadores

Estructurado de manera separada para el Gobierno y la Gestión

COBIT 5 – Sus principios



COBIT 5 – Su Arquitectura



Objetivo de Gobierno




Service

Capabilities

Processes

Culture,

Ethics,

Behaviour

Organisational

Structures

InformationPrinciples &

Policies

Skills &

Competencies

Cultura, Ética y Comportamiento

Estructura Organizacional

Información

Principios Políticas

Habilidades y Competencias

Capacidad de brindar Servicios

Procesos

Fundamentación de Facilitadores



COBIT 5 Familia de Productos– La guia detallada de procesos aún esta aquí



Guia de Referencia de Procesos

• Una publicación independiente que desarrolla el modelo de facilitadores de los procesos



Procesos de Gobierno Permite que las múltiples partes interesadas tengan una lectura organizada del análisis de opciones, identificación del norte a seguir y la supervisión del cumplimiento y avance de los planes establecidos

Procesos de Gestión Utilización prudente de medios (recursos, personas, procesos, practicas) para lograr un fin específico

Procesos de Gobierno y Gerenciamiento



Sesión 3




Sesión 3




Qué es Riesgo?



Métodos de análisis e identificación de riesgos y

controles.

Para poder realizar una eficaz labor preventiva es fundamental realizar una precisa identificación de todos y cada uno de los riesgos que existen en el entorno que se quiere mejorar.



Gestión de Riesgos.

La gestión de riesgos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes con las que se enfrentan muchos. Estas incertidumbres son el resultado de los requerimientos que no han sido definidos claramente. Es preciso anticiparse a los riesgos, comprender el impacto de éstos en el proyecto, en el sistema y en el negocio, y considerar los pasos para evitarlo. En el caso de que ocurran, se deben generar planes de contingencia para que se posible aplicar acciones de recuperación



Proceso de Gestión de Riesgos

Comprende los riesgos con los que enfrenta el sistema, descubriendo sus causas fundamentales y generando los requerimientos para gestionar dichos riesgos. El proceso comprende de las siguientes etapas:

Descripción de riesgos

Identificación de Riesgos

Análisis y clasificación de

riesgos

Descomposición de riesgos

Valoración de la reducción de

riesgos


Análisis de las causas raíz

Requerimientos de confiabilidad

http://www.youtube.com/watch?v=jnoIca7oKAs http://www.youtube.com/watch?v=m7bnF7XkqnU http://www.youtube.com/watch?v=m7bnF7XkqnU

http://www.youtube.com/watch?v=jnoIca7oKAs









http://www.youtube.com/watch?v=m7bnF7XkqnU

http://www.youtube.com/watch?v=m7bnF7XkqnU



Etapa 1: Identificación de Riesgos

El objetivo de la identificación de riegos, es identificar los riegos con los que el sistema tiene que tratar. Esto puede ser un proceso difícil y complejo debido a que en ocasiones los riesgos aparecen como consecuencia de interacciones entre el sistema y condiciones inesperadas del entorno.

Los riesgos principales son las contingencias que provocan accidentes. Se puede abordar el problema de identificación de contingencias considerando las diferentes clases de contingencias físicas, eléctricas, biológicas, radiactivas, de fallo de servicio. Los riesgos relacionados con el software normalmente se asocian a fallos en la ejecución un servicio del sistema o con el fallo de sistemas de monitorización y protección.



Etapa 2: Análisis y clasificación de riesgos

Comprende la probabilidad de que surja un riesgo y las consecuencias potenciales que tendrían lugar si se produce un accidente o incidente asociado a ese riego. Para cada riesgo, el resultado del proceso de análisis y clasificación de riesgos es una decisión de aceptación. Los riesgos pueden clasificarse de tres formas: Intolerable Tan Bajo como razonablemente práctico Aceptable




Intolerable.- El sistema debe diseñarse de tal forma que el riesgo no pueda ocurrirse, o si ocurre que no provoque un accidente. Tan Bajo como razonablemente práctico.- El sistema debe diseñarse para que a probabilidad de que ocurra un accidente debido a la contingencia se minimice. Aceptable .- Los diseñadores y/o desarrolladores deberían realizar todos los posibles pasos para reducir la probabilidad de ocurrencia de una contingencia . Estos pasos no deberían incrementar los costes y tiempos de entrega.

El riesgo no puede tolerarse

Riesgo tolerado sólo si la reducción del riesgo no es practica o es excesivamente cara

Región aceptable

Riesgo despreciable

Región ALARP

as low as reasonably practicable



Etapa 3: Descomposición de riesgos

Es e proceso de descubrir las causas fundamentales de los riegos de un sistema particular. Las técnicas para descomposición de riegos se ha derivado principalmente del desarrollo de sistemas de seguridad críticos en los que el análisis de contingencias es una parte central de proceso de seguridad. Técnica de análisis de árbol de defectos. Esta técnica fue desarrollada para sistemas de seguridad críticos. El análisis del árbol de defectos implica identificar eventos no deseados y trabajar hacia atrás a partir de ese evento para descubrir las posibles causas de la contingencia. Se debe poner la contingencia como raíz del árbol e identificar los estados que puedan conducir a la dicha contingencia




A continuación, para cada uno de estos riesgos , se identifican los estados o causas que pueden conducir a que el acontecimiento ocurra, se realiza la descomposición hasta que se identifiquen las causas de raíz del riesgo. Los estados se pueden unir mediante símbolos <<and>> y <<or>>



Etapa 4: Valoración de a reducción de riesgos

Una vez que se han identificado los riesgos potenciales y sus causas, se deberían obtener los requerimientos de confiabilidad del sistema que gestionan los riesgos y aseguran que no ocurran incidentes. Hay tres posibles estrategias que pueden usarse: Evitación de riesgos.- El sistema se diseña para que el riesgo o la contingencia no pueda ocurrir. Detección y eliminación de riesgos.- El sistema se diseña para que los riesgos se detecten y neutralicen antes de que provoquen un accidente. Limitación del daño.- El sistema se diseña para que las consecuencias de un accidente se minimicen.

Auditoría de Sistemas

Es un examen que se realiza con carácter objetivo, crítico, sistemático y selectivo con el fin de evaluar la eficacia y eficiencia del uso adecuado de los recursos informáticos, de la gestión informática y si estas han brindado el soporte adecuado a los objetivos y metas del negocio.



• Tiene como objetivo verificar la calidad de los sistemas de información de la organización y proponer mejoras de los mismos, coherentes con el proyecto de calidad adoptado por la organización (cumplimiento de normas de calidad o modelo de excelencia en gestión).



La auditoría de sistemas de información persigue propiciar con sus actuaciones:

• El establecimiento y mantenimiento de sistemas de gestión de la seguridad.

• La reducción de los riesgos inherentes a la utilización de los sistemas informáticos.

• El incremento de la confianza de los usuarios internos y externos en los sistemas de información.


• Para hacer una planeación eficaz, lo primero que se requiere es obtener información general sobre la organización y sobre la función de informática a evaluar. Para ello es preciso hacer una investigación preliminar y algunas entrevistas previas, con base en esto planear el programa de trabajo, el cual deberá incluir tiempo, costo, personal necesario y documentos auxiliares a solicitar o formular durante el desarrollo de la misma.



Planificación


Qué auditar:

• Cumplimiento de requerimientos legales

• Sensibilidad de la organización a riesgos / resultado de análisis

• Resultado de auditorías anteriores

• Condicionantes de la Organización

Cuándo auditar:

• Priorizar las actuaciones detectadas y ajustando el alcance a los recursos disponibles y las demandas de la dirección

• Elaborar el documento de planificación periódica de la unidad de auditoría

• Revisión periódica del plan inicial para incorporar actuaciones no previstas

Cómo auditar

• Proceso para planificar las actuaciones individuales

Proceso de Auditoria de Sistemas


Proceso de Auditoria de Sistemas




Sesión 4


Gerencia de Sistemas de Información


QUE ES UN SISTEMA?

Un conjunto de elementos dinámicamente relacionados formando una actividad para alcanzar un objetivo, operando sobre datos, energía, materia para proveer información.

QUE ES INFORMACION?

Es un conjunto organizado de datos procesados, que constituyen un mensaje sobre un determinado ente o fenómeno.





En un mundo globalizado, la tecnología de la información ha tomado mayor importancia en las empresas ante la creciente competitividad.

El éxito en los negocios depende en gran medida de la toma de decisiones acertadas y para esto se hace necesario contar con la mayor cantidad de información posible

Las empresas ya no pueden pensar en tener centros de cómputo como hace una década, los cuales se dedicaban sólo a digitar información, ahora se necesita que esta información pueda analizarse, entenderse y utiizarse en la toma de decisiones empresariales.

Planeación Estratégica de Sistemas de información


Los sistemas de información brindan grandes oportunidades para crear ventajas competitivas, para cambiar la manera como una empresa compite, o para innovar los procesos de una organización.

La realización de un Plan de Sistemas de Información dentro de cualquier organización, tiene como finalidad asegurar la adecuación entre los objetivos estratégicos de la misma y la información necesaria para soportar dichos grandes objetivos. Esto hace que una metodología de planificación de sistemas abarque a toda la organización y exige tener en cuenta una serie de conceptos, en cuanto a planificación deestrategias, que desbordan el marco específico de una metodología de desarrollo de sistemas.



Una estrategia es un conjunto de decisiones que se toman con miras a lograr algo (un objetivo).

En el caso de una organización, una estrategia a largo plazo es lo que permite lograr la visión de la organización en un futuro. Esta estrategia es el resultado de una serie de decisiones sobre su alcance, competencias y manejo:

El Alcance del Negocio está asociado con decisiones que determinan dónde va a competir la empresa, e implica contestar ¿qué productos o servicios va a producir?, ¿en qué nichos?, ¿para qué clientes? y ¿en qué zonas geográficas?



• Uno de los objetivos de la adecuada aplicación de tecnología en la organización consiste en obtener ventajas estratégicas que sean difíciles de imitar; es decir, en lograr que la infraestructura y los procesos organizacionales (¿cómo? y ¿con qué?) apoyen la estrategia (¿qué? ¿dónde? ¿Porqué?) de la empresa.

• Estas ventajas estratégicas se traducirán en ventajas competitivas hacia el exterior si ellas contribuyen a dar mayor valor a los productos o servicios en relación a la competencia.

• Usar tecnología para obtener ventajas estratégicas implica instrumentar

estrategias que refuercen los factores críticos de éxito (¿con qué?) y las "competencias centrales" del negocio (¿cómo?).



Las fases propuestas para la redacción de un plan de estratégico sistemas son:

1. Determinar la estrategia y contexto actual de la organización 2. Identificar los requisitos de negocio para los sistemas de información 3. Determinar el estado actual de los sistemas de información 4. Análisis de los sistemas de información 5. Definir la estrategia y plan de sistemas de información 6. Desarrollar el programa de despliegue

Estrategia de Tecnologías de Información.


1. Determinar la estrategia y contexto actual de la organización La primera fase del proyecto consiste en asegurar que cubrirá de manera efectiva las necesidades de la organización, y conocer esta suficientemente para poder determinar posteriormente sus requisitos de los sistemas de información. 2. Identificar los requisitos de negocio para los sistemas de información La segunda fase del proyecto, una vez identificado el contexto y la estrategia de la organización, es determinar cuáles son los requisitos concretos de negocio a los que pueden contribuir los sistemas de información. Para identificar dichos requisitos con una visión amplia y estratégica, deben revisarse las necesidades del negocio desde varios niveles del análisis. Moviéndonos del nivel más estratégico al más centrado en la organización tenemos, los siguientes modelos de análisis: Modelo DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades) Requisitos de contexto y operativos Modelo de componentes de negocio En este resumen se detalla el modelo de componentes de negocio, por ser probablemente el menos conocido en cuanto a determinación de requisitos de negocio.



3. Determinar el estado actual de los sistemas de información Una vez se ha revisado el negocio y se han obtenido sus requisitos, la siguiente fase es determinar el estado actual de los sistemas de información, para poder analizar posteriormente la efectividad del soporte ofrecido. La determinación del estado de los sistemas de información debería realizarse respecto a sus tres aspectos básicos, que son: Estado de la infraestructura técnica Estado de las aplicaciones Estado de la organización y de los procesos



4. Análisis de los sistemas de información Una vez conocidos los requisitos que el negocio demanda de los sistemas de información y determinado el estado actual de estos, se debe realizar su análisis para identificar cuáles son los puntos fuertes a mantener y las debilidades a mejorar. Para ello puede realizarse un análisis a los siguientes cuatro niveles: Análisis estratégico de los sistemas de información Benchmarking de las prácticas de la competencia y del estado de la industria IT Soporte ofrecido a los compontes de negocio Evaluación de coste/beneficio de las aplicaciones y los sistemas El análisis identificará acciones de mejora, determinadas en base a las oportunidades de mejora identificadas anteriormente, y se agruparan en los tres aspectos de los sistemas de información anteriormente vistos: Aplicaciones Infraestructura Organización y procesos



5. Definir la estrategia y plan de sistemas de información La última fase de un proyecto de planificación estratégica de sistemas es la definición de la estrategia y plan de sistemas. En base a las necesidades estratégicas, se identificarán los objetivos estratégicos y bajo estos se agruparán las acciones de mejora identificadas y cualificadas.



5. Definir la estrategia y plan de sistemas de información



6. Desarrollar el programa de despliegue Una vez finalizado y aprobado el plan estratégico de sistemas, se debe desplegar y

ello se planifica y gestiona de manera similar a cualquier otro programa o proyecto grande. El primer paso es lanzar el proyecto, obteniendo la aprobación de un miembro de la dirección con la autoridad necesaria para comprometer los recursos necesarios para su ejecución. Habitualmente suele ser el director de sistemas de información u otro ejecutivo.

Políticas


ALCANCE Las prácticas y lineamientos de Seguridad de la información de esta Política están orientadas a proteger en todo momento y circunstancia, los datos e información

contra los riesgos de robo, divulgación, acceso no autorizado, modificación, pérdida, interrupción o mal uso, producidas en forma intencional o accidental.

Las siguiente practicas que podemos aplicar son: a) Analizar y evaluar los riesgos de seguridad a los que está expuesta cada Unidad Administrativa para que la organización determine los niveles de riesgos permitidos y las estrategias de protección a seguir. b) Desarrollar las Normas, Prácticas y Estándares de Seguridad de la Información que deberá adoptar la dependencia para la protección de los activos de información, su confidencialidad, integridad y disponibilidad. c) Coordinar y evaluar iniciativas, proyectos y planes institucionales de Seguridad de la Información de la organización, así como crear y fomentar una cultura de trabajo orientada a la protección de la información. d) Adoptar las mejores prácticas y en su caso certificar, asegurar y soportar la implantación de las normas y estándares institucionales de Seguridad de la Información en cada Unidad Administrativa.



Videos


http://www.youtube.com/watch?v=v2HGIMITrgU Sistema de Información Gerencial

http://www.youtube.com/watch?v=pZ9YdAVw5kQ Toma de decisiones

http://www.youtube.com/watch?v=v2HGIMITrgU

http://www.youtube.com/watch?v=pZ9YdAVw5kQ



Sesión 5


CMMI


¿Qué es CMMI? CMMI (Capability Maturity Model Integration) Modelo Integrado de Madurez de la Capacidad

Áreas de Proceso


Un proceso… • Agrupa una serie de actividades o acciones, que realizamos sobre unas

entradas, para conseguir generar una salida acorde a nuestros objetivos. • Un proceso incluye Técnicas, Materiales, Herramientas y Personas. Las Áreas de Proceso de CMMI representan un conjunto de actividades que nos facilitan el camino de la mejora, nos marcan los objetivos a cumplir.

Áreas de Proceso


Áreas de Proceso


EJEMPLO:

OBJETIVOS DE CMMI


OBJETIVOS DE CMMI


Algunos de los objetivos del CMMI y que son buenos para el negocio.

Producir servicios y Productos de alta calidad. Crear valor para los accionistas. Mejorar la satisfacción del cliente. Incrementar la participación en el mercado. Ganar reconocimiento en la industria.

Representaciones


El CMMI tiene dos representaciones: Por Etapas (Staged) Continuo (Continuous) Estas representaciones permiten a la organización perseguir diferentes objetivos de mejora. La presentación y organización de la información es diferente para cada una, sin embargo el contenido es el mismo.

Representaciones


Representación por Etapas Ofrece un método estructurado y sistemático de mejoramiento de procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la organización se asegura de contar con una infraestructura robusta en términos de procesos para optar a alcanzar el nivel siguiente. Una organización puede ser certificada bajo un nivel de madurez, un nivel de madurez esta compuesto por áreas de procesos.

Representación Continua Se focaliza en la mejora de un proceso o un conjunto de ellos relacionados estrechamente a un área de proceso en que una organización desea mejorar, por lo tanto una organización puede ser certificada para un área de proceso en cierto nivel de capacidad.



Sesión 6


De dónde surgió la iniciativa CMMI ?


El éxito y la amplia aceptación en el mundo desarrollado de CMM

para software, inspiró el desarrollo de modelos similares en

otras disciplinas relacionadas con la ingeniería.

La proliferación de modelos se prestó a confusiones, lo que

llevó al desarrollo de CMMI, Capability Maturity Model Integration Model.

Estructura del modelo CMMI


A diferencia de CMM(Capability Maturity Model for Software), que

sólo tiene representación por niveles, CMMI tiene dos

representaciones: 1) Por niveles, 2) Continua.

La representación por niveles es similar a la de CMM. Son cinco

niveles, cada uno de los cuales contiene PA’s (Process Areas. En

CMM se denominan Key Process Areas).

Las organizaciones pueden optar por una u otra representación.

CMMI por Etapas


Da una secuencia probada para la mejora en donde cada una es base para la siguiente. Se puede migrar fácilmente del CMMI a CMMI-SW.

Niveles de Madurez (por Etapas)


CMMI (por Etapas)


CMMI (por Etapas)


CMMI (por Etapas)


CMMI Continuo


Cada nivel de madurez es una plataforma bien definida para evolucionar la mejora.

Existen cinco niveles de madurez.

Cada nivel es una base para la mejora utilizando una secuencia probada desde sus bases.

Niveles de Madurez (Continuo)


CMMI (Continuo)


CMMI (Continuo)


CMMI (Continuo)


Metas y Prácticas.


Metas específicas. Una meta específica describe las características únicas que deben estar presentes para satisfacer el área de proceso. Metas genéricas. Las metas genéricas se denominan “genéricas” porque la misma declaración de la meta se aplica a múltiples áreas de proceso. Prácticas genéricas. Las practicas genéricas ayudan a institucionalizar en la organización las prácticas establecidas en cada una de las áreas de proceso.

¿Cuál Seleccionar?


Continuo Nos centramos en los problemas, mitigación de riesgos y en lo que le interesa a los objetivos de la organización. Permite la comparación entre áreas de proceso. Permite una comparación contra el modelo ISO 15504.

Por Etapas Provee una secuencia de las mejoras desde la administración básica hasta niveles de alta madurez. Permite al comparación entre organizaciones por los niveles de madurez. Provee un solo indicador que permite la comparación entre organizaciones.



Sesión 7


ITIL


ITIL fue desarrollado debido a que se vio la necesidad de estandarizar las prácticas de gestión de tecnologías de información inicialmente en las empresas estatales de reino unido pero con el pasar del tiempo fue adoptado por empresas de todo el mundo.

ITIL.- No es una metodología, no da instrucciones, ni asigna tareas a las

personas, no propone una estructura organizacional.


ITIL


ITIL es un sumario de las mejores prácticas en cuanto gestión de tecnologías de la informática y telecomunicaciones que nació de observar que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos y que como resultado se ve la necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, que satisfagan los requisitos y las expectativas del cliente.

ITIL


La 1era versión de ITIL creada a finales de 1980 era un sumario de 10 libros con recomendaciones sobre la gestión de TI entre los años posteriores hasta 1999 este sumario de libro llego hasta 31 libros con la creación y publicación, que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. A partir de 1999 y hasta el 2003 se realizo el proceso de agrupar e integrar los libros según unos conjuntos lógicos destinados a tratar los procesos de administración, con ello se logra que diversos aspectos de los sistemas de TIC, se presentaran en conjuntos temáticos dando paso a lo que se denomino la versión 2 de ITIL. En junio de 2007 se realizo la publicación de la versión 3 de ITIL que consta de 5 libros.

ITIL


La Biblioteca de Infraestructura de Tecnologías de Información, abreviada ITIL (InformationTechnologyInfrastructure Library), es un marco de trabajo de las mejores prácticas recomendables, coherentes y globales destinadas a facilitar la entrega y gestión de servicios de tecnologías de la información. ITIL describe lo que se debe hacer pero no el cómo se hace. Es un conjunto de mejores prácticas para la dirección y gestión de servicios de tecnologías de la información en lo referente a Personas, Procesos y Tecnología.

ITIL


¿Qué es una buena práctica? Es un conjunto de guías y consejos basadas en las mejores experiencias de los profesionales más experimentados y calificados en un campo en particular.

En este caso es el área de Tecnología de Información. ¿Qué es gestión de servicios de TI? Es una disciplina basada en procesos, enfocada en alinear los servicios de TI proporcionados con las necesidades de las empresas, poniendo énfasis en los beneficios que puede percibir el cliente final.

ITIL


A través de las Mejores Prácticas especificadas en ITIL se hace posible para departamentos y organizaciones reducir costos, mejorar la calidad del servicio tanto a clientes externos.

ITIL v3


La edición de estos libros de ITIL más actual es la tercera; que salió a mediados del 2007.ITIL v3 consta de 5 libros basados en el ciclo de vida del servicio: 1. Estrategia del Servicio 2. Diseño del Servicio 3. Transición del Servicio 4. Operación del Servicio 5. Mejora Continua del Servicio

Estructura de ITIL


Estructura de ITIL


Planificación para la implementación de servicios de gestión. Su objetivo es asegurar el correcto paralelismo de las TI con las necesidades reales del negocio, permitiendo que el uso de éstas facilite el progreso del negocio. De esta manera se evita perdida de horas productivas, costos más elevados, y que haya un menor número de ventas.

Perspectiva del negocio Definición de las directrices y consejos para ayudar a entender como estos aspectos pueden contribuir a conseguir los objetivos de negocio y como se pueden mejorar los servicios para que se adapten mejor al negocio y maximizar de este modo su contribución en el negocio. Dirigida a profesionales que se dedican a gestionar y/o dirigir proyectos.

Estructura de ITIL


Gestión de infraestructuras de TI La función de la gestión de la infraestructura de TI es gestionar y controlar los eventos relacionados con la gestión de la infraestructura de telecomunicaciones. Se encarga de los procesos de Diseño y planificación, Soporte técnico y Operaciones de despliegue. Es la responsable de todos los estados en los que se encuentre la infraestructura a nivel técnico: Expansión, diseño y desarrollo y servicio final.

Estructura de ITIL


Gestión de Aplicaciones Es el conjunto que engloba todo el ciclo de vida de una aplicación. Este ciclo de vida está compuesto primero por la administración de Aplicaciones Requerimientos, diseño y construcción y después por la administración de servicios: implantación, operación y optimización. Gestión de seguridad. Sus objetivos son: Definir los procesos de la planificación y gestión de los niveles de seguridad necesarios para la información y los servicios TI, incluyendo todos los aspectos asociados con relación a las incidencias de seguridad.

Libros de ITIL


Los ocho libros de ITIL y sus temas son: Gestión de Servicios de TI, 1. Mejores prácticas para la Provisión de Servicio 2. Mejores prácticas para el Soporte de Servicio Otras guías operativas 3. Gestión de la infraestructura de TI 4. Gestión de la seguridad 5. Perspectiva de negocio 6. Gestión de aplicaciones 7. Gestión de activos de software Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional con guías de implementación (principalmente de la Gestión de Servicios): 8. Planeando implementar la Gestión de Servicios Adicional a los ocho libros originales, más recientemente se añadió una guía con recomendaciones para departamentos de TIC más pequeños: 9. Implementación de ITIL a pequeña escala

Beneficios de ITIL


Los siguientes son algunos de los beneficios que debe tener una adecuada Gestión del Servicio en las Tecnologías de Información: Maximiza la calidad del servicio apoyando al negocio de forma expresa. Ofrece una visión clara de la capacidad del área IT. Aumenta la satisfacción en el trabajo mediante una mayor comprensión de las expectativas y capacidades del servicio. Minimiza el ciclo de cambios y mejora los resultados de los procesos y proyectos IT. Facilita la toma de decisiones de acuerdo con indicadores de IT y de negocio

Características de ITIL


Las siguientes son algunas de las características de ITIL: Es un framework de procesos de IT no propietario. Es independiente de los proveedores. Es independiente de la tecnología. Está basado en "BestPractices".

Videos


http://www.youtube.com/watch?v=bdqFlFHZCBs ITIL

http://www.youtube.com/watch?v=bdqFlFHZCBs



Sesión 8


Modelo de datos


Es un conjunto de conceptos que pueden servir para describir la estructura de una Base de Datos; tipo de datos, las relaciones y que deben cumplirse para esos datos. Por lo general los modelos de datos contienen además un conjunto de operaciones básicas para especificar lecturas y actualizaciones de la base de datos.

Partes de un modelo


Estructura: Se definen las reglas bajos las cuales está estructurada la data sin especificar el significado de ésta y la manera como deberá ser usada. Operaciones: Son las permitidas sobre la data. Estas operaciones están normalmente relacionadas a la estructura de la data, es decir, las operaciones son ejecutadas dentro del contexto provisto por las estructuras. Restricciones: Son aciertos para cualquier estructura dentro del modelo de data para las cuales se aplica. Estas pueden ser de dos tipos: implícito o explícito.

Cualidades de un modelo


1.- Expresividad: La disponibilidad de una amplia gama de conceptos hace posible una representación más extensa de la realidad, por esto los modelos más ricos en conceptos son también muy expresivos. 2.- Simplicidad: Debe ser lo mas simple posible. 3.- Formalidad: Requiere que todos los conceptos del modelo tengan una interpretación única, precisa y bien definida

Representación Gráfica


1.- Completitud gráfica: un modelo es gráficamente completo si todos sus conceptos poseen una representación gráfica, de otro modelo; esta representación tendría que completarse con una representación lingüística. 2.- Facilidad de lectura: un modelo es fácil de leer si cada concepto representa con un símbolo gráfico diferentes (o claramente distinguible) del resto de los símbolos gráficos.

Clasificación de los modelos de datos


Se clasifican según los tipos de conceptos:

Ciclo de vida del diseño de una BD


Planificación del proyecto. Definición del sistema. Recolección y análisis de los requisitos. Diseño de la base de datos. Selección del SGBD. Diseño de la aplicación. Implementación. Conversión y carga de datos. Prueba. Mantenimiento.

Estas etapas no son estrictamente secuenciales

Diseño Conceptual


Es un esquema conceptual a partir de los requerimientos recopilados. El esquema conceptual es una descripción concisa de los requerimientos de información de los usuarios y contiene descripciones detalladas de los tipos de datos, vínculos y las restricciones.

Fases de Diseño de Base de Datos


Esquema Conceptual


Tipos de modelos de Datos


1. Modelos lógicos basados en objetos:

Se usan para describir datos en el nivel conceptual. Se caracterizan porque proporcionan capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Los mas conocidos son: Modelo entidad-relación (E/R), el orientado a objetos, modelo lógico el modelo funcional de datos y Modelos físico de datos. 1.1 Modelo Entidad-Relación (E/R): Este modelo de datos se basa en una percepción de un mundo real que consiste en una colección de objetos básicos llamados entidades, y relaciones entre estos objetos. Una entidad es un objeto distinguible de otros por medio de un conjunto de atributos. Una relación es una asociación entre varias entidades.

1. Modelos lógicos basados en objetos:


1.2 Modelo Orientado a Objetos: Al igual que el modelo E/R, el modelo orientado a objetos se basa en una colección de objetos. Un objeto contiene valores acumulados en variables dentro de él, y estos valores son objetos por si mismos. Un objeto también contiene partes de código que operan sobre el objeto, que se denominan métodos. Los objetos que contienen los mismos tipos de valores y los mismos métodos se agrupan en clases. Una clase puede ser vista como una definición de tipo para objetos.

Tipos de modelos de Datos


2. Modelos lógicos basados en registros: Se utilizan para describir datos en los modelos conceptual y físico. A diferencia de los modelos lógicos basados en objetos, se usan para especificar la estructura lógica global de la BD y para proporcionar una descripción a nivel más alto de la implementación. Los tres modelos de datos más aceptados son los modelos relacional, de red y jerárquico.

2. Modelos lógicos basados en registros:


2.1 Modelo relacional : El modelo relacional representa los datos y sus relaciones mediante tablas bidimensionales, que contienen datos tomados de los dominios correspondientes.

2.2 Modelo de datos RED


El modelo de red está formado por colecciones de registros, relacionados mediante punteros o ligas en grafos arbitrarios..

2.3 Modelo jerárquico


El modelo jerárquico es similar al modelo de red, los datos y las relaciones se representan mediante registros y enlaces. Se diferencia del modelo de red en que los registros están organizados como colecciones de árboles.

Tipos de Modelos de datos


3. Modelos físico de datos Se usan para describir datos en el nivel más bajo. Hay muy pocos de modelos físicos de datos en uso, siendo los más conocidos el modelo unificador y de memoria de elementos.

Definición de Calidad de Datos


El dato es la representación simbólica de un hecho o atributo de un entidad, es la unidad básica de la información, la simbología puede ser numérica, alfabética, entre otras. La calidad es el conjunto de propiedades inherentes a un objeto, que permite apreciarlo más, igual o menor a otro objeto de su mismo tipo.

Definición de Calidad de Datos y Calidad


Metodología Orientada a Objetos


Las etapas de la metodología orientada a objetos contemplan desde el análisis de los requerimientos del sistema, hasta la implementación del mismo en productivo. A continuación las etapas con sus respectivas actividades y tareas:









Videos


https://www.youtube.com/watch?v=_SADhrQD5bY Modelo ER

https://www.youtube.com/watch?v=_SADhrQD5bY



Sesión 9


Análisis de Riesgo


El proceso del Análisis de riesgo empieza con el estudio e identificación de los diferentes peligros potenciales y deberá facilitar e identificar los mecanismos mas eficientes para proteger el sistema. El análisis de riesgo por consiguiente permite cuantificar el riesgo, de tal forma que se tienen dos tipos de riesgos, puede ser cualitativos y cuantitativos, dependiendo de los datos asequibles al analista o sobre los requisitos eventuales del análisis.



Proceso de Gestión de Riesgos

Comprende los riesgos con los que enfrenta el sistema, descubriendo sus causas fundamentales y generando los requerimientos para gestionar dichos riesgos. El proceso comprende de las siguientes etapas:


Identificación de Riesgos

Análisis y clasificación de

riesgos

Descomposición de riesgos

Valoración de la reducción de

riesgos


Análisis de las causas raíz

Requerimientos de confiabilidad



Etapa 1: Identificación de Riesgos

El objetivo de la identificación de riegos, es identificar los riegos con los que el sistema tiene que tratar. Esto puede ser un proceso difícil y complejo debido a que en ocasiones los riesgos aparecen como consecuencia de interacciones entre el sistema y condiciones inesperadas del entorno.

Los riesgos principales son las contingencias que provocan accidentes. Se puede abordar el problema de identificación de contingencias considerando las diferentes clases de contingencias físicas, eléctricas, biológicas, radiactivas, de fallo de servicio. Los riesgos relacionados con el software normalmente se asocian a fallos en la ejecución un servicio del sistema o con el fallo de sistemas de monitorización y protección.




Comprende la probabilidad de que surja un riesgo y las consecuencias potenciales que tendrían lugar si se produce un accidente o incidente asociado a ese riego. Para cada riesgo, el resultado del proceso de análisis y clasificación de riesgos es una decisión de aceptación. Los riesgos pueden clasificarse de tres formas: Intolerable Tan Bajo como razonablemente práctico Aceptable




Intolerable.- El sistema debe diseñarse de tal forma que el riesgo no pueda ocurrirse, o si ocurre que no provoque un accidente. Tan Bajo como razonablemente práctico.- El sistema debe diseñarse para que a probabilidad de que ocurra un accidente debido a la contingencia se minimice. Aceptable .- Los diseñadores y/o desarrolladores deberían realizar todos los posibles pasos para reducir la probabilidad de ocurrencia de una contingencia . Estos pasos no deberían incrementar los costes y tiempos de entrega.

El riesgo no puede tolerarse

Riesgo tolerado sólo si la reducción del riesgo no es practica o es excesivamente cara

Región aceptable

Riesgo despreciable

Región ALARP

as low as reasonably practicable




Es e proceso de descubrir las causas fundamentales de los riegos de un sistema particular. Las técnicas para descomposición de riegos se ha derivado principalmente del desarrollo de sistemas de seguridad críticos en los que el análisis de contingencias es una parte central de proceso de seguridad. Técnica de análisis de árbol de defectos. Esta técnica fue desarrollada para sistemas de seguridad críticos. El análisis del árbol de defectos implica identificar eventos no deseados y trabajar hacia atrás a partir de ese evento para descubrir las posibles causas de la contingencia. Se debe poner la contingencia como raíz del árbol e identificar los estados que puedan conducir a la dicha contingencia




A continuación, para cada uno de estos riesgos , se identifican los estados o causas que pueden conducir a que el acontecimiento ocurra, se realiza la descomposición hasta que se identifiquen las causas de raíz del riesgo. Los estados se pueden unir mediante símbolos <<and>> y <<or>>



Etapa 4: Valoración de a reducción de riesgos

Una vez que se han identificado los riesgos potenciales y sus causas, se deberían obtener los requerimientos de confiabilidad del sistema que gestionan los riesgos y aseguran que no ocurran incidentes. Hay tres posibles estrategias que pueden usarse: Evitación de riesgos.- El sistema se diseña para que el riesgo o la contingencia no pueda ocurrir. Detección y eliminación de riesgos.- El sistema se diseña para que los riesgos se detecten y neutralicen antes de que provoquen un accidente. Limitación del daño.- El sistema se diseña para que las consecuencias de un accidente se minimicen.



Estrategia de Desarrollo de Software












METODOS DE ESTIMACION DE COSTO DEL SOFTWARE







Factores que influyen en el costo del software


La estimación de lo que costará el desarrollo de un software es una de las actividades de planeación que reviste especial importancia, ya que una de las características que debe tener un producto de software es que su costo sea adecuado, de lo contrario el proyecto puede fracasar. Los factores que afectan el costo del software: 1.-Capacidad del programador. 2.-Complejidad del producto. 3.Tamaño del programa. 4.Tiempo disponible. 5.Confiabilidad requerida.

Factores que influyen en el costo del software


Perspectivas sobre la Calidad


1.-Calidad de software Para definir calidad de software se han consultado diferentes investigaciones respecto a sus propiedades, las cuales van desde el valor de la calidad, hasta las medidas de sus atributos y trascienden a estándares, normas y modelos establecidos para gestionar, administrar e implementar la calidad de software. Los modelos de calidad permiten precisar conceptos dada la utilidad para planificar y obtener índices de calidad, puesto ayudan en la puesta en practica de conceptos generales por medio de definiciones de tipo operacional. Los diferentes modelos de calidad y estándares permiten identificar algunas necesidades en cuanto a los aspectos de la seguridad como: Incorporar y profundizar sobre la seguridad en modelos y estándares de calidad, por medio de sincronización de los diferentes modelos. Plantear un modelo de calidad concreto aplicando la seguridad del software y sus características en el desarrollo del mismo. Implementar metodologías de medición.



2.-Seguridad de Software Una definición de seguridad no es fácil de concretar, dado que seguridad puede interpretarse de diferente forma, dependiendo del contexto en el se este analizando . Los fundamentos de seguridad plantea que la base de los problemas de seguridad son la conectividad, la complejidad y la extensibilidad de los sistemas actuales y su definición esta bajo dos conceptos orientados dentro de los objetivos de la ingeniería de software: 1.La seguridad de un producto desarrollado se orienta a la búsqueda de que dicho producto continúe funcionando correctamente ante ataques maliciosos. 2.La seguridad de software en construcción se orienta a la resistencia proactiva de posibles ataques.



3.El conocimiento para la seguridad del software Para alcanzar un desarrollo de software seguro es necesario tener fundamentos sólidos para la aplicación de buenas practicas de ingeniería de software y profesionales experimentados; dentro de los desafíos críticos que enfrenta la seguridad del software esta precisamente la escasez de profesionales experimentados. Para el conocimiento para a seguridad del software en los pilares para el desarrollo de software seguro se encuentra distribuida en siete catálogos: Principios Guías Reglas Vulnerabilidades Uso Indebidos Patrones de Ataque Riesgos Históricos



Sesión 10


Estándares y Normas de Software


El ISO/IEC 12207 es el estándar para los procesos de ciclo de vida del software de la organización ISO Este estándar se creo para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software. El estándar comprende 17 procesos lo cuales son agrupados en tres categorías: Principales de apoyo de organización Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos organizativos. Cada proceso del ciclo de vida está divido en un conjunto de actividades; cada actividad se sub -divide a su vez en un conjunto de tareas. A continuación se hace una introducción de cada proceso



Vista de los procesos:

ISO 15504


La norma ISO 15504 permite realizar evaluaciones usando niveles de madurez, la evaluación más extendida en la actualidad. Los niveles de madurez son conjuntos predefinidos de procesos que ayudan a una organización a mejorar en el desarrollo software evolucionando por los distintos niveles. En este modelo, se han establecido 6 niveles, y en cada nivel se ha definido una serie de procesos que indican la madurez de la organización.



Como se observa en la siguiente tabla, el nivel inferior (nivel 0) se corresponde con una organización inmadura, los siguientes niveles van haciendo crecer a la organización en su madurez, hasta el máximo nivel, el nivel 5.

Procesos de los niveles de madurez 1 y 2


Procesos del nivel de madurez 3


Documents

UCV Gobierno de TI_Sesion 10