Modelos De Desarrollo De

Software
Armando Arturo Camacho Perez

Modelo De Desarrollo
De Software

Para el desarrollo de cualquier producto de

software se realizan una serie de tareas entre
la idea inicial y el producto final, un modelo
de desarrollo establece el orden en el que se
harn las cosas en el proyecto, provee de
requisitos de entrada y de salida para cada
una de las actividades, por ello es necesario
el modelo de desarrollo.

Dado que cada proyecto es nico, no existe un

modelo que se aplique al 100% a todos los
proyectos de una organizacin. Una organizacin
puede contar con uno o ms modelos de desarrollo
para ser utilizados dependiendo del tipo de
proyecto.
A continuacin se muestran los modelos de
desarrollo de software que fueron utilizados en el
anlisis, desarrollo e implementacin del sistema.

Modelo De Cascada

Esta es tambin llamada modelo clsico, modelo

Tradicional o modelo secuencial lineal
Este es el mas bsico de todos los modelos y sirve
como bloque de construccin para los dems
modelos de ciclo de vida. La visin del modelo
cascada del desarrollo de software es muy
simple; dice que el desarrollo de software puede
ser atreves de una secuencias simple de frases

Cada Fase tiene un conjunto de metas bien

definidas, y las actividades dentro de una fase
contribuyen a la satisfaccin de metas de esa fase
o quizs a una subsecuencica de metas de la fase.
Las flechas muestran el flujo de informacin ente
las faces la flecha de avance muestra el flujo
normal las flechas hacia atrs representan la
retroalimentacin .

MODELO ESPIRAL
Modelo Original de
Boehm
Pablo Joel Perales
Gaytn

 TIPOS DE MODELOS

VENTAJAS

DESVENTAJA
S

El modelo en espiral puede

adaptarse y aplicarse a lo largo de
la vida del software de
computadora.
Como el software evoluciona a
medida que progresa el proceso, el
desarrollador y el cliente
comprenden y reaccionan mejor
ante riesgos en cada uno de los
nivele evolutivos.
El modelo en espiral permite a quien
lo desarrolla aplicar el enfoque de
construccin
prototiposa en
Resulta difcilde
convencer
grandes
cualquier
etapa
de
evolucin
del
clientes de que el enfoque evolutivo
producto.
D
es controlable.
Debido a su elevada complejidad no
se aconseja utilizarlo en pequeos
sistemas.
Genera mucho tiempo en el
desarrollo del sistema
Modelo costoso
Requiere experiencia en la
identificacin de riesgo

Prototipado

Guillermo Alfonzo Figueroa del Bosque

Prototipado
Es frecuente que los clientes
no sepan lo que quieren, pero
cuando ven algo y utilizan
prototipos, pronto saben lo
que no quieren.

 Los prototipos son una representacin limitada de un

producto, permite a las partes probarlo en
situaciones reales o explorar su uso, creando as
unproceso de diseo de iteracinque genera
calidad.
Un prototipo puede ser cualquier cosa, desde un
trozo de papel con sencillos dibujos a un complejo
software.

Los prototipos apoyan la

evaluacin de productos, clarifican
requisitos de usuario y definen
alternativas.

Desarrollo basado en la
reutilizacin
Carlos Alberto Gmez Rodrguez

Desarrollo basado en componentes

El modelo de desarrollo basado
componentes incorpora muchas de
caractersticas del modelo espiral.
evolutivo por naturaleza y exige
enfoque interactivo para la creacin
software.

en
las
Es
un
del

El modelo de desarrollo basado en

componentes conduce ala reutilizacin del
software, y la reutilizacin proporciona
beneficios a los ingenieros de software

Beneficios del desarrollo

basado en componentes

Notracion de compontes
Diagrama de componentes
Interfaces
Componentes y los nodos
Restricciones
Anlisis del riesgo

Ventajas y desventajas
El anlisis del riesgo se hace de forma explcita y clara.
Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto - Incorpora objetivos de
calidad - Integra el desarrollo con el mantenimiento
Genera mucho tiempo en el desarrollo del sistema Modelo
costoso
Requiere
experiencia
en
la
identificacin
de
riesgos

Inconvenientes
Genera mucho trabajo adicional. Cuando un sistema
falla se pierde tiempo y coste dentro de la empresa.
Exige una cierta habilidad en los analistas (es bastante
difcil).

Transformacin
Formal
Calidad en el

Leonardo Garca Ugalde

Es el fenmeno por la cual una forma o una

organizacin de formas es sometida a
cambios que provienen de decisiones del
operador. Las transformaciones se pueden
clasificar segn en lo que se altere:
-color ( saturacin, de saturacin, cambio
de
tinte,
brillo,
etc.)
(deformacin,
Este modelo,-Estructural
propuesto por
Robert Balzeradicin,
en 1983,corte,
aplica una
interseccin,
etc.)
de transformaciones
usando un soporte automatizado
para con
-Movimiento
(rotacin,
traslacin,
una especificacin
formal (modelo
matemtico)
en un sistema
yuxtaposicin,
etc.)
implementable
(ejecutable).
Es decir, este paradigma intenta

automatizar las etapas de diseo e implementacin utilizando

el concepto de transformacin. Tambin se denomina a este
paradigma Sntesis Automtica de Software.

Listado de smbolos para una Presentacin Formal

Analista de sistemas - (Sujeto)

Nocin: Es la persona encargada deanalizar requisitos.
Es el responsable de identificar lo que elusuario finalnece
gracias a su experiencia.
Impacto: Recibe losrequisitos informales.
Para realizar sus tareas se apoya en el uso delasistente.
Determina lo que elusuario finalnecesita mas all de que este n
haya
expresado
totalmente
en
losrequisitos
informa
Mantienelaespecificacin
Analizar
Requisito - (Verbo) formal.

Nocin: Es la accin de convertir unrequisito informalen unaespeci

Es realizado por elanalista de sistemas.
Impacto: Se examinan losrequisitos informalespara extraer la inform
En conjunto con elusuario finalse analizan las soluciones plantea
necesidades del mismo.
Se evalan distintas alternativas de mejoras de losrequisitos infor
Se documenta laespecificacin formal.

Asistente (Sujeto)
Nocin: Es una herramienta que da soporte alanalista de sis
Brinda soporte aldesarrolladorpararefinarelsistema fina
Impacto: Realiza tareas de monitoreo desistemas finalesen
refinamiento.
Almacena el historial de cambios en elregistro formal de d
Es utilizado para lavalidacinyverificacin.

Cdigo fuente del compilador automtico - (Objeto)

Nocin: Son las instrucciones delcompilador automtico 2ex
de programacin especifico.
Lo genera y mantienen losdesarrolladores.
Impacto: Puede ser editado fcilmente por losdesarrolladore
Se almacena por lo general en formato digital con unasist
En base a este, se reconstruye elcompilador automtico 2

Compilador Automtico 1 - (Sujeto)

Nocin: Es la herramienta encargada detransformarunaesp
sistema final.
Impacto: Recibe como entrada unaespecificacin formal.
Aplica una serie detransformacionesde manera automti
Genera elsistema final.

Compilador Automtico 2 - (Objeto)Nocin

Nocin: Es un programa creado por losdesarrolladores.
Impacto: Para su construccin losdesarrolladoresse ajustan
en laespecificacin formal.
Para su construccin se utilizan lenguajes de programaci
que permiten definir mediante instrucciones las transform
programa ser capaz de realizar.

Desarrollador (Sujeto)
Nocin: Es la persona encargada de construir
elcompilador automtico 2.
Impacto: Posee conocimientos tcnicos que le
permiten expresar la serie
detransformacionesa
realizar en instrucciones de cdigo del compilador 2.
Utiliza elasistentepara registrar cambios y
en bsqueda de informacin relevante.
Documento de mantenimiento (Objeto)
Nocin: Es documento en el cual se registran los
cambio realizados durante
elmantenimiento.
Es completado por elanalista de sistemas.
Impacto: Posee la descripcin del cambio,
relacionando elrequisito informalcon
laespecificacin formal.
En el se menciona el origen del cambio, si

Especificacin Formal / Modelo Matemtico - (Objeto)

Nocin: Es un documento que refleja de manera
losrequisitos informales.
Impacto: Utiliza un lenguaje de expresin mucho mas ajus
cuestiones
tcnicas / matemticas.
Se lo usa como entrada para elcompilador automtico 1.
Semantienea travs de ciclos devalidacinyverificacin

Mantener - (Verbo)
Nocin: Es la accin de modificar unaespecificacin formald
de que est ms cerca de
la necesidad delusuario final.
Es realizado por elanalista de sistema.
Impacto: Se identifican mejoras a realizar en laespeci
formal.
Se evala junto con elusuario finalsi estas modificaci
ajustan a sus expectativas.

Mantener por repeticin - (Verbo)

Nocin
Es la accin demantenersin necesidad de documentar los
cambios.
Es realizado por elanalista de sistema.
Impacto
Es una accin mas informal, y con mucho contacto con elusuar
final.
Se produce una nuevaespecificacin formal.

Refinar - (Verbo)
Nocin
Es la accin de modificar elsistema finalpara obtener mayor
precisin respecto a laespecificacin formal.
Es realizado por elcompilador automtico 1.
Impacto
Se detecta una mejora y se aplica sobre laespecificacin forma
La nueva versin de laespecificacin formalse coloca como
entrada en elcompilador automtico 1.
Se genera una nueva versin delsistema finalcon las

Registro Formal de Desarrollo - (Objeto)

Nocin: Es un documento que registra
lastransformacionesllevadas a cabo sobre elcompilador
automtico 2.
Es utilizado por eldesarrollador.
Impacto: Es elasistentequien lleva un registro y control
de cambios.
Se registran las mejoras que elanalistasolicita a
losdesarrolladorescon el fin de
que
elcompilador 2se ajuste mas a las necesidades en su
capacidad de generarsistemas finales.
Requisito informal (Objeto)
Nocin: Es una necesidad delusuario finaldescrita en
lenguaje natural que debe ser
implementada dentro de
unsistema final.
Es definida por elusuario final.
Impacto: Elusuario finalexpresa su inters o necesidad.
Puede ser ampliado con mayor detalle por
elanalista de sistemas.

Simular - (Verbo)
Nocin
Es una tcnica utilizada paravalidarunaespecificacin fo
Es ejecutada por elanalista de sistemas.
Impacto
Se realiza a partir de una nuevaespecificacin formalque
requieravalidacin.
Se ejecuta antes detransformarlaespecificacin formalc
finalidad de confirmar los
cambios antes de aplicarlos.
Sistema Final - (Objeto)
Nocin
Es el software que va a ser utilizado por elusuario final.
Impacto
Es generado por elcompilador automtico 2luego de
lastransformaciones.
El mismo puede serrefinado.

Usuario Final - (Sujeto)

Nocin: Es la persona que usa elsistema final.
Es quien define losrequisitos informales.
Impacto: Especifica losrequisitos informales.
Acuerda con elanalistalos puntos que losrequisitos
informalesno hayan dejado claros.
Aprueba yvalidacambios segn sus necesidades.
Usa elsistema final.

Validar - (Verbo)
Nocin: Es la accin de comprobar en conjunto con elusuario
finalque laespecificacin formalse ajusta
a lo que este espera.
Es llevada a cabo por elanalista de sistemas.
Se realiza una vez finalizado elanlisis de requisitos.
Impacto: Se controla con elusuario final, laespecificacin
formalobtenida.
Sesimulala
ejecucin
de
unsistema
finalsegn
laespecificacin formalactual.
Se contrasta contra la realidad de las necesidades delusuario.
Se realiza elmantenimientosobre lo que sea necesario seguir

Verificar Formalmente - (Verbo)

Nocin:
Es la accin de comprobar que laespecificacin
formalse ajusta a losrequisitos informales.
Es llevada a cabo por elanalista de sistemas.
Se realiza una vez finalizado elanlisis de
requisitos.
Impacto
Laespecificacin formalobtenida se controla con
losrequisitos informales.
De existir inconsistencias se corrige
laespecificacin formal.
Sobre estas cuestiones que son necesarias
continuar ajustando, se realiza un nuevo ciclo
demantenimientoomantenimiento por
repeticin.

GRACIAS
.