Trabajo por Milton y Cristian.

1. ALUMNO:
CATEDRATICO MILTON E. CHAVEZ
: H.
ING. MARLENE CRISTIAN AGUILERA

2. • 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.

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

4. El proceso de El diseño del
recopilación de software se
los requisitos se enfoca en
El diseño debe centra.. cuatro
traducirse en una Mas información.. atributos..
forma legible.. Mas información..
Mas informacion..
El software
sufrirá cambios
después de que
se entrega al..
Debido a que el Mas información..
software es
siempre parte de Una vez que se
un sistema… ha generado el
Mas información.. código…
Mas información..

5. • 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)

6. Un segundo prototipo es
evolucionado de un
procedimiento……
Mas información…
Se crea un diseño
preliminar para el nuevo
sistema. Esta fase es la
más importante…
Los requerimientos de Se construye un primer
sistema son definidos ….. prototipo del nuevo…Mas información…
Mas información…
Mas información…

7. • 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.

8. HIST. DE USUARIO El cliente es una parte
Uno de los pilares de la
RELEASE más del equipo de
metodología X.P es el uso PLANNING
PLANIFICACION desarrollo; su presencia
de test para comprobar el
ITERACION es indispensable en las
funcionamiento de …..
distintas fases de X.P.
Mas información.. VELOCIDAD DEL
PROYECTO Mas información..
PROGRAMACION
EN PAREJA
REUNIONES REUNIONES
DISEÑO DIARIAS SIMPLES
GLOSARIO DE
TERMINOS
RIESGOS
XP
EXTREME FUNCIONALIDAD
PROGRAMING EXTRA
TARJETAS C.R.C
CODIFICACION
Historias de usuario: El Diseños simples: La
primer paso de metodología X.P sugiere
cualquier proyecto que que hay que conseguir
siga la metodología X.P diseños simples y
es definir…. sencillos.
Mas información.. PRUEBAS
TEST DE
ACEPTACION
Mas información..

9. • 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.

10. Es una meta o finalidad Es la metodología de
a cumplir para la que se DEFIN. DE elegir lo que mejor
disponen medios OBJETIVO ayudara ala realización
determinados. S del software .
DEF. DE
REQUERI
REVISION MIENTOS
GESTION
DE En esta fase se
PROYECT identificarán las fuentes
Es evaluar el software O de los datos y las
que cumpla con los transformaciones
requerimientos de necesarias para, a partir
usuario con calidad. Es la realización de una de dichas fuentes,
aplicación, o la ejecución obtener el modelo lógico
de un plan, idea, modelo de datos.
científico, diseño, DISEÑO Y
IMPLEMEN MODELIZ
-TACION especificación, estándar,
algoritmo o política. ACION

11. ESTA ES UNA RECOPILACION DE
INFORMACION DE PAGINAS WEB
PARA HACER UN POCO MAS
ENTENDIBLE ESTOS TEMAS.
GRACIAS!!!

12. • 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/f
ases-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

13. •

14. •
•

15. • 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.

16. • 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.

17. •

18. • El software sufrirá cambios después de que se
entrega al cliente. Los cambios ocurrirán
debi do a que hayan encont r ado er r or es, a
que el software deba adaptarse a cambios del
entorno externo (sistema operativo o
dispositivos periféricos), o debi do a que el
cl i ent e r equi er a am i aci ones
pl
f unci onal es o del r endi m ent o.
i

19. • 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.

20. • 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.

21. • 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.

22. • 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

23. • 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.
CONTINUA…

24. • . 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.

25. • 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.
CONTINUA….

26. • 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.

27. • 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.

28. • 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.