Tutorías Preparación Complexivo: Ingeniería de Software I y II (Parte 2)

Ingeniería de Software I y II
(Parte 2)
Autor(es):
Ciencias de la Ingeniería
Carrera de Sistemas
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Aguaszoft@Outlook.es

Tener éxito no es cuestión de suerte, es el
resultado del esfuerzo más arduo
(Anónimo)
Carrera de Sistemas

Contenidos
• Modelo XP (Extreme Programming)
• Calidad de Software
• Pruebas de Carga
• Pruebas de Stress
• Versionamiento

Modelo XP (Extreme
Programming)
Carrera de Sistemas

Cambiando la forma
de hacer las cosas.
eXtremeProgramming

Emplea un enfoque
orientado a objetos.
Pararealizarsusdesarrollos

Planeación:
• Fundamentadaenlasllamadas“historias de
usuario”. Describenlascaracterísticasyla
funcionalidadrequerida.
• Losclientesasignanprioridadesaestas historias.
• Elstaff asignauncostodependiendode
experienciaspreviasyestimaciones.
• Lamedidaestadadaen “semanas”
• Tantoelclientecomoelstaff decidenenconjunto
paraloslanzamientos.

Historia de usuario
http://globalnerdy.com/wordpress/wp-content/uploads/2007/11/dilbert-xp02.gif

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

http://rbazinet.files.wordpress.com/2007/11/dilbert2666700071126.gif
Diseño:

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

Programación parejas
http://sontag.ca/gif/dilbertPairProgramming.gif

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

Pruebe con el usuario
http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/7000/200/7251/7251.strip.gif

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.

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.

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.

PROGRAMACIÓN EXTREMA (EXTREME
PROGRAMMING, XP)
VENTAJAS
• la programación extrema es
fácil de adaptarse tanto al
desarrollo de sistemas
pequeños como grandes
• optimiza el tiempo en
desarrollo
• permite realizar el
desarrollo en parejas para
complementar el
conocimiento
• el código es sencillo y
entendible
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.

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

Calidad de Software
Carrera de Sistemas

Concepto de Calidad
Conjunto de propiedades y de
características de un producto o
servicio, que le confieren aptitud para
satisfacer una necesidades explícitas o
implícitas (ISO 8402)

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.

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

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

• 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

• 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

 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
 ISO/IEC 27001 Sistema de Gestión de Seguridad de la
Información

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

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

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

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ándar ISO 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.

CMM
Capability Maturity Model
Software Engineering Institute
Carnegy Mellon University
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”

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
organizaciones
• Obliga a una revisión constante.

Inicial
Repetible
Optimizado
Dirigit
Definit
CMM

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

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.

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.

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.

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!!!

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

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

Pruebas de Carga y Stress
Carrera de Sistemas

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 consta de varios
componentes que ayudan para que la
prueba de un buen resultado

TIPOS DE PRUEBA
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

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.

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.

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

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.

PRUEBAS DE 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.

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.

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.

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

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.

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

Versionamiento
Carrera de Sistemas

Sistema de Control de Versiones
Jesús M. Castagnetto M., Ph.D. - Facultad de Ciencias y Filosofía,
y Dirección Universitaria de Información, Universidad Peruana Cayetano Heredia
● Permite el manejo de múltiplesrevisiones
Actúa a niveles de archivo decó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.
●
●
●

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

¿Cómo puede trabajar un SCV?
● Local
Información acerca de cambiosse
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.
●
●

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

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

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

Jesús M. CastagnettoM., Ph.D. - Facultad de Cienciasy Filosofía, y
Dirección Universitariade Información, Universidad Peruana Cayetano Heredia
TerceraGeneración
●
●
●
Almacenamiento centralizadode
revisiones.
Manejo completo de operaciones
complejas con archivos.
Ejemplo: Subversion.

CuartaGeneración
●
●
●
Almacenamiento descentralizadode
revisiones.
Manejo deficiente de algunos flujosde
trabajo y consolidacióncompleja.
Ejemplo: GNU arch.

QuintaGeneración
●
●
●
Almacenamiento descentralizadode
revisiones.
Manejo de múltiples flujos de trabajo,
inlcuyendo el centralizado.
Ejemplo: Bazaar.
Bazaar: http://bazaar-vcs.org/

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).
●
●

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.

Tutorías Preparación Complexivo: Ingeniería de Software I y II (Parte 2)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Tutorías Preparación Complexivo: Ingeniería de Software I y II (Parte 2)

Similar a Tutorías Preparación Complexivo: Ingeniería de Software I y II (Parte 2) (20)

Más de Luis Fernando Aguas Bucheli

Más de Luis Fernando Aguas Bucheli (20)

Último

Último (20)

Tutorías Preparación Complexivo: Ingeniería de Software I y II (Parte 2)