INSTITUTO TECNOLÓGICO          DE ACAPULCO       INGENIERIA EN SISTEMAS         COMPUTACIONALESFundamentos de desarrollo d...
ÍNDICE DE CONTENIDOUNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE ........................ 33.1 EL ENFOQUE ESTRUCTURAD...
UNIDAD IIIPARADIGMAS DE LA INGENIERÍA DE SOFTWARE        La ingeniería de software está compuesta por una serie de pasos d...
Existen tres categorías de paradigmas de programación:   a) Los que soportan técnicas de programación de bajo nivel (ejemp...
En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos)como principal herramienta para entender al sistema...
Figura 3.1 Refinamiento del flujo de informaciónUn diagrama de flujo de datos (DFD) es una representación gráfica de lospr...
1. Libertad para emprender la implementación técnica del sistema en las      primeras etapas.   2. Comprensión más profund...
El cuadrado doble se usa para describir una entidad externa que puede enviardatos al sistema o recibirlos de él. La entida...
flujo de entrada y salida se deben examinar en busca de flujos de datos      perdidos.El rectángulo abierto representa un ...
salidas. Al proceso se le asigna el numero cero. En este diagrama se muestrantodas las entidades externas, así como los fl...
El diagrama cero es la ampliación del diagrama de contexto y puede incluirhasta nueve procesos, esto se hace porque si se ...
problemáticas podrá realizar una lista de preguntas para las entrevistas de   seguimiento con los usuarios clave.Creación ...
Almacén de                                           D1                                                                   ...
Se ha propuesto el diccionario de datos como gramática casi formal para describirel contenido de los objetos definidos dur...
que usan el dato o la información de control y cómo lo usan. Aunque esto puedano parecer importante, realmente es una de l...
3.1.2.2 Creación del Diccionario de Datos       Las entradas del diccionario de datos se podrían crear después decompletar...
6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o       derivados y sus criterios de edición.D...
3.1.3 DISEÑO DE MÓDULOS       La arquitectura de computadora expresa la modularidad; es decir, elsoftware se divide en com...
problema por separado. Teniendo en cuenta la ecuación (3.2) y la condiciónimplicada por la ecuación (3.1) se establece que...
Las curvas de la Figura 3.4 proporcionan en efecto una guía útil cuando se tieneen consideración la modularidad. La modula...
que los subprogramas introduzcan sobrecargas de memoria y de velocidad pormínimos que sean (por ejemplo, subrutinas, proce...
cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega yevaluación del cliente) puede adaptarse al ...
7. Revisar todas las mini-especificaciones para comprobar             su      corrección , su consistencia la ausencia de ...
El trabajo técnico asociado con la ingeniería del software OO sigue las siguientestareas:    1.      Identificar clases ca...
Los      Objetos   tienen      características   y   comportamientos.   Mantiene   suscaracterísticas en una o más "variab...
AtributoLos Atributos están asociados a clases y objetos, ellos describen la clase y elobjeto de alguna manera. Un atribut...
EL Ocultamiento es la capacidad de ocultar los detalles internos delcomportamiento de una clase y exponer sólo los detalle...
diferentes puntos de vista. El análisis representa los requisitos de tresdimensiones, por esa razón, se incrementa la prob...
clases y objetos y realiza una serie de refinamientos para elaborar el modelo   del análisis. El método de Rumbaugh. Rumb...
o Identificar relaciones entre clases.       o Definir     colaboraciones       entre   clases        basándose        en ...
El diseño de software orientado a objetos es difícil, y el diseño de softwarereusable orientado a objetos es aun más difíc...
Diseño de sistema: crea la arquitectura del producto definiendo una serie decapas, que cumplen funciones específicas del s...
 La capa de clases y objetos. Contiene la jerarquía de clases, que permiten al   sistema ser creado usando generalizacion...
UNIDAD IVMODELOS DE PROCESO DE SOFTWARE:Introducción:El proceso es el conocimiento incorporado, y puesto que el conocimien...
Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo deprocesos del Software es una simplificación...
El primer paso es conseguir un documento con la especificación completa,exacta, no ambigua de los requisitos del sistema s...
la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir uncambio en las fases más avanzadas de un p...
Diseño         Se enfoca en cuatro atributos distintos del programa: la estructura de losdatos, la arquitectura del softwa...
Desventajas      Los proyectos reales raramente siguen el flujo secuencial que propone el       modelo, siempre hay itera...
4.2 MODELO DE ESPIRAL      Propuesto originalmente por Boehm en 1988, es un modelo de proceso desoftware evolutivo ha sido...
Con cada iteración alrededor de la espiral (comenzando en el centro ysiguiendo hacia el exterior), se construyen sucesivas...
4.3 MODELO INCREMENTAL      El modelo incremental aplica secuencias lineales de forma escalonadamientras avanza el tiempo....
El Modelo Incremental es particularmente útil cuando no se cuenta con unadotación de personal suficiente. Los primeros pas...
Características.    Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con      cierta frecuencia.   ...
 Requiere de mucha planeación, tanto administrativa como técnica.    Requiere de metas claras para conocer el estado del...
Características:- Iterativo e IncrementalEl Proceso Unificado es un marco de desarrollo iterativo e incremental compuestod...
- Enfocado en los riesgosEl Proceso Unificado requiere que el equipo del proyecto se centre en identificarlos riesgos crít...
- Revisión entre colegas.- Ingeniería del producto de Software.- Manejo integrado del Software.- Definición del proceso de...
El Proceso Personal Software, conocido por sus siglas como PSP es unaalternativa dirigida a los ingenieros de Sistemas, qu...
introduciendo tareas y actividades para un mejor manejo de los aspectos deinterés en nivel, o bien para incluir nuevos asp...
Upcoming SlideShare
Loading in …5
×

94368577 unidad-iii-y-iv

540 views

Published on

nvvjgbhjgh

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
540
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

94368577 unidad-iii-y-iv

  1. 1. INSTITUTO TECNOLÓGICO DE ACAPULCO INGENIERIA EN SISTEMAS COMPUTACIONALESFundamentos de desarrollo de sistemas Profesor. Daniel Solís Chávez Integrantes del Equipo: Ana Alexis Vargas Beltrán No. De control 09320776 Basilio Isaac Moctezuma Saucedo No. De control 09320746 Luis Antonio Huerta Silva No. de control 09320741 Manuel Pérez Nava No. De control 09320787 Horario: Lunes a Viernes de 11:00-12:00 pm. Acapulco Gro. A 17 de Mayo del 2012 1
  2. 2. ÍNDICE DE CONTENIDOUNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE ........................ 33.1 EL ENFOQUE ESTRUCTURADO .................................................................... 4 3.1.1 DIAGRAMAS DE FLUJOS DE DATOS. .............................................. 5 3.1.2 DICCIONARIOS DE DATOS. ............................................................ 13 3.1.3 DISEÑO DE MÓDULOS .................................................................... 18 3.1.4 DESCOMPOSICIÓN EN PROCESOS .............................................. 213.2 EL ENFOQUE ORIENTADO A OBJETOS ...................................................... 23 3.2.1 ANÁLISIS. .......................................................................................... 27 3.2.2 DISEÑO. ............................................................................................ 30UNIDAD IV MODELOS DEL PROCESO DE SOFTWARE................................... 344.1 MODELO DE CASCADA................................................................................. 354.2 MODELO DE ESPIRAL ................................................................................... 404.3 MODELO INCREMENTAL .............................................................................. 424.4 PROCESO DE DESARROLLO UNIFICADO .................................................. 454.5 PROCESO SOFTWARE PERSONAL ............................................................. 47BIBLIOGRAFÍA .................................................................................................... 50 2
  3. 3. UNIDAD IIIPARADIGMAS DE LA INGENIERÍA DE SOFTWARE La ingeniería de software está compuesta por una serie de pasos deabarcan los métodos, las herramientas y los procedimientos, estos pasos sedenominan frecuentemente paradigmas de la ingeniería de software. La elecciónde un paradigma para la ingeniería de software se lleva a cabo de acuerdo con lanaturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, loscontroles y entregas requeridos. En un nivel técnico, la ingeniería del software empieza con una serie de tareasde modelado que llevan a una especificación completa de los requisitos y a unarepresentación del diseño general del software a construir. El modelo de análisis, realmente un conjunto de modelos, es la primerarepresentación técnica de un sistema. Con los años se han propuesto muchosmétodos para el modelado del análisis. Sin embargo, ahora dos tendenciasdominan el panorama del modelado del análisis. El primero, análisis estructurado,es un método de modelado clásico. El otro enfoque, análisis orientado a objetos. El análisis estructurado es una actividad de construcción de modelos. Medianteuna notación que satisfaga los principios de análisis operacional, creamosmodelos que representan el contenido y flujo de la información (datos y control);partimos el sistema funcionalmente, y según los distintos comportamientosestablecemos la esencia de lo que se debe construir. El análisis estructurado noes un método sencillo aplicado siempre de la misma forma por todos los que lousan. Un paradigma de programación es un modelo básico de diseño y desarrollode programas, que permite producir programas con una directriz específica, talescomo: estructura modular, fuerte cohesión, alta rentabilidad, etc. 3
  4. 4. Existen tres categorías de paradigmas de programación: a) Los que soportan técnicas de programación de bajo nivel (ejemplo: copia de ficheros frente estructuras de datos compartidos) b) Los que soportan métodos de diseño de algoritmos (ejemplo: divide y vencerás, programación dinámica, etc.) c) Los que soportan soluciones de programación de alto nivel, como los descritos en el punto anteriorLos paradigmas relacionados con la programación de alto nivel se agrupan en trescategorías de acuerdo con la solución que aportan para resolver el problema: a) Solución procedimental u operacional. Describe etapa a etapa el modo de construir la solución. Es decir señala la forma de obtener la solución. b) Solución demostrativa. Es una variante de la procedimental. Especifica la solución describiendo ejemplos y permitiendo que el sistema generalice la solución de estos ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir resultados muy diferentes a ésta, hace que sea tratada como una categoría separada. c) Solución declarativa. Señala las características que debe tener la solución, sin describir cómo procesarla. Es decir señala qué se desea obtener pero no cómo obtenerlo.3.1 EL ENFOQUE ESTRUCTURADO La primera aparición del enfoque de análisis estructurado fue comocomplemento de otro tema importante - el «diseño estructurado»-. Losinvestigadores, necesitaban una notación gráfica para representar los datos y losprocesos que los transforman. Esos procesos quedarían finalmente establecidosen una arquitectura de diseño. 4
  5. 5. En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos)como principal herramienta para entender al sistema antes de plasmarlo a códigofuente. DFD es un diagrama en el q participan procesos (métodos), flujo de datos(argumentos) y archivos (base de datos).Hay de diferentes niveles dependiendo la complejidad del sistema q analiza. Otradesventaja es que una porción de código en lenguaje estructurado es difícil quepueda servir en otros proyectos.3.1.1 DIAGRAMAS DE FLUJOS DE DATOS.A medida que la información se mueve a través del software, es modificada poruna serie de transformaciones.El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de lainformación y las transformaciones que se aplican a los datos al moverse desde laentrada hasta la salida. En la Figura 3.1 se muestra la forma básica de undiagrama de flujo de datos. El DFD es también conocido como grafo de flujo dedatos o como diagrama de burbujas. 5
  6. 6. Figura 3.1 Refinamiento del flujo de informaciónUn diagrama de flujo de datos (DFD) es una representación gráfica de losprocesos que se realizan con los datos en su organización, con el uso de tan solocuatro símbolos, se puede crear una descripción grafica de los procesos que, conel tiempo, contribuirán a desarrollar una sólida documentación del sistema. Se puede usar el diagrama de flujo de datos para representar un sistema oun software a cualquier nivel de abstracción. De hecho, los DFDs pueden serdivididos en niveles que representen un mayor flujo de información y un mayordetalle funcional. Por consiguiente, el DFD proporciona un mecanismo para elmodelado funcional, así como el modelado del flujo de información. Al hacer esto,se cumple el segundo principio de análisis operacional.Un DFD de nivel O, también denominado modelo fundamental del sistema omodelo de contexto, representa al elemento de software completo como una solaburbuja con datos de entrada y de salida representados por flechas de entrada yde salida, respectivamente. Al dividir el DFD de nivel O para mostrar más detalles,aparecen representados procesos (burbujas) y caminos de flujo de informaciónadicionales.La notación básica que se usa para desarrollar un DFD no es en sí mismasuficiente para describir los requisitos del software.En seguida mencionan las ventajas sobre las explicaciones descriptivas enrelación con la forma en que los datos se mueven a través del sistema: 6
  7. 7. 1. Libertad para emprender la implementación técnica del sistema en las primeras etapas. 2. Comprensión más profunda de la interrelación entre sistemas y subsistemas. 3. Comunicación con los usuarios sobre el conocimiento del sistema actual mediante diagramas de flujos de datos. 4. Análisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. La ventaja más grande es la libertad conceptual para utilizar los cuatrosímbolos, los DFD’s hacen énfasis en el procesamiento o la transformaciónconforme estos pasan por una variedad de procesos. En los DFD’s lógicos no haydistinción entre procesos manuales o automatizados. Los procesos tampoco serepresentan gráficamente en orden cronológico. En vez de ello, se agrupan solo siel análisis detallado dicta que tiene sentido hacerlo. Los procesos manuales seagrupan, y los procesos automatizados también se pueden agrupar.3.1.1.1 Simbología En los diagramas de flujos de datos se usan cuatro símbolos básicos paragraficar el movimiento de los datos: Un cuadrado doble, una flecha, un rectángulocon esquinas redondeadas(o una burbuja) y un rectángulo abierto (cerrado en ellado izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 acontinuación. Con la combinación de estos cuatro símbolos se puede describirgráficamente un sistema completo y varios subsistemas. 7
  8. 8. El cuadrado doble se usa para describir una entidad externa que puede enviardatos al sistema o recibirlos de él. La entidad externa, o solo entidad, también sellama origen o destino de datos, y se considera externa al sistema descrito. A cadaentidad se le asigna un nombre adecuado. Aunque interactúa con el sistema, seconsidera fuera de los límites de este. La misma entidad se podría usar más deuna vez en un diagrama de flujo de datos en particular para evitar que las líneasse crucen en el flujo de datos.La flecha muestra el movimiento de los datos de un punto a otro, con la punta dela flecha señalando hacia el destino de los datos. Los flujos de datos que ocurrensimultáneamente se pueden describir mediante flechas paralelas. Una flechatambién puede se debe describir con un nombre, debido a que representan losdatos de un apersona, lugar o cosa.Rectángulo con esquinas redondeadas se usa para mostrar la presencia de unproceso de transformación. Los procesos siempre denotan un cambio en los datoso una transformación de estos; por lo tanto el flujo de datos que sale de unproceso siempre se designa de forma diferente al que entra en el. Los procesosrepresentan trabajo que se realiza en el tema.  A un proceso se le debe de asignar un número de identificación único y exclusivo, que indique su nivel en el diagrama. Podría haber varios flujos de datos que entren y salgan de cada proceso. Los procesos con solo un 8
  9. 9. flujo de entrada y salida se deben examinar en busca de flujos de datos perdidos.El rectángulo abierto representa un almacén de datos. Estos símbolos se dibujancon el espacio suficiente para que quepan las letras de identificación como semuestra en la figura. En los diagramas de flujo de datos lógicos no se especifica eltipo de almacenamiento a un lugar. En este punto el símbolo del almacén dedatos simplemente muestra un lugar de depósito para los datos que permiteexaminar, agregar y recuperar datos.3.1.1.2 Desarrollo de Diagramas de Flujos de Datos Los diagramas de flujos de datos se pueden y deben dibujar de manerasistemática. Primero se deben visualizar los flujos de datos desde una perspectivajerárquica de arriba a bajo. En seguida se describen los pasos a seguir.Lista de actividades Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativadel sistema de la organización en una lista con las cuatro categorías de entidadexterna, flujo de datos, procesos, y almacén de datos. Esta lista a su vez ayudaraa determinar los límites del sistema que describirá. Una vez que se hayarecopilado una lista básica de elementos de datos se empieza a dibujar eldiagrama de contexto.Creación de diagrama de contexto Con un enfoque jerárquico de arriba hacia abajo para diagramar elmovimiento de los datos, los diagramas van de lo general a lo específico. Aunqueel primer diagrama ayuda a entender el movimiento básico de los datos, lo generalde su naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrarun panorama global que incluya las entradas básicas, el sistema general y las 9
  10. 10. salidas. Al proceso se le asigna el numero cero. En este diagrama se muestrantodas las entidades externas, así como los flujos de datos principales que vandesde y hacia dichas entidades. El diagrama no contiene ningún almacén dedatos. Es bastante simple la creación ya que se conocen las entidades externas yel flujo de datos desde y hacia ellas.Dibujo del diagrama 0 (el siguiente nivel)Al ampliar los programas se puede lograr un mayor detalle que con los diagramasde contexto. Las entradas y salidas especificadas en el primer diagramapermanecen constantes en todos los diagramas que le siguen. Sin embargo, elresto del diagrama original se amplia para incluir de tres a nueve procesos ymostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cadadiagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs pararepresentar subprocesos, en este paso se empiezan a completar los detalles delmovimiento de los datos. El manejo de excepciones se ignora en los primero dos otres niveles del diagrama de flujo de datos. 10
  11. 11. El diagrama cero es la ampliación del diagrama de contexto y puede incluirhasta nueve procesos, esto se hace porque si se agregan más procesos produciráun diagrama difícil de entender. Por lo general, cada proceso se numero con unentero, empezando en la esquina superior izquierda del diagrama y terminando enla esquina inferior derecha. En el diagrama cero se incluyen los principalesalmacenes de datos del sistema (que representan a los archivos maestros) y todaslas entidades externas. La figura 3.2 representa gráficamente el diagrama decontexto y el diagrama cero. Debido a que un diagrama de flujo de datos es bidimensional, se puedeempezar en cualquier punto del diagrama e ir hacia delante o hacia atrás. Si noesta seguro de lo que podría incluir en cualquier punto, tome una entidad externa,un proceso o un almacén de datos diferente y empiece a dibujar el flujo a partir deél:1. Empezamos con el flujo de datos de una entidad en el lado de la entrada. Se hacen preguntas como: ¿Qué sucede con los datos que entran en el sistema? ¿Se almacenan? ¿Esta entrada es para varios procesos?2. Trabajamos hacia atrás a partir de un flujo de datos de salida. Examinamos los campos de salida de un documento o pantalla. Se pregunta sobre cada campo de la salida: "¿De dónde viene?" o "¿Se calcula o almacena en un archivo?" Examinamos el flujo de datos desde o hacia un almacén de datos. Se pregunta: "¿Qué procesos ponen los datos en el almacén?" o "¿Qué procesos usan los datos?" Observamos que un almacén de datos utilizado en el sistema en el que se esta trabajando podría ser producido por un sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya ningún flujo de datos hacia el almacén de datos.3. Analizamos un proceso bien definido. Vea qué entrada de datos necesita el proceso y qué salida produce. Se hace un vínculo la entrada y la salida con los almacenes de datos y las entidades adecuadas.4. Tome nota de cualquier área confusa en donde no esté seguro de lo que se debe incluir o de la entrada o la salida que se requiera. Al conocer las áreas 11
  12. 12. problemáticas podrá realizar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave.Creación de diagramas hijos (niveles mas detallados)Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear undiagrama hijo más detallado. El proceso del Diagrama cero a partir del cual serealiza la ampliación se llama proceso padre, y el diagrama que se produce sellama diagrama hijo. La regla principal para crear diagramas hijos, es el equilibriovertical, estipula que un diagrama hijo no puede producir salida o no puede recibirentrada que el proceso padre no produzca o reciba también. Por lo regular las entidades no se muestran en los diagramas hijos debajodel diagrama cero. El flujo de datos que coincide con el flujo padre se llama flujode datos de interfaz y se representa con una flecha que parte de un área vacía deldiagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacénde datos, también el diagrama hijo podría incluir el almacén de datos. Además,este diagrama de nivel inferior podría contener almacenes de datos que no semuestran en el proceso padre. En un diagrama hijo se podrían incluir un flujo dedatos de nivel inferior, como una línea de error, aunque no se podría hacer lomismo en el proceso padre.Los procesos se podrían ampliar o no ampliar, dependiendo de su nivel decomplejidad. Cuando no se amplia un proceso, se dice que es funcionalmenteprimitivo y se llama proceso primitivo. En la figura 3.3 se ilustran niveles detalladosde un diagrama de flujos de datos hijo. 12
  13. 13. Almacén de D1 El flujo de datos Datos 1 A Registro coincidente Entrada B 3 Flujo de 4 Entidad 2 datos D Proceso Proceso El flujo de datos Almacén de D1 del proceso padre debe coincidir con Datos 1 el diagrama hijo Registro A Registro Registro Entrada B 3.1 de 3 de transacción Archivo de transacción D5 Transacción 1 Proceso Proceso Error Flujo de datos En los diagramas Z detallado de nivel inferior se podrían agregar archivos de En un diagrama 3 transacciones hijo detallado se podrían agregar líneas de error El flujo de salida Proceso debe coincidir con Flujo de datos D el proceso padre Figura 3.3 Representación del diagrama de contexto y del diagrama cero Kendall Kenneth E. & Kendall Julie E., Análisis y diseño de sistemas, Ed. Prentice Hall 6ª ed3.1.2 DICCIONARIOS DE DATOS. El modelo de análisis acompaña representaciones de objetos de datos,funciones y control. En cada representación los objetos de datos y/o elementos decontrol juegan un papel importante. Por consiguiente, es necesario proporcionarun enfoque organizado para representar las características de cada objeto dedatos y elemento de control. Esto se realiza con el diccionario de datos. 13
  14. 14. Se ha propuesto el diccionario de datos como gramática casi formal para describirel contenido de los objetos definidos durante el análisis estructurado. Estaimportante notación de modelado ha sido definida de la siguiente forma: El diccionario de datos es un listado organizado de todos los elementos dedatos que son pertinentes para el sistema, con definiciones precisas y rigurosasque permiten que el usuario y el analista del sistema tengan una mismacomprensión de las entradas, salidas, de las componentes de los almacenes ytambién de los cálculos intermedios.Actualmente, casi siempre se implementa el diccionario de datos como parte deuna «herramienta CASE de análisis y diseño estructurados». Aunque el formatodel diccionario varía entre las distintas herramientas, la mayoría contiene lasiguiente información: Nombre: el nombre principal del elemento de datos o de control, del almacén de datos, o de una entidad externa. Alias: otros nombres usados para la primera entrada. Donde se usa / como se usa: un listado de los procesos que usan el elemento de datos o de control y cómo lo usan (por ejemplo, como entrada al proceso, como salida del proceso, como almacén de datos, como entidad externa). Descripción del contenido: el contenido representado mediante una notación. Información adicional: otra información sobre los tipos de datos, los valores implícitos (si se conocen), las restricciones o limitaciones, etc. Una vez que se introducen en el diccionario de datos un nombre y sus alias,se debe revisar la consistencia de las denominaciones. Esto mejora laconsistencia del modelo de análisis y ayuda a reducir errores.La información de «dónde se usa/cómo se usa» se registra automáticamente apartir de los modelos de flujo. Cuando se crea una entrada del diccionario, laherramienta CASE inspecciona los DFD y los DFC para determinar los procesos 14
  15. 15. que usan el dato o la información de control y cómo lo usan. Aunque esto puedano parecer importante, realmente es una de las mayores ventajas del diccionario.Durante el análisis, hay una corriente casi continua de cambios. Al poder tratar eldiccionario de datos como una base de datos, el analista puede hacer preguntasbasadas en «dónde se usa/cómo se usan y obtener respuestas a peticionessimilares a las anteriores.La notación utilizada para desarrollar una descripción de contenido se indica en lasiguiente tabla:La notación permite al ingeniero del software representar una composición dedatos en una de las tres alternativas fundamentales que pueden ser construidas1. Como una secuencia de elementos de datos.2. Como una selección de entre un conjunto de elementos de datos.3. Como una agrupación repetitiva de elementos de datos. Cada entrada deelemento de datos que aparezca como parte de una secuencia, una selección ouna repetición puede a su vez ser otro elemento de datos compuestos quenecesite un mayor refinamiento en el diccionario.Además de proporcionar documentación y eliminar la redundancia, el diccionariodatos se podría usar para: 1. Validar la integridad y exactitud del diagrama de flujo de datos. 2. Proporcionar un punto de partida para desarrollar pantallas e informes, 3. Determinar el contenido de los datos almacenados en archivos. 4. Desarrollar la lógica para los procesos del diagrama de flujo de datos. 15
  16. 16. 3.1.2.2 Creación del Diccionario de Datos Las entradas del diccionario de datos se podrían crear después decompletar el diagrama de flujo de datos, o se podrían construir conforme sedesarrolle el diagrama de flujo de datos. El uso de notación algebraica y registrosestructurales permite desarrollar el diccionario de datos y los diagramas de flujosde datos mediante un enfoque jerárquico de arriba a bajo. Después de realizar varias entrevistas adicionales para descubrir losdetalles del sistema, se puede extender el diagrama de flujo de datos y se crearanlos diagramas hijos. Posteriormente se modifica el diccionario de datos para incluirlos nuevos registros estructurales y elementos recabados en las entrevistas,observación y análisis de documentos posteriores. Cada nivel de un diagrama de flujo de datos debe usar datos adecuadospara el nivel. El diagrama 0 debe incluir únicamente formularios, pantallasinformes y registros. Conforme se creen los diagramas hijos, el flujo de datos queentre y salga de los procesos será cada vez mas detallado, incluyendo losregistros estructurales y los elementos.Análisis de las entradas y salidas Un paso importante en la creación del diccionario de datos es identificar ycategorizar el flujo de datos de entrada y salida del sistema. Campos comúnmenteincluidos: 1. Nombre descriptivo para la entrada o la salida. Si el flujo de datos esta en un diagrama lógico, el nombre debe identificar el propósito de los datos. 2. El contacto del usuario responsable para la clarificación de detalles adicionales, retroalimentación del diseño y aprobación final 3. Si los datos son de entrada o salida 4. El formato de flujo de datos. En la fase del diseño lógico, el formato podría ser indeterminado. 5. Elementos que indican la secuencia de los datos en un informe o pantalla. 16
  17. 17. 6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o derivados y sus criterios de edición.Desarrollo de almacenes de datos Otra actividad es el desarrollo de los almacenes de datos. Esta informaciónse describe en estructuras de datos. Sin embargo la información podría estaralmacenada en diferentes lugares, y el almacén de datos podría ser diferente encada lugar. Mientras que los flujos de datos representan datos en movimiento, losalmacenes de datos representan datos en reposo. Los almacenes de datos contienen información de una naturalezapermanente o semipermanente.Cuando los almacenes de datos se crean para un solo informe o pantalla nosreferimos a ellos como “vistas del usuario”, porque representan la manera en queel usuario quiere ver la información.Uso del diccionario de datos El diccionario de datos ideal es automatizado, interactivo, en línea yevolutivo. Conforme el analista de sistemas descubre cosas nuevas de lossistemas de la organización, se agregan elementos de datos al diccionario dedatos. El diccionario de datos no es un fin en si mismo y nunca debe serlo,siempre debe verse como una actividad paralela al análisis y diseño de sistemas. El diccionario de datos debe vincular a varios programas de sistemas paraque cuando un elemento se actualice o elimine del diccionario de datos, ocurra lomismo en la base de datos. El diccionario de datos se vuelve una curiosidadhistórica sino se mantiene actualizado. 17
  18. 18. 3.1.3 DISEÑO DE MÓDULOS La arquitectura de computadora expresa la modularidad; es decir, elsoftware se divide en componentes nombrados y abordados por separado,llamados frecuentemente módulos, que se integran para satisfacer los requisitosdel problema. Se ha afirmado que “La modularidad es el único atributo del software quepermite gestionar un programa intelectualmente”. El software monolítico no puedeser entendido fácilmente por el lector. La cantidad de rutas de control, la amplitudde referencias, la cantidad de variables y la complejidad global hará que elentendimiento este muy cerca de ser imposible. Para ilustrar este punto, tomemosen consideración el siguiente argumento basado en observaciones humanas sobrela resolución de problemas. Pensemos que C(x) es una función que define la complejidad percibida deun problema x, y que E(x) es una función que define el esfuerzo (oportuno) que serequiere para resolver un problema x. para dos problemas p1 y p2, siC(p1) > C(p2) (3.1a)Implica queE(p1) > E(p2) (3.1b)En general, este resultado es por intuición obvio. Se tarda más en resolver unproblema difícil.Mediante la experimentación humana en la resolución de problemas se haaveriguado otra característica interesante. Esta es,C(p1 + p2) > C(p1) + C(p2) (3.2) La ecuación 3.2 implica que la complejidad percibida de un problema quecombina p1 y p2, es mayor que la complejidad percibida cuando se considera cada 18
  19. 19. problema por separado. Teniendo en cuenta la ecuación (3.2) y la condiciónimplicada por la ecuación (3.1) se establece queE(p1 + p2) > E(p1) + E(p2) (3.3) Es más fácil resolver un problema complejo cuando se rompe en piezasmanejables. El resultado expresado en la ecuación 3.3 implica que es importanteen lo que respecta a la modularidad y al software. Es, de hecho, un argumentopara la modularidad. Es posible concluir de la ecuación (3.3) que si subdividimos el softwareindefinidamente, el esfuerzo que se requiere para desarrollarlo sería mínimo.Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusión seafalsa. Como muestra la figura 3.4, el esfuerzo para desarrollar un módulo softwareindividual disminuye a medida que aumenta el número total de módulos. Dado elmismo conjunto de requisitos: tener más módulos conduce a un tamaño menor demódulo. Sin embargo, a medida que aumenta el número de módulos, tambiéncrece el esfuerzo asociado con la integración de módulos. Estas característicasconducen también a la curva total del costo o esfuerzo que se muestra en lafigura. Existe un número M de módulos que daría como resultado un costo mínimode desarrollo, aunque no tenemos la sofisticación necesaria para predecir M conseguridad. 19
  20. 20. Las curvas de la Figura 3.4 proporcionan en efecto una guía útil cuando se tieneen consideración la modularidad. La modularidad deberá aplicarse, pero teniendocuidado de estar próximo a M. Se deberá evitar modularizar de más o de menos. Cuando se tiene en consideración la modularidad surge otra preguntaimportante. ¿Cómo se define un modulo con un tamaño adecuado? La respuestase, encuentra en los métodos utilizados para definir los módulos dentro de unsistema. Meyer define cinco criterios que nos permitirán evaluar un método dediseño en relación con la habilidad de definir un sistema modular efectivo: Capacidad de descomposición modular. Si un método de diseño proporciona un mecanismo sistemático para descomponer el problema en subproblemas, reducirá la complejidad de todo el problema, consiguiendo de esta manera una solución modular efectiva. Capacidad de empleo de componentes modulares. Si un método de diseño permite ensamblar los componentes de diseño (reusables) existentes en un sistema nuevo, producirá una solución modular que no inventa nada ya inventado. Capacidad de comprensión modular. Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos) será más fácil de construir y de cambiar. Continuidad modular. Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios. Protección modular. Si dentro de un módulo se produce una condición absurda y sus efectos se limitan a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los errores. Es importante destacar que un sistema se puede diseñar modularmente,incluso aunque su implementación deba ser “monolítica”. Existen situaciones (porejemplo, software en tiempo real, software empotrado) en donde no es admisible 20
  21. 21. que los subprogramas introduzcan sobrecargas de memoria y de velocidad pormínimos que sean (por ejemplo, subrutinas, procedimientos). En tales situacionesel software podrá y deberá diseñarse con modularidad como filosofíapredominante. El código se puede desarrollar “en línea”. Aunque el código fuentedel programa puede no tener un aspecto modular a primera vista, se ha mantenidola filosofía y el programa proporcionará los beneficios de un sistema modular.3.1.4 DESCOMPOSICIÓN EN PROCESOS Las fases que generalmente caracterizan al proceso del software son:definición desarrollo y soporte, se aplican a todo software. El problema esseleccionar el modelo de proceso apropiado para la ingeniería del software quedebe aplicar el equipo. El gestor del proyecto debe decidir que modelo de procesoes el más adecuado para: 1. Los clientes que han solicitado el producto y la gente que realizara el trabajo. 2. Las características del producto. 3. El entorno del proyecto en el que trabaja el equipo de software. Cuando se selecciona un modelo de proceso, el equipo define entonces unplan de proyecto preliminar basado en conjunto de actividades estructurales. Unavez establecido el plan preliminar, empieza la descomposición del proceso. Esdecir, se debe crear un plan completo reflejando las tareas requeridas a laspersonas para cubrir las actividades estructurales. Un proyecto cuando es relativamente pequeño se debe realizar con un enfoquesecuencial lineal. Si hay limites de tiempo muy severos y le problema se puedecompartir, el modelo apropiado es el DRA. Si se tiene el tiempo limitado lo masapropiado es tomar una estrategia incremental. Una vez que hemos elegido el modelo de proceso, la Estructura Común deProcesos (ECP) se adapta a él. En todos los casos, la ECP (comunicación con el 21
  22. 22. cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega yevaluación del cliente) puede adaptarse al paradigma. Funcionara para modeloslineales, para modelos iterativos e incrementales, para modelos de evolución eincluso para modelos concurrentes o de ensamblaje de componentes. El ECP esinvariable y sirve como base para todo el trabajo de software realizado por unaorganización. Un proyecto simple requiere las siguientes tareas para la actividad decomunicación con el cliente: 1. Desarrollar una lista de aspectos que se deben aclarar 2. Reunirse con el cliente para aclarar los aspectos de la lista 3. Desarrollar en conjunto una exposición del ámbito del proyecto 4. Revisar el alcance del proyecto con todos los implicados 5. Modificar el alcance del proyecto cuando se requiera. Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 48horas. Representan una descomposición del problema apropiado para proyectospequeños relativamente sencillos.Si se considera un proyecto más complejo que tenga un ámbito más amplio y unmayor impacto comercial. Un proyecto como ése podría requerir las siguientestareas para la actividad de comunicación con el cliente: 1. Revisar la petición del cliente 2. Planificar y programar una reunión formal con el cliente 3. Realizar una investigación para definir soluciones propuestas y enfoques existentes. 4. Prepara un plan de trabajo y una agenda para la reunión formal 5. Realizar la reunión 6. Desarrollar conjuntamente mini-especificaciones que reflejen la información, función y características de comportamiento del software 22
  23. 23. 7. Revisar todas las mini-especificaciones para comprobar su corrección , su consistencia la ausencia de ambigüedades 8. Ensamblar las mini-especificaciones de un documento de alcance del proyecto 9. revisar ese documento general con todo lo que pueda afectar 10. modificar el documento de alcance del proyecto cuando se requieraAmbos proyectos realizan la actividad estructural que denominamos comunicacióncon el cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas deingeniería del software que el segundo.3.2 EL ENFOQUE ORIENTADO A OBJETOS El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO)constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basanen los conceptos de la programación orientada a objetos, que han sido codificadosen UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado demodelación en el cual los objetos generados no solo incluyen código referente alos datos sino también instrucciones acerca de las operaciones que se realizaransobre los datos.EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo ymodelado de software que permite construir más fácilmente sistemas complejos apartir de componentes individuales.Objetos + Mensajes = ProgramaEl proceso Orientado a Objetos se mueve a través de una espiral evolutiva quecomienza con la comunicación con el usuario. Es en esta parte donde se define eldominio del problema y se identifican las clases básicas del problema. Laplanificación y el análisis de riesgos establecen una base para el plan de proyecto 23
  24. 24. El trabajo técnico asociado con la ingeniería del software OO sigue las siguientestareas: 1. Identificar clases candidatas 2. Buscar clases en biblioteca 3. Extraer nuevas clases si existen 4. Desarrollar las clases sino existen 5. Añadir las nuevas clases a la biblioteca 6. Construir n-esima iteración del sistemaLa ingeniería de software hace hincapié en la reutilización. Por lo tanto las clasesse buscan en una biblioteca (de clases existentes) antes de construirseLas Características del Enfoque Orientado a Objetos son: a) Objeto: Los datos están cuantificados en entidades discretas y distinguibles llamadas objetos. b) Clase: Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase. c) Atributo: Describen la clase o el objeto de alguna manera d) Mensajes: Medio por el cual interactúan los objetos e) Polimorfismo: Una misma operación puede comportarse de modos distintos en distintas clases. f) Herencia: Compartir atributos y operaciones entre clases tomando como base una relación jerárquica.ObjetoUn objeto es una unidad de código compuesto de variables y métodosrelacionados. Encapsula datos, operaciones, otros objetos, constantes y otrainformación relacionada. Pueden ser: Entidades externas, ocurrencias o eventos,papeles o roles, unidades organizacionales, lugares, estructuras. 24
  25. 25. Los Objetos tienen características y comportamientos. Mantiene suscaracterísticas en una o más "variables", e implementa su comportamiento con"métodos". Un método es una función o subrutina asociada a un objeto. Cuando alas características del objeto le ponemos valores decimos que el objeto tieneestados. Las variables almacenan los estados de un objeto en un determinadomomento.Para ser considerado como valido un objeto debe de tener las siguientescaracterísticas:  Información retenida  Servicio necesario  Atributos múltiples  Atributos comunes  Operaciones comunes  Requisitos esencialesClaseLa clase es un modelo o prototipo que define las variables y métodos comunes atodos los objetos de cierta clase.Es una descripción generalizada que describe una colección de objetos concaracterísticas similares.Todos los objetos que existen dentro de una heredan sus atributos y lasoperaciones disponibles para la manipulación de los atributos.Una superclase es una colección de clases y una instancia de una clase.Una instancia de una clase es otra forma de llamar a un objeto. En realidad noexiste diferencia entre un objeto y una instancia. Sólo que el objeto es un términomás general, pero los objetos y las instancias son ambas representación de unaclase. 25
  26. 26. AtributoLos Atributos están asociados a clases y objetos, ellos describen la clase y elobjeto de alguna manera. Un atributo puede tomar un valor definido por undominio enumerado. En la mayoría de los casos, un dominio es simplemente unconjunto de valores específicos. En situaciones más complejas el dominio puedeser un conjunto de clases.MensajesLos mensajes son el medio a través del cual los objetos intercambian información.Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor.El comportamiento se realiza cuando se ejecuta una operación.El medio empleado para que un objeto interactúe con otro son los mensajes. Losmensajes son invocaciones a los métodos de los objetos.EncapsulamientoEl encapsulamiento significa que toda la información de un objeto se encuentraempaquetada bajo un nombre y puede reutilizarse como una especificación ocomponente de un programa.Consiste en unir en la clase las características y comportamientos, esto es, lasvariables y métodos. Es tener todo esto es una sola entidad. En los lenguajesestructurados esto era imposible. Es evidente que el encapsulamiento se logragracias a la abstracción y el ocultamiento.La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, yaque tendremos a las clases como cajas negras donde sólo se conoce elcomportamiento pero no los detalles internos, y esto es conveniente porque nosinteresará será conocer qué hace la clase pero no será necesario saber cómo lohace. 26
  27. 27. EL Ocultamiento es la capacidad de ocultar los detalles internos delcomportamiento de una clase y exponer sólo los detalles que sean necesariospara el resto del sistema.El ocultamiento permite: restringir y controlar el uso de la Clase. Restringir porquehabrá cierto comportamiento privado de la Clase que no podrá ser accedido porotras Clases. Y controlar porque daremos ciertos mecanismos para modificar elestado de nuestra Clase y es en estos mecanismos dónde se validarán quealgunas condiciones se cumplan.HerenciaLa herencia consiste en que una clase puede heredar sus variables y métodos avarias subclases (la clase que hereda es llamada superclase o clase padre). Estosignifica que una subclase, aparte de los atributos y métodos propios, tieneincorporados los atributos y métodos heredados de la superclase. La herenciareduce el trabajo de la programación usando fácilmente objetos comunes. Solo esnecesario declarar que la clase A hereda de la clase B y después proporcionarcualquier detalle adicional. Los atributos y comportamientos de la clase B sonparte de la clase A y no requiere ninguna programación adicional.PolimorfismoEl polimorfismo permite que un número de operaciones diferentes tengan elmismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada unomás independiente.3.2.1 ANÁLISIS. El análisis utiliza una combinación de texto y de diagramas, pararepresentar los requisitos de datos, funciones y comportamientos, que esrelativamente fácil de entender y mas importante aun, sencillo para revisar sucorrección, completitud y consistencia. El ingeniero del software o analista es elresponsable de construir el modelo utilizando los requisitos definidos por el cliente.Lo cual es importante para validar los requerimientos del software desde 27
  28. 28. diferentes puntos de vista. El análisis representa los requisitos de tresdimensiones, por esa razón, se incrementa la probabilidad de encontrar errores,descubrir inconsistencias y detectar omisiones. El objetivo del análisis orientado a objetos es desarrollar una serie demodelos que describan el software de computadora al trabajar para satisfacer unconjunto de requisitos definidos por el cliente. El AOO, como los métodos deanálisis convencional, forma un modelo de análisis multiparte para satisfacer esteobjetivo. El modelo de análisis ilustra información, funcionamiento ycomportamiento dentro del contexto de los elementos del modelo de objetos. El análisis orientado a objetos (AOO) ha sido muy exitoso en derribarproblemas que se resisten al análisis estructurado, como las interfaces de usuario.Los partidarios del AOO argumentan que los objetos dentro de un sistema sonmás fundamentales (importantes, necesarios) para su naturaleza que lasfunciones que proporciona. Las especificaciones basadas en los objetos seránmás adaptables que las especificaciones basadas en las funciones.La popularidad de las tecnologías de objetos ha generado docenas de métodos deA00 desde finales de los 80 y durante los 90. Cada uno de ellos introduce unproceso para el análisis de un producto o sistema, un conjunto de modelos queevoluciona fuera del proceso, y una notación que posibilita al ingeniero delsoftware crear cada modelo de una manera consistente. Entre los másampliamente utilizados se encuentran: El método de Booch. Abarca un microproceso de desarrollo» y un «macroproceso de desarrollo». El nivel micro define un conjunto de tareas de análisis que se reaplican en cada etapa en el macro proceso. Por esto se mantienen un enfoque evolutivo. El microproceso de desarrollo identifica clases y objetos y la semántica de dichas clases y objetos, define las relaciones entre 28
  29. 29. clases y objetos y realiza una serie de refinamientos para elaborar el modelo del análisis. El método de Rumbaugh. Rumbaugh y sus colegas desarrollaron la Técnica de Modelado de Objetos (OMT) para el análisis, diseño del sistema y diseño a nivel de objetos. La actividad de análisis crea tres modelos: el modelo de objetos (una representación de objetos, clases, jerarquías y relaciones), el modelo dinámico (una representación del comportamiento del sistema y los objetos) y el modelo funcional (una representación a alto nivel del flujo de información a través del sistema similar al DFD). El método de Jacobson. También llamado OOSE (en español Ingeniería del Software Orientada a Objetos),el método de Jacobson es una versión simplificada de Objectory, un método patentado, también desarrollado por Jacobson. Este método se diferencia de los otros por la importancia que da al caso de uso una descripción o escenario que describe cómo el usuario interactúa con el producto o sistema. El método de Coad y Yourdon. El método de Coad y Yourdon se considera, con frecuencia, como uno de los métodos del A00 más sencillos de aprender.La notación del modelado es relativamente simple y las reglas para desarrollar elmodelo de análisis son evidentes. El método de Wirfs-Brock. El método de Wirfs-Brock propone un proceso continuo que comienza con la valoración de una especificación del cliente y termina con el diseño. A continuación se esbozan brevemente las tareas relacionadas con el análisis de Wirfs-Brock: o Evaluar la especificación del cliente. o Usar un análisis gramatical para extraer clases candidatas de la especificación. o Agrupar las clases en un intento de determinar superclases. o Definir responsabilidades para cada clase. o Asignar responsabilidades a cada clase. 29
  30. 30. o Identificar relaciones entre clases. o Definir colaboraciones entre clases basándose en sus responsabilidades. o Construir representaciones jerárquicas de clases para mostrar relaciones de herencia. o Construir un gafo de colaboraciones para el sistema.Aunque la terminología y etapas del proceso para cada uno de estos métodos deAOO difieren, los procesos generales de AOO son en realidad muy similares. Pararealizar un análisis orientado a objetos, un ingeniero del software debería ejecutarlas siguientes etapas genéricas:1. Obtener los requisitos del cliente para el sistema.2. Identificar escenarios o casos de uso.3. Seleccionar clases y objetos usando los requisitos básicos como guías.4. Identificar atributos y operaciones para cada objeto del sistema.5. Definir estructuras y jerarquías que organicen las clases.6. Construir un modelo objeto-relación.7. Construir un modelo objeto-comportamiento.8. Revisar el modelo de análisis OO con relación a los casos de uso/escenarios3.2.2 DISEÑO. El diseño orientado a objetos transforma el modelo de análisis creadousando análisis orientado a objetos, en un modelo de diseño que sirve comoanteproyecto para la construcción de software. El trabajo de diseñador de softwarepuede ser intimidante.Gamma y sus colegas proveen un panorama razonablemente exacto del DOOcuando declaran que: 30
  31. 31. El diseño de software orientado a objetos es difícil, y el diseño de softwarereusable orientado a objetos es aun más difícil. Se deben identificar los objetospertinentes, clasificarlos dentro de las clases en la granularidad correcta, definirinterfaces de clases y jerarquías de herencia y establecer relaciones clave entreellos. El diseño debe ser específico al problema que se tiene entre manos, perosuficientemente general para adaptarse a problemas y requerimientos futuros.Además se deberá evitar el rediseño, o por lo menos minimizarlo.El DOO debe describir la organización específica de los datos de los atributos y eldetalle procedural de cada operación. Estos representan datos y piezasalgorítmicas de un sistema OO y son los que contribuyen a la modularidad global.¿Qué es? El diseño de software Orientado a objetos requiere la definición de unaarquitectura de software multicapa, la especificación de subsistemas que realizanfunciones necesarias y proveen soporte de infraestructura, una descripción deobjetos (clases), que son los bloques de construcción del sistema, y unadescripción de los mecanismos de comunicación, que permiten que los datosBuyan entre las capas, subsistemas y objetos. El Diseño Orientado a Objetos(DOO), cumple todos estos requisitos.¿Quién lo hace? El DOO lo realiza un ingeniero de software.¿Por qué es importante? Un sistema orientado a objetos utiliza las definicionesde las clases derivadas del modelo de análisis. Algunas de estas definicionestendrán que ser construidas desde el principio, pero muchas otras pueden serreutilizadas, si se reconocen los patrones de diseño apropiados. El DOO estableceanteproyecto de diseño, que permite al ingeniero de software definir la arquitecturaOO. En forma que maximice la reutilización; de esta manera, se mejora lavelocidad del desarrollo y la calidad del producto terminado.¿Cuáles son los pasos? El DOO se divide en dos grandes actividades: diseñodel sistema y diseño de objetos. 31
  32. 32. Diseño de sistema: crea la arquitectura del producto definiendo una serie decapas, que cumplen funciones específicas del sistema e identifica las clases queson encapsuladas por los subsistemas que residen en cada capa. Además, eldiseño de sistemas incorpora la especificación de tres componentes: la interfazusuario, la gestión de datos y los mecanismos de administración de tareas.El diseño de objetos: se centra en los detalles internos de cada clase, definiciónatributos operaciones y detalles de los mensajes.¿Cuál es el producto obtenido? El modelo de DOO avara arquitectura desoftware, descripción de la interfaz de usuario, componentes de gestión de datosmecanismos de administración de tareas y descripciones detalladas de cada unade las clases usadas en el sistema.¿Cómo puedo estar seguro que lo he hecho correctamente? En cada etapa,los elementos del modelo de diseño orientado a objetos son revisados porclaridad, corrección, integridad y consistencia con los requisitos del cliente y entreellos.El concepto de una pirámide de diseño para el software convencional. Cuatrocapas de diseño: datos, arquitectura, interfaz y nivel de componentes fuerondefinidas y discutidas.Para sistemas orientados a objetos, podemos también definir una pirámide, perolas capas son un poco diferentes.Refiriéndose a la Figura 3.3, las cuatro capas de la pirámide de diseño OO son: La capa subsistema. Contiene una representación de cada uno de los subsistemas, para permitir al software conseguir sus requisitos definidos por el cliente e implementar la infraestructura que soporte los requerimientos del cliente. 32
  33. 33.  La capa de clases y objetos. Contiene la jerarquía de clases, que permiten al sistema ser creado usando generalizaciones y cada vez especializaciones más acertadas. Esta capa también contiene representaciones. La capa de mensajes. Contiene detalles de diseño, que permite a cada objeto comunicarse con sus colaboradores. Esta capa establece interfaces externas e internas para el sistema. La capa de responsabilidades. Contiene estructuras de datos y diseños algorítmicos, para todos los atributos y operaciones de cada objeto. La pirámide de diseño se centra exclusivamente en el diseño de unproducto o sistema específico. Observe, sin embargo, que existe otra capa dediseño, y que esta capa forma los cimientos sobre los que la pirámide se sostiene.La capa fundamental se centra en el diseño de los objetos del dominio (llamadospatrones de diseño). Los objetos del dominio juegan un papel clave, en laconstrucción de la infraestructura del sistema OO aportando soporte para lasactividades de interfaz hombre/máquina, administración (gestión) de tareas ygestión (administración) de datos.Los objetos del dominio se pueden usar, además, para desarrollar el diseño de laaplicación en sí misma. 33
  34. 34. UNIDAD IVMODELOS DE PROCESO DE SOFTWARE:Introducción:El proceso es el conocimiento incorporado, y puesto que el conocimiento estainicialmente disperso, el desarrollo de software implícito, latente e incompleto engran medida es un proceso social de aprendizaje. Es un dialogo en el que sereúne el conocimiento y se incluye en el software para convertirse en software.Proporciona una iteración entre los usuarios y los diseñadores, entre los usuariosy las herramientas de desarrollo, y entre los diseñadores y las herramientas dedesarrollo (tecnología). Es un proceso interactivo donde la herramienta dedesarrollo se usa como medio de comunicación, con cada iteración del dialogo seobtiene mayor conocimiento. Desde un punto de vista técnico se puede decir que el proceso de softwarees un marco de trabajo de las tareas que se requieren para construir software dealta calidad.Aun más importante es que la Ingeniería del Software la realizan personascreativas, con conocimiento, que deberían trabajar dentro de un proceso delsoftware definido y avanzado que es apropiado para los productos que construyeny para las demandas de su mercado. Los estándares establecen los diferentes procesos implicados a la hora dedesarrollar y mantener un Sistema desde que surge la idea o necesidad dedesarrollar las aplicaciones hasta que éstas se retiran de explotación. Sinembargo, ninguno impone un modelo de procesos concreto (modelo de ciclo devida) ni cómo realizar las diferentes actividades incluidas en cada proceso, por loque cada empresa deberá utilizar los métodos, técnicas y herramientas queconsidere oportuno. 34
  35. 35. Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo deprocesos del Software es una simplificación o abstracción de un proceso real.Podemos definir un modelo de procesos del Software como una representaciónabstracta de alto nivel de un proceso Software.Cada modelo es una descripción de un proceso Software que se presenta desdeuna perspectiva particular. Alternativamente, a veces se usan los términos Ciclode Vida y Modelo de Ciclo de Vida.Cada modelo describe una sucesión de fases y un encadenamiento entre ellas.Según las fases y el modo en que se produzca este encadenamiento, tenemosdiferentes modelos de proceso. Un modelo es más adecuado que otro paradesarrollar un proyecto dependiendo de un conjunto de características de éste.Existe una gran variedad de modelos diferentes entre los que tenemos los que sedescriben a continuación. 4.1 MODELO DE CASCADA Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970,Pressman lo presenta como ciclo de vida clásico). Se denomina modelo encascada porque su característica principal es que no se comienza con un pasohasta que no se ha terminado el anterior. Establece que el software debe serconstruido, rigurosamente, a través de una transformación sucesiva dedocumentos, siguiendo una estrategia lineal de desarrollo. Primero saber qué sequiere y después, cuando se conozca todo lo que se quiere, empezar aconstruirlo.También conocido como modelo lineal secuencial sugiere un enfoquesistemático, secuencial para el desarrollo del software que comienza en un nivelde sistemas y progresa con el análisis, diseño, codificación, pruebas ymantenimiento. 35
  36. 36. El primer paso es conseguir un documento con la especificación completa,exacta, no ambigua de los requisitos del sistema software que debe serdesarrollado. Este documento inicial es transformado en un documento deanálisis, supuestamente alejado de la máquina. Después, a partir del análisis, seobtiene otro documento, el diseño. Y por último, del diseño se obtiene eldocumento final: el código. Para asegurar que no se introducen equivocaciones altransformar un documento (modelo) en otro, se hacen pruebas, al terminar cadauno. Las pruebas son planificadas desde el principio y se documentan como sevayan realizando. Antes de la entrega del sistema software, se valida quesatisface los requisitos definidos en el documento inicial.Está basado en el ciclo convencional de una ingeniería, tiene las siguientesactividades que se muestran en la figura 4.1 del modelo de cascada: Ingeniería y Análisis del Sistema Análisis de los Requisitos Diseño Codificación Prueba Mantenimiento Figura 4.1 Modelo de Cascada Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas Venezuela [Consulta: Abril de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc>Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vidadel Software, de forma tal que el inicio de cada etapa debe esperar a lafinalización de la inmediatamente anterior. La palabra cascada sugiere, mediante 36
  37. 37. la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir uncambio en las fases más avanzadas de un proyecto.Modelo en Cascada: El más conocido, está basado en el ciclo convencional deuna ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades: - Ingeniería y Análisis del Sistema - Análisis de los Requisitos - Diseño - Codificación - Prueba - Mantenimiento 4.1.1 ActividadesIngeniería y Análisis del Sistema El trabajo comienza estableciendo los requisitos de todos los elementos delsistema y luego asignando algún subconjunto de estos requisitos al software.Análisis de los requisitos del softwareAnálisis: Se analizan las necesidades de los usuarios finales del software paradeterminar qué objetivos debe cubrir. De esta fase surge una memoria llamadaSRD (Documento de Especificación de Requisitos), que contiene la especificacióncompleta de lo que debe hacer el sistema sin entrar en detalles internos (debecomprender el ámbito de la información del software, así como la función, elrendimiento y las interfaces requeridas). 37
  38. 38. Diseño Se enfoca en cuatro atributos distintos del programa: la estructura de losdatos, la arquitectura del software, el detalle procedimental y la caracterización dela interfaz. El proceso de diseño traduce los requisitos en una representación delsoftware con la calidad requerida antes de que comience la codificación. Comoresultado surge el SDD (Documento de Diseño del Software), que contiene ladescripción de la estructura global del sistema y la especificación de lo que debehacer cada una de sus partes, así como la manera en que se combinan unas conotras.CodificaciónEs la fase de programación. Aquí se desarrolla el código fuente, el diseño debetraducirse en una forma legible para la maquina, haciendo uso de prototipos asícomo pruebas y ensayos para corregir errores. El paso de codificación realiza estatarea. Si el diseño se realiza de una manera detallada la codificación puederealizarse mecánicamente.PruebaSe centra en la lógica interna del software, y en las funciones externas, realizandopruebas que aseguren que la entrada definida produce los resultados querealmente se requieren. Se comprueba que funciona correctamente antes de serpuesto en explotación.MantenimientoEl software sufrirá cambios después de que se entrega al cliente. Los cambiosocurrirán cuando se hayan encontrado errores, esto en lugar de que el softwaredeba adaptarse a cambios del entorno externo (sistema operativo o dispositivosperiféricos), o debido a que el cliente requiera ampliaciones funcionales o delrendimiento. 38
  39. 39. Desventajas  Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.  Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.  El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.  Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocidaEste modelo, que se lleva a cabo de forma descendente, exige que para pasar a lasiguiente fase hay que concluir correctamente la anterior, de manera que losposibles errores sean fácilmente detectables. Así, la salida de una fase es laentrada de la siguiente.La Ventajas de este método radica en su sencillez ya que sigue los pasosintuitivos necesarios a la hora de desarrollar el software.Se tiene todo bien organizado y no se mezclan las fases.Es perfecto para proyectos que son rígidos.Ideal para proyectos donde se especifiquen muy bien los requerimientos.Ideal para proyectos en que se conozca muy bien la herramienta a utilizar.Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora dedesarrollar el Software. 39
  40. 40. 4.2 MODELO DE ESPIRAL Propuesto originalmente por Boehm en 1988, es un modelo de proceso desoftware evolutivo ha sido desarrollado para cubrir las mejores característicastanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo almismo tiempo un nuevo elemento: el análisis de riesgo. Proporciona el potencialpara el desarrollo rápido de versiones incrementales del software. En este modeloel software se desarrolla en una serie de versiones incrementales. Durante lasprimeras iteraciones, la versión incremental podría ser un modelo en papel o unprototipo. En las últimas iteraciones, se producen versiones cada vez mascompletas del sistema diseñado.El modelo representado mediante la espiral de la figura 4.2 define cuatroactividades principales, también llamadas regiones de tareas o sectores: 1. Planificación. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente. 2. Análisis de riesgo. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. 3. Ingeniería. En este sector se desarrolla y se valida. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema. 4. Evaluación del cliente. El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir". 40
  41. 41. Con cada iteración alrededor de la espiral (comenzando en el centro ysiguiendo hacia el exterior), se construyen sucesivas versiones del software, cadavez más completas y, al final, el propio sistema operacional. Un ciclo en espiral inicia con la elaboración de objetivos, como elrendimiento y la funcionalidad. Después se enumeran formas alternativas dealcanzar estos objetivos y las restricciones impuestas en cada una de ellas. Cadaalternativa se evalúa contra cada objetivo y se identifican las fuentes de riesgo delproyecto. Lo siguiente es resolver los riesgos mediante actividades de recopilaciónde información como la de detallar más el análisis, la construcción de prototipos yla simulación. Ya que se evaluaron los riesgos, se lleva a cabo cierto desarrollo,seguido de una actividad de planificación para la siguiente fase. El paradigma del modelo en espiral para la Ingeniería de Software esactualmente el enfoque más realista para el desarrollo de software y de sistemas agran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al clienteentender y reaccionar a los riesgos en cada nivel. Utiliza la creación de prototiposcomo un mecanismo de reducción de riesgo, pero, lo que es más importantepermite a quien lo desarrolla aplicar el enfoque de creación de prototipos encualquier etapa de la evolución de prototipos. 41
  42. 42. 4.3 MODELO INCREMENTAL El modelo incremental aplica secuencias lineales de forma escalonadamientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal depasos de desarrollo. Cada secuencia lineal produce un incremento del software.El modelo incremental entrega el software en partes pequeñas, pero utilizables,llamadas “incrementos”. En general, cada incremento se construye sobre aquelque ya ha sido entregado.Al igual que los otros métodos de modelado, el Modelo Incremental es denaturaleza interactiva pero se diferencia de aquellos en que al final de cadaincremento se entrega un producto completamente operacional. 42
  43. 43. El Modelo Incremental es particularmente útil cuando no se cuenta con unadotación de personal suficiente. Los primeros pasos los pueden realizar un gruporeducido de personas y en cada incremento se añadir personal, de ser necesario.Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.El Modelo Incremental se puede ver aquí: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra más. - Difícil de evaluar el coste total. - Difícil de aplicar a los Sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo.  PipelineLa arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujode datos en un proceso comprendido por varias fases secuenciales, siendo laentrada de cada una la salida de la anterior.Esta arquitectura es muy común en el desarrollo de programas para el intérpretede comandos, ya que se pueden concatenar comandos fácilmente con tuberías(pipe). Es una arquitectura muy natural en el paradigma de programaciónfuncional, ya que equivale a la composición de funciones matemáticas.Interprete de comandos.Parte fundamental de un Sistema Operativo que ordena la ejecución de mandatosobtenidos del usuario por medio de una interfaz alfanumérica. 43
  44. 44. Características.  Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.  El usuario se involucre más.  Difícil de evaluar el costo total.  Difícil de aplicar a los Sistemas transaccionales que tienden a ser integrados y a operar como un todo.  Requiere gestores experimentados.  Los errores en los requisitos se detectan tarde.  El resultado puede ser muy positivo.Ventajas:  Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.  También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.  El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.  Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.  Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.  Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.Desventajas:  El modelo Incremental no es recomendable para casos de Sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos. 44
  45. 45.  Requiere de mucha planeación, tanto administrativa como técnica.  Requiere de metas claras para conocer el estado del proyecto.Conclusión:Un modelo incremental lleva a pensar en un desarrollo modular, con entregasparciales del producto de Software denominados “incrementos” del Sistema, queson escogidos en base a prioridades predefinidas de algún modo.El modelo permite una implementación con refinamientos sucesivos (ampliacióny/o mejora).Con cada incremento se agrega nueva funcionalidad o se cubren nuevosrequisitos o bien se mejora la versión previamente implementada del producto deSoftware.4.4 PROCESO DE DESARROLLO UNIFICADO El Proceso Unificado de Desarrollo de Software o simplemente ProcesoUnificado es un marco de desarrollo de Software iterativo e incremental. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajoextensible que puede ser adaptado a organizaciones o proyectos específicos. Dela misma forma, el RUP también es un marco de trabajo extensible, por lo quemuchas veces resulta imposible decir si un refinamiento particular del proceso hasido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombressuelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genérico queincluye aquellos elementos que son comunes a la mayoría de los refinamientosexistentes. 45
  46. 46. Características:- Iterativo e IncrementalEl Proceso Unificado es un marco de desarrollo iterativo e incremental compuestode cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cadauna de estas fases es a su vez dividida en una serie de iteraciones (la de iniciosólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecencomo resultado un incremento del producto desarrollado que añade o mejora lasfuncionalidades del Sistema en desarrollo.Cada una de estas iteraciones se divide a su vez en una serie de disciplinas querecuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis derequisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelenincluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cadauna de ellas varía a lo largo del proyecto.- Dirigido por los casos de usoEn el Proceso Unificado los casos de uso se utilizan para capturar los requisitosfuncionales y para definir los contenidos de las iteraciones. La idea es que cadaiteración tome un conjunto de casos de uso o escenarios y desarrolle todo elcamino a través de las distintas disciplinas: diseño, implementación, prueba, etc. elproceso dirigido por casos de uso es el RUP- Centrado en la arquitecturaEl Proceso Unificado asume que no existe un modelo único que cubra todos losaspectos del Sistema. Por dicho motivo existen múltiples modelos y vistas quedefinen la arquitectura de Software de un Sistema. La analogía con la construcciónes clara, cuando construyes un edificio existen diversos planos que incluyen losdistintos servicios del mismo: electricidad, fontanería, etc. 46
  47. 47. - Enfocado en los riesgosEl Proceso Unificado requiere que el equipo del proyecto se centre en identificarlos riesgos críticos en una etapa temprana del ciclo de vida. Los resultados decada iteración, en especial los de la fase de Elaboración, deben ser seleccionadosen un orden que asegure que los riesgos principales son considerados primero.4.5 PROCESO SOFTWARE PERSONAL Es un modelo complejo con mucha terminología propia, pensadoprincipalmente para el desarrollo de grandes proyectos. Es un proceso que puedeadaptarse y extenderse en función de las necesidades de cada empresa. Es elresultado de esfuerzo de las tres últimas décadas en desarrollo de software y de laexperiencia de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh. El PSP se caracteriza porque es de uso personal y se aplica a programaspequeños de menos de 10.000 líneas de código. Se centra en la administracióndel tiempo y en la administración de la calidad a través de la eliminación tempranade defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo,Administración de configuraciones y Administración de requerimientos.El PSP se orienta el conjunto de áreas clave del proceso que debe manejar undesarrollador cuando trabaja de forma individual. Los siguientes son los niveles ylas capas que se manejan en cada uno:Nivel 1 - Inicial:- Seguimiento y control de proyectos- Planeación de los proyectosNivel 2 - Repetible: 47
  48. 48. - Revisión entre colegas.- Ingeniería del producto de Software.- Manejo integrado del Software.- Definición del proceso de Software.- Foco del proceso de Software.Nivel 3 - Definido:- Control de calidad.- Administración cuantitativa del proyecto.Nivel 4 - Controlado:- Administración de los cambios del proceso.- Administración del cambio tecnológico.- Prevención de defectos.- El PSP tiene varias fases:PSP0: Proceso Base.PSP0.1: Complementos al proceso base.PSP1 y PSP1.1: Planeación personal.PSP2 y PSP2.1: Control de calidad personal.PSP3: Programas más grandes. 48
  49. 49. El Proceso Personal Software, conocido por sus siglas como PSP es unaalternativa dirigida a los ingenieros de Sistemas, que les permite mejorar la formaen la que construyen Software. Considerando aspectos como la planeación,calidad, estimación de costos y productividad, PSP es una metodología que vale lapena revisar cuando el ingeniero de Software está interesado en aumentar lacalidad de los productos de Software que desarrolla dentro de un contexto detrabajo individual. Atendiendo a la premisa de que existe una fuerte relación entre lashabilidades de los ingenieros de Software y la calidad de los productos quedesarrollan, las actividades establecidas en PSP están orientadas al conocimiento,administración y mejora de sus habilidades al construir programas. En PSP todas las tareas y actividades que el ingeniero de Software deberealizar durante el proceso de desarrollo de un producto de Software, estánpuntualmente definidas en un conjunto de documentos conocidos como scripts.Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis enque deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxitode la mejora que se busca. Gran parte de las tareas y actividades definidas en losscripts generará en su realización un conjunto de datos, fundamentalmente decarácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y elanálisis de la información estadística generada en cada uno de éstos, permitirán alIngeniero de Software identificar, tanto sus fortalezas como sus debilidades, ycrecer a través de un proceso de autoaprendizaje y auto-mejora. Los scripts se organizan en cuatro niveles, identificados del 0 al 3,atendiéndose en cada nivel un conjunto de aspectos a mejorar del Proceso deDesarrollo de Software. Al primer nivel se le conoce como 0 o de mediciónpersonal, al segundo como nivel 1 o de planeación personal, al tercero, como nivel2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada uno deestos niveles, con excepción del 3, tiene una versión que los extiende, 49
  50. 50. introduciendo tareas y actividades para un mejor manejo de los aspectos deinterés en nivel, o bien para incluir nuevos aspectos.BIBLIOGRAFÍA [1] Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª Edición. [2] Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª ediciónREFERENCIAS WEB [3] Nelson Medinilla Martínez, Facultad de Informática, Universidad Politécnica de Madrid, “Análisis y selección de estrategias de desarrollo de software” [En línea], Madrid España [Consulta: Mayo de 2006], <http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/ estrategias.pdf> [4] Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas Venezuela [Consulta: Abril de 2006],<carolina.terna.net/ingsw2/Datos/Cascada- ModeloV.doc> [5] Tesis doctorales en Zarza, “Ingeniería de Software” [En línea], España [Consulta: Mayo de 2006], <http://www.tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-0716102- 102210//05Capitulo05.pdf> [6] Mundo Geek, “Ciclos de vida del software” [En línea], [Consulta: Mayo de 2006], <http://mundogeek.net/archivos/2004/05/20> 50

×