INDICE

………………………

………………………..

……………………….
 INTRODUCCION

Un modelo de proceso para desarrollo de software es el conjunto de actividades

necesarias para transformar los requerimientos del usuario en un sistema de
software.

Cada una de dichas actividades tiene asociado un conjunto de módulos asociados

a las mismas en el cual se vinculan la documentación de entrada que se necesita
para realizar la actividad, la documentación de salida que se pretende de la misma
y el o los roles de quienes deben llevar a cabo dicha actividades hecho de estar
modularizado nos permite de esta formas poder agregar o quitar actividades ,
modificar documentación de entrada o salida vinculada a la misma  o bien cambiar
los roles  en  las distintas actividades sin que esto se convierta en una tarea
pesada para futuros proyectos de Ingeniería de Software
Metodología del Ciclo de Vida
El modelo de ciclo de vida en cascada es el modelo más simple en desarrollo de
software. En él las etapas se llevan a cabo una detrás de otra de forma lineal. Este
modelo exige un enfoque sistemático y secuencial del desarrollo del software ya
que, cada fase genera entradas y documentación para la siguiente, así solo
cuando la primera fase se termine se puede empezar con la segunda, y así
progresivamente.
Este modelo asume que todo se lleva a cabo y tiene lugar tal y como se había
planeado en la fase anterior, y no es necesario pensar en asuntos pasados que
podrían surgir en la siguiente fase. Este modelo no funcionará correctamente si se
dejan asuntos de lado en la fase previa. La naturaleza secuencial del modelo no
permite volver atrás y deshacer o volver a hacer acciones.
Este modelo es recomendable cuando el desarrollador ya ha diseñado y
desarrollado aplicaciones similares con anterioridad, es decir, tiene la experiencia
suficiente para terminar con una etapa y comenzar la siguiente.
El ciclo de vida clásico tiene tres fases en que se agrupan las etapas:
 Definición del     problema, que incluye tanto la especificación de requisitos
como el análisis del sistema.
 Desarrollo, que abarca el diseño, implementación y pruebas del sistema.
 Mantenimiento, es decir, la instalación y el mantenimiento del sistema.
Proceso Unificado Racional
Su objetivo es asegurar la producción de alta calidad que satisfaga las
necesidades de sus usuarios finales, dentro de un calendario y presupuesto
predecibles 
La metodología de desarrollo RUP o Proceso de Desarrollo Unificado es un
proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado,
constituye la metodología estándar más utilizada para el análisis, implementación
y documentación de sistemas orientados a objetos. El Proceso de Desarrollo
Unificado no es un sistema con pasos firmemente establecidos, sino un conjunto
de metodologías adaptables al contexto y necesidades de cada organización.
El Proceso Unificado Racional mejora la productividad del equipo, al proporcionar
a cada miembro del equipo un fácil acceso a conocimientos bases con directrices,
plantillas y mentores de herramientas para todas las actividades de desarrollo
críticas. Todos los miembros del equipo acceden a la misma base de
conocimientos, sin importar si trabajan con requisitos, diseño, prueba, proyecto o
gestión de configuración, este método se asegura de que todos los miembros del
equipo compartan un lenguaje común, el proceso y la visión de cómo desarrollar el
software.
Las actividades del Proceso Unificado Racional crean y mantienen modelos. En
lugar de centrarse en la producción de gran cantidad de documentos en papel, el
Proceso Unificado hace hincapié en el desarrollo y el mantenimiento de
representaciones ricas en modelos sistemáticos del sistema de software en
desarrollo. El Proceso Unificado Racional es una guía sobre cómo utilizar
eficazmente el Lenguaje de Modelado Unificado.
El eje horizontal representa el tiempo y muestra el aspecto dinámico del proceso
tal y como se promulga, y es expresados en términos de ciclos, fases, iteraciones
e hitos, el eje vertical representa el aspecto estático del proceso: cómo se describe
en términos de actividades, objetos, trabajadores y flujos de trabajo.
Principales Características:
     Desarrollo iterativo

     Forma disciplinada de asignar tareas y responsabilidades

     Pretende implementar las mejores prácticas en Ingeniería de Software.
     Administración de requisito   
     Uso de arquitectura basada en componentes
     Control de cambios
     Modelado visual del software
     Verificación de la calidad del software
Proceso de Software Personal

Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la

productividad personal de los programadores o ingenieros de software, en tareas
de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para
emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue
propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de
1997 con el lanzamiento del libro "An introduction to the Personal Software
Process" se dirige ahora a ingenieros juniors.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay
que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El
PSP se orienta el conjunto de áreas clave del proceso que debe manejar un
desarrollador cuando trabaja de forma individual.

Principios
El diseño de PSP se basa en los siguientes principios de planeación y de calidad
 Cada ingeniero es esencialmente diferente; es decir, los ingenieros deben
planear su trabajo y basar sus planes en sus propios datos personales.

 Para mejorar constantemente su funcionamiento, los ingenieros deben

utilizar personalmente procesos bien definidos y medidos.

 Para desarrollar productos de calidad, los ingenieros deben sentirse

personalmente comprometidos con la calidad de sus productos.

 Para hacer un trabajo de ingeniería de software de la manera correcta, los

ingenieros deben planear de la mejor manera su trabajo antes de
comenzarlo y deben utilizar un proceso bien definido para realizar de la
mejor manera la planeación del trabajo.

 Para que los desarrolladores lleguen a entender su funcionamiento de

manera personal, deben medir el tiempo que pasan en cada proceso, los
defectos que inyectan y remueven de cada proyecto y finalmente medir los
diferentes tamaños de los productos que llegan a producir.
NIVELES DEL PSP

1. Nivel 1 - inicial:
o Seguimiento y control de proyectos.
o Planeación de los proyectos.
2.  Nivel 2 - repetible:
o Revisión entre colegas.
o Ingeniería del producto de software.
o Manejo integrado del software.
o Definición del proceso de software.
o Foco del proceso de software.
3. Nivel 3 - Definido:
o Control de calidad.
o Administración cuantitativa del proyecto.
4. Nivel 4 - Controlado:
o Administración de los cambios del proceso.
o Administración del cambio tecnológico.
o Prevención de defectos.
5. PSP0: proceso base, registro de tiempos, registro de errores, estándar de tipo de
errores.[Proceso personal de arranque]
a) PSP0.1: estándar de codificación, medición de tamaño, propuesta de
mejoramiento del proceso(PIP).[Proceso personal de arranque]
b) PSP1: estimación del tiempo, reporte de pruebas.[Proceso personal de
administración]
c) PSP1.1: planeación de actividades, planeación de tiempos.[Proceso personal de
administración]
d) PSP2: revisión de codificación, revisión del diseño.[Proceso personal de calidad]
e) PSP2.1: formatos de diseño.[Proceso personal de calidad]
f) PSP3: desarrollo en ciclos.[Proceso cíclico]
Modelo CMMI
El CMMI (Capability Maturity Model Integration) Integración del modelo de
madurez de capacidades, es una metodología para facilitar el control de
rendimiento de empresas en el sector de Tecnologías de la Información, con la
implantación de este tipo de metodología se busca el desarrollo de Kpi´s fiables
que sean clave para el funcionamiento y productividad de la empresa, por lo que
se consigue mejorar el proceso mediante un lenguaje que se amolda a los
procesos de la gestión y software de este sector.

Como cualquier otra metodología de calidad de esta índole se necesita de la

participación de toda la empresa y contar con los recursos disponibles para poder
desarrollarla, como personal, formación, con una buena implicación de la dirección
como base para concienciar a todos los componentes que conforman la empresa.

Fases del Capability Maturity Model Integration (CMMI)

Capability Maturity Model Integration se divide en 5 pasos o niveles de desarrollo,

dentro de cada uno de estos niveles se engloban una serie de objetivos claves
para poder pasar al siguiente nivel, esto implica que una implicación total. La
visión que se le puede dar al modelo de CMMI puede ser doble, por un lado,
encontramos la representación continua y por otro la escalonada.

La versión continua hace un desglose por nivel de proceso dejando a un lado la

parte de madurez, presenta un nivel más, en total 6, repartidos de la siguiente
manera:

 Nivel 0 o incompleto
 Nivel 1 o realizado
 Nivel 2 o gestionado
 Nivel 3 o definido
 Nivel 4 o gestionado cuantitativamente
 Nivel 5 u optimizado
Las 5 etapas que a medida que ascendemos tienen un mayor grado de desarrollo,
los niveles de madurez serían:

Nivel 1 o inicial. En este nivel se encuentran empresas que abarcan demasiados

objetivos incumplidos, falta de desarrollo de procesos o que directamente no se
ven capacidad de desarrollar las nuevas ideas.
Nivel 2 o gestionado. Aquí encontramos empresas que tienen sus proyectos
desarrollados están bien definidos, planificados tienen un buen seguimiento de kpi
´s y tienen asegurados un control.
Nivel 3 o definido. Una vez llegados a este nivel podemos ver empresas que
desarrollan sus proyectos mediante standares, herramientas, procedimiento, es
decir, vemos que los proyectos se siguen de una forma establecida según la
organización, pero de una forma clara y especifica.
Nivel 4 o gestionado cuantitativamente. Se busca el establecimiento de
objetivos cuantitativos y ejecución de los mismos, con ello se consigue tener en
cuenta las necesidades de los clientes, y como saldrá el producto para el cliente
final. En esta etapa se miden los procesos con datos, por lo que se realizan
cálculos estadísticos.
Nivel 5 u optimizado. Con el análisis de los datos se puede comprender donde
detectar la mejora y actuar al respecto, y conseguir una mayor eficiencia del
proceso.
Modelo en Espiral
El desarrollo o modelo en espiral es un enfoque de desarrollo de software que
puede ser considerado como una respuesta a los inconvenientes del desarrollo en
cascada. El modelo en espiral describe el ciclo de vida de un software por medio
de espirales, que se repiten hasta que se puede entregar el producto terminado. El
desarrollo en espiral también se conoce como desarrollo o modelo incremental. El
producto se trabaja continuamente y las mejoras a menudo tienen lugar en pasos
muy pequeños.
Una característica clave del desarrollo en espiral es la minimización de los riesgos
en el desarrollo de software, lo que podría resultar en un aumento de los costes
totales, más esfuerzo y un lanzamiento retardado. Estos riesgos son
contrarrestados por el enfoque incremental, haciendo primero prototipos, que
luego pasan al menos una vez, por las fases de desarrollo de software. El
desarrollo en espiral es genérico y puede combinarse con otros métodos de
desarrollo clásicos y ágiles, por lo que también se denomina modelo o desarrollo
de segundo orden.
Contenido
 Información general
 Cómo funciona
 Beneficios / Desventajas
  Relevancia para la programación
 Referencias
 Enlaces Web
Información general
El desarrollo en espiral fue propuesto por Barry W. Boehm en su ensayo "A Spiral
Model of Software Development and Enhancement." En ese momento, el modelo
de desarrollo en cascada prevalecía, por lo que los inconvenientes asociados
fueron discutidos con frecuencia. A diferencia de otros modelos como "code and
fix" o el "modelo cascada", el desarrollo en espiral está basado en el riesgo. La
identificación y resolución de riesgos juega un papel importante en las diferentes
espirales del proyecto una vez definidos los objetivos y condiciones. El enfoque se
centra en los posibles factores que pueden causar incertidumbres para el software
o para todo el proyecto. Según el supuesto, si los riesgos pueden ser controlados
de una manera rentable, no hay nada que impida la finalización exitosa del
proyecto. Los enfoques para minimizar estos riesgos son, por ejemplo, prototipos,
simulaciones, pruebas de referencia o entrevistas con los usuarios. Para ciertos
tipos de riesgos, todo el procedimiento puede incluso ser revisado y estructurado
de manera diferente. La intervención de la gerencia o management es posible en
cada fase del proyecto y pueden adaptarse otros enfoques de desarrollo.
Cómo funciona
El modelo de desarrollo en espiral se caracteriza por los siguientes ciclos (también
cuadrantes). Objetivo y determinación alternativa: Los objetivos se determinan
conjuntamente con el cliente. Al mismo tiempo, se discuten posibles alternativas y
se especifican las condiciones marco (por ejemplo, sistemas operativos, entornos
y lenguajes de programación).

Análisis y evaluación de riesgos

Se identifican y evalúan los riesgos potenciales. También se evalúan las
alternativas existentes. Los riesgos son registrados, evaluados y luego reducidos
utilizando prototipos, simulaciones y softwares de análisis. En este ciclo, existen
varios prototipos como plantillas de diseño o componentes funcionales
Desarrollo y prueba: Los prototipos se amplían y se añaden funcionalidades. El
código real es escrito, probado y migrado a un entorno de prueba varias veces
hasta que el software pueda ser implementado en un entorno productivo.
Planificación del siguiente ciclo: El siguiente ciclo se planifica al final de cada
etapa. Si se producen errores, se buscan soluciones, y si una alternativa es una
mejor solución, se prefiere en el siguiente ciclo.
La fuerza impulsora más importante del desarrollo en espiral es el análisis y la
evaluación de riesgos. Cualquier riesgo que amenace el proyecto debe ser
identificado desde el principio. El progreso del proyecto depende decisivamente de
cómo se puedan eliminar los riesgos. El proyecto se considera exitoso sólo
cuando no hay riesgos. El objetivo del ciclo es producir un producto en continua
mejora. El software o la aplicación se perfecciona constantemente. El modelo en
espiral es incremental, pero no necesariamente repetitivo. Las repeticiones
ocurren sólo cuando los riesgos, errores o conflictos amenazan el proyecto.
Entonces el producto tiene que pasar por un ciclo de nuevo, llamado una iteración
o repetición.
Beneficios / Desventajas
El modelo de desarrollo en espiral se utiliza a menudo para proyectos más
grandes que están sujetos a riesgos. Dado que estos riesgos tienen un impacto
monetario directo, el control de los presupuestos de los clientes y de las empresas
promotoras es fundamental. El modelo en espiral se utiliza especialmente en los
nuevos entornos técnicos, ya que éstos suponen un riesgo.
Los conflictos entre los requisitos de un software y su diseño se evitan
eficazmente mediante el enfoque cíclico, ya que los requisitos pueden
comprobarse constantemente y, si es necesario, modificarse.
Se puede obtener feedback de los usuarios, desarrolladores y clientes en las
primeras fases del proyecto. Sin embargo, esta estructura también requiere una
gestión que tenga en cuenta los ciclos del producto y pueda responder
rápidamente a los riesgos. El control de tales proyectos es, por lo tanto,
relativamente complejo y también requiere una buena documentación para que se
registren todos los cambios.
Aunque el software se prueba bajo varios aspectos durante el ciclo de desarrollo y
prueba (unidad, prueba de aceptación e integración), a menudo sucede que los
prototipos se transfieren al sistema de producción. Por lo tanto, existe el riesgo de
que se introduzcan otros errores e incoherencias conceptuales en el producto final
posterior.
En los lugares donde se toman decisiones sobre los ciclos siguientes, existe el
riesgo de que se formen bucles y el proyecto tarde más tiempo si se toman
decisiones equivocadas. Por esta razón, las alternativas y su evaluación son
importantes.
Relevancia para la programación
A diferencia de un modelo secuencial (por ejemplo, el modelo en cascada)
dispuesto en fases sucesivas, el modelo en espiral esboza el ciclo de vida de un
software por medio de espirales que hay que recorrer. Por lo tanto, este enfoque
se parece más a la creación de prototipos que los enfoques clásicos. El modelo en
espiral se supone que evita las desventajas de otros modelos y enfatiza las
ventajas. Al centrarse en la minimización del riesgo, este modelo tiene un
componente financiero que puede ser relevante para los responsables de la toma
de decisiones. A través de discusiones con los clientes, análisis y estudios de
viabilidad, se pueden implementar proyectos a gran escala y monitorizar su
impacto económico. Hasta qué punto los métodos ágiles como scrum,
programación extrema o DevOps son mejores opciones dependen de muchos
factores diferentes como el alcance del proyecto, el presupuesto o el nivel
requerido de soporte y mantenimiento. Cuanta más flexibilidad se requiera, más
métodos ágiles se considerarán.
METODOLOGÍA XP
Es una metodología de desarrollo de la ingeniería de software formulada 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 la 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.
Se puede considerar la programación extrema como la adopción de las mejores
metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Las características fundamentales del método son:
 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión. Se aconseja escribir el código de la
prueba antes de la codificación. Véase, por ejemplo, las herramientas de
prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la
plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en
JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework
orientado a realizar tests, realizado para el lenguaje de programación
Smalltalk.
 Programación en parejas: se recomienda que las tareas de desarrollo
se lleven a cabo por dos personas en un mismo puesto. La mayor
calidad del código escrito de esta manera -el código es revisado y
discutido mientras se escribe- es más importante que la posible pérdida
de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o
usuario. Se recomienda que un representante del cliente trabaje junto al
equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad.
Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código
para aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la
refactorización no se ha introducido ningún fallo.
 Propiedad del código compartida: en vez de dividir la responsabilidad
en el desarrollo de cada módulo en grupos de trabajo distintos, este
método promueve el que todo el personal pueda corregir y extender
 cualquier parte del proyecto. Las frecuentes pruebas de regresión
garantizan que los posibles errores serán detectados.
 Simplicidad en el código: es la mejor manera de que las cosas
funcionen. Cuando todo funcione se podrá añadir funcionalidad si es
necesario. La programación extrema apuesta que es más sencillo hacer
algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizás nunca utilizarlo.
 
La simplicidad y la comunicación son extraordinariamente complementarias. Con
más comunicación resulta más fácil identificar qué se debe y qué no se debe
hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste,
lo que lleva a una comunicación más completa, especialmente si se puede reducir
el equipo de programadores.

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. 
 Conclusión No. 1
Así que ahora ya sabes muy bien cómo funciona cada una de las metodologías
básicas y de los procesos o fases que conlleva cada una de ellas, así como las
metodologías ágiles y las ventajas de utilizarlas, por supuesto que hoy en día son
las más usadas. Sin embargo, algunas metodologías existentes actualmente que
no son tan famosas, están basadas en estas principalmente, razón por la cual no
se les hace mucha mención. De cualquier forma, al final del día, tanto tú, como tu
equipo de desarrollo de sistema, deberán hacer el análisis inicial y determinar bajo
qué esquema quieren empezar a desarrollar. Si formas parte de una agencia de
desarrollo de software, todo dependerá del tipo y tamaño de software que el
cliente requiera, si no es así, entonces solamente deberás elegir uno para
establecer cierto orden en tus procesos o tomar fases de varios procesos como el
de cascada y prototipos y crear tu propia metodología, pues esto es precisamente
lo que muchos hacen.