Estrategias de Desarrollo de

Software

Análisis de Sistemas I
Ingeniería en Sistemas de Información
Proceso Personal del Software
(PPS)
 PPS

El mejor proceso del software es el que está cerca de las personas que harán
el trabajo. Si un modelo del proceso del software se ha desarrollado en un
nivel corporativo u organizacional, será eficaz sólo si acepta una adaptación
significativa para que cubra las necesidades del equipo de proyecto que en
realidad hace el trabajo de ingeniería de software.

En la situación ideal se crearía un proceso que se ajustara del mejor modo a

los requerimientos, y al mismo tiempo cubriera las más amplias necesidades
del equipo y de la organización (Pressman, 2010).
 PPS

Todo desarrollador utiliza algún proceso para elaborar software. El proceso

quizá cambie a diario; tal vez no sea eficiente, eficaz o incluso no sirva; pero
sí existe un “proceso”.

A fin de cambiar un proceso personal ineficaz, un individuo debe pasar por las
cuatro fases, cada una de las cuales requiere capacitación e instrumentación
cuidadosa. El proceso personal del software (PPS) pone el énfasis en la
medición personal tanto del producto del trabajo que se genera como de su
calidad (Pressman, 2010).
 PPS

El modelo del PPS define cinco actividades estructurales:

- Planeación

- Diseño de alto nivel

- Revisión del diseño de alto nivel

- Desarrollo

- Post mórtem (Pressman, 2010).

 PPS - Planeación

Esta actividad aísla los requerimientos y desarrolla las estimaciones tanto del
tamaño como de los recursos.

Todas las mediciones se registran en hojas de trabajo o plantillas. Por último,

se identifican las tareas de desarrollo y se crea un programa para el proyecto
(Pressman, 2010).
 PPS – Diseño de Alto Nivel

Se desarrollan las especificaciones externas para cada componente que se va

a construir y se crea el diseño de componentes. Si hay incertidumbre, se
elaboran prototipos. Se registran todos los aspectos relevantes y se les da
seguimiento (Pressman, 2010).
 PPS – Revisión del Diseño de Alto Nivel

Se aplican métodos de verificación formal para descubrir errores en el diseño.

Se mantienen las mediciones para todas las tareas y resultados del trabajo
importantes (Pressman, 2010).
 PPS – Desarrollo

Se mejora y revisa el diseño del componente. El código se genera, revisa,

compila y prueba. Las mediciones se mantienen para todas las tareas y
resultados de trabajo de importancia (Pressman, 2010).
 PPS – Post mórtem

Se determina la eficacia del proceso por medio de medidas y mediciones

obtenidas (ésta es una cantidad sustancial de datos que deben analizarse con
métodos estadísticos). Las medidas y mediciones deben dar la guía para
modificar el proceso a fin de mejorar su eficacia (Pressman, 2010).
 PPS

Enfatiza la necesidad de detectar pronto los errores; de igual importancia es

entender los tipos de ellos que es probable cometer. Representa un enfoque
disciplinado basado en la medición para la ingeniería de software que quizá
sea un choque cultural para muchos de sus practicantes.

El PPS no ha sido adoptado con amplitud por la industria. Es triste reconocer

que las razones de esto tienen que ver más con la naturaleza humana y la
inercia organizacional que con las fortalezas y debilidades del enfoque
(Pressman, 2010).
 PPS

El enfoque plantea desafíos intelectuales y demanda un nivel de compromiso

(por parte de los practicantes y sus administradores) que no siempre es
posible obtener. La capacitación es relativamente larga y sus costos elevados.

El nivel requerido de las mediciones es culturalmente difícil para muchas

personas de la comunidad del software (Pressman, 2010).
CMMI
 CMMI

El Software Engineering Institute (SEI) se estableció para mejorar las

capacidades de la industria de software estadounidense. A mediados de la
década de 1980, el SEI inició un estudio de formas para valorar las
capacidades de los contratistas de software. El resultado de esta valoración
de capacidad fue el Modelo de Madurez de Capacidades de Software (CMM,
por las siglas de Software Capability Maturity Model) del SEI.

Dicho modelo ha influido enormemente para convencer a la comunidad de la

ingeniería de software de tomar con seriedad la mejora de procesos
(Sommerville, 2011).
 CMMI

Con la intención de integrar el cúmulo de modelos de capacidad con base en

la noción de madurez de proceso, el SEI se embarcó en un nuevo programa
para desarrollar un modelo de capacidad integrado (CMMI). El marco CMMI
sustituye los CMM de ingeniería de software y sistemas, e integra otros
modelos de madurez de capacidades.

El modelo CMMI tiene la intención de ser un marco para la mejora de procesos

con amplia aplicabilidad a través de varias compañías. Su versión en etapas es
compatible con el CMM de software y permite que los procesos de desarrollo y
gestión del sistema de una organización se valoren asignándoles un nivel de
madurez de 1 a 5. Su versión continua permite una clasificación más fina de
la madurez del proceso. Este modelo ofrece una forma de clasificar 22 áreas
de proceso en una escala de 0 a 5 (Sommerville, 2011).
 CMMI

Fuente: Sommerville, I. (2011). Ingeniería del Software. México: Pearson Educación.

 Video

https://www.youtube.com/watch?v=KkcPP6chA2U
 CMMI

El modelo CMMI es muy complejo, con más de 1,000 páginas de descripción.

Aquí se simplificó principalmente para su análisis. Los principales
componentes del modelo son:

1. Un conjunto de áreas de proceso que se relacionan con las actividades de

proceso del software. El CMMI identifica 22 áreas de proceso que son
relevantes para la capacidad y la mejora del proceso de software. Están
organizadas en cuatro grupos en el modelo CMMI continuo (Sommerville,
2011).
 CMMI

2. El CMMI tiene metas específicas que se asocian con cada área de proceso y
definen el estado deseable de dicha área. También define metas genéricas
asociadas con la institucionalización de la buena práctica (Sommerville,
2011).

Fuente: Sommerville, I. (2011). Ingeniería del Software. México: Pearson Educación.

 CMMI

3. Un conjunto de buenas prácticas, las cuales son descripciones de formas

para lograr una meta. Muchas prácticas específicas y genéricas pueden
asociarse con cada meta dentro de un área de proceso. El CMMI reconoce
que lo importante es la meta, más que la forma en que se alcanza dicha
meta. Las organizaciones pueden usar cualquier práctica adecuada para
lograr cualquiera de las metas CMMI: No tienen que adoptar las prácticas
recomendadas por el CMMI (Sommerville, 2011).
 CMMI

Fuente: Sommerville, I. (2011). Ingeniería del Software. México: Pearson Educación.

 CMMI

En una etapa temprana del desarrollo de madurez, la institucionalización

quizá pretenda garantizar que se establezcan los planes en la compañía y se
definan los procesos para todo el desarrollo de software. No obstante, para
una organización con procesos avanzados más maduros, la institucionalización
puede suponer introducir control de procesos mediante técnicas estadísticas y
otras técnicas cuantitativas a través de la organización (Sommerville, 2011).
 CMMI - Valoración

Implica examinar los procesos en una organización y clasificar dichos procesos

o áreas de proceso en una escala de seis puntos que se relacionan con el nivel
de madurez en cada área de proceso.

La idea es que, cuanto más maduro sea el proceso, mejor será. Existe una
escala de seis puntos que asigna un nivel de madurez a un área de proceso
(Sommerville, 2011).
 CMMI – Valoración - Incompleto

Al menos no se satisface una de las metas específicas asociadas con el área de

proceso. No hay metas genéricas en este nivel, pues no tiene sentido la
institucionalización de un proceso incompleto (Sommerville, 2011).
 CMMI – Valoración - Realizado

Las metas asociadas con el área de proceso están satisfechas, y para todos los
procesos el alcance del trabajo a realizar se estableció de manera explícita y
se comunicó a los miembros del equipo (Sommerville, 2011).
 CMMI – Valoración - Gestionado

En este nivel se satisfacen las metas asociadas con el área de proceso y se

establecen políticas organizacionales que determinan cuándo debe usarse
cada proceso. Tiene que haber planes de proyecto documentados que
establezcan las metas del proyecto. En la institución debe haber
procedimientos para la gestión de recursos y la monitorización de procesos
(Sommerville, 2011).
 CMMI – Valoración - Definido

Este nivel se enfoca en la estandarización organizacional y el despliegue de

procesos. Cada proyecto tiene un proceso gestionado que se adapta a los
requerimientos del proyecto desde un conjunto definido de procesos
organizacionales. Deben recopilarse activos y mediciones de proceso, además
de usarse para futuras mejoras de proceso (Sommerville, 2011).
 CMMI – Valoración – Gestionado Cuantitativamente

En este nivel hay una responsabilidad organizacional cuya finalidad es usar

métodos estadísticos y cuantitativos para controlar los subprocesos; esto es,
deben utilizarse mediciones recopiladas de proceso y producto en la gestión
del proceso (Sommerville, 2011).
 CMMI – Valoración – Optimizado

En este nivel superior, la organización debe usar las mediciones de proceso y

producto para impulsar la mejora de los procesos. Hay que analizar las
tendencias y adaptar los procesos a las necesidades cambiantes de la empresa
(Sommerville, 2011).
 Modelo CMMI en Etapas

Ofrece un medio para valorar la capacidad de proceso de una organización en

uno de cinco niveles, y prescribe las metas que deben lograrse en cada uno de
dichos niveles. La mejora de proceso se logra al implementar prácticas en
cada nivel, y desplazarse en el modelo de los niveles inferiores a los
superiores (Sommerville, 2011).
 Modelo CMMI en Etapas

Cada nivel de madurez tiene un conjunto de áreas de proceso y metas

genéricas asociadas. Éstas reflejan la buena práctica de ingeniería y gestión
de software, además de la institucionalización de la mejora de los procesos.
Los niveles de madurez más bajos pueden alcanzarse al introducir buenas
prácticas; sin embargo, los niveles más altos requieren un compromiso con la
medición y la mejora de los procesos (Sommerville, 2011).
 Modelo CMMI Continuo

Valoran el uso de la buena práctica dentro de cada grupo de procesos. Por lo

tanto, la valoración de la madurez no es un solo valor, sino un conjunto de
valores que muestran la madurez de la organización en cada proceso o grupo
de procesos.

El CMMI continuo considera las áreas de proceso y asigna el nivel de

valoración de capacidad de 0 a 5 (como se describió anteriormente) a cada
área del proceso (Sommerville, 2011).
 Modelo CMMI Continuo

Fuente: Sommerville, I. (2011). Ingeniería del Software.

México: Pearson Educación.
 Modelo CMMI Continuo

La principal ventaja del modelo continuo es que las compañías pueden elegir
procesos para mejorar de acuerdo con sus necesidades y requerimientos
particulares. Diferentes tipos de organizaciones tienen distintos
requerimientos para la mejora de los procesos.

Por ejemplo, una compañía que desarrolle software para la industria

aeroespacial puede enfocarse en mejorar la especificación del sistema, la
administración de la configuración y la validación, mientras que una
compañía de desarrollo Web tal vez esté más interesada en los procesos que
enfrenta el cliente (Sommerville, 2011).
 Modelo CMMI en Etapas vrs. Modelo CMMI Continuo

La principal diferencia entre los modelos CMMI por etapas y continuo es que
el primero se usa para valorar la capacidad de la organización como un todo,
mientras que el segundo mide la madurez de áreas de proceso específicas
dentro de la organización (Sommerville, 2011).
Parte Práctica
 Bibliografía

Pressman, R. (Ed.). (2010). Ingeniería del Software. Un Enfoque Práctico.

México: McGraw Hill.

Sommerville, I. (2011). Ingeniería del Software. México: Pearson Educación.