Este documento presenta una introducción a la asignatura de Ingeniería de Software I. Explica que el objetivo es que los alumnos aprendan a modelar sistemas de información usando metodologías, técnicas y herramientas. Luego, describe las unidades temáticas que incluyen metodologías de desarrollo de software, administración de requerimientos, modelado con UML, y bibliografía. Finalmente, detalla la forma de evaluación del curso.

1. Ingeniería de Software I
DOCENTE:
ING. JOSÉ DENYS HERNÁNDEZ ESPINOZA
1

2. Objetivo de la Asignatura
El alumno elaborará el modelado de un sistema de información
empleando metodologías, técnicas y herramientas para construir
una propuesta de solución a un problema determinado.
2

3. Unidades Temáticas
1. Metodologías de desarrollo de software.
• Clasificación.
• Ventajas y desventajas.
2. Administración de requerimientos.
• Estudio de factibilidad.
• Obtención y análisis de requerimientos.
• Especificación de requerimientos.
• Validación de requerimientos.
3. Análisis y modelado de desarrollo de software con UML.
• Introducción al UML (Lenguaje Unificado de Modelado (UML, en inglés, Unified Modeling Language).
• Diagramas de Casos de uso.
• Diagramas de Clases.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
• Diagrama de Estado.
3Temario

4. 4
Autor Año Título del Documento Ciudad País Editorial
Booch G., Rumbaugh
J., Jacobson I.
(2000) El Lenguaje Unificado de
Modelado. Manual de Referencia.
Madrid España Addison Wesley,
Booch G., Rumbaugh
J., Jacobson I.
(2000) El Lenguaje Unificado de
Modelado. Guía del Usuario
Madrid España Addison Wesley
Pressman, Roge S (2002) Ingeniería del software. Un
enfoque práctico
Madrid España McGraw Hill
Sommerville, Ian. (2005) Ingeniería del Software. Madrid España Addison Wesley.
Bibliografía

5. 5
Practicas/Exposición 20%
Examen 40%
Tareas 30%
Asistencia 10%
100%
Evaluación
Las actividades se mandarán por email usando:
- Asunto: Usar la nomenclatura según la actividad que esta anexando al email.
- Cuerpo del email ó Mensaje: Solo poner su nombre completo o algún otro dato relevante que desee.
- Solo se aceptarán usando la nomenclatura establecida para tal, y al email jodesite88@Hotmail.com
Reglas para hacer válidas 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 títulos serán Arial tamaño 14 en negritas y el Contenido Arial tamaño 12.
- Usar interlineado de 1.5 de espacio.
- El documento deberá tener: Portada, Índice, Contenido, Conclusiones y Bibliografía.

6. 6Evaluación
Nomenclatura para nombrar las actividades a realizar:
- Nombrar las Tareas de la siguiente forma: T_Matrícula-Grupo
- Nombrar las Prácticas de la siguiente forma: P_Matrícula-Grupo
En las Exposiciones:
- Crear material para 10 minutos como mínimo y 15 como máximo.
- Deberán participar y estar presentes todos los integrantes de equipo.
- Deberá tener una estructura y diseño gráfico apropiado al tema a ser presentado.
- Deberán tener una carga de información por diapositiva apropiada de forma que tengan valor didáctico, se recomienda
de 6 a 10 renglones y un tamaño de letra de 20 puntos como mínimo, tipografía clara o entendible y podrán apoyarse de
gráficos bajados de Internet como, Tablas, Imágenes, Fotos, etc.
NOTA: La falta u omisión de alguno de los aspectos de Evaluación repercutirá en puntos menos en su
calificación final.

7. UNIDAD 1.
Metodología del Desarrollo
de Software.
INTRODUCCIÓN RÁPIDA.
7

8. Concepto de Ingeniería de Sistemas
 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 informáticos están compuestos por ordenadores y sus periféricos. 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 informáticos es el tratamiento de la información:
almacenamiento, elaboración y presentación de datos. De esta forma se automatizan
determinadas acciones.
 En la concepción del sistema informático no solo se decide el trabajo a realizar, sino
también cómo ha de ser utilizado por los usuarios.
8

9.  Características del software (lo contrario para el hardware):
 No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales.
 Su duplicación es poco costosa, lo caro es el desarrollo.
 Puede ser modificado fácilmente, tanto que es necesario un control de versiones.
 La Ingeniería del Software comprende las técnicas y procedimientos ingenieriles para el desarrollo
del software. La Ingeniería del Software no se plantea solo una actividad de programación,
previamente son necesarias las fases de análisis y diseño y posteriormente la integración y la
verificación, incluso el manteniendo cuando el producto ya está en explotación. (CICLO DE VIDA).
 Inicialmente la tarea de desarrollo era realizada individualmente por hábiles creativos, de forma
poco disciplinada. El trabajo en equipo supone la división y organización del trabajo utilizando
metodologías 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 “Ingeniería de Software
Asistida e Integrada por Computadora”).
9
Concepto de Ingeniería de Sistemas

10. La crisis del Software
 Se produce cuando surge la necesidad de desarrollar aplicaciones software demasiado
complejas, a mediados de los 60.
 Para superar la crisis:
 Aparición de metodologías concretas de desarrollo.
 Concepción de la definición de la Ingeniería del Software como disciplina.
 Trabajo en equipo y especialización (analistas, programadores, depuradores).
 No se ha llegado a una situación estable, sino a una evolución permanente con avances
continuos en la Ingeniería del Software, forzados por el rápido abaratamiento y aumento
de capacidad del hardware.
10

11. Mitos del Software
 El hardware es mucho más importante que el software.
 El software es fácil de desarrollarse y modificarse.
 El software consiste exclusivamente en programas ejecutables.
 El desarrollo del software es sólo una labor de programación.
 Es natural que el software contenga errores.
 El software no necesita de validaciones.
 Se hace software por hacer sin requerimientos ni especificaciones del cliente.
11

12. Mantenimiento del software
El mantenimiento no representa una actividad específica, sino que consiste en rehacer
parte de las actividades correspondientes a las otras fases del desarrollo para introducir
cambios sobre una aplicación ya en fase de explotación.
 MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron
detectados en el desarrollo del producto.
 MANTENIMIENTO ADAPTATIVO, modificar una aplicación para adaptarla a las nuevas
necesidades del entorno.
 MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del
producto.
12

13. Gestión de cambios
 El mantenimiento supone la realización 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 solución dada al problema y el cambio realizado.
REINGENIERÍA, es necesaria cuando el desarrollo de una aplicación no está documentado y se
dispone solamente del código. Se llama también ingeniería inversa porque supone reconstruir y
documentar las fases de análisis y diseño llegando a la estructura modular de la aplicación y las
dependencias entre módulos y funciones. Estas actividades organizan y documentan un
sistema deficiente.
13

14. Garantía de calidad
Para evaluar la calidad son necesarias técnicas de aplicación de métricas precisas tanto sobre los productos software como a sus
procesos de desarrollo. McCall propone un esquema basado en valoraciones a 3 niveles:
 FACTORES, valoración significativa de la calidad en base a los criterios establecidos.
 CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad.
 MÉTRICAS, mediciones puntuales de determinadas características del producto.
Entre los factores de calidad tenemos:
 CORRECCIÓN, grado en que cumple con las especificaciones.
 FIABILIDAD, grado de ausencia de fallos.
 EFICIENCIA, relación 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 aplicación.
 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 corrección 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.
14

15. Plan de Garantía de Calidad de Software
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:
 Organización, dirección y seguimiento de los equipos de desarrollo.
 Modelo de ciclo de vida a seguir, detallando fases y actividades.
 Documentación requerida, determinando contenido y guión de cada documento.
 Revisiones y auditorias, para garantizar que las actividades y los documentos son
correctos.
 Organización de las pruebas, a distintos niveles.
 Organización de la etapa de mantenimiento, determinando cómo gestionar la
realización de cambios.
15

16. Revisiones del Software
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 producción.
 Se debe establecer de antemano una lista formal de comprobaciones.
 Se debe levantar acta de la reunión de revisión, recogiendo las decisiones tomadas.
16

17. Pruebas del Software
 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.
17

18. ¿Qué es la Ingeniería del Software? 18
Pruebas del Software
Consiste en hacer funcionar el
producto o una parte de él y
comprobar si los resultados
son correctos.
Revisiones del Software
Inspeccionar el resultado de
una actividad para determinar
si es aceptable o contiene
defectos
Plan de Garantía de Calidad
de Software
documento formal para
organizar el proceso de
desarrollo software de manera
que se asegure la calidad del
producto final
Garantía de calidad
Evaluar la calidad son necesarias técnicas
Gestión de cambios
Reingeniería
Mantenimiento del software
Correctivo, Adaptativo, Perfectivo
Mitos del Software
El hardware es mucho más importante que el software.
La crisis del Software
Surge la necesidad de desarrollar
aplicaciones software demasiado
complejas

19. ¿Qué es la Ingeniería del Software?
Podemos definir a la Ingeniería del Software como la aplicación práctica del conocimiento científico en el
diseño y construcción de programas de computadora y la documentación asociada requerida para
desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo de software o producción
de software.
Entonces, la Ingeniería del Software implica un trabajo integral, es decir, se produce un análisis del contexto,
se diseña el proyecto, se desarrolla el correspondiente software, se efectúan 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:
 Concepción (en esta se fijan los objetivos y se desarrolla el modelo).
 Elaboración (en este paso se establecen las características y cómo será la arquitectura del mismo y
porqué).
 Construcción (implica el desarrollo del programa).
 Transición (es el momento en el cual se transfiere el producto final al usuario).
19

20. UNIDAD 1. Metodología del
Desarrollo de Software.
1.1. CLASIFICACIÓN DE LAS
DIFERENTES METODOLOGÍAS.
20

21. 21Metodologías de Desarrollo de Software:
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 Rápido de Aplicaciones).
Modelo de Desarrollo Iterativo e Incremental.

22. Desarrollo en Cascada 22
Es el enfoque metodológico 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 finalización de la etapa
anterior. Un ejemplo de una metodología de desarrollo en
cascada es:
1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.

23. 23

24. Desarrollo en Componentes 24
Permite reutilizar piezas de código preelaborado que permiten realizar diversas
tareas, conllevando a diversos beneficios como las mejoras a la calidad, la
reducción del ciclo de desarrollo y el mayor retorno sobre la inversión.
• “La reutilización de software es un proceso de la Ingeniería de Software que
conlleva al uso recurrente de activos de software en la especificación, análisis,
diseño, implementación y pruebas de una aplicación o sistema de software”.
• “Un componente es una unidad de composición 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. 25
En esencia, un componente es una pieza de código preelaborado que encapsula
alguna funcionalidad expuesta a través de interfaces estándar. 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
música que tenemos en nuestra casa.
Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente
con sus pares, las conexiones son estándar y el protocolo de comunicación está ya
preestablecido. Al unirse las partes, obtenemos música para nuestros oídos.

26. 26Características de un Componente:
• Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios que
permita su clasificación.
• Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la
función para la cual fue diseñado.
• Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro
componente que lo remplace y mejore.
• Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo
de su implementación.
• Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su
implementación sí.
• Bien Documentado: Un componente debe estar correctamente documentado para facilitar su
búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
• Es genérico: Sus servicios deben servir para varias aplicaciones.
• Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
• Independiente de la plataforma: Hardware, Software, S.O.

27. 27Gráfico del desarrollo de software basado en componentes

28. 28
Ventajas:
• Funcionalidad mejorada y sencilla para el usuario final.
• Reduce los costos y tiempos en su desarrollo y pruebas.
• Reutilización del software basado en sus módulos.
• 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 más cortos y por etapas.

29. 29
Desventajas:
• Genera mucho tiempo analizar riesgos de implementación 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 módulos
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 difícil si se
carece de ellos).

30. Modelo Evolutivo 30
Este enfoque entrelaza las actividades de especificación,
desarrollo y validación. Un sistema inicial se desarrolla
rápidamente a partir de especificaciones abstractas. Éste se
refina basándose en las peticiones del cliente para producir
un sistema que satisfaga sus necesidades.
El desarrollo evolutivo consta del desarrollo de una versión
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 especificación,
desarrollo y validación se entrelazan en vez de separarse.

31. 31
Existen dos tipos de desarrollo evolutivo:
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 definición 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. 32
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer
más ventajas en comparación 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 ingeniería y gestión 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 rápidamente, no es
rentable producir documentos que reflejen cada versión 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 más en una tarea difícil y costosa.

33. 33

34. Modelo Incremental 34
Es una unión 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 iteración del proceso anterior pero aplicando las
experiencias aprendidas del proceso anterior. A diferencia del modelo de
prototipos, los prototipos de este modelo están orientados a ser
operacionales en cada incremento y no ser solo una “previa” de cómo sería
el sistema en su versión final. En una visión genérica, el proceso se divide en
4 partes:
• Análisis
• Diseño
• Código
• Prueba

35. 35
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la
filosofía interactiva de Construcción 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 núcleo.

36. 36
El modelo incremental
combina elementos del
modelo en cascada con la
filosofía interactiva de
construcción de
prototipos. Se basa en la
filosofía 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.

37. 37
Ventajas:
• 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 sólo al ámbito de cada incremento.
• Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
• Es más fácil probar y depurar en una iteración más pequeña.

38. 38
Desventajas:
• 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 planeación, tanto administrativa como técnica.
• 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

39. 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
iteración (repetición) 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 próxima versión es cada vez mayor.
Cada división recibe el nombre de región de tareas.
Aunque el modelo espiral representa ventajas por sobre el desarrollo
lineal, el cálculo de los riesgos puede ser muy complicado y no es tan
usado en la realidad.

40. 40
El Modelo en Espiral se divide en un número de actividades estructurales, también llamadas "regiones
de tareas" . Generalmente existen seis regiones de tareas:
Comunicación con el cliente.- Las tareas requeridas para establecer comunicación entre el
desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.
Planificación.- Las tareas requeridas para definir recursos, tiempos e información relacionada con el
proyecto.
Análisis de riesgos.- Las tareas requeridas para evaluar riesgos técnicos y de gestión.
Ingeniería.- Las tareas requeridas para construir una o más representaciones de la aplicación
Construcción y adaptación.- Las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.
Evaluación del cliente.- Las tareas requeridas para obtener la reacción del cliente, según la
evaluación de las representaciones del software creadas durante la etapa de ingeniería e
implementada durante la etapa de instalación.

41. 41

42. Modelo en Espiral (Win/Win) 42
Basado en el Modelo Espiral clásico que sugiere la comunicación con el cliente
para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él
proporciona la información para continuar, sin embargo, esta es una situación que
rara vez ocurre. Normalmente el cliente y desarrollador entran en una negociación,
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
también gane consiguiendo presupuesto y fecha de entrega realista.
Evidentemente, este modelo requiere fuertes habilidades de negociación.

43. 43
Cada ciclo envuelve cuatro actividades principales:
• Elaboración 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 número de fuentes de producto y
Riesgos posibles.
• Elaboración de la definición del producto y del proceso.
• Planificación del próximo ciclo y actualización de la planificación.
Del ciclo de vida. Ello incluye, si es necesario, el
Particionamiento del sistema en subsistemas a desplegarse en
Paralelo. Puede incluir, además, la definición de un plan para
Finalizar el proyecto si éste es de riesgo demasiado alto o no es
Factible.

44. 44

45. Modelo en “V” (Cuatro Niveles) 45
Define un procedimiento uniforme para el desarrollo de productos para las
Tecnologías y la Información.
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 reducción de tiempo de cada fase y
mientras mas se reduce aumenta el nivel, esto puede ser prácticamente una
ventaja o desventaja dependiendo del modo de trabajo de cada persona ya
que para algunas personas puede ser benéfico trabajar con dos procesos a la
vez o puede ser mas complicado.

46. 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 especificación consiste principalmente de:
1. Especificaciones de requerimiento de usuario.
2. Especificaciones funcionales.
3. Especificaciones de diseño.

47. 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 análisis de
requisitos y especificaciones, se traduce en un
documento de requisitos y especificaciones.
2.El nivel 2 se dedica a las características 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 análisis 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 implementación, en la que se
desarrollan los elementos unitarios o módulos del
programa.

48. Modelo en Prototipos 48
Este permite que todo el sistema, o algunas de sus partes, se construyan
rápidamente para comprender con facilidad y aclarar ciertos aspectos en los
que se aseguren que el desarrollador, el usuario y el cliente estén de acuerdo
en lo que se necesita así como también la solución 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 diseños 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. 49
Las etapas del modelo son:
• Investigación preliminar.
• Colecta y refinamiento de los requerimientos y proyecto rápido.
• Análisis y especificación del prototipo.
• Diseño y construcción del prototipo.
• Evaluación del prototipo por el cliente.
• Renacimiento del prototipo.
• Diseño técnico.
• Programación y test.
• Operación y mantenimiento.

50. 50
Producto de
ingeniería
(Paso 6)
Diseño rápido
(Paso 2)
Refinamiento del
prototipo
(Paso 5)
Evaluación del prototipo
por el cliente
(Paso 4)
Construcción del
prototipo
(Paso 3)
Recolección y
refinamiento de
requisitos
(Paso 1) Cada realización de un Prototipo
requiere una revisión que se puede ir
intercalando (con otras etapas del
desarrollo) conforme se vaya avanzando
en la entrega de los requisitos
solicitados.

51. Modelo de Desarrollo Concurrente 51
Este modelo define una serie de acontecimientos que dispararán transiciones
de estado a estado para cada una de las actividades. Durante las primeras
etapas del diseño, no se contempla una inconsistencia del modelo de análisis.
Esto genera la corrección del modelo de análisis de sucesos, que disparará la
actividad de análisis 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 división de
sistemas y una división de componentes.

52. 52
Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y
realización. La concurrencia se logra de dos formas:
• Las actividades del sistema y de componente ocurren simultáneamente y pueden
modelarse con el enfoque orientado a objetos descrito anteriormente.
• Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno
de los cuales se pueden diseñar 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 señaladas no es aplicable.
• Si no existen grupos de trabajo no se puede trabajar en este método

53. 53
La imagen proporciona una representación
esquemática de una actividad (análisis)
como se puede observar todas las
actividades existen concurrentemente, pero
residen en estados diferentes , al principio
es la comunicación con el cliente (no esta
plasmada en la figura) y esta en estado de
cambios en espera. La actividad de análisis
esta en ninguna significa que ya se ha
hecho la comunicación con el cliente luego
hace una transición al estado bajo
desarrollo. sin embargo si el cliente indica
que se deben hacer cambios en requisitos ,
la actividad de análisis cambia del estado
bajo desarrollo al estado cambios en
espera.

54. RUP (Proceso Unificado de Rational) 54
Es un proceso de desarrollo de software desarrollado por la empresa Rational
Software, gracias a la colaboración de Grady Booch, actualmente es
propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML,
constituye la metodología estándar más utilizada para el análisis, diseño,
implementación y documentación de sistemas orientados a objetos. De este
modelo nacen las metodologías de Booch y de Rumbaug.
El RUP tiene tres características esenciales:
1. Proceso dirigido por Casos de Uso.
2. Proceso centrado en la arquitectura.
3. Proceso iterativo e incremental.

55. 55
1. Proceso dirigido por Casos de Uso
Son una técnica de captura de requisitos que fuerza a pensar en
términos de importancia para el usuario y no sólo en términos
de funciones que sería bueno contemplar.

56. 56
2. Proceso centrado en la arquitectura.
Es la organización o estructura de sus partes más relevantes, lo que permite tener
una visión común entre todos los involucrados (desarrolladores y usuarios) y una
perspectiva clara del sistema completo, necesaria para controlar el desarrollo.
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del
sistema, está relacionada con la toma de decisiones que indican cómo 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 más pequeñas 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. 57

58. DRA (Desarrollo Rápido de
Aplicaciones)
58
Es un proceso de desarrollo de software, desarrollado inicialmente por James
Martin en 1980. El método comprende el desarrollo iterativo, la construcción
de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo
rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la
rapidez de ejecución.
Generalmente es un modelo de proceso del desarrollo del software lineal
secuencial que enfatiza un ciclo de desarrollo extremada mente corto. DRA es
una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido
utilizando un enfoque de construcción basado en componentes.

59. 59
El enfoque DRA comprende las siguientes fases:
• Modelado de gestión: Responde a las preguntas: ¿Qué información conduce el
proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la
información? ¿Quién la proceso?
• Modelado de datos: Se definen las características (llamadas atributos) de cada uno de
los objetos y las relaciones entre estos objetos.
• Modelado de proceso. Las descripciones del proceso se crean para añadir, modificar,
suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones. El DRA asume la utilización de técnicas de programación
de cuarta generación.
• Pruebas de entrega. El DRA enfatiza la reutilización, ya se han comprobado muchos
de los componentes de los programas.

60. 60

61. Modelo de Desarrollo Iterativo e Incremental 61
Consiste en la iteración (repetición) de varios ciclos de vida en cascada. Al final de cada
iteración se entrega una versión 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. 62
 Esta idea es la base de varios métodos de desarrollo de software como RUP (Rational
Unified Process), Extreme Programming y otros métodos de desarrollo ágiles.
 La idea básica es desarrollar el sistema siguiendo etapas incrementales caracterizadas
por generación de sucesivas versiones que van abarcando requerimientos hasta
completar el sistema.
 Cada versión 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 versión con
sentido para el cliente.

63. 63
El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se
muestran a los usuarios y clientes. En el ciclo de vida iterativo, en cada iteración se
reproduce el ciclo de vida en cascada a menor escala. Los objetivos de una iteración se
establecen en función de la evaluación de las iteraciones precedentes.
Análisis
Diseño
Codificación
Pruebas e Integración
“N"
veces
“N"
veces

64. 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
priorización de los objetivos/requisitos en
función del valor que aportan al cliente.