Ao de la Diversificacin Productiva y del Fortalecimiento de la Educacin.

UNIVERSIDADNACIONALSANLUISGONZAGA

FACULTADDEINGENIERIADESISTEMAS
EscueladeIngenieradeSistemas

MODELOSDECICLODEVIDADE
SOFTWARE
Docente:
Ing.AlonsoMorales
Integrantes:
AyllonChuquispuma,Jos
BautistaLinares,Antony
CuliGabriel,William

IcaPer
2015
1

Dedicatoria
A la generacin del bicentenario de la independencia, que darn todo el
esfuerzo por construir una pas ms justo.

INDICE
MODELOS DE CICLO DE VIDA DEL SOFTWARE...............................................................................................5
Actividades del desarrollo de software..........................................................................................................6
MODELOS DE CICLO DE VIDA.........................................................................................................................7
Clasificacin...................................................................................................................................................8
Modelos descriptivos vs. Modelos prescriptivos............................................................................................8
Modelos tradicionales vs. Modelos evolutivos...............................................................................................9
Modelos de Ciclo de Vida del software.........................................................................................................10
Modelo Cascada...........................................................................................................................................10
Descripcin del modelo................................................................................................................................10
Existen generalmente cinco etapas en este modelo de desarrollo de software:........................................11

Anlisis y definicin de requerimientos..............................................................................................11

Diseo del sistema..............................................................................................................................11

Implementacin...................................................................................................................................11

Testeo del sistema...............................................................................................................................11

Mantenimiento....................................................................................................................................11

Desventajas con el Modelo Cascada............................................................................................................12

Aplicacin del modelo cascada....................................................................................................................12
Prototipado...13
Espiral....14
Descripcin del modelo................................................................................................................................17
Ventajas........................................................................................................................................................18
Desventajas..................................................................................................................................................18
Aplicacin del modelo..................................................................................................................................18
Modelo V...19
Ventajas........................................................................................................................................................20
Desventajas..................................................................................................................................................20
Modelo Iterativo..21
Ventajas........................................................................................................................................................22
Inconvenientes.............................................................................................................................................22
Modelo de desarrollo incremental...23
Ventajas........................................................................................................................................................23
Desventajas..................................................................................................................................................24
METODOLOGA DEL DESARROLLO DE SOFTWARE.......................................................................................25
Introduccin.................................................................................................................................................25
Definicin de metodologa...........................................................................................................................26
Metodologa vs ciclo de vida........................................................................................................................26
ventajas del uso de metodologas para el desarrollo de software...............................................................27
Desde el punto de vista de gestin:............................................................................................................27
Desde el punto de vista de los ingenieros del software..............................................................................27
Desde el punto de vista del cliente o usuario..............................................................................................27
Clasificacin de las metodologas................................................................................................................28
Metodologas estructurada..........................................................................................................................28

Definicin.....................................................................................................................................................28
Clasificacin metodologa estructurada orientada a procesos....................................................................29
Diagrama de flujo de datos..........................................................................................................................29
Diccionario de datos.....................................................................................................................................29
Especificaciones...........................................................................................................................................30
Orientadas a datos.......................................................................................................................................31
Jerrquicos....................................................................................................................................................31
Datos no jerrquicos...................................................................................................................................31
Metodologa Ingeniera de la Informacin....................................................................................................32
Metodologa orientada a objetos..................................................................................................................31
Se clasifican en dos las metodologas de objetos........................................................................................32
Metodologa revolucionario ( mtodo de booch)........................................................................................32
La complejidad.............................................................................................................................................33
El modelo del objeto....................................................................................................................................34
Elementos del modelo de objetos................................................................................................................34
La abstraccin..............................................................................................................................................35
El encapsulamiento......................................................................................................................................35
La modularidad............................................................................................................................................35
La jerarqua..................................................................................................................................................36
Metodo omt (evolutiva)...............................................................................................................................36
OMT (Object Modeling Tecnique) James Rambaugh....................................................................................36
Visin general...............................................................................................................................................36
Fases (4).......................................................................................................................................................37
Anlisis de objetos.......................................................................................................................................37
Pasos especficos a dar en cada fase...........................................................................................................38
Fase De Anlisis...........................................................................................................................................38
Construir un modelo de objetos:..................................................................................................................38
Construir un modelo dinmico:....................................................................................................................38
Construir un modelo funcional:....................................................................................................................38
Verificar, iterar y refinar los tres modelos:..................................................................................................39
Fase De Diseo Del Sistema........................................................................................................................39
Fase de Diseo De Objetos..........................................................................................................................40
Disear algoritmos para implementar operaciones:...................................................................................40
Optimizar los accesos a datos:....................................................................................................................40
Metodologa para sistema tiempo real.........................................................................................................41
Modelado de datos lgicos...........................................................................................................................41
Modelado de flujo de datos..........................................................................................................................42
Modelado Entidad Evento............................................................................................................................42
Fases o etapas :............................................................................................................................................42
Fases de las mtricas...................................................................................................................................49
Mtodos giles.............................................................................................................................................52
Gestin de proyectos...................................................................................................................................53
Extreme Programming (XP)..........................................................................................................................53
Elementos de la metodologa.......................................................................................................................54
Metodologa scrum.......................................................................................................................................56

MODELOS DE CICLO DE VIDA DEL SOFTWARE

Introduccin
El trmino ciclo de vida del software describe el desarrollo de software, desde
la fase inicial hasta la fase final. El propsito de este programa es definir las
distintas fases intermedias que se requieren para validar el desarrollo de la
aplicacin, es decir, para garantizar que el software cumpla los requisitos para
la aplicacin y verificacin de los procedimientos de desarrollo: se asegura de
que los mtodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los

errores que se detectan tarde dentro de la fase de implementacin. El ciclo de
vida permite que los errores se detecten lo antes posible y por lo tanto, permite
a los desarrolladores concentrarse en la calidad del software, en los plazos de
implementacin y en los costos asociados

Actividades del desarrollo de software

Actividades del proceso de desarrollo de software representados en el
desarrollo en cascada. Hay algunos modelos ms para representar este
proceso.
Planificacin
La importante tarea a la hora de crear un producto de software es obtener los
requisitos o el anlisis de los requisitos. Los clientes suelen tener una idea ms
bien abstracta del resultado final, pero no sobre las funciones que debera
cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un
anlisis del mbito del desarrollo. Este documento se conoce como
especificacin funcional.
Implementacin, pruebas y documentacin
La implementacin es parte del proceso en el que los ingenieros de software
programan el cdigo para el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del
software. Esta parte del proceso tiene la funcin de detectar los errores de
software lo antes posible.
La documentacin del diseo interno del software con el objetivo de facilitar su
mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir
la documentacin de un API, tanto interior como exterior.
Despliegue y mantenimiento
El despliegue comienza cuando el cdigo ha sido suficientemente probado, ha
sido aprobado para su liberacin y ha sido distribuido en el entorno de
produccin.

MODELOS DE CICLO DE VIDA

Por ciclo de vida del software, entendemos la sucesin de etapas por las que
pasa el software desde que un nuevo proyecto es concebido hasta que se deja
de usar. Estas etapas representan el ciclo de actividades involucradas en el
desarrollo, uso y mantenimiento de sistemas de software, adems de llevar
asociadas una serie de documentos que sern la salida de cada una de estas
fases y servirn de entrada en la fase siguiente.
Tales actividades son:

Adopcin e identificacin del sistema: es importante conocer el origen

del sistema, as como las motivaciones que impulsaron el desarrollo del
sistema (por qu, para qu, etc.).

Anlisis de requerimientos: identificacin de las necesidades del cliente

y los usuarios que el sistema debe satisfacer.

Especificacin: los requerimientos se realizan en un lenguaje ms

formal,

de

manera

que

se

pueda

encontrar

la

funcin

de

correspondencia entre las entradas del sistema y las salidas que se

supone que genera. Al estar completamente especificado el sistema, se
pueden hacer estimaciones cuantitativas del coste, tiempos de diseo y
asignacin de personal al sistema, as como la planificacin general del
proyecto.

Especificacin de la arquitectura: define las interfaces de interconexin y

recursos entre mdulos del sistema de manera apropiada para su diseo
detallado y administracin.

Diseo: en esta etapa, se divide el sistema en partes manejables que,

como anteriormente hemos dicho se llaman mdulos, y se analizan los
elementos que las constituyen. Esto permite afrontar proyectos de muy
alta complejidad.

Desarrollo e implementacin: codificacin y depuracin de la etapa de

diseo en implementaciones de cdigo fuente operacional.

Integracin y prueba del software: ensamble de los componentes de

acuerdo a la arquitectura establecida y evaluacin del comportamiento
de todo el sistema atendiendo a su funcionalidad y eficacia.

Documentacin: generacin de documentos necesarios para el uso y

mantenimiento.

Entrenamiento y uso: instrucciones y guas para los usuarios detallando

las posibilidades y limitaciones del sistema, para su uso efectivo.

Mantenimiento del software: actividades para el mantenimiento operativo

del sistema. Se clasifican en: evolucin, conservacin y mantenimiento
propiamente dicho.

Existen diversos modelos de ciclo de vida, pero cada uno de ellos va asociado
a unos mtodos, herramientas y procedimientos que debemos usar a lo largo
de un proyecto.
Clasificacin
Modelos descriptivos vs. Modelos prescriptivos.
Un modelo de ciclo de vida del software es una caracterizacin descriptiva o
prescriptiva- de la evolucin del software.
Los modelos prescriptivos dictan pautas de cmo deberan desarrollarse los
sistemas de software; por lo tanto son ms fciles de articular ya que los
detalles del desarrollo pueden ser ignorados, generalizados, etc. Esto puede
dejar dudas acerca de la validez y robustez de este tipo de modelos.
Otra forma de encarar el desarrollo de un modelo es la forma descriptiva, la
cual se basa en la observacin del desarrollo de sistemas reales. Son ms
difciles de articular debido a dos razones fundamentales:

La captura de datos es un proceso que puede tomar aos.

8

Los modelos descriptivos son especficos a los sistemas observados y

solamente generalizables a travs de anlisis sistemticos.

Modelos tradicionales vs. Modelos evolutivos

Los modelos tradicionales focalizan su atencin en la direccin del cambio en
trminos de progreso a travs de una serie de etapas que eventualmente
conducen a alguna etapa final.
Aunque este tipo de modelos son a menudo intuitivos y muy tiles para el
establecimiento de marcos de trabajo, administracin y seleccin de
herramientas para el desarrollo de software, presentan serios problemas:

Fallan para proveer un mecanismo adecuado que permita gobernar los

cambios en el desarrollo del software.

Plantea una organizacin muy poco realista que implica una secuencia
uniforme y ordenada de actividades de desarrollo.

Son pobres predictores de por qu ciertos cambios son hechos a un

sistema, y por qu los sistemas evolucionan de maneras similares o
diferentes.

Como una solucin a estos problemas surgieron nuevas propuestas que

pueden agruparse bajo el nombre de modelos evolutivos. Los modelos
evolutivos presentan las siguientes caractersticas:

Existen tres orientaciones: centrados en el producto, centrados en los

procesos y centrados en la administracin y organizacin del proceso.

Focalizan la atencin en los mecanismos y procesos que cambian

sistemas.

Estn caracterizados por el diseo, desarrollo y despliegue de una

capacidad inicial usando tecnologa actual que incluye previsin para la
adicin evolutiva de futuras capacidades a medida que se definen
nuevos requerimientos y que las tecnologas maduran.
9

Modelos de Ciclo de Vida del software.

1. Modelo Cascada.
El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de
modelos de actividades de ingeniera con el fin de establecer algo de orden en
el desarrollo de grandes productos de software. Consiste en diferentes etapas,
las cuales son procesadas en una manera lineal. Comparado con otros
modelos de desarrollo de software es ms rgido y mejor administrable. El
modelo cascada es un modelo muy importante y ha sido la base de muchos
otros modelos, sin embargo, para muchos proyectos modernos, ha quedado un
poco desactualizado.
Descripcin del modelo
El modelo cascada es un modelo de ingeniera diseado para ser aplicado en
el desarrollo de software. La idea principal es la siguiente: existen diferentes
etapas de desarrollo, la salida de la primera etapa fluye hacia la segunda
etapa y esta salida fluye hacia la tercera y as sucesivamente.

1.1. Actividades del proceso de desarrollo de software representados en el desarrollo en cascada.

10

Existen generalmente cinco etapas en este modelo de desarrollo de

software:

Anlisis y definicin de requerimientos: en esta etapa, se establecen

los requerimientos del producto que se desea desarrollar. stos
consisten usualmente en los servicios que debe proveer, limitaciones y
metas del software. Una vez que se ha establecido esto, los
requerimientos deben ser definidos en una manera apropiada para ser
tiles en la siguiente etapa

Diseo del sistema: el diseo del software es un proceso multipaso que

se centra en cuatro atributos diferentes de los programas: estructura de
datos, arquitectura del software, detalle del proceso y caracterizacin de
las interfaces. El proceso de diseo representa los requerimientos en
una forma que permita la codificacin del producto (adems de una
evaluacin de la calidad previa a la etapa de codificacin).

Implementacin: esta es la etapa en la cual son creados los

programas. Si el diseo posee un nivel de detalle alto, la etapa de
codificacin puede implementarse mecnicamente. A menudo suele
incluirse un testeo unitario en esta etapa, es decir, las unidades de
cdigo producidas son evaluadas individualmente antes de pasar a la
etapa de integracin y testeo global.

Testeo del sistema: una vez concluida la codificacin, comienza el

testeo del programa. El proceso de testeo se centra en dos puntos
principales: las lgicas internas del software; y las funcionalidades
externas, es decir, se solucionan errores de comportamiento del
software y se asegura que las entradas definidas producen resultados
reales que coinciden con los requerimientos especificados.

Mantenimiento: esta etapa consiste en la correccin de errores que no

fueron previamente detectados, mejoras funcionales y de performance, y
otros tipos de soporte. La etapa de mantenimiento es parte del ciclo de
11

vida del producto de software y no pertenece estrictamente al desarrollo.

Sin embargo, mejoras y correcciones pueden ser consideradas como
parte del desarrollo.
Desventajas con el Modelo Cascada
El ciclo de vida clsico es el paradigma ms viejo y el ms ampliamente usado
en la ingeniera del software. Sin embargo, su aplicabilidad en muchos campos
ha sido cuestionada. Entre los problemas que aparecen cuando se aplica el
modelo cascada estn:

Los proyectos raramente siguen el flujo secuencial que el modelo

propone. La iteracin siempre es necesaria y est presente, creando
problemas en la aplicacin del modelo.

A menudo es difcil para el cliente poder especificar todos los

requerimientos explcitamente. El modelo de vida del software clsico
requiere esto y presenta problemas acomodando la incertidumbre
natural que existe al principio de cualquier proyecto.

El cliente debe ser paciente. Una versin funcional del sistema no estar
disponible hasta tarde en la duracin del desarrollo. Cualquier error o
malentendido, si no es detectado hasta que el programa funcionando es
revisado, puede ser desastroso.

Cada uno de estos problemas es real. Sin embargo, el modelo clsico del ciclo
de vida del software tiene un lugar bien definido e importante en los trabajos de
ingeniera del software. Provee un patrn dentro del cual encajan mtodos para
el anlisis, diseo, codificacin y mantenimiento.
Aplicacin del modelo cascada
El modelo cascada se aplica bien en situaciones en las que el software es
simple y en las que el dominio de requerimientos es bien conocido, la
tecnologa usada en el desarrollo es accesible y los recursos estn disponibles.

12

2. Prototipado.
Dos de las crticas que se hacan al modelo de ciclo de vida en cascada eran
que es difcil tener claros todos los requisitos del sistema al inicio del proyecto,
y que no se dispone de una versin operativa del programa hasta las fases
finales del desarrollo, lo que dificulta la deteccin de errores y deja tambin
para el final el descubrimiento de los requisitos inadvertidos en las fases de
anlisis. Para paliar estas deficiencias se ha propuesto un modelo de ciclo de
vida basado en la construccin de prototipos.
En primer lugar, hay que ver si el sistema que tenemos que desarrollar es un
buen candidato a utilizar el paradigma de ciclo de vida de construccin de
prototipos o al modelo en espiral. En general, cualquier aplicacin que presente
mucha interaccin con el usuario, o que necesite algoritmos que puedan
construirse de manera evolutiva, yendo de lo ms general a lo ms especfico
es una buena candidata. No obstante, hay que tener en cuenta la complejidad:
si la aplicacin necesita que se desarrolle una gran cantidad de cdigo para
poder tener un prototipo que ensear al usuario, las ventajas de la construccin
de prototipos se vern superadas por el esfuerzo de desarrollar un prototipo
que al final habr que desechar o modificar mucho
Tambin es conveniente construir prototipos para probar la eficiencia de los
algoritmos que se van a implementar, o para comprobar el rendimiento de un
determinado componente del sistema en condiciones similares a las que
existirn durante la utilizacin del sistema.
En otros casos, el prototipo servir para modelar y poder mostrar al cliente
cmo va a realizarse la E/S de datos en la aplicacin, de forma que ste pueda
hacerse una idea de cmo va a ser el sistema final, pudiendo entonces detectar
deficiencias o errores en la especificacin aunque el modelo no sea ms que
una cscara vaca.
Segn esto un prototipo puede tener alguna de las tres formas siguientes:

13

Un prototipo, en papel o ejecutable en ordenador, que describa la

interaccin hombre-mquina y los listados del sistema.

Un prototipo que implemente algn(os) subconjunto(s) de la funcin

requerida, y que sirva para evaluar el rendimiento de un algoritmo o las
necesidades de capacidad de almacenamiento y velocidad de clculo
del sistema final.

Un programa que realice en todo o en parte la funcin deseada pero que

tenga caractersticas (rendimiento, consideracin de casos particulares,
etc.) que deban ser mejoradas durante el desarrollo del proyecto.

La secuencia de tareas del paradigma de construccin de prototipos puede

verse en la siguiente figura.

1.2. Modelo Prototipo.

Si se ha decidido construir un prototipo, lo primero que hay que hacer es

realizar un modelo del sistema, a partir de los requisitos que ya conozcamos.
En este caso no es necesario realizar una definicin completa de los requisitos,
pero s es conveniente determinar al menos las reas donde ser necesaria
una definicin posterior ms detallada.
Luego se procede a disear el prototipo. Se tratar de un diseo rpido,
centrado sobre todo en la arquitectura del sistema y la definicin de la
14

estructura de las interfaces ms que en aspectos de procedimiento de los

programas: nos fijaremos ms en la forma y en la apariencia que en el
contenido.
A partir del diseo construiremos el prototipo. Existen herramientas
especializadas en generar prototipos ejecutables a partir del diseo
Una vez listo el prototipo, hay que presentarlo al cliente para que lo pruebe y
sugiera modificaciones. En este punto el cliente puede ver una implementacin
de los requisitos que ha definido inicialmente y sugerir las modificaciones
necesarias en las especificaciones para que satisfagan mejor sus necesidades.
A partir de estos comentarios del cliente y los cambios que se muestren
necesarios en los requisitos, se proceder a construir un nuevo prototipo y as
sucesivamente hasta que los requisitos queden totalmente formalizados, y se
pueda entonces empezar con el desarrollo del producto final.
Por tanto, el prototipado es una tcnica que sirve fundamentalmente para la
fase de anlisis de requisitos, pero lleva consigo la obtencin de una serie de
subproductos que son tiles a lo largo del desarrollo del proyecto:

Gran parte del trabajo realizado durante la fase de diseo rpido

(especialmente la definicin de pantallas e informes) puede ser utilizada
durante el diseo del producto final.

Durante la fase de construccin de prototipos ser necesario codificar

algunos componentes del software que tambin podrn ser reutilizados
en la codificacin del producto final, aunque deban de ser optimizados
en cuanto a correccin o velocidad de procesamiento.

No obstante, hay que tener en cuenta que el prototipo no es el sistema final,

puesto que normalmente apenas es utilizable. Ser demasiado lento,
demasiado grande, inadecuado para el volumen de datos necesario, contendr
errores (debido al diseo rpido), ser demasiado general (sin considerar
casos particulares, que debe tener en cuenta el sistema final) o estar

15

codificado en un lenguaje o para una mquina inadecuadas, o a partir de

componentes software previamente existentes.
Hay que tener en cuenta que un anlisis de requisitos incorrecto o incompleto,
cuyos errores y deficiencias se detecten a la hora de las pruebas o tras
entregar el software al cliente, nos obligar a repetir de nuevo las fases de
anlisis, diseo y codificacin, que habamos realizado cuidadosamente,
pensando que estbamos desarrollando el producto final
Uno de los problemas que suelen aparecer siguiendo el paradigma de
construccin de prototipos, es que con demasiada frecuencia el prototipo pasa
a ser parte del sistema final, bien sea por presiones del cliente, que quiere
tener el sistema funcionando lo antes posible o bien porque los tcnicos se han
acostumbrado a la mquina, el sistema operativo o el lenguaje con el que se
desarroll el prototipo.
El utilizar el prototipo en el producto final conduce a que ste contenga
numerosos errores latentes, sea ineficiente, poco fiable, incompleto o difcil de
mantener. En definitiva a que tenga poca calidad, y eso es precisamente lo que
se quiere evitar aplicando la ingeniera del software.
3. Espiral.
El problema con los modelos de procesos de software es que no se enfrentan
lo suficiente con la incertidumbre inherente a los procesos de software.
Importantes proyectos de software fallaron porque los riegos del proyecto se
despreciaron y nadie se prepar para algn imprevisto. Boehm reconoci esto
y trat de incorporar el factor riesgo del proyecto al modelo de ciclo de vida,
agregndoselo a las mejores caractersticas de los modelos Cascada y
Prototipado. El resultado fue el Modelo Espiral. La direccin del nuevo modelo
fue incorporar los puntos fuertes y evitar las dificultades de otros modelos
desplazando el nfasis de administracin hacia la evaluacin y resolucin del
riesgo. De esta manera se permite tanto a los desarrolladores como a los
clientes detener el proceso cuando se lo considere conveniente.

16

1.3. Modelo Espiral.

Descripcin del modelo

Bsicamente, la idea es desarrollo incremental usando el modelo Cascada para
cada paso, ayudando a administrar los riesgos. No se define en detalle el
sistema completo al principio; los diseadores deberan definir e implementar
solamente los rasgos de mayor prioridad. Con el conocimiento adquirido,
podran entonces volver atrs y definir e implementar ms caractersticas en
trozos ms pequeos.
El modelo Espiral define cuatro actividades principales en su ciclo de vida:

Planeamiento: Determinacin de los objetivos, alternativas y limitaciones

del proyecto.

Anlisis de riesgo: Anlisis de alternativas e identificacin y solucin de

riesgos.

Ingeniera: Desarrollo y testeo del producto.

Evaluacin del cliente: Tasacin de los resultados de la ingeniera.

El modelo est representado por una espiral dividida en cuatro cuadrantes,

cada una de las cuales representa una de las actividades arriba mencionadas.

17

Ventajas

Evita las dificultades de los modelos existentes a travs de un

acercamiento conducido por el riesgo.

Intenta eliminar errores en las fases tempranas.

Es el mismo modelo para el desarrollo y el mantenimiento.

Provee mecanismos para la aseguracin de la calidad del software.

La reevaluacin despus de cada fase permite cambios en las

percepciones de los usuarios, avances tecnolgicos o perspectivas
financieras.

La focalizacin en los objetivos y limitaciones ayuda a asegurar la

calidad.

Desventajas

Falta un proceso de gua explcito para determinar objetivos, limitaciones

y alternativas.

Provee ms flexibilidad que la conveniente para la mayora de las

aplicaciones.

La pericia de tasacin del riesgo no es una tarea fcil. El autor declara

que es necesaria mucha experiencia en proyectos de software para
realizar esta tarea exitosamente.

Aplicacin del modelo

Proyectos complejos, dinmicos, innovadores, ambiciosos, llevados a cabo por
equipos internos (no necesariamente de software).

18

4. Modelo en V.
El modelo en v se desarroll para terminar con algunos de los problemas que
se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban
siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no
se introducan hasta el final del proyecto. El modelo en v dice que las pruebas
necesitan empezarse lo ms pronto posible en el ciclo de vida. Tambin
muestra que las pruebas no son slo una actividad basada en la ejecucin.
Hay una variedad de actividades que se han de realizar antes del fin de la fase
de codificacin. El modelo en v es un proceso que representa la secuencia de
pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades
y resultados que han de ser producidos durante el desarrollo del producto. La
parte izquierda de la v representa la descomposicin de los requisitos y la
creacin de las especificaciones del sistema

1.4. Modelo V.

Realmente las etapas individuales del proceso pueden ser casi las mismas que
las del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir
para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la
fase de codificacin, formando una V. La razn de esto es que para cada una
19

de las fases de diseo se ha encontrado que hay un homlogo en las fases de

pruebas que se correlacionan.
Ventajas
Las ventajas que se pueden destacar de este modelo son las siguientes:

Es un modelo simple y fcil de utilizar.

En cada una de las fases hay entregables especficos.

Tiene una alta oportunidad de xito sobre el modelo en cascada debido

al desarrollo de planes de prueba en etapas tempranas del ciclo de vida.

Es un modelo que suele funcionar bien para proyectos pequeos donde

los requisitos son entendidos fcilmente.

Desventajas
Entre los inconvenientes y las crticas que se le hacen a este modelo estn las
siguientes:

Es un modelo muy rgido, como el modelo en cascada.

Tiene poca flexibilidad y ajustar el alcance es difcil y caro.

El software se desarrolla durante la fase de implementacin, por lo que

no se producen prototipos del software.

20

5. 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.

1.5. Modelo Iterativo.

21

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 entregas.
Inconvenientes
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

arquitectura.

22

la

6.-Modelo de desarrollo Incremental

El modelo incremental combina elementos del modelo en cascada con la
filosofa interactiva de construccin de prototipos. Se basa en la filosofa de
construir incrementando las funcionalidades del programa. Este modelo aplica
secuencias lineales de forma escalonada mientras progresa el tiempo en el
calendario. Cada secuencia lineal produce un incremento del software.

1.6.Modelo de desarrollo Incremental.

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un

producto esencial, slo con los requisitos bsicos. Este modelo se centra en la
entrega de un producto operativo con cada incremento. Los primeros
incrementos son versiones incompletas del producto final, pero proporcionan al
usuario la funcionalidad que precisa y tambin una plataforma para la
evaluacin.
Ventajas.
Entre las ventajas que puede proporcionar un modelo de este tipo encontramos
las siguientes:

Mediante este modelo se genera software operativo de forma rpida y

en etapas tempranas del ciclo de vida del software.

Es un modelo ms flexible, por lo que se reduce el coste en el cambio de

alcance y requisitos.
23

Es ms fcil probar y depurar en una iteracin ms pequea.

Es ms fcil gestionar riesgos.

Cada iteracin es un hito gestionado fcilmente

Desventajas
Para el uso de este modelo se requiere una experiencia importante para definir
los incrementos y distribuir en ellos las tareas de forma proporcionada.
Entre los inconvenientes que aparecen en el uso de este modelo podemos
destacar los siguientes:

Cada fase de una iteracin es rgida y no se superponen con otras.

Pueden surgir problemas referidos a la arquitectura del sistema porque

no todos los requisitos se han reunido, ya que se supone que todos ellos
se han definido al inicio.

24

METODOLOGA DEL DESARROLLO DE SOFTWARE

Introduccin
El desarrollo de software no es una tarea fcil. Prueba de ello es que existen
numerosas propuestas metodolgicas que inciden en distintas dimensiones del
proceso de desarrollo. Por una parte tenemos aquellas propuestas ms
tradicionales que se centran especialmente en el control del proceso,
estableciendo rigurosamente las actividades involucradas, los artefactos que se
deben producir, y las herramientas y notaciones que se usarn. Estas
propuestas han demostrado ser efectivas y necesarias en un gran nmero de
proyectos, pero tambin han presentado problemas en muchos otros. Una
posible mejora es incluir en los procesos de desarrollo ms actividades, ms
artefactos y ms restricciones, basndose en los puntos dbiles detectados.
Sin embargo, el resultado final sera un proceso de desarrollo ms complejo
que puede incluso limitar la propia habilidad del equipo para llevar a cabo el
proyecto. Otra aproximacin es centrarse en otras dimensiones, como por
ejemplo el factor humano o el producto software. Esta es la filosofa de las
metodologas giles, las cuales dan mayor valor al individuo, a la colaboracin
con el cliente y al desarrollo incremental del software con iteraciones muy
cortas. Este enfoque est mostrando su efectividad en proyectos con requisitos
muy cambiantes y cuando se exige reducir drsticamente los tiempos de
desarrollo pero manteniendo una alta calidad. Las metodologas giles estn
revolucionando la manera de producir software, y a la vez
generando un amplio debate entre sus seguidores y quienes por escepticismo
o convencimiento no las ven como alternativa para las metodologas
tradicionales
Definicin de metodologa.
Una metodologa es un conjunto integrado de tcnicas y mtodos que permite
abordar de forma homognea y abierta cada una de las actividades del ciclo de

25

vida de un proyecto de desarrollo. Es un proceso de software detallado y

completo.
Las metodologas se basan en una combinacin de los modelos de proceso
genricos (cascada, incremental). Definen artefactos, roles y actividades,
junto con prcticas y tcnicas recomendadas.
La metodologa para el desarrollo de software en un modo sistemtico de
realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas
posibilidades de xito. Una metodologa para el desarrollo de software
comprende los procesos a seguir sistemticamente para idear, implementar y
mantener un producto software desde que surge la necesidad del producto
hasta que cumplimos el objetivo por el cual fue creado.
Metodologa vs ciclo de vida :
Una metodologa puede seguir uno o varios Modelos de ciclo de vida, es decir,
el ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo
del proyecto pero no cmo hacerlo.
La metodologa indica cmo hay que obtener los distintos productos parciales y
finales.

1.7. Diferencias entre metodologa vs Ciclo de vida

26

ventajas del uso de metodologas para el desarrollo de software

Desde el punto de vista de gestin:

Facilitar la tarea de planificacin

Facilitar la tarea del control y seguimiento de un proyecto

Mejorar la relacin coste/beneficio

Optimizar el uso de recursos disponibles

Facilitar la evaluacin de resultados y cumplimiento de los objetivos

Facilitar la comunicacin efectiva entre usuarios y desarrolladores

Desde el punto de vista de los ingenieros del software:

Ayudar a la comprensin del problema

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

Facilitar el mantenimiento del producto final

Permitir la reutilizacin de partes del producto

Desde el punto de vista del cliente o usuario:

Garanta de un determinado nivel de calidad en el producto final

Confianza en los plazos de tiempo fijados en la definicin del proyecto

Definir el ciclo de vida que ms se adecue a las condiciones y

caractersticas del Desarrollo

27

Clasificacin de las metodologas

Metodologas estructurada
Definicin :
Las

metodologas

descomposicin

estructuradas

funcional

de

se

basan

problemas

en

en

la

estructuracin

unidades ms pequeas

interrelacionadas entre s. Representan los procesos, flujos y estructuras de

datos, de una manera jerrquica y ven el sistema como entradas-procesosalidas.
Existe una gran cantidad de proyectos implementados utilizando estas
metodologas,

generalmente

orientados

la

manipulacin

de

datos

(persistentes en ficheros o bases de datos) y gestin. Estas metodologas

funcionan muy bien con los lenguajes de programacin estructurados, como
por ejemplo el COBOL.
Las metodologas estructuradas hacen fuerte separacin entre los datos y los
procesos. Producen una gran cantidad de modelos y documentacin y se
basan en ciclos de vida en cascada.
El enfoque estructurado tiene un alto grado de especializacin en sus perfiles y
las relaciones entre ellos tienen fuertes races en los principios de la
descomposicin funcional. Su principio fundamental es examinar el sistema
desde las funciones y tareas, mientras que en las metodologas orientadas a
objetos modelan el sistema examinando el dominio del problema como un
conjunto de objetos que interactan entre s.
Clasificacin metodologa estructurada orientada a procesos
Para llevar una buena metodologa para el desarrollo de software la
programacin orientada a procesos sigue ciertas tcnicas que son

los

diagrama de flujo de datos,diccionario de datos,especificaciones de procesos .

28

Diagrama de flujo de datos

Los diagramas de flujo de datos (DFD) son utilizados para modelar la
funcionalidad de un sistema. Tal como es descripto por De Marco y Gane &, un
DFD

permite representar un sistema como una red de procesos de

transformacin de datos que intercambian informacin por medio de flujos de

datos.
Un proceso en un DFD puede representar funcionalidad en distintos niveles de
abstraccin, desde unidades funcionales de una organizacin (por ejemplo:
departamento de recursos humanos,seccin de ventas, etc.) hasta expresiones
simples (por ejemplo: clculo de la taza nominal anual deun prstamo).
El diagrama de flujo de datos describe cmo los datos fluyen a travs del
sistema, pero no proveen informacin acerca de estructuras de control o de
secuencias de ejecucin. La nica secuencia que puede ser reconocida en un
DFD es la determinada por la necesidad de informacin: el proceso Generar
Pedido del Cliente puede completar su funcionalidad slo en el caso que los
flujos de datos Datos del Cliente Validados, Informacin de Embarque e
Informacin de las Tarifas estn. Por otra parte, los procesos Validar Cliente y
Validar Existencia no tienen un orden definido de ejecucin relativo entre ellos,
puesto que ninguno de ellos recibe flujos de salida del otro proceso.
Podemos considerar al diagrama de flujo de datos como un lenguaje grfico,
til para describir la funcionalidad de un sistema, en un cierto grado de detalle.
Diccionario de datos
El diccionario de datos es una herramienta fundamental en el modelamiento de
sistemas. Las herramientas grficas como los diagramas de flujo de datos, los
diagramas de entidad-relacin, los diagramas de transicin de estados, etc.,
son de mucha importancia para el modelamiento estructural de los sistemas
(estructuras

funcionales,

estructuras

de

informacin,

estructuras

de

comportamiento,etc.) y permiten una adecuada interpretacin general de las

ideas modeladas pero, no son completos.
29

Para contar con una especificacin completa es preciso tener una descripcin
textual de los detalles que no pueden ser especificados en los diagramas. La
importancia del diccionario de datos queda mucho ms clara si usted trata de
recordar los das de escuela primaria, en las aulas de lengua cuando usted era
constantemente asediado por nuevas palabras.
Recuerde tambin, los cursos de lengua extranjera, especialmente aquellos
que exigan que leyera libros y revistas o hiciera traducciones. Sin un
diccionario, usted estara perdido.

mismo puede ser dicho en relacin al

diccionario de datos en el anlisis de sistemas: sin l, usted estar perdido, y

el usuario no tendr certeza de que usted haya entendido completamente los
detalles de la aplicacin.
Especificaciones
Una especificacin de procesos describe las actividades a ser desarrolladas
para transformar los datos de entrada en datos de salida. Existen diversas
herramientas para la especificacin de procesos:
tablas de decisin, rboles de decisin, lenguajes estructurados, pre/pos
condiciones y diagramas de Nassi-Shneiderman, entre otras. En general, una
herramienta puede ser utilizada para la especificacin de procesos si cumple
los siguientes dos requisitos:
Una especificacin de procesos debe ser expresada de forma tal que pueda
ser verificada porel usuario y por el analista de sistemas. Por esta razn, no es
recomendable utilizar el uso de lenguajes de programacin, tampoco es
recomendable el uso de lenguaje natural. Una especificacin de procesos debe
ser expresada de forma tal que pueda ser efectivamente comunicada a la
audiencia

involucrada.

Habitualmente

hay

una

audiencia

diversa

de

usuarios,gerentes, auditores y controladores de calidad, los cuales leern la

especificacin.
La especificacin de procesos es realizada solo para los procesos de los
niveles ms bajos del diagrama de flujo de datos. Los procesos de un nivel
30

intermedio son definidos por los diagramas de flujos de datos del nivel inferior
inmediato. Sin embargo, en otros diagramas como por ejemplo el diagrama de
estructura, todos los componentes deben ser especificados.
Orientadas a datos :
Se clasifican en dos jerarquico y no jerarquico
Jerrquicos

La estructura de control del programa debe ser jerrquica y se debe

derivar de la estructura de datos del programa

El proceso de diseo consiste en definir primero las estructuras de los

datos de entrada y salida, mezclarlas todas en una estructura jerrquica
de programa y despus ordenar detalladamente la lgica procedimental
para que se ajuste a esta estructura.

El diseo lgico debe preceder y estar separado del diseo fsico

Datos no jerrquicos
Metodologa Ingeniera de la Informacin
Planificacin: construir una arquitectura de la Informacin y una estrategia que
soporte los objetivos de la organizacin
Anlisis: comprender las reas del negocio y determinar los requisitos del
sistema
Diseo: establecer el comportamiento del sistema deseado por el usuario y
que sea alcanzable por la tecnologa
Construccin: construir sistemas que cumplan los tres niveles anteriores
Metodologa orientada a objetos
La metodologa orientada a objetos ha derivado de las metodologas anteriores
a ste. As como los mtodos de diseo estructurado realizados guan a los
desarrolladores que tratan de construir sistemas complejos utilizando
31

algoritmos como sus bloques fundamentales de construccin, similarmente los

mtodos de diseo orientado a objetos han evolucionado para ayudar a los
desarrolladores a explotar el poder de los lenguajes de programacin basados
en objetos y orientados a objetos, utilizando las clases y objetos como bloques
de construccin bsicos.
Actualmente el modelo de objetos ha sido influenciado por un nmero de
factores no slo de la Programacin Orientada a Objetos, POO (Object
Oriented Programming, OOP por sus siglas en ingls). Adems, el modelo de
objetos ha probado ser un concepto uniforme en las ciencias de la
computacin, aplicable no slo a los lenguajes de programacin sino tambin al
diseo de interfaces de usuario, bases de datos y arquitectura de
computadoras por completo. La razn de ello es, simplemente, que una
orientacin a objetos nos ayuda a hacer frente a la inherente complejidad de
muchos tipos de sistemas.
Se define a un objeto como "una entidad tangible que muestra alguna conducta
bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual
almacenamos datos y los mtodos que controlan dichos datos".
Se clasifican en dos las metodologas de objetos
metodologa revolucionario ( mtodo de booch)
El mtodo de Grady Booch es uno de los ms conocidos en la orientacin al
objeto. En su versin de 1.993 este mtodo cubre las fases de anlisis y
diseo dentro de un desarrollo orientado al objeto.
Se definirn una gran cantidad de smbolos para representar las distintas
decisiones de diseo.
Este mtodo ofrece una gran libertad en la produccin del software, como ya
veremos ms adelante.

32

En un primer momento se explicarn una serie de conceptos bsicos, los

cuales han de quedar claros para poder comprender a fondo la metodologa de
Booch.
Dichos conceptos se pueden estructurar estructurarlos de la siguiente manera:

Complejidad.

El modelo del objeto.

Clases y objetos.

Clasificacin.

La complejidad
El software, por lo general, va a ser un sistema complejo, sobre todo
cuando se trate de un software grande. Esto es debido a 4 elementos:

La

complejidad

del

dominio

del

problema.

(Definicin

de

los

requisitos, modificaciones que pueden ir sufriendo stos...)

La dificultad de gestionar el proceso de desarrollo. (Sobre todo en

proyectos muy grandes.)

La flexibilidad que posibilita el software.

Los problemas del comportamiento de sistemas discretos.

Para tratar un sistema complejo se pueden utilizar las siguientes tcnicas:

Descomposicin: consiste en dividir el sistema en partes ms y ms
pequeas cada vez, pudiendo ser stas refinadas independientemente.
Abstraccin: la abstraccin denota las caractersticas esenciales de un objeto
que lo distinguen de todos los dems tipos de objetos y proporciona as
fronteras conceptuales ntidamente definidas respecto a la perspectiva del
observador.

33

Jerarqua: para Booch la jerarqua es una clasificacin u ordenacin de

abstracciones.
Existen dos clases de jerarqua:
Jerarqua parte de (part of) o tiene un (has a): corresponde a la estructura
del objeto.
Jerarqua es un (is a): corresponde a la estructura de la clase.
El modelo del objeto
La programacin orientada a objetos es un mtodo en el que los programas se
organizan como una coleccin de objetos, representando cada uno una
instancia de alguna clase, estando relacionadas todas las clases mediante una
jerarqua.
Un programa que no tenga bien claros estos 3 elementos (que se tengan
objetos en lugar de algoritmos, que cada objeto sea instancia de alguna
clase, y que entre las clases exista una relacin de herencia que de lugar a
una jerarqua) no puede considerarse orientado a objetos. Booch lo llama
programacin con tipos de datos abstractos.
Se estudiarn las fases de anlisis y diseo en la orientacin al objeto. El
anlisis se realizar a partir del dominio inicial del problema. A continuacin
vendr el diseo.
Elementos del modelo de objetos
Hay 4 elementos bsicos que constituyen dicho modelo:

Abstraccin.

Encapsulamiento.

Modularidad.

Jerarqua.

34

Hay otros elementos (no principales) que son los siguientes:

Concurrencia.

Persistencia.

La abstraccin.
La abstraccin denota las caractersticas esenciales de un objeto que lo
distinguen de todos los dems tipos de objetos y proporciona as fronteras
conceptuales ntidamente definidas respecto a la perspectiva del observador.
Existen varios tipos de abstraccin:
Abstraccin de entidad: un objeto que representa un modelo til del
problema de dominio de la entidad.
Abstraccin de accin: un objeto proporciona un conjunto generalizado de
operaciones para una determinada funcin.
El encapsulamiento.
Es el proceso de almacenar en un mismo compartimento los elementos de una
abstraccin que constituyen su estructura y su comportamiento; sirve para
separar la interfaz contractual de una abstraccin y su implantacin (El
encapsulamiento oculta los detalles de la implementacin de un objeto).
La modularidad.
Cuando se habla de modularidad hay que imaginarse la fragmentacin de un
programa en componentes individuales para reducir la complejidad. Booch
define modularidad como la propiedad que tiene un sistema que ha sido
descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados.

35

La jerarqua.
Para Booch la jerarqua es una clasificacin u ordenacin de abstracciones.
Las 2 jerarquas ms importantes en un sistema complejo son la estructura de
la clase (es un) y la estructura del objeto (parte de) o (tiene un).
La herencia es el ejemplo ms importante de jerarqua (es un), ya que va a
definir las relaciones entre clases, tanto en el caso de herencia simple como en
el caso de herencia mltiple.
Cuando se habla de jerarqua (es un) normalmente se refiriere a
generalizacin/especializacin. Sin embargo (parte de) es ms bien un caso de
agregacin. La combinacin de la herencia y la agregacin puede ser muy
potente:

la agregacin permite el agrupamiento fsico de las estructuras

lgicas, y la jerarqua permite a estos grupos su funcionamiento en diferentes

niveles de abstraccin.
Metodo omt (evolutiva)
OMT (Object Modeling Tecnique) James Rambaugh
Visin general
Es una metodologa orientada a objeto muy difundida, de hecho es la que
actualmente ms se est utilizando por encima incluso de la de Booch. Se
desarroll en el Research and Development Center de General Electric a
finales de los 80. Se hace cargo de todo el ciclo de vida del software, y
durante ese tiempo mantiene la misma notacin. Se divide en cuatro fases
consecutivas. Tiene una parte de diseo no muy compleja. Se centra mucho en
un buen anlisis. Es de las denominadas dirigidas por los datos.

36

Fases (4)
Anlisis de objetos
Se describe el problema: Se obtienen unos requisitos que no den lugar a
dudas (rendimiento, funcionalidad, contexto,...). En toda la fase de anlisis se
describe el comportamiento del sistema como una caja negra.
Se hacen los diagramas de objetos con su diccionario de datos. As obtengo
el modelo de objetos. En l se define su la estructura de los objetos y
clases as como las relaciones que les unen. Comprende tanto un Diagrama
de Clases como un Diccionario de Datos que las explique. Este modelo debe
ser refinado por medio de la iteracin.
Creacin de un modelo dinmico para describir los aspectos de control y
evolucin del sistema. Incluye un Diagrama de Eventos del sistema y un
Diagrama de Estado por cada clase que tenga un comportamiento dinmico.
Creacin de un modelo funcional que describa las funciones, los valores de
entrada y salida, e imponga las restricciones pertinentes. Se suelen utilizar
Diagramas de Flujo de Datos (DFDs).

Se verifican todos los modelos creados.

Se itera para conseguir un refinamiento de los 3 modelos.

Diseo del sistema: Comprende la arquitectura bsica. En esta fase se

tomarn las decisiones estratgicas (a alto nivel) de diseo (estructura global
del sistema).
Diseo de objetos: Es el ltimo paso antes de implementar, y sirve para
definir completamente todas las caractersticas de los objetos. Se detallan los 3
modelos ya descritos en el anlisis de objetos de cara a poder implementarlo,
y optimizar el programa (acceso a datos, iteraciones, control, recursos,...).
Todo esto ha de hacerse con independencia del lenguaje o entorno en que
finalmente codifiquemos y ejecutemos la aplicacin.

37

Implementacin: Se codifica lo ya diseado.

Pasos especficos a dar en cada fase
Fase De Anlisis
Obtener y escribir una descripcin inicial del problema.
Construir un modelo de objetos:

Identificar las clases (y objetos).

Probar que los accesos son correctos, usando escenarios e iterando

los pasos siguientes como sea necesario.

Agrupar las clases en mdulos, basndose en su proximidad y funcin.

Construir un modelo dinmico:

Reparar los escenarios para las secuencias de interaccin tpicas

entre los usuarios y el sistema.

Identificar los eventos que se dan entre objetos y preparar una

traza de eventos para cada escenario.

Construir un modelo funcional:

Identificar los valores de entrada y de salida.

Usar DFDs cuando sea necesario para mostrar las dependencias

funcionales.

Describir qu hace cada funcin.

Identificar las restricciones.

Especificar criterios de optimizacin.

38

Verificar, iterar y refinar los tres modelos:

Aadir las operaciones claves que fueron descubiertas durante la

preparacin del modelo funcional al modelo de objetos. No mostrar
todas las operaciones durante el anlisis, slo mostrar las ms
importantes.

Verificar que las clases, asociaciones, atributos

y operaciones

son consistentes y completas al nivel elegido de abstraccin. Compara

los tres modelos con la definicin del problema y probar los modelos
mediante el uso de escenarios.

Desarrollar escenarios ms detallados (incluyendo condiciones que

den errores) como variaciones de los escenarios bsicos. Usar estos
escenarios y si... para verificar en el futuro los tres modelos.

Iterar los pasos anteriores cuanto sea necesario para completar el

anlisis.

Fase De Diseo Del Sistema

1. Organizar el sistema en subsistemas (conjunto de capas horizontales).
2. Identificar la concurrencia inherente al problema.
3. Colocar los susbsistemas a sus procesos y tareas. Aqu han de
asignarse recursos de la mquina a los distintos subsitemas (memoria,
procesador, ficheros...).
4. Elegir

la

estrategia

bsica

para

almacenar

los

datos;

tipos

abstractos de datos, estructuras, ficheros y bases de datos.

5. Identificar los recursos globales y determinar mecanismos de control
de acceso a ellos.
6. Elegir un mtodo de implementacin del control de software. Existen 3
tipos de control destacados: Por programa (sistemas dirigidos por
procedimientos; C++), Por planificador del entorno (sistemas dirigidos
39

por eventos; X-Windows) o Concurrente (sistemas concurrentes; Ada).

Esto se puede implementar de la siguientes maneras:
Usar el programa como un estado fijo o directamente implementar un
autmata de estados, o usar tareas de concurrencia.
7. Considerar las condiciones lmite.
8. Establecer las prioridades.
Fase de Diseo De Objetos

Obtener operaciones para el modelo de objetos a partir de los otros

modelos:

Encontrar una operacin para cada proceso del modelo funcional.

Definir una operacin por cada evento del modelo

dinmico,

dependiendo de la implementacin del control.

Disear algoritmos para implementar operaciones:

Elegir

algoritmos que

minimicen

el coste

de

implementar

las

operaciones.

Elegir estructuras de datos apropiadas a los algoritmos.

Definir nuevas clases internas y operaciones como sea necesario.

Asignar

responsabilidades

para

operaciones

que

no

han

minimizar

el

coste

sido

claramente asociadas a una sola clase.

Optimizar los accesos a datos:

Aadir

asociaciones

redundantes

para

de

acceso y maximizar la conveniencias.

Reajustar los procesos computacionales para lograr una mayor

efectividad.

40

Almacenar los valores derivados para evitar los clculos repetidos.

Implementacin
No se detiene en ella (al igual que la fase de pruebas), con lo que se queda a
la eleccin del programador.
Metodologa para sistema tiempo real
SSADM es un mtodo de cascada para el anlisis y diseo de sistemas de
informacin. se considera que SSADM representa el pinculo del enfoque
riguroso en la documentacin hacia el diseo del sistema que contrasta con
mtodos giles como DSDM o Scrum.
SSADM es una aplicacin en particular y se basa en el trabajo de las diferentes
escuelas de anlisis estructurados mtodos y desarrollo, como la de Peter
ChecklandMetodologa blanda de sistemas, de Larry Constantino diseo
estructurado, de Edward Yourdon Mtodo estructurado de Yourdon, de Michael
A. Jackson Programacin Estructurada de Jackson, y Tom DeMarco anlisis
estructurado.
Los nombres "Sistemas estructurados mtodo de anlisis y diseo" y "SSADM"
son marcas registradas de la Oficina Gubernamental de Comercio (OGC), que
es una oficina de Hacienda del Reino Unido.
Las tres tcnicas ms importantes que se utilizan en SSADM son los
siguientes:
Modelado de datos lgicos
El proceso de identificacin, modelado y documentacin de los requisitos de
datos del sistema que est siendo diseado. El resultado es un modelo de
datos que contiene las entidades (cosas de las que una empresa necesita para
registrar la informacin), atributos (datos sobre las entidades) y relaciones
(asociaciones entre las entidades).

41

Modelado de flujo de datos

El proceso de identificar, modelar y documentar cmo los datos se mueven
alrededor de un sistema de informacin. El Modelado de flujo de datos examina
los procesos (actividades que transforman los datos de una forma a otra),
almacenes de datos (las zonas de espera de los datos), entidades externas (lo
que enva los datos a un sistema o recibe datos de un sistema), y los flujos de
datos (rutas por el cual los datos pueden fluir).
Modelado Entidad Evento
Es un proceso de dos hebras: Behavior Modeling Entidad, identificar, modelar y
documentar los eventos que afectan a cada entidad y la secuencia (o historia
de vida) en el que se producen estos eventos, y Modelado de eventos,
diseando para cada caso el proceso para coordinar las historias de vida
entidad.
Fases o etapas :
Fase 1 - Investigacin de la situacin actual
Esta es una de las etapas ms importantes de SSADM. Los desarrolladores de
SSADM entendieron que en casi todos los casos hay algn tipo de sistema de
corriente incluso si est compuesta en su totalidad de las personas y de papel.
A travs de una combinacin de entrevistar a los empleados, cuestionarios,
observaciones de circulacin y documentacin existente, el analista llega a la
comprensin completa del sistema, ya que se encuentra al principio del
proyecto. Esto sirve para muchos propsitos:

el analista aprende la terminologa de la empresa, lo que los usuarios

hacen y cmo lo hacen.

el viejo sistema proporciona los requisitos bsicos para el nuevo

sistema.

fallas, errores y reas de ineficiencia se resaltan y sus correcciones se

aaden a los requisitos.
42

el modelo de datos se puede construir.

los usuarios se involucran y aprenden las tcnicas y modelos del

analista.

los lmites del sistema se pueden definir.

Los productos de esta etapa son:

Catlogo de Usuarios describe todos los usuarios del sistema y cmo

interactuar con el.

Catlogo de Necesidades detalla todos los requisitos del nuevo sistema.

Servicios actuales Descripcin compuso ms de

Para producir los modelos, el analista trabaja a travs de la construccin de los

modelos que hemos descrito. Sin embargo, el primer conjunto de diagramas de
flujo de datos (DFD) son el modelo fsico actual, es decir, con todos los detalles
de cmo se implementa el sistema antiguo. La versin final es el modelo lgico
actual que es esencialmente la misma que la corriente fsica pero con toda
referencia a la aplicacin eliminado junto con las redundancias como la
repeticin de la informacin que compone los usuarios y los requisitos
catlogos.
Etapa 2 - opciones del sistema de negocios
Tras investigar el sistema actual, el analista debe decidir sobre el diseo
general del nuevo sistema. Para hacer esto, l o ella deben usar las salidas de
la etapa anterior, se desarrolla un conjunto de opciones de negocios del
sistema. Estas son diferentes formas en que el nuevo sistema podra ser
producido variando de no hacer nada para tirar el viejo sistema en su totalidad
y la construccin de uno totalmente nuevo. El analista puede realizar una
sesin de lluvia de ideas para que se generen tantas y diversas ideas como
sea posible.

43

Las ideas se recogen entonces para formar un conjunto de dos o tres opciones
diferentes que se presentan al usuario. Las opciones en cuenta lo siguiente:

El grado de automatizacin

El lmite entre el sistema y los usuarios

La distribucin del sistema, por ejemplo, es centralizada a una oficina o

hacia fuera a travs de varios?

Costo / beneficio

Impacto del nuevo sistema

Cuando sea necesario, la opcin ser documentada con una estructura de

datos lgica y un diagrama de flujo de datos de nivel 1.
Los usuarios y analista juntos escogen una opcin de negocio nico. Esta
puede ser una de las ya definidas o puede ser una sntesis de los diferentes
aspectos de las opciones existentes. La salida de esta etapa es la opcin
seleccionada de negocios nica, junto con todas las salidas de la etapa de
factibilidad.
Etapa 3 - Requisitos de especificacin
Esta es probablemente la etapa ms compleja en SSADM. Usando los
requisitos desarrollados en la etapa 1 y trabajando en el marco de la opcin de
negocio seleccionado, el analista debe desarrollar una especificacin lgica
completa de lo que el nuevo sistema debe hacer. La especificacin debe estar
libre de error, ambigedad e inconsistencia. Por lgica, nos referimos a que la
especificacin no dice cmo se implementar el sistema, sino que describe lo
que el sistema va a hacer.
Para producir la especificacin lgica, el analista construye los modelos lgicos
necesarios tanto para los diagramas de flujo de datos(DFDs) y el modelo de
datos lgicos (LDM), que consiste en la estructura lgica de datos
(contemplados en otros mtodos como diagramas entidad relacin) y una
44

descripcin completa de los datos y sus relaciones. Estos se utilizan para

producir la definicin de funciones de todas las funciones que los usuarios
requieren del sistema,una entidad de vida-Historias (ELHs) que describen
todos los acontecimientos a travs de la vida de una entidad, y el efecto de
Correspondencia Diagramas (ECD) que describen cmo interacta cada uno
de los eventos con todas las entidades pertinentes. Estos son continuamente
comparan con los requisitos y en caso necesario, se aaden los requisitos para
y completados. El producto de esta etapa es un documento completo con la
especificacin de requisitos que se compone de:

El catlogo de datos actualizada

El catlogo de requisitos actualizado

La especificacin de procesamiento que a su vez se compone de

Rol de usuario matriz de funciones /

Definiciones de funciones

Modelo lgico de datos requerido

Historias de vida entidad

Diagramas efecto correspondencia

Aunque algunos de estos artculos pueden ser desconocidos para usted, est
ms all del alcance de esta unidad para entrar en ellos con gran detalle.
Etapa 4 - opciones del sistema Tcnicas
Esta primera etapa es una implementacin fsica del nuevo sistema. Al igual
que las opciones del sistema de negocio, en esta etapa se generan un gran
nmero de opciones para la aplicacin del nuevo sistema. Esto se perfeccion
hasta dos o tres usuario para presentar desde que se elige la opcin o
sintetizado final. Sin embargo, las consideraciones son seres muy diferentes:

Las arquitecturas de hardware

45

El software a utilizar

El costo de la implementacin

La dotacin de personal necesaria

Las limitaciones fsicas, tales como un espacio ocupado por el sistema

La distribucin incluidas las redes que que pueden requerir

El formato general de la interfaz de la computadora humana

Todos estos aspectos deben tambin ajustarse a las restricciones impuestas

por la empresa, como el dinero y la estandarizacin de hardware y software
disponibles.
La salida de esta etapa es una opcin de sistema tcnico elegido.
Etapa 5 - Diseo lgico
Aunque el nivel anterior especifica los detalles de la ejecucin, los resultados
de esta etapa son independiente de la implementacin y se concentran en los
requisitos de la interfaz de la computadora humana. El diseo lgico especifica
los principales mtodos de interaccin en trminos de estructuras de mens y
estructuras de mando.
Un rea de actividad es la definicin de los dilogos de usuario. Estas son las
principales interfaces con que los usuarios podrn interactuar en el sistema.
Otras actividades estn relacionadas con el anlisis de los efectos de
actualizacin del sistema tanto de los acontecimientos en la necesidad de
hacer consultas sobre los datos en el sistema. Ambos utilizan los eventos,
descripciones de las funciones y diagramas efecto correspondencia producidos
en la etapa 3 para determinar con precisin cmo actualizar y leer datos de una
manera consistente y segura.
El producto de esta etapa es el diseo lgico que se compone de:

Catlogo de datos
46

Estructura de datos lgica requerida

Modelo de proceso lgico - incluye dilogos y modelo para los procesos

de actualizacin y consulta

El estrs y momentos de flexin.

Etapa 6 - Diseo fsico

Esta es la etapa final en la que todas las especificaciones lgicas del sistema
se convierten en las descripciones del sistema en trminos de hardware y
software real. Esta es una etapa muy tcnica y un simple resumen se presenta
aqu.
La estructura lgica de los datos se convierte en una arquitectura fsica en
trminos de estructuras de base de datos. Se especifica la estructura exacta de
las funciones y la forma en que se implementan. La estructura de datos fsica
se optimiza cuando sea necesario para satisfacer los requisitos de tamao y
rendimiento.
El producto es un diseo fsico completo que podra decirle a los ingenieros de
software la manera de construir el sistema en detalles especficos de hardware
y software y para los estndares apropiados

47

1.8. Administracin y control

4. Metodologas mtricas
MTRICA tiene un enfoque orientado al proceso, ya que la tendencia general
en los estndares se encamina en este sentido y por ello, como ya se ha dicho,
se ha enmarcado dentro de la norma ISO 12.207, que se centra en la
clasificacin y definicin de los procesos del ciclo de vida del software. Como
punto de partida y atendiendo a dicha norma, MTRICA cubre el Proceso de
Desarrollo y el Proceso de Mantenimiento de Sistemas de Informacin.
MTRICA ha sido concebida para abarcar el desarrollo completo de Sistemas
de Informacin sea cual sea su complejidad y magnitud, por lo cual su
estructura

responde

desarrollos

mximos

deber

adaptarse

dimensionarse en cada momento de acuerdo a las caractersticas particulares

de cada proyecto.
La metodologa descompone cada uno de los procesos en actividades, y stas
a su vez en tareas. Para cada tarea se describe su contenido haciendo
referencia a sus principales

acciones, productos, tcnicas, prcticas y

participantes.
48

Fases de las mtricas

Fase 0 (Planificacin de Sistemas de Informacin )
El objetivo de un Plan de Sistemas de Informacin es proporcionar un marco
estratgico de referencia para los Sistemas de Informacin de un determinado
mbito de la Organizacin.El resultado del Plan de Sistemas debe, por tanto,
orientar las actuaciones en materia de desarrollo de Sistemas de Informacin
con el objetivo bsico de apoyar la estrategia corporativa, elaborando una
arquitectura de informacin y un plan de proyectos informticos para dar apoyo
a los objetivos estratgicos.Por este motivo es necesario un proceso como el
de Planificacin de Sistemas deInformacin, en el que participen, por un lado
los responsables de los procesos de la organizacin con una visin estratgica
y por otro, los profesionales de SI capaces de enriquecer dicha visin con la
aportacin de ventajas competitivas por medio de los sistemas y tecnologas de
la informacin y comunicaciones.
Fase1(anlisis de sistemas)
El propsito de este proceso es conseguir la especificacin detallada del
sistema de informacin, a travs de un catlogo de requisitos y una serie de
modelos que cubran las necesidades de informacin de los usuarios para los
que se desarrollar el sistema de informacin y que sern la entrada para el
proceso de Diseo del Sistema de Informacin.
Fase 2(diseo de sistemas)
El propsito del Diseo del Sistema de Informacin (DSI) es obtener la
definicin de la arquitectura del sistema y del entorno tecnolgico que le va a
dar soporte, junto con la especificacin detallada de los componentes del
sistema de informacin. A partir de dicha informacin, se generan todas las
especificaciones de construccin relativas al propio sistema, as como la
especificacin tcnica del plan de pruebas, la definicin de los requisitos de
implantacin y el diseo de los procedimientos de migracin y carga inicial,
stos ltimos cuando proceda. El diseo de la arquitectura del sistema
49

depender en gran medida de las caractersticas de la instalacin, de modo

que se ha de tener en cuenta una participacin activa de los responsables de
Sistemas y Explotacin de las Organizaciones para las que se desarrolla el
sistema de informacin.
Este proceso consta de un primer bloque de actividades, que se realizan en
paralelo, y cuyo objetivo es obtener el diseo de detalle del sistema de
informacin que comprende la particin fsica del sistema de informacin,
independiente de un entorno tecnolgico concreto,
la organizacin en subsistemas de diseo, la especificacin del entorno
tecnolgico sobre el que se despliegan dichos subsistemas y la definicin de
los requisitos de operacin, administracin del sistema, seguridad y control de
acceso. En el caso de diseo orientado a objetos, conviene sealar que se ha
contemplado que el diseo de la persistencia se lleva acabo sobre bases de
datos relacionales.
Fase 3 (construccin de sistemas)
La construccin del Sistema de Informacin (CSI) tiene como objetivo final la
construccin y prueba de los distintos componentes del sistema de informacin,
a partir del conjunto de especificaciones lgicas y fsicas del mismo, obtenido
en el Proceso de Diseo del Sistema de Informacin (DSI). Se desarrollan los
procedimientos de operacin y seguridad y se elaboran los manuales de
usuario final y de explotacin, estos ltimos cuando proceda. Para conseguir
dicho objetivo, se recoge la informacin relativa al producto del diseo
Especificaciones de construccin del sistema de informacin, se prepara el
entorno de construccin, se genera el cdigo de cada uno de los componentes
del sistema de informacin y se van realizando, a medida que se vaya
finalizando la construccin, las pruebas unitarias de cada uno de ellos y las de
integracin entre subsistemas. Si fuera necesario realizar una migracin de
datos, es en este proceso donde se lleva a cabo la construccin de los
componentes de migracin y procedimientos de migracin y carga inicial de
datos.
50

Como resultado de dicho proceso se obtiene:

Resultado de las pruebas unitarias.

Evaluacin del resultado de las pruebas de integracin.

Evaluacin del resultado de las pruebas del sistema.

Producto software:o Cdigo fuente de los componentes.

Procedimientos de operacin y administracin del sistema.

Procedimientos de seguridad y control de acceso.

Manuales de usuario.

Especificacin de la formacin a usuarios finales.

Cdigo fuente de los componentes de migracin y carga inicial de datos.

Procedimientos de migracin y carga inicial de datos.

Evaluacin del resultado de las pruebas de migracin y carga inicial de

datos.

Fase 4(implantacin de sistemas)

Este proceso tiene como objetivo principal, la entrega y aceptacin del sistema
en su totalidad, que puede comprender varios sistemas de informacin
desarrollados de manera independiente, segn se haya establecido en el
proceso de Estudio de Viabilidad del Sistema (EVS), y un segundo objetivo que
es llevar a cabo las actividades oportunas para el paso a

produccin del

sistema.
Se establece el plan de implantacin, una vez revisada la estrategia de
implantacin y se detalla el equipo que lo realizar. Para el inicio de este
proceso se toman como punto de partida los componentes del sistema
probados de forma unitaria e integrados en el proceso Construccin del
Sistema de Informacin (CSI), as como la documentacin asociada. El
51

Sistema se someter a las Pruebas de Implantacin con la participacin del

usuario de operacin cuya responsabilidad, entre otros aspectos, es comprobar
el comportamiento del sistema bajo las condiciones ms extremas.Tambin se
someter a las Pruebas de Aceptacin cuya ejecucin es responsabilidad del
usuario final.
Mtodos giles
La adaptacin de mtodos se define como: Un proceso o capacidad en el que
agentes humanos a travs de cambios responsables, e interacciones
dinmicas entre contextos, y mtodos determinan un enfoque de desarrollo de
un sistema para una situacin de proyecto especfica
Potencialmente, casi todos los mtodos giles son adecuados para la
adaptacin. La conveniencia de situacin puede considerarse como una
caracterstica de distincin entre los mtodos giles y los mtodos
tradicionales, que son mucho ms rgidos y perceptivos. La implicacin prctica
es que los mtodos giles permiten a los equipos de proyecto adaptar las
prcticas de trabajo de acuerdo con las necesidades del proyecto individual.
Las prcticas son actividades y productos concretos que son parte del marco
de trabajo del mtodo. En un nivel ms extremo, la filosofa detrs del mtodo,
que consiste en un nmero de principios, podra ser adaptada.
XP hace la necesidad de la adaptacin de mtodos explcita. Una de las ideas
fundamentales de XP es que un proceso no es adecuado para todos los
proyectos, sino ms bien que las prcticas deberan ser adaptadas a las
necesidades de los proyectos individuales. La adopcin parcial de prcticas XP
ha sido informada en varias ocasiones
Gestin de proyectos
Los mtodos giles suelen cubrir la gestin de proyectos. Algunos mtodos se
suplementan con guas en gestin de proyectos. PRINCE2 se ha propuesto
como un sistema de gestin de proyectos complementario y adecuado.

52

Algunas herramientas de gestin de proyectos estn dirigidas para el desarrollo

gil. Estn diseadas para planificar, hacer seguimiento, analizar e integrar
trabajo. Estas herramientas
juegan un papel importante en el desarrollo gil, como medios para la gestin
del conocimiento.
Algunas de las caractersticas comunes incluyen: integracin de control de
versiones, seguimiento de progreso, asignacin de trabajo, versiones
integradas y planificacin de iteraciones, foros de discusin e informe y
seguimiento de defectos de software. La gestin del valor ganado es una
tcnica de gestin de proyectos aprobada por el PMI (Project Management
Institute) para medir objetivamente el xito del proyecto.
Extreme Programming (XP)
La programacin extrema (XP) es un enfoque de la ingeniera del software
formulado por Kent Beck. Es el ms destacado de los procesos giles de
desarrollo de software. Al igual que stos, la programacin extrema se
diferencia de las metodologas tradicionales principalmente en que pone ms
nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP
consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que
ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la
vida del proyecto es una aproximacin mejor y ms realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en
controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las
mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a
cabo con el proyecto y aplicarlo de manera dinmica durante el ciclo de vida
del software.
XP

es

una

metodologa

gil

centrada

en

potenciar

las

relaciones

interpersonales como clave para el xito en el desarrollo de software,

53

promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los

desarrolladores, y propiciando un buen clima de trabajo. XP se basa en la
realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin
fluida

entre

todos

los

participantes,

simplicidad

en

las

soluciones

implementadas y coraje para enfrentar los cambios. XP se define como

especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo tcnico. A Kent Beck se le considera
el padre de XP.
Los principios y prcticas son de sentido comn pero llevada al extremo, de ah
proviene su nombre.
Elementos de la metodologa

Roles XP: los roles de acuerdo con la propuesta de Beck son:

Programador: el programador escribe las pruebas unitarias y produce el

cdigo del sistema

Cliente: escribe las historias de usuario y las pruebas funcionales para

validar su implementacin. Adems, asigna la prioridad a las historias de
usuario y decide cules se implementan en cada iteracin centrndose
en apoyar mayor valor al negocio.

Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas

funcionales. Ejecuta las pruebas regularmente, difunde los resultados en
el equipo y es responsable de las herramientas de soporte para las
pruebas.

Encargado de seguimiento (tracker): proporciona realimentacin al

equipo. Verifica el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado, para mejorar futuras estimaciones. Realiza el
seguimiento del progreso de cada iteracin.

54

Entrenador (coach): es el responsable del proceso global. Debe

proveer guas al equipo de forma que se apliquen las prcticas XP y se
siga el proceso correctamente.

Consultor: es un miembro externo del equipo con un conocimiento

especfico en algn tema necesario para el proyecto, en el que puedan
surgir problemas.

Gestor (big boss): es el vnculo entre clientes y programadores, ayuda

a que el equipo trabaje efectivamente creando las condiciones
adecuadas. Su labor esencial es de coordinacin.

55

Metodologa scrum
es un proceso gil que se usa para gestionar y controlar desarrollos complejos
de software y productos usando prcticas iterativas e incrementales.
Scrum es un proceso incremental iterativo para desarrollar cualquier producto o
gestionar cualquier trabajo. Aunque Scrum estaba previsto que fuera para la
gestin de proyectos de desarrollo de software, se puede usar tambin para la
ejecucin de equipos de mantenimiento de software o como un enfoque de
gestin de programas.
Caractersticas
Es un esqueleto de proceso que incluye un conjunto de prcticas y roles
predefinidos. Los roles principales en Scrum son el ScrumMaster que
mantiene los procesos y trabaja junto con el jefe de proyecto, el Product
Owner que representa a las personas implicadas en el negocio y el Team
que incluye a los desarrolladores.
Durante cada iteracin (sprint- periodos de tiempo), tpicamente un periodo de
2 a 4 semanas (longitud decidida por el equipo), el equipo crea un incremento
de software operativo. El conjunto de caractersticas que entra en una iteracin
viene del backlog del producto, que es un conjunto priorizado de requisitos de
trabajo de alto nivel que se han de hacer. Los tems que entran en una iteracin
se determinan durante la reunin de planificacin de la iteracin. Durante esta
reunin, el Product Owner informa al equipo de los tems en el backlog del
producto que quiere que se completen. El equipo determina entonces a cuanto
de eso puede comprometerse a completar durante la siguiente iteracin.
Durante una iteracin, nadie puede cambiar el backlog de la iteracin, lo que
significa que los requisitos estn congelados para esa iteracin. Cuando se
completa una iteracin, el equipo demuestra el uso del software. Scrum permite
la creacin de equipos con propia organizacin fomentando la localizacin
conjunta de todos los miembros del equipo y la comunicacin verbal entre
todos los miembros del equipo y las disciplinas implicadas en el proyecto.

56

57