1

Ingeniera de Software I
DOCENTE:
ING. JOS DENYS HERNNDEZ ESPINOZA
 Objetivo de la Asignatura 2

El alumno elaborar el modelado de un sistema de

informacin empleando metodologas, tcnicas y
herramientas para construir una propuesta de solucin a un
problema determinado.
 Temario 3
Unidades Temticas
1. Metodologas de desarrollo de software.
Clasificacin.
Ventajas y desventajas.
2. Administracin de requerimientos.
Estudio de factibilidad.
Obtencin y anlisis de requerimientos.
Especificacin de requerimientos.
Validacin de requerimientos.
3. Anlisis y modelado de desarrollo de software con UML.
Introduccin al UML (Lenguaje Unificado de Modelado (UML, en ingls, Unified Modeling
Language).
Diagramas de Casos de uso.
Diagramas de Clases.
Diagrama de Secuencia.
Diagrama de Colaboracin.
Diagrama de Estado.
 Bibliografa 4

Autor Ao Ttulo del Documento Ciudad Pas Editorial

Booch G., (2000) El Lenguaje Unificado de Madrid Espaa Addison Wesley,

Rumbaugh J., Modelado. Manual de
Jacobson I. Referencia.

Booch G., (2000) El Lenguaje Unificado de Madrid Espaa Addison Wesley

Rumbaugh J., Modelado. Gua del Usuario
Jacobson I.
Pressman, Roge S (2002) Ingeniera del software. Un Madrid Espaa McGraw Hill
enfoque prctico
Sommerville, Ian. (2005) Ingeniera del Software. Madrid Espaa Addison Wesley.
 Evaluacin 5

Practicas/Exposicin 20%
Examen 40%
Tareas 30%
Asistencia 10%
100%
Las actividades se mandarn por email usando:
- Asunto: Usar la nomenclatura segn la actividad que esta anexando al email.
- Cuerpo del email Mensaje: Solo poner su nombre completo o algn otro dato relevante que desee.
- Solo se aceptarn usando la nomenclatura establecida para tal, y al email jodesite88@Hotmail.com

Reglas para hacer vlidas las Tareas:

- Usar formato APA.
- Deben guardarlas y mandarlas en formato archivo .PDF
- El documento deber tener un margen de 2.5 cm por cada lado.
- Los ttulos sern Arial tamao 14 en negritas y el Contenido Arial tamao 12.
- Usar interlineado de 1.5 de espacio.
- El documento deber tener: Portada, ndice, Contenido, Conclusiones y Bibliografa.
 Evaluacin 6
Nomenclatura para nombrar las actividades a realizar:
- Nombrar las Tareas de la siguiente forma: T_Matrcula-Grupo
- Nombrar las Prcticas de la siguiente forma: P_Matrcula-Grupo

En las Exposiciones:
- Crear material para 10 minutos como mnimo y 15 como mximo.
- Debern participar y estar presentes todos los integrantes de equipo.
- Deber tener una estructura y diseo grfico apropiado al tema a ser presentado.
- Debern tener una carga de informacin por diapositiva apropiada de forma que tengan valor didctico, se
recomienda de 6 a 10 renglones y un tamao de letra de 20 puntos como mnimo, tipografa clara o
entendible y podrn apoyarse de grficos bajados de Internet como, Tablas, Imgenes, Fotos, etc.

NOTA: La falta u omisin de alguno de los aspectos de Evaluacin repercutir en puntos menos en su
calificacin final.
 7

INTRODUCCIN RPIDA.

UNIDAD 1.
Metodologa del
Desarrollo de Software.
 Concepto de Ingeniera de Sistemas
8
Concepto de sistema, conjunto de cosas que ordenadamente relacionadas
entre s contribuyen a un determinado objeto. De forma recursiva, las partes de
un sistema pueden ser consideradas como nuevos sistemas (subsistemas).
Los sistemas informticos estn compuestos por ordenadores y sus perifricos.
Entre ellos podemos distinguir dos tipos de subsistemas:
Sistemas Hardware, son los elementos materiales, los que se pueden tocar.
Sistemas Software, los programas que gobiernan el funcionamiento del
computadora.
El objetivo de los sistemas informticos es el tratamiento de la informacin:
almacenamiento, elaboracin y presentacin de datos. De esta forma se
automatizan determinadas acciones.
En la concepcin del sistema informtico no solo se decide el trabajo a realizar,
sino tambin cmo ha de ser utilizado por los usuarios.
 Concepto de Ingeniera de Sistemas
9
Caractersticas del software (lo contrario para el hardware):
No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales.
Su duplicacin es poco costosa, lo caro es el desarrollo.
Puede ser modificado fcilmente, tanto que es necesario un control de versiones.
La Ingeniera del Software comprende las tcnicas y procedimientos ingenieriles para el
desarrollo del software. La Ingeniera del Software no se plantea solo una actividad de
programacin, previamente son necesarias las fases de anlisis y diseo y posteriormente
la integracin y la verificacin, incluso el manteniendo cuando el producto ya est en
explotacin. (CICLO DE VIDA).
Inicialmente la tarea de desarrollo era realizada individualmente por hbiles creativos, de
forma poco disciplinada. El trabajo en equipo supone la divisin y organizacin del
trabajo utilizando metodologas de desarrollo.
En los 70 y los 80 empiezan a usarse herramientas CASE (Computer Aided Software
Engineering). En los 90 IPSE (Integrated Project Support Environment Ambiente de Apoyo
Integrado de Desarrollo) e ICASE (Integrated Computer - Aided Software Engineering
Ingeniera de Software Asistida e Integrada por Computadora).
 La crisis del Software 10

Se produce cuando surge la necesidad de desarrollar aplicaciones software

demasiado complejas, a mediados de los 60.
Para superar la crisis:
Aparicin de metodologas concretas de desarrollo.
Concepcin de la definicin de la Ingeniera del Software como disciplina.
Trabajo en equipo y especializacin (analistas, programadores,
depuradores).
No se ha llegado a una situacin estable, sino a una evolucin permanente con
avances continuos en la Ingeniera del Software, forzados por el rpido
abaratamiento y aumento de capacidad del hardware.
 Mitos del Software 11

El hardware es mucho ms importante que el software.

El software es fcil de desarrollarse y modificarse.
El software consiste exclusivamente en programas ejecutables.
El desarrollo del software es slo una labor de programacin.
Es natural que el software contenga errores.
El software no necesita de validaciones.
Se hace software por hacer sin requerimientos ni especificaciones del cliente.
 Mantenimiento del software 12

El mantenimiento no representa una actividad especfica, sino que consiste en

rehacer parte de las actividades correspondientes a las otras fases del desarrollo
para introducir cambios sobre una aplicacin ya en fase de explotacin.
MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron
detectados en el desarrollo del producto.
MANTENIMIENTO ADAPTATIVO, modificar una aplicacin para adaptarla a las
nuevas necesidades del entorno.
MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del
producto.
 Gestin de cambios
13

El mantenimiento supone la realizacin de una serie de cambios sucesivos.

Si afectan a la mayor parte del sistema se puede plantear como un nuevo
desarrollo.
Cada cambio debe ser documentado con:
INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser propuesto por el
cliente.
INFORME DE CAMBIO, describe la solucin dada al problema y el cambio
realizado.

REINGENIERA, es necesaria cuando el desarrollo de una aplicacin no est

documentado y se dispone solamente del cdigo. Se llama tambin ingeniera
inversa porque supone reconstruir y documentar las fases de anlisis y diseo llegando
a la estructura modular de la aplicacin y las dependencias entre mdulos y
funciones. Estas actividades organizan y documentan un sistema deficiente.
 Garanta de calidad
14
Para evaluar la calidad son necesarias tcnicas de aplicacin de mtricas precisas tanto sobre los productos software
como a sus procesos de desarrollo. McCall propone un esquema basado en valoraciones a 3 niveles:
FACTORES, valoracin significativa de la calidad en base a los criterios establecidos.
CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad.
MTRICAS, mediciones puntuales de determinadas caractersticas del producto.
Entre los factores de calidad tenemos:
CORRECCIN, grado en que cumple con las especificaciones.
FIABILIDAD, grado de ausencia de fallos.
EFICIENCIA, relacin entre la cantidad de resultados y los recursos requeridos.
SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas.
FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicacin.
MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario.
FLEXIBILIDAD, facilidad para modificar el producto.
FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su correccin o fiabilidad.
TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma.
REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos.
INTEROPERATIVIDAD, facilidad del producto para trabajar con otros.
 Plan de Garanta de Calidad de Software
15
SQAP: Software Quality Assurance Plan

Es un documento formal para organizar el proceso de desarrollo software

de manera que se asegure la calidad del producto final. Debe
contemplar:
Organizacin, direccin y seguimiento de los equipos de desarrollo.
Modelo de ciclo de vida a seguir, detallando fases y actividades.
Documentacin requerida, determinando contenido y guin de cada
documento.
Revisiones y auditorias, para garantizar que las actividades y los documentos
son correctos.
Organizacin de las pruebas, a distintos niveles.
Organizacin de la etapa de mantenimiento, determinando cmo gestionar
la realizacin de cambios.
 Revisiones del Software
16

Consiste en inspeccionar el resultado de una actividad para determinar si es

aceptable o contiene defectos que han de ser subsanados.
Las revisiones deben ser formalizadas y contempladas en el modelo de ciclo de
vida:
Deben ser realizadas por un grupo de personas y no individualmente.
El grupo de be ser reducido.
Debe ser imparcial, nada que ver con los desarrolladores.
Se debe revisar el producto, pero no el productor ni el proceso de produccin.
Se debe establecer de antemano una lista formal de comprobaciones.
Se debe levantar acta de la reunin de revisin, recogiendo las decisiones
tomadas.
 Pruebas del Software 17

Consiste en hacer funcionar el producto o una parte de l y comprobar si los

resultados son correctos.
No permite garantizar la calidad del producto. En general no es posible probar un
producto de forma exhaustiva, debido a su complejidad.
 Qu es la Ingeniera del Software? 18
La crisis del Software
Mantenimiento del software
Surge la necesidad de desarrollar
Correctivo, Adaptativo, Perfectivo
aplicaciones software demasiado
complejas
Mitos del Software
El hardware es mucho ms importante que el software.

Gestin de cambios Garanta de calidad

Reingeniera Evaluar la calidad son necesarias tcnicas

Revisiones del Software

Plan de Garanta de Inspeccionar el resultado
Pruebas del Software
Calidad de Software de una actividad para
Consiste en hacer
documento formal para determinar si es aceptable
funcionar el producto o
organizar el proceso de o contiene defectos
una parte de l y
desarrollo software de
comprobar si los resultados
manera que se asegure la
son correctos.
calidad del producto final
 Qu es la Ingeniera del Software? 19

Podemos definir a la Ingeniera del Software como la aplicacin prctica del conocimiento
cientfico en el diseo y construccin de programas de computadora y la documentacin
asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin como
desarrollo de software o produccin de software.
Entonces, la Ingeniera del Software implica un trabajo integral, es decir, se produce un anlisis del
contexto, se disea el proyecto, se desarrolla el correspondiente software, se efectan las
pruebas para asegurar su correcto funcionamiento y finalmente se implementa el sistema.
El proceso de desarrollo de un software se denomina formalmente como ciclo de vida del
software, en tanto, se encuentra conformada por cuatro estados:
Concepcin (en esta se fijan los objetivos y se desarrolla el modelo).
Elaboracin (en este paso se establecen las caractersticas y cmo ser la arquitectura del
mismo y porqu).
Construccin (implica el desarrollo del programa).
Transicin (es el momento en el cual se transfiere el producto final al usuario).
 20

1.1. CLASIFICACIN DE LAS

DIFERENTES METODOLOGAS.

UNIDAD 1. Metodologa del

Desarrollo de Software.
 Metodologas de Desarrollo de Software: 21
Modelo en Cascada.
Modelo en Componentes.
Modelo Evolutivo.
Modelo Incremental.
Modelo en Espiral.
Modelo en Espiral (WIN/WIN).
Modelo en V.
Modelo en Prototipos.
Modelo de Desarrollo concurrente.
RUP (Proceso Unificado de Racional).
DRA (Desarrollo Rpido de Aplicaciones).
Modelo de Desarrollo Iterativo e Incremental.
 Desarrollo en Cascada 22

Es el enfoque metodolgico que ordena rigurosamente las

etapas del proceso para el desarrollo de software, de tal
forma que el inicio de cada etapa debe esperar a la
finalizacin de la etapa anterior. Un ejemplo de una
metodologa de desarrollo en cascada es:
1. Anlisis de requisitos.
2. Diseo del Sistema.
3. Diseo del Programa.
4. Codificacin.
5. Pruebas.
6. Implantacin.
7. Mantenimiento.
23
 Desarrollo en Componentes 24

Permite reutilizar piezas de cdigo preelaborado que permiten realizar

diversas tareas, conllevando a diversos beneficios como las mejoras a la
calidad, la reduccin del ciclo de desarrollo y el mayor retorno sobre la
inversin.
La reutilizacin de software es un proceso de la Ingeniera de Software
que conlleva al uso recurrente de activos de software en la
especificacin, anlisis, diseo, implementacin y pruebas de una
aplicacin o sistema de software.
Un componente es una unidad de composicin de aplicaciones
software, que posee un conjunto de interfaces y un conjunto de
requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al
sistema y compuesto con otros componentes de forma independiente,
en tiempo y espacio.
 25
En esencia, un componente es una pieza de cdigo preelaborado que
encapsula alguna funcionalidad expuesta a travs de interfaces estndar.
Los componentes son los "ingredientes de las aplicaciones", que se juntan y
combinan para llevar a cabo una tarea. Es algo muy similar a lo que
podemos observar en el equipo de msica que tenemos en nuestra casa.

Cada componente de aquel aparato ha sido diseado para acoplarse

perfectamente con sus pares, las conexiones son estndar y el protocolo de
comunicacin est ya preestablecido. Al unirse las partes, obtenemos
msica para nuestros odos.
Caractersticas de un Componente: 26

Identificable: Debe tener una identificacin que permita acceder fcilmente a sus
servicios que permita su clasificacin.
Auto contenido: Un componente no debe requerir de la utilizacin de otros para finiquitar
la funcin para la cual fue diseado.
Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u
otro componente que lo remplace y mejore.
Con acceso solamente a travs de su interfaz: Debe asegurar que estas no cambiaran a
lo largo de su implementacin.
Sus servicios no varan: Las funcionalidades ofrecidas en su interfaz no deben variar, pero
su implementacin s.
Bien Documentado: Un componente debe estar correctamente documentado para
facilitar su bsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
Es genrico: Sus servicios deben servir para varias aplicaciones.
Reutilizado dinmicamente: Puede ser cargado en tiempo de ejecucin en una
aplicacin.
Independiente de la plataforma: Hardware, Software, S.O.
Grfico del desarrollo de software basado en componentes
27
Ventajas:
28

Funcionalidad mejorada y sencilla para el usuario final.

Reduce los costos y tiempos en su desarrollo y pruebas.
Reutilizacin del software basado en sus mdulos.
Simplifica las pruebas finales en busca de errores.
Simplifica el mantenimiento y escalabilidad del sistema.
Ofrece una mayor calidad en el software.
Ciclos de desarrollo ms cortos y por etapas.
Desventajas:
29

Genera mucho tiempo analizar riesgos de implementacin de cada

requisito funcional.
Genera mucho trabajo adicional cuando no se analiza bien un requisito.
Confiabilidad de los componentes, como su desarrollo es basado en
mdulos existentes pueden acarrearse errores desde el origen de donde
se obtienen los datos reutilizados.
Exige una cierta habilidad en los analistas de software (es bastante difcil
si se carece de ellos).
 Modelo Evolutivo 30

Este enfoque entrelaza las actividades de

especificacin, desarrollo y validacin. Un sistema
inicial se desarrolla rpidamente a partir de
especificaciones abstractas. ste se refina basndose
en las peticiones del cliente para producir un sistema
que satisfaga sus necesidades.

El desarrollo evolutivo consta del desarrollo de una

versin inicial que luego de exponerse se va refinando
de acuerdo de los comentarios o nuevos
requerimientos por parte del cliente o del usuario final.
Las fases de especificacin, desarrollo y validacin se
entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
31
1.Desarrollo exploratorio, donde el objetivo del proceso
es trabajar con el cliente para explorar sus
requerimientos y entregar un sistema final. El desarrollo
empieza con las partes del sistema que se
comprenden mejor. El sistema evoluciona agregando
nuevos atributos propuestos por el cliente.

2.Prototipos desechables, donde el objetivo del

proceso de desarrollo evolutivo es comprender los
requerimientos del cliente y entonces desarrollar una
definicin mejorada de los requerimientos para el
sistema. El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprenden del
todo.
 32
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo
suele traer ms ventajas en comparacin con un enfoque en cascada ya
que el sistema se va ajustando a las necesidades del cliente, a la vez que
l mismo entiende mejor sus propios requerimientos. Sin embargo el
enfoque evolutivo desde una perspectiva de ingeniera y gestin suele
tener dos grandes problemas:

1. El proceso no es visible. Los administradores tienen que hacer entregas

regulares para medir el progreso. Si los sistemas se desarrollan
rpidamente, no es rentable producir documentos que reflejen cada
versin del sistema.
2. A menudo los sistemas tienen una estructura deficiente. Los cambios
continuos tienden a corromper la estructura del software. Incorporar
cambios en l se convierte cada vez ms en una tarea difcil y costosa.
33
 Modelo Incremental 34

Es una unin de las mejores funcionalidades del modelo de cascada

y del modelo de prototipos. A medida que se presenta un prototipo
se produce un incremento, que es una iteracin del proceso
anterior pero aplicando las experiencias aprendidas del proceso
anterior. A diferencia del modelo de prototipos, los prototipos de este
modelo estn orientados a ser operacionales en cada incremento y
no ser solo una previa de cmo sera el sistema en su versin final.
En una visin genrica, el proceso se divide en 4 partes:
Anlisis
Diseo
Cdigo
Prueba
 35

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con

la filosofa interactiva de Construccin de Prototipos. Como se muestra en la
Figura 1, el modelo incremental aplica secuencias lineales de forma
escalonada mientras progresa el tiempo en el calendario. Cada secuencia
lineal produce un incremento del software. El primer incremento generalmente
es un producto esencial denominado ncleo.
 36
El modelo incremental
combina elementos del
modelo en cascada con la
filosofa interactiva de
construccin de
prototipos. Se basa en la
filosofa de construir
incrementando las
funcionalidades del
programa. Este modelo
aplica secuencias lineales
de forma escalonada
mientras progresa el
tiempo en el calendario.
Cada secuencia lineal
produce un incremento del
software.
Ventajas:
37

Reduce el tiempo de desarrollo inicial, ya que se implementa la

funcionalidad parcial.
Provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada
realimentado, reduciendo sus desventajas slo al mbito de cada
incremento.
Resulta ms sencillo acomodar cambios al acotar el tamao de los
incrementos.
Es ms fcil probar y depurar en una iteracin ms pequea.
Desventajas:
38

No es recomendable para casos de sistemas de tiempo real, de alto

nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de
riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.
Pueden surgir problemas referidos a la arquitectura del sistema porque
no todos los requisitos se han reunido, ya que se supone que todos ellos
se han definido al inicio
 Modelo en Espiral 39

Es un modelo de desarrollo evolutivo propuesto por Barry Boehm,

que utiliza prototipos como apoyo. La forma de espiral representa
una iteracin (repeticin) de procesos que, a medida que se van
entregando prototipos y stos son revisados por los clientes o
usuarios finales, el tiempo empleado para desarrollar la prxima
versin es cada vez mayor. Cada divisin recibe el nombre de
regin de tareas.

Aunque el modelo espiral representa ventajas por sobre el

desarrollo lineal, el clculo de los riesgos puede ser muy
complicado y no es tan usado en la realidad.
 40

El Modelo en Espiral se divide en un nmero de actividades estructurales, tambin llamadas

"regiones de tareas" . Generalmente existen seis regiones de tareas:
Comunicacin con el cliente.- Las tareas requeridas para establecer comunicacin entre el
desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.
Planificacin.- Las tareas requeridas para definir recursos, tiempos e informacin
relacionada con el proyecto.
Anlisis de riesgos.- Las tareas requeridas para evaluar riesgos tcnicos y de gestin.
Ingeniera.- Las tareas requeridas para construir una o ms representaciones de la
aplicacin
Construccin y adaptacin.- Las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario.
Evaluacin del cliente.- Las tareas requeridas para obtener la reaccin del cliente, segn la
evaluacin de las representaciones del software creadas durante la etapa de ingeniera e
implementada durante la etapa de instalacin.
41
 Modelo en Espiral (Win/Win) 42

Basado en el Modelo Espiral clsico que sugiere la comunicacin con el

cliente para fijar los requisitos, en que simplemente se pregunta al cliente
qu necesita y l proporciona la informacin para continuar, sin embargo,
esta es una situacin que rara vez ocurre. Normalmente el cliente y
desarrollador entran en una negociacin, se negocia coste frente a
funcionalidad, rendimiento, calidad, etc. Las mejores negociaciones se
fuerzan en obtener Victoria & Victoria (Win & Win), es decir que el cliente
gane obteniendo el producto que lo satisfaga, y el desarrollador tambin
gane consiguiendo presupuesto y fecha de entrega realista.
Evidentemente, este modelo requiere fuertes habilidades de negociacin.
 43
Cada ciclo envuelve cuatro actividades principales:
Elaboracin del sistema o subsistemas y los objetivos, Restricciones y
alternativas del proceso.
Evaluar las alternativas respecto a los objetivos y restricciones.
Identificar y resolver el mayor nmero de fuentes de producto y
Riesgos posibles.
Elaboracin de la definicin del producto y del proceso.
Planificacin del prximo ciclo y actualizacin de la planificacin.

Del ciclo de vida. Ello incluye, si es necesario, el

Particionamiento del sistema en subsistemas a desplegarse en
Paralelo. Puede incluir, adems, la definicin de un plan para
Finalizar el proyecto si ste es de riesgo demasiado alto o no es
Factible.
44
 Modelo en V (Cuatro 45
Niveles)
Define un procedimiento uniforme para el desarrollo de productos
para las Tecnologas y la Informacin.
El modelo en V se encarga de representar las relaciones
temporalmente entre las fases del ciclo de desarrollo del proyecto, en
el se realizan dos procesos al mismo tiempo hasta llegar a la punta de
la V, conforme se reduce el espacio esto se refiere a la reduccin de
tiempo de cada fase y mientras mas se reduce aumenta el nivel, esto
puede ser prcticamente una ventaja o desventaja dependiendo
del modo de trabajo de cada persona ya que para algunas personas
puede ser benfico trabajar con dos procesos a la vez o puede ser
mas complicado.
 46

La parte izquierda de la V representa la corriente donde se definen

las especificaciones del sistema.
La parte derecha de la V representa la corriente donde se
comprueba el sistema (contra las especificaciones definidas en la
parte izquierda).
La parte de abajo, donde se encuentran ambas partes, representa
la corriente de desarrollo.

La corriente de especificacin consiste principalmente de:

1. Especificaciones de requerimiento de usuario.
2. Especificaciones funcionales.
3. Especificaciones de diseo.
 47
1.El nivel 1 est orientado al cliente. El inicio del
proyecto y el fin del proyecto constituyen los
dos extremos del ciclo. Se compone del anlisis
de requisitos y especificaciones, se traduce en
un documento de requisitos y especificaciones.
2.El nivel 2 se dedica a las caractersticas
funcionales del sistema propuesto. Puede
considerarse el sistema como una caja negra, y
caracterizarla nicamente con aquellas
funciones que son directa o indirectamente
visibles por el usuario final, se traduce en un
documento de anlisis funcional.
3.El nivel 3 define los componentes hardware y
software del sistema final, a cuyo conjunto se
denomina arquitectura del sistema.
4.El nivel 4 es la fase de implementacin, en la
que se desarrollan los elementos unitarios o
mdulos del programa.
 Modelo en Prototipos 48

Este permite que todo el sistema, o algunas de sus partes, se

construyan rpidamente para comprender con facilidad y aclarar
ciertos aspectos en los que se aseguren que el desarrollador, el usuario
y el cliente estn de acuerdo en lo que se necesita as como tambin
la solucin que se propone para dicha necesidad y de esta forma
minimizar el riesgo y la incertidumbre en el desarrollo. Este modelo se
encarga del desarrollo de diseos para que estos sean analizados y se
pueda prescindir de ellos a medida que se adhieran nuevas
especificaciones, es ideal para medir el alcance del producto, pero
no se asegura su uso real.
 49

Las etapas del modelo son:

Investigacin preliminar.
Colecta y refinamiento de los requerimientos y proyecto rpido.
Anlisis y especificacin del prototipo.
Diseo y construccin del prototipo.
Evaluacin del prototipo por el cliente.
Renacimiento del prototipo.
Diseo tcnico.
Programacin y test.
Operacin y mantenimiento.
 50
Recoleccin y
refinamiento de
requisitos
(Paso 1) Cada realizacin de un Prototipo
requiere una revisin que se puede
Producto de
Diseo rpido
ir intercalando (con otras etapas del
ingeniera
(Paso 6)
(Paso 2) desarrollo) conforme se vaya
avanzando en la entrega de los
requisitos solicitados.
Refinamiento Construccin
del prototipo del prototipo
(Paso 5) (Paso 3)

Evaluacin del
prototipo por el
cliente
(Paso 4)
 Modelo de Desarrollo 51
Concurrente
Este modelo define una serie de acontecimientos que dispararn
transiciones de estado a estado para cada una de las actividades.
Durante las primeras etapas del diseo, no se contempla una
inconsistencia del modelo de anlisis. Esto genera la correccin del
modelo de anlisis de sucesos, que disparar la actividad de anlisis del
estado hecho al estado cambios en espera.
Se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor. Un sistema cliente/servidor se compone de un conjunto
de componente funcionales. Cuando se aplica a cliente/servidor, el
modelo de proceso concurrente define actividades en dos
dimensiones: una divisin de sistemas y una divisin de componentes.
 52

Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseo y
realizacin. La concurrencia se logra de dos formas:
Las actividades del sistema y de componente ocurren simultneamente y
pueden modelarse con el enfoque orientado a objetos descrito anteriormente.
Una aplicacin cliente/servidor tpica se implementa con muchos componentes,
cada uno de los cuales se pueden disear y realizar concurrentemente.

Ventajas
Excelente para proyectos en los que se conforman grupos de trabajo
independientes.
Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas
Si no se dan las condiciones sealadas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar en este mtodo
 53

La imagen proporciona una

representacin esquemtica de una
actividad (anlisis) como se puede
observar todas las actividades existen
concurrentemente, pero residen en
estados diferentes , al principio es la
comunicacin con el cliente (no esta
plasmada en la figura) y esta en
estado de cambios en espera. La
actividad de anlisis esta en ninguna
significa que ya se ha hecho la
comunicacin con el cliente luego
hace una transicin al estado bajo
desarrollo. sin embargo si el cliente
indica que se deben hacer cambios
en requisitos , la actividad de anlisis
cambia del estado bajo desarrollo al
estado cambios en espera.
 RUP (Proceso Unificado de 54
Rational)
Es un proceso de desarrollo de software desarrollado por la empresa
Rational Software, gracias a la colaboracin de Grady Booch,
actualmente es propiedad de IBM. Junto con el Lenguaje Unificado
de Modelado UML, constituye la metodologa estndar ms utilizada
para el anlisis, diseo, implementacin y documentacin de sistemas
orientados a objetos. De este modelo nacen las metodologas de
Booch y de Rumbaug.

El RUP tiene tres caractersticas esenciales:

1. Proceso dirigido por Casos de Uso.
2. Proceso centrado en la arquitectura.
3. Proceso iterativo e incremental.
 55
1. Proceso dirigido por Casos de Uso
Son una tcnica de captura de requisitos que fuerza a
pensar en trminos de importancia para el usuario y no
slo en trminos de funciones que sera bueno
contemplar.
 56
2. Proceso centrado en la arquitectura.
Es la organizacin o estructura de sus partes ms relevantes, lo que permite
tener una visin comn entre todos los involucrados (desarrolladores y
usuarios) y una perspectiva clara del sistema completo, necesaria para
controlar el desarrollo.
La arquitectura involucra los aspectos estticos y dinmicos ms
significativos del sistema, est relacionada con la toma de decisiones que
indican cmo tiene que ser construido el sistema y ayuda a determinar en
qu orden.
3. Proceso iterativo e incremental.
Se propone en tener un proceso iterativo e incremental en donde el trabajo
se divide en partes ms pequeas o mini proyectos. Permitiendo que el
equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada
mini proyecto, as durante todo el proceso de desarrollo.
57
 DRA (Desarrollo Rpido de 58
Aplicaciones)
Es un proceso de desarrollo de software, desarrollado inicialmente por
James Martin en 1980. El mtodo comprende el desarrollo iterativo, la
construccin de prototipos y el uso de utilidades CASE.
Tradicionalmente, el desarrollo rpido de aplicaciones tiende a
englobar tambin la usabilidad, utilidad y la rapidez de ejecucin.

Generalmente es un modelo de proceso del desarrollo del software

lineal secuencial que enfatiza un ciclo de desarrollo extremada
mente corto. DRA es una adaptacin a "Alta velocidad" en el que se
logra el desarrollo rpido utilizando un enfoque de construccin
basado en componentes.
 59
El enfoque DRA comprende las siguientes fases:
Modelado de gestin: Responde a las preguntas: Qu informacin conduce
el proceso de gestin? Qu informacin se genera? Quin la genera? A
dnde va la informacin? Quin la proceso?
Modelado de datos: Se definen las caractersticas (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
Modelado de proceso. Las descripciones del proceso se crean para aadir,
modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre
los objetos.
Generacin de aplicaciones. El DRA asume la utilizacin de tcnicas de
programacin de cuarta generacin.
Pruebas de entrega. El DRA enfatiza la reutilizacin, ya se han comprobado
muchos de los componentes de los programas.
60
 Modelo de Desarrollo Iterativo e 61
Incremental
Consiste en la iteracin (repeticin) de varios ciclos de vida en cascada. Al final
de cada iteracin se entrega una versin mejorada. Este modelo se utiliza
cuando no se puede especificar a priori todos los requisitos del software, sino
que el proceso ayudar a ir descubriendo paso a paso los requisitos a partir de
cada nueva Entrega.
 62
Esta idea es la base de varios mtodos de desarrollo de software como RUP
(Rational Unified Process), Extreme Programming y otros mtodos de
desarrollo giles.
La idea bsica es desarrollar el sistema siguiendo etapas incrementales
caracterizadas por generacin de sucesivas versiones que van abarcando
requerimientos hasta completar el sistema.
Cada versin tiene sentido para el cliente.

Iterativo: Cada vez re-visitamos las etapas del modelo en cascada, rehacemos,
refinamos y extendemos lo hecho.

Incremental: Regularmente integramos los avances para generar una versin

con sentido para el cliente.
 63
El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que
se muestran a los usuarios y clientes. En el ciclo de vida iterativo, en cada
iteracin se reproduce el ciclo de vida en cascada a menor escala. Los
objetivos de una iteracin se establecen en funcin de la evaluacin de las
iteraciones precedentes.

Anlisis

Diseo N"
veces
N"
veces Codificacin

Pruebas e Integracin
 64
Las iteraciones se pueden entender
como miniproyectos: en todas las
iteraciones se repite un proceso de
trabajo similar (de ah el nombre
iterativo) para proporcionar un
resultado completo sobre producto final,
de manera que el cliente pueda obtener
los beneficios del proyecto de forma
incremental.
Un aspecto fundamental para guiar el
desarrollo iterativo e incremental es la
priorizacin de los objetivos/requisitos en
funcin del valor que aportan al cliente.