4.

Modelos de Proceso del Software

El proceso es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso, el desarrollo de software implcito, latente e incompleto en gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el que se rene el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una iteracin entre los usuarios y los diseadores, entre los usuarios y las herramientas de desarrollo, y entre los diseadores y las herramientas de desarrollo tecnologa!. Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicacin, con cada iteracin del dialogo se o"tiene mayor conocimiento.
Howard Baetjer

Desde un punto de vista tcnico se puede decir que el proceso de software es un marco de trabajo de las tareas que se requieren para construir software de alta calidad. Aun ms importante es que la Ingeniera del oftware la reali!an personas

creativas" con conocimiento" que deberan trabajar dentro de un proceso del software definido # avan!ado que es apropiado para los productos que constru#en # para las demandas de su mercado.

4.1 Modelo de cascada $%&

#odelo de $ascada %ennington &'(), #odificado por *oyce en &'+,, -ressman lo presenta como ciclo de vida cl.sico!. e denomina modelo en cascada porque su caracterstica principal es que no se comien!a con un paso 'asta que no se 'a terminado el anterior. (l modelo en )ascada establece que el software debe ser construido" rigurosamente" a travs de una transformaci*n sucesiva de documentos" siguiendo una estrategia lineal de desarrollo. +rimero saber qu se quiere # despus" cuando se cono!ca todo lo que se quiere" empe!ar a construirlo.
,%.odelos de proceso de software

(l modelo de cascada tambin conocido como modelo lineal secuencial sugiere un enfoque sistemtico" secuencial para el desarrollo del software que comien!a en un nivel de sistemas # progresa con el anlisis" dise/o" codificaci*n" pruebas # mantenimiento. A grandes rasgos el primer paso es conseguir un documento con la especificaci*n completa" e0acta" no ambigua de los requisitos del sistema software que debe ser desarrollado. (ste documento inicial es transformado en un documento de anlisis" supuestamente alejado de la mquina. Despus" a partir del anlisis" se obtiene otro documento" el dise/o. 1 por 2ltimo" del dise/o se obtiene el documento final3 el c*digo. +ara asegurar que no se introducen equivocaciones al transformar un documento 4modelo5 en otro" se 'acen pruebas" al terminar cada uno. 6as pruebas son planificadas desde el principio # se documentan como se va#an reali!ando. Antes de la entrega del sistema software" se valida que satisface los requisitos definidos en el documento inicial. (st basado en el ciclo convencional de una ingeniera" tiene las siguientes actividades que se muestran en la figura %., del modelo de cascada3
Ingeniera # Anlisis del istema Anlisis de los 7equisitos Dise/o )odificaci*n +rueba .antenimiento
Figura 4.1 .odelo de )ascada
)arolina 8ibert" 9)iclos de vida de Ingeniera de oftware: $(n lnea&" )aracas ;ene!uela $)onsulta3 Abril de <--=&">carolina.terna.net?ingsw<?Datos?)ascada@.odelo;.docA

,%, .odelos de proceso de software

Instituto Becnol*gico de .orelia

4.1.1 Actividades
Ingeniera y Anlisis del Sistema Debido a que el software es siempre parte de un sistema ma#or" el trabajo comien!a estableciendo los requisitos de todos los elementos del sistema # luego asignando alg2n subconjunto de estos requisitos al software. Anlisis de los requisitos del software Anlisis3 e anali!an las necesidades de los usuarios finales del software para

determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada 7D 4Documento de (specificaci*n de 7equisitos5" que contiene la especificaci*n completa de lo que debe 'acer el sistema sin entrar en detalles internos 4debe comprender el mbito de la informaci*n del software" as como la funci*n" el rendimiento # las interfaces requeridas5. $%& ise!o (l dise/o del software se enfoca en cuatro atributos distintos del programa3 la estructura de los datos" la arquitectura del software" el detalle procedimental # la caracteri!aci*n de la interfa!. (l proceso de dise/o traduce los requisitos en una representaci*n del software con la calidad requerida antes de que comience la codificaci*n. )omo resultado surge el DD 4Documento de Dise/o del oftware5" que contiene la descripci*n de la estructura global del sistema # la especificaci*n de lo que debe 'acer cada una de sus partes" as como la manera en que se combinan unas con otras. $%&

,%< .odelos de proceso de software

"odificaci#n (s la fase de programaci*n. Aqu se desarrolla el c*digo fuente" el dise/o debe traducirse en una forma legible para la maquina" 'aciendo uso de prototipos as como pruebas # ensa#os para corregir errores. (l paso de codificaci*n reali!a esta tarea. i el dise/o se reali!a de una manera detallada la codificaci*n puede reali!arse mecnicamente. $%& Prue$a Cna ve! que se 'a generado el c*digo comien!a la prueba del programa. 6a prueba se centra en la l*gica interna del software" # en las funciones e0ternas" reali!ando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. ser puesto en e0plotaci*n. $%& Mantenimiento (l software sufrir cambios despus de que se entrega al cliente. 6os cambios ocurrirn cuando se 'a#an encontrado errores" esto en lugar de que el software deba adaptarse a cambios del entorno e0terno 4sistema operativo o dispositivos perifricos5" o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. $%& esventa%as 6os pro#ectos reales raramente siguen el flujo secuencial que propone el modelo" siempre 'a# iteraciones # se crean problemas en la aplicaci*n del paradigma. Dormalmente" es difcil para el cliente establecer e0plcitamente al principio todos los requisitos. (l ciclo de vida clsico lo requiere # tiene dificultades e comprueba que funciona correctamente antes de

,%E .odelos de proceso de software

Instituto Becnol*gico de .orelia

en acomodar posibles incertidumbres que pueden e0istir al comien!o de muc'os productos. (l cliente debe tener paciencia. Hasta llegar a las etapas finales del pro#ecto" no estar disponible una versi*n operativa del programa. Cn error importante no detectado 'asta que el programa este funcionando puede ser desastroso. e tiene un /lto riesgo en sistemas nuevos debido a problemas en las especificaciones # en el dise/o. %ajo riesgo para desarrollos bien comprendidos utili!ando tecnologa conocida (ste modelo" que se lleva a cabo de forma descendente" e0ige que para pasar a la siguiente fase 'a# que concluir correctamente la anterior" de manera que los posibles errores sean fcilmente detectables. As" la salida de una fase es la entrada de la siguiente. 6a Ventaja de este mtodo radica en su sencille! #a que sigue los pasos intuitivos necesarios a la 'ora de desarrollar el software.

4.& Modelo de es'iral

(l modelo espiral propuesto originalmente por Boe'm en ,FGG" es un modelo de proceso de software evolutivo 'a sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico" como de la creaci*n de prototipos" a/adiendo al mismo tiempo un nuevo elemento3 el an.lisis de riesgo. +roporciona el potencial para el desarrollo rpido de versiones incrementales del software. (n este modelo el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones" la versi*n incremental podra ser un modelo en papel o un prototipo. (n las 2ltimas iteraciones" se producen versiones cada ve! mas completas del sistema dise/ado.

,%% .odelos de proceso de software

(l modelo representado mediante la espiral de la figura %.< define cuatro actividades principales" tambin llamadas regiones de tareas o sectores3 1. Planificaci#n. Durante la primera vuelta alrededor de la espiral se definen los objetivos" las alternativas # las restricciones" se anali!an e identifican los riesgos. i el anlisis de riesgo indica que 'a# una incertidumbre en los requisitos" se puede usar la creaci*n de prototipos en el cuadrante de ingeniera para dar asistencia tanto al encargado de desarrollo como al cliente.$,& &. Anlisis de riesgo. (l pro#ecto se revisa # se toma la decisi*n de si se debe continuar con un ciclo posterior de la espiral. i se decide continuar" se desarrollan los planes para la siguiente fase del pro#ecto. $,& (. Ingeniera. (n este sector se desarrolla # se valida. Despus de la evaluaci*n de riesgos" se elige un modelo para el desarrollo del sistema.
$,&

4. )valuaci#n del cliente. (l cliente eval2a el trabajo de ingeniera 4cuadrante de evaluaci*n de cliente5 # sugiere modificaciones. obre la base de los comentarios del cliente se produce la siguiente fase de planificaci*n # de anlisis de riesgo. (n cada bucle alrededor de la espiral" la culminaci*n del anlisis de riesgo resulta en una decisi*n de Hseguir o no seguirH.$,& )on cada iteraci*n alrededor de la espiral 4comen!ando en el centro # siguiendo 'acia el e0terior5" se constru#en sucesivas versiones del software" cada ve! ms completas #" al final" el propio sistema operacional. De acuerdo con ommerville Cn ciclo en espiral inicia con la elaboraci*n de

objetivos" como el rendimiento # la funcionalidad. Despus se enumeran formas alternativas de alcan!ar estos objetivos # las restricciones impuestas en cada una de ellas. )ada alternativa se eval2a contra cada objetivo # se identifican las fuentes de riesgo del pro#ecto. 6o siguiente es resolver los riesgos mediante actividades de recopilaci*n de informaci*n como la de detallar ms el anlisis" la
,%I .odelos de proceso de software

Instituto Becnol*gico de .orelia

construcci*n de prototipos # la simulaci*n. 1a que se evaluaron los riesgos" se lleva a cabo cierto desarrollo" seguido de una actividad de planificaci*n para la siguiente fase. (l paradigma del modelo en espiral para la Ingeniera de oftware es actualmente el enfoque ms realista para el desarrollo de software # de sistemas a gran escala. Ctili!a un enfoque evolutivo" permitiendo al desarrollador # al cliente entender # reaccionar a los riesgos en cada nivel. Ctili!a la creaci*n de prototipos como un mecanismo de reducci*n de riesgo" pero" lo que es ms importante permite a quien lo desarrolla aplicar el enfoque de creaci*n de prototipos en cualquier etapa de la evoluci*n de prototipos.

Planificaci#n
Anlisis de riesgo Anlisis de riesgo Anlisis de riesgo +rototipo E 7evisi*n A7 +rototipo < +rototipo ,
+lan de requisitos" +lan de ciclo de vida
+lan de desarrollo

Anlisis de *iesgos

+rototipo Jperativo

)oncepto de operaci*n

Simulaciones+ Modelos+ )stndares

7equisitos de oftware Dise/o del producto de software

;alidaci*n de requisitos

Dise/o detallado

+lan de prueba e Integraci*n

)odificaci*n ;erificaci*n # validaci*n de dise/o +rueba de Cnidad +rueba de Integraci*n

)valuaci#n del "liente

+rueba de aceptaci*n Implementaci*n

Ingeniera

Figura 4.& .odelo de (spiral de Boe'm

ommerville" Ian 4<--I5" Ingeniera de software" (d. Addison Kesle# LM ed

,%= .odelos de proceso de software

4.( Modelo incremental $<&

(l modelo incremental aplica secuencias lineales de forma escalonada mientras avan!a el tiempo. )orrige la necesidad de una secuencia no lineal de pasos de desarrollo. )ada secuencia lineal produce un incremento del software. +or ejemplo" el software de tratamiento de te0tos desarrollado con el paradigma incremental podra e0traer funciones de gesti*n de arc'ivos bsicos # de producci*n de documentos en el primer incrementoN funciones de edici*n mas sofisticadas # de producci*n de documentos en el segundo incrementoN correcci*n ortogrfica # gramatical en el terceroN # una funci*n avan!ada de esquema de pagina en el cuarto. e debera tener en cuenta que el flujo del proceso de cualquier incremento pude incorporar el paradigma de construcci*n de prototipos. El modelo incremental entrega el software en partes pequeas, pero utiliza"les, llamadas 0incrementos1. En general, cada incremento se construye so"re aquel que ya ha sido entregado. 234 )uando se utili!a un modelo incremental" el primer incremento a menudo es un producto esencial. (s decir" se afrontan requisitos bsicos" pero muc'as funciones suplementarias 4algunas conocidas" otras no5 quedan sin e0traer. (l cliente utili!a el producto central 4o sufre la revisi*n detalla5. )omo un resultado de utili!aci*n #?o de evaluaci*n" se desarrolla un plan para el incremento siguiente. (l plan afronta la modificaci*n del producto central a fin de cumplir mejor las necesidades del cliente # la entrega de funciones" # caractersticas adicionales. (ste proceso se repite siguiendo la entrega de cada incremento. Hasta que se elabore el producto completo. (l modelo de proceso incremental" como la construcci*n de prototipos # otros enfoques evolutivos" es iterativo por naturale!a. +ero a diferencia de la construcci*n de prototipos" el modelo incremental se centra en la entrega de un producto operacional con cada incremento. 6os primero incrementos son
,%L .odelos de proceso de software

Instituto Becnol*gico de .orelia

versiones 9incompletas: del producto final" pero proporcionan al usuario la funcionalidad que precisa # tambin una plataforma para la evaluaci*n. (l desarrollo incremental es particularmente 2til cuando el personal no esta disponible para una implementaci*n completa en la fec'a lmite que se 'a#a establecido para el pro#ecto. 6os primeros incrementos se pueden implementar con menos personas. (ste modelo constitu#o un avance sobre el modelo en cascada pero tambin presenta problemas. Aunque permite el cambio continuo de requisitos" aun e0iste el problema de determinar si los requisitos propuestos son validos. 6os errores en los requisitos se presentan tarde # su correcci*n resulta tan costosa como en el modelo en cascada.

4.4 Proceso de desarrollo unificado $,G&

(s un modelo complejo con muc'a terminologa propia" pensado principalmente para el desarrollo de grandes pro#ectos. (s un proceso que puede adaptarse # e0tenderse en funci*n de las necesidades de cada empresa. (s el resultado de esfuer!o de las tres 2ltimas dcadas en desarrollo de software # de la e0periencia de sus creadores Ivar Oacobson" Prad# Booc' # Oames 7umbaug'.

4.4.1 ,rgenes
(l antecedente ms importante lo ubicamos en ,F=L con la .etodologa (ricsson 4(ricsson Approac'5" sta es una apro0imaci*n de desarrollo basada en componentes" que introdujo el concepto de caso de usoN entre los a/os de ,FGL a ,FFI Oacobson funda la compa/a 9Jbjector# AB: # lan!a el proceso de desarrollo Jbjector# 4abreviaci*n de Jbject Qactor#5" posteriormente en ,FFI 97ational oftware )orporation: adquiere 9Jbjector# AB: # es entre ,FFI # ,FFL que se desarrolla 97ational Jbjector# +rocess 47J+5: fruto del encuentro # evoluci*n de
,%G .odelos de proceso de software

Jbjector# E.G # la .etodologa 7ational 47ational Approac'5 que adopta por primera ve! C.6 como lenguaje de modelamiento. $,=& A principios de los noventas" la guerra de los mtodos 'i!o evidente la necesidad de unificar criterios" es as como Prad# Booc' autor del mtodo Booc' # Oames 7umbaug' 4desarrollador para Peneral (lectric5 se unieron en 7ational en ,FF%" despus en ,FFI se une Oacobson # gracias al esfuer!o de varias compa/as # metodologistas evolucion* C.6 'asta ser un estndar en ,FFL" el cual es adoptado en todos los modelos del 7J+. Desde ese entonces # a la cabe!a de Booc'" Oacobson # 7umbaug'" 7ational 'a desarrollado e incorporado diversos elementos para e0pandir el 7J+" destacndose especialmente el flujo de trabajo conocido como modelamiento del negocio" es as como en junio del ,FFG se lan!a 7ational Cnified +rocess I.-. 6a evoluci*n # orgenes de este proceso de desarrollo se puede visuali!ar mejor en la figura <., $,=&

4.4.& "aractersticas del Proceso -nificado de

esarrollo

(l +roceso Cnificado gua a los equipos de pro#ecto en c*mo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio" el tiempo al mercado # los riesgos del pro#ecto. (l proceso describe los diversos pasos involucrados en la captura de los requerimientos # en el establecimiento de una gua arquitect*nica" para dise/ar # probar el sistema 'ec'o de acuerdo a los requerimientos # a la arquitectura. (l proceso describe qu producto se debe producir" c*mo desarrollar lo que vamos a entregar # tambin provee patrones. (l proceso unificado es soportado por 'erramientas que automati!an entre otras cosas" el modelado visual" la administraci*n de cambios # las pruebas. (l +roceso Cnificado est "asado en componentes" lo cual quiere decir que el sistema software en construcci*n est formado por componentes de software interconectados a travs de interfaces bien definidas. Adems" el +roceso
,%F .odelos de proceso de software

Instituto Becnol*gico de .orelia

Cnificado utiliza el 5#6 para e0presar grficamente todos los esquemas de un sistema de software. +ero" realmente" las caractersticas que definen este +roceso Cnificado son tres3 7terativo e 7ncremental, 8irigido por casos de uso y $entrado en la /rquitectura.

4.4.&.1

irigido 'or casos de uso

5n caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. 6os casos de uso modelan los requerimientos funcionales del sistema. 2&+4

Basndose en los casos de uso" los desarrolladores crean una serie de modelos de dise/o e implementaci*n que llevan a cabo. Adems" estos modelos se validan para que sean conforme a los casos de uso. Qinalmente" los casos de uso se usan para reali!ar los casos de pruebas sobre los componentes desarrollados. 6os casos de uso no solo inician el proceso" sino que tambin proporcionan un 'ilo conductor en todo el ciclo de vida del desarrollo de software. (n conclusi*n los casos de uso son utili!ados para3 (stablecer el comportamiento deseado del sistema ;erificar # validar la arquitectura del sistema Hacer +ruebas Bener una comunicaci*n entre los participantes del pro#ecto

4.4.&.& "entrado en la arquitectura

6a arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcci*n. Arquitectura3 $onjunto de decisiones significativas acerca de la organizacin de un sistema software, la seleccin de los elementos estructurales a partir de los
,I.odelos de proceso de software

cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus cola"oraciones, y su composicin. $,L& (l concepto de arquitectura software inclu#e los aspectos estticos # dinmicos ms significativos del sistema. 6a arquitectura es una vista del dise/o completo con las caractersticas ms importantes resaltadas" dejando los detalles de lado. 6os casos de uso y la arquitectura est.n profundamente relacionados . 6os casos de uso deben encajar en la arquitectura" # a su ve! la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos" actualmente # a futuro. (l arquitecto desarrolla la forma o arquitectura a partir de la comprensi*n de un conjunto reducido de casos de uso fundamentales o crticos 4usualmente no mas del ,- R del total5. (l arquitecto3 )rea un esquema en borrador de la arquitectura comen!ando por la parte no especfica de los casos de uso 4por ejemplo la plataforma5 pero con una comprensi*n general de los casos de uso fundamentales. (nseguida" trabaja con un conjunto de casos de uso clave o fundamental. )ada caso de uso es especificado en detalle # reali!ado en trminos de subsistemas" clases" # componentes. A medida que los casos de uso se especifican # maduran" se descubre ms de la arquitectura" # esto a su ve! lleva a la maduraci*n de ms casos de uso. (ste proceso contin2a 'asta que se considere que la arquitectura es estable.

,I, .odelos de proceso de software

Instituto Becnol*gico de .orelia

4.4.&.( Iterativo e incremental

Bodo sistema complejo supone un gran esfuer!o que puede durar desde varios meses 'asta a/os. +or lo tanto" lo ms prctico es dividir un pro#ecto en varias fases o mini proyectos. 5na iteracin es un "ucle de desarrollo completo, es una secuencia de actividades con un plan esta"lecido y criterios de evaluacin. /ca"a en la edicin de un producto ejecuta"le, su"conjunto del producto final "ajo desarrollo . e suele 'ablar de ciclos de vida en los que se reali!an varios recorridos por todas las fases. )ada recorrido por las fases se denomina 7teracin en el pro#ecto en la que se reali!an varios tipos de trabajo 4denominados flujos5. )ada iteracin parte de la anterior incrementado 4crece el producto5 o revisando la funcionalidad implementada. 6os desarrolladores basan la selecci*n de lo que implementarn en cada iteraci*n en dos cosas3 el conjunto de casos de uso que amplan la funcionalidad" # en los riesgos ms importantes que deben mitigarse. 6as iteraciones deben estar controladas. (sto significa que deben seleccionarse # ejecutarse de una forma planificada. 6os beneficios de este enfoque iterativo son3 6a iteracin controlada reduce el riesgo a los costos de un solo incremento. 7educe el riesgo de retrasos en el calendario atacando los riesgos ms importantes primero. Acelera el desarrollo. 6os trabajadores trabajan de manera ms eficiente al obtener resultados a corto pla!o. Biene un enfoque ms realista al reconocer que los requisitos no pueden definirse completamente al principio.

4.4.&.4 .asado en com'onentes

,I< .odelos de proceso de software

6a creaci*n de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas" que posteriormente sern ensamblados para generar el sistema. (sta caracterstica en un proceso de desarrollo" permite que el sistema se va#a creando a medida que se obtienen o que se desarrolla # maduran sus componentes. 5n componente, es una parte del sistema, fsica y reemplaza"le, que est. sujeto ., y proporciona la implementacin de un conjunto de interfaces. (l desarrollo "asado en componentes consiste en la creaci*n e implantaci*n de sistemas de software complejos" ensamblados a partir de componentes" # que ponen a la ve! nuevos componentes a disposici*n de otros sistemas. -uede automatizarse mediante herramientas y procesos, que permiten aumentar la productividad, calidad y tiempo de desarrollo.

4.4.3 Ciclo de vida

(l +roceso Cnificado se repite a lo largo de una serie de ciclos que constitu#en la vida de un sistema. )ada ciclo constitu#e una versi#n del sistema.

4.4.(.1 Fases
)ada ciclo consta de cuatro fases3 inicio" elaboraci*n" construcci*n" # transici*n3 Inicio3 Definici*n del pro#ecto. )la$oraci#n3 +lanificaci*n del pro#ecto" especificaci*n de caractersticas # elaborar arquitectura base. "onstrucci#n3 )onstrucci*n del sistema. /ransici#n3 Bransici*n a usuarios

,IE .odelos de proceso de software

Instituto Becnol*gico de .orelia

Inicio /iem'o

)la$oraci#n

"onstrucci#n

/ransici#n

0isi#n

Arquitectura

"a'acidad inicial

)dici#n del 'roducto

Figura 4.( Qases del )iclo de ;ida

Ivar Oacobson" 9Appl#ing C.6 in B'e Cnified +rocess: $(n linea&" $)onsulta3(nero de <--=&"

Iteraciones dentro del ciclo de>'ttp3??www.jecSle.de?files?uniproc.pdfA vida. )ada fase se subdivide en iteraciones. (n cada iteraci*n se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

Inicio /iem'o
Iteraci#n Preliminar 1

)la$oraci#n

"onstrucci#n

/ransici#n

Iteraci#n Arquitectura

Iteraci#n esarrollo

Iteraci#n esarrollo

Iteraci#n /ransici#n

0isi#n

Arquitectura

"a'acidad inicial

)dici#n del 'roducto

Figura 4.4 Iteraciones # fases

Ivar Oacobson" 9Appl#ing C.6 in B'e Cnified +rocess: $(n linea&" $)onsulta3(nero de <--=&"

4.4.(.&

isci'linas

>'ttp3??www.jecSle.de?files?uniproc.pdfA

)ada disci'lina es un conjunto de actividades relacionadas 4flujos de trabajo5 vinculadas a un rea especfica dentro del pro#ecto total. 6as ms importantes son3 Requerimientos, Anlisis, Diseo, Codificacin, !rue"a.

(l agrupamiento de actividades en disciplinas es principalmente una a#uda para comprender el pro#ecto desde la visi*n tradicional en cascada . )ada disciplina est asociada con un conjunto de modelos que se desarrollan. (stos modelos estn compuestos por artefactos. 6os artefactos ms importantes

,I% .odelos de proceso de software

son los modelos que cada disciplina reali!a3 modelo de casos de uso" modelo de dise/o" modelo de implementaci*n" # modelo de prueba. (l +roceso Cnificado consiste en una serie de disci'linas o flu%os de tra$a%o que van desde los requisitos 'asta las pruebas. 6os flujos de trabajo desarrollan modelos desde el modelo de casos de uso 'asta el modelo de pruebas.

4.4.(.( 2itos
)ada fase finali!a con un 3ito. )ada 'ito se determina por la disponibilidad de un conjunto de artefactos 47C+ llama artefactos a un subproducto5" es decir un conjunto de modelos o documentos que 'an sido desarrollados 'asta alcan!ar un estado predefinido. 6os hitos tienen muc'os objetivos. (l ms crtico es que los encargados del pro#ecto deben tomar ciertas decisiones antes de que el trabajo contin2e con la siguiente fase. 6os 'itos tambin permiten controlar la direcci*n # progreso del trabajo. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo # esfuer!o consumidos en cada fase. (stos datos son 2tiles para la estimaci*n en futuros pro#ectos.

4.4.(.4 Artefactos
Dentro del +roceso de Desarrollo Cnificado se denomina artefacto a todo producto o subproducto resultante del proceso. Dentro de esto se encuentra desde el propio c*digo fuente 'asta la documentaci*n aportada por el cliente # la entregada al completarse cada 'ito dentro del pro#ecto. +ara su mejor comprensi*n 'emos agrupado todos los artefactos posibles del proceso en tres grandes grupos3 /rtefactos entregados por el cliente, /rtefactos internos del proceso y /rtefactos entrega"les al cliente.

,II .odelos de proceso de software

Instituto Becnol*gico de .orelia

Do siempre en todo pro#ecto se crean los mismos artefactos" esto depender de las caractersticas del pro#ecto # los requisitos del cliente" siendo tarea de la gesti*n de la configuraci*n el definir qu artefactos especficos # con qu nivel de formalidad se crearn para el pro#ecto en cuesti*n.

4.4.(.4.1 Artefactos entregados 'or el cliente

4losario de /5rminos6

*lo e0iste uno para todo el sistema" que contiene

un conjunto de definiciones concisas para favorecer la comunicaci*n # evitar malos entendidos entre todos los involucrados. 6os miembros del pro#ecto utili!arn el glosario inicialmente para comprender sus trminos especficos. )s'ecificaciones de los casos de uso6 (s una colecci*n de documentos que recogen la especificaci*n completa de cada caso de uso. )ada uno contiene los campos3 nombre" descripci*n" actores" precondiciones" postcondiciones" flujo bsico" flujos alternativos" puntos de e0tensi*n" entre otros que describen en detalle un caso de uso. Modelo de casos de uso6 (s un modelo de las funciones concebidas del sistema # su entorno. (s una entrada importante a actividades de anlisis" dise/o # prueba. Inclu#e todos los actores # casos de uso del sistema con sus descripciones. +uede ser entregado directamente en el formato que utilice la 'erramienta de modelaci*n o gesti*n empleada" o mediante un informe de este modelo que contenga toda esta informaci*n que se complementar con las (specificaciones de los casos de uso. )s'ecificaciones su'lementarias6 (ste artefacto captura los requerimientos del sistema que no fueron recogidos en el .odelo de casos de uso. Peneralmente contiene los requerimientos no funcionales del sistema. )s'ecificaci#n de requisitos del software6 (n los casos en que la empresa cliente no desee utili!ar el enfoque de casos de uso para la
,I= .odelos de proceso de software

gesti*n de requisitos" podr entregar en lugar de los E artefactos descritos anteriormente un solo documento que recoja las caractersticas" requisitos funcionales # no funcionales del sistema" as como otra informaci*n 2til como por ejemplo3 restricciones en el dise/o e implementaci*n" componentes comprados a terceros" interfases de 'ardware o software" etc. ocumento de arquitectura del software6 (ste documento brinda un resumen de la arquitectura utili!ando varias vistas diferentes que muestran distintos aspectos del sistema. (s un medio de comunicaci*n entre el arquitecto de software # otros miembros del equipo del pro#ecto" acerca de las decisiones significativas que 'an sido tomadas para la arquitectura. Modelo de dise!o6 (s una abstracci*n de la implementaci*n del sistema que normalmente se utili!a para concebir # documentar su dise/o. (s un artefacto compuesto que contiene todas las clases" subsistemas" paquetes" colaboraciones # las relaciones entre ellas. Bambin contiene las reali!aciones de los casos de uso. Modelo de datos6 Describe la representaci*n fsica # l*gica de los datos persistentes utili!ados por la aplicaci*n. e utili!ar siempre que se necesiten manejar datos persistentes. Csualmente describir los diferentes elementos componentes de la estructura de una base de datos relacional. Ma'a de navegaci#n6 (0presa la estructura de los elementos de la interfa! de usuario del sistema" junto a los caminos de navegaci*n principales. (0istir solamente uno de estos artefactos en el sistema # por lo general ser empleado para aplicaciones Keb. Prototi'o de la interfa7 de usuario6 (s un ejemplo de la interfa! de usuario que se constru#e para validar #?o e0plorar su dise/o. (l grado de formalidad # 'erramientas utili!adas para generarlo puede variar muc'o de pro#ecto en pro#ecto" pudiendo ir desde solo unas cuantas imgenes de pantallas 'asta un esqueleto de interfa! de usuario ejecutable producido en un ambiente de Desarrollo rpido de aplicaciones 47AD 3 7apid Application Development5 o un conjunto de pginas HB.6 interactivas. (n aplicaciones
,IL .odelos de proceso de software

Instituto Becnol*gico de .orelia

Keb pueden ser las imgenes de las diferentes pantallas creadas por el dise/ador grfico.

4.4.(.4.& Artefactos Internos del Proceso

Plan de gesti#n de requisitos6 Describe los artefactos de la disciplina" tipos de requisitos # sus respectivos atributos. (specifica la informaci*n que deber ser obtenida # los mecanismos de control que debern ser utili!ados para reportar" medir" # controlar los cambios a los requisitos del producto.

Plan de 'rue$as6 )ontiene la definici*n de los objetivos de las pruebas" los elementos que debern ser probados" los mtodos que debern utili!arse" los recursos necesarios # documentos a entregar. Csualmente se tiene uno de estos documentos con alcance global para todo el pro#ecto # uno por cada iteraci*n del ciclo de vida del producto.

4ui#n de 'rue$as6

on las instrucciones paso a paso que indican como

llevar a cabo una prueba. +ueden ser documentos con informaci*n te0tual que describa c*mo reali!ar la prueba manualmente o arc'ivos de instrucciones legibles por las mquinas que posibiliten la ejecuci*n automati!ada de la prueba.

Informe resumen de las 'rue$as6 Jrgani!a # muestra un anlisis resumido de los resultados de las pruebas que ser entregado a los miembros del equipo de calidad para su revisi*n # evaluaci*n. Adicionalmente puede contener un enunciado general de la calidad relativa # ofrecer recomendaciones para futuros esfuer!os de prueba.

Plan de gesti#n de configuraci#n6 Describe todas las actividades de Pesti*n de configuraci*n # cambios que sern reali!adas durante todo el ciclo de vida del pro#ecto. Brinda planificaciones detalladas de las actividades" responsabilidades asignadas" recursos necesarios que inclu#en personal" 'erramientas # equipamiento.

,IG .odelos de proceso de software

Solicitud de cam$io6 6os cambios a los artefactos del pro#ecto se proponen mediante olicitudes de cambio 4)'ange 7equests )75. (stos se utili!an para documentar # controlar defectos" solicitudes de mejoras o cualquier otra solicitud de cambios al pro#ecto. (l beneficio de utili!arlos es que proporcionan un registro de las decisiones #" debido a su proceso evaluativo" se asegura que los impactos de los cambios sean entendidos por todos los miembros del equipo del pro#ecto.

Plan de desarrollo de software6 (s un artefacto compuesto que recoge toda la informaci*n necesaria para llevar a cabo la direcci*n del pro#ecto. )ontiene otros planes no menos importantes que" al igual que ste son desarrollados desde la fase de inicio # mantenidos durante todo el ciclo de vida 4Aseguramiento de la calidad" Pesti*n de riesgos" .tricas" Aceptaci*n del producto # 7esoluci*n de problemas5.

Plan de la iteraci#n6 (s un plan ms refinado que contiene un conjunto secuencial de actividades" tareas # recursos asignados a una iteraci*n" por lo que e0istir un artefacto de este tipo por cada iteraci*n del ciclo de vida del producto. Inclu#e los objetivos de la iteraci*n" que son utili!ados como criterio de evaluaci*n # miden diferentes aspectos deseables a su final" como grado de terminaci*n de la funcionalidad planificada" niveles de calidad" rendimiento" etc.

)valuaci#n de la iteraci#n6

e reali!a al final de la iteraci*n # captura el

grado en que se cumpli* el criterio de evaluaci*n" las lecciones aprendidas # los cambios a reali!ar en la planificaci*n de las subsiguientes iteraciones en funci*n del nuevo conocimiento adquirido. (s un artefacto esencial del enfoque iterativo de desarrollo de software.

Proceso de desarrollo6 Bambin conocido como +roceso especfico del pro#ecto" es una configuraci*n del +roceso Cnificado de 7ational 47C+5 para ajustarse a las necesidades del pro#ecto. (s un artefacto compuesto que contiene3 el )aso de desarrollo" plantillas # normativas para el pro#ecto.

,IF .odelos de proceso de software

Instituto Becnol*gico de .orelia

4.4.(.4.( Artefactos entrega$les al cliente

Modelo de im'lementaci#n6 7epresenta la composici*n fsica de la implementaci*n" est constituido por subsistemas # elementos de implementaci*n 4directorios # fic'eros" inclu#endo los de c*digo fuente" datos # ejecutables5. Informe de entrega al cliente6 )ontendr una descripci*n detallada de la estructura de directorios del paquete entregado" instrucciones para la instalaci*n" errores conocidos # cambios reali!ados en la versi*n actual del sistema" subsistema o componente implementado. Adicionalmente incluir cualquier otra informaci*n que sea considerada relevante referida al modelo de implementaci*n o los artefactos contenidos en la entrega al cliente. ocumentaci#n de so'orte6 (n funci*n de las caractersticas del pro#ecto" se entregar tambin la documentaci*n tcnica del sistema" subsistema o componente de software implementado" que podr ser usada posteriormente para su mantenimiento o modificaci*n por parte de otro equipo de desarrollo. Adicionalmente sern entregados los manuales necesarios para el soporte al usuario final.

,=.odelos de proceso de software

Flu%os de /ra$a%o de 'roceso

Inicio

(laboraci*n

)onstrucci*n

Bransici*n

Modelo de negocio *equisitos Anlisis y ise!o

Im'lementaci#n Prue$as Im'lantaci#n

Flu%os de /ra$a%o de so'orte

4esti#n de "onfiguraci#n 4esti#n )ntorno

Iteraciones preliminares

Iter T,

Iter T<

Iter Tn

Iter TnU,

Iter TnU<

Iter Tm

Iter TmU,

Figura 4.8 (structura del +roceso Cnificado

Ouan +av*n .aestras" Cniversidad )omplutense de .adrid" 9(l proceso unificado: $(n lnea&" .adrid (spa/a $)onsulta3 Abril de <--=&" >'ttp3??www.fdi.ucm.es?profesor?jpavon?is<?-E+rocesoCnificado.pdfA

4.4.(.8 Inicio
u meta principal es lograr el consenso de todos los involucrados acerca de los objetivos del ciclo de vida del pro#ecto. (s mu# importante especialmente en pro#ectos nuevos en que e0isten riesgos significativos en el negocio o la implementaci*n de los requisitos" # deben ser solucionados para que el pro#ecto proceda. +ara los pro#ectos que se enfocan en mejorar sistemas e0istentes" esta fase es ms breve" pero a2n as centrada en asegurar que el pro#ecto vale la pena # se puede reali!ar.
,=, .odelos de proceso de software

Instituto Becnol*gico de .orelia

,$%etivos (stablecer el alcance # fronteras del software del pro#ecto" inclu#endo la visi*n operacional" criterio de aceptaci*n" qu se espera que est en el producto # qu no. Discriminar los casos de uso crticos del sistema" los escenarios primarios de operaci*n que dirigirn las principales decisiones de dise/o. .ostrar al menos una arquitectura candidata para alguno de los escenarios primarios. (stimar el costo global # planificaci*n para el pro#ecto completo 4estimaciones ms precisas se obtendrn en la fase siguiente5. (stimar los riesgos potenciales. +reparar el ambiente de soporte al pro#ecto

Actividades Qormular el alcance del pro#ecto. +lanificar # preparar el caso de negocio. inteti!ar una arquitectura candidata. +reparar el ambiente del pro#ecto3 evaluar el pro#ecto # la organi!aci*n" seleccionar las 'erramientas" decidir qu partes del proceso mejorar. 2ito (stablecer el mbito del producto" la identificaci*n de los principales riesgos # la viabilidad del pro#ecto.

4.4.(.9 )la$oraci#n

,=< .odelos de proceso de software

(l prop*sito de la etapa de (laboraci*n es crear la lnea base de la arquitectura del software para as disponer de unos cimientos s*lidos sobre los que se basar el grueso del esfuer!o de dise/o e implementaci*n durante la siguiente fase de )onstrucci*n. (n la definici*n de la lnea base de la arquitectura se inclu#en los requisitos ms significativos 4aqullos que tienen un ma#or impacto sobre la arquitectura del sistema5" # los componentes de ma#or riesgo para el sistema. +ara evaluar la estabilidad de la arquitectura se emplean prototipos evolutivos de la arquitectura. ,$%etivos Asegurar que la arquitectura" requisitos # planes son lo suficientemente estables # los riesgos 'an sido mitigados lo suficiente para poder determinar los costos # planificaci*n necesarios para completar el desarrollo. olucionar todos los riesgos significativos para la arquitectura del pro#ecto. (stablecer la lnea base de la arquitectura obtenida despus de tratar los escenarios ms significativos para la arquitectura" que por lo general muestra los ma#ores riesgos tcnicos del pro#ecto. +roducir un prototipo progresivo de componentes con calidad para la producci*n" as como tambin algunos prototipos desec'ables e0ploratorios donde se mitigan riesgos especficos" como por ejemplo3 oluciones de compromiso en el dise/o" reutili!aci*n de componentes" factibilidad del producto" o demostraciones a inversores" clientes # usuarios finales Demostrar que la arquitectura incluida en la lnea base respaldar los requisitos del sistema a un costo # tiempo ra!onables. (stablecer el ambiente de soporte para el pro#ecto. (sto inclu#e crear los planes de desarrollo" preparar las plantillas de los documentos" instrucciones" # 'erramientas Actividades
,=E .odelos de proceso de software

Instituto Becnol*gico de .orelia

2ito

Definir" validar # a/adir la arquitectura a la lnea base. 7efinar la ;isi*n basndose en informaci*n nueva obtenida durante la fase. )rear # a/adir a la lnea base planes de iteraci*n detallados para la fase de construcci*n. 7efinar los planes de desarrollo # ponerlos en prctica en el ambiente de desarrollo. 7efinar la arquitectura # seleccionar componentes.

Jbtener una lnea base de la arquitectura del sistema" capturar la ma#ora de los requisitos # reducir los riesgos principales as como permitir la escalabilidad del equipo del pro#ecto durante la fase de construcci*n.

4.4.(.: "onstrucci#n
(n esta fase se documentan los requisitos restantes # se completa el desarrollo del sistema basndose en la arquitectura que se 'a sido a/adida a la lnea base. 6a )onstrucci*n es un proceso de fabricaci*n donde se 'ace nfasis en la administraci*n de los recursos # el control de operaciones para optimi!ar costos" el tiempo dedicado" # la calidad del producto. (n este sentido la administraci*n e0perimenta una transici*n del desarrollo de propiedad intelectual durante las fases de Inicio # (laboraci*n" al desarrollo de productos instalables durante la )onstrucci*n # Bransici*n. ,$%etivos

,=% .odelos de proceso de software

.inimi!ar los costos de desarrollo optimi!ando los recursos # evitando cambios innecesarios que resulten en desec'ar o modificar trabajo #a reali!ado.

Jbtener una calidad apropiada tan rpido como sea posible. Jbtener versiones 2tiles 4alfa" beta" # otras entregas de prueba5 tan rpido como sea posible. )ompletar el anlisis" dise/o" desarrollo # prueba de toda la funcionalidad requerida. Desarrollar de forma iterativa e incremental un producto completo que est listo para su transici*n 'acia la comunidad de usuarios. (sto implica detallar los casos de uso restantes # otros requisitos as como completar el dise/o" implementaci*n # prueba del software.

Decidir si el software" sitio # usuarios estn listos para la instalaci*n de la aplicaci*n. Alcan!ar alg2n grado de paralelismo en el trabajo de los equipos. Hasta en los pro#ectos ms peque/os e0isten componentes que pueden ser desarrollados de forma independiente entre ellos" permitiendo un paralelismo natural entre los equipos. (ste paralelismo puede acelerar significativamente el desarrollo de actividades.

Actividades Administraci*n de recursos" control # optimi!aci*n del proceso. Desarrollo # prueba completa de los componentes utili!ando el criterio de evaluaci*n definido. (valuaci*n de las entregas del producto utili!ando los criterios de aceptaci*n de la ;isi*n. 2ito

,=I .odelos de proceso de software

Instituto Becnol*gico de .orelia

+odemos decir que se alcan!a el 'ito principal de la fase cuando 'emos conseguido desarrollar el sistema con calidad de producci*n" # puede entonces prepararse para la entrega al equipo de transici*n. (n esta fase" toda la funcionalidad 'a sido implementada" # completadas las pruebas para el estado alfa de la aplicaci*n.

4.4.(.; /ransici#n
(n esta fase la atenci*n se enfoca en asegurar que el software est disponible para los usuarios finales. +uede e0tenderse a varias iteraciones" e inclu#e las pruebas del producto como parte de su preparaci*n para ser entregado" # la reali!aci*n de ajustes menores en respuesta a la retroalimentaci*n recibida de los usuarios. (n este punto del ciclo de vida la retroalimentaci*n de los usuarios debe enfocarse fundamentalmente a ajustes especficos # de corto alcance al producto" junto a otros temas como configuraci*n" instalaci*n" # usabilidad. 7eferencias a otros ajustes estructurales ma#ores 'abrn sido solucionadas anteriormente en el ciclo de vida # sern documentadas para futuras generaciones del software. Al final de la fase de 9ransicin los objetivos del ciclo de vida se 'an cumplido" # el pro#ecto est listo para cerrarse. (n algunos casos el final de este ciclo coincide con el inicio de otro ciclo en el mismo pro#ecto" encaminndose a la siguiente generaci*n o versi*n del producto. +ara otros pro#ectos el final de esta fase puede coincidir con la entrega completa de los productos 4aplicaciones5 # subproductos 4documentaci*n5 a terceros que pudieran ser responsables de la operaci*n" mantenimientos" # mejoras al sistema entregado. (sta fase de transici*n puede variar de mu# sencilla a e0tremadamente compleja" dependiendo del tipo de producto. (sta etapa comien!a cuando la lnea base est lo suficientemente madura como para reali!ar una entrega al dominio de los usuarios finales. (sto por lo general requiere que se 'a#a completado un subconjunto usable del sistema con un nivel

,== .odelos de proceso de software

de calidad aceptable # documentaci*n de usuario de modo que la transici*n produ!ca resultados positivos para todas las partes. ,$%etivos 7eali!ar pruebas de estadio beta para validar el nuevo sistema con las e0pectativas de los usuarios. 7eali!ar pruebas de estadio beta # la operaci*n en paralelo al sistema anterior que se est reempla!ando. (ntrenamiento de usuarios # encargados del mantenimiento. alida a comerciales" distribuci*n # ventas. Ingeniera especfica de instalaci*n3 comerciali!aci*n # producci*n de los paquetes" etc. Actividades de correcci*n de errores" mejoras en el funcionamiento # rendimiento # usabilidad. (valuaci*n de la lnea base de la instalaci*n con la visi*n completa # criterios de la aceptaci*n del producto. 6ograr el consenso de los involucrados en que la lnea base est completa. 6ograr el consenso de los involucrados en que la lnea base es consistente con el criterio de evaluaci*n de la visi*n. Actividades (jecutar los planes de instalaci*n. )ompletar el material de soporte de los usuarios finales. +ruebas del producto en el sitio de desarrollo. +reparar la entrega de esta versi*n del producto. 7ecoger la retroalimentaci*n de los usuarios. Hacer ajustes finos al producto basndose en la retroalimentaci*n de los usuarios.
,=L .odelos de proceso de software

Instituto Becnol*gico de .orelia

2ito

Hacer disponible el producto para los usuarios finales.

Al finali!ar esta fase se decide si los objetivos se cumplieron # si debe comen!arse otro ciclo de desarrollo. (s el resultado de la revisi*n # aceptaci*n por parte del cliente de los productos # subproductos que le 'an sido entregados.

4.8 Proceso Software Personal.

(l +roceso +ersonal del oftware 4 PSP5 es un sistema estructurado de

descripciones" de medidas" # de los mtodos de proceso que pueden a#udar a ingenieros a mejorar su actividad personal. (l + + fue definido por Katts . Hump're# del oftware (ngineering Institute

4 (I5 en la )arnegie .ellon Cniversit#.

4.8.1 Princi'ios del Proceso de Software Personal $,I&

)ada ingeniero es diferenteN para ser ms eficiente" debe planificar su trabajo basndose en datos tomados de su propia tra#ectoria profesional. +ara mejorar autnticamente su trabajo" los ingenieros deben usar procesos personales bien definidos # cuantificados. +ara obtener productos de calidad" el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. 6os buenos productos no se obtienen por a!ar" sino como son secuencia de un esfuer!o positivo para 'acer un trabajo de calidad. )uanto antes se detecten # corrijan los defectos menos esfuer!o ser necesario. (s mas efectivo evitar los defectos que detectarlos # corregirlos. Brabajar bien es siempre la forma ms rpida # econ*mica de trabajar.

,=G .odelos de proceso de software

(l + + )ubre los siguientes aspectos como3 Definici*n de procesos .edida de la calidad .edida de la productividad.

(s un acercamiento general que se puede utili!ar en casi cualquier parte del proceso del software. (l costo personal de un + +" es el tiempo que se requiere para aprender # para usarlo" el costo emocional de tener una disciplina necesaria # el riesgo potencial a su ego. 6os beneficios del + +3 Habilidades # talentos obtenidos (l estmulo de una corriente casi ilimitada de ideas (l marco que proporciona para la mejora personal (l grado de control se gana sobre el trabajo 6a sensaci*n del orgullo # de la reali!aci*n Cna base mejorada para el trabajo en equipo efica! 6a seguridad para 'acer el trabajo la manera que usted sabe que usted debe.

,=F .odelos de proceso de software

Instituto Becnol*gico de .orelia

+ +E Desarrollo cclico + +<., Dise/o de plantillas

+ +< 7evisi*n de c*digo 7evisi*n de dise/o

+ +, (stimaci*n de tama/o 7eporte de pruebas

+ +,., +laneaci*n de Bareas +laneaci*n de 'orarios

+ ++roceso actual Biempo de registro 7egistro de fallas (stndar de fallas

+ +-., )odificaci*n estndar .edida del tama/o .ejora del proceso Figura 4.9 (voluci*n de + +

.iSe Prasso" Cniversit# of .ar#land" 9B'e +ersonal oftware +rocess: $(n lnea&" .ar#land (CA $)onsulta3 .a#o de <--=& >'ttp3??www.csee.umbc.edu?VmiSeg?cmsc=%I?seWpsp.pdfA

,L.odelos de proceso de software

4.8.& PSP< =nea .ase $,I&

(stablece una lnea de medida del progreso # para definir un fundamento para mejorar. (6 + +- provee una estructura mu# conveniente para 'acer tareas a peque/a escala" un marco de trabajo para medir las tareas # un fundamento de mejora del proceso 6as tareas inclu#en lo siguiente3 Definici*n del proceso actual 4+ +-5. Biempo de registro 4+ +-5. 7egistro de falla 4+ +-5. 7egistro de falla estndar 4+ +-5. )odificaci*n estndar 4+ +-.,5. .edida del tama/o 4+ +-.,5. .ejora del proceso 4+ +-.,5.

,L, .odelos de proceso de software

Instituto Becnol*gico de .orelia

7equerimientos +laneaci*n Dise/o

cripts

)*digo )ompilaci*n +ruebas +ost@ejecuci*n 7egistros 7esumen del plan

+roducto terminado Figura 4.: Qlujo del proceso

.iSe Prasso" Cniversit# of .ar#land" 9B'e +ersonal oftware +rocess: $(n lnea&" .ar#land (CA $)onsulta3 .a#o de <--=& >'ttp3??www.csee.umbc.edu?VmiSeg?cmsc=%I?seWpsp.pdfA

4.8.&.1 PSP< Proceso Actual $,I&

e debe identificar el proceso actual del desarrollo de software. (n caso de que no se tenga un proceso regular se puede utili!ar el siguiente3 Dise/o" )odificaci*n" )ompilaci*n" +rueba

(l proceso inclu#e las siguientes tareas3 +laneaci*n 4+roduce un +lan de trabajo5. Desarrollo 4Desarrollo del software actual5. +ost ejecuci*n 4)omparaci*n del funcionamiento actual con el plan de trabajo5.

4.8.&.& PSP< /iem'o de *egistro $,I&

,L< .odelos de proceso de software

(l tiempo de registro se usa para medir el tiempo que se lleva en cada parte del proceso + +. (l objetivo es determinar donde se invierte ms tiempo. er bastante minucioso con los datos 4probablemente 'asta minutos5

El tiempo de registro incluye: Qec'a de entrada Hora de Inicio Hora de fin (stimaci*n de tiempo de interrupci*n para esta entrada Biempo delta 4el tiempo en el que se trabaja para esta entrada5 Qase en la que se esta trabajando )omentarios pertinentes

4.8.&.( PSP< *egistro de fallas $,I&

(l registro de una falla se usa para tener los defectos encontrados # corregidos. (l objetivo de esto es determinar donde se pierde muc'o tiempo # ser lo mas minucioso posible con los datos. (l registro de fallas debe incluir lo siguiente3 Qec'a de la falla encontrada Dumero de falla Bipo de falla 4Documentaci*n" sinta0is" asignaci*n" interfase" etc.X5 Qase donde se inicio la falla Qase donde la falla se elimino Biempo que se llevo para reparar la falla Descripci*n del porque de la falla

,LE .odelos de proceso de software

Instituto Becnol*gico de .orelia

4.8.&.4 PSP< )stndar de fallas $,I&

(stos pueden se algunas de las fallas que se registran # que se pueden tomar como un estndar3
>o ,<E%I=LGF,->om$re o descri'ci#n )omentario de documentaci*n" mensajes Deletreo de sinta0is" puntuaci*n" formato )onstrucci*n" .anejo de cambio de paquete" librera" control de versi*n Declaraci*n de asignaci*n" duplicado de nombres" alcance" limitaciones +rocedimiento de la Interfa!" llamadas" referencias" I?J" formato de usuario )'equeo de mensajes de error (structura de datos" contenido Qunci*n de cone0i*n" enlace" recursividad" )onfiguraci*n de sistema" sincroni!aci*n" memoria Dise/o del entorno" compilaci*n" prueba" otro sistema de soporte de problemas /a$la 4.1 (standa de fallas

El resumen del plan guarda # estima los datos del pro#ecto actual" el cual debera de contener lo siguiente3 (stimaci*n $)onsulta3 original de Jf )ode:" 6neas de c*digo5 que .a#o de6J)496ines <--=& >'ttp3??www.csee.umbc.edu?VmiSeg?cmsc=%I?seWpsp.pdfA se estima se van a desarrollar. 6neas de c*digo que se llevan en desarrollo 'asta ese momento. (l tiempo estimado que es requerido para cada fase. (l tiempo que se requiere para cada fase. (l numero total # el porcentaje de fallos que se 'an provocado en cada fase. (l numero total # el porcentaje que se 'an eliminado en cada fase.
.iSe Prasso" Cniversit# of .ar#land" 9B'e +ersonal oftware +rocess: $(n lnea&" .ar#land (CA

4.8.&.8 PSP<.1 "odificaci#n estndar $,I&

Desarrollo de la codificaci*n estndar para lo siguiente3
,L% .odelos de proceso de software

)abecera

Cso? reuso Identificadores )omentarios ecci*n mas importante (spacios en blanco Identidad )apitali!aci*n

Dentro de este estndar se pueden incluir definiciones # ejemplos.

4.8.&.9 PSP<.1 Medida del tama!o $,I&

Durante la planeaci*n del proceso de software" inclu#e la estimaci*n del tama/o del trabajo as como las lneas de c*digo. (l desarrollo del estndar tiene peque/os problemas con lo siguiente3 .odificaci*n o eliminaci*n de lneas. )omentarios o lneas en blanco. 6neas con m2ltiples declaraciones. Declaraciones nulas o vacas. Incluir arc'ivos 4agregados una ve! o varias veces5. Qunciones de lnea o e0pansi*n de marcos. Declaraciones (tiquetas mbolos como llaves 9Y Z: " begin? end" else" caseX.

4.8.&.: PSP<.1 Me%ora del 'roceso $,I&

,LI .odelos de proceso de software

Instituto Becnol*gico de .orelia

6a mejora del proceso provee un registro de fallas problemas e ideas de mejora. +uede contener lo siguiente3 Descripci*n de la falla encontrada dentro del pro#ecto Dumero del problema Descripci*n # las dificultades Descripci*n del impacto que tiene el producto o el proceso con la falla o problema. Descripci*n de las sugerencias para mejorar el proceso. Dumeraci*n de cada una de las sugerencias. Identificaci*n de los elementos del proceso que son afectados. )uando ser apropiado" relacionar las sugerencias de mejor para el problema. Dar prioridades a las sugerencias # e0plicar porque son importantes. Agregar comentarios sobre el pro#ecto. 6ecci*n aprendida )ondiciones que es necesario recordar para determinar el porque funciona bien el proceso o el porqu es deficiente.

4.8.&.; PSP<

ocumentaci#n del 'roceso $,I&

(n esta parte se debe tener documentada la planeaci*n el desarrollo # el post ejecuci*n del proceso. (n seguida se describe que es lo que debe contener cada uno de ellos. +laneaci*n3 +roducir u obtener los requerimientos de las declaraciones. (stimaci*n de nuevos totales como los cambios en las lneas de c*digo requeridos en + +-.,. (stimaci*n del tiempo requerido para el desarrollo.

,L= .odelos de proceso de software

7egistrar el inicio del pro#ecto en el resumen del plan del pro#ecto. 7egistrar la fec'a del pro#ecto.

Desarrollo3 Dise/o" implementaci*n" compilaci*n" prueba.4+ +-.,5 7egistrar el tiempo.

+ost@ejecuci*n3 )ompletar el resumen del plan del pro#ecto" con el tiempo actual" fallas" tama/o de los datos. Berminar el mejoramiento del proceso.

4.8.( PSP1 Planeaci#n Personal del Proceso $,I&

(l + +, estima el tama/o del software" 'ace una prueba de reporte del + +. Adicionalmente contribu#e a + +, estimar los recursos # el 'orario. (l + +, intenta establecer el proceso de forma ordenada # repetida para desarrollar el software usando el tama/o" recursos # 'orarios estimados. (l proceso de valoraci*n llega a ser progresivamente ms e0acto conforme los datos se recopilan de varios pro#ectos. 6as tareas que se inclu#en del + +- # + +-., agregan lo siguiente3 (stimaci*n de tama/o. 7eporte de prueba. +laneaci*n de tareas +laneaci*n del 'orario

4.8.(.1 PSP1 )stimaci#n de tama!o $,I&

,LL .odelos de proceso de software

Instituto Becnol*gico de .orelia

6as siguientes disciplinas se usan para estimar las lneas de c*digo. desarrollados para poder establecer estimaciones iniciales. .todo +7JB( 4+ro0#@Based (stimating5" Descrito en la disciplina para la Ingeniera de oftware. +untos de Qunci*n3 Ali Arifoglu. .etodologa de software para la estimaci*n de costos A). igsoft oftware (ngineering. )J)J.J .odel 4)onstructive )ost .odel5 es el modelo constructivo de costos. (ste modelo es para la estimaci*n de lneas de c*digo.

e debe

tener el tama/o de los datos sobre un n2mero de pro#ectos previamente

4.8.(.& PSP1 *e'orte de 'rue$as $,I&

(l reporte de pruebas se usa para mantener un registro de pruebas de ejecuci*n # resultados obtenidos. (stos pueden ser tan detallados como se desee" con esto se puede 'acer la misma prueba # obtener los mismos resultados. (l reporte inclu#e lo siguiente3 Dombre # numero de prueba Jbjetivo de la prueba Descripci*n de la prueba )ondiciones de tiempo o configuraci*n especial 7esultados esperados 7esultado actual

4.8.(.( PSP1.1 Planeaci#n de /areas $,I&

,LG .odelos de proceso de software

6a planeaci*n de las tareas implica estimar el tiempo de desarrollo # de los datos de la terminaci*n para cada tarea del pro#ecto. (ste tambin proporciona una base seg2n el 'orario que se sigue. (l plan debe contener lo siguiente3 Dombre # n2mero de la tarea. +laneaci*n de 'ora de acuerdo a la tarea por semana" # para el pro#ecto. Biempo actual por tarea por semana" # ara el pro#ecto.

4.8.(.4 PSP1.1 Planeaci#n de 3orarios $,I&

(l 'orario se usa para recordar el 'orario actual # empleado en el calendario por periodo. e usa para relacionar tareas previstas con el 'orario seg2n el calendario. 6as siguientes semanas se usan para peque/os pro#ectos" # puede que sea mejor 'acer ma#or esfuer!o por da. (l 'orario puede contener lo siguiente3 Dumero de cada semana" tpicamente empe!ando en ,. Qec'ad de calendario para cada semana. +laneaci*n prevista para el trabajo en el pro#ecto por semana. Horas previstas acumuladas. Horas reales que se invierten en el pro#ecto por semana. Horas reales acumuladas.

4.8.(.8 PSP1
+laneaci*n

ocumentaci#n del 'roceso $,I&

+roduce u obtiene la declaraci*n de los requisitos. (stimaci*n del tama/o del software" tiempo del desarrollo requerido 4+ +,5. +lan completo de tareas.
,LF

.odelos de proceso de software

Instituto Becnol*gico de .orelia

Horario completo del plan 4+ +,.,5. Incorporaci*n de los datos iniciales en el resumen del plan de pro#ecto. 7egistro de tiempo # datos iniciales.

Desarrollo Dise/o" Implementaci*n" compilaci*n" prueba. 7ecolectar los datos del reporte de prueba 4+ +,5. 7ecolectar los registros de los datos.

+ost@ejecuci*n 7esumen del plan del pro#ecto completo con el tiempo real" fallas" tama/o de los datos. )ompletar la mejora del proceso.

4.8.4 PSP& "alidad 'ersonal $,I&

(l proceso + +< introduce revisiones de dise/o" c*digo a la medida # medici*n de la calidad. (ste tipo de revisiones mejoran la calidad del software ms que otro cambio personal que se 'aga en el proceso del software. Introduce tambin criterios # verificaci*n de dise/o completos. e inclu#en tareas de + +, # de + +,., ms las siguientes3 7evisi*n de c*digo 4+ +<5. 7evisi*n de dise/o 4+ +<5. Dise/o de plantillas 4+ +<.,5.

4.8.4.1 PSP& *evisi#n de c#digo $,I&

,G.odelos de proceso de software

(l objetivo principal de la revisi*n de calidad es mejorar la calidad del programa e0aminando parte o todo el sistema # su documentaci*n asociada. 6as revisiones tcnicas o inspecciones de programa son similares e0cepto porque su objetivo principal es identificar las fallas o defectos tales como anomalas en el c*digo" errores l*gicos" incumplimiento de estndares. 6as revisiones tienen un n2mero de pruebas dinmicas del e0cedente de las ventajas. Do requieren que el programa se este ejecutando on una medida directa de defectos o cualidades de la calidad e consideran mas efectivos

6a revisi*n de c*digo consiste en la comprobaci*n de la iniciali!aci*n de la variable # sus parmetros. (n el inicio del programa" inicio de los ciclos" formato de la llamada de la funci*n 6lamada de funci*n # formato de la llamada +unteros parmetros" # el uso de [\]

)omprobaci*n # deletreo de nombres (s consistente. (sta dentro del alcance de la declaraci*n. Bodas las estructuras # clases usan [.] 1 [@A] de forma correcta.

)omprobaci*n de secuencias Identificaci*n de terminaci*n por puntuaciones # DC66.

)omprobaci*n de arc'ivos Declaraci*n correcta. Abrir # cerrar correctamente.

,G, .odelos de proceso de software

Instituto Becnol*gico de .orelia

)omprobaci*n de punteros Iniciar en DC66. Borrar solamente despus que se crea o es nuevo Borrar siempre despus de su uso

)omprobaci*n del formato de salida Alineaci*n # espaciado correcto

;erificaci*n de operadores l*gicos Cso apropiado de operadores l*gicos 4^" >" A"Xetc.5. Cso apropiado de parntesis para operaciones l*gicas.

Asegurar que las llaves estn alineadas. ;erificar cada lnea de c*digo por instrucciones" sinta0is # puntuaci*n apropiada. Asegurar el c*digo conforme al estndar de codificaci*n.

4.8.4.& PSP& *evisi#n de

ise!o $,I&

(n la revisi*n de dise/o se deben asegurar los requisitos" especificaciones # niveles altos de dise/o sean cubiertos totalmente. (n esta parte se producen todas las salidas especificadas" se crean todas las entradas necesarias # todos los requerimientos incluidos son indicados en esta parte. ;erificaci*n de la l*gica del programa Apilado" 6istas" 7ecursividad Bodos los ciclos son propiamente iniciali!ados" tanto el terminaci*n del mismo. ;erificaci*n de casos especiales
,G< .odelos de proceso de software

incremento #

Asegurar las operaciones con los valores de empt#" full" min" ma0" negative" !ero. +roteger contra fuera de limites" desbordamiento 4overflow5" desbordamiento de menor capacidad 4underflow5. Asegurar que las condiciones imposibles son imposibles. .anejar todas las condiciones incorrectas de entrada.

;erificaci*n de uso de funciones Bodas las funciones # objetos se deben de usar # entender propiamente. Bodas las abstracciones e0ternas son definidas.

;erificaci*n de nombres Bodos los nombres # tipos son claramente definidos. (l alcance de todas las variables son evidentes o bien definidos. Bodos los nombres # objetos se usan dentro de su alcance definido.

7evisi*n del dise/o de acuerdo al estndar aplicable al dise/o.

4.8.4.( PSP&.1

ise!o de 'lantillas $,I&

Ha# cuatro plantillas de dise/o que proveen de forma ordenada un marco de trabajo # el formato de registro para los dise/os. 6os formatos no indican la forma en como 'acer el dise/o" pero pueden a#udar a que se registren de manera apropiada. 6as plantillas inclu#en lo siguiente3 (scenario de operaci*n de la plantilla. (specificaci*n funcional de la plantilla. (specificaci*n de estado de la plantilla. (specificaci*n l*gica de la plantilla.
,GE .odelos de proceso de software

Instituto Becnol*gico de .orelia

Escenario de operacin de la plantilla (sta plantilla tiene las descripciones de los panoramas probables que se seguirn al usar el programa. 6as plantillas deben incluir lo siguiente3 Dumero de escenarios para los escenarios # los pasos para el escenario. Identificaci*n del objetivo de los usuarios. Quente de acci*n as como los usuarios" programas o sistemas. Descripci*n de la acci*n" que lugar toma as como el mensaje de error de una entrada incorrecta. 6ista de comentarios significativos.

Especificacin funcional de la plantilla (sta plantilla se puede usar para describir funciones # procedimientos de dise/o de funciones o de objetos de dise/o orientado a objetos. 6as plantillas deben incluir3 Dombre de la funci*n ? clase o clases de donde 'ereda. )ualquier parmetro o atributo cu#os valores son e0ternos visibles o cualquier comportamiento del objeto. Documentaci*n de los mtodos para cada objeto" inclu#endo el prototipo" variables requeridas" tipos # la operaci*n reali!ada. Especificacin de estado de la plantilla (sta plantilla se usa para registrar el comportamiento del programa" subprograma o clase en un sistema orientado a objetos.

,G% .odelos de proceso de software

6a plantilla inclu#e lo siguiente3 Dombre del estado. Descripci*n de estado. Atributos o variables que caracteri!an el estado. +ara cada estado. o 6ista de todos los estados siguientes posibles. o 6ista de condiciones para cada estado siguiente. o Dar ejemplos de la condici*n de transici*n. Especificacin lgica de la plantilla (sta plantilla mantiene la l*gica del pseudo c*digo para cada funci*n o unidad del programa. 6a plantilla debe contener lo siguiente3 (numerar todos los 9inclu#es: nuevos o inusuales requeridos por la funci*n. (numerar todos los tipos inusuales o especiales. (ntregar el prototipo de la funci*n o la declaraci*n. Documentaci*n au0iliar de informaci*n requerida para entender la funci*n. Asignar un n2mero o etiqueta para cada declaraci*n l*gica significativa. Documentar la l*gica del programa o Cso de pseudoc*digo. o Cso de una lnea separada para cada funci*n significativa. o Cso de lenguaje com2n o matemtico para ma#or claridad. o Incluir comentarios donde sea necesario.

,GI .odelos de proceso de software

Instituto Becnol*gico de .orelia

4.8.4.4 PSP&
+laneaci*n

ocumentaci#n del Proceso $,I&

+roducir u obtener la declaraci*n de los requisitos. (stimaci*n del tama/o del software" tiempo de desarrollo requerido. (stimaci*n de tiempo requerido en el desarrollo. )ompletar el plan de tareas. )ompletar el 'orario. Incorporaci*n de los datos iniciales en el resumen del plan de pro#ecto. 7egistrar los datos iniciales en el registro de tiempo

Desarrollo Dise/ar" implementar" compilar # probar. Agregar la revisi*n del dise/o # revisi*n de c*digo 4+ +<5. Csar las plantillas de dise/o donde sea apropiado. Bomar los datos del informe de prueba. Bomar los datos del informe de registro de tiempo.

+ost@ejecuci*n )ompletar el resumen del plan del pro#ecto con el tiempo real" falla # tama/o de los datos.

4.8.8 PSP( Proceso cclico $,I&

(l proceso cclico combina m2ltiples procesos de + +<., para soportar el desarrollo de software a gran escala. (l objetivo principal es ampliar el proceso de software personal 'acia pro#ectos industriales # para cubrir el trabajo de pro#ecto de equipo.

,G= .odelos de proceso de software

(sta estrategia se centra en el desarrollo del producto" incrementos convenientes para el desarrollo cclico. 6as tareas inclu#en todo lo de + +< # + +<., # lo siguiente3 Desarrollo cclico4+ +E5

4.8.8.1 PSP(

esarrollo "clico $,I&

)uando se usa + +E" se debe de tener un plan para implementar grandes programas en m*dulos incrementales ms o menos de ,-- lneas de c*digo 4u otro tama/o apropiado5. A lo largo del resumen del pro#ecto + +E utili!ara el resumen del ciclo para seguir los datos. Bama/o del programa Biempo que se lleva en el desarrollo de cada fase Qallas eliminadas

4.8.8.& PSP(
+laneaci*n

ocumentaci#n del Proceso $,I&

Declaraci*n de los requerimientos producidos # obtenidos (stimaci*n del tama/o del software" tiempo de desarrollo requerido )ompletar el plan de tareas. )ompletar el 'orario de trabajo Incorporaci*n de los datos iniciales en el resumen del plan de pro#ecto. 7egistrar los datos iniciales en el registro de tiempo

Desarrollo
,GL .odelos de proceso de software

Instituto Becnol*gico de .orelia

Dise/ar" implementar" compilar # probar. Agregar la revisi*n del dise/o # revisi*n de c*digo Csar las plantillas de dise/o donde sea apropiado. Csar el desarrollo cclico" # seguir los res2menes del ciclo. Bomar los datos del informe de prueba. Bomar los datos del informe de registro de tiempo.

(specificaciones
+laneaci*n # 7equerimientos

Diveles Altos de dise/o # 7evisi*n de Dise/o

(specificaci*n del ciclo Desarrollo ;aloraci*n del nuevo ciclo

Desarrollo )clico

+ost @ (jecuci*n +roducto Berminado +ro#ecto # Datos de proceso Figura 4.; +roceso cclico del desarrollo
.iSe Prasso" Cniversit# of .ar#land" 9B'e +ersonal oftware +rocess: $(n lnea&" .ar#land (CA $)onsulta3 .a#o de <--=& >'ttp3??www.csee.umbc.edu?VmiSeg?cmsc=%I?seWpsp.pdfA

+ost@ejecuci*n )ompletar el resumen del plan del pro#ecto con el tiempo real" falla # tama/o de los datos /signaciones 6os principios de estas asignaciones son los siguientes3

,GG .odelos de proceso de software

Atenci*n especial a las tareas de + +. (l objetivo principal de estas asignaciones no es completarlas correctamente sino que estas tareas usen completa # correctamente los elementos apropiados del + +.

obre todo" el trabajo debe ser correcto. (s mejor estar atrasado que este incorrecto. i se necesita mas tiempo es necesario pedirlo. Bodas las asignaciones son individuales. 6a asistencia tcnica se obtiene del instructor o de otro grupo de miembros que aclaran los requerimientos o tareas de + +. e debe de registrar cuando se recibe asistencia.

;inculacin de listas e debe escribir un programa para calcular la desviaci*n estndar de una serie de n n2meros usando lista encadenada. (s el promedio de los n2meros. 6a formula de la desviaci*n estndar es3 ` 40, ... 0n5
a40, @ 0avg5<

$ontando las 6neas de $digo Al escribir el programa se deben de contar las lneas de c*digo" omitiendo comentarios # lneas en blanco. Asegurarse de que las declaraciones se 'agan en una sola lnea" o se cuenten varias veces. +or ejemplo" las siguientes lneas se cuentan de manera m2ltiple #a que contienen dos lneas de c*digo If 40^^-5 f45N If 40^^-5 f45N _^,-N #^0 U IN

(l total de 6neas de c*digo del programa debe contar los totales para cada unidad logia4es decir para cada funci*n5. Bambin el n2mero de las declaraciones que no son ejecutables deben de contadas.
,GF .odelos de proceso de software

Instituto Becnol*gico de .orelia

/lmacenamiento y recuperacin de archivos (scribir un programa para almacenar" recuperar # modificar serie de n n2meros reales de un arc'ivo. De entrada el programa debe aceptar enteros o n2meros reales # guardar como n2meros reales. 6as funciones que debe proveer el usuario son las siguientes3 (l usuario asigna el nombre del arc'ivo. (l usuario selecciona la forma de usar el arc'ivo" lectura" escritura" modificar. 6ectura" el programa proporciona una numeraci*n por lnea dentro del arc'ivo. (scritura" el usuario establece el n2mero de registros. .odificaci*n o (l programa proporciona el n2mero # el usuario tiene la opci*n de aceptar" reempla!ar o eliminar el n2mero. o (l usuario puede dar orden al programa de aceptar el resto de la numeraci*n al arc'ivo. o (l usuario puede guardar las modificaciones con un nuevo nombre dejando el original intacto. /signacin Est.ndar Desarrollar los siguientes estndares para el + + )uenta estndar de las lneas de c*digo +roducir una especificaci*n estndar de c*mo contar las lneas de c*digo. e puede usar en conjunto con la asignaci*n.

)odificaci*n estndar +roducir una codificaci*n estndar que se usara para nuestro + +

,F.odelos de proceso de software

e puede usar para evaluar cualquier asignaci*n que se desarrolle

7evisi*n estndar +roducir un estndar que sea usado para el dise/o # revisi*n de c*digo

+roceso de Ingeniera de oftware +roducir un estndar que documente el proceso de la Ingeniera de oftware" donde se usa # demostrar donde encajan las tareas de + + /n.lisis del reporte de fallas Agregar los siguientes comentarios al resumen de comentarios basados en las fallas encontradas durante el desarrollo. (l total de fallas encontradas 6as nuevas # modificadas lneas de c*digo 6as fallas por b6J)4bilo 6ines Jf )ode5

cue debe dar la tabla3 (l listado debe dar el promedio de reparaci*n Qallas encontradas durante la compilaci*n Qallas encontradas durante la prueba Qallas introducidas en el dise/o # la codificaci*n Qallas introducidas en el c*digo Dumero de fallas encontradas en la compilaci*n Dumero de fallas encontradas al probarlo Dumero de fallas encontradas por b6J) en la pruebas. Dumero de fallas encontradas en la compilaci*n por b6J)

,F, .odelos de proceso de software

Instituto Becnol*gico de .orelia

.I.=I,4*AF?A
@1A @&A ommerville" Ian 4<--I5" Ingeniera de software" (d. Addison Kesle# LM (dicion. +ressman 7oger . Ingeniera del software" (d. .c Praw Hill" IM edici*n

*)F)*)>"IAS B).
@(A Delson .edinilla .artne!" Qacultad de Informtica" Cniversidad +olitcnica de .adrid" 9Anlisis # selecci*n de estrategias de desarrollo de software: $(n lnea&" .adrid (spa/a $)onsulta3 .a#o de <--=&" >'ttp3??is.ls.fi.upm.es?udis?docencia?pro#ecto?docs? estrategias.pdfA @4A )arolina 8ibert" 9)iclos de vida de Ingeniera de ;ene!uela @8A $)onsulta3 Abril de .odelo;.docA Besis doctorales en 8ar!a" 9Ingeniera de oftware: $(n lnea&" (spa/a $)onsulta3 .a#o de @9A @:A @;A <--=&" >'ttp3??www.td0.cesca.es?B( I WC+)?A;AI6AB6(?BD_@-L,=,-<@ ,-<<,-??-I)apitulo-I.pdfA .undo PeeS" 9)iclos de vida del software: $(n lnea&" $)onsulta3 .a#o de <--=&" >'ttp3??mundogeeS.net?arc'ivos?<--%?-I?<-A KiSipedia Qoundation Inc" (CA Desarrollo en )ascada $(n lnea&" t. +etersburg $)onsulta3 .a#o de <--=&" >'ttp3??es.wiSipedia.org?wiSi?.odeloWenWcascadaA Instituto Becnol*gico de la pa!" 9Anlisis # dise/o de sistemas .odelo de (spiral: $(n lnea&" .0ico $)onsulta3 .a#o de <--=&" >'ttp3??www.itlp.edu.m0?publica?tutoriales? analisis?inde0.'tmA @CA @1<A )op#rig't D +rogramaci*n en )astellano" $(n lnea&" (spa/a $)onsulta3 .a#o de <--=&" >'ttp3??www.programacion.com?blogs?%=WaprendiendostrutsA 8avala 7. <---. Dise/o de un istema de Informaci*n Peogrfica sobre Internet. Besis de .aestra en )iencias de la )omputaci*n. Cniversidad Aut*noma .etropolitana@ A!capot!alco." 96a Ingeniera del @11A oftware: $(n lnea&" $)onsulta3 Abril de <--=&" .0ico" D.Q. >'ttp3??www.angelfire.com?scifi?j!avalar?apuntes?Ing oftware.'tmlTfig<A Ouan +av*n .aestras" Cniversidad )omplutense de .adrid" 9(l proceso unificado: $(n lnea&" .adrid (spa/a $)onsulta3 Abril de <--=&" >'ttp3??www.fdi.ucm.es?profesor? jpavon?is<?-E+rocesoCnificado.pdfA @1&A )arlos 7e#noso" Cniversidad de Buenos Aires" Arquitectura de msdn?arquitectura?roadmapWarq?'eterodo0.aspA oftware $(n lnea& Buenos Aires Argentina $)onsulta3 .a#o de <--=&" >'ttp3??www.microsoft.com?spanis'? oftware: $(n lnea&" )aracas <--=&">carolina.terna.net?ingsw<?Datos?)ascada@

,F< .odelos de proceso de software

@1(A

Prupo de Investigaci*n b#bele" Cniversidad 7e# Ouan )arlos" 9Qases del proceso unificado: $(n linea&" .adrid (spa/a $)onsulta3 Abril de <--=&" >'ttp3??S#bele.escet.urjc.es?Documentos?I I?QasesR<-delR<-+roceso R<-Cnificado.pdfA

@14A @18A

KiSipedia Qoundation Inc" (CA 9+roceso Cnificado de 7ational: $(n lnea&" +etersburg $)onsulta3 Abril de <--=&"'ttp3??es.wiSipedia.org?wiSi?7C+ .iSe Prasso" Cniversit# of .ar#land" 9B'e +ersonal cmsc=%I?seWpsp.pdfA

t.

oftware +rocess: $(n lnea&"

.ar#land (CA $)onsulta3 .a#o de <--=& >'ttp3??www.csee.umbc.edu?VmiSeg? @19A Pustavo Adolfo 7amre! Pon!le!" Cniversidad del )aucan +opa#n" 9+roceso Cnificado para desarrollo de @1:A oftware:" )olombia $)onsulta3 Ounio de <--=&" oftware: $(n lnea&" Ounio de <--=& >'ttp3??atenea.ucauca.edu.co?Vgramire!?arc'ivos?Anotaciones7C+.pdfA A.C. . PustavoBorossi" 9(l +roceso Cnificado de Desarrollo de +rovincia @1;A de )'aco 7epublica de Argentina $)onsulta3

>'ttp3??www.c'aco.gov.ar?CBD?disenodesistemas?apuntes?oo?Apunte7C+.pdfA Ivar Oacobson" 9Appl#ing C.6 in B'e Cnified +rocess: $(n linea&" $)onsulta3(nero de <--=&" >'ttp3??www.jecSle.de?files?uniproc.pdfA

,FE .odelos de proceso de software