CENTRO DE ESTUDIOS TECNOLÓGICO
INDUSTRIAL Y DE SERVICIOS
PROFESORA: MARGARITA ROMERO
ALVARADO
ALUMNA: KAREN GUADALUPE RIVERA
MARTÍNEZ
INVESTIGACIÓN: DIAGRAMAS DE
DISEÑO Y MODELOS DE CICLO DE
VIDA, SU APLICACIÓN Y
ELABORACIÓN
SEMESTRE: 3º

GRUPO: “C”

TURNO: MATUTINO
ESPECIALIDAD: PROGRAMACION
DIAGRAMA DE DISEÑO
Un Diagrama es una representación gráfica de una colección de elementos de modelado, a
menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos
del modelo). Un diagrama no es un elemento semántico, un diagrama muestra
representaciones de elementos semánticos del modelo, pero su significado no se ve
afectado por la forma en que son representados. Un diagrama está contenido dentro de un
paquete.
El diseño se mira desde tres puntos de vista:
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema
modelado:
* Diagrama de clases
* Diagrama de componentes
* Diagrama de objetos
* Diagrama de despliegue
* Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema
modelado:
* Diagrama de actividades
* Diagrama de casos de uso
* Diagrama de estados
Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que
enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
* Diagrama de secuencia
* Diagrama de colaboración

CICLOS DE VIDA
El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la
concepción de una idea hasta la entrega y el retiro del sistema.
Representa todas las actividades y artefactos (productos intermedios) necesarios para
desarrollar una aplicación.

Actividades de un Ciclo de Vida
Implícita o Explícitamente todos los modelos de ciclo de vida cuentan por lo menos con las
siguientes actividades.
MODELAMIENTO DEL CICLO DE VIDA
Responsable: Gerente del proyecto
Personalizar las actividades de IEEE1074 a los requerimientos del proyecto y de la
empresa
TPOS DE MODELOS
Modelo Cascada
Este es el más básico de todos los modelos. su
visión dice que el desarrollo de software esa
través de una secuencia simple de fases. Cada
fase tiene un conjunto de metas bien definidas.
Utiliza punto de control para pasar a la siguiente
fase: Análisis, Diseño, Codificación, Pruebas,
Implementación, Mantenimiento. Se tarda mucho
tiempo en pasar todo el ciclo. El fracaso del
software es la comunicación con el usuario final.
Se utiliza en proyectos con requerimientos bien
definidos. Las flechas muestran el flujo de
información
entre
las
fases.
este modelo se enfrasca en los en: Planear un
proyecto antes de embarcarse en él. Definir el comportamiento externo antes de diseñar su
arquitectura interna. Documentar los resultados de cada actividad. Diseñar un sistema antes
de codificarlo.
Modelo De Desarrollo Evolutivo
El modelo de desarrollo evolutivo construye versiones sucesivas de un producto, el modelo
evolutivo asume que los requerimientos no son completamente conocidos al inicio del
proyecto.
Basada en esta retroalimentación, la especificación de requerimientos es actualizada. El
desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación
de documentos, programas, datos de test, etc. desarrollados para distintas versiones del
software.
Modelo de Prototipado de Requerimientos
El prototipado de requerimientos es la creación de una implementación parcial de un
sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un
prototipo es construido de una manera rápida tal como sea posible.
Modelo Espiral
Basada en la necesidad continúa de refinar los
requerimientos y estimaciones del proyecto.
Efectivo para proyectos pequeños donde con la
retroalimentación dada por el cliente, se aprueba las
diferentes etapas, puede ocurrir el riesgo que no se defina
bien los objetivos por el cual el desarrollo puede ser
caótico.
Modelo Concurrente
El modelo concurrente provee una meta-descripción del proceso software, tiene la
capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Los requerimientos son denominadas "líneas de base", es decir que cuando una mayoría de
los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo
considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los
requerimientos son comunes y frecuentes.

BIBLIOGRAFIAS
http://www.hanantek.com/es/modelos-ciclo-vida-software
http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?media=principal:isis26
03-modelosciclosdevida.pdf
http://answers.yahoo.com/question/index?qid=20080602183112AAaCGjT
http://www.slideshare.net/riveramiguel/diagrama-de-diseo
http://egdamar877.blogspot.mx/2009/05/expocicion.html

Diagramas de Diseño

  • 1.
    CENTRO DE ESTUDIOSTECNOLÓGICO INDUSTRIAL Y DE SERVICIOS PROFESORA: MARGARITA ROMERO ALVARADO ALUMNA: KAREN GUADALUPE RIVERA MARTÍNEZ INVESTIGACIÓN: DIAGRAMAS DE DISEÑO Y MODELOS DE CICLO DE VIDA, SU APLICACIÓN Y ELABORACIÓN SEMESTRE: 3º GRUPO: “C” TURNO: MATUTINO ESPECIALIDAD: PROGRAMACION
  • 2.
    DIAGRAMA DE DISEÑO UnDiagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete. El diseño se mira desde tres puntos de vista: Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: * Diagrama de clases * Diagrama de componentes * Diagrama de objetos * Diagrama de despliegue * Diagrama de paquetes Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: * Diagrama de actividades * Diagrama de casos de uso * Diagrama de estados Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: * Diagrama de secuencia * Diagrama de colaboración CICLOS DE VIDA El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Representa todas las actividades y artefactos (productos intermedios) necesarios para desarrollar una aplicación. Actividades de un Ciclo de Vida Implícita o Explícitamente todos los modelos de ciclo de vida cuentan por lo menos con las siguientes actividades.
  • 3.
    MODELAMIENTO DEL CICLODE VIDA Responsable: Gerente del proyecto Personalizar las actividades de IEEE1074 a los requerimientos del proyecto y de la empresa TPOS DE MODELOS Modelo Cascada Este es el más básico de todos los modelos. su visión dice que el desarrollo de software esa través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas. Utiliza punto de control para pasar a la siguiente fase: Análisis, Diseño, Codificación, Pruebas, Implementación, Mantenimiento. Se tarda mucho tiempo en pasar todo el ciclo. El fracaso del software es la comunicación con el usuario final. Se utiliza en proyectos con requerimientos bien definidos. Las flechas muestran el flujo de información entre las fases. este modelo se enfrasca en los en: Planear un proyecto antes de embarcarse en él. Definir el comportamiento externo antes de diseñar su arquitectura interna. Documentar los resultados de cada actividad. Diseñar un sistema antes de codificarlo. Modelo De Desarrollo Evolutivo El modelo de desarrollo evolutivo construye versiones sucesivas de un producto, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. Basada en esta retroalimentación, la especificación de requerimientos es actualizada. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Modelo de Prototipado de Requerimientos El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible.
  • 4.
    Modelo Espiral Basada enla necesidad continúa de refinar los requerimientos y estimaciones del proyecto. Efectivo para proyectos pequeños donde con la retroalimentación dada por el cliente, se aprueba las diferentes etapas, puede ocurrir el riesgo que no se defina bien los objetivos por el cual el desarrollo puede ser caótico. Modelo Concurrente El modelo concurrente provee una meta-descripción del proceso software, tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente. Los requerimientos son denominadas "líneas de base", es decir que cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes. BIBLIOGRAFIAS http://www.hanantek.com/es/modelos-ciclo-vida-software http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?media=principal:isis26 03-modelosciclosdevida.pdf http://answers.yahoo.com/question/index?qid=20080602183112AAaCGjT http://www.slideshare.net/riveramiguel/diagrama-de-diseo http://egdamar877.blogspot.mx/2009/05/expocicion.html