Procesos Agiles vs Pesados                                                                               Ciclos de vida   ...
Procesos Agiles vs Pesados                                                                       Ciclos de vidasistema com...
Procesos Agiles vs Pesados                                                                       Ciclos de vida           ...
Procesos Agiles vs Pesados                                                                      Ciclos de vida     INFORMA...
Upcoming SlideShare
Loading in...5
×

Procesos ligeros vs pesados, MSF MOF ITIL

783

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
783
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Procesos ligeros vs pesados, MSF MOF ITIL

  1. 1. Procesos Agiles vs Pesados Ciclos de vida ANALISIS PROCESOS LIGEROS VS PESADOS URL: http://www.scrummanager.net/files/sm_proyecto.pdfAntes de ingresar al resumen de los más importantes representantes de los diferentes procesos resumo elanálisis entre estos 2 tipos de proyectos.CARACTERÍSTICAS DE LA GESTIÓN DE PROYECTOS PREDICTIVAEstas 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ón2. Carácter predictivo, se define con detalle cuál es el “producto previsto” y elabora un plan de desarrollo, apartir del cual calcula costes y fechas.PREMISAS Y CARACTERICITICAS PROCESOS LIVIANOS1. No hay una forma única y válida para gestionar cualquier tipo de proyectoCada producto tiene diferentes características diferenciales: • Innovación en el producto. • Maleabilidad del producto para modificar su • Bajo grado de estabilidad de los requisitos. funcionalidad una vez desarrollado. • Bajo coste de prototipo.Hay proyectos en los que importa más el valor y la innovación que el cumplimiento del plan. InnovaciónCUÁNDO USAR ADAPTABLE O PREDICTIVO CRITERIO ADAPTABLE PREDICTIVAPrincipal prioridad de negocio. VALOR CUMPLIMIENTOEstabilidad de los requisitos. INESTABLE ESTABLERigidez del producto. MODIFICABLE DIFICIL DE MODIFICARCoste de prototipado. BAJO ALTOCriticidad del sistema. BAJO MEDIO ALTOTamañ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ónque se dio al sistema. Los diferentes modelos y artefactos que deben crearse se basan en UML.CICLO DE VIDA EN ESPIRALLa principal características del modelo en espiral es la gestión deriesgos de forma periódica en el ciclo de desarrollo. Este modelo fuecreado en 1988 por Barry Boehm, combinando algunos aspectosclave de las metodologías del modelo de cascada y del desarrollorápido de aplicaciones, pero dando énfasis en un área que paramuchos no jugó el papel que requiere en otros modelos: un análisisiterativo y concienzudo de los riesgos, especialmente en el caso deIng. Oscar Reynaldo Calllisaya Limachi 1
  2. 2. Procesos Agiles vs Pesados Ciclos de vidasistema complejos de gran escala.La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de loscuatro cuadrantes representativos de las siguientes actividades:• Crear planes con el propósito de identificar los objetivos del software,seleccionados para implementarel 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 identificary eliminar el riesgo;• La implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;XP EXTERME PROGRAMMINGXP, se basa en el trabajo orientado directamente al producto, basándose para esto en las relacionesinterpersonales y en la velocidad de reacción para la implementación y para los cambios que puedan surgirdurante 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 surjanpor 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 dentrodel equipo y describen los escenarios claves del funcionamiento del software, a partir de estas se generan losreleases (entregas) entre el equipo y el cliente. Estos releases son los que permiten definir las iteracionesnecesarias para cumplir con los objetivos, de manera que cada resultado de la iteración sea un programaaprobado 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 vancambiando constantemente para lograr así que todo el equipo sepa y pueda modificar según necesidades elcódigo generado, esto logra en el equipo que los integrantes aprendan entre sí y compartan todo el código.SCRUMScrum es un marco de gestión para proyectos ágiles, se enfoca en lo que pide elcliente 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 cadaincremente el cliente indica su aprobación y mejoras al mismo.Se inicia con una descripción y listado de funciones(ProductBacklog) esto hechopor el ProductOwner, luego se planifica las tareas a realizar (Sprint Backlog)hecho por el EQUIPO pero con la ayuda del SCRUM MASTER y PRODUCTOWNER, luego el equipo SE ENCIERRA A DESARROLLAR (SPRINT) pararealizar el SPRINT BACKLOG, realizar REUNIONES DIARAS para revisar avance y al finalizar REALIZADEMO de la parte FINALIZADA DEL SOFTWARE se hace RETROSPECTIVAS para mejorar el proceso enlos 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 lasmás recomendadas es XP, de la cual XP ha nacido.Ing. Oscar Reynaldo Calllisaya Limachi 2
  3. 3. Procesos Agiles vs Pesados Ciclos de vida MICROSOFT SOLUTIONS FRAMEWORKMICROSOFT SOLUTIONS FRAMEWOR, es un conjunto de principios, modelo, disciplinas, conceptos y guiaspara 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 elsoftware y no permite el lanzamiento de un software si este tiene errores proponiendo un equipo de pruebasBETA 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 5. Enfoque en entregar valor de negocio 2. Trabajar en pro de una visión compartida 6. Manténgase ágil, esperan cambiar 3. Empoderar a los miembros del equipo 7. Invertir en calidad 4. Establecer la rendición de cuentas clara y la 8. Aprender de todas las experiencias responsabilidad compartidaMODELOS 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 InformationTechnologies (IT) que respalden las soluciones de servicio críticas. MOF es un modelo genérico y, por estemotivo, debe adaptar muchas de las recomendaciones para usarlas en su empresa. Cuando encuentrereferencias a "funciones" en el modelo MOF, tenga en cuenta que se puede asignar a una misma persona avarias funciones, sobre todo en las empresas pequeñas. No obstante, aunque represente a todo eldepartamento de TI, los procedimientos y recomendaciones de este modelo se pueden aplicar de formageneral.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 MicrosoftWindows Server 2003 y Microsoft Exchange Server 2007.CUADRANTES DE REVISIONEl modelo de proceso MOF está formado por cuadrantes, revisiones de la administración de las operaciones yrevisiones de la administración de los servicios. El modelo de proceso MOF se desplaza en sentido de lasagujas del reloj y se divide en los cuatro cuadrantes integrados siguientes: 1. Cambios 2. Operaciones 3. Soporte técnico 4. OptimizaciónIng. Oscar Reynaldo Calllisaya Limachi 3
  4. 4. Procesos Agiles vs Pesados Ciclos de vida INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL)La Biblioteca de Infraestructura de Tecnologías de Información, abreviada ITIL, es un conjunto deconceptos y prácticas para la gestión de servicios de tecnologías de la información, el desarrollodetecnologías de la información y las operaciones relacionadas con la misma en general. ITIL dadescripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a lasorganizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos sonindependientes del proveedor y han sido desarrollados para servir como guía que abarque todainfraestructura, desarrollo y operaciones de TI.CERTIFICACIÓNExiste un serie de certificaciones dadas por los Institutos Examinadores que describe el nivel de conocimientoy 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. PractitionersCertificate (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. ManagersCertificate (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 SERVICIOITIL 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 mismoIng. Oscar Reynaldo Calllisaya Limachi 4

×