Jessica Karina García López
MAESTRA: Margarita Romero Alvarado
GRADO Y GRUPO: 3° Bm
MATERIA: dsaupo
DIAGRAMAS DE DISEÑO
Se trata de un lenguaje llamado UML (Unified Modeling Language)
Resumiendo, aunque todo esto puede ocupar mil libros de mil páginas:
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
MODELOS DE CICLO DE VIDA
Define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de
software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del
70.
Desde 10 a 15 años atrás, este modelo fue sujeto a críticas, por ser restrictivo y rígido.
Se ocupa en describir las fases principales del desarrollo de software, ayudando a
administrare progreso y desarrollo, además de proveer un espacio de trabajo detallado de
la elaboración del software
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. Testear el sistema
después de construirlo.
Modelo De Desarrollo Incremental
Existen riesgos en el desarrollo de sistemas largos y complejos. La forma de reducir los
riesgos es construir una parte del sistema.
Un sistema pequeño es siempre menos riesgoso que construir un sistema grande.es más
fácil determinar si los requerimientos para los niveles subsiguientes son correctos.
Reduciendo el tiempo de desarrollo de un sistema decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo. Los errores de
desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del
próximo incremento.
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.

APLICACIÓN Y ELABORACIÓN
1) Primero es el análisis del problema que quieres resolver (aquí se piensa cuál es tu
necesidad)
2)Diseño de la aplicación (aquí se resuelve esa necesidad mediante el código que tu
escribes <programar>)
3)Fase de pruebas (aquí pruebas tu aplicación terminada para ver que no falle)
4.a)Si falla regresas al punto 1 o 2 dependiendo de cómo se haya comportado en la etapa
de pruebas, después de eso regresas a la etapa 3.
4.b)Implementación del programa (aquí instalas tu programa en la computadora que va a
ser uso de él, para que ya trabaje de manera formal, el programa ya está terminado y se
supone que no da fallos)
5)Mantenimiento (algunas veces es necesario darle mantenimiento a los programas
creados, para solucionar pequeños detalles que salen atravesó del tiempo de uso, y es
entonces cuando salen segundas versiones de un mismo programa.)
BIBLIOGRAFIA
http://answers.yahoo.com/question/index?qid=20080602183112AAaCGjT
http://www.hanantek.com/es/modelos-ciclo-vida-software
http://answers.yahoo.com/question/index?qid=20090607140927AATf7G
http://es.wikipedia.org/wiki/Software

Tarea 13

  • 1.
    Jessica Karina GarcíaLópez MAESTRA: Margarita Romero Alvarado GRADO Y GRUPO: 3° Bm MATERIA: dsaupo
  • 2.
    DIAGRAMAS DE DISEÑO Setrata de un lenguaje llamado UML (Unified Modeling Language) Resumiendo, aunque todo esto puede ocupar mil libros de mil páginas: 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
  • 3.
    Los Diagramas deComportamiento 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
  • 4.
    MODELOS DE CICLODE VIDA Define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde 10 a 15 años atrás, este modelo fue sujeto a críticas, por ser restrictivo y rígido. Se ocupa en describir las fases principales del desarrollo de software, ayudando a administrare progreso y desarrollo, además de proveer un espacio de trabajo detallado de la elaboración del software
  • 5.
    Modelo Cascada Este esel 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. Testear el sistema después de construirlo. Modelo De Desarrollo Incremental Existen riesgos en el desarrollo de sistemas largos y complejos. La forma de reducir los riesgos es construir una parte del sistema. Un sistema pequeño es siempre menos riesgoso que construir un sistema grande.es más fácil determinar si los requerimientos para los niveles subsiguientes son correctos.
  • 6.
    Reduciendo el tiempode desarrollo de un sistema decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento. 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.
  • 7.
    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. APLICACIÓN Y ELABORACIÓN
  • 8.
    1) Primero esel análisis del problema que quieres resolver (aquí se piensa cuál es tu necesidad) 2)Diseño de la aplicación (aquí se resuelve esa necesidad mediante el código que tu escribes <programar>) 3)Fase de pruebas (aquí pruebas tu aplicación terminada para ver que no falle) 4.a)Si falla regresas al punto 1 o 2 dependiendo de cómo se haya comportado en la etapa de pruebas, después de eso regresas a la etapa 3. 4.b)Implementación del programa (aquí instalas tu programa en la computadora que va a ser uso de él, para que ya trabaje de manera formal, el programa ya está terminado y se supone que no da fallos) 5)Mantenimiento (algunas veces es necesario darle mantenimiento a los programas creados, para solucionar pequeños detalles que salen atravesó del tiempo de uso, y es entonces cuando salen segundas versiones de un mismo programa.)
  • 9.