-
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
-
Pgina 1 de 42
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 2 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 3 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 4 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 Producto
Estudio de viabilidad Reporte de viabilidad
Anlisis de requisitos Documento de especificaciones de
requisitos
Planificacin del proyecto Plan del proyecto
Diseo del sistema Documento de diseo del sistema
Diseo detallado Documento del diseo detallado
Codificacin y prueba de la unidad Cdigo del programa
Integracin del sistema Documentos de proceso y pruebas de
integracin
Pruebas Plan y resultados de las pruebas y manuales
instalacin Reporte de 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 5 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 6 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 7 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 8 de 42
Comunicacin
Desarrollo, entrega
o retroalimentacin
Construccin del
prototipo
Modelado (diseo
rpido)
Plan rpido
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
-
Pgina 9 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 10 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
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.
Planificacin
Comunicacin
con el cliente
Eje de punto
de entrada de
proyecto
Evaluacin del
cliente Construccin y adaptacin
Ingeniera
Anlisis de
riesgos
-
Pgina 11 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 12 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
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.
Modelado de
gestin
Pruebas y
entrega
Generacin de
aplicaciones
Modelado de
procesos
Modelado de
datos
Modelado de
gestin
Pruebas y
entrega
Generacin
de
aplicaciones
Modelado de
procesos
Modelado de
datos
Modelado
de gestin
Pruebas y
entrega
Generacin
de
Modelado
de procesos
Modelado
de datos
-
Pgina 13 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 14 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
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
Iteraciones
Iteracin 1 Iteracin 2 Iteracin 3 Iteracin N
-
Pgina 15 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 16 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.
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
Ninguna
Realizado
En lnea
base
Bajo revisin
Bajo
modificacin
Cambios en
espera
Bajo desarrollo
Actividad de anlisis
-
Pgina 17 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 18 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
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?
Inicio
proyecto
Codificacin
Fase test
diseo
Fase de
diseo
Fase test
funcional
Fase
funcional
Fase test
especificaciones
Fin proyecto
Fase
especificaciones
Plan test especificaciones
Plan test funcional
Plan test diseo
Plan test
-
Pgina 19 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 20 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 21 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 Win-
Win" (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 22 de 42
Representacin grafica
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
Identificacin
de sistema
Eje de punto
de entrada de
proyecto
Negociacin de
las condiciones
de victoria
Determinacin
de condiciones
de victoria
-
Pgina 23 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 24 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
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
Planificacin
Comunicacin
con el cliente
Eje de punto
de entrada de
proyecto
Evaluacin del
cliente Construccin y adaptacin
Ingeniera
Anlisis de
riesgos
Identificar
componentes
candidatos
Construir la
iteracin del
sistema
Buscar
componentes en
biblioteca
Extraer
componentes sisi estn disponibles
Poner nuevos
componentes en la biblioteca
Modificar
componentes si
-
Pgina 25 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 26 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. 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).
II. 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.
III. 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.
IV. Implementacin. Se refiere a las actividades relacionadas a
la liberacin de la aplicacin.
Representacin grafica
Gobernabilidad
Estrategia y
mtricas de
seguridad
Capacitacin
Polticas y
cumplimiento
Construccin
Anlisis de
amenazas
Requerimientos
de seguridad Arquitectura
de
seguridad
Verificacin
Revisin de
seguridad
Revisin de
cdigo
Pruebas de
seguridad
Implementacin
Gestin de
vulnerabilid
ades
Endurecimiento
de los
ambientes
Habilitacin
operativa
Desarrollo
de software
-
Pgina 27 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 28 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
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
Plan operativo
Especificacin de
requerimientos
Especificacin
funcional
Diseo
Implementacin
Integracin
Validacin y
verificacin
Mantencin
-
Pgina 29 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 30 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 31 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 32 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 33 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
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.
Especificacin
inicial
Desarrollo del
producto
Implementacin,
uso y evolucin
Re-especificacin
Versiones del
software
-
Pgina 34 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 35 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 36 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 37 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 38 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 39 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
