CAPITULO 2 MODELO DE PROCESOS
En un libro fascinante que expone el punto de vista de un economista sobre el software y su
ingeniería.
Debido a que el software, como todo capital, es conocimiento incorporado y a que el
conocimiento originalmente se halla disperso, tácito, latente e incompleto en gran medida, el
desarrollo de software es un proceso de aprendizaje social. El proceso es un diálogo en el que el
conocimiento que debe convertirse en software se reúne e incorpora en éste. El proceso genera
interacción entre usuarios y diseñadores, entre usuarios y herramientas cambiantes, y entre
diseñadores y herramientas en evolución [tecnología]. Es un proceso que se repite y en el que la
herramienta que evoluciona sirve por sí misma como medio para la comunicación: con cada nueva
ronda del diálogo se genera más conocimiento útil a partir de las personas involucradas.
¿Qué es?
Cuando se trabaja en la construcción de un producto o sistema,es importante ejecutar una serie
de pasos predecibles
Quién lo hace?
Los ingenieros de software y sus gerentes adaptan el proceso a sus necesidades
¿Por qué es importante?}
Porque da estabilidad,control y organización a una actividad que puede volverse caótica si se
descontrola.
¿Cuáles son los pasos?
En un nivel detallado,el proceso que se adopte depende del software que se esté elaborando.
¿Cuál es el producto final?
los productos del trabajo son los programas,documentos y datos que se producen
comoconsecuencia de las actividades y tareas definidas por el proceso.
Un modelo general del proceso
En el capítulo 1 se definió un proceso como la colección de actividades de trabajo,acciones y
tareas que se realizan cuando va a crearse algún producto terminado.
En la figura 2.1 se representa el proceso del software de manera esquemática.En dicha fi-
gura,cada actividad estructural está formada por un conjunto de acciones de ingeniería de
software y cada una de éstas se encuentra definida por un conjunto de tareas que identifica las
tareas del trabajo que deben realizarse,los productos del trabajo que se producirán,
Estructura del proceso
Actividades sombrilla
actividad estructural #1
Conjuntos
de tareas
tareas del trabajo
productos del trabajo
puntos de aseguramiento de la calidad
puntos de referencia del proyecto
acción de ingeniería de software #1.1
Conjuntos
de tareas
tareas del trabajo
productos del trabajo
puntos de aseguramiento de la calidad
puntos de referencia del proyecto
acción de ingeniería de software #1.k
actividad estructural #n
Conjuntos
de tareas
tareas del trabajo
productos del trabajo
puntos de aseguramiento de la calidad
puntos de referencia del proyecto
acción de ingeniería de software #n.1
Conjuntos
de tareas
tareas del trabajo
productos del trabajo
puntos de aseguramiento de la calidad
puntos de referencia del proyecto
acción de ingeniería de software #n.m
Proceso del software
FIGURA 2.1
PARTE UNO EL PROCESO DEL SOFTWARE
brilla:seguimiento y control del proyecto,administración de riesgos,aseguramiento de la cali-
dad,administración de la configuración,revisiones técnicas,entre otras.
El lector debe observar que aún no se menciona un aspecto importante del proceso del soft-
ware.En la figura 2.2 se ilustra dicho aspecto —llamado flujo del proceso — y se describe la
manera en que están organizadas las actividades estructurales y las acciones y tareas que ocu-
rren dentro de cada una con respecto de la secuencia y el tiempo.
Cita:
“Pensamos que los desarrolladores de software pierden de vista una verdad fundamental:la mayor
parte de organizaciones no saben lo que hacen.Piensan que lo saben,pero no es así.”Tom
DeMarco
FIGURA 2.2 Flujo del proceso
CAPÍTULO 2 MODELOS DEL PROCESO 29
paralelo con otras (por ejemplo,el modelado de un aspecto del software tal vez se ejecute
en paralelo con la construcción de otro aspecto del software).
2.1.1 Definición de actividad estructural
Aunque en el capítulo 1 se describieron cinco actividades estructurales y se dio una definición
básica de cada una,un equipo de software necesitará mucha más información antes de poder
ejecutar de manera apropiada cualquiera de ellas como parte del proceso del software.Por
tanto,surge una pregunta clave:¿qué acciones son apropiadas para una actividad estructural,
dados la naturaleza del problema por resolver,las características de las personas que hacen el
trabajo y los participantes que patrocinan el proyecto?
Para un proyecto de software pequeño solicitado por una persona (en una ubicación remota)
con requerimientos sencillos y directos,la actividad de comunicación tal vez no incluya algo
más que una llamada telefónica con el participante apropiado.Entonces,la única acción nece-
saria es una conversación telefónica ,y las tareas del trabajo (el conjunto de tareas )que engloba
son las siguientes:
1.Hacer contacto con el participante por vía telefónica.
2.Analizar los requerimientos y tomar notas.
3.Organizar las notas por escrito en una formulación breve de los requerimientos.
4.Enviar correo electrónico al participante para que revise y apruebe.
Si el proyecto fuera considerablemente más complejo,con muchos participantes y cada uno
con un distinto conjunto de requerimientos
2.1.2 Identificación de un conjunto de tareas
En relación con la figura 2.1,cada acción de la ingeniería de software (por ejemplo,obtención ,
asociada a la actividad de comunicación)se representa por cierto número de distintos conjuntos
de tareas ,cada uno de los cuales es una colección de tareas de trabajo de la ingeniería de soft-
ware,relacionadas con productos del trabajo,puntos de aseguramiento de la calidad y puntos
de referencia del proyecto.Debe escogerse el conjunto de tareas que se adapte mejor a las ne-
cesidades del proyecto y a las características del equipo.Esto implica que una acción de la in-
geniería de software puede adaptarse a las necesidades específicas del proyecto de software y
a las características del equipo del proyecto.
2.1.3 Patrones del proceso
Cada equipo de software se enfrenta a problemas conforme avanza en el proceso del software.
Si se demostrara que existen soluciones fáciles para dichos problemas,sería útil para el equipo
abordarlos y resolverlos rápidamente.Un patrón del proceso 1 describe un problema relacionado
con el proceso que se encuentra durante el trabajo de ingeniería de software,identifica el am-
biente en el que surge el problema y sugiere una o más soluciones para el mismo.Dicho de
manera general,un patrón de proceso da un formato [Amb98 ]:un método consistente para
describir soluciones del problema en el contexto del proceso del software.Al combinar patro-
nes,un equipo de software resuelve problemas y construye el proceso que mejor satisfaga las
necesidades de un proyecto.
Patrón de fase :define la secuencia de las actividades estructurales que ocurren dentro
del proceso,aun cuando el flujo general de las actividades sea de naturaleza iterativa.
Un ejemplo de patrón de fase es ModeloEspiral o Prototipos .3
Contexto inicial.Describe las condiciones en las que se aplica el patrón.Antes de iniciar
el patrón:1)¿Qué actividades organizacionales o relacionadas con el equipo han ocurrido?
2)¿Cuál es el estado de entrada para el proceso?3)¿Qué información de ingeniería de soft-
ware o del proyecto ya existe?
Por ejemplo,el patrón Planeación (patrón de etapa)requiere que:1)los clientes y los
ingenieros de software hayan establecido una comunicación colaboradora;2)haya termi-
nado con éxito cierto número de patrones de tarea [especificado ] para el patrón Comuni--
cación ;y 3)se conozcan el alcance del proyecto,los requerimientos básicos del negocio y
las restricciones del proyecto.
Problema.El problema específico que debe resolver el patrón.
Describe cómo implementar con éxito el patrón.Esta sección describe la forma
en la que se modifica el estado inicial del proceso (que existe antes de implementar el pa-
trón)como consecuencia de la iniciación del patrón.También describe cómo se transforma
la información sobre la ingeniería de software o sobre el proyecto,disponible antes de que
inicie el patrón,como consecuencia de la ejecución exitosa del patrón.
Contexto resultante.Describe las condiciones que resultarán una vez que se haya im-
plementado con éxito el patrón:1)¿Qué actividades organizacionales o relacionadas con el
equipo deben haber ocurrido?2)¿Cuál es el estado de salida del proceso?3)¿Qué información
sobre la ingeniería de software o sobre el proyecto se ha desarrollado?
Patrones relacionados.Proporciona una lista de todos los patrones de proceso directa-
mente relacionados con éste.Puede representarse como una jerarquía o en alguna forma
de diagrama.Por ejemplo,el patrón de etapa Comunicación incluye los patrones de tarea:
EquipoDelProyecto,LineamientosDeColaboración,DefiniciónDeAlcances,Reca-
barRequerimientos,DescripciónDeRestricciones y CreaciónDeEscenarios
2.2 EVALUACIÓN Y MEJORA DEL PROCESO
La existencia de un proceso del software no es garantía de que el software se entregue a tiempo,
que satisfaga las necesidades de los consumidores o que tenga las características técnicas
Método de evaluación del estándar CMMI para el proceso de mejora (SCAMPI,por
sus siglas en inglés):proporciona un modelo de cinco fases para evaluar el proceso:inicio,
diagnóstico,establecimiento,actuación y aprendizaje.El método SCAMPI emplea el SEI
CMMI como la base de la evaluación [SEI00 ].
Evaluación basada en CMM para la mejora del proceso interno (CBA IPI,por sus si-
glas en inglés):proporciona una técnica de diagnóstico para evaluar la madurez relativa de
una organización de software;usa el SEI CMM como la base de la evaluación [Dun01 ].
SPICE (ISO/IEC 15504):estándar que define un conjunto de requerimientos para la eva-
luación del proceso del software.El objetivo del estándar es ayudar a las organizaciones a
desarrollar una evaluación objetiva de cualquier proceso del software definido [ISO08 ].
ISO9001:2000 para software :estándar genérico que se aplica a cualquier organización
que desee mejorar la calidad general de los productos,sistemas o servicios que propor-
ciona.Por tanto,el estándar es directamente aplicable a las organizaciones y compañías de
software [Ant06 ].
