UNIVERSIDAD FRANCISCO GAVIDIA

FACULTAD DE INGENIERIA Y SISTEMAS

TEMA :MODELADO DEL
PROCESO Y DEL CICLO DE VIDA

INGENIERIA DEL SOFTWARE II

OBJETIVOS

• Proporcionar las Bases

Teóricas sobre el
Modelado del Proceso y
del Ciclo de vida de los
sistemas.
MODELADO DE PROCESO

Los sistemas, conjuntos

de procesos y
subprocesos integrados
en una organización.
MODELADO DE PROCESO

Un modelo es una representación

de una realidad compleja.

Modelar es desarrollar una

descripción lo más exacta posible
de un sistema y de las actividades
llevadas a cabo en él.
MODELADO DE PROCESO

Cuando un proceso es modelado, con

ayuda de una representación gráfica
(diagrama de proceso), pueden
apreciarse con facilidad las
interrelaciones existentes entre
distintas actividades, analizar cada
actividad, definir los puntos de
contacto con otros procesos, así como
identificar los subprocesos
comprendidos.
MODELADO DE PROCESO
Determinados
por practicas de
Industria ingeniería de
Software

Modelos de
procesos Determinados
Empresa por
procedimientos

Metodología Metodología Metodología

Comercial Comercial Propietaría
Determinados
por las
Proyectos Características
del proyecto

Proceso Proceso Proceso

definido del definido del definido del
proyecto proyecto proyecto
Los modelos y su
importancia

“Modelar consiste en definir un mundo

abstracto y teórico tal que las conclusiones
que se puedan sacar de él coinciden con las
manifestaciones aparentes del mundo real”.

Un modelo es la interpretación explicita de lo

que uno entiende de una situación, o tan
solo de las ideas de uno acerca de esa
situación.
Los modelos y su importancia

Utilidad Comprender la
Un modelo es una
simplificación de la realidad
de los realidad,
modelos
Un modelo permite comprender
Comprender el mejor el sistema que estamos
desarrollando: sus elementos y
sistema sus relaciones

Un modelo permite reducir la

Reducir la complejidad de entender
sistemas complejos en su
complejidad totalidad

Un modelo permite la
Comunicar con comunicación entre los
desarrolladores y los clientes.
otros
Modelado de Análisis del Sistema

El Análisis se refiere al
“extremo inicial” de un
proyecto de desarrollo de
sistemas, durante el tiempo
en que los requisitos del
usuario son definidos y
documentados.
El modelado de un sistema
software Diagramas

DocumentList

• Ingeniería Software
FileMgr Document

add( ) name : int

fetchDoc( ) delete( ) docid : int
sortByName( ) numField : int

get( )
open( ) read() fill the
close( ) code..
FileList read( )
sortFileList( )
fList create( )
fillDocument( )
add( )
delete( )
1

– Modelos UML del

rep

Repository File

(from Persistence) GrpFile

read( )
name : char * = 0
read( )
readDoc( ) open( )
readFile( ) create( )
fillFile( )

Sistema Software
• Modelo de Casos de
mainWnd fileMgr : document : gFile repository
user FileMgr Document

ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )

»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.

uso
2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

• Modelo Estructural
ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( )
¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.

7: readFile ( )

8: fillFile ( )

È¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( )

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡
º¸¿©ÁØ´Ù.

• Modelo de
Comportamiento Repository
DocumentList

• Modelo de FileManager

Implementación Document

• Modelo de Despliegue GraphicFile

File FileList
Modelado de Análisis del
Sistema
Estructura del Modelo de Análisis
El modelo debe cumplir tres objetivos
primarios:

1. Describe lo que requiere el

cliente

2. Establecer una base para la

creación de un diseño de software

3. Definir un conjunto de requisitos que

puedan validarse una vez construido el
software
El modelado de un sistema
software
• Un Modelo es un esquema simplificado que
describe un sistema o realidad desde un
determinado punto de vista que facilita su estudio
y compresión

Modelo
(simplificado)
Sistema Software Los modelos de un sistema
software se expresan visualmente
(complejo) mediante el lenguaje de modelado
UML
El modelado de un sistema
software
• Modelos de alto nivel en etapas tempranas
– Destinado a Stakeholders no técnicos
– Para exploración conceptual del problema
• Modelos de niveles medios
– Especificación de Capacidades esenciales del
sistema
– Históricamente: ERs, DFDs, ,
– Recientemente: Escenarios, Patrones de Diseño,
etc.
• Modelos de nivel Detallados
• Modelos Formales
El modelado de un sistema
software
• Nota: Paradigma Orientado a Objeto
– Desarrollo de un sistema software mediante
la construcción de unidades reusables
siguiendo los principios de :
• Abstracción
• Encapsulación
• Herencia
• Polimorfismo

14
El modelado de un sistema
software
• Nota: Paradigma Basado en
Componentes
– Desarrollo de un sistema software
mediante en el ensamblado de
unidades reusables siguiendo los
principios de:
• Componentes
• Interfaces
• Infraestructura
Modelo de Datos

Es un esquema teórico de un
sistema o realidad compleja
que se elabora para facilitar
su comprensión y estudio.

Es una representación de los

aspectos esenciales de una
realidad compleja de acuerdo
a un criterio

Todo modelo es
necesariamente una
simplificación de la realidad
 Modelo de Datos
Objetos, Atributos, Relaciones

Las entidades son los

objetos principales sobre los
que se debe recoger
información y generalmente
denotan personas, lugares,
cosas o eventos de interés.
 Modelo de Datos

Las entidades pueden clasificarse por la fuerza

de sus atributos identificadores, es decir, por su
dependencia o no dependencia respecto a
otras entidades.

Las entidades fuertes tienen existencia propia,

es decir, poseen identificadores internos que
determinan de manera única la existencia de
sus ocurrencias. Las entidades débiles pueden
tienen existencia en la base de datos
dependiendo de una entidad fuerte.
 Modelo de Datos

Los atributos se utilizan para detallar las

entidades asignándoles propiedades
descriptivas tales como nombre, color y peso.

No solo es posible especificar atributos en las

entidades sino también en las relaciones.

Los atributos también aparecen reflejados en

el enunciado, generalmente, como nombres.
 Modelo de Datos

Las relaciones representan asociaciones en el

mundo real entre una o más entidades.

Las relaciones se caracterizan por su nombre,

el grado (número de entidades que participan
en la relación), el tipo de cardinalidad (número
máximo de ejemplares de una entidad
asociados a una combinación de ejemplares
de las otras entidades de la relación, que
pueden ser 1 ó N).
Diagrama Entidad Relación

En este modelo se presenta la

vista unificada de los datos,
centrándose en la estructura
lógica y abstracta de los datos,
como representación del mundo
real, con independencia de
consideraciones del mundo físico.
Diagrama Entidad Relación

Un modelo Entidad-Relación tiene

los siguientes elementos:
• Entidad es “una persona, lugar, cosa,
concepto, suceso, real o abstracto de interés
para la empresa”. Es aquel objeto acerca del
cual queremos almacenar información en la
base de datos.
• Interrelación se define como la asociación o
correspondencia entre entidades.
• Atributos
MODELADO DEL FLUJO DE LA
INFORMACIÓN
DESCRIPCIÓN

• Es la manera en que se Las transformaciones que

representa la forma en se aplican a los datos son
que los datos cambian funciones que debe
realizar un programa.
conforme se mueven a
través del sistema.

REPRESENTACIÓN
Modelo Funcional y Flujo de la
Información
El modelo funcional describe los comportamientos y
operaciones de los objetos.
El modelo funcional muestra la dependencia de
datos en el sistema.
El modelo funcional describe la computación dentro del
sistema, cómo los valores de salida se derivan de los valores
de entrada, sin importar el orden en que son computados.
El modelo funcional consiste de múltiples diagramas
de flujo de datos.
• El diagrama de flujo de datos ( DFD ) es
una técnica gráfica que representa el flujo
de la información y las transformaciones
que se aplican a los datos al moverse
desde la entrada a la salida.
 LA NOTACIÓN BÁSICA PARA
CONSTRUIR DFD’S ES LA SIGUIENTE:

• Un rectangulo representa a un elemento

del sistema ( por ejemplo un hardware,
una persona, un programa ) o un sistema
que produce o recibe información que es
transformada por el software.

• Un circulo representa un proceso o

transformación que se aplica a los datos y
los cambia de alguna forma.
• La flecha representa a un elemento o una
colección de elementos de datos.

• Representa información almacenada y

que utiliza el software.
Modelado de
comportamiento

El diagrama de transición de estados DTE representa el

comportamiento de un sistema que muestra los estados y
los sucesos que hacen que el sistema cambie de estado.

Un estado es un modo observable de comportamiento, por

ejemplo monitoreando, comprobando, calculando, etc.

Cada estado representa un modo de comportamiento y el

DTE indica cómo se mueve el sistema de un estado a otro.
Diccionario de datos

Un Diccionario de Datos es una lista

con todos los detalles y
descripciones de los elementos
incluidos en los Diagramas de Flujo
de Datos que describen al sistema.
El diccionario de datos debe
contener:

1. Descripción de los almacenamientos de datos

2. Descripción de los procesos

3. Descripción de las estructuras de datos

4. Descripción de los elementos de datos

5. Descripción de los flujos de datos

MODELO LINEAL SECUENCIAL

Llamado algunas veces «ciclo de vida básico» o modelo en

cascada», el modelo lineal secuencial sugiere un enfoque
sistemático, secuencial, para el desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño,
codificación, pruebas y mantenimiento
MODELO LINEAL SECUENCIAL

Análisis de los requisitos del software.

Para comprender la naturaleza del (los) programa(s) a
construirse, el ingeniero («analista») del software debe
comprender el dominio de información del software, así
como la función requerida, comportamiento,
rendimiento de interconexión.

Diseño.
se centra en cuatro atributos distintos de
programa: estructura de datos, arquitectura de
software, representaciones de interfaz y
detalle procedimental (algoritmo).
MODELO LINEAL SECUENCIAL

Generación de código.
El diseño se debe traducir en una
forma legible por la máquina. El
paso de generación de código
lleva a cabo esta tarea. Si se lleva
a cabo el diseño de una forma
detallada, la generación de código
se realiza mecánicamente.
MODELO LINEAL SECUENCIAL

Pruebas.
Una vez que se ha generado el
código, comienzan las pruebas del
programa. detección de errores y
asegurar que la entrada definida
produce resultados reales de
acuerdo con los resultados
requeridos.
MODELO LINEAL SECUENCIAL

¿Por qué algunas veces falla el modelo lineal?

A menudo es difícil que el cliente exponga

explícitamente todos los requisitos. El modelo lineal
secuencial lo requiere y tiene dificultades a la hora de
acomodar la incertidumbre natural al comienzo de
muchos proyectos.

El cliente debe tener paciencia. Una versión de trabajo

del (los) programa(s) no estará disponible hasta
que el proyecto esté muy avanzado.
El paradigma de construcción de prototipos comienza con
la recolección de requisitos.
El desarrollador y el cliente encuentran y definen los
objetivos globales para el software, identifican los
requisitos conocidos y las áreas del esquema en donde es
obligatoria más definición.
MODELO DE CONSTRUCCION DE
PROTOTIPOS

El diseño rápido se centra en una

representación de aspectos del
software que serán visibles para el
usuario/cliente (enfoques de
entrada y formatos de salida). El
diseño rápido lleva a la
construcción de un prototipo.
MODELO DE CONSTRUCCION DE
PROTOTIPOS

En la mayoría de los proyectos, el

primer sistema construido apenas se
puede utilizar y se tiene que tirar,
porque incluso la mejor planificación
no es omnisciente como para que esté
perfecta la primera vez.
MODELO DE CONSTRUCCION DE
PROTOTIPOS

La iteración ocurre cuando el

prototipo se pone a punto para
satisfacer las necesidades del
cliente, permitiendo al mismo
tiempo que el desarrollador
comprenda mejor lo que se
necesita hacer.
MODELO DE CONSTRUCCION DE
PROTOTIPOS
La construcción de prototipos puede ser
problemática por las siguientes razones:

El cliente ve una versión de trabajo del software, sin

saber que con la prisa de hacer que funcione no se
ha tenido en cuenta la calidad del software global o
la facilidad de mantenimiento a largo plazo.
Se puede utilizar un sistema operativo o lenguaje
de programación inadecuado simplemente porque
está disponible.
 MODELADO PROTOTIPADO

Lista de Lista de Lista de

revisión revisión revisión

Prototipar los Prototipar el Prototipar el Probar

requerimientos diseño sistema

Requerimientos Sistema
Del sistema entregado
(a veces informal o
incompleto)
 Modelo DRA

El Desarrollo Rápido de Aplicaciones (DRA)es

un modelo de proceso del desarrollo del
software lineal secuencial que enfatiza un ciclo
de desarrollo extremadamente corto.

Es una adaptación a «alta velocidad» del

modelo lineal secuencial en el que se logra el
desarrollo
rápido utilizando una construcción basada en
componentes
Modelo DRA
 Modelo DRA

Si se comprenden bien los requisitos y

se limita el ámbito del proyecto, el
proceso DRA permite al equipo de
desarrollo crear un «sistema
completamente funcional» dentro de
períodos cortos de tiempo (por
ejemplo: de 60 a 90 días)
 Modelo DRA

Modelado de Gestión.
El flujo de información entre las funciones de
gestión se modela de forma que responda a las
siguientes 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 procesa?
 Modelo DRA

Modelado de datos.

Se definen las características (llamadas atributos)

de cada uno de los objetos y las relaciones entre
estos objetos.
 Modelo DRA

Los objetos de datos definidos en la

Modelado del fase de modelado de datos quedan
proceso. transformados para lograr el flujo de
información necesario para
implementar una función de gestión.
Las descripciones del proceso se
crean para añadir, modificar,
suprimir, o recuperar un objeto de
datos.
 Modelo DRA

Generación de aplicaciones
En lugar de crear software con lenguajes de
programación de tercera generación, trabaja para
volver a utilizar componentes de programas ya
existentes (cuando es posible) o a crear
componentes reutilizables (cuando sea necesario).

Se utilizan herramientas para facilitar la construcción

del software.
 Modelo DRA

Pruebas y entrega.

Como el proceso DRA enfatiza la reutilización, ya se han

comprobado muchos de los componentes de los programas.

Esto reduce tiempo de pruebas. Sin embargo, se deben probar

todos los componentes nuevos y se deben ejercitar todas las
interfaces a fondo.
 MODELOS EVOLUTIVOS
DE PROCESO DEL SOFTWARE

Los modelos evolutivos son

iterativos. Se caracterizan por la
forma en que permiten a los
ingenieros del software desarrollar
versiones cada vez mas
completas del software.
 MODELOS EVOLUTIVOS
DE PROCESO DEL SOFTWARE

El modelo incremental:

El modelo incremental combina elementos del

modelo lineal secuencial con la filosofía interactiva
de construcción de prototipos.
El modelo incremental aplica secuencias lineales
de forma escalonada mientras progresa el tiempo
en el calendario.
Cada secuencia lineal produce un «incremento»
del software suplementarias .
 Modelo Espiral

Es un modelo de proceso de software evolutivo que

conjuga la naturaleza iterativa de construcción de
prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial.

Se desarrolla en una serie de versiones

incrementales.
 Modelo Espiral

Durante las primeras iteraciones, la

versión incremental podría ser un modelo
en papel o un prototipo.
Durante las últimas iteraciones, se
producen versiones cada vez más
completas del sistema diseñado.
Modelo Espiral
 Modelo Espiral

El modelo en espiral se divide en un número de

actividades de marco de trabajo, también llamadas
regiones de tareas. La Figura 2.8 representa un modelo
en espiral que contiene seis regiones de tareas:

1 Comunicación análisis de
2. planificación-
con el cliente- riesgos-
• Las tareas • Las tareas • Las tareas
requeridas requeridas requeridas
para para definir para evaluar
establecer recursos, el riesgos
comunicación tiempo y otra técnicos y de
entre el información gestión.
desarrollador y relacionadas
el cliente. con el
proyecto.
 MODELO ESPIRAL

construcción y evaluación del

4.ingeniería
acción cliente
• Las tareas • Las tareas • Las tareas
requeridas para requeridas para requeridas para
construir una o más construir, probar, obtener la reacción
representaciones instalar y del cliente según la
de la aplicación proporcionar evaluación de las
soporte al usuario representaciones
(por ejemplo: del software
documentación y creadas durante la
práctica etapa de ingeniería
e implementada
durante la etapa de
instalación.
EL MODELADO DE DESARROLLO
CONCURRENTE

Define una serie de acontecimientos que

dispararán transiciones de estado a estado para
cada una de las actividades de la ingeniería del
software.
Por ejemplo, durante las primeras etapas del
diseño, no se contempla una inconsistencia del
modelo de análisis.
EL MODELADO DE DESARROLLO
CONCURRENTE

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.
El modelo de proceso concurrente se utiliza a
menudo como el paradigma de desarrollo de
aplicaciones cliente/ servidor
EL MODELADO DE DESARROLLO
CONCURRENTE
Un elemento del modelo de proceso
concurrente
EL MODELADO DE DESARROLLO
CONCURRENTE

El modelo de desarrollo basado en componentes incorpora las etapas

siguientes (se implementan con el uso de un enfoque evolutivo):

1. Se investigan y evalúan, para el tipo de aplicación de que se trate, productos

disponibles basados en componentes

2. Se consideran los aspectos de integración de los componentes.

3. Se diseña una arquitectura del software para que reciba los componentes.

4. Se integran los componentes en la arquitectura.

5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada

DESARROLLO BASADO EN COMPONENTES

Enfatiza la creación de clases que encapsulan tanto los

datos como los algoritmos que se utilizan para manejar
los datos. Si se diseñan y se implementan
adecuadamente, las clases orientadas a objetos son
reutilizables por las diferentes aplicaciones y
arquitecturas de sistemas basados en computadora.
EL MODELO DE METODOS
FORMALES

El modelo de métodos formales

comprende un conjunto de
actividades que conducen a la
especificación matemática del
software de computadora.

Los métodos formales permiten que

un ingeniero de software especifique,
desarrolle y verifique un sistema
basado en computadora aplicando
una notación rigurosa y matemática.
 EL MODELO DE METODOS
FORMALES

Sin embargo, se ha hablado de una gran preocupación sobre su

aplicabilidad en un entorno de gestión:

1. El desarrollo de modelos formales actualmente es bastante caro y

lleva mucho tiempo.

2. Se requiere un estudio detallado porque pocos responsables del

desarrollo de software tienen los antecedentes necesarios para aplicar
métodos formales.

3. Es difícil utilizar los modelos como un mecanismo de comunicación

con clientes que no tienen muchos conocimientos técnicos.
 MODELO SECUENCIAL LINEAL O
MODELO DE CASCADA

Este es también llamado "Modelo Clásico",

"Modelo Tradicional" o "Modelo en Cascada".
Este es el más básico de todos los modelos, y
sirve como bloque de construcción para los
demás modelos de ciclo de vida.
La visión del modelo cascada del desarrollo de
software es muy simple; dice que el desarrollo de
software puede ser a través de una secuencia
simple de fases.
 MODELO SECUENCIAL LINEAL O
MODELO DE CASCADA

Cada fase tiene un conjunto de metas bien

definidas, y las actividades dentro de una
fase contribuyen a la satisfacción de metas
de esa fase o quizás a una subsecuencia
de metas de la fase.
Las flechas muestran el flujo de
información entre las fases. La flecha de
avance muestra el flujo normal.
Las flechas hacia atrás representan la
retroalimentación.
MODELO SECUENCIAL LINEAL O
MODELO DE CASCADA
MODELADO V
El modelo V es una variación del modelo de cascada que
demuestra como se relacionan las actividades de prueba con
las de análisis y diseño.

El modelo V sugiere que la prueba unitaria y de integración

también sea utilizada pará verificar el diseño del programa.

La prueba de sistema debe verificar el diseño del sistema,

asegurando que todos los aspectos del diseño del sistema
están correctamente implementados .
MODELADO V
La prueba de aceptación, que es dirigida por
el cliente, en lugar del desarrollador, valida
los requerimientos asociando un paso de
prueba
Este tipo de prueba sirve para comprobar si
todos los requerimientos se han
implementado por completo, antes de que el
sistema sea aceptado.
MODELADO V
La vinculación entre los lados derecho e
izquierdo del modelo V implica que, si se
encuentran problemas durante la
verificación y la validación, entonces el
lado izquierdo de la V puede ser ejecutado
nuevamente, para solucionar el problema
y mejorar los requerimientos, el diseño y el
código antes de retomar los pasos de
prueba sobre el lado derecho.
 MODELADO V
Análisis de Operación y
requerimientos mantenimiento

Prueba de
aceptación
Diseño del sistema

Prueba de sistema

Diseño del programa Pruebas unitaria y

de integración

Codificación
MODELO DE ESPECIFICACIÓN
OPERACIONAL
Los requerimientos del sistema son
evaluados o ejecutados en una forma que
muestra el comportamiento del sistema.

Los requerimientos están especificados

pueden implementarse utilizando paquete
de software de modo que sus implicancias
puedan ser evaluadas antes de que
comience el diseño.
MODELO DE ESPECIFICACIÓN
OPERACIONAL
Ejecutar y
revisar

Especificación Especificación
PRUEBA
Operacional Transformada
(Orientada a la
(Orientada al problema) Implementación)

Requerimientos Sistema
Del sistema entregado
(a veces informal o
incompleto)
MODELO DE
TRANSFORMACIÓN
Reduce las oportunidades del error por medio de la
eliminación de varios de los pasos del desarrollo.

Soporte automatizado el proceso de transformación

aplica una serie de transformaciones para convertir
una especificación en un sistema implementarle

Una muestra de las transformaciones puede ser la

siguiente
• Cambiar la presentación de los datos
• Seleccionar algoritmos
• Optimizar
• compilar
MODELO TRANSFORMACIONAL
Comparar con
requerimientos; REGISTRO FORMAL DEL DESARROLLO
actualización
cuando se necesita
Secuencia de transformaciones con su justificación

ESPERIFICACIO TRANSFORMACIÓN N PRUEBA

N FORMAL
TRANSFORMACIÓN 2

TRANSFORMACIÓN 1

Requerimientos Sistema
Del sistema entregado
(a veces informal o
incompleto)
MODELO ESTATICO: LA
NOTACIÓN DE LAI
Esta construida sobre un paradigma donde
las personas cumplen roles mientras los
recursos cumplen actividades que llevan a la
producción de componentes.

El modelo de proceso muestra las relaciones

entre los roles, las actividades y los
artefactos y las tablas de estado presentan la
información acerca del grado de terminación
de cada componente en un momento dado
MODELO DINÁMICO : DINAMICA DE
LOS SISTEMAS.

Una propiedad deseable de un modelo de

proceso es la capacidad para dar validez al
proceso de modo que pueda verse que les
ocurre a los recursos y componentes cuando
suceden las actividades.

Describir un modelo del proceso y luego

observar como el software nos muestra el
modo en que los recursos fluye a través de
las actividades para convertirse en salidas
MODELO DINÁMICO : DINAMICA
DE LOS SISTEMAS.
La dinámica del proceso nos permite
simular dicho proceso y hacer los cambios
antes de gastar realmente los recursos.

Este modelo es útil para la simulación de

diversos proceso incluyendo sistemas
ecológicos , económicos y políticos.
Ciclo de vida del desarrollo de
software
• Definición de objetivos: definir el
resultado del proyecto y su papel en la
estrategia global.
• Análisis de los requisitos y su viabilidad:
recopilar, examinar y formular los
requisitos del cliente y examinar cualquier
restricción que se pueda aplicar.
• Diseño general: requisitos generales de la
arquitectura de la aplicación.
• Diseño en detalle: definición precisa de
cada subconjunto de la aplicación.
• Programación (programación e
implementación): es la implementación de
un lenguaje de programación para crear
las funciones definidas durante la etapa de
diseño.
• Prueba de unidad: prueba individual de
cada subconjunto de la aplicación para
garantizar que se implementaron de
acuerdo con las especificaciones.
• Integración: para garantizar que los
diferentes módulos se integren con la
aplicación. Éste es el propósito de la
prueba de integración que está
cuidadosamente documentada.
• Prueba beta (o validación), para garantizar
que el software cumple con las
especificaciones originales.
• Documentación: sirve para documentar
información necesaria para los usuarios
del software y para desarrollos futuros.
• Implementación

• Mantenimiento: para todos los

procedimientos correctivos
(mantenimiento correctivo) y las
actualizaciones secundarias del software
(mantenimiento continuo).
GRACIAS