Está en la página 1de 43

UNIVERSIDAD JUREZ AUTNOMA DE TABASCO

LSC. WILLIAM DAMIN DE LA CRUZ

MODELOS DE DESARROLLO DE
SOFTWARE
TRABAJO DE INVESTIGACIN PARA LA MATERIA DE
DESARROLLO DE SOFTWARE

Contenido
INTRODUCCIN .............................................................................................................................3
MODELO DE CASCADA .......................................................................................................................4
Representacin grfica ...................................................................................................................4
Etapas .............................................................................................................................................5
Ventajas y desventajas: ..................................................................................................................5
MODELO DE PROTOTIPO..............................................................................................................6
Etapas .............................................................................................................................................7
Representacin grfica ...................................................................................................................8
Ventajas y desventajas ...................................................................................................................9
MODELO ESPIRAL .........................................................................................................................9
Etapas ...........................................................................................................................................10
Representacin grfica .................................................................................................................10
Ventajas y desventajas .................................................................................................................10
MODELO DE DESARROLLO RPIDO DE APLICACIONES ....................................................11
Etapas ...........................................................................................................................................11
Representacin grfica .................................................................................................................12
Ventajas y desventajas .................................................................................................................13
MODELO ITERATIVO ..................................................................................................................13
Etapas ...........................................................................................................................................14
Representacin grafica .................................................................................................................14
Ventajas y desventajas .................................................................................................................15
MODELO DE DESARROLLO CONCURRENTE .........................................................................15
Etapas y representacin grafica ....................................................................................................16
Ventajas y desventajas .................................................................................................................17
MODELO EN V O DE CUATRO NIVELES ..................................................................................17
Etapas ...........................................................................................................................................17
Representacin grafica .................................................................................................................18
MODELO INCREMENTAL ...........................................................................................................19
Etapas ...........................................................................................................................................19
Representacin grafica .................................................................................................................20
Ventajas y desventajas .................................................................................................................20
MODELO WIN-WIN ......................................................................................................................21
Pgina 1 de 42

Etapas ...........................................................................................................................................21
Representacin grafica .................................................................................................................22
MODELO DE DESARROLLO BASADO EN COMPONENTE (reutilizacin) .............................22
Etapas ...........................................................................................................................................23
Representacin grafica .................................................................................................................24
Ventajas........................................................................................................................................24
MODELO SAMM APLICADO AL DESARROLLO DE APLICACIONES WEB ........................25
Etapas ...........................................................................................................................................26
Representacin grafica .................................................................................................................26
MODELO DE ETAPAS ..................................................................................................................27
Etapas ...........................................................................................................................................27
Representacion grafica .................................................................................................................28
MODELO DE PROCESO DE DESARROLLO UNIFICADO (RUP).............................................28
Etapas ...........................................................................................................................................29
Representacin grafica .................................................................................................................30
MODELO XP ..................................................................................................................................30
Representacin grafica .................................................................................................................31
Ventajas y desventajas .................................................................................................................32
MODELO DE DESARROLLO EVOLUTIVO................................................................................32
Etapas ...........................................................................................................................................33
Representacin grafica .................................................................................................................33
OTROS MODELOS DE DESARROLLO .......................................................................................33
PROCESO DE SOFTWARE PERSONAL (PSP) ........................................................................33
MODELO DEL COSTO DE UN PROYECTO ...........................................................................34
EL MTODO PSC .......................................................................................................................35
TCNICAS DE 4TA GENERACIN .........................................................................................36
MODELO DE TRANSFORMACIN .........................................................................................37
MODELO DE MTODOS FORMALES ....................................................................................39
CONCLUSIN ................................................................................................................................41
Bibliografa ......................................................................................................................................42

Pgina 2 de 42

INTRODUCCIN
Se puede decir que el proceso de desarrollo de software es un conjunto de herramientas,
mtodos y prcticas que se emplean para producir software. Y pueden ser vistas de la misma
forma que cualquier organizacin, ya que las dedicadas al desarrollo de software entre sus
principales fines estn la produccin de software de acuerdo con lo planificado desde el
principio del proyecto, adems de mantener un constante mejoramiento, esto con el fin de
lograr los tres objetivos principales de cualquier proceso de produccin: alta calidad, bajo
costo y en un mnimo de tiempo.
Histricamente han surgido varios enfoques que buscan abordar de manera sistemtica, la
planificacin, anlisis, diseo e implementacin de los proyectos de desarrollo de software,
sean estos de gran escala y pequeas aplicaciones, software a la medida o productos de
software. Cada uno de estos enfoques tiene su raz en las preconcepciones dominantes en su
poca y, sobre todo, en la bsqueda incesante de mejoras a los enfoques precedentes.
Sin embargo los problemas para desarrollar buen software provienen de la mala gestin
estratgica, como puede ser el entorno social y poltico de la organizacin, el nivel de
madurez y los factores humanos o del personal tcnico. Se puede decir que la incapacidad de
las tcnicas de gestin actuales para tratar el complicado factor humano ha sido el ms grande
problema que se puede encontrar al desarrollar un software
Por tal motivo con el objetivo de realizar un trabajo donde se mencione el proceso de
desarrollo de software se han desarrollado varios modelos. Cada uno de los modelos tiene
sus ventajas y desventajas. Algunos de los modelos resultan ms adecuados para algunos
tipos de proyectos y otros para otros tipos. En esta leccin presentamos los modelos ms
conocidos y otros que por su dinmica pueden ser de utilidad para el desarrollador de
software.

Pgina 3 de 42

MODELO DE CASCADA
El modelo de cascada es el ms simple y utilizado de todos los modelos. Este modelo sigue
una estructura lineal estricta en donde se asume que los requisitos nunca cambian. La
siguiente tabla resume las fases del modelo de cascada.
Fase
Estudio de viabilidad
Anlisis de requisitos

Producto
Reporte de viabilidad
Documento de especificaciones de
requisitos
Plan del proyecto
Documento de diseo del sistema
Documento del diseo detallado
Cdigo del programa
Documentos de proceso y pruebas de
integracin
Plan y resultados de las pruebas y manuales
Reporte de instalacin

Planificacin del proyecto


Diseo del sistema
Diseo detallado
Codificacin y prueba de la unidad
Integracin del sistema
Pruebas
instalacin
Operacin y mantenimiento

Representacin grfica
Estudio de
viabilidad
Anlisis de
requisitos
Planificacin del
proyecto

Diseo del
sistema
Diseo detallado
Codificacin y
prueba de la
unidad

Integracin del
sistema
Pruebas
Instalacin
Operacin y
mantenimiento

Pgina 4 de 42

Etapas

Anlisis de los requisitos del software. El proceso de reunin de requisitos se


intensifica y se centra especialmente en el software. Para comprender la naturaleza
de los programa(s) a construirse, el ingeniero (analista ) del software debe
comprender el dominio de informacin del software, as como la funcin requerida,
comportamiento, rendimiento e interconexin.
Diseo. El diseo del software es realmente un proceso de muchos pasos que se centra
en cuatro atributos distintos de programa: estructura de datos, arquitectura de
software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso
del diseo traduce requisitos en una representacin del software donde se pueda
evaluar su calidad antes de que comience la codificacin.
Generacin de cdigo. El diseo se debe traducir en una forma legible por la mquina.
El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo
de una forma detallada, la generacin de cdigo se realiza mecnicamente.
Aunque el modelo lineal es a menudo denominado modelo tradicional, resulto un
enfoque razonable cuando los requisitos se han entendido correctamente.
Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas del programa.
El proceso de pruebas se centra en los procesos lgicos internos del software,
asegurando que todas las sentencias se han comprobado, y en los procesos externos
funcionales es decir, realizar las pruebas para la deteccin de errores y asegurar que
la entrada definida produce resultados reales de acuerdo con los resultados
requeridos.
Mantenimiento. El software indudablemente sufrir cambios despus de ser
entregado al cliente (una excepcin posible es el software empotrado). Se producirn
cambios porque se han encontrado errores, porque el software debe adaptarse para
acoplarse a los cambios de su entorno externo (por ejemplo: se requiere un cambio
debido a un sistema operativo dispositivo perifrico nuevo), o porque el cliente
requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del
software vuelve a aplicar cada una de las fases precedentes a un programa ya existente
y no a uno nuevo.

Ventajas y desventajas:
Ventajas
Las ventajas que presentan el modelo de cascada tiene relacin con la idea de postular un
marco de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo
de software, permitiendo establecer relaciones de cooperacin entre ellas, adems de una
planificacin sencilla y una plantilla estructurada para ingeniera de software. Corresponden,
tambin, a los mtodos ms usados en desarrollo de software y que han sido exitosos durante
dcadas tanto en el desarrollo de grandes sistemas como en el de pequeos.
Pgina 5 de 42

Desventajas
Las mismas caractersticas que hacen que el modelo de cascada sea simple son sus puntos
dbiles. Entre las mismas estn:

Asume requisitos estticos


Implica seleccionar el hardware desde el comienzo.
Los requisitos tienen que estar establecidos completamente antes de proseguir el resto
del proceso.
Requiere mucha documentacin

Asumir que los requisitos permanecen inalterados a lo largo del desarrollo del software le
resta flexibilidad al modelo sobretodo porque es poco probable que esto ocurra. Dado que
los requisitos se asumen estticos el hardware en donde se implementar el software se puede
seleccionar desde el comienzo del desarrollo. Esto limita la capacidad del modelo para
ajustarse al uso de nuevo hardware que pueda surgir durante el proceso de desarrollo. Aunque
los primeros dos puntos se pueden flexibilizar durante el proceso de desarrollo una de las
caractersticas que menos agrada del modelo de cascada es que requiere mucha
documentacin. El modelo de cascada es, a pesar de sus limitaciones, el ms utilizado de
todos los modelos. El modelo resulta muy adecuado en el desarrollo de aplicaciones cuyas
especificaciones se conocen bastante bien.

MODELO DE PROTOTIPO
En este modelo se desarrolla un prototipo desechable del sistema con el objeto de comprender
mejor sus requisitos. Presentando el prototipo a los/las posibles usuarios/as se determina se
hacen los ajustes necesarios a los requisitos. El prototipo se mejora de forma iterativa para
refinar los requisitos hasta que se considera que no es costo efectivo seguir refinando el
mismo.
La siguiente figura muestra la estructura del modelo de prototipo. La caja de la izquierda
representa la etapa de desarrollo del prototipo el cual se puede considerar como una
aplicacin simple en s mismo.
Caractersticas del modelo de prototipo
Este modelo es adecuado para sistemas complejos y en donde no se tienen sistemas previos.
Slo aquellos componentes que provean un resultado costo-efectivos son implementados.
Aquellas partes que se conozcan bien o que resulten triviales no se implementan ya que el
objetivo del prototipo es conocer los requisitos que no se conocen bien. El proceso se termina

Pgina 6 de 42

cuando se considera que seguir desarrollando prototipos resultar ms costoso que seguir
adelante con el proceso sin desarrollarlos.

Etapas
Pertenece a los modelos evolutivos, en el cual el prototipo debe de ser construido rpidamente
y con la utilizacin escasa de recursos. El prototipo es construido para mostrrselo al cliente,
obtener crticas y retroalimentacin, con lo cual se obtendrn los requisitos especficos para
la aplicacin a partir de las metas graficas que son mostradas. Las etapas de este modelo son:
Las fases que comprende el mtodo de desarrollo orientado a prototipos seran:

Investigacin preliminar: Las metas principales de esta fase son: determinar el


problema y su mbito, la importancia y sus efectos potenciales sobre la organizacin
por una parte y, por otro lado, identificar una idea general de la solucin para realizar
un estudio de factibilidad que determine la factibilidad de una solucin software.
Definicin de los requerimientos del sistema: El objetivo de esta etapa es registrar
todos los requerimientos y deseos que los usuarios tienen en relacin al proyecto bajo
desarrollo. Esta etapa es la ms importante de todo el ciclo de vida, es aqu donde el
desarrollador determina los requisitos mediante la construccin, demostracin y
retroalimentaciones del prototipo. Por lo mismo esta etapa ser revisada con ms
detalle luego de esta descripcin.
Diseo tcnico: Durante la construccin del prototipo, el desarrollador ha obviado el
diseo detallado. El sistema debe ser entonces rediseado y documentado segn los
estndares de la organizacin y para ayudar a las mantenciones futuras. Esta fase de
diseo tcnico tiene dos etapas: por un lado, la produccin de una documentacin de
diseo que especifica y describe la estructura del software, el control de flujo, las
interfaces de usuario y las funciones y, como segunda etapa, la produccin de todo lo
requerido para promover cualquier mantencin futura del software.
Programacin y prueba: Es donde los cambios identificados en el diseo tcnico son
implementados y probados para asegurar la correccin y completitud de los mismos
con respecto a los requerimientos.
Operacin y mantencin: La instalacin del sistema en ambiente de explotacin, en
este caso, resulta de menor complejidad, ya que se supone que los usuarios han
trabajado con el sistema al hacer las pruebas de prototipos. Adems, la mantencin
tambin debera ser una fase menos importante, ya que se supone que el refinamiento
del prototipo permitira una mejor claridad en los requerimientos, por lo cual las
mantenciones perfectivas se reduciran. Si eventualmente se requiriese una
mantencin entonces el proceso de prototipado es repetido y se definir un nuevo
conjunto de requerimientos.
La fase ms importante corresponde a la definicin de requerimientos, la cual
correspondera a un proceso que busca aproximar las visiones del usuario y del
Pgina 7 de 42

desarrollador mediante sucesivas iteraciones. La definicin de requerimientos


consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo.
Anlisis grueso y especificacin: El propsito de esta subfase es desarrollar un diseo
bsico para el prototipo inicial.
Diseo y construccin: El objetivo de esta subfase es obtener un prototipo inicial. El
desarrollador debe concentrarse en construir un sistema con la mxima funcionalidad,
poniendo nfasis en la interface del usuario.
Evaluacin: Esta etapa tiene dos propsitos: extraer a los usuarios la especificacin
de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado
lo haya sido en concordancia con la definicin de requerimientos del sistema. Si los
usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente
corrige el prototipo antes de la siguiente evaluacin. El prototipo es repetidamente
modificado y evaluado hasta que todos los requerimientos del sistema han sido
satisfechos. El proceso de evaluacin puede ser dividido en cuatro pasos separados:
preparacin, demostracin, uso del prototipo y discusin de comentarios. En esta fase
se decide si el prototipo es aceptado o modificado.
Modificacin: Esto ocurre cuando la definicin de requerimientos del sistema es
alterada en la subfase de evaluacin. El desarrollador entonces debe modificar el
prototipo de acuerdo a los comentarios hechos por los usuarios.
Trmino: Una vez que se ha desarrollado un prototipo estable y completo, es
necesario ponerse de acuerdo en relacin a aspectos de calidad y de representacin
del sistema.
En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note
que la especificacin de requerimientos est claramente diferenciada de las dems.
Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que
sera una visin la solucin final en etapas tempranas del desarrollo, reduciendo
tempranamente los costos de especificaciones errneas.

Representacin grfica
Comunicacin

Plan rpido

Desarrollo, entrega
o retroalimentacin

Construccin del
prototipo

Modelado (diseo
rpido)

Pgina 8 de 42

Ventajas y desventajas
Ventajas:

Los conocimientos que se adquieren durante el desarrollo del prototipo pueden


reducir el costo del desarrollo del software ms adelante
Se ajusta mejor que el modelo de cascada a situaciones en donde los requisitos sufren
muchos cambios.
Se logra congelar los requisitos ms tarde en el proceso, cuando es de esperar que
sean ms estables.
Como tanto los desarrolladores como el cliente trabajan en el desarrollo de los
prototipos es ms probable que las especificaciones de los mismos se acerquen ms
a la realidad

Desventajas:

Da la impresin de que se pierden esfuerzos en el desarrollo de los prototipos.


En muchas ocasiones se quiere continuar el desarrollo del prototipo para crear el
producto final
No se conoce cuando se tendr un producto aceptable.
No se sabe cuntas iteraciones sern necesarias.
Da una falsa ilusin al usuario sobre la velocidad del desarrollo.
Se puede volver el producto an y cuando no este con los estndares.

MODELO ESPIRAL
El modelo en espiral, propuesto originalmente por Boehm [BOE88], es un modelo de proceso
de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con
los aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial
para el desarrollo rpido de versiones incrementales del software.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un
prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del
sistema diseado.

Pgina 9 de 42

Etapas
El modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin
llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre
el desarrollador y el cliente.
Planificacin: las tareas requeridas para definir recursos, el tiempo y otra informacin
relacionadas con el proyecto.
Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y de gestin.
Ingeniera: las tareas requeridas para construir una o ms representaciones de la
aplicacin.
Construccin y accin: las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario (por ejemplo: documentacin y prctica)
Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente segn
la evaluacin de las representaciones del software creadas durante la etapa de
ingeniera e implementada durante la etapa de instalacin.

Representacin grfica
Planificacin
Anlisis de
riesgos

Comunicacin
con el cliente

Eje de punto
de entrada de
proyecto

Evaluacin del
cliente

Ingeniera

Construccin
y adaptacin

Ventajas y desventajas
Ventajas:

A diferencia del modelo de proceso clsico que termina cuando se entrega el software
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.
Pgina 10 de 42

El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin


de prototipos en cualquier etapa de evolucin del producto.
El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en
todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos
antes de que se conviertan en problemas.
En la utilizacin de grandes sistemas ha doblado la productividad.
Es un enfoque realista para el desarrollo de software y de sistemas a gran escala.

Desventajas

No aplicable a proyectos bajo contrato.


No recomendable en proyectos simples.
Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es
controlable.
No se ha utilizado tanto como otros modelos de ciclo de vida.

MODELO DE DESARROLLO RPIDO DE APLICACIONES


El Desarrollo Rpido de Aplicaciones o RAD (Rapid Application Development) es aquel
mtodo que contempla un desarrollo de modo iterativo as como la realizacin de prototipos,
su esencia se concentra en la usabilidad y utilidad as como la rapidez de ejecucin, forma
parte al desarrollo lineal secuencial solo que la diferencia ms notable es que se lleva a cabo
en ciclos cortos, el equipo que implementa esta metodologa realiza desarrollos en periodos
cortos de tiempo.
Caractersticas

Debe contener dentro de un equipo, personas que involucran tanto su desarrollo as


como aquellos que analizan los requerimientos.
Muestra mediante modelos que contemplen los factores que permitan dar nociones a
la vida real.

Etapas
Esta metodologa est constituida por las siguientes etapas:

Modelado de Gestin. El flujo de informacin entre las funciones de gestin se


modela de forma que responda a las siguientes preguntas: Qu informacin conduce
el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va
la informacin? Quin la procesa?.
Modelado de datos. El flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios para
Pgina 11 de 42

apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de


los objetos y las relaciones entre estos objetos.
Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de informacin necesario para implementar
una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar,
suprimir, o recuperar un objeto de datos.
Generacin de aplicaciones. El DRA asume la utilizacin de tcnicas de cuarta
generacin. En lugar de crear software con lenguajes de programacin de tercera
generacin, el proceso DRA trabaja para volver a utilizar componentes de programas
ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea
necesario). En todos los casos se utilizan herramientas para facilitar la construccin
de software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, 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.

Representacin grfica
Modelado
de gestin

Modelado de
gestin

Modelado de
gestin

Modelado
de datos

Modelado de
datos

Modelado de
datos

Modelado de
procesos

Modelado de
procesos

Modelado
de procesos
Generacin
de
Pruebas y
entrega

Generacin
de
aplicaciones
Pruebas y
entrega

Generacin de
aplicaciones

Pruebas y
entrega

Inconvenientes
Este mtodo requiere de recursos suficientes, no es adecuado para riesgos tcnicos altos, por
ejemplo cuando se quiere que haya integridad junto con programas existentes dentro de la
maquina donde se quiera someter en operacin.
Pgina 12 de 42

Ventajas y desventajas
Ventajas:

Los entregables pueden ser fcilmente trasladados a otra plataforma.


El desarrollo se realiza a un nivel de abstraccin mayor.
Mayor flexibilidad.
Menor codificacin manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Ciclos de desarrollo ms pequeos.
Interfaz grfica estndar.

Desventajas

Comprar puede ser ms caro que construir.


Costo de herramientas integradas y equipo necesario.
Progreso ms difcil de medir.
Menos eficiente.
Riesgo de revertirse a las prcticas sin control de antao.
Ms fallas (por sndrome de "codificar a lo bestia").
Prototipos pueden no escalar, un problema maysculo.

MODELO ITERATIVO
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que
surge entre las necesidades del usuario y el producto final por malos entendidos durante la
etapa de recogida de requisitos.
Consiste en la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le
entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El
cliente es quien despus de cada iteracin evala el producto y lo corrige o propone mejoras.
Estas iteraciones se repetirn hasta obtener un producto que satisfaga las necesidades del
cliente.
Este modelo se suele utilizar en proyectos en los que los requisitos no estn claros por parte
del usuario, por lo que se hace necesaria la creacin de distintos prototipos para presentarlos
y conseguir la conformidad del cliente.
Caractersticas

Se desarrolla el software de forma incremental.


En primer lugar se desarrolla el ncleo del sistema, dndole prioridad a las
especificaciones que se conocen bien

Pgina 13 de 42

El proceso contiene una lista de las tareas que se desean realizar (lista de control del
proyecto) las cules se van eliminando en orden con cada iteracin
El propsito de cada iteracin es eliminar la prxima entrada en la lista - Luego de
cada iteracin se pueden realizar modificaciones, las cules se utilizarn en el
desarrollo de la prxima iteracin
Al final de cada etapa se realizan las pruebas de integracin del sistema. - Cuando
todas las tareas se remueven de la lista de control el sistema est terminado.
til cuando los desarrolladores tienen bastante control sobre los requisitos del sistema
ya que pueden establecer la lista de control ellos mismos. El modelo iterativo
bsicamente lo que hace es aplicar el modelo de prototipos de forma iterativa.

Etapas
Este tipo de modelo es esencial para el mtodo de programacin extrema. Este tipo de
programacin consiste en la realizacin de programas de manera incremental, la cual sirve
para obtener ventaja de lo que se ha realizado a lo largo del proyecto. En este se entran a
varias iteraciones con las cuales se obtendr el software final y a su vez, se le agregaran
nuevas funcionalidades a cada etapa.
Se puede dividir en los siguientes procesos:

Etapa de inicializacin. La meta de esta etapa es la construccin de un producto en el


cual se pueda obtener retroalimentacin de parte del usuario final.
Etapa de iteracin. Consiste en el anlisis, rediseo e implementacin del producto
de las iteraciones anteriores
Lista de control del proyecto. Son las tareas que se crean que describen las partes que
conforman el proyecto, son implementadas y rediseadas en cada etapa de iteracin
del producto.

Representacin grafica
Iteraciones

Iteracin 1

Iteracin 2

Iteracin 3

Iteracin N

Cada iteracin refina lo realizado en la iteracin anterior. De esta forma se produce una
dinmica en la que se van mejorando los productos (entregables) obtenidos en la iteracin
anterior. Eventualmente se realizarn todas las iteraciones planificadas, o se llegar al nivel
de refinamiento deseado

Pgina 14 de 42

Ventajas y desventajas
Ventajas
Una de las principales ventajas que ofrece este modelo es que no hace falta que los requisitos
estn totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando en cada
una de las iteraciones.
Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo en
pequeos ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregar, etc.
Desventajas
La primera de las ventajas que ofrece este modelo, el no ser necesario tener los requisitos
definidos desde el principio, puede verse tambin como un inconveniente ya que pueden
surgir problemas relacionados con la arquitectura.

MODELO DE DESARROLLO CONCURRENTE


El Modelo de Desarrollo Concurrente conocido adems como Ingeniera Concurrente dado
por Davis Sitaram, se puede representar en forma de esquema como una serie de actividades
tcnicas importantes, tareas y estados asociados a ellas.
Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor. Provee una metadescripcin del proceso del software. El modelo
concurrente tiene la capacidad de describir las mltiples actividades del software ocurriendo
simultneamente.
La mayora de los modelos de procesos de desarrollo del software son dirigidos por el tiempo
cuanto ms tarde sea, ms atrs se encontrar en el proceso de desarrollo. Un modelo de
proceso concurrente est dirigido por las necesidades del usuario, las decisiones de la gestin
y los resultados de las revisiones.
El modelo de proceso concurrente define una serie de acontecimientos que dispararn
transiciones de estado a estado para cada una de las actividades de la ingeniera del software.
Durante las primeras etapas del diseo, no se contempla una inconsistencia del modelo de
anlisis. Esto genera la correccin del modelo de anlisis de sucesos, que disparar la
actividad de anlisis del estado hecho al estado cambios en espera.
Esto genera la correccin del modelo de anlisis de sucesos, que disparar la actividad de
anlisis del estado hecho al estado cambios en espera. Es un modelo de tipo de red donde
todas las personas actan simultneamente o al mismo tiempo.
Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando
se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos
dimensiones:
Pgina 15 de 42

1. Dimensin de sistemas.
2. Dimensin de componentes.
Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseo, ensamblaje
y uso. En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo
de software y proporciona una imagen exacta del estado actual de un proyecto.
La concurrencia se logra de dos formas:
1. Las actividades de sistemas y de componentes ocurren simultneamente y pueden
modelarse con el enfoque orientado a objetos.
2. Una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada uno
de los cuales se pueden disear y realizar concurrentemente.

Etapas y representacin grafica


La Figura proporciona una representacin esquemtica de una actividad dentro del modelo
de proceso concurrente. La actividad anlisis se puede encontrar en uno de los estados'"
destacados anteriormente en cualquier momento dado. De forma similar, otras actividades
(por ejemplo: diseo o comunicacin con el cliente) se puede representar de una forma
anloga.
Ninguna

Actividad de anlisis
Bajo desarrollo

Cambios en
espera

Bajo
modificacin

Bajo revisin

En lnea
base

Realizado

Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por
ejemplo, al principio del proyecto la actividad de comunicacin con el cliente (no mostrada
en la figura) ha finalizado su primera iteracin y est en el estado de cambios, en espera. La
Pgina 16 de 42

actividad de anlisis (que estaba en el estado ninguno mientras que se iniciaba la


comunicacin inicial con el cliente) ahora hace una transicin al estado bajo desarrollo.
Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad
anlisis cambia del estado bajo desarrollo al estado cambios en espera.

Ventajas y desventajas
Ventajas:
Excelente para proyectos en los que se conforman grupos de trabajo independientes.
Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
Si no se dan las condiciones sealadas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar en este mtodo

MODELO EN V O DE CUATRO NIVELES


Se trata de un proceso ideal, por su robustez, para proyectos pequeos, con equipos de una a
cinco personas. Tambin es ideal, por su claridad, para toda esa gente que nunca ha
programado siguiendo una metodologa. Para el proyecto final de carrera o para ese cliente
que te ha conseguido un amigo de un amigo que te lo pide a ti y no se dirige a una empresa
por esto de la desaceleracin.
En qu consiste exactamente?
La figura que aparece a continuacin presenta el Modelo en V, o Modelo de Cuatro Niveles,
del ciclo de vida de un proyecto de desarrollo de software. El modelo representa, en forma
de V, las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto.

Etapas
En los niveles lgicos del 1 al 4, para cada fase del desarrollo, existe una fase correspondiente
o paralela de verificacin o validacin. Esta estructura obedece al principio de que para cada
fase del desarrollo debe existir un resultado verificable.
En la misma estructura se advierte tambin que la proximidad entre una fase del desarrollo y
su fase de verificacin correspondiente va decreciendo a medida que aumenta el nivel dentro
de la V. La longitud de esta separacin intenta ser proporcional a la distancia en el tiempo
entre una fase y su homloga de verificacin.

Pgina 17 de 42

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

Representacin grafica
Fin proyecto

Inicio
proyecto

Plan test especificaciones


Fase
especificaciones

Fase test
especificaciones

Plan test funcional


Fase
funcional

Fase test
funcional
Plan test diseo

Fase de
diseo

Fase test
diseo
Plan test

Codificacin

Tengo que hacer documentacin de todo?


Por supuesto. Cada fase tiene que estar respaldada por su documento correspondiente y test.
Por qu utilizar una metodologa?

Pgina 18 de 42

Porque es lo ms rpido y barato. Volviendo al ejemplo de la casa, imaginad la cantidad de


veces que debera volver atrs y tirar paredes ya hechas porque de pronto descubro que el
suelo es inestable, la baera no cabe, la instalacin elctrica no la haba tenido en cuenta
Pues, con el cdigo pasa exactamente lo mismo.

MODELO INCREMENTAL
El modelo incremental combina elementos del modelo lineal secuencial (aplicados
repetidamente) con la filosofa interactiva de construccin de prototipos. Los riesgos
asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de
reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para
niveles posteriores. El desarrollo incremental es el proceso de construccin siempre
incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de
requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo
incremental no demanda una forma especfica de observar el desarrollo de algn otro
incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de
desarrollo, como se muestra en la figura.

Etapas

Las fases se dividen en incrementos, en cada incremento se desarrolla una parte de la


funcionalidad y se validan los productos resultantes.
En general, una vez los productos de una fase se consideran listos, estos no se
modifican ms a lo largo de las siguientes fases.
En general, cada incremento aade funcionalidad nueva al sistema, de manera que el
usuario puede ir utilizando (validando) la funcionalidad antes de terminar el sistema
completo.
El sistema se desarrolla como una secuencia de pasos e iteraciones una vez
establecida la arquitectura global.
Los usuarios pueden experimentar con los productos resultantes de cada iteracin, y
usualmente el equipo de desarrollo puede continuar con el trabajo mientras que los
usuarios experimentan con el sistema.
En general, la idea es combinar lo mejor de las estrategias orientadas a prototipos con
una buena gestin.
En general, luego de que se valida y se termina un componente, este no se cambia (o
se procura no cambiarlo) a menos que se encuentren errores (Bugs).

Pgina 19 de 42

Representacin grafica

El modelo de desarrollo incremental provee algunos beneficios significativos para los


proyectos:

Construir un sistema pequeo es siempre menos riesgoso que construir un sistema


grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.
Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del
sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan
cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes
del comienzo del prximo incremento.

En la figura se muestra un refino del diagrama previo, bajo un esquema temporal, para
obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus
actividades genricas asociadas. Aqu se observa claramente cada ciclo cascada que es
aplicado para la obtencin de un incremento; estos ltimos se van integrando para obtener el
producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por
simplicidad, en la figura 5 se muestra como secuencial puro.
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas
en paralelo o concurrentemente, as por ejemplo, en la figura, mientras se realiza el diseo
detalle del primer incremento ya se est realizando en anlisis del segundo.

Ventajas y desventajas
Ventajas:

Pgina 20 de 42

El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo
sus desventajas slo al mbito de cada incremento.
Desventajas:
El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto
nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos.
Critica:
En este modelo se debe especificar con precisin todo lo que el sistema va a hacer antes de
desarrollarlo. Lo cual lo hace manejable y disminuira los costos.

MODELO WIN-WIN
Una variante interesante del Modelo Espiral previamente visto es el "Modelo Espiral WinWin" (Barry Boehm). El Modelo Espiral previo (clsico) sugiere la comunicacin con el
cliente para fijar los requisitos, en que simplemente se pregunta al cliente qu necesita y l
proporciona la informacin para continuar; pero esto es en un contexto ideal que rara vez
ocurre. Normalmente cliente y desarrollador entran en una negociacin, se negocia coste
frente a funcionalidad, rendimiento, calidad, etc.
"Es as que la obtencin de requisitos requiere una negociacin, que tiene xito cuando ambas
partes ganan".
Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win & Win), es
decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador tambin
gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo
requiere fuertes habilidades de negociacin.

Etapas
El modelo Win-Win define un conjunto de actividades de negociacin al principio de cada
paso alrededor de la espiral; se definen las siguientes actividades:
1 - Identificacin del sistema o subsistemas clave de los directivos (*) (saber qu quieren).
2 - Determinacin de "condiciones de victoria" de los directivos (saber qu necesitan y los
satisface)
3 - Negociacin de las condiciones "victoria" de los directivos para obtener condiciones
"Victoria & Victoria" (negociar para que ambos ganen).

Pgina 21 de 42

Representacin grafica
Identificacin
de sistema

Eje de punto
de entrada de
proyecto

Determinacin
de condiciones
de victoria

Negociacin de
las condiciones
de victoria

El modelo Win-Win hace nfasis en la negociacin inicial, tambin introduce 3 hitos en el


proceso llamados "puntos de fijacin", que ayudan a establecer la completitud de un ciclo de
la espiral, y proporcionan hitos de decisin antes de continuar el proyecto de desarrollo del
software.
Critica:
En este modelo las actividades que se definen son importantes como lo son: la identificacin
del sistema, la determinacin de las condiciones y la negociacin de estas.

MODELO DE DESARROLLO BASADO EN COMPONENTE


(REUTILIZACIN)
En la mayora de los proyectos de desarrollo de software existe la reutilizacin. Por lo general
esto sucede informalmente cuando las personas conocen diseos o cdigos similares al
requerido. Los buscan, los modifican segn lo creen necesario y los incorporan en un nuevo
sistema. El enfoque evolutivo, la reutilizacin es indispensable para el desarrollo ms gil de
un sistema. Esta reutilizacin es independiente del proceso de desarrollo que se utilice. Sin
embargo, en los ltimos aos ha surgido un enfoque de desarrollo de software denominado "
ingeniera de software basada en componentes", el cual se basa en la reutilizacin. Este
enfoque se basa en la reutilizacin y se compone de una gran base de componentes de
software que son reutilizables.
El modelo de desarrollo basado en componentes (mostrado en la figura) incorpora muchas
de las caractersticas del modelo en espiral. Es evolutivo por naturaleza, y exige un enfoque
Pgina 22 de 42

iterativo para la creacin del software. Sin embargo, el modelo de desarrollo basado en
componentes configura aplicaciones desde componentes preparados de software.
La actividad de la ingeniera comienza con la identificacin de clases candidatas. Esto se
lleva a cabo examinando los datos que se van a manejar por parte de la aplicacin y el
algoritmo que se va a aplicar para conseguir el tratamientoI2. Los datos y los algoritmos
correspondientes se empaquetan en una clase.
Las clases creadas en los proyectos de ingeniera del software anterior, se almacenan en una
biblioteca de clases o diccionario de datos.
Una vez identificadas las clases candidatas, la biblioteca de clases se examina para
determinar si estas clases ya existen. En caso de que as fuera, se extraen de la biblioteca y
se vuelven a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los mtodos
orientados a objetos. Se compone as la primera iteracin de la aplicacin a construirse,
mediante las clases extradas de la biblioteca y las clases nuevas construidas para cumplir las
necesidades nicas de la aplicacin. El flujo del proceso vuelve a la espiral y volver a
introducir por ltimo la iteracin ensambladora de componentes a travs de la actividad de
ingeniera.
El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la
reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de
reutilizacin, QSM Associates, Inc. informa que el ensamblaje de componentes lleva a una
reduccin el 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste del proyecto
y un ndice de productividad del 26.2, comparado con la norma de industria del 16.9. Aunque
estos resultados estn en funcin de la robustez de la biblioteca de componentes, no hay duda
de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros
de software.

Etapas
Aunque la etapa de especificacin de requerimientos y la revalidacin son comparables con
otros procesos, las etapas intermedias en el proceso orientado a la reutilizacin son diferentes.
Estas etapas son:

Anlisis de componentes. En esta se buscan los componentes para implementar los


con base en su especificacin. Por lo general, no existe una concordancia exacta y los
componentes que se utilizan slo proporcionan parte de la funcionalidad requerida.
Modificacin de requerimientos. En esta etapa los requerimientos se analizan
utilizando informacin acerca de los componentes que se han descubierto. Entonces
dichos componentes se modifican para reflejar los componentes disponibles, la
actividad de anlisis de componentes se puede llevar a cabo para buscar soluciones
alternativas.
Diseo del sistema con reutilizacin. En esta fase los diseadores tienen en cuenta los
componentes que se reutiliza y que se organizan el marco de trabajo para que los
Pgina 23 de 42

satisfaga. Si dichos componentes no estn disponibles se puede disear nuevos


software.
Desarrollo e integracin. El software que no se puede adquirir externamente se
desarrolla y se integra a los componentes. En este modelo, la integracin del sistema
es parte del proceso de desarrollo, ms que una actividad separada.

Adems pueden tomarse las siguientes fases:

Bosquejar los requerimientos del sistema.


Buscar componentes reutilizables ((COTS) (Ej. Aplicaciones Listas o Casi Listas).
Modificar requerimientos acorde a los componentes encontrados + modificar
componentes encontrados.
Diseo arquitectnico.
Buscar componentes reutilizables (COTS) (Ej. Libreras, Frameworks u otros).
Disear el sistema utilizando los componentes reutilizados.
Modificar componentes encontrados.

Representacin grafica
Identificar
componentes
candidatos

Planificacin
Anlisis de
riesgos

Comunicacin
con el cliente

Construir la
iteracin del
sistema

Eje de punto
de entrada de
proyecto

Evaluacin del
cliente

Ingeniera

Construccin
y adaptacin

Buscar
componentes en
biblioteca

Poner nuevos

Extraer

componentes en
la biblioteca

componentes sisi
estn disponibles

Modificar
componentes si

Ventajas
El modelo de desarrollo de software basado en componentes creado por Boehm (1988), tiene
la ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los
costos y los riesgos. Tambin permite una entrega ms rpida del software. Sin embargo, los
compromisos a los requerimientos son inevitables y esto da lugar a un sistema que no cumpla
con las necesidades reales de los usuarios. Pressman (2006), detecto que: El software de
computadoras moderno se caracteriza por el cambio continuo, los tiempos de entrega son
muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el
Pgina 24 de 42

tiempo de llegada al mercado es el requisito de gestin ms importante. Si se pierde una


ventana del mercado, el mismo proyecto de software puede perder su significado.

MODELO SAMM APLICADO AL DESARROLLO DE


APLICACIONES WEB
Las aplicaciones Web son programas de software que los usuarios pueden utilizar accediendo
a ellas a travs de un navegador como Internet Explorer, Firefox, Safari y Chrome, entre
otros. Muchas de estas aplicaciones son desarrolladas a la medida y frecuentemente los
requerimientos de seguridad no son tomados en cuenta durante el proceso de desarrollo o
adquisicin de la aplicacin, lo cual s sucede por ejemplo con las caractersticas de
funcionalidad, diseo visual, y uso.
Lograr aplicaciones Web seguras solo es posible cuando se utiliza un ciclo de desarrollo de
software seguro (SDLC, Software Development Life Cycle), para lo cual OWASP
recomienda que las organizaciones establezcan una base slida de formacin, estndares y
herramientas que hagan posible la codificacin segura. Por encima de esa base las
organizaciones deben integrar la seguridad a su desarrollo, verificacin y procesos de
mantenimiento que a su vez permitan a la gerencia utilizar los datos generados para gestionar
los costos y riesgos asociados a la seguridad en aplicaciones.
El modelo SAMM (Software Assurance Maturity Model), el cual es un marco de trabajo
abierto que ayuda a definir y estructurar una estrategia de seguridad en el desarrollo de
software basada en los riesgos especficos que enfrenta cada organizacin. En este artculo
se toma como referencia el modelo SAMM y se proporciona una gua de los controles que
se deben implementar en cada una de las prcticas de seguridad del modelo.

Entendiendo el modelo SAMM


El modelo se fundamenta en desarrollar el software de acuerdo a las funciones crticas del
negocio y cuenta con 3 niveles de madurez definidos a travs de 12 prcticas de seguridad,
estas prcticas determinan una variedad de actividades que deben ser implementadas en la
organizacin para reducir los riesgos de seguridad e incrementar el aseguramiento del
software.
El modelo SAMM fue diseado para ser flexible, de tal manera que puede ser adoptado por
cualquier tamao de organizacin y fue construido bajo los siguientes principios:

Cambios paulatinos en la organizacin.- Un programa de seguridad exitoso deben ser


implementado en pequeas iteraciones, lo cual permitir producir entregables
tangibles y de valor para la organizacin en el corto plazo, los cuales se pueden ir
incrementando para el logro de metas a largo plazo.
Pgina 25 de 42

No existe una receta nica que funcione en todas las organizaciones.- Un marco de
trabajo de seguridad de software debe ser flexible y permitir poner en marcha los
controles necesarios basndose en el nivel de riesgo de la organizacin.
Establecimiento de una directriz de seguridad.- Las actividades de un programa de
aseguramiento deben estar bien definidas, ser prcticas y medibles.

Etapas
SAMM define cuatro funciones crticas de negocio de alto nivel. Cada funcin es una
categora de actividades que la organizacin debe cumplir en el proceso de desarrollo de
software. Estas funciones son:
I.

II.

III.

IV.

Gobernabilidad. Est centrada en la definicin de la estrategia, en los procesos y


polticas relacionadas a cmo una organizacin debe gestionar el SDLC (Software
Development Life Cycle).
Construccin. Se refiere a los procesos y actividades que la organizacin debe seguir
para el desarrollo de la aplicacin, lo cual incluye la administracin del producto,
recoleccin de requerimientos, especificaciones de la arquitectura a alto nivel,
definicin del diseo detallado e implementacin de la aplicacin.
Verificacin. Se enfoca a los procesos relacionados a la revisin y pruebas de los
artefactos producidos durante el desarrollo del software; incluye aseguramiento de
calidad y diferentes tipos de pruebas.
Implementacin. Se refiere a las actividades relacionadas a la liberacin de la
aplicacin.

Representacin grafica
Desarrollo
de software

Gobernabilidad

Estrategia y
mtricas de
seguridad

Construccin

Capacitacin

Revisin de
seguridad

Anlisis de
amenazas

Polticas y
cumplimiento

Requerimientos
de seguridad

Verificacin

Arquitectura
de
seguridad

Pruebas de
seguridad

Revisin de
cdigo

Implementacin

Gestin de
vulnerabilid
ades

Endurecimiento
de los
ambientes

Habilitacin
operativa

Pgina 26 de 42

MODELO DE ETAPAS
Modelo lineal que considera que cada etapa debe ir a continuacin de la anterior, que pone
nfasis en la documentacin que resulta de cada una y que es la entrada de la siguiente. Todo
tendiente a conformar una cadena de produccin de software Sage (1956)
En 1956, el enfrentarse a un gran sistema de software como el SemiAutomated Ground
Environment (SAGE) hizo que se reconocieran los problemas inherentes a la codificacin y
esto llev al desarrollo del modelo de etapas, con el objetivo de poder mejorar estos nuevos
problemas.

Etapas
Este modelo estipula que el software ser desarrollado en sucesivas etapas:

Plan operativo. Etapa donde se define el problema a resolver, las metas del proyecto,
las metas de calidad y se identifica cualquier restriccin aplicable al proyecto.
Especificacin de requerimientos. Permite entregar una visin de alto nivel sobre el
proyecto, poniendo nfasis en la descripcin del problema desde el punto de vista de
los clientes y desarrolladores. Tambin se considera la posibilidad de una
planificacin de los recursos sobre una escala de tiempos.
Especificacin funcional. Especifica la informacin sobre la cual el software a
desarrollar trabajar.
Diseo. Permite describir como el sistema va a satisfacer los requerimientos. Esta
etapa a menudo tiene diferentes niveles de detalle. Los niveles ms altos de detalle
generalmente describen los componentes o mdulos que formarn el software a ser
producido. Los niveles ms bajos, describen, con mucho detalle, cada mdulo que
contendr el sistema.
Implementacin. Aqu es donde el software a ser desarrollado se codifica.
Dependiendo del tamao del proyecto, la programacin puede ser distribuida entre
distintos programadores o grupos de programadores. Cada uno se concentrar en la
construccin y prueba de una parte del software, a menudo un subsistema. Las
pruebas, en general, tienen por objetivo asegurar que todas las funciones estn
correctamente implementadas dentro del sistema.
Integracin. Es la fase donde todos los subsistemas codificados independientemente
se juntan. Cada seccin es enlazada con otra y, entonces, probada. Este proceso se
repite hasta que se han agregado todos los mdulos y el sistema se prueba como un
todo.
Validacin y verificacin. Una vez que el sistema ha sido integrado, comienza esta
etapa. Es donde es probado para verificar que el sistema es consistente con la
definicin de requerimientos y la especificacin funcional. Por otro lado, la
verificacin consiste en una serie de actividades que aseguran que el software

Pgina 27 de 42

implementa correctamente una funcin especfica. Al finalizar esta etapa, el sistema


ya puede ser instalado en ambiente de explotacin.
Mantencin. La mantencin ocurre cuando existe algn problema dentro de un
sistema existente, e involucrara la correccin de errores que no fueron descubiertos
en las fases de prueba, mejoras en la implementacin de las unidades del sistema y
cambios para que responda a los nuevos requerimientos. Las mantenciones se puede
clasificar en: correctiva, adaptativa, perfectiva y preventiva.

Representacion grafica
Plan operativo

Especificacin de
requerimientos

Especificacin
funcional

Diseo

Implementacin

Integracin

Validacin y
verificacin

Mantencin

MODELO DE PROCESO DE DESARROLLO UNIFICADO (RUP)


Durante varios aos se ha utilizado el modelo tradicional en cascada, demostrando en la
prctica que no refleja en la realidad la complejidad inherente al proceso de desarrollo de
software. Este problema es derivado de la naturaleza implcita de la estructura de este
modelo, definido por una secuencia de grandes etapas que requieren alcanzar hitos que deben
ser concluidos antes de continuar con la siguiente fase.
Como una alternativa de solucin a este problema, se definieron posteriormente los modelos
iterativos e incrementales que trabajan adecuadamente con niveles altos de riesgo, y permiten
entregar liberaciones de software en etapas tempranas tal es el caso del Proceso Unificado
propuesto por IBM, que incluye prcticas claves y aspectos relacionados a la planeacin
estratgica y administracin de riesgos y actualmente guan de forma natural el proceso de

Pgina 28 de 42

desarrollo de software complejo por lo que ha sido considerado como un estndar el


desarrollo de software en las empresas.
El proceso unificado conocido como RUP, es un modelo de software que permite el
desarrollo de software a gran escala, mediante un proceso continuo de pruebas y
retroalimentacin, garantizando el cumplimiento de ciertos estndares de calidad. Aunque
con el inconveniente de generar mayor complejidad en los controles de administracin del
mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo invertido en este
aspecto.
El proceso de desarrollo constituye un marco metodolgico que define en trminos de metas
estratgicas, objetivos, actividades y artefactos (documentacin) requerido en cada fase de
desarrollo. Esto permite enfocar esfuerzo de los recursos humanos en trminos de
habilidades, competencias y capacidades a asumir roles especficos con responsabilidades
bien definidas.

Etapas

Fase de concepcin. Esta fase tiene como propsito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos potenciales asociados al
proyecto, proponer una visin muy general de la arquitectura de software y producir
el plan de las fases y el de iteraciones.
Fase de elaboracin. En la fase de elaboracin se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se
realiza la especificacin de los casos de uso seleccionados y el primer anlisis del
dominio del problema, se disea la solucin preliminar.
Fase de construccin. El propsito de esta fase es completar la funcionalidad del
sistema, para ello se deben clarificar los requerimientos pendientes, administrar los
cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
Fase de transicin. El propsito de esta fase es asegurar que el software est
disponible para los usuarios finales, ajustar los errores y defectos encontrados en las
pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario.
Se debe verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.

Pgina 29 de 42

Representacin grafica

Desventajas
Este tipo de metodologa no ha sido aplicada probablemente por su complejidad de
administracin o desconocimiento de la misma, desaprovechando sus considerables ventajas
respecto a los mtodos tradicionales. Por esto, es necesario entonces desarrollar mecanismos
de apropiacin tecnolgica ms eficaces, que permitan mantener actualizadas las prcticas
organizacionales y los marcos de referencia aqu mencionados. Es aqu, donde es necesario
considerar que el conocimiento de la metodologa y desarrollo de habilidades de los analistas,
programadores, administradores de bases de bases de datos y dems miembros del equipo de
desarrollo, comienzan desde su preparacin universitaria donde es necesario conocer este
enfoque y aplicarlo en proyectos en donde utilicen las guas de trabajo definidas en el RUP
y desarrollen los artefactos asociados esperando que con la prctica alcancen un nivel de
madurez en la asimilacin del proceso unificado (RUP).

MODELO XP
La programacin extrema (XP) es un modelo de proceso de software que toma los principios
y practicas aceptadas, y las lleva a niveles extremos.
Las creencias de modelo son las siguientes:

Los cambios en un sistema son frecuentes.


Se deben manejar los cambios de manera incremental.
Se debe apoyar los cambios.
Se debe lograr una rpida retroalimentacin.
Se debe lograr un trabajo de calidad.
Se debe buscar la simpleza.

Pgina 30 de 42

Los equipos de desarrollo trabajan directamente con el cliente durante interaccin


con el usuario. ciclos cortos de una o dos semanas como mximo.
La entrega de las versiones del software ocurre muy temprano y en intervalos muy
cortos para maximizar la
Existe una fuerte colaboracin entre el equipo de desarrollo mientras trabaja en el
cdigo.
El cdigo se prueba y depura a lo largo del proceso de desarrollo.
Existen indicadores que miden el progreso del proyecto para poder actualizar el
plan de desarrollo.

Representacin grafica

Variables

La metodologa XP define cuatro variables para cualquier proyecto de software:


costo, tiempo, calidad y alcance.
Adems, se especifica que, de estas cuatro variables, slo tres de ellas podrn ser
fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes
y jefes de proyecto).
El valor de la variable restante podr ser establecido por el equipo de desarrollo,
en funcin de los valores de las otras tres.

Pgina 31 de 42

Ventajas y desventajas
Ventajas:

Cambios en los objetivos y prioridades son naturales.


Sin sobrecarga al equipo de desarrollo
El cliente desde las primeras etapas tiene software que puede usar y probar.
En cualquier momento puede parar el desarrollo, quedndose con un producto
que representa lo invertido hasta esa fecha.

Desventajas:

Es necesario un representante del cliente en todo momento del desarrollo.


Todo el proceso de desarrollo se basa en la comunicacin, si la misma es
costosa o lenta perjudica enormemente el tiempo y costo del desarrollo.
No sirve para proyectos grandes debido a sus requerimientos de
comunicacin.

MODELO DE DESARROLLO EVOLUTIVO


Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces
denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas
de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el
conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume
que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que
son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores
construyen una implementacin parcial del sistema que recibe slo estos requerimientos.
Pgina 32 de 42

Etapas
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los
desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es
actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se
repite indefinidamente.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin
de documentos, programas, datos de test, etc. desarrollados para distintas versiones del
software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad,
los cambios deben ser efectuados de una manera controlada.

Representacin grafica
Especificacin
inicial

Desarrollo del
producto

Implementacin,
uso y evolucin
Versiones del
software

Re-especificacin

OTROS MODELOS DE DESARROLLO


PROCESO DE SOFTWARE PERSONAL (PSP)
Mejora la planeacin del trabajo, conoce con precisin el desempeo mide la calidad de los
productos y mejora las tcnicas para su desarrollo.
Tambin muestra cmo aplicar mtodos avanzados de ingeniera a sus proyectos y/o deberes
diarios. Asimismo provee mtodos de estimacin y de planeacin muy bien detallados que
son necesarios para dar un seguimiento a su trabajo.
Pgina 33 de 42

Fases del PSP

Descripcin del problema


Especificacin de componentes
Formas de proceso
Estimadores del tamao del producto y tiempos en base a histricos

Representacin grafica

MODELO DEL COSTO DE UN PROYECTO


Otro punto de vista para el ciclo de vida de desarrollo de un producto de programacin es la
consideracin del costo de la realizacin de las distintas actividades del proyecto. El costo de
un proyecto es la suma de los costos incurridos en cada fase, y stos, a su vez, incluyen los
costos de la realizacin de los procesos y preparacin de los documentos de esa fase, ms los
costos de verificacin de la consistencia de estos productos con los de las fases previas.
Las modificaciones y correcciones a los productos de las fases previas son necesarias, dado
que durante el desarrollo de la fase actual se encontrarn imprecisiones, inconsistencias y
omisiones en sus productos y, adems, porque los requisitos, programacin, prioridades o
presupuesto del cliente pueden cambiar, hecho que producira modificaciones.
El costo de produccin de la Definicin del sistema y del Plan del proyecto es el mismo de
realizar las planeacin y preparacin de los documentos, ms el costo de verificacin de que
la Definicin del sistema establece precisamente las necesidades del cliente y el costo de
verificacin de que el Plan del proyecto es factible.
El costo de preparacin de la Especificacin de requisitos para la produccin de software
incluye el costo de definir requisitos y preparar documentos, ms el costo de modificar y
corregir la Definicin del sistema y el Plan del proyecto, ms el costo de verificacin de que
Pgina 34 de 42

la Especificacin est completa y sea consistente con respecto a la Definicin del sistema y
las necesidades del cliente.
De la misma manera, el costo del diseo es el costo de las actividades propias y la generacin
de los documentos, ms el costo de modificar y corregir la Definicin del sistema, el Plan del
proyecto y la Especificacin de requisitos para la produccin de software, ms el costo de
verificacin del diseo contra los requisitos, la Definicin del sistema y el Plan del proyecto.
El costo de la instrumentacin del producto es el costo de la conversin, documentacin,
depuracin y pruebas del cdigo fuente, ms el costo de la terminacin del Manual del
usuario, el plan de verificacin, los procedimientos de mantenimiento, y las instrucciones de
instalacin y entrenamiento, ms el costo de modificar y corregir la Definicin del sistema,
el Plan del proyecto, la Especificacin de requisitos para la produccin de software, la
Especificacin del diseo, y el Plan de verificacin ms el costo de verificacin de que la
instrumentacin est completa y sea consistente con respecto a la Definicin del sistema, la
Especificacin de requisitos para la produccin de software y los documentos del diseo.
El costo de las pruebas del sistema incluye el costo de planear y llevar a cabo las pruebas,
ms el costo de las modificaciones al cdigo fuente y a los documentos externos durante
ellas, ms el costo de verificacin de que las pruebas validan adecuadamente al producto.
Por ltimo, el costo del mantenimiento es la suma de los costos de llevar a cabo mejoras al
sistema, hacer adaptaciones para nuevas condiciones de operacin, y encontrar fallas. Cada
una de estas actividades puede comprender la modificacin de alguno o de todos los
documentos y la ejecucin de un gran nmero de casos de prueba para verificar la correccin
de la modificacin.
Dado este punto de vista del ciclo de vida de un producto, no es difcil entender por qu es
tan caro efectuar modificaciones o correcciones a la Especificacin de requisitos e para la
produccin de software o documentos del diseo cuando se estn en fases posteriores. No
slo se deben modificar los documentos, sino que todos los productos intermedios deben
actualizarse, y en cada fase siguiente se necesitan coordinar ms gente y ms detalles.

EL MTODO PSC
Este modelo toma otro enfoque, igualmente valido, para la modelaci6n del proceso de
desarrollo al aceptar que varios puntos de vista o perspectivas sean considerados. Las
principales perspectivas descritas dentro del FSC son:

Etapas

Pragmtica. Visualiza al sistema en el contexto de su ambiente.


Entrada/Salida. Estudia el comportamiento externo del sistema y c6mo va a ser
adquirido.
Pgina 35 de 42

Constructiva. Examina el sistema en trminos de una colecci6n de funciones y


recursos.
Operativa Estudia el comportamiento interno del sistema.

El uso del PSC involucra (como el de espiral) cuatro fases principales. Esta vez, cada una de
las fases concierne a los problemas de decisin de una de las perspectivas anteriores. El
modelo identifica la pragmtica como el nivel ms abstracto. En esta fase, el sistema se
estudia en trminos de su relacin con y su efecto en el ambiente en el que va a ser colocado.
El modelo necesita que el diseo, la prueba y el aseguramiento sean completados en este
nivel de abstracci6n antes de moverse a la siguiente fase.

TCNICAS DE 4TA GENERACIN


El trmino tcnicas de cuarta generacin (T4G) abarca un amplio espectro de herramientas
de software que tienen algo en comn: todas facilitan al ingeniero del software la
especificacin de algunas caractersticas del software a alto nivel. Luego, la herramienta
genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Cada
vez parece ms evidente que cuanto mayor sea el nivel en el que se especifique el software,
ms rpido se podr construir el programa. El paradigma T4G para la ingeniera del software
se orienta hacia la posibilidad de especificar el software usando formas de lenguaje
especializado o notaciones grficas que describa el problema que hay que resolver en
trminos que los entienda el cliente.
Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede
incluir todas o algunas de las siguientes herramientas: lenguajes no procedimentales de
consulta a bases de datos, generacin de informes, manejo de datos, interaccin y definicin
de pantallas, generacin de cdigos, capacidades grficas de alto nivel y capacidades de hoja
de clculo, y generacin automatizada de HTML y lenguajes similares utilizados para la
creacin de sitios web usando herramientas de software avanzado. Inicialmente, muchas de
estas herramientas estaban disponibles, pero slo para mbitos de aplicacin muy
especficos, pero actualmente los entornos T4G se han extendido a todas las categoras de
aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunin de requisitos.
Idealmente, el cliente describe los requisitos, que son, a continuacin, traducidos
directamente a un prototipo operativo. Sin embargo, en la prctica no se puede hacer eso.
El cliente puede que no est seguro de lo que necesita puede ser ambiguo en la especificacin
de hechos que le son conocidos y puede que no sea capaz o no est dispuesto a especificar la
informacin en la forma en que puede aceptar una herramienta T4G. Por esta razn, el
dilogo cliente desarrollador descrito por los otros paradigmas sigue siendo una parte
esencial del enfoque T4G

Pgina 36 de 42

MODELO DE TRANSFORMACIN
Desde la perspectiva de la evolucin del software y las leyes de Lehman, se hace una revisin
del ciclo de vida del software, el cual lleva al desarrollo de un mtodo que se podra
denominar el modelo de transformacin.
Desde la ptica de lan Sommerville, este modelo se caracteriza por que... un concepto de
aplicacin se transforma de modo paulatino en una especificacin formal de software. Esto
implica la reduccin de la cantidad de informacin bruta en cada etapa de la transformacin,
proceso que el denomina abstraccin. Una vez establecida la especificacin, se aade la
informacin (a esto le llama materializacin) y el sistema abstracto se transforma, mediante
un conjunto de notaciones formales, en un programa operacional.
Las bases de una concepcin de transformacin en el desarrollo de software, las explica el
mismo Lehman (1980). Al considerar una clasificacin de los programas y, mediante sta,
definir un mtodo sistemtico que permita transformar programas de una clase ms compleja
en otra de complejidad menor.
La clasificacin est basada en el reconocimiento del hecho que cualquier programa es un
modelo de un modelo dentro de una teora de un modelo de una abstraccin de alguna porcin
del mundo o de algn universo del discurso. La clasificacin categoriza a los programas en
tres clases, S, P y E.
ProgramasS.
Los ProgramaS son aquellos cuya funcin puede ser definida formalmente por y derivable
desde, una especificacin.... Las sentencias del problema, el programa y la solucin, cuando
es obtenida, puede relacionarse con un mundo externo. Pero esto es una relacin casual y no
causal. En efecto, cuando esto existe somos libres para cambiar nuestro inters y redefinir el
problema. Pero el resultado de esto es un nuevo programa para esta solucin. Puede ser
posible y eficiente derivar el nuevo programa desde el antiguo. Pero es un programa diferente
que define una solucin para un problema diferente.
Programas PE
En los Programas P (solucin de problemas del mundo real)... a despecho de el hecho de que
el problema a ser resuelto pueda ser definido precisamente, la aceptacin de la solucin est
determinada por el medio ambiente en que est involucrada. La solucin obtenida ser
evaluada por comparacin con el medio ambiente real... En los Programas S, el juicio sobre
la correccin, y por lo tanto el valor, del programa est relacionado con la definicin
solamente de esta especificacin, las sentencias del problema que debe ser reflejado. En los
Programas P, el asunto no est centrado en el problema pero si sobre el valor y la validez de
la solucin obtenida, esto es sobre el contexto del mundo real.

Pgina 37 de 42

Programas E.
La tercera clase, los Programas E, estn inherentemente ms inclinados al cambio. Estos son
programas que mecanizan una actividad humana o social... La instalacin de los programas
junto con este sistema asociado...cambia la real naturaleza del problema a ser resuelto, el
programa puede hasta convertirse en parte del mundo que el mismo modela, est embebido
en l. No como otros sistemas artificiales donde,..., el cambio es ocasional, aqu este aparece
continuamente. La presin del cambio est construida con l. Los Programas P y E estn
estrechamente relacionados, podemos establecer la clase unin de P y E como
ProgramasA.
stos difieren de los ProgramasS en el sentido que representan una aplicacin computacional
en el mundo real.
Los programas son siempre probablemente correctos... muchos de los componentes ms
importantes de un gran programa son del tipo S... un ProgramaA puede siempre ser
particionado y estructurado de manera que todos sus elementos sean ProgramasS.
En esta ltima afirmacin est el trasfondo de la idea de Lehman en relacin a la posibilidad
de definir un metalenguaje que permita reducir programas complejos o "del mundo real" a
especificaciones formales de programas. As, segn Boehm: el modelo de transformacin
asume la existencia de una capacidad de automticamente convertir una especificacin
formal de un producto de software en un programa que satisfaga la especificacin.

Pasos

Los pasos que son prescritos por el modelo de transformacin son:


Una especificacin formal de la mejor comprensin inicial del producto deseado.
Transformacin automtica de la especificacin en cdigo.
Un ciclo iterativo, si es necesario, para mejorar la ejecucin de el cdigo resultante
para dar una gua de optimizacin al sistema de transformacin.
Probar el producto resultante, y
Un ciclo interactivo externo para ajustar las especificaciones basadas en el resultado
de la experiencia operacional, y para rederivar, reoptimizar, y probar el producto de
software ajustado.

Ventajas y desventajas
El modelo de transformacin evita las dificultades de tener que modificar un cdigo que tiene
una estructuracin muy pobre debido a las repetidas optimizaciones , mediante la posibilidad
de que las modificaciones sean fabricadas a travs de las especificaciones, esto sin intervenir
el cdigo, el cual se reconstruira cada vez.
Con este modelo se puede aumentar, al menos tericamente, la capacidad de dar respuesta
rpida a la evolucin que connaturalmente estara asociada a las organizaciones, pero, al igual
Pgina 38 de 42

que el modelo espiral, se ha alejado del problema central que se ha discutido hasta ahora, que
es cmo acortar la brecha conceptual entre los dominios del desarrollador y del usuario, si es
que es posible.
En relacin a este ltimo y central problema, la crtica que se puede hacer al modelo de
transformacin es que necesariamente al transformar un problema del tipo A en problemas
S, se est aplicando un reduccionismo que, probablemente, limite la expresin de toda la
complejidad del problema original, particularizando la solucin a casos en que sea dable
resolver sistemticamente y dejando fuera situaciones en que esta formalizacin no sea
posible. En ese sentido, no sera factible que todos los problemas A sean transformables a
unidades S. Adems, esto no evita la necesidad de tener que caracterizar un problema del
tipo A, lo que remitira necesariamente a la cuestin original.

MODELO DE MTODOS FORMALES


El modelo de mtodos formales comprende un conjunto de actividades que conducen a la
especificacin matemtica del software de computadora. Los mtodos formales permiten que
un ingeniero de software especifique, desarrolle y verifique un sistema basado en
computadora aplicando una notacin rigurosa y matemtica.
Algunas organizaciones de desarrollo del software actualmente aplican una variacin de este
enfoque, llamado ingeniera del software de sala limpia [MIL87, DYE921.
Cuando se utilizan mtodos formales durante el desarrollo, proporcionan un mecanismo para
eliminar muchos de los problemas que son difciles de superar con paradigmas de la
ingeniera del software. La ambigedad, lo incompleto y la inconsistencia se descubren y se
corrigen ms fcilmente no mediante un revisin a propsito para el caso, sino mediante la
aplicacin del anlisis matemtico. Cuando se utilizan mtodos formales durante el diseo,
sirven como base para la verificacin de programas y por consiguiente permiten que el
ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera.

Desventajas
Aunque todava no hay un enfoque establecido, los modelos de mtodos formales ofrecen la
promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran
preocupacin sobre su aplicabilidad en un entorno de gestin:

El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo.


Se requiere un estudio detallado porque pocos responsables del desarrollo de software
tienen los antecedentes necesarios para aplicar mtodos formales.
Es difcil utilizar los modelos como un mecanismo de comunicacin con clientes que
no tienen muchos conocimientos tcnicos.
Pgina 39 de 42

No obstante es posible que el enfoque a travs de mtodos formales tenga ms partidarios


entre los desarrolladores del software que deben construir software de mucha seguridad (por
ejemplo: los desarrolladores de avinica y dispositivos mdicos), y entre los desarrolladores
que pasan grandes penurias econmicas al aparecer errores de software.

Pgina 40 de 42

CONCLUSIN
El uso de la los diferentes modelos de desarrollo de software mencionados en este trabajo
constituyen una herramienta de trabajo en funcin de la calidad para orientar a las empresas
o desarrolladores de software.
La aplicacin de los modelos y estndares disponibles para el control de la calidad del
software deben ser valorados durante la aplicacin de los mismos tomando en cuenta la
experiencia que tiene el personal encargado de desarrollar el software, la composicin del
equipo de trabajo, las exigencias y expectativas del cliente y los alcances que puede llegar a
tener el software, asegurndonos de seleccionar correctamente el modelo o tcnica que ms
se ajuste para la validacin, verificacin y control de calidad en los procesos de desarrollo de
software
Aplicar los diferentes modelos es importante para el desarrollo de software ya que esto
aumenta la posibilidad de producir softwares de calidad, pero tambin la mala aplicacin se
puede traducir en un gasto innecesario.

Pgina 41 de 42

Bibliografa
Abdelhamid t. K., madnick s. E., software project dynamics:
An integrated approach, englewood cliffs, nj: prenticehall 1991.
Allsoft s.a. De c.v. Monterrey, n.l.
Aracil j., gordillo, f. Dinmica de sistemas. Alianza editorial, madrid 1997.
Demin, gutirrez julio 2011 universidad de los andes
Gonzlo, c.a., gestin del proceso de software. 2003, madrid, espaa.
Genero m., p.m.y.c.c., metrics for sotware conceptual models. 2004, londres: imperial college press.
Interamericana de espaa, s.a.
Instituto tecnologico superior de villa la venta fundamentos de desarrollo de sistema
Ivar jacobson, g.b., james rumbaugh, el proceso unificado de desarrollo de software. 2000: addison wesley
longman inc.
Marck norris y peter rigby ingeniera de software explicada
Pressman, r.s., ingenieria de software, un enfoque prctico. Quinta edicin ed. 2002, madrid: mc grawhill,

Richard fairley ingeniera de software


Http://ingenieraupoliana.blogspot.mx/2010/10/modelodedesarrolloconcurrente.Html
Blogspot.mx/2012/09/ingenieriadesoftwarecontinuacion.Html
Http://www.magazcitum.com.mx/?p=1416
Http://heyssellopez.blogspot.mx/2010/10/modelosdedesarrollodesoftware.Html
Http://ingenexescom.blogspot.mx/2012/02/modelodedesarrollorapidode.Html
http://www.iiia.csic.es/udt/es/blog/jrodriguez/2008/metodologiadesarrollosotwaremodeloenvocuatroniveles
http://www.inf.udec.cl/~gdonoso/software/isenfoques.html
http://www.elconspirador.com/2013/08/19/modelosdedesarrollodesoftware/
Http://www.eumed.net/librosgratis/2011a/896/modelos%20de%20desarrollo%20de%20software.html

Pgina 42 de 42

También podría gustarte