Procesos ligeros vs pesados, MSF MOF ITIL

4
Procesos Agiles vs Pesados Ciclos de vida Ing. Oscar Reynaldo Calllisaya Limachi 1 ANALISIS PROCESOS LIGEROS VS PESADOS URL: http://www.scrummanager.net/files/sm_proyecto.pdf Antes de ingresar al resumen de los más importantes representantes de los diferentes procesos resumo el análisis entre estos 2 tipos de proyectos. CARACTERÍSTICAS DE LA GESTIÓN DE PROYECTOS PREDICTIVA Estas premisas han dado dos características a la gestión de proyectos predictiva: 1. Universalidad, a pesar de la diversidad se comparten patrones comunes de ejecución 2. Carácter predictivo, se define con detalle cuál es el “producto previsto” y elabora un plan de desarrollo, a partir del cual calcula costes y fechas. PREMISAS Y CARACTERICITICAS PROCESOS LIVIANOS 1. No hay una forma única y válida para gestionar cualquier tipo de proyecto Cada producto tiene diferentes características diferenciales: Innovación en el producto. Bajo grado de estabilidad de los requisitos. Bajo coste de prototipo. Maleabilidad del producto para modificar su funcionalidad una vez desarrollado. Hay proyectos en los que importa más el valor y la innovación que el cumplimiento del plan. Innovación CUÁNDO USAR ADAPTABLE O PREDICTIVO CRITERIO ADAPTABLE PREDICTIVA Principal prioridad de negocio. VALOR CUMPLIMIENTO Estabilidad de los requisitos. INESTABLE ESTABLE Rigidez del producto. MODIFICABLE DIFICIL DE MODIFICAR Coste de prototipado. BAJO ALTO Criticidad del sistema. BAJO MEDIO ALTO Tamaño del sistema. PEQUEÑO MEDIO GRANDE . PUDS Describe un proceso divido en 4 fases las cuales deben cumplir diferentes FLUJOS que se repetirán en todas las fases, solo que tendrán más o menos “TRABAJO” de acuerdo a la fase. Es un proceso CON CICLO DE VIDA ITERATIVO. Una o más vueltas a todos las tareas de una fase se puede dar, a esto se le llama HITO, cada FLUJO crea documentos que se usarán en los siguientes FASES Y FLUJO, al finalizar LAS FASES se ha concluido una iteración, con lo cual tenemos una versión del software listo. Se pueden dar las iteraciones necesarias, esto de acuerdo a la división que se dio al sistema. Los diferentes modelos y artefactos que deben crearse se basan en UML. CICLO DE VIDA EN ESPIRAL La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de

Transcript of Procesos ligeros vs pesados, MSF MOF ITIL

Procesos Agiles vs Pesados Ciclos de vida

Ing. Oscar Reynaldo Calllisaya Limachi 1

ANALISIS PROCESOS LIGEROS VS PESADOS

URL: http://www.scrummanager.net/files/sm_proyecto.pdf

Antes de ingresar al resumen de los más importantes representantes de los diferentes procesos resumo el análisis entre estos 2 tipos de proyectos.

CARACTERÍSTICAS DE LA GESTIÓN DE PROYECTOS PREDICTIVA

Estas premisas han dado dos características a la gestión de proyectos predictiva:

1. Universalidad, a pesar de la diversidad se comparten patrones comunes de ejecución

2. Carácter predictivo, se define con detalle cuál es el “producto previsto” y elabora un plan de desarrollo, a partir del cual calcula costes y fechas.

PREMISAS Y CARACTERICITICAS PROCESOS LIVIANOS

1. No hay una forma única y válida para gestionar cualquier tipo de proyecto

Cada producto tiene diferentes características diferenciales:

• Innovación en el producto. • Bajo grado de estabilidad de los requisitos. • Bajo coste de prototipo.

• Maleabilidad del producto para modificar su funcionalidad una vez desarrollado.

Hay proyectos en los que importa más el valor y la innovación que el cumplimiento del plan. Innovación

CUÁNDO USAR ADAPTABLE O PREDICTIVO

CRITERIO ADAPTABLE PREDICTIVA

Principal prioridad de negocio. VALOR CUMPLIMIENTO

Estabilidad de los requisitos. INESTABLE ESTABLE

Rigidez del producto. MODIFICABLE DIFICIL DE MODIFICAR

Coste de prototipado. BAJO ALTO

Criticidad del sistema. BAJO MEDIO ALTO

Tamaño del sistema. PEQUEÑO – MEDIO GRANDE

.

PUDS

Describe un proceso divido en 4 fases las cuales deben cumplir diferentes FLUJOS que se repetirán en todas las fases, solo que tendrán más o menos “TRABAJO” de acuerdo a la fase.

Es un proceso CON CICLO DE VIDA ITERATIVO. Una o más vueltas a todos las tareas de una fase se puede dar, a esto se le llama HITO, cada FLUJO crea documentos que se usarán en los siguientes FASES Y FLUJO, al finalizar LAS FASES se ha concluido una iteración, con lo cual tenemos una versión del software listo. Se pueden dar las iteraciones necesarias, esto de acuerdo a la división

que se dio al sistema. Los diferentes modelos y artefactos que deben crearse se basan en UML.

CICLO DE VIDA EN ESPIRAL

La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de

Procesos Agiles vs Pesados Ciclos de vida

Ing. Oscar Reynaldo Calllisaya Limachi 2

sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

• Crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;

• Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar cómo identificar y eliminar el riesgo;

• La implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;

XP EXTERME PROGRAMMING

XP, se basa en el trabajo orientado directamente al producto, basándose para esto en las relaciones interpersonales y en la velocidad de reacción para la implementación y para los cambios que puedan surgir durante el desarrollo del proceso.

Esto se logra, minimizando el riesgo de fallo del proceso manteniendo dentro del equipo a un representante "competente" del cliente, este representante es quién responderá a todas las preguntas y dudas que surjan por parte del equipo de desarrollo durante el proceso, de forma que no se retrase la toma de decisiones.

XP se basa en UseStories (historias de uso), estas historias las escribe el cliente o su representante dentro del equipo y describen los escenarios claves del funcionamiento del software, a partir de estas se generan los releases (entregas) entre el equipo y el cliente. Estos releases son los que permiten definir las iteraciones necesarias para cumplir con los objetivos, de manera que cada resultado de la iteración sea un programa aprobado por el cliente de quien depende la definición de las siguientes iteraciones.

Una característica saltante de XP, es que el código siempre se produce en parejas, parejas que van cambiando constantemente para lograr así que todo el equipo sepa y pueda modificar según necesidades el código generado, esto logra en el equipo que los integrantes aprendan entre sí y compartan todo el código.

SCRUM

Scrum es un marco de gestión para proyectos ágiles, se enfoca en lo que pide el cliente e indica que la forma de desarrollo debe ser con incrementos, demostrables en menos de un mes en el cual al inicio y al final de cada incremente el cliente indica su aprobación y mejoras al mismo.

Se inicia con una descripción y listado de funciones(ProductBacklog) esto hecho por el ProductOwner, luego se planifica las tareas a realizar (Sprint Backlog) hecho por el EQUIPO pero con la ayuda del SCRUM MASTER y PRODUCT OWNER, luego el equipo SE ENCIERRA A DESARROLLAR (SPRINT) para realizar el SPRINT BACKLOG, realizar REUNIONES DIARAS para revisar avance y al finalizar REALIZA DEMO de la parte FINALIZADA DEL SOFTWARE se hace RETROSPECTIVAS para mejorar el proceso en los siguientes Sprints.

SCRUM tiene un enfoque para la GESTION DE PROYECTOS pero no del DESARROLLO DEL SOFTWARE, al ser un FRAMEWORK permite utilizar otras metodologías para esas áreas que no usa SCRUM una de las más recomendadas es XP, de la cual XP ha nacido.

Procesos Agiles vs Pesados Ciclos de vida

Ing. Oscar Reynaldo Calllisaya Limachi 3

MICROSOFT SOLUTIONS FRAMEWORK MICROSOFT SOLUTIONS FRAMEWOR, es un conjunto de principios, modelo, disciplinas, conceptos y guias para proyectos de desarrollo, implementación, redes e infraestructura. MSF no obliga a seguir un ciclo de vida.

Propone una estructura de gestión del software para asegurar el impacto deseado, exige calidad en el software y no permite el lanzamiento de un software si este tiene errores proponiendo un equipo de pruebas BETA en la empresa y una vez solucionado lanzar el software al mercado.

MSF se guía en base a los siguientes principios.

1. Fomentar la comunicación abierta

2. Trabajar en pro de una visión compartida

3. Empoderar a los miembros del equipo

4. Establecer la rendición de cuentas clara y la responsabilidad compartida

5. Enfoque en entregar valor de negocio

6. Manténgase ágil, esperan cambiar

7. Invertir en calidad

8. Aprender de todas las experiencias

MODELOS

1. Modelo de equipo, describe los diferentes integrantes del equipo de software, de implementación, etc.

2. Modelo de gobierno, define el PROCESO que esta compuesto por diferentes etapas para el desarrollo del proyecto, las cuales puede AUMENTARSE para las tradicionales o DISMINUIR para los ágiles estas son: Visión, Plan, Construccion, Estabilización e Implementación.

MOF (MICROSOFT OPERATION FRAMEWORK)

MOF ofrece directrices sobre el modo de planear, implementar y mantener procesos operativos de Information Technologies (IT) que respalden las soluciones de servicio críticas. MOF es un modelo genérico y, por este motivo, debe adaptar muchas de las recomendaciones para usarlas en su empresa. Cuando encuentre referencias a "funciones" en el modelo MOF, tenga en cuenta que se puede asignar a una misma persona a varias funciones, sobre todo en las empresas pequeñas. No obstante, aunque represente a todo el departamento de TI, los procedimientos y recomendaciones de este modelo se pueden aplicar de forma general.

MOF es un modelo estructurado y flexible

• Los equipos de consultoría y soporte técnico de Microsoft y su experiencia de trabajo con clientes empresariales y socios, además de grupos internos de operaciones de TI en Microsoft.

• La Biblioteca de infraestructuras de TI (ITIL), que describe los procesos y las prácticas recomendadas necesarios para el suministro de soluciones de servicio críticas.

• ISO/IEC 15504, de la Organización Internacional de Normalización (ISO), que proporciona un enfoque normalizado para evaluar la madurez del proceso de software.

MOF ofrece recomendaciones para la implementación de varios productos de Microsoft, como Microsoft Windows Server 2003 y Microsoft Exchange Server 2007.

CUADRANTES DE REVISION

El modelo de proceso MOF está formado por cuadrantes, revisiones de la administración de las operaciones y revisiones de la administración de los servicios. El modelo de proceso MOF se desplaza en sentido de las agujas del reloj y se divide en los cuatro cuadrantes integrados siguientes:

1. Cambios

2. Operaciones

3. Soporte técnico

4. Optimización

Procesos Agiles vs Pesados Ciclos de vida

Ing. Oscar Reynaldo Calllisaya Limachi 4

INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL)

La Biblioteca de Infraestructura de Tecnologías de Información, abreviada ITIL, es un conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la información, el desarrollo detecnologías de la información y las operaciones relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.

CERTIFICACIÓN

Existe un serie de certificaciones dadas por los Institutos Examinadores que describe el nivel de conocimiento y manejo de ITIL.

1. FoundationCertificate (Certificado Básico): acredita un conocimiento básico de ITIL en gestión de servicios de tecnologías de la información y la comprensión de la terminología propia de ITIL.

2. Practitioner'sCertificate (Certificado de Responsable): destinado a quienes tienen responsabilidad en el diseño de procesos de administración de departamentos de tecnologías de la información y en la planificación de las actividades asociadas a los procesos.

3. Manager'sCertificate (Certificado de Director): garantiza que quien lo posee dispone de profundos conocimientos en todas las materias relacionadas con la administración de departamentos de tecnologías de la información.

CICLO DE VIDA DEL SERVICIO

ITIL se basa en el CICLO DE VIDA DEL SERVICIO descrito en sus 5 libros:

1. Estrategia del Servicio, se identifican nuevos servicios o mejoras a los existentes en base a estudios de mercado, tiene diferentes procesos más que todo del área administrativa.

2. Diseño del Servicio, ya identificados se los analiza su viabilidad de acuerdo a las capacidades internas y diseña todo lo respecto al proyecto, recursos, personal, infraestructura.

3. Transición del Servicio, Antes de poner en marcha el servicio se deben realizar pruebas, en base a la situación se prepara un escenario. Al finalizarlas se limpia y se implementa el servicio.

4. Operación del Servicio, se monitoriza el funcionamiento del servicio, se registran eventos, incidencias, problemas, peticiones y accesos al servicio.

5. Mejora Continua del Servicio, se definen formas de medir el servicio y se debe realizar mejoras continuas al mismo