CAPABILITY MATURITY MODEL INTEGRATION (CMMI)Integración de modelos de madurez de capacidades o Capability maturity model integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

Modelos CMMI

Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la 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.2 disponible:

CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), 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 for Acquisition), 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 for Services), 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ón\modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada (por ejemplo, usando un método de evaluación como SCAMPI y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organización, puede coger áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización.

OPENUP ENTERPRISE UPOpenUP es un método y un proceso de desarrollo de software propuesto por un conjunto de empresas de tecnología,[1] quienes lo donaron en el año 2007 a la Fundación Eclipse. La fundación lo ha publicado bajo una licencia libre [2] y lo mantiene como método de ejemplo dentro del proyecto Eclipse Process Framework.

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

participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidad

Organización de los componentes del OpenUP

El OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas: el método y el proceso. El contenido del método es donde los elementos del método (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuenta como son utilizados en el ciclo de vida del proyecto. El proceso es donde los elementos del método son aplicados de forma ordenada en el tiempo. Muchos ciclos de vida para diferentes proyectos pueden ser creados a partir del mismo conjunto de elementos del método.

eXtreme Programming (XP)

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Valores

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue

añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:

Simplicidad:

La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple 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 adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.

Comunicación:

La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características tienen prioridad y siempre debe estar disponible para solucionar dudas.

Retroalimentación (feedback):

Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. 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 del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código.

Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.

Coraje o valentía:

Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar todo lo demás del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es persistente.

Respeto:

El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.

Características de Scrum

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados 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 entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser

completamente entendido o definido, y centrándose en maximizar la capacidad del equipo 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, y requiere muy poco esfuerzo para comenzarse a utilizar.

INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL)La Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente abreviada ITIL (del inglés Information Technology Infrastructure Library), es un conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologí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.

Historia

Aunque se desarrolló durante los años 1980, ITIL no fue ampliamente adoptada hasta mediados de los años 1990. Esta mayor adopción y conocimiento ha llevado a varios estándares, incluyendo ISO/IEC 20000, que es una norma internacional cubriendo los elementos de gestión de servicios de TI de ITIL. ITIL se considera a menudo junto con otros marcos de trabajo de mejores prácticas como la Information Services Procurement Library (ISPL, ‘Biblioteca de adquisición de servicios de información’), la Application Services Library (ASL, ‘Biblioteca de servicios de aplicativos’), el método de desarrollo de sistemas dinámicos (DSDM, Dynamic Systems Development Method), el Modelo de Capacidad y Madurez (CMM/CMMI) y a menudo se relaciona con la gobernanza de tecnologías de la información mediante COBIT (Control Objectives for Information and related Technology).

El concepto de gestión de servicios de TI, aunque relacionado con ITIL, no es idéntico: ITIL contiene una sección específicamente titulada «Gestión de Servicios de TI» (la combinación de los volúmenes de Servicio de Soporte y Prestación de Servicios, que son un ejemplo específico de un marco ITSM). Sin embargo es importante señalar que existen otros marcos parecidos. La Gestión de Servicio ITIL 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 y gestión de las operaciones a menudo atribuida a W. Edwards Deming. Las recomendaciones de ITIL fueron desarrolladas en los años 1980 por la Central

Computer and Telecommunications Agency (CCTA) del gobierno británico como respuesta a la creciente dependencia de las tecnologías de la información y al reconocimiento de que sin prácticas estándar, los contratos de las agencias estatales y del sector privado creaban independientemente sus propias prácticas de gestión de TI y duplicaban esfuerzos dentro de sus proyectos TIC, lo que resultaba en errores comunes y mayores costes.

ITIL fue publicado como un conjunto de libros, cada uno dedicado a un área especí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 of Government Commerce (‘Oficina de comercio gubernamental’, OGC), que es una división del Ministerio de Hacienda del Reino Unido.

En abril de 2001 la CCTA fue integrada en la OGC, desapareciendo como organización separada.1

En diciembre de 2005, la OGC emitió un aviso de una actualización a ITIL,2

conocida comúnmente como ITIL v3, que estuvo planificada para ser publicada a finales de 2006; habiendo sido realizada en junio de 2007. Se esperaba que la publicació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 los Servicios 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 al Ciclo de Vida de los Servicios.

Uno de los principales beneficios propugnado por los defensores de ITIL dentro de la comunidad de TI es que proporciona un vocabulario común, consistente en un glosario de términos precisamente definidos y ampliamente aceptados. Un nuevo glosario ampliado ha sido desarrollado como entregable clave de ITIL versión 3.

Otros modelos: CMMI para el desarrollo de software y s3m,3 para el mantenimiento del software

COBIT

COBIT es un marco creado por ISACA para la tecnología de la información (TI) y el Gobierno de TI . It is a supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. Se trata de un conjunto de herramientas de apoyo que permite a 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 en los sistemas de información y en la información que estos produzcan. Cobit permite entender como dirigir y gestionar el uso de tales sistemas así como establecer un codigo de buenas practicas a ser utilizado por los proveedores de sistemas. Cobit suministra las herramientas para supervisar todas las actividades relacionadas 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.

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 y las que no es enorme. Cobit permite el desarrollo de políticas claras y buenas prácticas para la gestión de IT. Su marco de referencia permite gestionar los riesgos de IT y asegurar el cumplimiento, la continuidad, seguridad y privacidad.

Al ser Cobit reconocida y aceptada internacionalmente como una herramienta de gestió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 las demás compañías. Así como existen procesos genéricos de muchos tipos de negocios, existen estándares y buenas practicas específicos para IT que deben seguirse por las compañías cuando se soportan en IT, en donde Cobit agrupa tales estándares y entrega un marco de referencia para su implementación y gestión.

Una vez se identifican e implementan los principios relevantes de Cobit para una compañía, se obtiene plena confianza en que todos los recursos de sistemas estan 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 lo siguiente:

Marco de referencia: explica como Cobit organiza 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.

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.

LEAN

QUE 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 menos recursos.

Una organización ágil entiende el valor del cliente y enfoca sus procesos clave para aumentar continuamente. El objetivo final es aportar un valor ideal para el cliente a través de un proceso de creación de valor perfecta que tiene cero de residuos.

Para lograr esto, los cambios de pensamiento lean el enfoque de la gestión de la optimización de las tecnologías por separado, los activos, y los departamentos verticales para optimizar el flujo de productos y servicios a través de cadenas de valor enteras que fluyen horizontalmente a través de las tecnologías, los activos, y los departamentos a los clientes.

La eliminación de los residuos a lo largo de cadenas de valor completas, en lugar de en puntos aislados, crea procesos que requieren menos esfuerzo humano, menos espacio, menos capital y menos tiempo para hacer los productos y servicios a costos mucho menos y mucho menos con defectos, en comparación con los sistemas empresariales tradicionales . Las empresas son capaces de responder 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 la información se vuelve mucho más simple y más precisa.

Lean para la Producción y Servicios

Una creencia popular es que se apoyan es adecuado sólo para la fabricación. No es cierto. Esbelta se aplica en todos los negocios y cada proceso. No es una táctica o un programa de reducción de costes, sino una forma de pensar y de actuar para toda una organización.

Los negocios en todas las industrias y servicios, incluyendo la salud y los gobiernos, están utilizando los principios lean en su forma de pensar y hacer. Muchas organizaciones optan por no utilizar la palabra pobre, pero para etiquetar lo que hacen que su propio sistema, como el Sistema de Producción Toyota o el Sistema de Negocios Danaher. ¿Por qué? Para llevar a casa el punto que se

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 de transformación Lean a menudo se utiliza para caracterizar a una compañía móvil de una forma antigua de pensar que el pensamiento esbelto. Se requiere una transformación completa de cómo una empresa realiza negocios. Esto toma una perspectiva a largo plazo y la perseverancia.

El término "pobre" fue acuñado para describir negocio de Toyota en la década de 1980 por un equipo de investigación dirigido por Jim Womack, Ph.D., en el Programa MIT Internacional de Vehículos de Motor.

Las características de una organización ágil y cadena de suministro se describen en el Pensamiento Lean, por Womack y Dan Jones, fundadores del Lean Enterprise Institute y el Lean Enterprise Academy (Reino Unido), respectivamente. Si bien hay muchos libros muy buenos sobre las técnicas Lean, Lean Thinking sigue siendo uno de los mejores recursos para la comprensión de "lo que es pobre", ya que describe el proceso de pensamiento, los principios básicos generales que debe guiar sus acciones cuando la aplicación de técnicas Lean y herramientas.

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ón de las soluciones de Microsoft . MSF is not limited to developing applications only, it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF no se limita a las aplicaciones en desarrollo solamente, es también aplicable a otros proyectos de TI como los proyectos de implementación, redes o infraestructura. MSF does not force the developer to use a specific ( , ) but lets them decide what to use. MSF no obliga al desarrollador a utilizar un determinado método ( Cascada , Agile ), pero les permite decidir qué método utilizar.

Principios Fundamentales

Los siguientes son los ocho principios fundamentales, que forman la columna vertebral de los otros modelos y disciplinas de MSF:

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 de MSF

MSF se compone de dos modelos:

1. MSF Team Model. Esto describe el papel de los distintos miembros del equipo en un proyecto de desarrollo de software. Los miembros de este equipo sería el siguiente:

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én tiene sugerencias sobre cómo combinar las responsabilidades, tales como el desarrollador no debe ser asignado a cualquier otro rol.

2. MSF modelo de gobernanza. Este describe las diferentes etapas en el procesamiento de un proyecto. El Modelo de Gobierno de MSF cuenta con cinco pistas superpuestas de la actividad (ver más abajo), cada uno con un objetivo de calidad definido. Estas pistas de la actividad de definir lo que se necesita lograr y dejar la forma en que se llevan a cabo con la metodología del equipo seleccionado. Por ejemplo, estas pistas pueden ser pequeñas en su alcance y lleva a cabo rápidamente para ser coherente con una metodología ágil, o se puede serializar 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 Estabilizar - validar que la solución cumple con las necesidades y

expectativas ... "Sincronizar y estabilizar" Implementar - implementar la solución

Proceso 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 calidad

MSF sobre la metodología de desarrollo ágil de software

El MSF para Agile de desarrollo de software (MSF4ASD) está destinado a ser un peso ligero, iterativo y adaptable.

El MSF4ASD utiliza los principios del enfoque de desarrollo ágil formulada por la Agile Alliance . El MSF4ASD proporciona una guía de procesos que se centra en las personas y los cambios. Incluye las oportunidades de aprendizaje mediante el uso de iteraciones y evaluaciones en cada iteración.

MSF para el Modelo de Madurez de la Capacidad metodología de mejora de Integración de Procesos

El MSF para el Modelo de Madurez de la Capacidad de integración de Mejora de Procesos (MSF4CMMI) tiene más objetos, más procesos, más signoffs, más planificación y está destinado a los proyectos que requieren un mayor grado de formalidad y ceremonia.

El MSF4CMMI es una metodología formal para la ingeniería de software. Capability Maturity Model fue creado en el Software Engineering Institute de Carnegie Mellon University , y es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales del proceso de mejora continua que resulta en una reducción de SDLC , la capacidad de mejorar para cumplir con los objetivos de costes y el calendario, la construcción de productos de alta calidad. El MSF4CMMI ha ampliado la orientación MSF4ASD con la formalidad adicional, revisiones , verificación y auditoría . Esto resulta en un septiembre que se basa en el proceso y la conformidad de procesar en lugar de

confiar exclusivamente en la confianza y la capacidad de los miembros individuales del equipo. El MSF4CMMI tiene más documentos obligatorios y los informes que la versión ágil, y este proceso de desarrollo más formal reduce el riesgo de grandes proyectos de software y ofrece un estado medible. Una de las ventajas de utilizar el proceso de CMMI es la evaluación estándar por el cual se puede comparar la capacidad de desarrollar software en otras organizaciones.

PROJECT MANAGEMENT INSTITUTEEl Project Management Institute (PMI®) es una organización internacional sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos. A principios de 2011, es la más grande del mundo en su rubro, dado que se encuentra integrada por más de 260.000 miembros en cerca de 170 países. La oficina central se encuentra en la localidad de Newtown Square, en la periferia de la ciudad de Filadelfia, en Pennsylvania (Estados Unidos). Sus principales 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 proyectos desarrollado por el Project Management Institute (PMI). La misma comprende dos grandes secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto.

En 1987, el PMI publicó la primera edición del PMBOK® en un intento por documentar y estandarizar información y prácticas generalmente aceptadas en la gestión de proyectos. La edición actual, la cuarta, provee de referencias básicas a cualquiera que esté interesado en la gestión de proyectos. Posee un léxico común y una estructura consistente para el campo de la gestión de proyectos

La Guía del PMBOK es ampliamente aceptada por ser el estándar en la gestión de proyectos, sin embargo existen algunas críticas: La mayor viene de los seguidores de la Cadena Crítica (en oposición al Método de la ruta crítica). EL PMBOK se encuentra 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 generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK es un estándar reconocido internacionalmente (IEEE Std 1490-2003) que

provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc.

El 'PMBOK' reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento comunes a casi todos los proyectos.

Los procesos se traslapan e interactúan a través de un proyecto o fase y son descritos 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 Procesos

Los 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.

PRINCE2

PRojects IN Controlled Environments (PRINCE), en español: proyectos en entornos controlados, es un método de gestión de proyectos que cubre la administración, control y organización de un proyecto. PRINCE2 es una marca registrada de la OGC del Reino Unido. PRINCE2 fue originalmente desarrollado por la CCTA que actualmente forma parte de la OGC. Desde 1989 se viene usando como un estándar para la gestión de proyectos sobre todo en el Reino Unido. Este método fue inicialmente desarrollado únicamente para proyectos TIC, la última versión, PRINCE2, es compatible 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 siendo denominada esta versión como PRINCE2:2009 Refresh.

DRAEl Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce 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 de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos. Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables

(cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.

CRYSTALCrystal es una metodología de desarrollo de Software ágil, más que una metolodogía se la considera una familia de metodologías, debido a que se subdivide en varios tipos de metodologías en función a la cantidad de persona que vayan a estar en el proyecto. Es una metodología que ha sido creada por una persona en particular (Alistair Cockburn ) el cuál llego la creó en base al análisis de distintos proyectos de desarrollo de SW y su propia experiencia, lo cuál fusionando ambos aspectos dio lugar a una metodología bastante interesante, la cual se presenta a continuación.

Desarrollo de la metodología

Antecedentes 

En 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 Clear

Crystal Clear no es una metodología en si misma sino una familia de metodologías con un “código genético” común.El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, 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 que ayudan a estructurar la fundamentación teórica y se termina con las características esenciales de los diferentestipos de Crystal.

 La conclusión: 

Menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. Lo  primero son promesas, lo segundo hechos. Cada proyecto necesita sus propios métodos. Alistair Cockburn en lugar de partir solamente de su experiencia personal para construir una teoría de cómo deben hacerse las cosas complementa su experiencia directa con la búsqueda activa de proyectos para ver cómo trabajan.

 Él ha explorado a fondo los métodos ágiles, haciendo énfasis en la familia de metodologías Crystal. Es una  familia porque cree que los diferentes tipos de proyectos requieren diferentes tipos de metodologías. Él mira  esta 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 puede  perder dinero discrecionalmente tiene una metodología diferente a la de un proyecto vital de seis personas

KANBAN

El Kanban es un sistema de información que controla de modo armónico la fabricación de los productos necesarios en la cantidad y tiempo necesarios en cada uno de los procesos que tienen lugar tanto en el interior de la fábrica como entre distintas empresas. También se denomina “sistema de tarjetas”, pues en su implementación más sencilla utiliza son tarjetas que se pegan en los contenedores de materiales y que se despegan cuando estos contenedores son utilizados, para asegurar la reposición de dichos materiales. Las tarjetas actúan de testigo del proceso de producción. Otras implementaciones más sofisticadas utilizan la misma filosofía, sustituyendo las tarjetas por otros métodos de visualización del flujo. El Kanban se considera un subsistema del JIT.

TSPEn combinación con el Personal Software Process (PSP), el llamado Team Software Process (TSP) proporciona un marco de trabajo de procesos definidos que está diseñado para ayudarle a equipos de gerentes e ingenieros a organizar y producir proyectos de software de gran escala, que tengan tamaños mayores a varios miles de líneas de código. El objetivo del TSP es mejorar los niveles de calidad y productividad de un proyecto de desarrollo de software de un equipo, con el fin de ayudarlos a alcanzar los acuerdos de costos y tiempos en dicho desarrollo.La versión inicial del TSP fue desarrollada por Watts Humphrey en 1996, y el primer Reporte Técnico para TSP fue publicado en el año 2000, patrocinado por el Departamento de Defensa de los Estados Unidos. El libro de Watts Humphrey llamado "Introduction to the Team Software Process" (Addison Wesley Professional, Massachusetts, 1999), presenta el TSP en detalle y se enfoca en el proceso de la construcción de un equipo productor de software, estableciendo objetivos del equipo, distribuyendo los roles, y otras actividades de trabajo en equipo.

PSP

El Personal Software Process, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software(SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad, PSP es 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 desarrolla dentro de un contexto de trabajo individual.

CARACTERISTICAS

En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son

el punto medular de PSP, por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se 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 la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso de autoaprendizaje y auto mejora.

La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos que el producto de software contiene.

En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de software, dentro de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicación y coordinación de los equipos de trabajo.

PASOS A SEGUIR

Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndose en cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo de software. Al primer nivel se le conoce como 0 o de medición personal, al segundo como nivel1 o de planeación personal, al tercero, como nivel 2 o de calidad personal, 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 y actividades para un mejor manejo de los aspectos de interés en nivel, o bien para incluir nuevos aspectos, verla si la siguiente figura. Cada uno de los niveles extiende los aspectos considerados en el nivel inmediato anterior. Una de las razones de esta clasificación puede ser el que PSP es una metodología de mejora basada en datos estadísticos, los cuales deben ser cuidadosamente recabados por el ingeniero de software; el aumento gradual de la cantidad de datos que debe recolectar el ingeniero introduce, por consiguiente, el cambio en su manera de trabajo 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, en proyectos siguientes, ascendiendo a niveles superiores. Los scripts no pueden utilizase en forma separada o desordenada.

VENTAJAS Y DESVENTAJAS PARA UTILIZAR PSP

PSP es una alternativa, de las muchas que han surgido recientemente, para mejorar el proceso de desarrollo de software. Más que clasificar un conjunto de sentencias como ventajas o desventajas, a continuación se citan algunas caracterí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 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 Rational Unified Process (RUP) es un iterativo proceso de desarrollo de software creado por el marco de Rational Software Corporation, una división de IBM desde el año 2003. [1] RUP no es un único proceso normativo concreto, sino más bien un proceso de adaptación marco , la intención de ser medida por las organizaciones de desarrollo de software y equipos de proyectos que se seleccionan los elementos del proceso que son apropiados para sus necesidades. RUP is a specific implementation of the . RUP es una implementación específica del Proceso Unificado .