INSTITUTO TECNOLOGICOSUPERIOR DE VILLA LA VENTA

CATEDRATICO:

ING. MARLENE MIJANGOS

ALUMNO: MILTON E. CHAVEZ H.CRISTIAN

AGUILERA P.MARCO A.

SANCHEZ R.

• Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final.

• Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades.

INTRODUCCION

MODELOS DE DESARROLLOMODELO DE CASCADA

MODELO DE ESPIRAL.DESARROLLO INCREMENTAL.MODELO X.P.

MODELO EN CASCADA

Debido a que el software es

siempre parte de un sistema…

Mas información..

El proceso de recopilación de los requisitos se

centra..Mas información..

El diseño del software se enfoca en

cuatro atributos..

Mas información..

El diseño debe traducirse en una

forma legible..Mas

informacion..

Una vez que se ha generado el

código…Mas información..

El software sufrirá cambios después de que se entrega al..

Mas información..

MODELO DE ESPIRAL• El modelo de espiral es proceso

de desarrollo de software que combina elementos tanto de diseño como de prototipo en fases. Es también conocido como el modelo de ciclo de vida de espiral, el cual es método de desarrollo de sistemas utilizado en tecnologías de información (TI)

Los requerimientos de sistema son definidos …..

Mas información…

Se crea un diseño preliminar  para el nuevo sistema. Esta fase es la más importante… 

Mas información…

Se construye un primer prototipo del

nuevo…

Mas información…

Un segundo prototipo es evolucionado de un

procedimiento……

Mas información…

• La programación extrema es una metodología reciente (tiene alrededor de 5 años) en el desarrollo de software. La filosofía de X.P es satisfacer al completo las necesidades del cliente, por eso lo integra como una parte más del equipo de desarrollo. 

X.P

XPEXTREME

PROGRAMING

PLANIFICACION

DISEÑO

CODIFICACION

PRUEBAS

HIST. DE USUARIO

RELEASE PLANNING

ITERACION

VELOCIDAD DEL PROYECTO

PROGRAMACION EN PAREJA

REUNIONES DIARIAS

REUNIONES SIMPLES

GLOSARIO DE TERMINOS

RIESGOS

FUNCIONALIDAD EXTRA

TARJETAS C.R.C

TEST DE ACEPTACION

Historias de usuario: El primer paso de cualquier proyecto que siga

la metodología X.P es definir….

Mas información..

 Diseños simples: La

metodología X.P sugiere que hay que conseguir diseños

simples y sencillos. 

Mas información..

El cliente es una parte más del

equipo de desarrollo; su presencia es

indispensable en las distintas fases de

X.P.

Mas información..

 

Uno de los pilares de la metodología X.P es el uso de test

para comprobar el funcionamiento de

…..

Mas información..

• En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación.

MODELO INCREMENTAL

DEFIN. DE

OBJETIVOS

REVISION

IMPLEMEN-TACION

DISEÑO Y

MODELIZACION

DEF. DE REQUERIMIENTOS

Es una meta o finalidad a cumplir para la que se

disponen medios determinados.

Es evaluar el software que cumpla con los

requerimientos de usuario con calidad. Es la realización de una

aplicación, o la ejecución de un plan, idea, modelo

científico, diseño, especificación, estándar,

algoritmo o política.

En esta fase se identificarán las fuentes

de los datos y las transformaciones

necesarias para, a partir de dichas fuentes,

obtener el modelo lógico de datos.

Es la metodología de elegir lo que mejor

ayudara ala realización del software .

GESTION DE

PROYECTO

FIN

ESTA ES UNA RECOPILACION DE INFORMACION DE PAGINAS WEB

PARA HACER UN POCO MAS ENTENDIBLE ESTOS TEMAS.

GRACIAS!!!

• http://www.ricardochamberlain.com/2011/04/el-modelo-de-espiral/

• http://www.slideshare.net/inventa2/modelos-de-desarrollo

• http://es.wikipedia.org/wiki/Implementaci%C3%B3n• https://sites.google.com/site/datawarehouse2010iicr/fases-de-implantacion-de-un-data-warehouse/diseno-y-modelizacion

• http://www.sistemaspaez.com/revisiones/contabilidad.htm

• http://www.buenastareas.com/ensayos/Modelo-o-Desarrollo-En-Cascada/3726.html

BIBLIOGRAFIA

Ingeniería y análisis del sistema

• Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

Análisis de los requisitos del software

• El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

•                           

Diseño

• El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.

Codificación

• El diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.

Prueba

• Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento

• El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

• Los requerimientos de sistema son definidos con el mayor detalle posible. Normalmente esto involucra el entrevistar una gran cantidad de usuarios que representan a todos los usuarios externos e internos así como otros aspectos del sistema.

• Se crea un diseño preliminar  para el nuevo sistema. Esta fase es la más importante del modelo de espiral. En esta fase todas las alternativas posibles (y disponibles) que puedan ayudar en desarrollar un proyecto eficiente (en términos de costos) son analizadas y se deciden las estrategias a seguir para usarlas. Esta fase ha sido añadida especialmente para identificar y resolver todos los posibles riesgos en el desarrollo del proyecto.

• Se construye un primer prototipo del nuevo sistema tomando como referencia el diseño preliminar. Este normalmente es un sistema que irá creciendo, y representa una aproximación de las características del producto final.

• Un segundo prototipo es evolucionado de un procedimiento de cuatro fases:

1- Evaluación del primer prototipo en términos de sus fortalezas, debilidades y riesgos

2- Definición de los requerimientos del segundo prototipo

3- Planeación y diseño del segundo prototipo

4- Construcción y pruebas del segundo prototipo

• Historias de usuario: Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles.

• Reléase plan: Es una planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán implementadas en cada versión del programa.

PLANIFICACION DEL PROYECTO

CONTINUA…

• . Iteraciones Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el "Reléase planning" que serán implementadas.

• Velocidad del proyecto: La velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla el

proyecto. •   Programación en pareja: La metodología

X.P. aconseja la programación en parejas pues incrementa la productividad y la calidad del software desarrollado. 

• Reuniones diarias. Es necesario que los desarrolladores se reúnan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. 

• Diseños simples: La metodología X.P sugiere que hay que conseguir diseños simples y sencillos.

• Glosarios de términos: Usar glosarios de términos y un correcta especificación de los nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores ampliaciones y la reutilización del código. 

• Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese problema. 

• Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. 

FASE: DISEÑO

CONTINUA….

• Refactorizar. Refactorizar es mejorar y modificar la estructura y codificación de códigos ya creados

sin alterar su funcionalidad. • Tarjetas C.R.C. El uso de las tarjetas C.R.C

(Class, Responsabilities and Collaboration) permiten al programador centrarse y apreciar el desarrollo orientado a objetos olvidándose de los malos hábitos de la programación procedural clásica.

• La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares mantiene el código consistente y facilita su comprensión y escalabilidad. Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará a desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es exactamente lo que tiene que hacer el código a implementar y sabremos que una vez implementado pasará dichos test sin problemas ya que dicho código ha sido diseñado para ese fin.

CODIFICACION:

• Uno de los pilares de la metodología X.P es el uso de test para comprobar el funcionamiento de los códigos que vayamos implementando. 

• El uso de los test en X.P es el siguiente: 1.- Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo específico para test. 2.- Hay que someter a tests las distintas clases del sistema omitiendo los métodos más triviales. 3.-Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado anterior se explicó la importancia de crear antes los test que el código. 

PRUEBAS: