View
1
Download
0
Embed Size (px)
DESCRIPTION
Este reciente documento contiene información acerca del ciclo de vida de un software .Así como también sus pasos y procedimientos adecuados.
Citation preview
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