1) CMMI es un modelo para la mejora y evaluación de procesos de desarrollo, mantenimiento y operación de sistemas de software. 2) Existen tres modelos CMMI que cubren desarrollo, adquisición y servicios. 3) Las organizaciones no pueden ser certificadas CMMI, sino que reciben una calificación después de una evaluación.

1. CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
Integración de modelos de madurez de capacidades o
Capabilitymaturitymodelintegration (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 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, 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.

2. OPENUP ENTERPRISE UP
OpenUP 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 libre2 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

3. 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.
eXtremeProgramming (XP)
La programación extrema o eXtremeProgramming (XP) es un enfoque de la
ingeniería de software formulado por Kent Beck, autor del primer libro sobre la
materia, Extreme ProgrammingExplained: 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

4. añadido en la segunda edición de Extreme ProgrammingExplained. 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.

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

6. 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 ProductBacklog, que es un conjunto de requisitos de alto nivel
priorizados que definen el trabajo a realizar. Los elementos del ProductBacklog
que forman parte del sprint se determinan durante la reunión de Sprint Planning.
Durante esta reunión, el ProductOwner identifica los elementos del
ProductBacklog 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 requirementschurn), 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

7. 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ésInformationTechnologyInfrastructure 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
InformationServicesProcurement Library (ISPL, „Biblioteca de adquisición de
servicios de información‟), la ApplicationServices Library (ASL, „Biblioteca de
servicios 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 la
información mediante COBIT (Control ObjectivesforInformation and
relatedTechnology).
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

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

9. COBIT
COBIT es un marco creado por ISACA para la tecnología de la información (TI) y
el Gobierno de TI . 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.

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

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 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 JimWomack, 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 FRAMEWORK
Microsoft 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 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 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

13. 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 TeamModel. 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

14. 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.
CapabilityMaturityModel fue creado en el Software EngineeringInstitute de
Carnegie MellonUniversity , 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

15. 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 INSTITUTE
El 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 NewtownSquare, 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.

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

17. PRINCE2
PRojects IN ControlledEnvironments (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.
DRA
El Desarrollo Rápido de Aplicaciones (DRA) (rapidapplicationDevelopment 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.

18. CRYSTAL
Crystal 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 ac
uerdos (Cockburn, 2001).
Los equipos exitosos enfatizaban que no habían seguido métodos formales ni herr
amientas 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, continuan
do con definiciones que
ayudan a estructurar la fundamentación teórica y se termina con las características
esenciales de los diferentestipos de Crystal.

19. La conclusión:
Menos énfasis en la documentación exhaustiva y más en versiones que corran y p
uedan 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 met
odologí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 c
onsecuencias de los errores.
Cada metodología encaja en una parte diferente, de modo que para un proyecto d
e 40 personas que puede
perder dinero discrecionalmente tiene una metodología diferente a la de un proyec
to 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

20. 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.
TSP
En 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 "IntroductiontotheTeam 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.

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

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.
RUP
El RationalUnifiedProcess (RUP) es un iterativoproceso de desarrollo de
software creado por el marco de Rational SoftwareCorporation, 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 es una implementación específica del Proceso Unificado .