Luis

363 views
319 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
363
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Luis

  1. 1. CAPABILITY MATURITY MODEL INTEGRATION (CMMI)Integración de modelos de madurez de capacidades oCapabilitymaturitymodelintegration (CMMI) es un modelo para la mejora yevaluación de procesos para el desarrollo, mantenimiento y operación de sistemasde software.Modelos CMMILas mejores prácticas CMMI se publican en los documentos llamados modelos. Enla actualidad hay tres áreas de interés cubiertas por los modelos de CMMI:Desarrollo, Adquisición y Servicios.La versión actual de CMMI es la versión 1.3 la cual corresponde a CMMI-SVC,liberada el 1 de noviembre de 2010. Hay tres constelaciones de la versión 1.2disponible: CMMI para el Desarrollo (CMMI-DEV o CMMI forDevelopment), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios. CMMI para la adquisición (CMMI-ACQ o CMMI forAcquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria. CMMI para servicios (CMMI-SVC o CMMI forServices), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.Dentro de la constelación CMMI-DEV, existen dos modelos: CMMI-DEV CMMI-DEV + IPPD (Integrated Product and Process Development)Independientemente de la constelaciónmodelo que opta una organización, lasprácticas CMMI deben adaptarse a cada organización en función de sus objetivosde negocio.Las organizaciones no pueden ser certificadas CMMI. Por el contrario, unaorganización es evaluada (por ejemplo, usando un método de evaluación comoSCAMPI y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (sibien se comienza con el nivel 2). En caso de que quiera la organización, puedecoger áreas de proceso y en vez de por niveles de madurez puede obtener losniveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfilde Capacidad" de la Organización.
  2. 2. OPENUP ENTERPRISE UPOpenUP es un método y un proceso de desarrollo de software propuesto por unconjunto de empresas de tecnología,1 quienes lo donaron en el año 2007 a laFundación Eclipse. La fundación lo ha publicado bajo una licencia libre2 y lomantiene como método de ejemplo dentro del proyecto Eclipse ProcessFramework.Principios del OpenUP Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la colaboración y desarrollan un conocimiento compartido del proyecto. Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este principio promueve prácticas que permiten a los participantes de los proyectos desarrollar una solución que maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del proyecto. Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo. Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo. Este principio promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación temprana y continua de los
  3. 3. participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidadOrganización de los componentes del OpenUPEl OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas:el método y el proceso. El contenido del método es donde los elementos delmétodo (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuentacomo son utilizados en el ciclo de vida del proyecto. El proceso es donde loselementos del método son aplicados de forma ordenada en el tiempo. Muchosciclos de vida para diferentes proyectos pueden ser creados a partir del mismoconjunto de elementos del método.eXtremeProgramming (XP)La programación extrema o eXtremeProgramming (XP) es un enfoque de laingeniería de software formulado por Kent Beck, autor del primer libro sobre lamateria, Extreme ProgrammingExplained: Embrace Change (1999). Es el másdestacado de los procesos ágiles de desarrollo de software. Al igual que éstos, laprogramación extrema se diferencia de las metodologías tradicionalesprincipalmente en que pone más énfasis en la adaptabilidad que en laprevisibilidad. Los defensores de XP consideran que los cambios de requisitossobre la marcha son un aspecto natural, inevitable e incluso deseable deldesarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios derequisitos en cualquier punto de la vida del proyecto es una aproximación mejor ymás realista que intentar definir todos los requisitos al comienzo del proyecto einvertir esfuerzos después en controlar los cambios en los requisitos.ValoresLos Valores originales de la programación extrema son: simplicidad,comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue
  4. 4. añadido en la segunda edición de Extreme ProgrammingExplained. Los cincovalores se detallan a continuación: Simplicidad:La simplicidad es la base de la programación extrema. Se simplifica el diseño paraagilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del códigojunto a sucesivas modificaciones por parte de diferentes desarrolladores hacenque la complejidad aumente exponencialmente. Para mantener la simplicidad esnecesaria la refactorización del código, ésta es la manera de mantener el códigosimple a medida que crece. También se aplica la simplicidad en la documentación,de esta manera el código debe comentarse en su justa medida, intentando eso síque el código esté autodocumentado. Para ello se deben elegir adecuadamentelos nombres de las variables, métodos y clases. Los nombres largos nodecrementan la eficiencia del código ni el tiempo de desarrollo gracias a lasherramientas de autocompletado y refactorización que existen actualmente.Aplicando la simplicidad junto con la autoría colectiva del código y la programaciónpor parejas se asegura que cuanto más grande se haga el proyecto, todo elequipo conocerá más y mejor el sistema completo. Comunicación:La comunicación se realiza de diferentes formas. Para los programadores elcódigo comunica mejor cuanto más simple sea. Si el código es complejo hay queesforzarse para hacerlo inteligible. El código autodocumentado es más fiable quelos comentarios ya que éstos últimos pronto quedan desfasados con el código amedida que es modificado. Debe comentarse sólo aquello que no va a variar, porejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebasunitarias son otra forma de comunicación ya que describen el diseño de las clasesy los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Losprogramadores se comunican constantemente gracias a la programación porparejas. La comunicación con el cliente es fluida ya que el cliente forma parte delequipo de desarrollo. El cliente decide que características tienen prioridad ysiempre debe estar disponible para solucionar dudas. Retroalimentación (feedback):Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyectose conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales semuestran resultados, se minimiza el tener que rehacer partes que no cumplen conlos requisitos y ayuda a los programadores a centrarse en lo que es másimportante. Considérense los problemas que derivan de tener ciclos muy largos.Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios delcliente o malentendidos por parte del equipo de desarrollo. El código también esuna fuente de retroalimentación gracias a las herramientas de desarrollo. Porejemplo, las pruebas unitarias informan sobre el estado de salud del código.
  5. 5. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos acambios recientes en el código. Coraje o valentía:Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar yprogramar para hoy y no para mañana. Esto es un esfuerzo para evitarempantanarse en el diseño y requerir demasiado tiempo y trabajo paraimplementar todo lo demás del proyecto. La valentía le permite a losdesarrolladores que se sientan cómodos con reconstruir su código cuando seanecesario. Esto significa revisar el sistema existente y modificarlo si con ello loscambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía essaber cuando desechar un código: valentía para quitar código fuente obsoleto, sinimportar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además,valentía significa persistencia: un programador puede permanecer sin avanzar enun problema complejo por un día entero, y luego lo resolverá rápidamente al díasiguiente, solo si es persistente. Respeto:El respeto se manifiesta de varias formas. Los miembros del equipo se respetanlos unos a otros, porque los programadores no pueden realizar cambios quehacen que las pruebas existentes fallen o que demore el trabajo de suscompañeros. Los miembros respetan su trabajo porque siempre están luchandopor la alta calidad en el producto y buscando el diseño óptimo o más eficiente parala solución a través de la refactorización del código. Los miembros del equiporespetan el trabajo del resto no haciendo menos a otros, una mejor autoestima enel equipo y elevando el ritmo de producción en el equipo.SCRUMScrum es un marco de trabajo para la gestión y desarrollo de software basada enun proceso iterativo e incremental utilizado comúnmente en entornos basados enel desarrollo ágil de software.Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo desoftware, puede ser utilizado en equipos de mantenimiento de software, o en unaaproximación de gestión de programas: Scrum de Scrums.
  6. 6. Características de ScrumScrum es un modelo de referencia que define un conjunto de prácticas y roles, yque puede tomarse como punto de partida para definir el proceso de desarrolloque se ejecutará durante un proyecto. Los roles principales en Scrum son elScrumMaster, que mantiene los procesos y trabaja de forma similar al director deproyecto, el ProductOwner, que representa a los stakeholders (interesadosexternos o internos), y el Team que incluye a los desarrolladores.Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud esdefinida por el equipo), el equipo crea un incremento de software potencialmenteentregable (utilizable). El conjunto de características que forma parte de cadasprint viene del ProductBacklog, que es un conjunto de requisitos de alto nivelpriorizados que definen el trabajo a realizar. Los elementos del ProductBacklogque forman parte del sprint se determinan durante la reunión de Sprint Planning.Durante esta reunión, el ProductOwner identifica los elementos delProductBacklog que quiere ver completados y los hace del conocimiento delequipo. Entonces, el equipo determina la cantidad de ese trabajo que puedecomprometerse a completar durante el siguiente sprint. 2 Durante el sprint, nadiepuede cambiar el Sprint Backlog, lo que significa que los requisitos estáncongelados durante el sprint.Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entretodos los miembros y disciplinas involucrados en el proyecto.Un principio clave de Scrum es el reconocimiento de que durante un proyecto losclientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudollamado requirementschurn), y que los desafíos impredecibles no pueden serfácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrumadopta una aproximación pragmática, aceptando que el problema no puede ser
  7. 7. completamente entendido o definido, y centrándose en maximizar la capacidad delequipo de entregar rápidamente y responder a requisitos emergentes.Existen varias implementaciones de sistemas para gestionar el proceso de Scrum,que van desde notas amarillas "post-it" y pizarras hasta paquetes de software.Una de las mayores ventajas de Scrum es que es muy fácil de aprender, yrequiere muy poco esfuerzo para comenzarse a utilizar.INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL)La Biblioteca de Infraestructura de Tecnologías de Información, frecuentementeabreviada ITIL (del inglésInformationTechnologyInfrastructure Library), es unconjunto de conceptos y prácticas para la gestión de servicios de tecnologías de lainformación, el desarrollo de tecnologías de la información y las operacionesrelacionadas con la misma en general. ITIL da descripciones detalladas de unextenso conjunto de procedimientos de gestión ideados para ayudar a lasorganizaciones a lograr calidad y eficiencia en las operaciones de TI. Estosprocedimientos son independientes del proveedor y han sido desarrollados paraservir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.HistoriaAunque se desarrolló durante los años 1980, ITIL no fue ampliamente adoptadahasta mediados de los años 1990. Esta mayor adopción y conocimiento ha llevadoa varios estándares, incluyendo ISO/IEC 20000, que es una norma internacionalcubriendo los elementos de gestión de servicios de TI de ITIL. ITIL se considera amenudo junto con otros marcos de trabajo de mejores prácticas como laInformationServicesProcurement Library (ISPL, „Biblioteca de adquisición deservicios de información‟), la ApplicationServices Library (ASL, „Biblioteca deservicios de aplicativos‟), el método de desarrollo de sistemas dinámicos (DSDM,DynamicSystemsDevelopmentMethod), el Modelo de Capacidad y Madurez(CMM/CMMI) y a menudo se relaciona con la gobernanza de tecnologías de lainformación mediante COBIT (Control ObjectivesforInformation andrelatedTechnology).El concepto de gestión de servicios de TI, aunque relacionado con ITIL, no esidéntico: ITIL contiene una sección específicamente titulada «Gestión de Serviciosde TI» (la combinación de los volúmenes de Servicio de Soporte y Prestación deServicios, que son un ejemplo específico de un marco ITSM). Sin embargo esimportante señalar que existen otros marcos parecidos. La Gestión de ServicioITIL está actualmente integrado en el estándar ISO 20000 (anterior BS 15000).ITIL se construye en torno a una vista basada en proceso-modelo del control ygestión de las operaciones a menudo atribuida a W. Edwards Deming. Lasrecomendaciones de ITIL fueron desarrolladas en los años 1980 por la Central
  8. 8. Computer and Telecommunications Agency (CCTA) del gobierno británico comorespuesta a la creciente dependencia de las tecnologías de la información y alreconocimiento de que sin prácticas estándar, los contratos de las agenciasestatales y del sector privado creaban independientemente sus propias prácticasde gestión de TI y duplicaban esfuerzos dentro de sus proyectos TIC, lo queresultaba en errores comunes y mayores costes.ITIL fue publicado como un conjunto de libros, cada uno dedicado a un áreaespecífica dentro de la Gestión de TI. Los nombres ITIL e IT Infrastructure Library(„Biblioteca de infraestructura de TI‟) son marcas registradas de la Office ofGovernment Commerce („Oficina de comercio gubernamental‟, OGC), que es unadivisión del Ministerio de Hacienda del Reino Unido.En abril de 2001 la CCTA fue integrada en la OGC, desapareciendo comoorganización separada.1En diciembre de 2005, la OGC emitió un aviso de una actualización a ITIL,2conocida comúnmente como ITIL v3, que estuvo planificada para ser publicada afinales de 2006; habiendo sido realizada en junio de 2007. Se esperaba que lapublicación de ITIL versión 3 incluyera cinco libros principales, concretamente:Diseño de Servicios de TI, Introducción de los Servicios de TI, Operación de losServicios de TI, Mejora de los Servicios de TI y Estrategias de los Servicios de TI,consolidando buena parte de las prácticas actuales de la versión 2 en torno alCiclo de Vida de los Servicios.Uno de los principales beneficios propugnado por los defensores de ITIL dentro dela comunidad de TI es que proporciona un vocabulario común, consistente en unglosario de términos precisamente definidos y ampliamente aceptados. Un nuevoglosario ampliado ha sido desarrollado como entregable clave de ITIL versión 3.Otros modelos: CMMI para el desarrollo de software y s3m,3 para elmantenimiento del software
  9. 9. COBITCOBIT es un marco creado por ISACA para la tecnología de la información (TI) yel Gobierno de TI . Se trata de un conjunto de herramientas de apoyo que permitea los administradores para cerrar la brecha entre las necesidades de control,cuestiones técnicas y los riesgos de negocio.El propósito de Cobit es brindar a la Alta Dirección de una compañía confianza enlos sistemas de información y en la información que estos produzcan. Cobitpermite entender como dirigir y gestionar el uso de tales sistemas así comoestablecer un codigo de buenas practicas a ser utilizado por los proveedores desistemas. Cobit suministra las herramientas para supervisar todas las actividadesrelacionadas con IT.Veamos que ventajas ofrece Cobit: Cobit es un marco de referencia aceptado mundialmente de gobierno IT basado en estándares y mejores prácticas de la industria. Una vez implementado, es posible asegurarse de que IT se encuentra efectivamente alineado con las metas del negocio, y orientar su uso para obtener ventajas competitivas. Suministra un lenguaje común que le permite a los ejecutivos de negocios comunicar sus metas, objetivos y resultados con Auditores, IT y otros profesionales. Proporciona las mejores prácticas y herramientas para monitorear y gestionar las actividades de IT. El uso de sistemas usualmente requiere de una inversión que necesita ser adecuadamente gestionada.
  10. 10. Ayuda a los ejecutivos a entender y gestionar las inversiones en IT a través de sus ciclo de vida, así como también proporcionándoles métodos para asegurarse que IT entregara los beneficios esperados.La diferencia entre compañías que gestionan adecuadamente sus recursos IT ylas que no es enorme. Cobit permite el desarrollo de políticas claras y buenasprácticas para la gestión de IT. Su marco de referencia permite gestionar losriesgos de IT y asegurar el cumplimiento, la continuidad, seguridad y privacidad.Al ser Cobit reconocida y aceptada internacionalmente como una herramienta degestión, su implementación es un indicativo de la seriedad de una organización.Ayuda a Empresas y profesionales de IT a demostrar su competitividad ante lasdemás compañías. Así como existen procesos genéricos de muchos tipos denegocios, existen estándares y buenas practicas específicos para IT que debenseguirse por las compañías cuando se soportan en IT, en donde Cobit agrupatales estándares y entrega un marco de referencia para su implementación ygestión.Una vez se identifican e implementan los principios relevantes de Cobit para unacompañía, se obtiene plena confianza en que todos los recursos de sistemasestan siendo gestionados efectivamente.Que resultados se obtienen al implementar Cobit? Veamos: El ciclo de vida de costos de IT será mas transparente y predecible. IT entregara información de mayor calidad y en menor tiempo. IT brindara servicios con mayor calidad y todos los proyectos apoyados en IT serán mas exitosos. Los requerimientos de seguridad y privacidad serán más fácilmente identificados, y su implementación podrá ser mas fácilmente monitoreada. Todos los riesgos asociados a IT serán gestionados con mayor efectividad. El cumplimiento de regulaciones relacionadas a IT serán una práctica normal dentro de su gestión.El marco de referencia Cobit en su versión 4 (a Julio de 2010), incluye losiguiente: Marco de referencia: explica como Cobitorganiza la Gestión de IT, los objetivos de control y buenas practicas del negocio por dominios y procesos de IT, relacionándolos directamente con los requerimientos del negocio. Este marco de referencia contiene un total de 34 niveles de objetivos de control, uno por cada proceso de IT, agrupados en cuatro dominios: Planeamiento y Organización, Adquisición e Implementación, Desarrollo y Soporte y Monitoreo y Evaluación (Que tal la coincidencia con el ciclo PHVA de las Normas ISO?) Descripción de procesos: Incluida para cada uno de los 34 procesos de IT, cubriendo todas las áreas y responsabilidades de IT de principio a fin.
  11. 11. Objetivos de Control: Suministra objetivos de gestión basados en las mejores prácticas para los procesos de IT. Directrices de Gestión: Incluye herramientas para ayudar a asignar responsabilidades y medir desempeños. Modelos de madurez: proporciona perfiles de los procesos de IT describiendo para cada uno de ellos un estados actual y uno futuro.LEANQUE ES LEAN?La idea central es maximizar el valor del cliente y reducir al mínimo los residuos.Simplemente, delgado significa crear más valor para los clientes con menosrecursos.Una organización ágil entiende el valor del cliente y enfoca sus procesos clavepara aumentar continuamente. El objetivo final es aportar un valor ideal para elcliente a través de un proceso de creación de valor perfecta que tiene cero deresiduos.Para lograr esto, los cambios de pensamiento lean el enfoque de la gestión de laoptimización de las tecnologías por separado, los activos, y los departamentosverticales para optimizar el flujo de productos y servicios a través de cadenas devalor enteras que fluyen horizontalmente a través de las tecnologías, los activos, ylos departamentos a los clientes.La eliminación de los residuos a lo largo de cadenas de valor completas, en lugarde en puntos aislados, crea procesos que requieren menos esfuerzo humano,menos espacio, menos capital y menos tiempo para hacer los productos yservicios a costos mucho menos y mucho menos con defectos, en comparacióncon los sistemas empresariales tradicionales . Las empresas son capaces deresponder a los deseos cambiantes de los clientes con gran variedad, alta calidad,bajo costo y con tiempos de producción muy rápidos. Además, la gestión de lainformación se vuelve mucho más simple y más precisa.Lean para la Producción y ServiciosUna creencia popular es que se apoyan es adecuado sólo para la fabricación. Noes cierto. Esbelta se aplica en todos los negocios y cada proceso. No es unatáctica o un programa de reducción de costes, sino una forma de pensar y deactuar para toda una organización.Los negocios en todas las industrias y servicios, incluyendo la salud y losgobiernos, están utilizando los principios lean en su forma de pensar y hacer.Muchas organizaciones optan por no utilizar la palabra pobre, pero para etiquetarlo que hacen que su propio sistema, como el Sistema de Producción Toyota o elSistema de Negocios Danaher. ¿Por qué? Para llevar a casa el punto que se
  12. 12. apoyan no es un programa o un programa a corto plazo de reducción de costos,pero la forma en que la compañía opera. La transformación de palabra o detransformación Lean a menudo se utiliza para caracterizar a una compañía móvilde una forma antigua de pensar que el pensamiento esbelto. Se requiere unatransformación completa de cómo una empresa realiza negocios. Esto toma unaperspectiva a largo plazo y la perseverancia.El término "pobre" fue acuñado para describir negocio de Toyota en la década de1980 por un equipo de investigación dirigido por JimWomack, Ph.D., en elPrograma MIT Internacional de Vehículos de Motor.Las características de una organización ágil y cadena de suministro se describenen el Pensamiento Lean, por Womack y Dan Jones, fundadores del LeanEnterprise Institute y el Lean Enterprise Academy (Reino Unido), respectivamente.Si bien hay muchos libros muy buenos sobre las técnicas Lean, Lean Thinkingsigue siendo uno de los mejores recursos para la comprensión de "lo que espobre", ya que describe el proceso de pensamiento, los principios básicosgenerales que debe guiar sus acciones cuando la aplicación de técnicas Lean yherramientas.MICROSOFT SOLUTIONS FRAMEWORKMicrosoft Solutions Framework (MSF) es un conjunto de principios, modelos,disciplinas, conceptos y directrices para la entrega de tecnología de la informaciónde las soluciones de Microsoft . MSF no se limita a las aplicaciones en desarrollosolamente, es también aplicable a otros proyectos de TI como los proyectos deimplementación, redes o infraestructura. MSF no obliga al desarrollador a utilizarun determinado método ( Cascada , Agile ), pero les permite decidir qué métodoutilizar.Principios FundamentalesLos siguientes son los ocho principios fundamentales, que forman la columnavertebral de los otros modelos y disciplinas de MSF:1. Fomentar la comunicación abierta2. Trabajar en pro de una visión compartida3. Empoderar a los miembros del equipo4. Establecer la rendición de cuentas clara y la responsabilidad compartida5. Enfoque en entregar valor de negocio
  13. 13. 6. Manténgase ágil, esperan cambiar7. Invertir en calidad8. Aprender de todas las experienciasModelos de MSFMSF se compone de dos modelos:1. MSF TeamModel. Esto describe el papel de los distintos miembros del equipoen un proyecto de desarrollo de software. Los miembros de este equipo sería elsiguiente: Gestión del producto: se ocupa principalmente de los clientes y definir los requisitos del proyecto, también se asegura de que se cumplan las expectativas del cliente. Gestión del programa: Mantiene el desarrollo de proyectos y la entrega al cliente Arquitectura: Responsable de diseño de la solución, asegurándose de que el diseño de la solución óptima satisface todas las necesidades y expectativas Desarrollo: se desarrolla de acuerdo a las especificaciones. De la prueba: Pruebas y asegura la calidad del producto Release / Operaciones: Se asegura una implementación sin problemas y de las operaciones del software Experiencia de usuario: Soporta los problemas de los usuarios.Una persona puede ser asignado para realizar múltiples funciones. MSF tambiéntiene sugerencias sobre cómo combinar las responsabilidades, tales como eldesarrollador no debe ser asignado a cualquier otro rol.2. MSF modelo de gobernanza. Este describe las diferentes etapas en elprocesamiento de un proyecto. El Modelo de Gobierno de MSF cuenta con cincopistas superpuestas de la actividad (ver más abajo), cada uno con un objetivo decalidad definido. Estas pistas de la actividad de definir lo que se necesita lograr ydejar la forma en que se llevan a cabo con la metodología del equiposeleccionado. Por ejemplo, estas pistas pueden ser pequeñas en su alcance ylleva a cabo rápidamente para ser coherente con una metodología ágil, o se puedeserializar y alargado para ser coherente con una metodología de cascada. Envision - pensar en lo que se necesita lograr y determinar las limitaciones - Plan y el diseño de una solución para satisfacer las necesidades y expectativas dentro de esas limitaciones Construir - generar la solución
  14. 14. Estabilizar - validar que la solución cumple con las necesidades y expectativas ... "Sincronizar y estabilizar" Implementar - implementar la soluciónProceso de Gestión de Proyectos de MSF Integrar la planificación y el control de cambio de conducta Definir y gestionar el alcance del proyecto Prepare un presupuesto y administrar los costos Preparar y realizar un seguimiento de los horarios Asegúrese de que los recursos se asignan a la derecha del proyecto Administrar los contratos y proveedores y recursos procuran proyecto Facilitar el equipo y las comunicaciones externas Facilitar el proceso de gestión de riesgos Documentar y supervisar el proceso del equipo de gestión de calidadMSF sobre la metodología de desarrollo ágil de softwareEl MSF para Agile de desarrollo de software (MSF4ASD) está destinado a ser unpeso ligero, iterativo y adaptable.El MSF4ASD utiliza los principios del enfoque de desarrollo ágil formulada por laAgile Alliance . El MSF4ASD proporciona una guía de procesos que se centra enlas personas y los cambios. Incluye las oportunidades de aprendizaje mediante eluso de iteraciones y evaluaciones en cada iteración.MSF para el Modelo de Madurez de la Capacidad metodología de mejora deIntegración de ProcesosEl MSF para el Modelo de Madurez de la Capacidad de integración de Mejora deProcesos (MSF4CMMI) tiene más objetos, más procesos, más signoffs, másplanificación y está destinado a los proyectos que requieren un mayor grado deformalidad y ceremonia.El MSF4CMMI es una metodología formal para la ingeniería de software.CapabilityMaturityModel fue creado en el Software EngineeringInstitute deCarnegie MellonUniversity , y es un enfoque de mejora de procesos queproporciona a las organizaciones los elementos esenciales del proceso de mejoracontinua que resulta en una reducción de SDLC , la capacidad de mejorar paracumplir con los objetivos de costes y el calendario, la construcción de productosde alta calidad. El MSF4CMMI ha ampliado la orientación MSF4ASD con laformalidad adicional, revisiones , verificación y auditoría . Esto resulta en unseptiembre que se basa en el proceso y la conformidad de procesar en lugar deconfiar exclusivamente en la confianza y la capacidad de los miembrosindividuales del equipo. El MSF4CMMI tiene más documentos obligatorios y losinformes que la versión ágil, y este proceso de desarrollo más formal reduce el
  15. 15. riesgo de grandes proyectos de software y ofrece un estado medible. Una de lasventajas de utilizar el proceso de CMMI es la evaluación estándar por el cual sepuede comparar la capacidad de desarrollar software en otras organizaciones.PROJECT MANAGEMENT INSTITUTEEl Project Management Institute (PMI®) es una organización internacional sinfines de lucro que asocia a profesionales relacionados con la Gestión deProyectos. A principios de 2011, es la más grande del mundo en su rubro, dadoque se encuentra integrada por más de 260.000 miembros en cerca de 170países. La oficina central se encuentra en la localidad de NewtownSquare, en laperiferia de la ciudad de Filadelfia, en Pennsylvania (Estados Unidos). Susprincipales objetivos son: Formular estándares profesionales en Gestión de Proyectos. Generar conocimiento a través de la investigación. Promover la Gestión de Proyectos como profesión a través de sus programas de certificación.PMBOK®La Guía del PMBOK® es un estándar en la Administración de proyectosdesarrollado por el Project Management Institute (PMI). La misma comprende dosgrandes secciones, la primera sobre los procesos y contextos de un proyecto, lasegunda sobre las áreas de conocimiento específico para la gestión de unproyecto.En 1987, el PMI publicó la primera edición del PMBOK® en un intento pordocumentar y estandarizar información y prácticas generalmente aceptadas en lagestión de proyectos. La edición actual, la cuarta, provee de referencias básicas acualquiera que esté interesado en la gestión de proyectos. Posee un léxico comúny una estructura consistente para el campo de la gestión de proyectosLa Guía del PMBOK es ampliamente aceptada por ser el estándar en la gestión deproyectos, sin embargo existen algunas críticas: La mayor viene de los seguidoresde la Cadena Crítica (en oposición al Método de la ruta crítica). EL PMBOK seencuentra disponible en 11 idiomas: inglés, español, chino simplificado, ruso,coreano, japonés, italiano, alemán, francés, portugués de Brasil y árabe.PMBOK®El PMBOK es una colección de procesos y áreas de conocimiento generalmenteaceptadas como las mejores prácticas dentro de la gestión de proyectos. ElPMBOK es un estándar reconocido internacionalmente (IEEE Std 1490-2003) queprovee los fundamentos de la gestión de proyectos que son aplicables a un ampliorango de proyectos, incluyendo construcción, software, ingeniería, etc.
  16. 16. El PMBOK reconoce 5 grupos de procesos básicos y 9 áreas de conocimientocomunes a casi todos los proyectos.Los procesos se traslapan e interactúan a través de un proyecto o fase y sondescritos en términos de: Entradas (documentos, planes, diseños, etc.) Herramientas y Técnicas (mecanismos aplicados a las entradas) Salidas (documentos, productos, etc.).Grupos básicos de ProcesosLos 5 grupos básicos de procesos son:1. Iniciación: Define y autoriza el proyecto o una fase del mismo. Está formado por dos procesos.2. Planificación: Define, refina los objetivos y planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto. Está formado por veinte procesos.3. Ejecución: Compuesto por aquellos procesos realizados para completar el trabajo definido en el plan a fin de cumplir con las especificaciones del mismo. Implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto. Está formado por ocho procesos.4. Seguimiento y Control: Mide, supervisa y regula el progreso y desempeño del proyecto, para identificar áreas en las que el plan requiera cambios. Está formado por diez procesos.5. Cierre: Formaliza la aceptación del producto, servicio o resultado, y termina ordenadamente el proyecto o una fase del mismo. Está formado por dos procesos.
  17. 17. PRINCE2PRojects IN ControlledEnvironments (PRINCE), en español: proyectos enentornos controlados, es un método de gestión de proyectos que cubre laadministración, control y organización de un proyecto. PRINCE2 es una marcaregistrada de la OGC del Reino Unido.PRINCE2 fue originalmente desarrollado por la CCTA que actualmente formaparte de la OGC. Desde 1989 se viene usando como un estándar para la gestiónde proyectos sobre todo en el Reino Unido. Este método fue inicialmentedesarrollado únicamente para proyectos TIC, la última versión, PRINCE2, escompatible con la gestión de todo tipo de proyectos.La revisión más reciente se publicó el 16 de junio de 2009 por la OGC siendodenominada esta versión como PRINCE2:2009 Refresh.DRAEl Desarrollo Rápido de Aplicaciones (DRA) (rapidapplicationDevelopment RAD)es un modelo de proceso del desarrollo del software lineal secuencial que enfatizaun ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Altavelocidad” en el que se logra el desarrollo rápido utilizando un enfoque deconstrucción basado en componentes. Si se comprenden bien los requisitos y selimita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crearun “sistema completamente funcional” dentro de periodos cortos de tiempo.Cuando se utiliza principalmente para aplicaciones de sistemas de información, elenfoque DRA comprende las siguientes fases:Modelado de gestión: el flujo de información entre las funciones de gestión semodela de forma que responda a las siguientes preguntas: ¿Qué informaciónconduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera?¿A dónde va la información? ¿Quién la proceso?Modelado de datos: el flujo de información definido como parte de la fase demodelado de gestión se refina como un conjunto de objetos de datos necesariospara apoyar la empresa. Se definen las características (llamadas atributos) decada uno de los objetos y las relaciones entre estos objetos.Modelado de proceso: los objetos de datos definidos en la fase de modelado dedatos quedan transformados para lograr el flujo de información necesario paraimplementar una función de gestión. Las descripciones del proceso se crean paraañadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicaciónentre los objetos.Generación de aplicaciones: El DRA asume la utilización de técnicas de cuartageneración. En lugar de crear software con lenguajes de programación de tercerageneración, el proceso DRA trabaja para volver a utilizar componentes deprogramas ya existentes (cuando es posible) o a crear componentes reutilizables(cuando sea necesario). En todos los casos se utilizan herramientas automáticaspara facilitar la construcción del software.Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se hancomprobado muchos de los componentes de los programas. Esto reduce tiempode pruebas. Sin embargo, se deben probar todos los componentes nuevos y sedeben ejercitar todas las interfases a fondo.
  18. 18. CRYSTALCrystal es una metodología de desarrollo de Software ágil, más que unametolodogía se la considera una familia de metodologías, debido a que sesubdivide en varios tipos de metodologías en función a la cantidad de persona quevayan a estar en el proyecto. Es una metodología que ha sido creada por unapersona en particular (Alistair Cockburn ) el cuál llego la creó en base al análisisde distintos proyectos de desarrollo de SW y su propia experiencia, lo cuálfusionando ambos aspectos dio lugar a una metodología bastante interesante, lacual se presenta a continuación. Desarrollo de la metodologíaAntecedentesEn los inicios de 1990, en un estudio realizado en IBM se llegó a los siguientes acuerdos (Cockburn, 2001).Los equipos exitosos enfatizaban que no habían seguido métodos formales ni herramientas CASE y que habían estimulado la comunicación y los test.Los equipos con problemas no entendían sus fallas o si habían cumplido con los métodos formales.Qué es Crystal ClearCrystal Clear no es una metodología en si misma sino una familia de metodologíascon un “código genético” común.El nombre Crystal deriva de la caracterización de los proyectos según 2dimensiones, tamaño y complejidad (como en los minerales, color y dureza).Por ejemplo. Clear es para equipos de hasta 8 personas o menos. Amarillo para equipos entre 10 a 20 personas. Naranja para equipos entre 20 a 50 persona. Roja para equipos entre 50 a 100 personas. Azul para equipos entre 100 a 200 personas.CC puede ser usado en proyectos pequeños y como casi todos los otros métodos,CC consiste en valores, técnicas y procesos.En primera instancia se especifican los antecedentes de la metodología, continuando con definiciones queayudan a estructurar la fundamentación teórica y se termina con las características esenciales de los diferentestipos de Crystal.
  19. 19. La conclusión:Menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. Loprimero son promesas, lo segundo hechos. Cada proyecto necesita sus propios métodos. Alistair Cockburn en lugar de partir solamente de su experiencia personalpara construir una teoría de cómo deben hacerse las cosascomplementa su experiencia directa con la búsqueda activa de proyectos para vercómo trabajan. Él ha explorado a fondo los métodos ágiles, haciendo énfasis en la familia de metodologías Crystal. Es unafamilia porque cree que los diferentes tipos de proyectos requieren diferentes tipos de metodologías. Él miraesta variación a lo largo de dos ejes: el número de personas en el proyecto, y las consecuencias de los errores.Cada metodología encaja en una parte diferente, de modo que para un proyecto de 40 personas que puedeperder dinero discrecionalmente tiene una metodología diferente a la de un proyecto vital de seis personasKANBANEl Kanban es un sistema de información que controla de modo armónico lafabricación de los productos necesarios en la cantidad y tiempo necesarios encada uno de los procesos que tienen lugar tanto en el interior de la fábrica comoentre distintas empresas. También se denomina “sistema de tarjetas”, pues en suimplementación más sencilla utiliza son tarjetas que se pegan en los contenedoresde materiales y que se despegan cuando estos contenedores son utilizados, paraasegurar la reposición de dichos materiales. Las tarjetas actúan de testigo del
  20. 20. proceso de producción. Otras implementaciones más sofisticadas utilizan la mismafilosofía, sustituyendo las tarjetas por otros métodos de visualización del flujo. ElKanban se considera un subsistema del JIT.TSPEn combinación con el Personal Software Process (PSP), el llamado TeamSoftware Process (TSP) proporciona un marco de trabajo de procesos definidosque está diseñado para ayudarle a equipos de gerentes e ingenieros a organizar yproducir proyectos de software de gran escala, que tengan tamaños mayores avarios miles de líneas de código. El objetivo del TSP es mejorar los niveles decalidad y productividad de un proyecto de desarrollo de software de un equipo, conel fin de ayudarlos a alcanzar los acuerdos de costos y tiempos en dichodesarrollo.La versión inicial del TSP fue desarrollada por Watts Humphrey en 1996, y elprimer Reporte Técnico para TSP fue publicado en el año 2000, patrocinado por elDepartamento de Defensa de los Estados Unidos. El libro de Watts Humphreyllamado "IntroductiontotheTeam Software Process" (Addison Wesley Professional,Massachusetts, 1999), presenta el TSP en detalle y se enfoca en el proceso de laconstrucción de un equipo productor de software, estableciendo objetivos delequipo, distribuyendo los roles, y otras actividades de trabajo en equipo.PSPEl Personal Software Process, conocido por sus siglas como PSP, es unametodología de reciente creación, proveniente del Instituto de Ingeniería delSoftware(SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, queles permite mejorar la forma en la que construyen software. Considerandoaspectos como la planeación, calidad, estimación de costos y productividad, PSPes una metodología que vale la pena revisar cuando el ingeniero de software estáinteresado en aumentar la calidad de los productos de software que desarrolladentro de un contexto de trabajo individual.CARACTERISTICASEn PSP todas las tareas y actividades que el ingeniero de software debe realizardurante el proceso de desarrollo de un producto de software, están puntualmentedefinidas en un conjunto de documentos conocidos como scripts. Los scripts sonel punto medular de PSP, por lo que se hace mucho énfasis en que deben serseguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora quese busca. Gran parte de las tareas y actividades definidas en los scripts generaráen su realización un conjunto de datos, fundamentalmente de carácter estadístico.La aplicación de PSP en varios procesos de desarrollo, y el análisis de lainformación estadística generada en cada uno de éstos, permitirán al ingeniero desoftware identificar, tanto sus fortalezas como sus debilidades, y crecer a través deun proceso de autoaprendizaje y auto mejora.
  21. 21. La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad dedefectos que el producto de software contiene.En este nivel se introducen algunos métodos aplicables al proceso de desarrollode software, dentro de un enfoque de proyectos a gran escala, pero sin lidiar conproblemas de comunicación y coordinación de los equipos de trabajo.PASOS A SEGUIRLos scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndoseen cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo desoftware. Al primer nivel se le conoce como 0 o de medición personal, al segundocomo nivel1 o de planeación personal, al tercero, como nivel 2 o de calidadpersonal, y al cuarto, como nivel 3 o cíclico personal. Cada uno de estos niveles,con excepción del 3, tiene una versión que los extiende, introduciendo tareas yactividades para un mejor manejo de los aspectos de interés en nivel, o bien paraincluir nuevos aspectos, verla si la siguiente figura. Cada uno de los nivelesextiende los aspectos considerados en el nivel inmediato anterior. Una de lasrazones de esta clasificación puede ser el que PSP es una metodología de mejorabasada en datos estadísticos, los cuales deben ser cuidadosamente recabadospor el ingeniero de software; el aumento gradual de la cantidad de datos que deberecolectar el ingeniero introduce, por consiguiente, el cambio en su manera detrabajo de una manera paulatina. Se recomienda un uso incremental de PSP,iniciando con el nivel más bajo durante un primer proyecto de desarrollo y, enproyectos siguientes, ascendiendo a niveles superiores. Los scripts no puedenutilizase en forma separada o desordenada.VENTAJAS Y DESVENTAJAS PARA UTILIZAR PSPPSP es una alternativa, de las muchas que han surgido recientemente, paramejorar el proceso de desarrollo de software. Más que clasificar un conjunto desentencias como ventajas o desventajas, a continuación se citan algunascaracterísticas: PSP es una metodología basada en estimación. La estimación permite saber cuándo y cómo se desarrollan las tareas de un proceso, por lo que podría citarse como un aspecto importante de esta metodología el estar basada en métricas y estimaciones. La información de las métricas y estimaciones se utiliza para evaluar y mejorar procesos futuros. PSP parte de la premisa que, si el ingeniero de software conoce sus fortalezas y debilidades, puede establecer las acciones necesarias para erradicar o explotar los aspectos identificados en la forma en que desarrolla software. Aunque lo mencionado en el punto anterior podría sonar bastante atractivo, la forma de llegar a ese auto conocimiento puede resultar tediosa y, en el
  22. 22. peor de los casos, una pesadilla para el desarrollador. Salvo muy pocas excepciones, los ingenieros de software nunca realizan procedimientos formales para conocer la forma en que trabajan, no saben con exactitud cuántas líneas de código generan por hora, cuánto tiempo invierten al corregir un error, cuánto tiempo invierten en pruebas, etcétera. Los pasos de registro de información a detalle en el nivel de medición pueden resultar frustrantes cuando se tiene presión de tiempo. En los scripts de PSP no se incluyen tareas y actividades para la etapa de análisis de requerimientos. Siempre se parte de una definición de requerimientos que no va a cambiar. Aún no existe una herramienta automatizada que facilite el registro y análisis de datos generados por la aplicación de PSP.RUPEl RationalUnifiedProcess (RUP) es un iterativoproceso de desarrollo desoftware creado por el marco de Rational SoftwareCorporation, una división deIBM desde el año 2003. [1] RUP no es un único proceso normativo concreto, sinomás bien un proceso de adaptación marco , la intención de ser medida por lasorganizaciones de desarrollo de software y equipos de proyectos que seseleccionan los elementos del proceso que son apropiados para sus necesidades.RUP es una implementación específica del Proceso Unificado .

×