a einai
aotrhMC Cientifica y a
Balter(Holi) St fs euie .
48 erat Seeeae Rca
EN UNA ORGANIZACION
|
TESIS
hei a CIENCIAS
GABRIEL ALBERTO GARCIA MIRELES _
Educacién Superior de Ensenada
Divisi6n Fisica Aplicada
Departamento de Ciencias de la Computacién
El Proceso de Desarrollo de Software
en una Organizacion
Tesis
Que para cubrir parcialmente los requisitos necesarios para obtener el grado
de MAESTRO EN CIENCIASpresenta:
GABRIEL ALBERTO GARCIA MIRELES
El Proceso de Desarrollo de Software en una Organizacion
Resumen aprobadopor:
( “
| /
/
i
b
M.C.Josefin§Rodriguez Jacobo
Dingdetesis
En general, los proyectos de software se caracterizan por liberar los sistemas después del tiempo acordado, no abordan toda la funcionalidad requerida, la calidad no se verifica o exceden el costo estipulado. Existen diversos factores que tienen influencia en la productividad de los ingenieros de software. El proceso de desarrollo de software que utiliza la organizacion es uno de los que tienen mayorinfluencia.
El proceso de desarrollo de software se refiere a los métodos, técnicas, procedimientos y actividades que los individuos emplean para generar y mantenerel software. Entenderel proceso porel cual se generan los productos de software es el primer paso para ganar control sobre el proceso de desarrollo y asi, mejorar el producto y el proceso mismo.
En el ambito educativo se estd utilizando el enfoque de procesos como medio para introducir el paradigma de calidad. Algunosutilizan el proceso de software de Humprey y otros utilizan el Modelo de Maduracién de Capacidades. No hay un modelo estandar para ensefiar la ingenieria del software basada en procesos. En el curso de Ingenieria y Metodologia de la Programacién, impartido en el CICESE,el enfoque utilizado para resolver los problemas de comunicacién y coordinacién ha sido técnico. Se tiene la memoria organizacional de los cursos impartidos desde 1994, pero no esta definido ni documentadoel proceso de desarrollo de software.
El propésito de este trabajo es analizar el proceso de desarrollo de software en el contexto del curso referido anteriormente, para disefiar un modelo que defina los procesos considerados en el segundo nivel del Modelo de Maduracién de Capacidades. Eneste nivel se consideran las actividades de planificacién y seguimiento del proyecto, administracién de configuracidn y requerimientos, y aseguramiento de la calidad.
los nuevos procesos administrativos en el desarrollo de software.
The Software Development Process lr a Organization
Abstract approved by: >
d--—
M.Sc. Josefind/ Rodriguez Jacobo Thesis director
Many software projects are delivered after the commited date, do not addressall capacities required by the customer, the quality is not verified or have an excessive cost for deployment. There are somefactors than have an influence in the productivity of software engineers. The software development process used by the organization is the factor with greater impact.
The software process is concerned with methods, techniques, procedures and activities
which people use to build and maintain software. One ofthe first steps to gain more control
overthe the developmentprocessis understandit.
The educational environment is using the process approach as the meansto introduce the quality paradigm. Some people use the Humpresy’s software process and others, the Capability Maturity Model. There is not a standard model to teach process-based software engineering. The course, Ingenierfa y Metodologia de la Programacién (Software Engineering) tought in CICESE, use a technical approach to problem solving concerned
with communication and coordination. There is an organizational memory from the past
tought courses, since 1994, but the software processis not well defined nor documented.
The goal of this research is to analize the software development process in a controlled
environment, with the main aim of defining a software process model whichsatifies the
level two of the Capability Maturity Model. This level addresses the key process areas of
project planning and tracking, configuration management, requirements management and software quality assurance.
Wealso describe the process’ framework and the Capability Maturity Model and wedefine the software process used in the course addressing an agent-based approach. These models help in the software process appraisal, where we check the conformance with the key practices of Capability Maturity Model’s level two. Finally, we describe recommendation for each key process area and suggest the new management process in the software development.
A los miembros de mi comité de tesis, Josefina Rodriguez, Fernando Rojas, Gilberto Lépez, Lidia Gémezy Jestis Favela, porel apoyo brindado enlas revisiones deeste trabajo.
A Sonia Sosa, quien siempre escuch6 los planes para terminar esta tesis y me acompafié para lograrlos.
A Adrian Vazquez, Ana Martinez y Edelmira Rodriguez, quienes estuvieron dispuestos a trabajar conmigo en cualquier momento.
A Sergio Gonzalez, por sus recomendaciones.
A losestudiantes que participaron en las entrevistas, Eunice Mejia, Gilberto Ibarra, Octavio
Garcia, Rafael Llamas, Juan Tapia, Adan Hirales y José Barraza.
A los compafieros del laboratorio, profesores del Departamento y al personal administrativo.
A todos, que de alguna manera me apoyaronenlarealizacién de este trabajo.
Capitulo [. Introducctn...3. ssissisasscsssassalelxeesasssremrssveasiaavcecrnadt epetestesvesseee 1
1.1 Planteamiento del problema. To OW(CHYG.... ..esieneissasiarres 1.3 Organizacién de la tesis
Capitulo II. Modelado de proceso...cceccesessessseseeseesceseeecsecseeeeneeaeeecaeeecsenenesaes 9
IL.1 Introduccién. IL2 Historia...
IL.3 Ingenieria de procesos.
IL4 Conceptos fundamentales de procesos IL4.1 Clases de procesos....
IL.4.2 Conceptos asociados.
II.5 Representacién de procesos y modelos... IL.6 Metodologia de la ingenieria de procesos.. IL.7 Técnicas de representacién de procesos.
IL7.1 Diawiaiias UMLisssssssrsvsssesserenssssaseavecvees IL.7.2 Diagramas IDEFO...
IL.7.3 Diagramasrol-actividad
Elementos de los diagramas rol-actividad
IL.7.4 Comparacion de las técnicas para generardiagramas.. II.8 Estandares para el proceso de software..
TL.8.1 El modelo CMM wu... ecceeseteenereeseeee
Capitulo II. Modelo de Maduracién de Capacidades«0.0.0... eeeseteseeeereneeees 33
Tl Tithoduction...maieuepsnenanmmanmncaunnrennmacaies III.2 Conceptos fundamentales de soporte a la madurez del proceso... III.3 Beneficios y riesgos del mejoramiento basadoen el modelo... TI.4 Adaptacién del modelo CMM. ou... .esssssssssssereetesereeesesneenesensnees TI.5 Aplicacién del CMM...
TII.6 Estructura del CMM. III.6.1 Niveles de madurez.. III.6.2 Areas clave del proceso... TI.6.3 Metas cee
TIL.6.4 Practicas clave TII.6.5 Rasgos comunes
Ill.7 Niveles del modelo CMM . III.8 Nivel 2: Repetible...
III.9 Areas clave del proceso en el nivel 2. IIL.9.1 Administracién de requerimientos... IIL.9.2 Planificacidn del proyecto de software.
IIL.9.3 Seguimiento e inspeccién del proyecto de software TIL.9.4 Administraci6nde contratistas...0000
TII.9.5 Aseguramiento dela calidad del software
IIL.9.6 Administracidn de la configuracién del software...
T.11 Técnicas de valoraciOn w....c eee ey
IIL.11,1 Método de valoracién basado en el CMM... 53
IIL.11.2 Método de estimacién de perfil interno... io3
IIL. 12 Utilizacién del modeloen el ambito educativo... 54
Capitulo IV. Definicién del proceso de desarrollo de software...c.cccce 59
IV. Introduccion scccssssscssessesaszesnensssves IV.2 Introducciénal caso deestudio .
IV,2.1 Antecedentes ....cccceccceeeeesereeeneneaees IV,2.2 Contexto de la definicién de procesos
IV.3 Descripcién del curso isecccvsessserssssisesseves
IV.3.1 Caracteristicas del proyecto... IV.3.2 Estrategia de evaluacién del curso IV.3.3 Actividades previas al proyecto
IV.3.4 Actividades del estudiante durante el curso..
IV.4 Proceso de desarrollo de software...
IV.4.1 Aspecto de comportamiento del proceso IV.4.2 Aspecto organizacionaldel proceso...
IV.5 Aspectos funcional e informacional del proceso.
IV.5.1 Administradordel proyecto... IV.5.2 Administracion de configuracién IV.5.3 Especialista en documentacion.... IV.5.4 Ingeniero de mantenimiento . IV.5.5 Validacién y verificacién IV,5.6 Control de calidad... IV.5,7 Pruebas..
TV.5.8 Analista.. IV.5.9 Disefiador..
TV.5.10 Programador...ceseecsssssesssseseeneseeseesseeseeneneenees IV.6 Difusién del proceso de desarrollo de software
Capitulo V. Evaluacion del proceso de software respecto
al MOdElG CMMs coucsscsemecouersencanceevennsenarset bebbvesseieetamektomdctes 103
VL IntroducciOnoo... eects r reece V.2 Elementos del reporte de valoracién..
V.2.1 Introduccién
V.2.2 Metas 0.0...
V.2.3 Alcance del CMM. V.2.4 Alcance organizacional V.2.5 Actividades «0... V.2.6 Consolidacién de datos V.2.7 Validacionde los datos... V.2.8 Determinacién de cobertura V.2.9 CalificaciOn...cieeee V.2.10 Reporte de la valoracién...
V.3 Administracién de requerimiento:
V.3.1 Descripcidn del proceso...
V4 Planificacién del proyecto de software. V.4.1 Descripciéndel proceso...
V.4.2 Comparaciéncon las practicas clave del CMM V.4.3 EvaluaciOn...0..
V.4.4 Recomendaciones . V.5 Seguimiento del proyecto ..
V.5.1 Descripcién del proceso...
V.5.2 Comparacioncon las practicas clave del CMM V.5.3 EvaluaciOn ...
V.5.4 Recomendaciones .
V.6 Aseguramiento dela calidad del software... V.6.1 Descripcién del proceso...
V.6.2 Comparaciéncon las practicas clave del CMM V.6.3 EvaluaciOn...0..
V.6.4 Recomendaciones.
V.7 Administracion de la configuracién del software. V.7.1 Descripcién del proceso...c.sccssceseseeseseseseereereees V.7.2 Comparaci6n conlas practicas clave del CMM V.7.3 Evaluacion..
V.7.4 Recomendaciones.
Capitulo VI. Propuesta de los procesos clave del nivel dos
del modelo CMM...
VI.1 Introduccion..
V1.2 Propuesta del proceso de administracién de requerimientos.. VIL2.1 IntroducciOn oo...
VIL2.2 Objetivos woes
VI.2.3 Establecer los compromisosdel proyecto conelcliente VI1.2.4 Seguimiento de los requerimientos...
1.1.1 Control de cambios de los requerimientos...
VI.2.5 Documentos de apoyoal proceso de administracién de requerimientos VIL2:6 MEtricas,...ssssssersoerssensvonssnnevesserenneqnenapensseenpersrantenenssensdsessasvnnennietseseets
VI.2.7 Requisitos para las herramientas de apoyoa la administracién de requerimientos. V1.3 Propuestapara la planeacién del proyecto
VL3.1 Introduccion sciccisisccssissssasevsesssneascsassaee VIL3.2 ObjetivOs ...ceccscevees
V1.3.3 Proceso de planeacién V1.3.4 Documentos de apoyo...
VIB S MGCaSsesscsssvisseanssiccneccsccnvieesviavesvcesesesenes VI.3.6 Requisitos en las herramientas de soporte.
VI.4 Propuesta parael proceso de seguimiento del proyecto.. VL.4.1 Introduccién.
VI1.4.2 Objetivos...
VI.4.3 Seguimiento del proyecto.. V1.4.4 Documentos de apoyo VIA4.S MEtricas...cseeereereees
VI.4.6 Requisitos para las herramientas de apoyo al seguimiento del proyecto VL5 Propuesta de mejora al proceso de garantia de calidad...
VI.6 Propuestaal proceso de administracién de configuraci6n.. 244
VI.6.1 Introduccién.. 244
VI.6.2 Objetivos... 1245
VI1.6.3 Proceso de administraci6n de configuracién.. 245
VI.6.4 Documentos de apoyo 254
VI.6.5 MEtricas....ccsseseees .260
VI.6.6 Requisitos en las herramientas de soporte.. +260
Capitulo VII. Conclusiones, aportaciones y trabajo fUturo ... ee eeeeeeeteeee 263
VILI ConeWUStOttS wsccaucnsuss resonance mmnnerronemiee meen aE 263VIL2 Aportaciones... .. 264
VIL.3 Trabajo futuro... .. 265
Referencias ciscessssczeccsaaancasedeees iia aaraeeunasnvareonsed var onnsaesnonsensanccsesvyneoancossoves 269
Apéndice A. Definicién de términos de acuerdo al modelo CMM... 275
AA ROS cccscomancncmagaunannnncnmmnmna wi 215
A.2 Términosgenerales... wa BET
A.3 Otras interpretaciones.. wes 218
Apéndice B. Cuestionario para valoraciOn de proyect0S...ccceeeeeeeeeees 280
B.1 Nivel 2... .. 280
B.2 Nivel 3... . 281
Apéndice C. Cuestionario de Madurez...
C.1 Administracién de requerimientos... ... 286
C.2 Planificacién del proyecto de software... + 290
C.3 Seguimiento del proyecto... 1 293
C.3 Aseguramientode la calidad del software... we 297
Figura 1, Diagramade las etapas realizadas en el proceso de investigaciON...ccseeeeeserseseseseeeeeeereeseeneeee 6 Figura 2. Elementosdela técnica Rol Activity Didgram, ..cccccssseesesesesesersesesnesesseseseseserssssssenseseeenerseeees 24 Figura 3, Proceso para la revisidn de un producto de SOftWALE...ceceesseeesetesesesesceeetseesesssesesrersstssesseessssseeneees 28 Figura 4, Estructura:del CMM (Paulk éf al., 1995)..,...secsosessesvossnserensrosorsnosanevacneeceovsonsbosovasansoporssovevasbapeansvann 39 Figura 5. Rich picture del proceso general de desarrollo de SOftWare...ssccscessssesseseseseseesessssessessssesteasesssssenes q2 Figura 6. Actividades del proceso generalde desarrollo de software a nivel de andlisis del proceso... 75 Figura 7. Diagramade transicién de estados del proceso de desarrollo de software para la etapa de
andlisis.del:ciclo de vida del proyecto...,...cisssieiinesseanconaavnrcinianirnnmmnarnisinauniiacmemenees 78 Figura 8. Diagramade transicién de estados del proceso de desarrollo de software para la etapa de
disefio, codificacién y pruebas del ciclo de vida del proyecto...ccccsesessseerereerereeenessseeneeneersteneerenes 719 Figura 9. Diagrama RADdelas actividades e interacciones del administrador del proyecto... 88 Figura 10. Diagrama RADdelas actividadese interacciones del administrador de configuraci6n.... 189 Figura 11, Diagrama RADdelas actividades ¢ interaccionesdel especialista en documentaci6n.. wn Dl Figura 12. Diagrama RADdelasactividades e interacciones del ingeniero de mantenimiento, ...:00008 92 Figura 13. Diagrama RADdelas actividades e interacciones del ingeniero de validaci6ny verificacion...93 Figura 14, Diagrama RADdelas actividades e interaccionesdel ingeniero de controlde calidad...00 94 Figura 15. Diagrama RADdelasactividades e interaccionesdel ingeniero de pruebas...cseerereeeeeeens 95 Figura 16. Diagrama RADdelas actividades e interacciones del analista. ...scssssseseeeeereseeeereseeneeeeenens 96 Figura 17. Diagrama RADdelasactividadese interacciones del disefadOL...cseseseeereereereseenerteneeneeeenens 98 Figura 18. Diagrama RADdelasactividades e interacciones del programadot...cesesereeeeeseeerresereeneenens 99 Figura 19. Proceso para la validaciOn de requeriMient0S...:.ccccscetssessesesessseeesesssssseseceeeseneseseesesensseseeneseesens 109 Figura 20. Flujo de informacion enel proceso de validacién de requerimient0S...cssssecssseeseesesresesseetereenee lit Figura 21. Grafica de las practicas clave realizadas comparadasconlas requeridas por el CMM para
la administracion de requerimientos... wll7
Figura 22. Practicas clave que corresponden la meta uno de la administracién de requerimientos. ... 118 Figura 23. Practicas clave que corresponden a la meta dos de la administracién de requerimientos... 119 Figura 24. Grafica de las practicas clave realizadas, comparadascon las requeridas por el CMM para
Figura 32. Figura33. Figura 34. Figura 35. Figura 36. Figura 37. Figura 38. Figura 39, Figura 40. Figura 41. Figura 42. Figura 43, Figura 44, Figura 45. Figura 46. Figura 47. Figura 48. Figura 49. Figura 50. Figura 51. Figura 52. Figura 53.
Practicas clave que correspondena la meta tres del seguimiento del proyecto, uo... 147
Grafica de las practicas clave realizadas, comparadascon las requeridas por el CMM para eL-aseguramiento de la‘calidad del softwates sicsssssiisccschsesssvinessssbusvsstocsssssasvsassssasesnsesesvevabasonivesees 158 Practicas clave que corresponden la meta uno del aseguramientodela calidad del software...160
Practicas clave que correspondena la meta dos del aseguramientodela calidad del software...160
Practicas clave que corresponden a la meta tres del aseguramiento dela calidad del software....161
Practicas clave de la meta cuatro del aseguramiento de la calidad del software... 161
Proceso para la administraciOn de configuraciones...ccscsssesssssseseesssesesssssrevensesssstsnssseresseeneeees 165 Grafica de las practicas clave realizadas, compradas conlas requeridas por el CMM para la administracién de configuracion.... eedGi Practicas clave que correspondena la meta unode la administracién de configuraciOn... 178
Practicas clave que corresponden la meta dosde la administraci6n de configuraciOn... 178
Prdcticas clave que correspondena la metatres de la administracién de configuraciOn... 179
Practicas clave que correspondena la meta cuatro de la administracién de configuraci6n... 179
Diagrama RADparaestablecerlos compromisosdel proyecto Con el Cliente...sseseseeeseeseenes 186 Diagrama RADparael proceso de seguimiento de los requeriMicnt0S...c:cccseeesseseeteseeeseeseeees 192 Diagrama RADparael proceso de cambio a los requeriMientOS,...ceccseseessseeseesesresesteseeeseeseenes 196 Proceso para la planificaci6n del proyectos sessssccsscivosssscsvsedleoedssssovsesvnevesesseneencerasseneadraelenneeenens’208 Diagrama RAD del seguimiento del proyecto. ...ccsescssssssssesesesesesreresenssseeseeseseseasaseneeeesssesnenessees217 Diagrama RADdelasactividades propuestas para el aseguramiento dela calidad. ...00234
Tabla I. Comparaciéndelas técnicas para realizar diagramas: UML, IDEFO y RAD.Labasedela
comparaci6nsonlas caracteristicas de los procesos a los cuales deben dar soporte...cccsscesseesesseene 29 Tabla II. Enfoque del modelo CMM de acuerdoal SEI y las propuestas de aplicacién en la educacién
de la ingenieria del software. ...sssicsssscccsssiscvectessssossencsbsssssnsesesenssideccsssdecsassessssoreanssnsersesevessasensesees 58 TablaIII. Proyectos del curso Ingenieria y Metodologia de la ProgramaciOn...s:ssscsssesseseessessesseseessessesseene 60 Tabla IV. Formulario para la eleccidn de puesto. ...ccssscessessessecsseeseesnssssessessnessussssessseassessecassessesssesseessesseessess 69 Tabla V. Matriz rol-actividad-documento del proceso de desarrollo de software...ccscsscessessessessessessesseesesseess 84 Tabla VI. Matriz rol-actividad-documento del proceso de software (ContinuaciOn)...ccssecessesesseseeseseseseeseeee 85 Tabla VII. Matriz rol-actividad-documento del proceso de software (CONtINUACION),...c.ccescceesesessestesesseseesesenes 86 Tabla VIII. Proyecciéndelos roles del CMM lospuestos utilizados en el curso
de Ingenieria del sOltWwares.cicssscecvssesvesaccesssceisecccsetlsadsd svscerovansstlbbdearsenseensnveddalesnerssncenencerennapsnenncnes 105 Tabla IX. Historia de modificaciones al documento de requerimientos por el grupo DASIS...:.ccseeeeees 112 Tabla X. Historia de las modificaciones al documento de requerimientos porel grupo GENSIS98. ... 112 Tabla XI. Evaluaciéndelas practicas clave de la administraciOn de requerimientOS. ...ceseeeeeetesteeeeeeees 117 Tabla XII. Proyeccidn delas practicas clave a metas de la administracién de requerimient0S...0ceee 118 Tabla XIII. Evaluacién de las practicas clave para la planificacién del proyecto. v..ccccseeseeseeeeeeeeeseeees 129 Tabla XIV. Proyecciénde las practicas clave a metas de la planificaci6n del proyecto... sseeeeeeeeeees 130 Tabla XV. Informacién del proceso de seguimiento del proyecto disponible en el depdsito del proyecto... 136 Tabla XVI. Evaluacionde las practicas clave del seguimiento del proyecto...cccsseeesseresesreesensseecseerenenes 144 Tabla XVII. Proyecciéndelas practicas clave a metas del seguimiento del proyect0...cccreeereseseseenenes 145 Tabla XVIII. Revisiones técnicas practicadas porel grupo GENSIS98. ...cccsccssesssseeesseseeeseerenenserscsneeeerenee 151 Tabla XIX. Revisiones técnicas practicadas por el grupO DASIS., ...c.cseseecesesessssesesseeesesesesssreesenessesseseeeenenes 151 Tabla XX. Evaluaciéndelas practicas clave para el aseguramiento dela calidad del software...:0000 158 Tabla XXI. Proyecciénde las practicas clave a metas del aseguramientode la calidad del software... 159 Tabla XXII. Estructura del plan de administraciOn de ConfiguraciONn,...ccscccsseesesseeseseesessesestessstesesesesseeess 164 Tabla XXIII. Elementos bajo la administracion de configuracién en GENSIS98. ...cccccceseeesreesneseenssesresees 166 Tabla XXIV.Peticiones de cambio en el grupo GENSIS98. oo. ccssscseesesesessesssescsessscsssesesseesereseseesererscseeese 166 Tabla XXV. Elementos bajo la administracién de configuraciOn en DASIS...cccesceseeeseseseseseeeseseseseereees 167
Tabla XXVI. Evaluaciénde las practicas clave de la administraciOn de configuraciONn...csceeeseseseenees 176
Tabla XXVII. Proyeccién delas practicas clave a metas de la administraci6n de configuraciOn...00+ 177
Tabla XXVIII. Tareas para revisar actividades de andlisis. ...cscccsssessesseseeseeseseeesereenesescenesseessenennensseenens 187
administraciOn del proyecto.wc. cesceesessssssssesessessseessescssssessssessseecsssesssssucscsssscsrsessvsessavarseeeees 242 Tabla LXIX. Tareas para identificar elementos de configuraciON...:.cccscsssessssssesessesseesessessessssessesssesseseesseees 247
Tabla LXX.Tareaspara realizarla programaciOn de actividades, ...cescesesessesssessessesnecsesaneessecsseseesssees 249
Cualquier administrador de proyectos de software se sentirfa orgulloso al decir: “Conozco a mi equipo de trabajo y estoy seguro que este proyecto estard listo en nueve meses”, “La calidad del producto que entrego esta verificada”, “Los estimados del costo son precisos”, “El equipo del proyecto esta organizadoy tienen claras las responsabilidades de su trabajo al colaborar con otros miembros del equipo”, “podemos adelantarnos a la ocurrencia de problemas para poner en marcha los planes de contingencia”. Sin embargo, rara vez escuchamosesas expresiones. En cambio, es comtin oir que los proyectos no liberan los sistemas de software en el tiempo acordado, los productos no abordan toda la funcionalidad solicitada, la calidad es dudosa 0 se excedenen el costo presupuestado. jQué diferencia!
Los problemas de la ingenieria del software no son nuevos. En la década de los setenta se acufié el término ‘crisis del software’ para sefialar la falta de control en los proyectos. Existen diversos factores que inciden en la productividad del grupo de desarrollo y la calidad del sistema de software liberado al cliente, como son: el tamafio del grupo de desarrollo y la experiencia en el dominio de aplicacién, la disponibilidad de herramientas adecuadas y la estabilidad de los requisitos y restricciones del producto. Otro factor importante que tiene influencia en la productividad se refiere a los métodos, técnicas y
procedimientos utilizados para desarrollar el software, es decir, necesitamos considerarel
proceso de desarrollo de software.
requieren. El modelado y ejecucién de procesos de software es unalas areas principales de la investigacién en ingenierfa de software (Maurer y Kaiser, 1998).
La introduccién de procesos de software puede considerarse como unaintroduccién al paradigmade calidad. La filosofia que fundamenta al paradigmaes: un grupo que opera e institucionaliza ciertas practicas es més comin que produzca un mejor producto que un grupo que no las tenga. En particular, entender el proceso porel cual se generan los productos de softwarees el primer paso hacia ganarcontrol sobre el proceso de desarrollo y de ahi, mejorar el producto y proceso,
La investigacion de las necesidades de la industria del software y los esfuerzos porllevarel
paradigmade la calidad a los cursos de ingenierfa del software introduce un nuevo enfoque educativo. El fundamento de esta directriz esta en identificar los procesos necesarios para llevar a cabo el proyecto de software. Para lograrlo, los educadores deben estar convencidos de que los procesos son la base para el desarrollo de software efectivo, identificar las aptitudes y los roles involucrados, y construir situaciones que requieran de los estudiantes la aplicaci6n de dichas aptitudes.
En la revision de la literatura encontramos evidencia de la educacién basada en procesos. Por ejemplo, algunosinstructores utilizan el modelo del proceso de software de Humprey, otros estructuran sus proyectos de cursos de ingenierfa del software para alcanzarel nivel 2 6 3 del Modelo de Maduracién de Capacidades (CMM)(Upchurch y Sims-Knight, 1998).
necesitan los graduados. Segundo, la identificacién de aptitudes provee una oportunidad
para modelary entrenar, la cual ha sido vista como unaestrategia instructiva poderosa para las tareas cognoscitivas, como es el disefio de software. Finalmente, el control de lasactividades por los mismos estudiantes, al medir su desempefio, hace mas visible su
aportacion en un proyecto de grupo.1.1 Planteamiento del problema
No hay un modelo estandarpara ensefiar la ingenieria del software basada en procesos. Por ejemplo, en algunoscursosse entrega los estudiantes el documento de requerimientos. En éstos, el propdsito es querealicen el trabajo que se especifica pasando portodas las etapas del desarrollo, siguiendo algunos procesos descritos de manera textual, como el de revisiones técnicas (Upchurch y Sims-Knight, 1998). Otros educadores introducen un proceso general de desarrollo basado en el modelo CMMy utilizan los estandares de la IEEE para generar algunos productos en el ciclo de vida del proyecto (Robillard, 1998). Atin otros, utilizan un manual de calidad automatizado para que los estudiantes obtengan planes especificos del proyecto y lograr la coordinacién del grupo (Jaccheri y Lago, 1997). También se ha utilizado el enfoque de procesos y una adaptacién del modelo CMM para evaluar el desempefio del profesor y la coordinacién del curso de Ingenieria del Software (Umphress, 1997).
Porsu parte, el CICESE,a través del programa de posgrado en Ciencias de la Computacién ofrece el curso Ingenieria y Metodologia de la Programacién. El objetivo del cursoes:
“entender el desarrollo de proyectos de software de mediana escala en un ambiente distribuido, asi como evaluar el desarrollo del proyecto e ir conjuntando
herramientas, definiendo procesos y acumulando
de una alta certidumbre de que los proyectos serdan terminados con éxito aunque los miembros del equipo de desarrollo cambien por completo cada afio”(Licea et al., 1996).
Loscursos impartidos en el lapso de seis afios, han sido evaluadosporlos instructores para determinar los problemas que enfrentaron los estudiantes y las actividades que fueron de utilidad en el proceso de desarrollo de software. A la fecha, el principal enfoque para resolver los problemas de comunicacién y coordinacién ha sido técnico: proporcionar nuevas herramientas (0 que el estudiante las implemente) y otras plataformas de desarrollo para mitigar los problemas. Sin embargo, no se ha utilizado el enfoque de procesos para resolverlo. En estos proyectos se detectaron dificultades comoretraso en las actividades programadas, problemas de comunicaci6n, falta de integracién del grupo, ausencia de control del proyecto y de administracién de configuracién, redundancia de trabajo debido al intercambio de informacion no actualizada, integridad de documentacién pobre, entre otros (Favela er al., 1999).
Debido a que se cuenta con la historia documentada de los proyectos en el curso de Ingenieria y Metodologia de la Programacion y al apoyo que brinda en la comunicaciénel modelado de procesos, surge la motivacién de formalizar la metodologia para el desarrollo de software que se utiliza en dicha asignatura con el fin de evaluarla y mejorarla tomando como guia el modelo CMM.
Actualmente,se tiene la memoria organizacional de los cursos impartidos desde 1994, Esta es una ventaja, ya que nos permite analizar la manera en que se ha desarrollado el software desde entonces y cémo ha evolucionado.El inconveniente de tal informaci6n es que noesta estructurada, ya que atin no cuenta con la definicién y documentacién del proceso de software. Ademés, el desarrollo del proyecto durante el curso tiene limitaciones que no se encuentran en organizaciones que se dedican exclusivamente al desarrollo de sistemas de software, entre ellas: se conoce con anticipacién la fecha de término del proyecto, los estudiantes tienen que cursar cuando menosotrastres asignaturas de la maestrfa durante el desarrollo del mismoporlo que no dedican tiempo completo a esta asignatura; y, no hay un historial de seguimiento en otro proyecto que permita analizar si es consistente el alcance de los objetivos de ingenieria del software con el mismo grupodeparticipantes.
1.2 Objetivo
El propésito de este trabajo de tesis es analizar el proceso de desarrollo de software en un ambiente controlado, para disefiar un modelo que defina la arquitectura de los procesos considerados en el segundo nivel del Modelo de Maduracién de Capacidades.
Para alcanzar el objetivo anterior, se realizaron varias tareas, que van desde revisar el material tedrico correspondiente a la ingenieria de procesos, el modelo CMM, y las distintas disciplinas de la ingenierfa del software; hasta la aplicacién prdctica de estos conocimientos al generar el modelo del proceso de desarrollo de software, valorarlo y proponer mejoras, para que sirva de guia en el curso de Ingenieria y Metodologia de la Programacién.
por diagramas, fue la base para aplicar la valoracién tomando comoreferencia el modelo CMM, para determinar las fortalezas y debilidades del proceso relacionadas a la planificacién del proyecto, administracién de requerimientos, seguimiento del proyecto, administracién de configuracién y aseguramiento de la calidad. Los resultados de la evaluacién y la captura del proceso vigente, permiten proponer mejoras al proceso de
desarrollo de software.
Memoria organizacional
de los proyectos
Ingenieria de procesos
Modelo del proceso de
desarrollo de software
Ne
—— Evaluacién del
proceso
Modelo de Maduracién
de Capacidades
—
Propuesta de mejora al proceso
Figura 1. Diagramadelas etapas realizadas en el proceso de investigaci6n.
1.3 Organizacion de la tesis
De acuerdo a las etapas principales, descritas anteriormente, se muestra la organizacion de
describen algunas técnicas para representar procesos. También se resefia el enfoque metodoldégico de los proyectosde esta naturaleza.
En el capitulo tres se describe el modelo CMM,base para la evaluacién del proceso de desarrollo de software. Se presentan los conceptos fundamentales para el sustento de la madurez del proceso, las distintas aplicaciones del modelo y su adaptacién en ambientes particulares. También se describe la estructura interna del modelo: inicia en los niveles de madurez, presenta las Areas clave del proceso para el nivel dos y los objetivos de las practicas clave. Ademds, se consideran los aspectos esenciales para llevar a cabo una
valoracién basada en el CMMy sepresentan los esfuerzos que se han realizado en el
ambiente académico para evaluar el proceso de desarrollo de software en cursos de ingenieria del software.
Ya que tenemos la teoria para modelar procesos, en el capitulo cuatro se expone la introducciénal caso de estudio, los proyectos realizados en el curso, indicando el propésito
del modelado y las condiciones que rigen la evolucién del proyecto que se desarrolla en
esos cursos. El andlisis se presenta en un alto nivel mostrando las distintas vistas del proceso de desarrollo de software y se toma comoreferencia cada uno de los puestos para generarlos diagramasdel proceso.
software y administracién de configuracién. Estas descripciones serviran de base para ejercer los procesos en nuevoscursos de Ingenieria y Metodologia de la Programacién.
Finalmente, se presentan algunas ideas a manera de conclusién, aportacionesrealizadas y algunas vertientes que pudiera tomarel trabajo. Se incluyen, ademas, tres apéndices: en el
primero se exponenlas definiciones de los roles y términos en el Aambito del modelo CMM
Il.1 Introduccién
En este capitulo se describen los conceptos asociados al término proceso. Se muestra, brevemente, los movimientos que impulsaronel desarrollo de la ingenierfa de procesosy el propésito de esta disciplina. Se describe brevemente el enfoque metodolégico para realizar un proyecto de ingenieria de procesosy se sefialan técnicas para representarprocesos. El propésito de este capitulo es presentar el marco tedrico que sustenta al modelado de
procesos.
Il.2 Historia
En la década anterior, la globalizacién de mercadosy el rapido avance de la tecnologia de informacion, demand6 de las organizaciones su transformacién. Estos cambios se han introducido a través de Business Process Reengineering (BPR). BPR es la busqueda constante y la instrumentacién de nuevos enfoques radicales en la practica de negocios dirigidos a mejorar la productividad y servicio al cliente (Miers, 1996). Los primeros consultores prescribieron principios que demandabanel cambioradical: fuerte liderazgo de arriba-abajo, introduccion de Ja tecnologia de informacion, procesamiento paralelo y poder de decisién del empleado. Aunque el enfoque es revolucionario, algunos otros consultores tomaron un enfoque evolutivo (incremental) debido a las restricciones politicas, organizacionales y de recursos (Wastell et al., 1994).
horizontal que encapsula la interdependencia detareas, roles, individuos, departamentos y funciones requeridas para proveeral cliente un producto o servicio (Kettinger, 1997).
Los proyectos de BPR tratan de transformar los subsistemas de administraci6n (estilo,
valores, métricas), los individuos(trabajo, aptitudes, cultura), la tecnologia de informacién
y las estructuras organizacionales, incluyendo los mecanismosde coordinacién de equipos.
Porotro lado,el interés en el modelado de procesos de software, con énfasis en el soporte activo de procesos a través de la tecnologia de informacién, ha evolucionado independientemente y en paralelo con los esfuerzos de cambio en las 4reas administrativas. Ambostienen mucho en comtn, aunqueel primero esta buscando nuevas formasde liberar productos con o sin nueva tecnologia; y el segundo, persigue dar mejor soporte a las actividades centradas en procesosutilizando la tecnologia de informacion. (Warboysef al., 1999). Ambosenfoques necesitan entender sus procesos organizacionales y su relacién con
los sistemas de informacién.
La ingenieria de procesos es una manera de resolver problemas en el contexto de la organizacion, en particular aquellos cuya solucién esté basada en explotar el uso de tecnologias de coordinacién e integracién (Warboysef al., 1999).
Asi, sobre el mismo periodo de tiempo, se identificaron preocupaciones similares en un amplio sector de la comunidad de negocios y se desarrollé un vocabulario especial, el cual, aunque no compartido portodoslos ingenieros del software, Ileg6 a ser un puente entre las comunidadesde la ciencia de la computacion y la ciencia administrativa.
ll.3 Ingenieria de procesos
El campode la ingenierfa de procesos ha sido reconocida enlaliteratura recientemente, las primeras publicaciones aparecieron a principios de los noventa (Warboysefal., 1999). Esta area nacié en el domino de la ingenierfa del software debido a que los desarrolladores se encontraron estudiando procesos organizacionales, desde la perspectiva de los ingenieros del software, para mejorarlos con tecnologias adecuadas.
La disciplina de ingenieria de procesos esta en una etapa temprana de desarrollo y requiere de la construccién de unabiblioteca de estandares (aceptado porpracticantes). La ausencia de tales estandares significa que el marco de referencia esta mal definido, implicando que los resultados de la ingenierfa de procesos no sean muy predecibles.
Como un primerpaso para lograr unadisciplina madura, es necesario establecer un marco de referencia desde el cual permita ver los problemas (0 estados del problema) y se pueda formar una base para valorar soluciones. Una solucién que es elegante desde el punto de vista de la ingenierfa tradicional puedeser una solucién pobre cuandoes analizada desdeel punto de vista sociolégico. Dentro de las inquietudes de importancia para el enfoque de procesosse encuentranlas siguientes (Warboysetal., 1999):
e Los individuos son importantes. La solucién técnica mas brillante ser un fracaso en la instrumentaci6n si los usuarios no estén convencidos.
e Estudiar procesos frecuentemente puede traer mejoramiento. Sin embargo, se debe recordar que la estructura de las actividades organizacionales es s6lo una faceta de un proceso. Es esencial mejorar nuestra comprensién de los procesos que existen, y evaluarlos conel fin de sabersi estan sustentados de manera exitosa y consistente.
e La soluci6n a problemas es evolutiva. Los requerimientos y el disefio evolucionan conjuntamente para alcanzar un estado de adaptacién mutua. De la misma manera, la solucién implantada debe evolucionar subsecuentemente en relacién al ambiente de sus usuarios y otras influencias.
No existe un camino correcto parael disefio de sistemas de negocios que incluya procesos organizacionales y su mantenimiento. Sin embargo,utilizando el enfoque de ingenierfa para marcarlas actividades de disefio, se puede mejorarla probabilidad de éxito.
A diferencia de la ingenierfa tradicional, el enfoque no puede todavia garantizar una solucién perfectamente buena. La desventaja mas obvia en este contexto es la falta de una entrada sociolégica robusta y estructurada, la cual debe permanecer asi hasta que los resultados en sociologia sean més repetibles.
ll.4 Conceptos fundam entales de procesos
decir, hay un patrén de eventos que un observadorpuede reconocera través de ocurrencias distintas del proceso. Los procesos pueden seruna descripcién de ocurrencias o pudieran
darle forma a esas ocurrencias.
Los procesos construidos porlos individuos, existen con el propésito de cambiarel estado del mundoreal o pararestringirlo de alguna manera y adaptarlo a las necesidades humanas. Este tipo de proceso necesita ser articulado por un agente para efectuar las
transformaciones.
Cuando el agente es una maquina, hay regularidad y determinismo en el proceso, lo que permite una descripcidn relativamente facil y precisa. Pero, cuando se trata de agentes humanos, no es posible garantizar las consecuencias de un evento anticipado, no son deterministicos. Sin embargo,a diferencia de las maquinas, los individuos tienen capacidad adaptativa. Un individuo puede percibir un error en la definicién del proceso y tomarla iniciativa de trabajar en resolverlo. Asi, los objetivos del proceso pueden ser alcanzados aunqueel procesooriginal esté equivocado.
Todas las organizaciones, en mayor o menor grado, coordinan las actividades de sus miembros para lograr sus objetivos. Mucho del esfuerzo no productivo se dedica a la unificacion de salidas a través de la coordinacién para lograr sus objetivos, y éste, es un problema mayorque confronta a las organizaciones. La naturaleza de la coordinaci6n cubre un espectro desde el muy laxo, donde los individuos estén conscientes de los objetivos que deben lograr y se les permite procederpor cualquier medio para realizarlo; hasta el extremo restrictivo, en el que los individuos reciben descripciones explicitas de las tareas que deben realizar, entradas esperadas y salidas que debenliberar.
esté casi completa. En muchoscasos, no se entienden completamente las condiciones que estén relacionadas para quelas actividades se realicen. Asimismo, las estructuras de los procesos son frecuentemente dindmicas, en el sentido que los patrones de actividades pueden estar cambiando.
Hay muchasdefiniciones de proceso, entre las que destacan:
“Un conjunto de pasos parcialmente ordenados con el propdsito de alcanzar una meta”
(Paulk et al., 1995).
Warboyset al. (1999) presentan la definicidn de Lonchamp, como “un conjunto de pasos parcialmente ordenados, con un conjunto de artefactos relacionados, recursos humanos y computarizados, estructuras organizacionalesy restricciones, con el propésito de producir y mantenerlos productos liberables del software solicitado”’.
Curtis et al. (1992) adoptaron la ultima definicién y distinguen las diferentes perspectivas del proceso:
e Funcional. Considera qué actividades del proceso estan siendo realizadas y los flujos
de entidades de informacién relevantes.
e Desempefio o comportamiento. Considera cuando se realizan las actividades, asi
como aspectos de cémosonrealizadas (condiciones, secuencia, iteraciones).
© Organizacional. Considera dénde y por quién en la organizaciOn se realizadan las actividades.
11.4.1 Clases de procesos
Los procesos en las organizaciones existen en una gran variedad de formas, desde pasos explicitos Ilevados a cabo casi automaticamente, hasta procesos de software, que sdlo indican unaestrategia que debe ser seguida y en la que su éxito depende de la experiencia, conocimiento y cooperacién delos desarrolladores. Las diferentes clases de procesos que pueden ocurrir en la organizacién son:
Proceso operacional o proceso de produccién. Este es el que directamente se propone alcanzarlos objetivos organizacionales (eficiencia en la produccién). Todos estos procesos tienen salidas las cuales son objetosfisicos 0 textuales, o un comportamiento (servicio) el cual es de valor para alguien, ya sea dentro o fuera de la organizacion.
Proceso de control. Las metas del proceso de control son mantener continuamente un estado vinculado a otro proceso, mas que alcanzarun estado especifico. Esto significa que
el proceso de control existe en la vida de todas las ocurrencias de aquel proceso y que
pudiera tener ciclos en su definicién muchas veces. Debe tener ciertas caracteristicas
especificas, como alguna provision para la realimentacién de su andlisis y los medios para manipular los procesos operacionales conel fin de alcanzar los resultados deseados.
Proceso genérico. El término genérico significa que algo puede ser aplicable a cualquier miembro o grupo. Generalmente se refiere a una clase de abstraccién, una descripcion simplificada que exponiendo lo esencial de un proceso, evita la confusién pordetalles de implementacién. Un proceso genérico existe sdlo como un modelo, no posee suficiente informaci6n para ser usado directamente en el mundo real. Sin embargo, puede ser adaptado y asociado a individuos y maquinasparallevar a cabo el proceso.
Proceso adaptado. Es una adaptacién del proceso genérico que se ajusta a objetivos
Proceso ejecutable. Un proceso definido de tal manera y en tal medio que puede ser ejecutadoutilizando la tecnologia de procesos, como ambientescentradosen procesos. Este tipo de proceso interacciona con usuarios para coordinarsus actividades conforme progresa la instancia del proceso hasta su conclusi6n.
Il.4.2 Conceptos asociados
Los conceptos asociadosa los procesosson los siguientes:
Actividad. Es un elemento de comportamientoel cual es de interés. El grado de detalle del comportamiento tiene un alcance muy amplio, desde movimientos elementales de un individuo hasta el comportamiento de una organizacion entera. Debe hacerse una eleccién de la granularidad adecuada para los propésitos del modelado. Unatarea es una actividad administrada, es decir, que cuenta con tiempo de inicio y duracién, y de interés para la
administracion.
Agente. Es el medio para lograr la actividad o la tarea. Los agentes realizan la tarea y pueden ser humanos 0 maquinas.
Casos. Estos son las ocurrencias de los procesos para los cuales ciertos aspectos del contexto son disimilares que requieren actividades ligeramente diferentes para alcanzarlas salidas deseadas. Aunque no son lo suficientemente diferentes para que merezcan un reacomodoorganizacionalpara tratar con ellos.
Plan. Esto es la ruta de las actividades para una instancia de] proceso. Un plan muestra
como sera realizado un objetivo, no en términos de un método general o teoria, aunque
hace uso de éstos, sino en términos practicos. Consiste de submetas especificas, las cuales
en el sentido que pueden ser modificados porla informacién de realimentaci6n acerca de las actividades actuales en el mundoreal.
Procedimiento. Es un proceso que se adopta bajo circunstancias especificas. Es generalmente corto y expresado en formanarrativa. Se utiliza para considerar situaciones recurrentes 0 situaciones excepcionales anticipadas.
Proyecto. Es una arreglo temporal organizacional para alcanzar un conjunto de objetivosal ejecutar una instancia simple del proceso. Cuando se alcanzan los objetivos, el arreglo se disuelve y los recursos (humanos y maquinas) pueden ser asignados a un nuevo proyecto.
Los proyectos hacen uso de planes y procedimientos.
Programas. Los programas de software son ejemplos de la clase mas rigurosa de proceso. En general, el objetivo que deben alcanzardebe estarfijo y conocido precisamente antes de que sean escritos. Los programas determinan el comportamiento de una maquina, pero los sistemas de cémputo no determinan el comportamiento del usuario en la organizaci6n,
aunque puedeninfluenciarlo fuertemente.
ll.5 Representacion de procesos y modelos
Las descripciones de procesos pueden tomar muchasformasy es posible usar una narrativa sencilla para exponerlos. De hecho,este es frecuentemente el medio paralas descripcién de procesos, pero puede serinsatisfactorio porquetal expresién tiene la probabilidad de sufrir de la ambigiiedad inherente al lenguaje natural y puede ser semanticamente confusa, ya que la profundidad necesaria en la explicacién oscurecela entendibilidad de la descripcién.
modelo exista: la parte de la realidad que es el tema del modelo; el modelo ensj; la relacién entre ellos; y un observador, usuario o creadordel modelo.
Los modelos son representaciones expresadas en algtin medio de modelado. Un modelo sustenta en alguna abstracci6n la relacién con su tema. El propésito de crear un modelo es proveer una manera de estudiar ciertos rasgos del tema. Un modelo enfatizara ciertas propiedadesdel tema,al incluirlos en el modelo, y suprimira otros, al omitirlos. Lo que se presenta u omite en un modelo es una decisién del modeladory esta basada en el propésito
del modelo.
Un modelo tiene una estructura, la cual sistematicamente puede estar relacionada a estructuras en el mundo real. Cualquier modelo implica una abstracci6n de ciertos rasgos que el usuario o modeladorconsideran deinterés en la situacion del mundoreal.
Se ha encontrado que los modelos son muyUtiles, de hecho indispensables en muchos contextos. Son de gran asistencia en representar una parte de la realidad si se logra un mejor entendimiento de la realidad en sf misma. Esto permite el enfoque en aquellos aspectos de la realidad que son significativos en el contexto. Asi los modelos en general pueden ayudaren las siguientes maneras:
Simplifican la complejidad. Los modelos permiten la representacién de una realidad compleja en algo de compresiénclara y sirnple.
Entendimiento comun. Unarepresentacién del modelo puede ser semanticamente superior a una descripcién narrativa y asf promoverel conocimiento y el aprendizaje.
En el contexto de organizaciones, los modelos nos ayudan de diferentes maneras. La mas obvia es la captura del comportamiento del proceso, que permite exponer ese comportamiento a un anélisis racional y es posible utilizarlo para investigar diferentes formasdela realidad. Estos modelos pueden actuar como depésitos del conocimiento de la organizacion y facilitan el aprendizaje acerca de la organizacién y sus procesos.
ll.6 Metodologia de la ingenieria de procesos
En la literatura encontramos diversas metodologias para plantear e implementar un proyecto de mejora al proceso (Kettingeret al., 1997).
El Grupo de Procesos en la Universidad de Manchester (Wastell et al., 1994) desarroll6 un marco de referencia metodolédgico llamado Process Analysis and Design Methodology (PADM)(Puede encontrar mayorinformacién en Finkelstein et al. (1994)). Esta no es una metodologia prescriptiva rigurosa. Provee una bateria de herramientas y técnicas que pueden ser aplicadas de acuerdo a las circunstancias de los proyectos individuales. Esta inspirada en las metodologias Soft systems y Sociotechnical systems design.
E] disefio del sistema sociotécnico esta basado en la idea de que las organizaciones son sistemas sociotécnicos, es decir, tiene una dimension técnica y social; y que el desempefio efectivo depende de ambos subsistemas. El subsistema técnico de una organizaci6n se refiere a sus procedimientos y tecnologia; el social, denota a los individuos que trabajan en la compafifa y se enfoca en la necesidad psicoldgica de satisfacci6n enel trabajo.
La PADMconsta de cuatro fases: definicién, captura, evaluacién y redisefio del proceso. La metodologia no aborda de manera detallada la seleccién de los procesos, se enfoca en el analisis y disefio después de haberidentificado un proceso o 4rea general del negocio.
La fase de definicién implica establecer los objetivos de un proceso, definir las fronteras e interfaces, las entradas y salidas principales, los clientes que se benefician y los proveedores de entradas. En esta etapa se puedeutilizar la Soft Systems Methodology para asistir en la definicién del proceso.
En el caso particular de esta investigacién, las areas de investigacién en el proceso de desarrollo de software estén definidas en el nivel 2 del modelo CMMy son: planificacién del proyecto, seguimiento del proyecto, administracién de requerimientos, administraci6n de configuracién y aseguramiento de la calidad. La proyecciénde estas areas del proceso de software a los participantes en los proyectosdel cursoes intuitiva.
La etapa de evaluacién del proceso implica técnicas y criterios para analizar y evaluar
procesos. El propésito general es buscar debilidades y problemas en el proceso. La evaluaci6n del proceso es unaactividad cuantitativa. Hay un fuerte énfasis en identificar y medir los indicadores clave del desempefio del proceso. En términos sociotécnicos las deficiencias caen en dos categorias: técnicos y sociales. El sfntoma tfpico de un problema social puede incluir baja satisfaccién enel trabajo y motivacién pobre. Del lado técnico, se pueden distinguir dos tipos de debilidades: inefectividad e ineficiencia. Un proceso inefectivo es aquel que falla en satisfacer los requerimientos del cliente y se refleja por quejas del cliente, productos incompletos y liberados después de lo planeado y necesidad de repetir el trabajo. Del otro lado,ineficiencia, significa que el proceso esta desperdiciando recursos, aunque esta cumpliendo con sus metas.
En esta investigaciOn, nos enfocamosa los aspectos técnicos del proceso con el propésito
de identificar las debilidades en el desarrollo de software, para lograrlo, se toma como referencia de evaluacion el modelo CMM.La cuarta fase, redisefio del proceso, involucra el disefio de nuevos procesos para la organizaciOn, ya sea por mejoras incrementales o cambio radical. Otra vez existe la necesidad de un lenguaje para expresarlos nuevosdisefios del proceso.
El redisefio del proceso de desarrollo de software en este caso de estudio tiene un enfoque de mejoras incremental y se presenta una propuesta, que contiene los objetivos, recursos de entrada y salida, mediciones que deberan realizarse y diagramas rol-actividad, con la finalidad de que sirvan de guia en los cursos subsecuentes.
ll.7 Técnicas de representaci6n de procesos
opciones de mejoras a los procesos. Las técnicas que se revisaron fueron: UML, IDEFO y RAD.
I.7.1 Diagramas UML
UML (Unified Modelling Language) esta basado principalmente en el trabajo de Rumbaugh, Jacobson y Booch (Fowler y Scott, 1999). La técnica consiste de diversos diagramas auxiliares para el andlisis y disefio de sistemas orientados a objetos. Los autores agregaron un mddulo para la modelacién de procesos de negocios. Los diagramas que puedenserutilizados en la representacion de procesossonlos siguientes:
Casos de uso
Puedenserutilizados para documentarel proceso existente 0 para analizar nuevas formas del proceso, permite identificar las fronteras del sistema y las relaciones de agentes
externos al proceso.
Diagramasde interaccién
Muestran un patr6én de interaccién entre objetos. Son de dos tipos: de secuencias y de colaboracién. Los diagramas de secuencia muestran la interaccién de acuerdo a la dependencia del tiempo. Los diagramas de colaboracién muestran la secuencia de mensajes que implementa una operacién o transaccién. Mientras que los diagramas de secuencia enfatizan el comportamiento temporaldel flujo, los de colaboracién enfatizan las relaciones entre objetos.
Diagramasdetransicion de estado
Es un grafo dirigido de estados conectados por transiciones. Describe todas las formas posibles en que un objeto responde a los eventos originados por otros objetos. Deben utilizarse para objetos que reciben eventos de actores fuera del sistema. Pueden ser
Il.7.2 Diagramas IDEFO
Es una metodologia que permite el andlisis y disefio de sistemas. Fue establecida por la Fuerza Aérea de Estados Unidos como resultado del programa de integracién de computacién y manufactura. E] IDEFO es un médulo utilizado para modelar actividades capturadas de los requisitos funcionales (Kettinger et al, 1997).
Los diagramas IDEF representan los elementos del proceso con cajas y flechas. Las cajas representan las actividades o funcionesdel sistema, las flechas representan la informacién o productos necesarios para llevar a cabolas actividades (entradas y salidas de la actividad). Los mecanismos son elementosutilizados para realizar la actividad (una maquina 0 recurso humano). Los controles representan la informacién que influencia la manera en que se debe realizar la actividad. Esto forma un método riguroso para describir sistemas de cualquier tipo.
Miers (1996) recomienda que este enfoque no debe utilizarse en las primeras etapas del proyecto de reingenierfa de procesos. Esto se debe a que las entradas y salidas son los artefactos utilizados para coordinarel proceso y si estos elementos se incluyen comoparte central del modelo, puede resultar mas dificil romper el enlace con el pasado cuando se estan buscando opcionesderedisefio.
ll.7.3 Diagramasrol-actividad
La forma basica de los diagramasrol-actividad (RAD) fue introducida por Holt como una
Los RADsonintuitivamente simples y faciles de leer. Permiten que el comportamiento sea subdividido en médulos,lo que hace posible la descripcién de comportamientos complejos de una manera altamente legible. La unidad de modularizacién en un RADesun rol que involucra una responsabilidad particular.
Elementosde los diagramasrol-actividad
mw Actividad
vy Alternativa
J Meta
Rol
cg Interaccién
<A Concurrencia ,, Evento
Figura 2, Elementos de la técnica Rol Activity Diagram.
Los diagramasutilizados para describir el proceso de desarrollo estén basadosen la técnica
de diagramacion Role Activity Diagram (Ould, 1995). Los elementos que se utilizan estan
representadosen la figura 2, y se describen a continuaci6n:
Roles y actores
Un rol involucra un conjunto de actividades, las cuales, tomadas juntas, llevan una
responsabilidad particular o un conjunto de responsabilidades. Los roles pueden tomar
varias formas:
Un tinico grupo funcional, una Unica posicién funcional o cargo, un titulo de trabajo, un grupo funcional replicado, una posicidn funcional o cargo replicado, una clase de persona,
Las nocionesdetipo e instancia del tipo, son importantes en la técnica RAD. Unrol es un tipo. En principio, puede haber diferentes instancias u ocurrencias de un tipo derol activo en cualquier momento dentro de la organizaci6n.
Un actor puede tomarvarias formas. Puede ser una persona, un grupo de personas, una computadora, una persona 0 grupo de personasasistido por computadora, una maquina, una compaiifa. Es cualquier agente en el mundoreal capaz de hacerel trabajo del rol. No hay una proyecci6n uno a unoentre instancias del rol y actor. Una instancia del rol puede causarla creacién de nuevasinstanciasde roles para realizar nuevastareas.
Actividades
Las actividades son las tareas que los actores hacen como individuos en sus roles. Una
actividad debe estar bien definida, en particular es necesario saber qué la hace iniciar y qué
la hace terminar, cual es el estado de la realidad cuando inicia y cuando termina. Las actividades también son tipos que tienen instancias. Se crea una instancia de un tipo de actividad cuando el proceso de la organizacién esta en una condicién particular —lo llamamosactivaci6n o condicién de disparo para la actividad. La condicién de paro de una actividad es la condicion en la realidad que causa quela instancia deje de existir.Puede haberotras condiciones que también son verdaderas cuando unaactividad inicia que es importante apuntar. Estas son referidas colectivamente como precondiciones de la actividad. Similarmente, cada actividad tendra algunas postcondiciones las cuales describen el estado de la realidad en el tiempo que la actividad termina.
Una parte importante en la definicién de una actividad es trabajar con los materiales envueltos en ésta. Unaactividad utiliza (y posiblemente consume) sus entradas y produce salidas. Esas entradasy salidas seran referidas como entidades.
e Laactividad A debe seguir siempre a la actividad B. En otras palabras, las actividades debe estar ordenadas y seguir una secuenciaparticular.
© Puede ser Ilevada a cabo la actividad A o B dependiendo de que se cumpla alguna
condici6n, es decir, las actividades pueden ser condicionales.
e° En algtin momento, tanto la actividad A y B puedenrealizarse en paralelo. Entonces, las
actividades pueden ser concurrentes.
Alternativa
Enlas actividades a cargo de unrol, es posible que alguna de ellas deba efectuarse siempre y cuando se cumpla alguna condicién. Para mostrar esta decision se utiliza el elemento de
la técnica RADalternativa (verla figura 2).
Concurrencia
En las actividades a cargo de un rol, es posible que las actividades se puedan llevar en paralelo sin dependenciasentre estas. Cuando ocurreesta situaci6nse utiliza el elemento de la técnica RAD concurrencia(verla figura 2).
Evento
Es un acontecimiento externo al proceso que estamos modelando y que repercute en éste, de tal manera, que provoca un curso de accién enel proceso. Para representar este elemento
se utiliza la flecha (verla figura 2).
Interacciones
Unainteraccién es neutral y no tiene direccién implicita -es sdlo la coordinacién entre roles. Pero una interaccién puede incluir la transferencia de algo, entidades; o puede consistir en una discusién con acuerdos. Las interacciones se pueden dar entre dos 0 mas
roles. Las interacciones son siempre sincronas; ambas instancias del rol deben estar listas
Metasdel Proceso
En el modelo del proceso queremos identificar el punto (o los puntos) donde se logra la meta del proceso. Podemos identificar el rol en algtin punto, donde el estado ha sido alcanzado, es decir, el estado en ese punto es la meta. Alcanzar el estado es alcanzar la meta. En algunas situaciones la meta puede ser mas compleja y equivalente a una combinaci6n de estados en varios roles.
Es importante ver los modelos de procesos como descripciones de la manera en que la
organizacion cambia de estado, desde su estado inicial (alguien solicitando un servicio)
hasta el estado final (servicio entregado). Otro punto de vista es pensar que los procesos toman entradas y producen salidas, aunque muchos procesos tienen metas que no son tangibles de esta forma.
Entidades
Entidad es el nombre dado a cualquiera que sea sujeto de trabajo de una actividad. Las entidades puedenserentradas y salidas de unaactividad.
Ingeniero de validacién y verificacion
Productor
Tilia, (Gp A
Periodo de
/__|_ Acordar revision
i revision técnica at
Prepara agenda
Tyee producto Revisor
=)
Distribuye agenda y soe
producto Especialista en
documentacion
Evaluar
producto
Presentar oe anrreyiaiea Cusstionar el Registrar minula [_poroducto oe producto
4Se apruebael
producto?
no si
Entregarlista Documento
“f de defectos ‘aprobado.
Se establece
Hacer‘ ‘ linea base
modificaciones \ )
Figura 3. Proceso para la revision de un producto de software.
1.7.4 Comparaci6n delas técnicas para generar diagramas
Tabla I. Comparaciénde las técnicas para realizar diagramas: UML, IDEFO y RAD. La base de la comparaci6n sonlascaracteristicas de los procesos a los cuales deben dar
soporte.
Actividad Orden
Decisié6n Rol
Responsable de la decisién
Interacci6n Evento Meta
Reglas del negocio
Facilidad de comprensié6n
¥v
¥
v
x
x
x
4
x
SUSY
<<VSSyygyss
Este trabajo toma como referencia la técnica RAD, ya que es la que permite mayor flexibilidad para generar modelos, brinda el soporte a las caracteristicas del proceso y los diagramas son simplesy faciles deleer.
Il.8 Estandares para el proceso de software
El enfoque a procesos en el area de ingenieria del software con el propdésito de mejorarla calidad, reducir los costos y el ciclo de vida de los proyectos ha dado frutos en forma de estandares internacionales y prdacticas de ingenierfa ampliamente aceptadas. Emmerich (1999)sefiala que las iniciativas para incrementarel nivel de madurez de las organizaciones que desarrollan software han tomadotres direcciones:
e Definicién de procesos estandares. Estas se enfocan en los puntos clave que deben ser
considerados para proporcionar un manual de calidad bien definido y efectivo. Por
ejemplo el ISO 9000.
e Definici6n de métodos de valoracién. Estas proveen directrices para evaluar la
modelos identifican diferentes niveles de madurez y un método de valoracién, lo que
permite colocar a una organizaci6n en dentro de una escala de madurez.
e Definicién de métodos para sustentar el mejoramiento de un proceso existente. Por ejemplo, el Quality Improvement Paradigm esté basado en la idea de que el mejoramiento del proceso puede ser logrado sdlo si la organizaciédn es capaz de aprender de las experiencias previas. Durante la ejecucién del proyecto se realizan algunas mediciones apropiadas, se recolectan los datos y se analizan y se empaquetan para uso futuro. Algunos métodos de valoracién también proveen pautas de mejoramiento.
Este trabajo esté basado en el CMM. Las razones que nos Ilevaron a tomar esta decisién incluyen el acceso al modelo sin costo, las referencias publicadas de las experiencias de organizacionesal incorporar el CMM la aplicacion en el 4mbito educativo en los cursos de ingenierfa del software. Finalmente, el CMM describe los requisitos del proceso mientras que otros modelos prescriben procesos, y ademas, permite valorar el estado del proceso para identificar fortalezas y debilidades.
I1.8.1 El modelo CMM
Para evaluar la madurez de una organizacion e identificar los aspectos que deben ser
considerados en la mejora de procesos, el Software Engineering Institute (SEI) definié un modelo de madurez, llamado Modelo de Maduracién de Capacidades (CMM). Este modelo
define cinco niveles de madurez para las industrias del software.
El SEI suministra dos programas diferentes para la valoracion de procesos de software:
e Programa de evaluacién de la capacidad de software. Puede ser utilizado por los clientes (en particular, lo han utilizado las agencias de gobierno de Estados Unidos) para evaluar los procesos y niveles de madurez de sus contratistas (Byrnes y Phillips,
1996).
Estos dos programas comparten casi el mismo método de valoracion. En el primercaso,el resultado del programa de valoracién es un documento que proporcionaa la organizaci6n sugerencias de cémo conducir el mejoramiento de procesos. En el segundo,se calcula una
calificacién en una escala ordinal de | a 5, la cual cuantifica el nivel de madurez de la
organizacion. En general, en el primercaso la valoracién puedeserrealizada por la misma organizacién, posiblemente bajo la asistencia del SEI; mientras que en el segundo, la valoracion es realizada por un equipo externo independiente.
El programa de valoracién del proceso de software inicia con el entrenamiento del equipo valuador. Después de esto, el equipo selecciona algtin proyecto representativo de la organizacion para evaluarlo. Los miembros del proyecto seleccionado completaran el cuestionario del SEI y seran entrevistados por el equipo valuador. El equipo utiliza el cuestionario y la informacién obtenida de las entrevistas para preparar un reporte que identifica las debilidades de la organizacién. Después, la organizacién evaluada da seguimiento a las soluciones y directrices recomendadas para mejorar su proceso. Con el fin de obtener buenos resultados de la evaluacién, es necesario que la alta direccidn apoye esta valoracién, con ello se logra que los individuos participantes estén alentados porel hecho de que sus sugerencias sean tomadas en cuenta y que influencian los procesos actuales de mejoramiento enel desarrollo de productos.
CapituloIll. Modelo de Maduraci6n de Capacidades
Ill.1 Introduccion
A finales de los ochenta, el Software Engineering Institute (SEI) inicié el trabajo en la valoraci6n de procesos de software. Para evaluar la madurez de la organizaci6ne identificar los aspectos que deben considerarse para mejorar el proceso, definid un modelo de madurez, llamado Modelo de Maduracién de Capacidades (CMM). En este capitulo se
describen brevementelas caracteristicas del modelo, los métodosde evaluaci6n utilizados y
la aplicacién al ambiente educativo.
Ill.2 Conceptos fundam entales de soporte a la madurez del
proceso
El CMM se enfoca en la capacidad de las organizaciones de software para generar productos de alta calidad, de manera consistente y predecible. Paulk et al. (1995) toman comobase los siguientes conceptospara elaborar el modelo de maduracién de capacidades:
Unproceso es una secuencia de pasos realizados con un propésito dado. El proceso integra individuos, herramientas y procedimientos. El proceso es lo que los individuos hacen, utilizando procedimientos, métodos, herramientas y equipo para transformarlas entradas (insumos) en unasalida (producto) que es de valorpara losclientes.
La capacidad del proceso de software describe el intervalo de resultados esperados que pueden ser alcanzados al seguir un proceso de software. Ayuda a predecir las salidas esperadas del siguiente proyecto de software que se desarrolle en la organizacion.
El desempejfio del proceso de software representalos logros obtenidosal seguir un proceso de software. Esta enfocado en los resultados logrados, mientras que el concepto anterior en los resultados esperados.
La madurez del proceso de software es la extension en la cual un proceso especifico esta
explicitamente definido, administrado, medido, controlado y es efectivo. La madurez
implica el potencial de crecimiento en la capacidad.
lll.3 Beneficios y riesgos del mejoramiento basado en el modelo
El CMM ayuda a formaruna visi6n compartida de lo que es el mejoramiento del proceso de software y lo que significa para la organizacién. Establece un lenguaje comtn para referirse a los procesos de software y define un conjunto de prioridades para atacar los problemasdel software.
El CMM soporta la medicién del proceso de software al proveer un marco de referencia para realizar evaluaciones confiables y consistentes. Aunque el juicio humano no puede ser removido, provee una base parala objetividad.
El CMM esta construido sobre un conjunto de procesos y practicas que han sido desarrolladas en colaboraci6n con una amplia selecci6n de practicantes.
Los modelos son simplificaciones del mundo real que representan y el CMM noes una descripcién exhaustiva del proceso de software. No esta completo: no contempla otros factores, como individuos y tecnologia, que afectan el éxito del proyecto de software
