Unidad 2

PROCESOS DEL
SOFTWARE

Introducción
2

— Un proceso del software es un conjunto de actividades

que conducen a la creación de un producto software.

— Estas actividades pueden consistir en el desarrollo de

software desde cero en un lenguaje de programación
estándar como Java o C.

— Sin embargo, cada vez más, se desarrolla nuevo software

ampliando y modificando los sistemas existentes y
configurando e integrando software comercial o
componentes del sistema.
Prof. John W. Castro

1
 Introducción
3

— Los procesos del software son complejos y, como todos los

procesos intelectuales y creativos, dependen de las personas
que toman decisiones y juicios.
— Debido a la necesidad de juzgar y crear, los intentos para
automatizar estos procesos han tenido un éxito limitado.
— Las herramientas de ingeniería del software asistida por
computadora (CASE) pueden ayudar a algunas actividades
del proceso.
— Sin embargo, no existe posibilidad alguna, al menos en los
próximos años, de una automatización mayor en el diseño
creativo del software realizado por los ingenieros
relacionados con el proceso del software.
Prof. John W. Castro

Introducción
4

— Una razón por la cual la eficacia de las herramientas

CASE está limitada se halla en la inmensa diversidad de
procesos del software.
— No existe un proceso ideal, y muchas organizaciones
han desarrollado su propio enfoque para el desarrollo
del software.

Prof. John W. Castro

2
 Introducción
5

— Los procesos han evolucionado para explotar:

¡ Las capacidades de las personas de una organización

¡ Las características específicas de los sistemas que se están

desarrollando.

— Para algunos sistemas, como los sistemas críticos, se

requiere un proceso de desarrollo muy estructurado.

— Para sistemas de negocio, con requisitos rápidamente

cambiantes, un proceso flexible y ágil probablemente
sea más efectivo.

Prof. John W. Castro

Introducción
6

— Aunque existen muchos procesos diferentes de software,

algunas actividades fundamentales son comunes para
todos ellos:
¡ Especificación del software. Se debe definir la funcionalidad del
software y las restricciones en su operación.
¡ Diseño e implementación del software. Se debe producir software
que cumpla su especificación.
¡ Validación del software. Se debe validar el software para asegurar
que hace lo que el cliente desea.
¡ Evolución del software. El software debe evolucionar para cubrir
las necesidades cambiantes del cliente.

Prof. John W. Castro

3
 Introducción
7

— Aunque no existe un proceso del software “ideal”, en las

organizaciones existen enfoques para mejorarlos.
— Los procesos pueden incluir técnicas anticuadas o no
aprovecharse de las mejores prácticas en la ingeniería
del software industrial.
— De hecho, muchas organizaciones aún no aprovechan
los métodos de la ingeniería del software en el desarrollo
de su software.

Prof. John W. Castro

Introducción
8

— Los procesos del software se pueden mejorar por la

estandarización del proceso donde la diversidad de los
procesos del software en una organización sea
reducida.

— Esto conduce a mejorar la comunicación y a una

reducción del tiempo de formación.

— La estandarización también es un primer paso

importante para introducir nuevos métodos, técnicas y
buenas prácticas de ingeniería del software.
Prof. John W. Castro

4
 Introducción
9

— Cualquier proceso tiene la siguientes características:

¡ El proceso establece todas las actividades principales.
¡ El proceso utiliza recursos, está sujeto a una serie de restricciones y genera
productos intermedios y finales.
¡ El proceso puede estar compuesto de subprocesos que se encadenan de
alguna manera. Puede definirse como una jerarquía de procesos
organizada de modo que cada subproceso tenga su propio modelo de
proceso.
¡ Cada actividad del proceso tiene criterios de entrada y de salida, de modo
que se conoce cuándo comienza y cuándo termina una actividad.
¡ Las actividades se organizan en secuencia de modo que resulta claro
cuando una actividad se realiza en orden relativo a otras actividades.
¡ Todo proceso tiene un conjunto de principios orientadores que explican
las metas de cada actividad.
¡ Las restricciones o controles pueden aplicarse a una actividad, recurso o
Prof. Johnproducto.
W. Castro

Introducción
10

— Otras características que van a definir un proceso son:

¡ Comprensión: Está definido y es comprensible.
¡ Visibilidad: Se visualizan los progresos externamente.
¡ Soporte: Está soportado por herramientas CASE.
¡ Aceptación: Es aceptable para todos los actores implicados.
¡ Confianza: Los errores del proceso se detectan antes de que se produzcan
errores en el producto.
¡ Robustez: Se puede continuar a pesar de problemas inesperados.
¡ Capacidad de mantenimiento: Puede ajustarse a las necesidades de
cambio de la organización.
¡ Rapidez: Con qué “velocidad” se producen los sistemas.
¡ Adaptación: Capacidad que tiene un usuario del mismo de adaptarlo a sus
necesidades.

Prof. John W. Castro

10

5
 Introducción
11

La importancia del proceso en el desarrollo del software.

— Un proceso software debe especificar:
¡ La secuencia de actividades a realizar por el equipo de desarrollo.
÷ Flujo del proceso, donde se describe la manera en que están
organizadas las actividades estructurales y las acciones y tareas que
ocurren dentro de cada una con respecto a la secuencia y el tiempo.
¢ Un flujo de proceso lineal ejecuta cada una de las cinco
actividades estructurales en secuencia, comenzando por la
comunicación y terminando con el despliegue.

Fuente: Pressman 2010

Prof. John W. Castro

11

Introducción
12

La importancia del proceso en el desarrollo del software.

— Un proceso software debe especificar:
¡ La secuencia de actividades a realizar por el equipo de desarrollo.
¢ Un flujo de proceso iterativo repite una o más de las actividades antes de
pasar a la siguiente.

Fuente: Pressman 2010

¢ Un flujo de proceso evolutivo realiza las actividades en forma “circular”. A

través de las cinco actividades, cada circuito lleva a una versión más completa
del software.

Fuente:
Prof. John W. Castro Pressman 2010

12

6
 Introducción
13

La importancia del proceso en el desarrollo del software.

— Un proceso software debe especificar:
¡ La secuencia de actividades a realizar por el equipo de desarrollo.
¢ Un flujo de proceso paralelo ejecuta una o más actividades en paralelo con
otras:
• Por ejemplo, el modelado de un aspecto del software tal vez se ejecute en paralelo
con la construcción de otro aspecto del software.

Prof. John W. Castro Fuente: Pressman 2010

13

Introducción
14

La importancia del proceso en el desarrollo del software.

— Un proceso software debe especificar:
¡ Los productos que deben crearse.
÷ Resultados del trabajo (modelos, documentos, datos, informes, ...).
÷ Qué y cuándo.

¡ La asignación de tareas a cada miembro del equipo y al equipo como

un todo.

¡ Los criterios para controlar el proceso.

÷ Se establece el control de gestión de los proyectos software.
÷ Establecimiento de hitos

Prof. John W. Castro

14

7
 Introducción
15

La importancia del proceso en el desarrollo del software

— Facilita la gestión del proyecto.
— Establece una división del trabajo.
— Facilita la comunicación de los miembros del equipo.
— Permite la reasignación y la reutilización de personal especializado.
¡ Transferencia entre proyectos.
— Mejora la productividad y el desarrollo.
¡ El desarrollo es reproducible.
— Establece el contexto en el que se aplican los métodos técnicos.
— Gestiona el cambio adecuadamente.
— Asegura la calidad.

Prof. John W. Castro

15

Modelos del Proceso del Software

16

— Un modelo del proceso del software es una

representación abstracta de un proceso del software.
— Cada modelo de proceso representa un proceso desde
una perspectiva particular, y así proporciona sólo
información parcial sobre ese proceso.
— Los modelos de proceso genéricos, también llamados
paradigmas de proceso:
¡ Presentan un proceso desde una perspectiva arquitectónica, es
decir, ofrecen un marco de trabajo del proceso, pero no los detalles
de las actividades específicas.
¡ No son descripciones definitivas de los procesos del software, más
bien, son abstracciones que se pueden utilizar para explicar
diferentes enfoques para el desarrollo del software.
Prof. John W. Castro

16

8
 Modelos del Proceso del Software
17

Razones para modelar un proceso:

— Cuando se pone por escrito una descripción de un

proceso, se da forma a una comprensión común de las
actividades, recursos y restricciones relacionados con el
desarrollo del software.

— Ayuda al equipo de desarrollo a encontrar las

inconsistencias, las redundancias y las omisiones en el
proceso y en las partes que lo constituyen.

Prof. John W. Castro

17

Modelos del Proceso del Software

18

Razones para modelar un proceso:

— El modelo debe reflejar las metas del desarrollo. A

medida que se construye el modelo el equipo de
desarrollo evalúa las actividades candidatas por su
adecuación para alcanzar dichas metas.
— Ayuda al equipo de desarrollo a comprender dónde
debe adaptarse el proceso.
— Los modelos de proceso de desarrollo de software
incluyen los requisitos del sistema como entrada y un
producto entregado como salida.
Prof. John W. Castro

18

9
 Modelos del Proceso del Software
19

Tipos de Modelos de Proceso

— Modelos de Procesos lineales o secuenciales
¡ Modelo primitivo
¡ Modelo clásico o en cascada
¡ Modelo V
— Modelos de Procesos Evolutivos
¡ Desarrollo evolutivo
¡ Modelos basados en prototipos
¡ Modelo incremental
¡ Modelo iterativo
¡ Modelo en espiral
— Modelos de Procesos Especializados
¡ Ingeniería del software basada en componentes
¡ Modelo de métodos formales
¡ Desarrollo
Prof. John W. Castro de software orientado a aspectos

19

Modelos del Proceso del Software

20

Modelos de Procesos lineales o secuenciales: han sido

ampliamente utilizados, porque:
¡ Ofrecen grandes facilidades a los gestores para controlar el progreso de los
proyectos.
¡ Proponen un enfoque sistemático, secuencial, para el desarrollo del
software.
¡ Comienza en un nivel de sistemas y progresa con el análisis, diseño,
codificación, pruebas y mantenimiento.
¡ Fases separadas en la especificación y el desarrollo.
— La filosofía de estos modelos de proceso no es realista:
¡ No se ajusta al proceso de desarrollo software.
¡ Raramente sigue un flujo secuencial sino que exige diversas iteraciones.
¡ No ofrece un soporte adecuado a las técnicas de desarrollo basadas en
objetos y componentes.
Prof. John W. Castro

20

10
 Modelos del Proceso del Software
21

Modelo Primitivo
— Se le conoce también con el nombre de Modelo Prueba y Error
o Modelo Codifica y Mejora.
— Proceso de desarrollo aplicado en las primeras experiencias de
programación.
— Supone una iteración de fases codificación-depuración sin
ninguna planificación ni diseños previos.
— No se ajusta al proceso de desarrollo software.
— Raramente sigue un flujo secuencial sino que exige diversas
iteraciones.
— No ofrece un soporte adecuado a las técnicas de desarrollo
basadas en objetos y componentes.
Prof. John W. Castro

21

Modelos del Proceso del Software

22

Modelo
Primitivo
Codificación

Prueba Empezar a Continuar

Final
codificar codificando

Comienza el proyecto Tiempo

Prof. John W. Castro

22

11
 Modelos del Proceso del Software
23

Modelo Primitivo
— Los inconvenientes de este modelo son:
¡ Código pobremente estructurado tras varias iteraciones.
÷ Código espagueti.
¡ Costoso de desarrollar por las numerosas recodificaciones.
¡ Posible rechazo del usuario al no existir análisis de
requisitos.
¡ Costoso de depurar por la falta de planificación.
¡ Costoso de mantener por la falta de estructura y
documentación.

Prof. John W. Castro

23

Modelos del Proceso del Software

24

Modelo Primitivo
— Qbasic2

Prof. John W. Castro

24

12
 Modelos del Proceso del Software
25

Modelo Primitivo

Prof. John W. Castro

25

Modelos del Proceso del Software

26

Modelo Clásico o en Cascada

— El primer modelo de proceso de desarrollo de software que se
publicó se derivó de procesos de ingeniería de sistemas más
generales.
— Debido a la cascada de una fase a otra, dicho modelo se conoce
como modelo en cascada o como ciclo de vida del software.
— Las principales etapas de este modelo se transforman en
actividades fundamentales de desarrollo:
¡ Análisis y definición de requisitos
¡ Diseño del sistema y del software
¡ Implementación y prueba de unidades
¡ Integración y prueba del sistema
¡ Funcionamiento y mantenimiento
Prof. John W. Castro

26

13
 Modelos del Proceso del Software
27

Modelo Clásico o en Cascada

— Análisis y definición de requisitos. Los servicios, restricciones y
metas del sistema se definen a partir de las consultas con los
usuarios. Entonces, se definen en detalle y sirven como una
especificación del sistema.
— Diseño del sistema y del software. El proceso de diseño del sistema
divide los requisitos en sistemas hardware o software. Establece
una arquitectura completa del sistema. El diseño del software
identifica y describe las abstracciones fundamentales del sistema
software y sus relaciones.
— Implementación y prueba de unidades. Durante esta etapa, el
diseño del software se lleva a cabo como un conjunto o unidades
de programas. La prueba de unidades implica verificar que cada
una cumpla su especificación.
Prof. John W. Castro

27

Modelos del Proceso del Software

28

Modelo Clásico o en Cascada

— Integración y prueba del sistema. Los programas o las unidades
individuales de programas se integran y prueban como un sistema
completo para asegurar que se cumplan los requisitos del software.
Después de las pruebas, el sistema software se entrega al cliente.
— Funcionamiento y mantenimiento. Por lo general (aunque no
necesariamente), ésta es la fase más larga del ciclo de vida. El
sistema se instala y se pone en funcionamiento práctico. El
mantenimiento implica corregir errores no descubiertos en las
etapas anteriores del ciclo de vida, mejorar la ¡implementación de
las unidades del sistema y resaltar los servicios del sistema una vez
que se descubren nuevos requisitos.

Prof. John W. Castro

28

14
 Modelos del Proceso del Software
29

Definición de
requisitos
Modelo
Diseño del sistema
clásico o
y del software en cascada

Implementación y
prueba de unidades

Integración y
prueba del sistema

Funcionamiento y
mantenimiento

Prof. John W. Castro Fuente: Sommerville 2010

29

Modelos del Proceso del Software

30

Modelo Clásico o en Cascada

— Asume secuencialidad y linealidad.

— En principio, el resultado de cada fase es uno o más documentos

aprobados (“firmados”).

— La siguiente fase no debe empezar hasta que la fase previa haya

finalizado.

— El proceso del software no es un modelo lineal simple, sino que

implica una serie de iteraciones de las actividades de desarrollo.

Prof. John W. Castro

30

15
 Modelos del Proceso del Software
31

Modelo Clásico o en Cascada

— Durante la fase final del ciclo de vida (funcionamiento y
mantenimiento), el software se pone en funcionamiento. En esta
fase:
¡ Se descubren errores y omisiones en los requisitos originales del
software.

¡ Los errores de programación y de diseño emergen y se identifica la

necesidad de una nueva funcionalidad.

¡ Por tanto, el sistema debe evolucionar para mantenerse útil.

¡ Hacer estos cambios (mantenimiento del software) puede implicar

repetir etapas previas del proceso.
Prof. John W. Castro

31

Modelos del Proceso del Software

32

Modelo Clásico o en Cascada

— La principal ventaja del modelo en cascada es que la
documentación se produce en cada fase.
— Su principal problema es su inflexibilidad al dividir el proyecto en
distintas etapas.

— Se deben hacer compromisos en las etapas iniciales, lo que hace

difícil responder a los cambios en los requisitos del cliente.

— Por lo tanto, el modelo en cascada sólo se debe utilizar cuando los

requisitos se comprendan bien y sea improbable que cambien
radicalmente durante el desarrollo del sistema.

Prof. John W. Castro

32

16
 Modelos del Proceso del Software
33

Modelo Clásico o en Cascada

— Sin embargo, el modelo refleja el tipo de modelo de proceso usado
en otros proyectos de ingeniería.

— Por consiguiente, los procesos del software que se basan en este

enfoque se siguen utilizando para el desarrollo de software,
particularmente cuando éste es parte de proyectos grandes de
ingeniería de sistemas.

Prof. John W. Castro

33

Modelos del Proceso del Software

34

Modelo en V
— Es una variación del modelo en cascada que demuestra cómo se
relacionan las actividades de prueba con las de análisis y
desarrollo.

— Presenta una implantación ascendente.

— Demuestra que el desarrollo de las pruebas se efectúa de manera

síncrona con el desarrollo del programa.

— Mientras que el modelo clásico centra su atención en los

documentos y artefactos producidos, el modelo en V lo hace en la
actividad y la exactitud.
Prof. John W. Castro

34

17
 Modelos del Proceso del Software
35

Modelo
en V

Prof. John W. Castro Fuente: Pressman 2010

35

Modelos del Proceso del Software

36

Modelo en V
— En la figura anterior se aprecia la relación entre las acciones para
el aseguramiento de la calidad y aquellas asociadas con la
comunicación, modelado y construcción temprana.
— A medida que el equipo de software avanza hacia abajo desde el
lado izquierdo de la V, los requisitos básicos del problema mejoran
hacia representaciones técnicas cada vez más detalladas del
problema y de su solución.
— Una vez que se ha generado el código, el equipo sube por el lado
derecho de la V, y en esencia ejecuta una serie de pruebas
(acciones para asegurar la calidad) que validan cada uno de los
modelos creados cuando el equipo fue hacia abajo por el lado
izquierdo.
Prof. John W. Castro

36

18
 Modelos del Proceso del Software
37

Tipos de Modelos de Proceso

— Modelos de Procesos lineales o secuenciales
¡ Modelo primitivo
¡ Modelo clásico o en cascada
¡ Modelo V
— Modelos de Procesos Evolutivos
¡ Desarrollo evolutivo
¡ Modelos basados en prototipos
¡ Modelo incremental
¡ Modelo iterativo
¡ Modelo en espiral
— Modelos de Procesos Especializados
¡ Ingeniería del software basada en componentes
¡ Modelo de métodos formales
¡ Desarrollo
Prof. John W. Castro de software orientado a aspectos

37

Modelos del Proceso del Software

38

Modelos de Procesos Evolutivos:

¡ El software, al igual que todos los sistemas complejos, evolucionan con
el tiempo.
¡ Se caracterizan porque permiten desarrollar versiones cada vez más
completas del software, teniendo en cuenta la naturaleza evolutiva del
software.
¡ Presentan la filosofía de poner un producto en explotación cuanto
antes.
÷ Están muy ligados a la idea de prototipado evolutivo.
¡ Existen muchos modelos de proceso evolutivos.

¡ Se caracterizan por la forma en que permiten a los ingenieros de

software desarrollar versiones cada vez más completas del producto
software, que puede ir entregándose al cliente en forma de
incrementos.
Prof. John W. Castro

38

19
 Modelos del Proceso del Software
39

Modelos de Procesos Evolutivos:

¡ Los desarrollos orientados a objetos se ajustan a un modelo de proceso
iterativo e incremental.
¡ Se puede argumentar lo mismo para los desarrollos basados en
componentes.
¡ Esto es así porque:
÷ Las tareas de cada fase se llevan a cabo de una forma iterativa. A la vez que
existe un ciclo de desarrollo análisis-diseño-implementación-análisis que
permite hacer evolucionar al sistema.
÷ En el desarrollo incremental el sistema se divide en un conjunto de particiones.
¢ Cada una se desarrolla de forma completa hasta que se finaliza el sistema.

¡ Esta idea de interactividad máxima propia

de la orientación a objetos ha sido
equiparada por autores como James
Rumbaugh (1992) o L.B.S. Raccoon (1995)
a la teoría del caos.
Prof. John W. Castro

39

Modelos del Proceso del Software

40

Desarrollo Evolutivo
— Se basa en la idea de desarrollar una implementación inicial,
exponiéndola a los comentarios del usuario y refinándola a
través de las diferentes versiones hasta que se desarrolla un
sistema adecuado.
Actividades
concurrentes

Especificación Versión inicial

Esbozo de la Versiones
Desarrollo intermedias
descripción

Validación Versión final

Prof. John W. Castro Fuente: Sommerville 2010

40

20
 Modelos del Proceso del Software
41

Desarrollo Evolutivo
— Las actividades de especificación, desarrollo y validación se
entrelazan en vez de separarse, con una rápida
retroalimentación entre éstas.

— Un sistema inicial se desarrolla rápidamente a partir de

especificaciones abstractas.

— Este sistema se refina basándose en las peticiones del cliente

para producir un sistema que satisfaga sus necesidades.

Prof. John W. Castro

41

Modelos del Proceso del Software

42

Desarrollo Evolutivo
— Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio: El objetivo del proceso es trabajar con el
cliente para explorar sus requisitos 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 requisitos del cliente y entonces
desarrollar una definición mejorada de los requisitos para el sistema.
El prototipo se centra en experimentar con los requisitos del cliente
que no se comprenden del todo.

Prof. John W. Castro

42

21
 Modelos del Proceso del Software
43

Desarrollo Evolutivo
— En la producción de sistemas, un enfoque evolutivo para el
desarrollo de software suele ser más efectivo que el enfoque en
cascada, ya que satisface las necesidades inmediatas de los
clientes.
— La ventaja de un proceso del software que se basa en un
enfoque evolutivo es que la especificación se puede desarrollar
de forma creciente.
— Tan pronto como los usuarios desarrollen un mejor
entendimiento de su problema, éste se puede reflejar en el
sistema software.
— Sin embargo, desde una perspectiva de ingeniería y de gestión,
el enfoque evolutivo tiene dos problemas:
Prof. John W. Castro

43

Modelos del Proceso del Software

44

Desarrollo Evolutivo
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.

— Para sistemas pequeños y de tamaño medio (hasta 500.000 líneas de

código), el enfoque evolutivo de desarrollo es el mejor.
— Los problemas del desarrollo evolutivo se hacen particularmente
agudos para sistemas grandes y complejos con un periodo de vida
largo, donde diferentes equipos desarrollan distintas partes del
sistema.
Prof. John W. Castro

44

22
 Modelos del Proceso del Software
45

Desarrollo Evolutivo
— Es difícil establecer una arquitectura del sistema estable usando este
enfoque, el cual hace difícil integrar las contribuciones de los equipos.
— Para sistemas grandes, se recomienda un proceso mixto que incorpore
las mejores características del modelo en cascada y del desarrollo
evolutivo.
— Esto puede implicar desarrollar un prototipo desechable utilizando un
enfoque evolutivo para resolver incertidumbres en la especificación del
sistema. Luego, puede re-implementarse utilizando un enfoque más
estructurado.
— Las partes del sistema bien comprendidas se pueden especificar y
desarrollar utilizando un proceso basado en el modelo en cascada.
— Las otras partes del sistema, como la interfaz de usuario, que son
difíciles de especificar por adelantado, se deben desarrollar siempre
utilizando un enfoque de programación exploratoria.
Prof. John W. Castro

45

Modelos del Proceso del Software

46

Modelos Basados en Prototipos

— Un prototipo es un modelo experimental de un sistema o de
un componente de un sistema que tiene los suficientes
elementos que permiten su uso.
— Es una solución parcial que describe la interacción entre el
hombre y la máquina, mostrando parte de su funcionalidad
no optimizada.
— Los modelos de proceso basados en prototipos presentan un
componente iterativo que facilita involucrar a los
clientes/usuarios en el desarrollo del software para ayudar a
estos a comprender los requisitos. Porque el cliente/usuario
no identifica los requisitos detallados para las funciones y
características.
Prof. John W. Castro

46

23
 Modelos del Proceso del Software
47

Modelos Basados en Prototipos

— En otros casos, el desarrollador tal vez no esté seguro de la:
¡ Eficiencia de un algoritmo
¡ Adaptabilidad de un sistema operativo
¡ Forma que debe adoptar la interacción entre el humano y la
máquina.
— En estas situaciones, y muchas otras, el paradigma de hacer
prototipos tal vez ofrezca el mejor enfoque.

Prof. John W. Castro

47

Modelos del Proceso del Software

48

Modelos Basados en Prototipos

— Aunque es posible hacer prototipos como un modelo de
proceso aislado, es más común usarlo como una técnica que
puede implementarse en el contexto de cualquiera de los
modelos de proceso ya estudiados anteriormente.

— Sin importar la manera en la que se aplique, el paradigma de

hacer prototipos le ayudará a usted y a otros participantes a
mejorar la comprensión de lo que hay que elaborar cuando los
requisitos no están claros.

Prof. John W. Castro

48

24
 Modelos del Proceso del Software
49
El
paradigma
de hacer
prototipos

Fuente: Pressman 2010

Prof. John W. Castro

49

Modelos del Proceso del Software

50

Modelos Basados en Prototipos

— El paradigma de hacer prototipos comienza con comunicación.
¡ Usted se reúne con otros participantes para:
÷ Definir los objetivos generales del software
÷ Identificar los requisitos y
÷ Detectar las áreas en las que es imprescindible una mayor definición.

— Se planea rápidamente una iteración para hacer el prototipo, y

se lleva a cabo el modelado (en forma de un “diseño rápido”).
¡ Éste se centra en la representación de aquellos aspectos del software
que serán visibles para los usuarios finales
÷ Por ejemplo, disposición de la interfaz de usuario o formatos de la pantalla
de salida.

Prof. John W. Castro

50

25
 Modelos del Proceso del Software
51

Modelos Basados en Prototipos

— El diseño rápido lleva a la construcción de un prototipo.
— Éste se entrega y es evaluado por los participantes, que dan
retroalimentación para mejorar los requisitos.
— La iteración ocurre a medida de que el prototipo es afinado para
satisfacer las necesidades de distintos participantes, y al mismo
tiempo le permite a usted entender mejor lo que se necesita hacer.
— El ideal es que el prototipo sirva como mecanismo para identificar los
requisitos del software.
— Si va a construirse un prototipo, pueden utilizarse fragmentos de
programas existentes o aplicar herramientas.
¡ Por ejemplo, generadores de reportes y administradores de ventanas que
permitan generar rápidamente programas que funcionen.

Prof. John W. Castro

51

Modelos del Proceso del Software

52

Modelos Basados en Prototipos

— El prototipo sirve como “el primer sistema”.
— Brooks recomienda desechar los prototipos. Pero esto quizá sea
un punto de vista idealizado.
— Aunque algunos prototipos se construyen para ser
“desechables”, otros son evolutivos; es decir, poco a poco se
transforman en el sistema real.

Prof. John W. Castro

52

26
 Modelos del Proceso del Software
53

Modelos Basados en Prototipos

— Diferentes enfoques en la utilización de los prototipos en el
ciclo de vida.
1. En el enfoque desechable, el propósito del prototipo es
validar algún aspecto del sistema, sirviendo, en este caso,
como herramienta auxiliar a la especificación de requisitos
y el diseño.
2. En el enfoque evolutivo, el prototipo se utiliza como
alternativa de ciclo de vida y es la base de los modelos de
proceso evolutivos.
3. En el enfoque mixto, conocido con el nombre de
prototipado operativo combina ambos tipos de prototipos.

Prof. John W. Castro

53

Modelos del Proceso del Software

54

Modelos Basados en Prototipos

— Tanto a los participantes como a los ingenieros de software les gusta el
paradigma de hacer prototipos.
— Los usuarios adquieren la sensación del sistema real, y los
desarrolladores logran construir algo de inmediato.
— No obstante, hacer prototipos llega a ser problemático por las siguientes
razones:
¡ El sistema se puede llegar a deteriorar tendiendo hacia el modelo primitivo.
¡ Tiende a la automatización y no a la innovación, ya que permite la automatización
de las tareas actuales.
¡ Se suele refinar el prototipo hacia el sistema final en lugar de desecharlo y
empezar desde el principio.
¡ El cliente puede encontrar atractivo el prototipo y quedarse con el prototipo como
sistema final.
¡ Relajación de los desarrolladores.
¡ Al usuario le desagrada que se deseche código.
Prof. John W. Castro

54

27
 Modelos del Proceso del Software
55

Modelos Basados en Prototipos

— Aunque puede haber problemas, hacer prototipos es un
paradigma eficaz para la ingeniería de software.

— La clave es definir desde el principio las reglas del juego; es

decir, todos los participantes deben estar de acuerdo en que el
prototipo sirva como el mecanismo para definir los requisitos.

— Después se descartará (al menos en parte) y se hará la

ingeniería del software real con la mirada puesta en la calidad.

Prof. John W. Castro

55

Modelos del Proceso del Software

56

Modelo Incremental
— Hay muchas situaciones en las que los requisitos iniciales del
software están razonablemente bien definidos, pero el alcance
general del esfuerzo de desarrollo imposibilita un proceso
lineal.
— Además, tal vez haya una necesidad imperiosa de dar
rápidamente cierta funcionalidad limitada de software a los
usuarios y aumentarla en las entregas posteriores de software.
— En tales casos, se elige un modelo de proceso diseñado para
producir el software en incrementos.
— El modelo incremental aplica secuencias lineales en forma
escalonada a medida que avanza el calendario de actividades.

Prof. John W. Castro

56

28
 Modelos del Proceso del Software
57

Modelo
incremental

Fuente: Pressman 2010

Prof. John W. Castro

57

Modelos del Proceso del Software

58

Modelo Incremental
— Cada secuencia lineal produce “incrementos” de software
susceptibles de entregarse de manera parecida a los
incrementos producidos en un flujo de proceso evolutivo.
¡ Por ejemplo, un software para procesar textos que se elabore con el
paradigma incremental quizá entregue en el primer incremento las
funciones básicas de administración de archivos, edición y
producción del documento; en el segundo dará herramientas más
sofisticadas de edición y producción de documentos; en el tercero
habrá separación de palabras y revisión de la ortografía; y en el
cuarto se proporcionará la capacidad para dar formato avanzado a las
páginas.
— Debe observarse que el flujo de proceso para cualquier
incremento puede incorporar el paradigma del prototipo.
Prof. John W. Castro

58

29
 Modelos del Proceso del Software
59

Modelo Incremental
— Cuando se utiliza un modelo incremental, es frecuente que el primer
incremento sea el producto fundamental.
— Es decir, se abordan los requisitos básicos, pero no se proporcionan
muchas características suplementarias (algunas conocidas y otras no).
— El cliente usa el producto fundamental (o lo somete a una evaluación
detallada).
— Como resultado del uso y/o evaluación, se desarrolla un plan para el
incremento que sigue.
— El plan incluye la modificación del producto fundamental para cumplir
mejor las necesidades del cliente, así como la entrega de características
adicionales y más funcionalidad.
— Este proceso se repite después de entregar cada incremento, hasta
terminar el producto final.
Prof. John W. Castro

59

Modelos del Proceso del Software

60

Modelo Incremental
— El modelo de proceso incremental se centra en que en cada
incremento se entrega un producto que ya opera.
— Los primeros incrementos son versiones desnudas del producto
final, pero proporcionan capacidad que sirve al usuario y
también le dan una plataforma de evaluación.
— El desarrollo incremental es útil en particular cuando no se
dispone de personal para la implementación completa del
proyecto en el plazo establecido por el negocio.
— Los primeros incrementos se desarrollan con pocos
trabajadores.

Prof. John W. Castro

60

30
 Modelos del Proceso del Software
61

Modelo Incremental
— Si el producto básico es bien recibido, entonces se agrega más
personal (si se requiere) para que labore en el siguiente
incremento.
— Además, los incrementos se planean para administrar riesgos
técnicos.
¡ Por ejemplo, un sistema grande tal vez requiera que se disponga de
hardware nuevo que se encuentre en desarrollo y cuya fecha de entrega
sea incierta.
— En este caso, tal vez sea posible planear los primeros
incrementos de forma que eviten el uso de dicho hardware, y así
proporcionar una funcionalidad parcial a los usuarios finales
sin un retraso importante.
Prof. John W. Castro

61

Modelos del Proceso del Software

62

Modelo Incremental
— En este modelo, el sistema, tal y como está especificado en la
especificación de requisitos del software, se divide en
subsistemas de acuerdo a su funcionalidad.

— Las versiones se definen comenzando con un subsistema

funcional pequeño y agregando funcionalidad con cada nueva
versión.
¡ Cada nueva parte entregada se denomina incremento.

— Combina elementos del modelo en cascada con la filosofía

interactiva de construcción de prototipos.

Prof. John W. Castro

62

31
 Modelos del Proceso del Software
63

Modelo Iterativo
— Entrega un sistema completo desde el principio, para posteriormente
cambiar la funcionalidad de cada subsistema con cada versión.
— Características:
¡ Se basa en la evolución de prototipos ejecutables, mensurables y evaluables.
¡ Se van incorporando cambios en cada iteración.
¡ Exige más atención e implicación de todos los actores del proyecto.
— Evaluación de las iteraciones.
— Deben definirse criterios de evaluación de las iteraciones.
— Una iteración se marca por etapas intermedias que permitan medir
los progresos. Debe haber al menos dos etapas:
¡ Revisión Inicial: Fija los objetivos y criterios de la iteración.
¡ Revisión de Evaluación: Valida los resultados.

Prof. John W. Castro

63

Modelos del Proceso del Software

64

Modelo en Espiral
— Propuesto en primer lugar por Boehm, el modelo espiral es un
modelo evolutivo del proceso del software y se acopla con la
naturaleza iterativa de hacer prototipos con los aspectos
controlados y sistémicos del modelo de cascada.
— Tiene el potencial para hacer un desarrollo rápido de versiones
cada vez más completas.
— Con el empleo del modelo espiral, el software se desarrolla en
una serie de entregas evolutivas.
— Durante las primeras iteraciones, lo que se entrega puede ser
un modelo o prototipo.
— En las iteraciones posteriores se producen versiones cada vez
más completas del sistema cuya ingeniería se está haciendo.
Prof. John W. Castro

64

32
 Modelos del Proceso del Software
65

Modelo en Espiral
— Un modelo en espiral es dividido por el equipo de software en
un conjunto de actividades estructurales.
— Al comenzar el proceso evolutivo, el equipo de software realiza
actividades implícitas en un circuito alrededor de la espiral en
el sentido horario, partiendo del centro.
— El riesgo se considera conforme se desarrolla cada revolución.
— En cada paso evolutivo se marcan puntos de referencia
puntuales:
¡ Combinación de productos del trabajo y
¡ Condiciones que se encuentran a lo largo de la trayectoria de la espiral.

Prof. John W. Castro

65

Modelos del Proceso del Software

66

Modelo en
espiral

Prof. John W. Castro Fuente: Pressman 2010

66

33
 Modelos del Proceso del Software
67

Modelo en Espiral
— Progresión de la espiral.
¡ Se progresa a partir del centro de la espiral en el sentido de las agujas
del reloj.
÷ Desarrollo de una especificación de productos.
÷ Desarrollo de un prototipo.
÷ Desarrollo de versiones más sofisticadas del software.
¡ Cada paso de la región de planificación produce ajustes en el plan del
proyecto.
÷ El coste y la planificación se ajustan según la reacción ante la evaluación del
cliente.
÷ El gestor del proyecto ajusta el número planificado de iteraciones
requeridas para completar el software.

Prof. John W. Castro

67

Modelos del Proceso del Software

68

Modelo en Espiral
— Progresión de la espiral.
¡ Presenta un enfoque realista del desarrollo de sistemas y de software a
gran escala.
÷ Según progresa el proceso, el desarrollador y el cliente comprenden y
reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
— A diferencia de otros modelos del proceso que finalizan cuando
se entrega el software, el modelo espiral puede adaptarse para
aplicarse a lo largo de toda la vida del software.
— Entonces, el primer circuito alrededor de la espiral quizá
represente un “proyecto de desarrollo del concepto” que
comienza en el centro de la espiral y continúa por iteraciones
múltiples hasta que queda terminado el desarrollo del
concepto.
Prof. John W. Castro

68

34
 Modelos del Proceso del Software
69

Modelo en Espiral
— Si el concepto va a desarrollarse en un producto real, el proceso
sigue hacia fuera de la espiral y comienza un “proyecto de
desarrollo de producto nuevo”.
— El nuevo producto evolucionará a través de cierto número de
iteraciones alrededor de la espiral.
— Más adelante puede usarse un circuito alrededor de la espiral para
representar un “proyecto de mejora del producto”.
— En esencia, la espiral, cuando se caracteriza de este modo, sigue
operativa hasta que el software se retira.
— Hay ocasiones en las que el proceso está inmóvil, pero siempre que
se inicia un cambio comienza en el punto de entrada apropiado
¡ Por ejemplo, mejora del producto.
Prof. John W. Castro

69

Modelos del Proceso del Software

70

Modelo en Espiral
— Las ventajas de este modelo son:
¡ El modelo espiral es un enfoque realista para el desarrollo de sistemas y de
software a gran escala.
¡ Como el software evoluciona a medida que el proceso avanza, el desarrollador
y cliente comprenden y reaccionan mejor ante los riesgos en cada nivel de
evolución.
¡ El modelo espiral usa los prototipos como mecanismo de reducción de riesgos,
pero, más importante, permite aplicar el enfoque de hacer prototipos en
cualquier etapa de la evolución del producto.
¡ Mantiene el enfoque de escalón sistemático sugerido por el ciclo de vida
clásico, pero lo incorpora en una estructura iterativa que refleja al mundo real
en una forma más realista.
¡ El modelo espiral demanda una consideración directa de los riesgos técnicos
en todas las etapas del proyecto y, si se aplica de manera apropiada, debe
reducir los riesgos antes de que se vuelvan un problema.
Prof. John W. Castro

70

35
 Modelos del Proceso del Software
71

Modelo en Espiral
— Las ventajas de este modelo son:
¡ Refleja de forma más realista la idiosincrasia del desarrollo de software.
¡ Toma lo mejor y evita lo peor de los demás modelos, según la situación en cada
momento.
¡ Las opciones de reutilización se tienen en cuenta desde el primer momento.

¡ Proporciona una preparación para la evolución, crecimiento y cambio.

¡ Proporciona un mecanismo para incorporar objetivos de calidad en el

desarrollo.
¡ Se centra en la eliminación de errores y opciones no atractivas desde el
principio.
¡ Determina el nivel de esfuerzo de cada fase en cada proyecto.

¡ Se sigue el mismo procedimiento para el desarrollo que para el

mantenimiento, con lo que se evitan los problemas de las “mejoras rutinarias”
de alto riesgo.
¡ Permite
Prof. John W. Castro una gran flexibilidad.

71

Modelos del Proceso del Software

72

Modelo en Espiral
— Pero, como otros paradigmas, el modelo espiral no es una
panacea.
— Es difícil convencer a los clientes (en particular en situaciones
bajo contrato) de que el enfoque evolutivo es controlable.
— Demanda mucha experiencia en la evaluación del riesgo y se
basa en ella para llegar al éxito.
— No hay duda de que habrá problemas si algún riesgo
importante no se descubre y administra.
— Necesita una elaboración adicional de los pasos del modelo.

Prof. John W. Castro

72

36
 Modelos del Proceso del Software
73

Tipos de Modelos de Proceso

— Modelos de Procesos lineales o secuenciales
¡ Modelo primitivo
¡ Modelo clásico o en cascada
¡ Modelo V
— Modelos de Procesos Evolutivos
¡ Desarrollo evolutivo
¡ Modelos basados en prototipos
¡ Modelo incremental
¡ Modelo iterativo
¡ Modelo en espiral
— Modelos de Procesos Especializados
¡ Ingeniería del software basada en componentes
¡ Modelo de métodos formales
¡ Desarrollo
Prof. John W. Castro de software orientado a aspectos

73

Modelos del Proceso del Software

74

— Modelos de Procesos Especializados.

¡ Son muy adaptables a otro tipo de modelos ya que tienen
algunas características de uno o más de los modelos
tradicionales.
¡ Sin embargo, estos modelos son aplicados cuando el
proyecto de software tiene un enfoque a la ingeniería
mucho más especializado que el de los modelos
tradicionales.
¡ Se pueden caracterizar mejor, por ser un conjunto de
técnicas o “metodologías” para alcanzar una meta
específica de desarrollo de software. No obstante, implica
un proceso.
Prof. John W. Castro

74

37
 Modelos del Proceso del Software
75

Ingeniería del software basada en componentes

(CBSE)
— En la mayoría de los proyectos de software existe algo de reutilización de
software.
— Por lo general, esto sucede informalmente cuando las personas que
trabajan en el proyecto conocen diseños o código similares al requerido.
— Los buscan, los modifican según lo creen necesario y los incorporan en el
sistema. En el enfoque evolutivo, la reutilización es a menudo
indispensable para el desarrollo rápido de sistemas.
— Esta reutilización informal es independiente del proceso de desarrollo
que se utilice.
— Sin embargo, en los últimos años, ha surgido un enfoque de desarrollo de
software denominado ingeniería del software basada en componentes
(CBSE) que se basa en la reutilización, el cual se está utilizando de forma
amplia.
Prof. John W. Castro

75

Modelos del Proceso del Software

76

Ingeniería del software basada en componentes

(CBSE)
— Este enfoque basado en la reutilización se compone de una gran base de
componentes software reutilizables y de algunos marcos de trabajo de
integración para éstos.
— Algunas veces estos componentes son sistemas por sí mismos
(componentes comerciales de software general, o COTS) que se pueden
utilizar para proporcionar una funcionalidad especifica, como dar
formato al texto o efectuar cálculos numéricos.
— Este modelo incorpora muchas de las características del modelo espiral.
— Es de naturaleza evolutiva y demanda un enfoque iterativo para la
creación de software.
— Sin embargo, la ingeniería del software basada en componentes
construye aplicaciones a partir de fragmentos de software prefabricados.
Prof. John W. Castro

76

38
 Modelos del Proceso del Software
77

Ingeniería del software basada en componentes

(CBSE)
— CBSE es el proceso de definir, implementar e integrar o componer en
sistemas componentes independientes débilmente acoplados.
— Se ha convertido en una importante aproximación de desarrollo del
software debido a que los sistemas software son cada vez más grandes
y más complejos y los clientes demandan software más confiable que
sea desarrollado más rápidamente.

Especificación de Análisis de Modificación de Diseño del sistema

requisitos componentes componentes con reutilización

Desarrollo e Validación
integración del sistema

Prof. John W. Castro Fuente: Sommerville 2010

77

Modelos del Proceso del Software

78

Ingeniería del software basada en componentes

(CBSE)
— La única forma en la que podemos tratar con la complejidad y
entregar mejor software más rápidamente es reutilizar
componentes software en vez de reimplementarlos.
— Aunque la etapa de especificación de requisitos y la de validación
son comparables con otros procesos, las etapas intermedias en el
proceso orientado a la reutilización son diferentes.
— Estas etapas son:
¡ Análisis de componentes
¡ Modificación de componentes
¡ Diseño del sistema con reutilización
¡ Desarrollo e integración

Prof. John W. Castro

78

39
 Modelos del Proceso del Software
79

Ingeniería del software basada en componentes

(CBSE)
— Estas etapas son:
¡ Análisis de componentes. Dada la especificación de requisitos, se
buscan los componentes para implementar esta especificación. Por lo
general, no existe una concordancia exacta y los componentes que se
utilizan sólo proporcionan parte de la funcionalidad requerida.

¡ Modificación de requisitos. Los requisitos son refinados y modificados

en etapas tempranas en el proceso dependiendo de los componentes
disponibles. Si los requisitos del usuario no pueden ser satisfechos por
los componentes disponibles, deberían discutirse los requisitos
relacionados que pueden ser soportados. Los usuarios pueden estar
dispuestos a cambiar sus ideas si esto significa entregar el sistema más
rápidamente y con un menor costo económico.
Prof. John W. Castro

79

Modelos del Proceso del Software

80

Ingeniería del software basada en componentes

(CBSE)
— Estas etapas son:
¡ Diseño del sistema con reutilización. En esta fase se diseña o se
reutiliza un marco de trabajo para el sistema. Los diseñadores tienen
en cuenta los componentes que se reutilizan y organizan el marco de
trabajo para que los satisfaga. Si los componentes reutilizables no
están disponibles, se puede tener que diseñar nuevo software.

¡ Desarrollo e integración. Para crear el sistema, el software que no se

puede adquirir externamente se desarrolla, y los componentes y los
sistemas COTS se integran. En este modelo, la integración de sistemas
es parte del proceso de desarrollo, más que una actividad separada.

Prof. John W. Castro

80

40
 Modelos del Proceso del Software
81

Ingeniería del software basada en componentes

(CBSE)
— Surgió a finales de los 90 con una aproximación basada en
reutilización al desarrollo de sistemas software.

— Su creación fué motivada por la frustración de los diseñadores

de que el desarrollo orientado a objetos no ha conducido a una
reutilización extensiva, tal y como se sugirió originalmente.

— Las clases de objetos simples eran demasiado detalladas y

especificas, y a menudo tenían que ser enlazada con
aplicaciones en tiempo de compilación.
Prof. John W. Castro

81

Modelos del Proceso del Software

82

Ingeniería del software basada en componentes

(CBSE)
— Había que tener un conocimiento detallado de las clases para
usarlas, lo cual generalmente significaba que había que tener
acceso al código fuente del componente.

— Esto hizo que fuera difícil el marketing de objetos como

componentes reutilizables.

— A pesar de las predicciones optimistas iniciales, nunca se

desarrolló un mercado significativo para objetos individuales.

Prof. John W. Castro

82

41
 Modelos del Proceso del Software
83

Modelo de Métodos Formales

— Agrupa actividades que llevan a la especificación matemática
formal del software de cómputo.
— Los métodos formales permiten especificar, desarrollar y
verificar un sistema basado en computadora por medio del
empleo de una notación matemática rigurosa.
— Ciertas organizaciones de desarrollo de software aplican una
variante de este enfoque, que se denomina ingeniería de
software de quirófano.
— Cuando durante el desarrollo se usan métodos formales, se
obtiene un mecanismo para eliminar muchos de los problemas
difíciles de vencer con otros paradigmas de la ingeniería de
software.
Prof. John W. Castro

83

Modelos del Proceso del Software

84

Modelo de Métodos Formales

— Lo ambiguo, incompleto e inconsistente se descubre y corrige
con más facilidad, no a través de una revisión ad hoc sino con la
aplicación de análisis matemático.
— Si durante el diseño se emplean métodos formales, éstos sirven
como base para la verificación del programa, y así permiten
descubrir y corregir errores que de otro modo no serían
detectados.

Prof. John W. Castro

84

42
 Modelos del Proceso del Software
85

Modelo de Métodos Formales

— Las ventajas de este modelo son:
¡ Aunque el modelo de los métodos formales no es el más
seguido, promete un software libre de defectos.
¡ La ambigüedad, lo incompleto y la inconsistencia se
descubren y se corrigen fácilmente.
¡ Los métodos formales de diseño sirven como base para la
verificación de programas.
¡ Sirven de base para la generación automática de código.

Prof. John W. Castro

85

Modelos del Proceso del Software

86

Modelo de Métodos Formales

— Sin embargo, se han expresado preocupaciones acerca de su
aplicabilidad en un ambiente de negocios:
¡ El desarrollo de modelos formales consume mucho tiempo y es
costoso.

¡ Debido a que pocos desarrolladores de software tienen la

formación necesaria para aplicar métodos formales, se requiere
mucha capacitación.

¡ Es difícil utilizar los modelos como mecanismo de comunicación

para clientes sin complejidad técnica.

Prof. John W. Castro

86

43
 Modelos del Proceso del Software
87

Modelo de Métodos Formales

— A pesar de estas preocupaciones, el enfoque de los métodos
formales ha ganado partidarios entre los desarrolladores que:
¡ Deben construir software de primera calidad en seguridad. Por
ejemplo, control electrónico de aeronaves y equipos médicos.
¡ Sufrirían graves pérdidas económicas si ocurrieran errores en su
software.

— Sin importar el proceso del software que se elija, los

constructores de software complejo implementan de manera
invariable un conjunto de características, funciones y contenido
de información localizados.

Prof. John W. Castro

87

Modelos del Proceso del Software

88

Principios que Guían el Proceso

— Los siguientes principios fundamentales se aplican a la
estructura y, por extensión, a todo proceso de software:
¡ Principio 1. Ser ágil. Ya sea que el modelo de proceso que se elija sea
prescriptivo o ágil, son los principios básicos del desarrollo ágil los que
deben gobernar el enfoque. Todo aspecto del trabajo que se haga debe
poner el énfasis en la economía de acción:
÷ En mantener el enfoque técnico tan sencillo como sea posible,
÷ hacer los productos del trabajo que se generan tan concisos como se
pueda y
÷ tomar las decisiones localmente, siempre que sea posible.
¡ Principio 2. En cada etapa, centrarse en la calidad. La condición de
salida para toda actividad, acción y tarea del proceso debe centrarse en
la calidad del producto del trabajo que se ha generado.
Prof. John W. Castro

88

44
 Modelos del Proceso del Software
89

Principios que Guían el Proceso

— Los siguientes principios fundamentales se aplican a la
estructura y, por extensión, a todo proceso de software:
¡ Principio 3. Estar listo para adaptar. El proceso no es una experiencia
religiosa, en él no hay lugar para el dogma. Cuando sea necesario,
adapte su enfoque a las restricciones impuestas por el problema, la
gente y el proyecto en si.

¡ Principio 4. Formar un equipo eficaz. El proceso y práctica de la

ingeniería de software son importantes, pero el objetivo son las
personas. Forme un equipo con organización propia en el que haya
confianza y respeto mutuos.

Prof. John W. Castro

89

Modelos del Proceso del Software

90

Principios que Guían el Proceso

— Los siguientes principios fundamentales se aplican a la
estructura y, por extensión, a todo proceso de software:
¡ Principio 5. Establecer mecanismos para la comunicación y
coordinación. Los proyectos fallan porque la información importante
cae en las grietas o porque los participantes no coordinan sus esfuerzos
para crear un producto final exitoso. Éstos son aspectos de la
administración que deben enfrentarse.

¡ Principio 6. Administrar el cambio. El enfoque puede ser formal o

informal, pero deben establecerse mecanismos para administrar la
forma en la que los cambios se solicitan, evalúan, aprueban e
implementan.

Prof. John W. Castro

90

45
 Modelos del Proceso del Software
91

Principios que Guían el Proceso

— Los siguientes principios fundamentales se aplican a la
estructura y, por extensión, a todo proceso de software:
¡ Principio 7. Evaluar el riesgo. Son muchas las cosas que pueden salir
mal cuando se desarrolla software. Es esencial establecer planes de
contingencia.
¡ Principio 8. Crear productos del trabajo que agreguen valor para otros.
÷ Sólo genere aquellos productos del trabajo que agreguen valor para otras
actividades, acciones o tareas del proceso.
÷ Todo producto del trabajo que se genere como parte de la práctica de
ingeniería de software pasará a alguien más.
÷ La lista de las funciones y características requeridas se dará a la persona (o
personas) que desarrollará(n) un diseño, el diseño pasará a quienes generan
código y así sucesivamente.
÷ Asegúrese de que el producto del trabajo imparte la información necesaria
sin ambigüedades u omisiones.
Prof. John W. Castro

91

Modelos del Proceso del Software

92

— Como conclusión podemos decir que el modelo en

cascada, el desarrollo evolutivo y la ingeniería del software
basada en componentes (CBSE) son los tres modelos de
procesos genéricos que se utilizan ampliamente en la
práctica actual de la ingeniería del software.
— No se excluyen mutuamente y a menudo se utilizan juntos,
especialmente para el desarrollo de sistemas grandes.
— Los subsistemas dentro de un sistema más grande pueden
ser desarrollados utilizando enfoques diferentes.
— Por lo tanto, aunque es conveniente estudiar estos
modelos separadamente, debe entenderse que, en la
práctica, a menudo se combinan.
Prof. John W. Castro

92

46
 Modelos del Proceso del Software
93

— Se han propuesto todo tipo de variantes de estos

procesos genéricos y pueden ser usados en algunas
organizaciones.
— La variante más importante es probablemente el
desarrollo formal de sistemas, donde se crea un modelo
formal matemático de un sistema.
— Este modelo se transforma entonces, usando
transformaciones matemáticas que preservan su
consistencia, en código ejecutable.

Prof. John W. Castro

93

Modelos del Proceso del Software

94

¨ El ejemplo más conocido de un proceso de desarrollo formal es el

proceso de sala limpia, el cual fue originalmente desarrollado por
IBM es el siguiente:
¤ “En el proceso de sala limpia, cada incremento del software se
especifica formalmente, y esta especificación se transforma en una
implementación. La corrección del software se demuestra utilizando un
enfoque formal. No hay pruebas para defectos en el proceso, y las
pruebas del sistema se centran en evaluar su fiabilidad”.

— Tanto el enfoque de sala limpia como otro enfoque para desarrollo formal
basado en el método B [*] son particularmente apropiados para el
desarrollo de sistemas que tienen estrictos requisitos de seguridad,
fiabilidad o protección.

[*] Wordsworth, J. (1996). Software Engineering with B. Wokingham: Addison-Wesley.

Prof. John W. Castro

94

47
 Especificación del Software
95

— La especificación del software o ingeniería de requisitos

es el proceso de comprensión y definición de qué
servicios se requieren del sistema y de identificación de
las restricciones de funcionamiento y desarrollo del
mismo.

— La ingeniería de requisitos es una etapa particularmente

crítica en el proceso del software ya que los errores en
esta etapa originan inevitablemente problemas
posteriores en el diseño e implementación del sistema.

Prof. John W. Castro

95

Especificación del Software

96

— El proceso de ingeniería de requisitos que se muestra en

la siguiente figura, conduce a la producción de un
documento de requisitos, que es la especificación del
sistema.

— Normalmente en este documento los requisitos se

presentan en dos niveles de detalle.
1. Los usuarios finales y los clientes necesitan una declaración
de alto nivel de los requisitos
2. Mientras que los desarrolladores del sistema necesitan una
especificación más detallada de éste.

Prof. John W. Castro

96

48
 Especificación del Software
97

Obtención y
Estudio de
análisis de
viabilidad
requisitos
Especificación de
requisitos
Informe de
viabilidad Validación de
requisitos
Modelos del
sistema

Requisitos del
usuario y del sistema

Documento de
requisitos

Proceso de Ingeniería de Requisitos

Prof. John W. Castro Fuente: Sommerville 2010

97

Especificación del Software

98

— Existen cuatro fases principales en el proceso de ingeniería de

requisitos:
1. Estudio de viabilidad. Se estima si las necesidades del usuario se
pueden satisfacer con las tecnologías actuales de software y
hardware.
÷ El estudio analiza si el sistema propuesto será rentable desde un punto
de vista de negocios y
÷ Si se puede desarrollar dentro de las restricciones de presupuesto
existentes.
÷ Este estudio debe ser relativamente económico y rápido de elaborar.
÷ El resultado debe informar si se va a continuar con un análisis más
detallado.

Prof. John W. Castro

98

49
 Especificación del Software
99

— Existen cuatro fases principales en el proceso de ingeniería de

requisitos:
2. Obtención y análisis de requisitos. Es el proceso de obtener los
requisitos del sistema por medio de:
÷ La observación de los sistemas existentes,
÷ Discusiones con los usuarios potenciales y proveedores,
÷ El análisis de tareas, etc.
÷ Esto puede implicar el desarrollo de uno o más modelos y
prototipos del sistema que ayudan al analista a comprender el
sistema a especificar.

Prof. John W. Castro

99

Especificación del Software

100

— Existen cuatro fases principales en el proceso de ingeniería de

requisitos:
3. Especificación de Requisitos. Es la actividad de traducir la
información recopilada durante la actividad de análisis en un
documento que define un conjunto de requisitos. En este
documento se pueden incluir dos tipos de requisitos:
÷ Los requisitos del usuario, que son declaraciones abstractas de
los requisitos del cliente y del usuario final del sistema, y
÷ Los requisitos del sistema, que son una descripción más
detallada de la funcionalidad a proporcionar.

Prof. John W. Castro

100

50
 Especificación del Software
101

— Existen cuatro fases principales en el proceso de ingeniería de

requisitos:
4. Validación de requisitos. Esta actividad comprueba la veracidad,
consistencia y completitud de los requisitos. Durante este
proceso, inevitablemente se descubren errores en el documento
de requisitos. Se debe modificar entonces para corregir estos
problemas.

— Por supuesto, las actividades en el proceso de requisitos no se

llevan a cabo de forma estrictamente secuencial.
— El análisis de requisitos continúa durante la definición y
especificación, y a lo largo del proceso surgen nuevos
requisitos.
Prof. John W. Castro

101

Especificación del Software

102

— Por lo tanto, las actividades de análisis, definición y

especificación se entrelazan.

— En los métodos ágiles como la programación extrema (XP), los

requisitos de desarrollan de forma incremental conforme a las
prioridades del usuario, y la obtención de requisitos viene de
los usuarios que forman parte del equipo de desarrollo.

Prof. John W. Castro

102

51
 Diseño e Implementación del Software
103

— La etapa de implementación del desarrollo de software

es el proceso de convertir una especificación del sistema
en un sistema ejecutable.

— Siempre implica los procesos de diseño y programación

de software, pero, si se utiliza un enfoque evolutivo de
desarrollo, también puede implicar un refinamiento de
la especificación del software.

Prof. John W. Castro

103

Diseño e Implementación del Software

104

— Un diseño de software es una descripción de la

estructura del software que se va a implementar, los
datos que son parte del sistema, las interfaces entre los
componentes del sistema y, algunas veces, los
algoritmos utilizados.
— Los diseñadores no llegan inmediatamente a un diseño
detallado, sino que lo desarrollan de manera iterativa a
través de diversas versiones.
— El proceso de diseño conlleva agregar formalidad y
detalle durante el desarrollo del diseño, y regresar a los
diseños anteriores para corregirlos.
Prof. John W. Castro

104

52
 Diseño e Implementación del Software
105

— El proceso de diseño puede implicar el desarrollo de

varios modelos del sistema con diferentes niveles de
abstracción.
— Mientras se descompone un diseño, se descubren
errores y omisiones de las etapas previas.
— Esta retroalimentación permite mejorar los modelos de
diseño previos.
— La siguiente figura es un modelo de este proceso que
muestra las descripciones de diseño que pueden
producirse en varias etapas del diseño.

Prof. John W. Castro

105

Diseño e Implementación del Software

106

Especificación de
requisitos

Actividades de diseño
Diseño de la
Diseño Especificación Diseño de la Diseño de Diseño de
estructura de
arquitectónico abstracta interfaz componentes algoritmo
datos

Especificación
Arquitectura Especificación Especificación Especificación Especificación
de la estructura
del sistema del software de la interfaz de componentes de algoritmos
de datos

Productos del diseño

Un modelo general del proceso de diseño

Prof. John W. Castro Fuente: Sommerville 2010

106

53
 Diseño e Implementación del Software
107

— Este diagrama sugiere que las etapas son secuenciales.

— En realidad, las actividades del proceso de diseño se
entrelazan.
— La retroalimentación entre etapas y la consecuente
repetición del trabajo es inevitable en todos los procesos de
diseño.
— Una especificación para la siguiente etapa es la salida de cada
actividad de diseño.
— Esta especificación puede ser abstracta y formal, realizada
para clarificar los requisitos, o puede ser una especificación
para determinar qué parte del sistema se va a construir.

Prof. John W. Castro

107

Diseño e Implementación del Software

108

— Durante todo el proceso de diseño, se detalla cada vez más esta

especificación.
— El resultado final del proceso son especificaciones precisas de
los algoritmos y estructuras de datos a implementarse.
— Las actividades específicas del proceso de diseño son:
¡ Diseño arquitectónico. Los subsistemas que forman el sistema y sus
relaciones se identifican y documentan.
¡ Especificación abstracta. Para cada subsistema se produce una
especificación abstracta de sus servicios y las restricciones bajo las
cuales debe funcionar.
¡ Diseño de la interfaz. Para cada subsistema se diseña y documenta su
interfaz con otros subsistemas. Esta especificación de la interfaz debe
ser inequívoca ya que permite que el subsistema se utilice sin
conocimiento de su funcionamiento. En esta etapa pueden utilizarse
Prof. Johnlos métodos de especificación formal.
W. Castro

108

54
 Diseño e Implementación del Software
109

— Las actividades específicas del proceso de diseño son:

¡ Diseño de componentes. Se asignan servicios a los componentes y se
diseñan sus interfaces.
¡ Diseño de la estructura de datos. Se diseña en detalle y especifica la
estructura de datos utilizada en la implementación del sistema.
¡ Diseño de algoritmos. Se diseñan en detalle y especifican los
algoritmos utilizados para proporcionar los servicios.
— Éste es un modelo general del proceso
de diseño, y los procesos reales y
prácticos pueden adaptarlo de
diversas maneras.

Prof. John W. Castro

109

Diseño e Implementación del Software

110

— He aquí algunas adaptaciones posibles:

¡ Las dos últimas etapas -diseño de la estructura de datos y de
algoritmos- se pueden retrasar hasta la etapa de implementación.
¡ Si se utiliza un enfoque exploratorio de diseño, las interfaces del
sistema se pueden diseñar después de que se especifiquen las
estructuras de datos.
¡ Se puede omitir la etapa de especificación abstracta, aunque
normalmente es una parte fundamental del diseño de sistemas
críticos.
— Cada vez más, cuando se utilizan métodos ágiles de desarrollo,
las salidas del proceso de diseño no serán documentos de
especificación separados, sino que estarán representadas en el
código del programa.

Prof. John W. Castro

110

55
 Diseño e Implementación del Software
111

— Una vez diseñada la arquitectura de un sistema, las etapas

posteriores del diseño son incrementales.

— Cada incremento se representa como código del programa en

vez de como un modelo de diseño.

— Un enfoque opuesto es dado por los métodos estructurados que

se basan en la producción de modelos gráficos del sistema y, en
muchos casos, código automáticamente generado desde estos
modelos.

Prof. John W. Castro

111

Diseño e Implementación del Software

112

— Se propusieron varios modelos competentes de apoyo al

diseño orientado a objetos (Robinson, 1992; Booch, 1994) y
éstos se unificaron en los años 90 para crear el Lenguaje
Unificado de Modelado (UML) y el proceso unificado de
diseño asociado (Rumbaugh et al., 1991; Booch et al., 1999;
Rumbaugh et al., 1999a; Rumbaugh et al.. 1999b).

— Un método estructurado incluye un modelo del proceso de

diseño, notaciones para representar el diseño, formatos de
informes, reglas y pautas de diseño.

Prof. John W. Castro

112

56
 Diseño e Implementación del Software
113

— Los métodos estructurados pueden ayudar a alguno o a la

totalidad de los siguientes modelos de un sistema:
¡ Un modelo de objetos que muestra las clases de objetos utilizadas en el
sistema y sus dependencias.
¡ Un modelo de secuencias que muestra cómo interactúan los objetos en
el sistema cuando éste se ejecuta.
¡ Un modelo del estado de transición que muestra los estados del
sistema y los disparadores de las transiciones desde un estado a otro.
¡ Un modelo estructural en el cual se documentan los componentes del
sistema y sus agregaciones.
¡ Un modelo de flujo de datos en el que el sistema se modela utilizando
la transformación de datos que tiene lugar cuando se procesan. Éste no
se utiliza normalmente en los métodos orientados a objetos, pero
todavía se utiliza frecuentemente en el diseño de sistemas de tiempo
real y de negocio.
Prof. John W. Castro

113

Diseño e Implementación del Software

114

— En la práctica, los “métodos” estructurados son realmente

notaciones estándar que comprenden prácticas aceptables.
— Si se siguen estos métodos y se aplican las pautas, puede
obtenerse un diseño razonable.

— La creatividad del diseñador aún se requiere para decidir

la descomposición del sistema y asegurar que el diseño
capte de forma adecuada la especificación del mismo.

— Los diseñadores seleccionan y eligen de las pautas según

circunstancias locales.
Prof. John W. Castro

114

57
 Diseño e Implementación del Software
115

— La programación es una actividad personal y no existe un

proceso general que se siga comúnmente.
— Algunos programadores empiezan con los componentes que
comprenden, los desarrollan y después continúan con los que
comprenden menos.
— Otros toman el enfoque opuesto, dejando los componentes
que son más familiares hasta el final debido a que saben
cómo desarrollarlos.
— Algunos desarrolladores:
¡ Prefieren definir los datos al inicio del proceso y los utilizan para
conducir el desarrollo del programa;
¡ Otros dejan los datos sin especificar tanto como sea posible.

Prof. John W. Castro

115

Diseño e Implementación del Software

116

— Normalmente, los programadores llevan a cabo

algunas pruebas del código que han desarrollado.
— A menudo esto muestra defectos en el programa que
se deben eliminar del mismo.
— Esto se denomina depuración.
— Las pruebas y la depuración de defectos son procesos
diferentes.
— Las pruebas establecen la existencia de defectos.
— La depuración comprende la localización y corrección
de estos defectos.

Prof. John W. Castro

116

58
 Diseño e Implementación del Software
117

— La siguiente figura ilustra las etapas de la depuración.

— Los defectos en el código se localizan y el programa se
modifica para cumplir los requisitos.
— Las pruebas se deben entonces repetir para asegurar
que los cambios se han efectuado correctamente.
— Así, el proceso de depuración es parte tanto del
desarrollo como de las pruebas del software.

Localizar Diseñar la Reparar el Volver a probar

error reparación del error error el programa

El proceso de depuración
Prof. John W. Castro
Fuente: Sommerville 2010

117

Diseño e Implementación del Software

118

— Al depurar, se generan hipótesis acerca del

comportamiento que se observa en el programa;
después, se prueban estas hipótesis con la esperanza de
encontrar el defecto que origina la anomalía en la salida.
— Probar las hipótesis puede implicar realizar una traza
manual del código del programa.
— Pueden escribirse nuevos casos de pruebas para
localizar el problema.
— Para ayudar al proceso de depuración, se pueden utilizar
herramientas de depuración interactiva que muestran
los valores intermedios de las variables del programa y
una traza de las sentencias ejecutadas.
Prof. John W. Castro

118

59
 Validación del Software
119

— La validación del software o, de forma más general, la

verificación y validación (V&V) se utiliza para mostrar
que el sistema se ajusta a su especificación y que cumple
las expectativas del usuario que lo comprará.
— Implica procesos de comprobación, como las
inspecciones y revisiones, en cada etapa del proceso del
software desde la definición de requisitos hasta el
desarrollo del programa.
— Sin embargo, la mayoría de los costos de validación
aparecen después de la implementación, cuando se
prueba el funcionamiento del sistema.
Prof. John W. Castro

119

Validación del Software

120

— A excepción de los programas pequeños, los sistemas no

se deben probar como una simple unidad monolítica.
— La siguiente figura muestra un proceso de pruebas de
tres etapas en el cual se prueban:
¡ Los componentes del sistema,
¡ La integración del sistema y,
¡ Finalmente, el sistema con los datos del cliente.

Prueba de Prueba del Prueba de

componentes sistema aceptación

El proceso de pruebas
Prof. John W. Castro
Fuente: Sommerville 2010

120

60
 Validación del Software
121

— En el mejor de los casos, los defectos se descubren en las

etapas iniciales del proceso y los problemas con la
interfaz, cuando el sistema se integra.
— Sin embargo, cuando se descubren defectos el programa
debe depurarse y esto puede requerir la repetición de
otras etapas del proceso de pruebas.
— Los errores en los componentes del programa pueden
descubrirse durante las pruebas del sistema.
— Por lo tanto, el proceso es iterativo y se retroalimenta
tanto de las últimas etapas como de la primera parte del
proceso.
Prof. John W. Castro

121

Validación del Software

122

— Las etapas del proceso de pruebas son:

¡ Prueba de componentes (o unidades). Se prueban los componentes
individuales para asegurarse de que funcionan correctamente.

— Cada uno se prueba de forma independiente,

sin los otros componentes del sistema.
— Los componentes pueden ser:
÷ Entidades simples como funciones o clases de
objetos, o
÷ Agrupaciones coherentes de estas entidades.

Prof. John W. Castro

122

61
 Validación del Software
123

— Las etapas del proceso de pruebas son:

¡ Prueba del sistema. Los componentes se integran para formar el
sistema. Este proceso comprende:
÷ Encontrar errores que son el resultado de interacciones no previstas
entre los componentes y su interfaz.
÷ Validar que el sistema cumpla sus requisitos funcionales y no
funcionales y probar las propiedades emergentes del sistema.
÷ Para sistemas grandes, esto puede ser un
proceso gradual en el cual los componentes
se integran para formar subsistemas que
son probados individualmente antes de que
ellos mismos se integren para formar el
sistema final.

Prof. John W. Castro

123

Validación del Software

124

— Las etapas del proceso de pruebas son:

¡ Prueba de aceptación. Es la etapa final en el proceso de pruebas
antes de que se acepte que el sistema se ponga en funcionamiento.
Este se prueba con los datos proporcionados por el cliente más que
con datos de prueba simulados. Debido a la diferencia existente
entre los datos reales y los de prueba, la prueba de aceptación
puede revelar:
÷ Errores y omisiones en la definición de requisitos del sistema.
÷ Problemas en los requisitos donde los recursos del sistema no cumplen
las necesidades del usuario o donde el desempeño del sistema es
inaceptable.

Prof. John W. Castro

124

62
 Validación del Software
125

— Normalmente, el desarrollo de componentes y las

pruebas se entrelazan.
— Los programadores definen sus propios datos de prueba
y de forma incremental prueban el código que se va
desarrollando.
— Éste es un enfoque económicamente razonable puesto
que el programador es el que mejor conoce los
componentes y es, por lo tanto, la mejor persona para
generar los casos de prueba.

Prof. John W. Castro

125

Validación del Software

126

— Si se utiliza un enfoque incremental de desarrollo, cada

incremento debe ser probado cuando se desarrolla, con
estas pruebas basadas en los requisitos de ese
incremento.
— En la programación extrema (XP), las pruebas se
desarrollan junto con los requisitos antes de que
empiece el desarrollo.
— Esto ayuda a los probadores y desarrolladores a
entender los requisitos y asegurar que no hay retardos
pues se crean los casos de prueba.

Prof. John W. Castro

126

63
 Validación del Software
127

— Las últimas etapas de prueba consisten en integrar el

trabajo de los programadores y deben planificarse por
adelantado.
— Un equipo independiente de probadores debe trabajar a
partir de planes de prueba que se desarrollan desde la
especificación y diseño del sistema.
— La siguiente figura ilustra cómo los planes de prueba
son el vínculo entre las actividades de prueba y de
desarrollo.

Prof. John W. Castro

127

Validación del Software

128

Especificaciones Especificación Diseño del Diseño

de requisitos del sistema sistema detallado

Plan de la prueba Plan de la prueba Prueba y

Plan de la prueba
de aceptación del de integración de codificación de
de aceptación
sistema los subsistemas módulo y unidades

Prueba de Prueba de Prueba de

Servicio integración del
aceptación integración de
sistema subsistemas

Las fases de prueba en el proceso del software

Prof. John W. Castro Fuente: Sommerville 2010

128

64
 Validación del Software
129

— La prueba de aceptación algunas veces se denomina

prueba alfa.
— Los sistemas personalizados se desarrollan para un
único cliente.
— El proceso de prueba alfa continúa hasta que el
desarrollador del sistema y el cliente acuerdan que el
sistema que se va a entregar es una implementación
aceptable de los requisitos del sistema.
— Cuando un sistema se va a comercializar como un
producto de software, a menudo se utiliza un proceso de
prueba denominado prueba beta.
Prof. John W. Castro

129

Validación del Software

130

— Las pruebas beta comprenden la entrega de un sistema

a un número potencial de clientes que acuerdan
utilizarlo, los cuales informan de los problemas a los
desarrolladores del sistema.
— Esto expone el producto a un uso real y detecta los
errores no identificados por los constructores del
sistema.
— Después de esta retroalimentación, el sistema se
modifica y se entrega ya sea para una prueba beta
adicional o para la venta.

Prof. John W. Castro

130

65
 Evolución del Software
131

— La flexibilidad de los sistemas software es una de las

principales razones por la que más y más software se
incorpora a los sistemas grandes y complejos.
— Una vez que se decide adquirir hardware, es muy
costoso hacer cambios en su diseño.
— Sin embargo, se pueden hacer cambios al software en
cualquier momento durante o después del desarrollo del
sistema.
— Aun cambios importantes son todavía mucho más
económicos que los correspondientes de los sistemas
hardware.
Prof. John W. Castro

131

Evolución del Software

132

— Históricamente, siempre ha existido una separación entre el

proceso de desarrollo y el proceso de evolución del software
(mantenimiento del software).
— La gente considera el desarrollo de software como una
actividad creativa en la cual un sistema software se desarrolla
desde un concepto inicial hasta que se pone en
funcionamiento.
— Sin embargo, a veces consideran el mantenimiento del
software como algo aburrido y sin interés.
— Aunque los costos de “mantenimiento” son a menudo varias
veces los costos iniciales de desarrollo, el proceso de
mantenimiento se considera a veces menos problemático que
el desarrollo del software original.
Prof. John W. Castro

132

66
 Evolución del Software
133

— Esta distinción entre el desarrollo y el mantenimiento es

cada vez más irrelevante.

— Hoy en día, pocos sistemas software son completamente

nuevos, lo que implica que tiene más sentido ver el desarrollo
y el mantenimiento como actividades continuas.

— Más que dos procesos separados, es más realista considerar a

la ingeniería del software como un proceso evolutivo en el
cual el software se cambia continuamente durante su periodo
de vida como respuesta a los requisitos cambiantes y
necesidades del usuario, como se puede observar en la
siguiente figura.
Prof. John W. Castro

133

Evolución del Software

134

Definir requisitos Valorar sistemas Proponer cambios Modificar el

del sistema existentes en el sistema sistema

Sistemas Nuevo
existentes sistema

Evolución del sistema

Prof. John W. Castro Fuente: Sommerville 2010

134

67