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

UNIVERSIDADNACIONALSANLUISGONZAGA

FACULTADDEINGENIERIADESISTEMAS

EscueladeIngenieradeSistemas

MODELOSDECICLODEVIDADESOFTWARE

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.

2

INDICEMODELOS DE CICLO DE VIDA DEL SOFTWARE...............................................................................................5Actividades del desarrollo de software..........................................................................................................6MODELOS DE CICLO DE VIDA.........................................................................................................................7Clasificacin...................................................................................................................................................8Modelos descriptivos vs. Modelos prescriptivos............................................................................................8Modelos tradicionales vs. Modelos evolutivos...............................................................................................9Modelos de Ciclo de Vida del software.........................................................................................................10Modelo Cascada...........................................................................................................................................10Descripcin del modelo................................................................................................................................10Existen 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....................................................................................................................................11Desventajas con el Modelo Cascada............................................................................................................12Aplicacin del modelo cascada....................................................................................................................12Prototipado...13

Espiral....14

Descripcin del modelo................................................................................................................................17Ventajas........................................................................................................................................................18Desventajas..................................................................................................................................................18Aplicacin del modelo..................................................................................................................................18Modelo V...19

Ventajas........................................................................................................................................................20Desventajas..................................................................................................................................................20Modelo Iterativo..21

Ventajas........................................................................................................................................................22Inconvenientes.............................................................................................................................................22Modelo de desarrollo incremental...23

Ventajas........................................................................................................................................................23Desventajas..................................................................................................................................................24METODOLOGA DEL DESARROLLO DE SOFTWARE.......................................................................................25Introduccin.................................................................................................................................................25Definicin de metodologa...........................................................................................................................26Metodologa vs ciclo de vida........................................................................................................................26ventajas del uso de metodologas para el desarrollo de software...............................................................27Desde el punto de vista de gestin:............................................................................................................27Desde el punto de vista de los ingenieros del software..............................................................................27Desde el punto de vista del cliente o usuario..............................................................................................27Clasificacin de las metodologas................................................................................................................28Metodologas estructurada..........................................................................................................................28

3

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

4

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

5

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.

6

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.

7

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 la

arquitectura.

22

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 estructuradas se basan en la estructuracin y

descomposicin funcional de problemas en unidades ms pequeas

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

datos, de una manera jerrquica y ven el sistema como entradas-proceso-

salidas.

Existe una gran cantidad de proyectos implementados utilizando estas

metodologas, generalmente orientados a 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 sido

claramente asociadas a una sola clase.

Optimizar los accesos a datos:

Aadir asociaciones redundantes para minimizar el coste 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 a desarrollos mximos y deber adaptarse y

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 ca