Este documento presenta una introducción al modelo de programación extrema (XP). Describe algunas de las prácticas clave de XP como la programación en parejas, la propiedad colectiva del código, la integración continua y las pruebas automatizadas. También discute brevemente algunas ventajas y desventajas de XP, como su capacidad de adaptarse fácilmente pero la necesidad constante de la presencia del cliente.

1. Examen de Fin de
Carrera
Ingeniería de Software
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Mg. Luis Fernando Aguas Bucheli

3. Objetivo
1. Adquirir los conceptos
básicos relacionados con
IS
2. Reconocer las
características de IS
● Ing de Software
Contenido

4. Objetivos de Desarrollo Sostenible

5. Modelo XP (Extreme
Programming)

6. Cambiando la forma de hacer las cosas.
eXtremeProgramming

7. Emplea un enfoque orientadoa objetos.
Pararealizar susdesarrollos

8. Proceso Xp

9. Planeación:
• Fundamentadaenlasllamadas“historias de
usuario”. Describenlascaracterísticasy la
funcionalidadrequerida.
• Losclientesasignanprioridadesaestashistorias.
• Elstaff asignauncostodependiendode
experienciaspreviasyestimaciones.
• Lamedidaestadadaen “semanas”
• Tantoelclientecomoelstaff decidenenconjunto
paraloslanzamientos.

10. Historia de usuario

11. Diseño:
• Siguelafilosofíade“mantenerlosimple”.
• Proporcionaunaguíadediseñoparalashistorias, tal y
comoestánescritas.Nocubrefuncionalidades extra.
• EmplealasCRC(colaborador-responsabilidad-clase).
• Dificultaddediseño=prototipo rápido para
evaluarlo.
• Prototipo dediseño=Soluciónpico.
• PromocionalaRefabricación.

12. Diseño:

13. Codificación:
• Sedebecodificarlo masprontoposible.
• Peroesnecesariodesarrollarpruebasunitariasde las
historiasdeusuario.
• Soloseagregalo queestadiseñado.
• Laprogramaciónenparejasesunelemento
característicodeXp.
• Sedebeefectuarintegracióndeloscódigosenel
momento quesonterminados.

14. Programación parejas

15. Pruebas:
• Serequierenpruebasdeunidad.
• Laautomatizacióndeestaspruebasesunelemento de
granimportancia.
• Conjuntouniversaldepruebas
• Pruebasde aceptación:
• Características
• Funcionalidad
• Laspruebasderivandelashistoriasdeusuario.

16. Pruebe con el usuario

17. Prácticas XP
Programación en parejas:
Toda la producción de código debe realizarse con
trabajo en parejas de programadores. Según Cockburn
y Williams
Propiedad colectiva del código:
Cualquier programador puede cambiar cualquier parte
del código en cualquier momento.
Integración continua:
Cada pieza de código es integrada en el sistema una
vez que esté lista. Así, el sistema puede llegar a ser
integrado y construido varias veces en un mismo día.

18. Prácticas XP
El juego de la planificación:
Es un espacio frecuente de comunicación entre el cliente y los
programadores.
Pruebas:
Las pruebas unitarias son establecidas antes de escribir el
código y son ejecutadas constantemente ante cada
modificación del sistema.
Refactorización (Refactoring):
Es una actividad constante de reestructuración del código con el
objetivo de remover duplicación de código, mejorar su
legibilidad, simplificarlo y hacerlo más flexible para facilitar los
posteriores cambios.

19. Prácticas XP
Horas por semana:
Se debe trabajar un máximo de 40 horas por semana. No se trabajan horas
extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo
un problema que debe corregirse.
Estándares de programación:
XP enfatiza la comunicación de los programadores a través del código, con lo
cual es indispensable que se sigan ciertos estándares de programación (del
equipo, de la organización u otros estándares reconocidos para los lenguajes de
programación utilizados).
Metáfora:
En XP no se enfatiza la definición temprana de una arquitectura estable para
el sistema.

20. PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP)
DESVENTAJAS
• no se tiene un
costo o tiempo
definido
• el sistema va creciendo
con cada entrega que
se le realiza al cliente
• se necesitaría de la
presencia constante del
cliente lo cual resulta
difícil de lograr.
VENTAJAS
• la programación extrema es
fácil de adaptarse tanto al
desarrollo de sistemas
pequeños como grandes
desarrollo
• optimiza el tiempo en
• permite realizar el
desarrollo en parejas para
complementar el
conocimiento
• el código es sencillo y
entendible

21. Adicional
• Consulte:
• Desarrolloadaptativo desoftware(DAS).
• Método dedesarrollodesistemasdinámicos
(MDSD).
• Melé
• Cristal
• Desarrolloconducidopor características(DCC)
• Modeladoágil(MA)

22. Calidad de Software

23. Actividades de estandarización internacional
• Existen varias organizaciones de estandarización
internacional, algunas son regionales mientras que otras son
globales. Las últimas están relacionadas con la ONU o son
independientes, como por ejemplo la International
Telecomunication Union (ITU). El ISO y el IEC son de particular
importancia para SPICE.

24. Ambas tienen por objetivo facilitar
intercambio de bienes y servicios a nivel
internacional que abarcan diversas áreas
de IT.

25. Principales normas ISO
ISO 216 Medidas de papel: p.e. ISO A4
ISO 639 Nombres de lenguas
ISO 690:1987 regula las citas bibliográficas (corresponde a la
norma UNE 50104:1994)
ISO 690-2:1997 regula las citas bibliográficas de
documentos
electrónicos
ISO 732 Formato de carrete de 120
ISO 838 Estandar para perforadoras de papel
ISO 1007 Formato de carrete de 135
ISO/IEC 1539-1 Lenguaje de programación Fortran
ISO 3029 Formato carrete de 126

26. • ISO 3166 códigos de países
• ISO 4217 códigos de divisas
• ISO 7811 Técnica de grabación en tarjetas de identificación
• ISO 8601 Representación del tiempo y la fecha. Adoptado en Internet
mediante el Date and Time Formats de W3C que utiliza UTC.
• ISO 8859 codificaciones de caracteres que incluye ASCII como un
subconjunto (Uno de ellos es el ISO 8859-1 que permite codificar las
lenguas originales de Europa occidental, como el español)
• ISO/IEC 8652:1995 Lenguaje de programación Ada
• ISO 9000 Sistemas de Gestión de la Calidad - Fundamentos y
vocabulario
• ISO 9001 Sistemas de Gestión de la Calidad - Requisitos
• ISO 9004 Sistemas de Gestión de la Calidad - Directrices para la mejora
del desempeño

27. • ISO 9660 Sistema de archivos de CD-ROM
• ISO 9899 Lenguaje de programación C
• ISO 10279 Lenguaje de programación BASIC
• ISO 10646 Universal Character Set
• ISO/IEC 11172 MPEG-1
• ISO/IEC_12207 Tecnología de la información / Ciclo de vida
del software
• ISO 13450 Formato de carrete de 110
• ISO/IEC 13818 MPEG-2

28. ISO 14000 Estándares de Gestión Medioambiental en
entornos de producción
ISO/IEC 14496 MPEG-4
ISO/IEC 15444 JPEG 2000
ISO 15693 Estándar para "tarjetas de vecindad"
ISO/IEC 17799 Seguridad de la información
ISO 26300 OpenDocument
ISO/IEC 17025 Requisitos generales relativos a la
competencia de los laboratorios de ensayo y calibración

29. (SPICE) ISO/IEC -TR 15504
Software Process Improvement Capability dEtermination
(Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de
software).
• Evaluación y mejora de procesos software.
• Inicio del proyecto 1993
• Se halla en fase de Informe Técnico
• Es aplicable a cualquier organización o empresa que quiera mejorar la capacidad de
cualquiera de sus procesos de software.
• Se puede utilizar como herramienta de evaluación del estado de los procesos de
software de la empresa.
• Es independiente de la organización, modelo del ciclo de vida, metodología y
tecnología.

30. SPICE
en sí
• Marco para métodos de evaluación, no un método o modelo
• Abarca:
– Evaluación de procesos
– Mejora de procesos
– Determinación de capacidad
• Alineado con el ISO/IEC 12207
enfoques existentes
• Intenta proporcionar un marco en el que armonizar los
• Se encuentra en la fase de Informe Técnico (TR) Tipo 2

31. Modelo de Referencia
• El modelo de referencia de SPICE describe los procesos que
una organización puede realizar para comprar, suministrar,
desarrollar, operar, mantener y soportar el software, así
como los atributos que caracterizan la capacidad de estos
procesos
• Proporciona una base para medir la capacidad de los
procesos, en función de grado de consecución de sus
atributos.
• El tiene dos dimensiones: Procesos y Capacidad

32. Dimensión Procesos
Contiene los procesos que se han de evaluar. Se
corresponden
con los procesos del ciclo de vida del software, definidos al
estándarISO 12207:1995
Se agrupan en categorías, en función del tipo de actividad
al cual se aplican:
• CUS: Cliente-Proveedor.
• ENG: Ingeniería.
• SUP: Soporte.
• MAN: Gestión.
• ORG: Organización.

33. CMM
Capability Maturity Model
Mark C. Paulk
“CMM es una aplicación de sentido común
de los conceptos de gestión de procesos y
mejora de la calidad al desarrollo y
mantenimiento del software”

34. CMM
• Estudia los procesos de desarrollo de software de una
organización y produce una evaluación de la madurez
de la organización según una escala de cinco niveles
• La madurez de un proceso es un indicador de la
capacidad para construir un software de calidad.
• Es un modelo para la mejora de las
• Obliga a una revisión constante
.

35. Inicial
Optimizado
Dirigit
Definit
Repetible
CMM

36. CMM
Contienen
Áreas claves
de proceso
Organizadas con
Características
comunes
Contienen
Prácticas
clave
Indican
Alcanzan
Se aplican
Describen
Capacidad
del proceso
Objetivos
Implementación o
Institucionalización
Infraestructura
o actividades
Niveles de
madurez

37. CMM
•Es importante tener claro
• Dónde nos encontramos
• A dónde queremos llegar
• Cómo llegaremos
• Cómo sabremos si hemos llegado
•No se puede hacer todo de golpe
•Procesos piloto previos a un despliegue a gran
escala.

38. Certificación
• La certificación, una exigencia?
• La Unión Europea edita el libro blanco sobre crecimiento, competitividad y
puestos de trabajo, y reconoce la calidad como un elemento esencial de
éxito de la empresa y constituye un factor estratégico en la política
europea de competitividad.
• Las empresas precisan marcas y certificados que ayuden a vender sus
productos en el mercado único en la era de la globalización.
• Se potencia la creación de infraestructuras de calidad: entidades de
acreditación, organismos de normalización, entidades de inspección, etc.

39. Certificación
La certificación, una exigència?
• Se impulsa la implantación de programas de calidad en las
distintas administraciones públicas.
• Las grandes empresas exigen certificados de calidad a sus proveedores.
• Desde la administración se potencia mediante subvenciones, la
implantación de programas de calidad.

40. Certificación
Proceso habitual de certificación
• Motivación.
• Selección de la norma aplicable
• Subcontratación a empresa externa.
• Auditoría de certificación.
• Informe de acciones correctoras.
• Certificado.
• Imposición de seguimiento
• Incumplimiento!!!

41. Certificación
Documentación
• Solicitud formal.
• Sistema de calidad
• Manual de calidad
• Manual de procedimientos.
• Manual de especificaciones
• Otros documentos
• Expediente y certificación.

42. Certificación
Otros aspectos
• Plazos y costes
• Consultoría
• Formación
• Organismo certificador
• Mantenimiento de la certificación
• Seguimiento anual.
• Revisión de la certificación.

43. Pruebas de Carga y Stress

44. CONCEPTO
• Se trata de evaluar el sistema o parte de
este durante o al final del desarrollo para
determinar si satisface los requisitos
iniciales.
• Este proceso
componentes que
consta
ayudan
de varios
para que la
prueba de un buen resultado

45. TIPOS
PRUEBAS UNITARIAS
• Se focaliza en ejecutar cada módulo (o
unidad mínima a ser probada, ej. = una
clase).
• Busca asegurar que el código funciona de
acuerdo con las especificaciones y que el
módulo lógico es válido

46. PRUEBAS DE INTEGRACIÓN
• Identificar errores introducidos por la combinación de
programas probados unitariamente.
• Verificar que las especificaciones de diseño sean
alcanzadas.
• Determina el enfoque para avanzar desde un nivel de
integración de las componentes al siguiente.

47. PRUEBA DE REGRESIÓN
• Determinar si los cambios recientes en
una parte de la aplicación tienen efecto
adverso en otras partes.
• La prueba de regresión es una nueva
corrida de casos de prueba previos.
• La prueba de regresión es un buen
candidato para automatización.

48. PRUEBAS DE HUMO
Toma éste nombre debido a que su objetivo es
probar el sistema constantemente buscando
que saque “humo” o falle.
de manera fácil
• Los objetivos son los siguientes:
• Detectar los errores en realeases tempranos y
• Probar el sistema constantemente
• Garantizar poco esfuerzo en la integración
final del sistema

49. PRUEBAS DEL SISTEMA
• Asegurar la apropiada navegación dentro
del sistema, ingreso de datos,
procesamiento y recuperación.
• Las pruebas del sistema deben enfocarse
en requisitos que puedan ser tomados
directamente de casos de uso y reglas y
funciones de negocios.

50. DESEMPEÑO
• Las pruebas de desempeño miden tiempos
de respuesta, índices de procesamiento de
transacciones y otros requisitos sensibles al
tiempo.
• El objetivo de las pruebas es verificar y
validar los requisitos de desempeño que se
han especificado.

51. PRUEBAS DE CARGA
• Las pruebas de carga miden la capacidad
del sistema para continuar funcionando
apropiadamente bajo diferentes
condiciones de carga.
• La meta de las pruebas de carga es
determinar y asegurar que el sistema
funciona apropiadamente aún más allá de
la carga de trabajo máxima esperada.

52. PRUEBAS DE STRESS
Use los scripts utilizados en las pruebas de
desempeño.
Verificar que el sistema funciona
apropiadamente y sin errores, bajo estas
condiciones de stress:
• Máximo número de clientes conectados o
simulados (actuales o físicamente posibles)
• Múltiples usuarios desempeñando la
misma transacción con los mismos datos.

53. PRUEBAS DE VOLUMEN
• Las pruebas de volumen hacen referencia a grandes
cantidades de datos para determinar los límites en que
se causa que el Sistema falle.
• También identifican la carga máxima o volumen que el
sistema puede manejar en un período dado.
• Máximo (actual o físicamente posible).
• Máximo tamaño de base de datos (actual o escalado).

54. PRUEBAS DE VALIDACIÓN A
SISTEMAS A LA MEDIDA
• Pruebas del Ciclo del Negocio
• Asegurar que el sistema funciona de
acuerdo con el modelo de negocios
emulando todos los eventos en el tiempo y
en función del tiempo.

55. PRUEBAS DE CONFIGURACIÓN
• Validar y verificar que el cliente del sistema
funciona apropiadamente en las estaciones
de trabajo recomendadas.
• Estas pruebas verifican la operación del
sistema en diferentes configuraciones de
hardware y software.
• Con frecuencia, el número de
configuraciones posibles es demasiado
grande

56. Versionamiento

57. Sistema de Control de Versiones
● Permite el manejo de múltiplesrevisiones
● Actúa a nivelesde archivodecódigo,
directorio, proyecto, etc.
● Se encarga de identificar, comparar, revertir, etc.,
cambios en la información
Ayuda en el desarrollo paralelo de un proyecto,
por múltiples programadores.
●

58. ¿Qué puede controlar un SCV?
● Archivos
Los más simples, controlansolamente
archivosindividuales.
● Árboles de archivos
Los más avanzados, pueden manejar
directorios (y sub-directorios) con sus archivos
asociados, incluyendo el concepto de proyecto.

59. ¿Cómo puede trabajar un SCV?
● Local
Información acerca de cambios se
mantiene en un repositoriolocal.
Centralizado
Necesitan el uso de un servidory
repositorio central.
Descentralizado
Permiten el uso de múltiples repositorios,y
sincronización entre ellos.
●
●

60. Evolución de los SCV
1
2
3
4
5
6
0
1970 1975 1980 1986 1991 1997 2002 2008
RCS (1980)
CVS (1986)
Subversion (2000)
GNU arch (2003)
Bazaar (2005)
SCCS (1972)
Source Code Control System (SCCS)

61. Desarrollo de los SCV (1)
Primera Generación
● Control de archivos individuales.
●
● Almacenamiento de local (en el mismo
directorio) de revisiones.
Ejemplos: SCCS, RCS.

62. Desarrollo de los SCV (2)
SegundaGeneración
● Control de árboles de archivos.
●
●
● Almacenamiento centralizadode
revisiones.
Manejo deficiente de algunas operaciones
(ej. renombrado de archivos).
Ejemplo: CVS.

63. Desarrollo de los SCV (3)
TerceraGeneración
● Control de árboles de archivos.
●
●
● Almacenamiento centralizadode
revisiones.
Manejo completo de operaciones
complejas con archivos.
Ejemplo: Subversion.

64. Desarrollo de los SCV (4)
CuartaGeneración
● Control de árboles de archivos.
●
●
● Almacenamiento descentralizado de
revisiones.
Manejo deficiente de algunos flujos de
trabajo y consolidación compleja.
Ejemplo: GNUarch.

65. Desarrollo de los SCV (5)
QuintaGeneración
● Control de árboles de archivos.
●
●
● Almacenamiento descentralizado de
revisiones.
Manejo de múltiples flujos detrabajo,
inlcuyendo el centralizado.
Ejemplo: Bazaar.

66. Repositorio
● Un sitio de almacenamiento derevisiones.
Puede estar estructurado internamente
como un solo archivo, una colección de
archivos, base de datos, etc.
Puede residir localmente (en el mismo
sistema de archivos), o ser remoto
(servidor o servidores).
●
●

67. GITHUB
GitHub es una forja (plataforma de desarrollo
colaborativo) para alojar proyectos utilizando
el sistema de control de versionesGit.
Se utiliza principalmente para la creación de
código fuente de programas de ordenador.

68. Gracias
Responsabilidad con pensamiento positivo