Manual de modelos de

desarrollo de software

Universidad Tecnolgica del Centro de Veracruz

Contenido
Conceptos........................................................................................................... 3
Mtodo............................................................................................................. 3
Ciclo de vida.................................................................................................... 3
Modelo............................................................................................................. 3
Modelo Cascada.................................................................................................. 4
Fases................................................................................................................ 4
Ingeniera y Anlisis del Sistema..................................................................4
Anlisis de los requisitos del software..........................................................4
Diseo........................................................................................................... 5
Codificacin.................................................................................................. 5
Prueba.......................................................................................................... 5
Mantenimiento.............................................................................................. 5
Modelo Espiral..................................................................................................... 7
Determinar o fijar los objetivos........................................................................7
Anlisis del riesgo............................................................................................ 7
Desarrollar, verificar y validar..........................................................................7
Planificar.......................................................................................................... 7
Metodologa Extreme Programing (XP)...............................................................9
Fases................................................................................................................ 9
Exploracin................................................................................................... 9
Planificacin de la entrega............................................................................9
Iteraciones.................................................................................................. 10
Produccin.................................................................................................. 10
Mantenimiento............................................................................................ 11
Muerte del proyecto.................................................................................... 11
Cuatro prcticas esenciales de XP.................................................................12
Liberacin limitada..................................................................................... 12
Semana de trabajo de 40 horas..................................................................12
Cliente en el sitio........................................................................................ 12
Programacin en parejas............................................................................ 13
Modelo MOPROSOFT......................................................................................... 14

20

Caractersticas............................................................................................... 14

Beneficios...................................................................................................... 14
Moprosoft se estructura en 3 categoras:.......................................................15
Categora de Alta Direccin (DIR)...............................................................15
Categora de Gerencia(GER).......................................................................15
Categora de Operacin (OPE)....................................................................15
Direccin........................................................................................................ 16
Gestin de Negocios................................................................................... 16
Gestin.......................................................................................................... 16
Gestin de Proyectos:................................................................................. 16
Gestin de Procesos:.................................................................................. 16
Gestin de Recursos:.................................................................................. 16
Operacin...................................................................................................... 16
Administracin de Proyectos Especficos....................................................16
Desarrollo y Mantenimiento de Software:...................................................16
Entregables en fases y sus caractersticas:...................................................16
FASE ESPECIFICACIN DE REQUERIMIENTOS..............................................16
Metodologa RUP............................................................................................... 19
Dirigido por casos de uso............................................................................... 19
Centrado en la arquitectura...........................................................................19
Es iterativo e incremental.............................................................................. 19
Beneficios de un proceso iterativo controlado:...........................................20
Vida del proceso unificado............................................................................. 20
Los objetivos que se persiguen en cada fase son los siguientes:...............20
Bibliografa........................................................................................................ 22

Conceptos

20

Mtodo
Es un conjunto de herramientas, tcnicas y procesos que brindan soporte y
facilitan el logro u obtencin de una meta, que hacer, a lo largo de todo el ciclo de

vida del software, para construir un producto bueno, de calidad, dentro del
presupuesto y a tiempo.
Ciclo de vida
Es un enfoque por fases para el anlisis y el diseo cuya premisa principal
consiste en que los sistemas se desarrollan mejor utilizando un ciclo especfico de
actividades del analista y el usuario.
La mayora considera 7 fases las que conforman un ciclo de vida

Modelo
Un modelo es una referencia al arquetipo o punto de referencia para su imitacin o
reproduccin. En este sentido, un modelo es un ejemplar que se debe seguir por
su perfeccin. Un modelo tambin es el esquema terico de un sistema o de una
realidad compleja.

Modelo Cascada

20

Este es el ms bsico de todos los modelos y ha servido como bloque de

construccin para los dems paradigmas de ciclo de vida. Est basado en el ciclo
convencional de una ingeniera y su visin es muy simple: el desarrollo de

software se debe realizar siguiendo una secuencia de fases. Cada etapa tiene un
conjunto de metas bien definidas y las actividades dentro de cada una contribuyen
a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de
la misma.

Fases
Ingeniera y Anlisis del Sistema

Debido a que el software es siempre parte de un sistema mayor, el trabajo

comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algn subconjunto de estos requisitos al software.
Entregables: entrevistas, encuestas, cuestionarios, investigacin inicial.
Anlisis de los requisitos del software

El proceso de recopilacin de los requisitos se centra e intensifica especialmente

en el software. El ingeniero de software debe comprender el mbito de la
informacin del software, as como la funcin, el rendimiento y las interfaces
requeridas.

20

Entregables: estudio de viabilidad. Se revisa y observa si el proyecto es viable si

lo es se continua adelante.

Diseo

El diseo del software se enfoca en cuatro atributos distintos del programa; la

estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una
representacin del software con la calidad requerida antes de que comience la
codificacin.
Entregables: prototipos, interfaces de usuario y pruebas.
Codificacin

El diseo debe traducirse en una forma legible para la mquina. Si el diseo se

realiza de una manera detallada, la codificacin puede realizarse mecnicamente.
Entregables: cdigo fuente.
Prueba

Una vez que se ha generado el cdigo comienza la prueba del programa. La

prueba se centra en la lgica interna del software y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.
Entregables: reporte y nmero de la prueba a ejecutar
Mantenimiento

El software sufrir cambios despus de que se entrega al cliente. Los cambios

ocurrirn debidos a que se haya encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos
perifricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

20

Entregables: actas de las revisiones regulares del sistema y aceptacin de los

niveles de soporte, listado de fallos detectados por el sistema.

20

El resultado de cada etapa son documentos firmados y aprobados por las partes
involucradas Altos costos, especialmente si se requieren cambios Definicin de
Requerimientos Diseo de Sistema y de Software Implementacin y Pruebas de
Unidades Integracin y Prueba del Sistema Operacin y Mantenimiento.

Modelo Espiral
El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida
del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un
esfuerzo del desarrollo por ah mismo comienza otro; adems en cada ejecucin
del desarrollo se sigue cuatro pasos principales:
Determinar o fijar los objetivos
En este paso se definen los objetivos especficos para posteriormente identifica las
limitaciones del proceso y del sistema de software, adems se disea una
planificacin detallada de gestin y se identifican los riesgos.
Anlisis del riesgo
En este paso se efecta un anlisis detallado para cada uno de los riesgos
identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y
luego del anlisis de estos riesgos se planean estrategias alternativas.
Desarrollar, verificar y validar
En este tercer paso, despus del anlisis de riesgo, se eligen un paradigma para
el desarrollo del sistema de software y se lo desarrolla.

20

Planificar
En este ltimo paso es donde el proyecto se revisa y se toma la decisin si se
debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se
desarrollan los planes para la siguiente fase del proyecto.

20

Con cada iteracin alrededor de la espiral, se crean sucesivas versiones del

software, cada vez ms completas y, al final, el sistema de software ya queda
totalmente funcional.
La diferencia principal entre el modelo espiral y otros modelos es la evaluacin del
riesgo. El riesgo es todo lo que pueda salir mal en un proyecto de desarrollo de
software. Por ejemplo, si queremos utilizar un lenguaje de programacin para
desarrollar un sistema operativo, un riesgo posible es que los compiladores
utilizables no produzcan un cdigo objeto eficiente. Los riesgos originan problemas
en el proyecto, como el exceso de los costos. Es as que, la disminucin de los
riesgos es una actividad muy importante.

Metodologa Extreme Programing (XP)

Es un enfoque para el desarrollo de software que utiliza buenas prcticas de

desarrollo y las lleva a los extremos. Se basa en valores, principios y prcticas
esenciales. Los cuatros valores son la comunicacin, la simplicidad, la
retroalimentacin y la valenta. Las actividades de XP consisten en codificar,
probar, escuchar y disear. Por supuesto, la codificacin es esencial en cualquier
proyecto de software. Las pruebas de funcionalidad, desempeo y conformidad
son obligatorias. La actividad de escuchar al cliente y otros programadores y
analistas es fundamental. La principal diferencia entre la administracin de
proyectos de XP y otros tipos de administracin de proyectos ms tradicionales es
que al escuchar lo que desean los usuarios, usted puede calcular la cantidad que
se requerir de cada recurso. Con el fin de equilibrar los resultados del proyecto,
el analista de XP puede ajustar cualquiera de las cuatro variables de recursos.
Fases
Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de
inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se
familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto.
Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema
construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos
meses, dependiendo del tamao y familiaridad que tengan los programadores con la
tecnologa.

Entregable: historial de usuario.

20

Planificacin de la entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimacin del esfuerzo necesario
de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente. Una entrega debera obtenerse en
no ms de tres meses. Esta fase dura unos pocos das.

Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen

los programadores utilizando como medida el punto. Un punto, equivale a una semana
ideal de programacin. Las historias generalmente valen de 1 a 3 puntos. Por otra parte,
el equipo de desarrollo mantiene un registro de la "velocidad" de desarrollo, establecida
en puntos por iteracin, basndose principalmente en la suma de puntos
correspondientes a las historias de usuario que fueron terminadas en la ltima iteracin.

Entregable: cronograma de actividades, Release planning (es una planificacin

donde los desarrolladores y clientes establecen los tiempos de implementacin
ideales de las historias de usuario) y la velocidad en que se realizara el proyecto.
Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de
Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera
iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la
creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el
cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el
valor de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en
produccin.
Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la
Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas de
aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin
anterior. Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una
de ellas es asignada a un programador como responsable, pero llevadas a cabo por
parejas de programadores. Wake en proporciona algunas guas tiles para realizar la
planificacin de la entrega y de cada iteracin.

Entregables: esta fase entrega iteraciones que son las historias del usuario y se
divide en cuantas iteraciones el cliente quiera.

Primera iteracin: primera historia de usuario seria autentificar usuario

tendra la tarea de diseo de la interfaz de autentificacin. Segunda historia
de usuario gestin de cuenta de usuarios. Su tarea o entregable seria
diseo de interfaz para la seleccin de los usuarios, insercin de usuarios,
eliminacin de usuarios.
Segunda iteracin: tercera historia de usuario diseo de la interfaz para la
seleccin de AT3. Sus entregables serian insercin AT3, eliminacin de AT3,
modificacin de AT3.

20

Cada iteracin puede tener varias historias de usuarios las cuales a su vez pueden
tener varios entregables.

Produccin
La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes
de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a
cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana. Las
ideas que han sido propuestas y las sugerencias son documentadas para su posterior
implementacin (por ejemplo, durante la fase de mantenimiento).

Entregables: Guion del usuario. Aprueba o no la iteracin si la ve incompleta la

puede regresar a la fase anterior hasta que cumpla satisfactoriamente los deseos
del cliente.
Mantenimiento
Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el
sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para
realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad
de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de
mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su
estructura.

Entregables: soporte al cliente manual de usuario.

Muerte del proyecto
Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere
que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y
confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan
ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema
no genera los beneficios esperados por el cliente o cuando no hay presupuesto para
mantenerlo.

20

Entregables: documentacin final del sistema.

Cuatro prcticas esenciales de XP

Liberacin limitada

Para que el desarrollo de XP tenga xito, los productos deben liberarse con
rapidez. Esto significa que aun cuando los programadores no puedan implementar
todas las caractersticas en una sola pieza de software, la versin debe liberarse
de acuerdo con lo programado. S, esto es extremo, pero los clientes estarn
contentos porque tendrn un producto para usar.
Semana de trabajo de 40 horas

Los equipos de desarrollo de XP fomentan una prctica cultural en la que el

equipo trabaja de manera intensa durante una semana tpica de 40 horas. Esta
prctica esencial de la programacin extrema tiene como propsito motivar a los
miembros del equipo a que laboren intensamente en el lugar de trabajo, y que
tomen un periodo de descanso para que cuando vuelven al trabajo estn
relajados, menos presionados, con capacidad de detectar los problemas y menos
proclives a cometer errores costosos y omisiones debido a un desempeo
ineficiente o a la apata.
Cliente en el sitio

20

La mayora de los desarrolladores de sistemas argumentan que el cliente es vital

para el xito del sistema, pero terminan reunindose slo una o dos veces con el
cliente para determinar los requerimientos del sistema. La prctica esencial del
cliente en el sitio llega al extremo al insistir en que un experto en el negocio debe
trabajar en el sitio durante todo el proceso de desarrollo. Esta persona toma parte
activa en el proceso, pues escribe los relatos del usuario, se comunica con los
miembros del equipo y ayuda a establecer prioridades.

Programacin en parejas

20

Estamos bastante familiarizados con el concepto de equipos de analistas de

sistemas; por qu no tener equipos de programadores? No, un programador no
mira por encima del hombro de los dems para ver si se cometen errores. Ms
bien, la programacin en parejas significa que dos programadores que eligen
trabajar juntos hacen la programacin, ejecutan las pruebas y conversan acerca
de formas de hacer eficiente y eficazmente el trabajo. Al trabajar con otro
programador puede clarificar su forma de pensar. La programacin en parejas
ahorra tiempo, reduce la negligencia, estimula la creatividad y es una manera
divertida de programar.

Modelo MOPROSOFT
El Modelo Moprosoft Proporciona un conjunto de procesos integrados, con sus
flujos de trabajo, roles y productos, que pueden servir de marco de referencia para
las empresas de la industria de software. El esquema agrupa los procesos en tres
categoras principales: Alta Direccin, Gerencia y Operacin. Esta divisin de
procesos se ajusta a la estructura funcional de una organizacin convencional.
Las organizaciones que no cuenten con procesos establecidos, pueden usar el
modelo como la primera versin de sus procesos e ir ajustndolos de acuerdo a
sus necesidades y experiencia adquirida.
Caractersticas
Es especfico para el desarrollo y mantenimiento de software.
Facilita el cumplimiento de los requisitos de otros modelos como ISO 9000:2008
y CMMI.
Es sencillo de entender y adoptar.
Es prctico en su aplicacin.
Comprende un documento de menos de 200 pginas que al compararlo con
otros modelos y estndares, lo hace bastante prctico.
Resulta acorde con la estructura de las organizaciones mexicanas con
desarrollo o mantenimiento de software.
Est orientado a mejorar los procesos, para contribuir a los objetivos de
la organizacin, y no simplemente ser un marco de referencia o dictaminacin.
Tiene un bajo costo, tanto para su capacitacin y, su adopcin como para
su evaluacin.

20

Beneficios
Mejorar la calidad del software producido por la organizacin que adopta
el modelo.
Elevar la capacidad de las organizaciones para ofrecer servicios con calidad
y alcanzar niveles internacionales de competitividad.
Integrar todos los procesos de la organizacin y mantiene la alineacin con
los objetivos estratgicos.
Reconocer a las organizaciones mexicanas por su nivel de madurez
de procesos.
Obtener acceso a las prcticas de ingeniera de software de clase mundial.
Pertenecer a la Lista Nacional de Empresas Dictaminadas, que sirve como una
referencia oficial para clientes, autoridades y competidores.

Moprosoft se estructura en 3 categoras:

Categora de Alta Direccin (DIR)
Se establecen los lineamientos para los procesos de la Categora de Gerencia y se
retroalimenta con la informacin generada por ellos en apoyo a la estrategia de la
organizacin.
Categora de Gerencia(GER)
Se definen los elementos para el funcionamiento de los procesos de la Categora de
Operacin en funcin de la estratgica de Direccin, recibe y evala la informacin
generada por stos y comunica los resultados a la Categora de Alta Direccin.

20

Categora de Operacin (OPE)

Se realizan las actividades de acuerdo a los elementos proporcionados por la Categora
de Gerencia y entrega a sta la informacin y productos generados.

Direccin
Gestin de Negocios

Su propsito la razn de Ser de la organizacin, sus objetivos y las condiciones

para lograrlos, para lo cual es necesario considerar las necesidades de los
clientes, as como evaluar los resultados para poder proponer cambios que
permitan la mejora continua.
Gestin
Gestin de Proyectos:

Generar proyectos que contribuyan al cumplimiento de los objetivos y estrategias

de la organizacin.
Gestin de Procesos:

Establece procesos que apoyen a las estrategias de la organizacin, as como

actividades de mejora en los mismos.
Gestin de Recursos:

Consigue y provee a la organizacin de los recursos para desarrollar las

actividades de acuerdo a las necesidades de cada proceso y proyecto.
Operacin
Administracin de Proyectos Especficos

Administra los proyectos internos y externos en base a los planes de cada uno,
genera acciones correctivas.
Desarrollo y Mantenimiento de Software:

Genera los productos a travs del ciclo de vida de desarrollo del software
buscando satisfacer las necesidades del cliente.
Entregables en fases y sus caractersticas:
FASE ESPECIFICACIN DE REQUERIMIENTOS.

Descripcin: Se compone de una introduccin y una descripcin de

requerimientos.
Introduccin:
Descripcin general del software y su uso en el mbito de negocio del cliente.
Descripcin de requerimientos:

* Funcionales: Necesidades establecidas que debe satisfacer el software cuando

es usado en condiciones especficas. Las funcionalidades deben ser adecuadas,
exactas y Seguras.

20

* Interfaz con usuario: Definicin de aquellas caractersticas de la interfaz de

usuario que permiten que el software sea fcil de entender, aprender, que genere
satisfaccin y con el cual el usuario pueda desempear su tarea eficientemente.
Incluyendo la descripcin del prototipo de la interfaz.

* Interfaces externas: Definicin de las interfaces con otro software o con

hardware.
* Confiabilidad: Especificacin del nivel de desempeo del software con respecto
a la madurez, tolerancia a fallas y recuperacin.
* Eficiencia: Especificacin del nivel de desempeo del software con respecto al
tiempo y a la utilizacin de recursos.
* Mantenimiento: Descripcin de los elementos que facilitarn la comprensin y la
realizacin de las modificaciones futuras del software.
* Portabilidad: Descripcin de las caractersticas del software que permitan su
transferencia de un ambiente a otro.
* Restricciones de diseo y construccin: Necesidades impuestas por el
cliente.
* Legales y reglamentarios: Necesidades impuestas por leyes, reglamentos,
entre otros.
FASE DE ANLISIS Y DISEO:

Descripcin: Esta fase contiene la descripcin textual y grafica de la estructura de

los componentes de software. El cual consta de las siguientes partes:
Arquitectnica:
Contiene la estructura interna del sistema, es decir la descomposicin del sistema
en subsistemas. As como la identificacin de los componentes que integran los
subsistemas y las relaciones de interaccin entre ellos.
Detallada:
Contiene el detalle de los componentes que permita de manera evidente
Su construccin y prueba en el ambiente de programacin.
FASE COMPONENTE

Software: Sistema de software, destinado a un cliente o usuario, constituido por

componentes agrupados en subsistemas, posiblemente anidados.
Configuracin de Software: Conjunto consistente de productos de software, que
incluye:
Especificacin de Requerimientos.
Anlisis y Diseo.
Software.

20

Registro de Rastreo.

 Plan de Pruebas de Sistema.

Reporte de Pruebas de Sistema.
Plan de Pruebas de Integracin.
Reporte de Pruebas de Integracin.
Manual de Usuario.
Manual de Operacin.
Manual de Mantenimiento.
Manual de Usuario: Documento electrnico o impreso que describe la forma de
uso del software con base a la interfaz del usuario. ste deber ser redactado en
trminos comprensibles a los usuarios.
Manual de Operacin: Documento electrnico o impreso que contenga la
informacin indispensable para la instalacin y administracin del software, as
como el ambiente de operacin (sistema operativo, base de datos, servidores,
etc.). ste deber ser redactado en trminos comprensibles al personal
responsable de la operacin.
Manual de Mantenimiento: Documento electrnico o impreso que describe la
Configuracin de Software y el ambiente usado para el desarrollo y pruebas
(Compiladores, herramientas de anlisis y diseo, construccin y pruebas). Este
deber ser redactado en trminos comprensibles al personal de mantenimiento.
Reporte de Actividades: Registro peridico de actividades, fechas de inicio y fin,
responsables y mediciones, tales como:
Tiempo de produccin, de correccin, de verificacin y de validacin, Defectos
encontrados en verificacin, validacin o prueba,
Tamao de productos.
Lecciones Aprendidas: Registro de mejores prcticas, problemas recurrentes y
experiencias exitosas en la solucin de problemas, encontrados en un ciclo de
desarrollo y mantenimiento.
Reporte de Mediciones y Sugerencias de Mejora:
Registro que contiene:
* Mediciones de los indicadores del proceso de Desarrollo y Mantenimiento de
Software.

20

* Sugerencias de mejora al proceso de Desarrollo y Mantenimiento de Software

(mtodos, herramientas, formatos, estndares, etc.).

Metodologa RUP
Es ms que in simple proceso de desarrollo de software, es un marco de trabajo
genrico que puede especializarse para una gran variedad de sistemas de
software, reas de aplicaciones, tamaos de proyecto, etc.
Utiliza el lenguaje unificado de modelado para preparar todos los esquemas de un
sistema de software.
Sus aspectos definitorios se resumen en tres frases claves

Dirigido por casos de uso.

Centrado en la arquitectura.

Iterativo e incremental

Dirigido por casos de uso

Casos de uso. - Representan los requisitos funcionales. Guan su diseo,
implementacin y prueba.
Un sistema de software ve la luz para dar servicio a sus usuarios, por lo tanto,
para construir un sistema con xito debemos conocer o que sus futuros usuarios
necesitan y desean.
Usuario. - Alguien o algo que interacta con el sistema que estamos desarrollando.
Una interaccion de este tipo es un caso de uso, y todos juntos constituyen el
modelo de casos de uso.
Centrado en la arquitectura
La arquitectura de software incluye los aspectos estticos y dinmicos ms
significativos del sistema, surge de las necesidades de la empresa, como las
perciben los usuarios y los inversores, se refleja en los casos de uso. Sin
embargo, tambin de ver influida por otros factores como, la plataforma, los
bloques de construccin, entre otros. Debe haber interaccin entre los caos de uso
y la arquitectura.
Los casos de uso deben encajar en la arquitectura cuando se llevan a cabo.
La arquitectura debe permitir el desarrollo de los casos de uso requeridos, ahora y
en futuro.
Tanto la arquitectura como los casos de uso deben evolucionar en paralelo.

20

Es iterativo e incremental
Es practico dividir el trabajo en partes ms pequeas o mini proyectos. Cada mini
proyecto es una iteracin que resulta en un incremento. Para la efectividad
mxima, las iteraciones deben estar controladas, esto es, seleccionarse y
ejecutarse de forma planificada.

Iteracin. - Trata un grupo de casos de uso que juntos amplan la utilidad del
producto.
En cada iteracin los desarrolladores identifican y especifican los casos de uso
relevantes, crean un diseo utilizando la arquitectura seleccionada como gua,
implementan el diseo mediante componentes y verifican que estos satisfacen los
casos de uso. si una iteracin cumple con sus objetivos el desarrollo continuo con
la siguiente iteracin, sino, los desarrolladores deben revisar sus decisiones
previas y probar con un nuevo enfoque.
Beneficios de un proceso iterativo controlado:

Reduce el coste de riesgo a los costes de un solo incremento.

Reduce el riesgo de no sacar al mercado el producto en el calendario

previsto.

Acelera el ritmo del esfuerzo de desarrollo.

Reconoce que no pueden definirse completamente los requisitos del

producto al principio del desarrollo.

Vida del proceso unificado

El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la
vida de un sistema, cada ciclo consta de cuatro fases:

Inicio

Elaboracin

Construccin

Transicin

Cada fase se subdivide en iteraciones.

Cada ciclo produce una nueva version del sistema, y cada version es un producto
preparado para su entrega. El producto terminado incluye:

Requisitos

Casos de uso

Casos de prueba

Entre otros.

Los objetivos que se persiguen en cada fase son los siguientes:

20

Inicio: Obtencin de los objetivos, catlogo de requisitos, identificacin de casos

de uso.

Entregables: misin, visin, plan de desarrollo de software.

Elaboracin: Refinamiento de los objetivos de la fase anterior, casos de uso,
anlisis, diseo, definicin y establecimiento de la arquitectura base del sistema.
Entregables: modelos de casos de uso, modelo de anlisis, diseo de interfaces,
diseo de clases, plantilla de clases, diseo de la base de datos, modelo de
despliegue.
Construccin: Refinamiento de los objetivos de las fases anteriores y
construccin del sistema de informacin.
Entregables: modelo de componentes, modelo de caja negra, prototipo del
software.
Transicin: Refinamiento de los objetivos de las fases anteriores e implantacin
del sistema de informacin (preparacin del producto para su entrega y pasos a
produccin de versiones no finales (porque hay que hacer ajustes) y de la versin
final prevista).

20

Entregables: prueba de aceptacin.

Bibliografa
Allsoft. (2011). Obtenido de Allsoft: http://www.allsoft.mx/recursos/ASMoprosoft.pdf
Gutierrez, D. (Julio de 2011). Obtenido de
http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_proces
os.pdf
Ivar Jacobson, Grady Booch, Jame Rumbaugh. (2000). El proceso unificado de
desarrollo de software. Madrid: Addison Wesley.
Kendall, K. E. (2005). Analisis y diseo de sistemas. Naucalpan de Juarez:
Pearson Educacin.
Libros web. (s.f.). Obtenido de Libros web:
http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html

20

R., G. F. (2011). Obtenido de

http://www.ojovisual.net/galofarino/modeloespiral.pdf