GCSW Unidad1: Objetos de la Gestión de Configuración del Software

Gestión de Configuración del Software Carrera de Software
Ph.D. Franklin Parrales 1
22/10/2022
Objetos de la Gestión de
Configuración del Software
Unidad 1
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Gestión de Configuración del Software

22/10/2022
Objetivo general de la Unidad 1
Caracterizar los elementos que involucran la gestión de la
configuración del software mediante la identificación de
cada uno de sus elementos y características para la
correcta aplicación de los mismos.

22/10/2022
Referencias
• Pressman, R.S. Ingeniería
del Software. Un Enfoque
Práctico. Séptima Edición.
McGraw-Hill, 2011
• Sommerville, I. Ingeniería
del Software. 7ª edición.
Addison-Wesley, 2005
• IEEE Std. 828-1998, IEEE
Standard for Software
Configuration
Management Plans
• IEEE Std. 1042-1987,
IEEE Guide to Software
Configuration
Management

22/10/2022
Contenido: Introducción a la gestión de
la configuración del software.
• Línea base y objetivos de la gestión de la configuración de
software.
• Especificación del sistema.
• Especificación de requisitos de software
• Especificación de diseño de software
• Código fuente
• Pruebas de software: Integración de los distintos tipos de
pruebas de software en el ciclo de desarrollo. Análisis del
papel de las pruebas de software en la integración y
despliegue continuos.
• Manual de operación e instalación
• Programas ejecutables
• Manual de usuario
• Mantenimiento.

22/10/2022
Introducción
• Cuando se construye software los cambios
son inevitables
• Los cambios aumentan el nivel de confusión
en el equipo de desarrollo
• Confusión debida a:
– No se han analizado los cambios antes de
realizarlos.
– No se han registrado antes de implementarlos.
– No se les ha comunicado a aquellas personas
que necesitan saberlo.
– No se han controlado de manera que mejoren la
calidad y reduzcan los errores.

22/10/2022
¿Qué es la Gestión de Configuración?
• El arte de coordinar el desarrollo de software para minimizar
la confusión. El arte de identificar, organizar y controlar las
modificaciones que sufre el software que construye un equipo
de programación. El objetivo es maximizar la productividad
minimizando los errores (Babich)
• MISIÓN
– Minimizar la confusión
– Maximizar la productividad
– Minimizar los errores

22/10/2022
¿Cuándo realizar Gestión de Configuración?
• La Gestión de la Configuración Software (GCS)
es una actividad de protección que gestiona el
cambio a lo largo del ciclo de vida del software
Inicio Desarrollo Mantenimiento
Gestión de la Configuración

22/10/2022
Objetivos de la Gestión de Configuración
• Facilitar la visibilidad:
– sobre el estado del producto en todo
momento: ESTADO
– sobre su historia: EVOLUCIÓN
• Mantener la integridad del producto:
REQUISITOS

22/10/2022
Tipos de Evolución en el Software
• Propia del proceso de desarrollo: Ciclo de
Vida del Producto
• Como respuesta a errores o desviaciones
respecto de los requisitos
• Como respuesta a cambios en los
requisitos

22/10/2022
El Cambio
• Inevitabilidad del cambio: puede
producirse en cualquier momento y por
cualquier razón
• Justificación del cambio: Según pasa el
tiempo se sabe más
– Cuál es el problema
– Cómo resolverlo

22/10/2022
El Cambio
• Las fuentes fundamentales del cambio son:
– Fallos.
– Nuevos negocios o condiciones comerciales que
dictan cambios en los requisitos del producto.
– Nuevas necesidades del cliente que demandan la
modificación de los datos, funciones o servicios.
– Reorganización y/o reducción del volumen
comercial que provoca cambios en el proyecto.
– Restricciones presupuestarias o de planificación
que provocan una redefinición del producto.

22/10/2022
Cómo conseguir los objetivos
• Actividades de Gestión de Configuración
según el estándar IEEE 828
– Identificación de la Configuración: Visibilidad sobre el
producto
• Componentes
• Estructura
– Control de Cambios sobre la Configuración: Control
de la Evolución
– Auditoría de la Configuración: Comprobación de la
Integridad
– Contabilidad del Estado de la Configuración:
Informes, Registros, Estadísticas

22/10/2022
Definiciones
• Configuración:
– Productos utilizados o generados en un
proyecto de desarrollo de software
• Elemento de Configuración Software
(ECS):
– Componente de la configuración
– Unidad de trabajo para la GCS

22/10/2022
¿Qué puede ser un ECS?
• Pueden ser:
• Documentos
• Programas
• Ficheros
• Bases de Datos, etc.
• Decisión en cada proyecto:
– ¿Qué van a ser los ECS?
• Productos HW/SW/Documentación utilizados
• Descomposición del producto SW construido:
– Tamaño
– Complejidad
– Necesidad de visibilidad y control
– ¿Cuáles van a estar “bajo control de configuración”?

22/10/2022
Línea Base (Baseline)
• Concepto para facilitar el control de cambios
• Definiciones
– Punto de vista del proceso
• Punto de referencia
• Aprobación de uno o más ECS
• Revisión técnica formal
– Punto de vista del producto
• Conjunto de ECS aprobados
• Sirven como base para el desarrollo posterior
• Sólo pueden cambiarse mediante un proceso formal de
control de cambios

22/10/2022
Línea Base (Baseline)
• IEEE define una línea base como:
– “una especificación o producto que se ha
revisado formalmente y sobre el que se ha
llegado a un acuerdo, y que de ahí en
adelante sirve como base para un desarrollo
posterior y que puede cambiarse solamente a
través de procedimientos formales de control
de cambios”

22/10/2022
Complejidad de la Gestión de Configuración
• Número de elementos a controlar
– Crece según progresa el proceso
– Según el tamaño del producto
• Número de cambios: Hay que intentar minimizarlos
– Cambios en los requisitos: Buena Gestión de Requisitos
• Educción
• Prototipado
• Participación del usuario en el desarrollo
• A VECES ES INEVITABLE. CUANTO ANTES SE PRODUZCA MEJOR
– Problemas: Buena Garantía de Calidad
• Gestión de Configuración
• Gestión de Problemas
– Detectarlos lo antes posible
– Estudiar sus causas y evitar que se produzcan

22/10/2022
Necesidad de la Gestión de Configuración
• Aplicaciones grandes:
– Es más difícil tener visibilidad y controlar un número
elevado de componentes
• Aplicaciones complejas:
– Cuantas más relaciones entre componentes más
difícil determinar los efectos de un cambio
– Más difícil visibilidad sobre el producto
• Aplicaciones de larga vida:
– Las personas cambian y se llevan lo que tienen en la
memoria
– Caminos de evolución largos con múltiples versiones

22/10/2022
Necesidad de la Gestión de Configuración
• Organización grande:
– Cada persona conoce sólo su porción del
producto
– Problemas de coordinación entre cambios
• Mantenimiento simultáneo de múltiples
versiones
– Sobre qué versión realizar cada cambio

22/10/2022
Actividades Relacionadas
• Control de Versiones (Facilita la Gestión de
Configuración)
– Saber para cada elemento:
• Cuál es la última versión
• Relación entre distintas versiones (evolución de
versiones)
• Dónde están
– Esto facilita el control de cambios
• ¿Sobre qué versión/es hacer un cambio?

22/10/2022
• Construcción (building): Gestión de la
compilación y enlazado (Facilitada por la
Gestión de Configuración)
– Necesita saber:
• Qué componentes enlazar
• En qué versión
• Dónde están
– Toma esta información de:
• Identificación de la Configuración
• Control de Versiones

22/10/2022
• Gestión de Problemas (Facilitada por la Gestión
de Configuración)
– El cambio sobre un producto puede venir
dado por:
• Cambio en los requisitos/necesidades
• PROBLEMA:
– Información acerca del problema
– Proceso y forma de resolución del problema

22/10/2022
• Control del Trabajo en Equipo (Facilitada por
la Gestión de Configuración)
– Compartición de elementos de trabajo:
Peligro de sobreescritura de cambios
– Desarrollo paralelo: Integración del trabajo
realizado en paralelo (MERGE)
• Mantenimiento (Facilitada por la Gestión de
Configuración)

22/10/2022
Otros aspectos relacionados
• Metodologías
– Integración de las actividades de GC
– Determina los productos que se van a generar y tienen que ser
controlados
• Entorno de Desarrollo
– Uso de herramientas de GC
– Integración con otras herramientas del entorno de desarrollo
• Organización
– Aparecen nuevos roles y responsabilidades
– Integración en la organización del proyecto (interrelaciones con
otros)

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
Visión global del desarrollo
Clientes y
Usuarios
Desarrolladores
software
objetivo
Maquina
Personas, Equipos, Organizaciones
Ideas…Especificación… Diseño… Código

22/10/2022
Visión global del desarrollo
client,
users
architect developers
appearance,
behaviour
construction,
co-operation
architectural
design
visualises prescribes
requirements solutions
creates
assess assess
requerimientos
crea
mide
visualiza preescribe
imple-
menta
soluciones
clientes,
usuarios arquitecto desarrolladores
apariencia,
comportamiento
diseño
arquitectónico
construcción,
cooperación

22/10/2022
Ingeniería de Requerimientos y el diseño en
el proceso de desarrollo de software
• Requerimientos: Generalmente, cliente y contratista
analizan primero los requerimientos que resultan, desde el
punto de vista del cliente, para el software a diseñar. En este
contexto, el cliente prepara el así llamado pliego de
condiciones.
• Realización: A continuación, cliente y contratista elaboran un
concepto, en el que se define con qué estructuras de
programa, técnicas de programación y algoritmos los
requerimientos analizados anteriormente se deben cumplir y
programar. El contratista especifica los resultados de este
concepto en el denominado pliego de condiciones.
• Diseño de software: es el proceso de diseño para la
planificación de una solución de software. Este proceso es,
por regla general, necesario para que los programadores
puedan manejar la complejidad que la mayoría de los
programas informáticos poseen y para disminuir el riesgo de
desarrollos erróneos.

22/10/2022
Requisitos y diseño
“El usuario podrá
enviar mensajes a
cualquier usuario
en cualquier otra
computadora en
red”
Topología de Red
Protocolo
Velocidad (bps)
. . .
DISEÑO
TÉCNICO
DISEÑO
CONCEPTUAL
SRS SDD

22/10/2022
Requisitos y diseño
• En principio, los requisitos deben indicar lo qué el
sistema debe hacer y el diseño debe describir
cómo lo debe hacer.
• En la práctica, es prácticamente imposible excluir
toda la información de diseño al especificar en un
nivel adecuado los requisitos de software.
– La arquitectura del sistema puede ser diseñada para
estructurar los requisitos.
– El sistema puede interactuar con otros sistemas que
generan requisitos de diseño.
– El uso de una arquitectura especifica para satisfacer
los requisitos no funcionales puede ser un requisito.

22/10/2022
Diseño Conceptual y Técnico
• Para transformar los requerimientos en un
sistema que funcione, los diseñadores deben
satisfacer tanto a los clientes como a los
constructores de sistemas.
• Los clientes deben comprender lo que el
sistema debe hacer, y los constructores
deben comprender cómo debe operar el
sistema.
• El diseño es un proceso iterativo que
consta de dos partes: Diseño conceptual
o del sistema, Diseño técnico.

22/10/2022
Diseño Conceptual y Técnico
DISEÑO
CONCEPTUAL
función
DISEÑO
TÉCNICO
forma
QUÉ CÓMO
Constructores
del Sistema
Diseñadores
del Sistema
Clientes
SRS SDD

22/10/2022
Uso de ingeniería inversa para un diseño muy detallado
Arquitectura
Diseño
detallado
SRS SDD
Código
fuente
comentado
Jerarquía de clases;
lista de métodos;
pseudo-
código
3
Ingeniería
inversa
2
1

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
IEEE Std. 830-1998
Introducción
• El IEEE Std. 830-1998 se encarga de
proporcionar unas normas para la
creación de la Especificación de
Requisitos Software (SRS, Software
Requirements Specification)

22/10/2022
IEEE Std. 830-1998
Introducción
• Objetivos de la SRS:
– Establecer la base para un acuerdo entre clientes
y desarrolladores sobre qué debe hacer el
software.
– Reducir el esfuerzo de desarrollo.
– Proporcionar una base para la estimación de
costes y planificación.
– Proporcionar una guía para la validación y
verificación.
– Facilitar la transferencia de software.
– Servir como base para mejoras posteriores.

22/10/2022
IEEE Std. 830-1998
Introducción
• Según el IEEE una SRS debería identificar las
siguientes características del sistema:
– Funcionalidad. Lo que hace el sistema.
– Interfaces externas. Forma de interactuar del sistema
con las personas, el hardware del sistema, otro
hardware y otro software.
– Prestaciones. Entre otras, velocidad, disponibilidad y
tiempo de respuesta del sistema
– Atributos. Portabilidad, corrección, mantenibilidad,
seguridad y otros atributos.
– Restricciones de diseño impuestas a la
implementación. Entre otras, estándares, lenguajes
de implementación, entornos operativos, etc.

22/10/2022
IEEE Std. 830-1998
Introducción
• Hay otras cuestiones que deben excluirse
de la SRS:
– Detalles de diseño o implementación.
– Restricciones adicionales sobre el software.

22/10/2022
1. Introducción
1.1 Propósito
1.2 Alcance
1.3 Definiciones, acrónimos y abreviaturas
1.4 Referencias
1.5 Resumen
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones
2.5 Supuestos y dependencias
2.6 Requisitos futuros
3. Requisitos específicos
3.1 Interfaces externos
3.2 Funciones
3.3 Requisitos de rendimiento
3.4 Requisitos lógicos de la base de datos
3.5 Restricciones de diseño
3.6 Atributos del sistema software
Apéndices
Índice
Estándar IEEE Std 830-1998, para
documentación de requisitos de software

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
• El diseño detallado tiene que ver con el diseño de las
micro-componentes de nuestro sistema.
• Obviamente, este diseño tiene que tener en cuenta los
requisitos del SRD (última versión) y el Diseño
arquitectónico.
• Para efectos del proyecto consideraremos que el
especificaremos el Diseño Detallado a través de:
– Diseño Detallado de Módulos
– Modelo de Navegación
– Interfaces de Usuario
– Diccionario de Datos
– Diseño de Algoritmos
– Matríz de Trazado
documentación de diseño de software

22/10/2022
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
2. References
3. Decomposition description
3.1. Module decomposition
3.1.1 Module 1 description
3.2 Concurrent process
decomposition
3.2.1 Process 1 description
3.3 Data decomposition
3.3.1 Data entry 1 description
3.3.2 Data entry 2 description
4. Dependency description
4.1 Intermodule dependencies
4.2 Interprocess dependencies
4.3 Data dependencies
5. Interface description
5.1 Module interface
5.2 Process interface
6. Detailed design
6.1 Module detailed design
6.1.1 Module 1 detail
6.2.2 Module 2 detail
6.2 Data detailed design
6.2.1 Data entity 1 detail
6.2.2 Data entity 2 detail
Architecture
documentación de diseño de software

22/10/2022
Arquitectura vs. Diseño
• Arquitectura: donde se plasman las decisiones no
funcionales y se dividen los requisitos funcionales
• Diseño: donde se cumplen los requisitos funcionales
requisitos no
funcionales
("ilitys")
requisitos
funcionales
(dominio)
Arquitectura
(ADL)
Diseño
(UML)

22/10/2022
Clasificación de estilos arquitectónicos
❑ Flujo de datos
– Datos fluyen entre los elementos funcionales
❑ Componentes independientes
– -- ejecución en paralelo, ocasionalmente se
están comunicando
❑ Máquinas virtuales
– Interpretador + programa en lenguaje de
propósito especial
❑ Repositorios
– Construido principalmente en torno a un gran
almacén de datos
❑ Capas jerárquicas (layers)
– Subsistemas, cada uno de los cuales depende
unidireccionalmente de otro subsistema
Garlan
&
Shaw

22/10/2022
Modelado
de
software
Niveles
de
abstracción
arquitectónica

22/10/2022
conceptos del dominio
Modelo de Casos de Uso
: Sistema
introducirArticulo
(id, cantidad)
...
Procesar Venta
1.El Cliente
llega ...
2.El Cajero
realiza una
nueva venta.
3. ...
Casos de uso Diagramas de Secuencia del Sistema
crear
NuevaVenta()
eventos
del sistema
Modelo de Diseño
: Registro
introducirArticulo
(id, cantidad)
: CatalogoDeProductos
espec := getEspecificacion( id )
añadirLineaDeVenta(espec, cantidad)
. . .
las clases del
diseño
descubiertas
durante el
diseño de las
realizaciones
de los casos
de uso se puede
resumir en
diagramas
de clases.
: Venta
realización del
caso de uso
con diagramas
de interacción
las clases
conceptuales
del dominio
inspiran
los nombres
de algunas
de las clases
software en
el diseño
crearNuevaVenta()
create()
Cajero
Procesar
Venta
Diagramas de Casos de Uso
: Cajero
Venta Capturada-en Registro CatalogoDeProductos . . .
marcaDeTiempo 1 1 ... . . . . . .
Registro
1 1
CatalogoDeProductos
...
...
crearNuevaVenta()
introducirArticulo(...)
...
getEspecificacion(...) : EspecificacionDelProducto
...
Modelo del Dominio
Modelado
UML
de
software
Relaciones
entre
los
artefactos
del
Proceso
Unificado

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
Máquina ( 0’s y 1’s)
Alto nivel (C, vb,perl..)
Más parecido
al lenguaje
natural, más
fácil de
entender
Más
parecido al
lenguaje del
computador
Bajo Nivel (Ensamblador)
Lenguajes de Programación
• Las computadoras “hablan” su propio lenguaje, el cual es numérico
y está limitado a 1s y 0s (Sistema Binario).
• Para poder comunicarnos con ellas, existen varias alternativas:
– Usar el mismo lenguaje de ellas: un lenguaje de máquina
– Usar un lenguaje parecido al de las computadoras: un lenguaje
de bajo nivel
– Usar un lenguaje parecido al nuestro: un lenguaje de alto nivel

22/10/2022
Código fuente
• Por código fuente se entiende todo texto
legible por un ser humano y redactado en
un lenguaje de programación
determinado.
• El objetivo del código fuente es crear
normas y disposiciones claras para el
ordenador y que este sea capaz de
traducirlas a su propio lenguaje.

22/10/2022
El problema del mapeo
• La implementación es la única fase de la ingeniería de
software que no es opcional
• El desarrollo basado en la arquitectura proporciona un
giro único al problema clásico
– Se convierte, en gran medida, en una actividad de
mapeo
• Mantener el mapeo significa asegurar que nuestra
intención arquitectónica se refleje en nuestros sistemas
construidos
Decisiones
de diseño
Implementación de
Artefactos

22/10/2022
Una forma de implementar el código (1/2)
1. Planifique la estructura y el diseño residual para tu
código
– (complete lo que falta al diseño detallado, si aplica)
• Considerar las condiciones previas y posteriores
• Considerar el tiempo invertido
2. Inspeccione su diseño y / o estructura.
– Considerar el tiempo empleado, tipo por defecto, fuente,
prioridad
3. Escriba su código
– no compilar todavía
– pruebe los métodos que se enumeran a continuación
– aplicar los estándares requeridos
– código de la manera más fácil de verificar
– use métodos formales si es apropiado

22/10/2022
Una forma de implementar el código (2/2)
4. Auto-inspecciona tu código, no lo compiles todavía.
– Convéncete de que tu código hace el trabajo requerido
• el compilador nunca hará esto por usted: ¡simplemente verifica
la sintaxis!
– Anota el tiempo empleado, los defectos encontrados, el
tipo, fuente, prioridad
5. Compila tu código
– Repara defectos de sintaxis
– Anota el tiempo empleado, el tipo de defecto, la fuente, la
prioridad y las LOCs.
6. Pruebe su código
– Aplica los métodos de prueba unitaria
– Anota el tiempo empleado, los defectos encontrados, el
tipo, la fuente, la prioridad

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
Bugs y testing
• Confiabilidad (reliability): Probabilidad de que un sistema
de software no cause fallas en condiciones específicas.
– Medido por tiempo de actividad, MTTF (tiempo medio hasta la
falla), datos de fallas.
• Bugs son inevitables en cualquier sistema de software
complejo.
– Estimaciones de la industria: 10-50 errores por 1000 líneas de
código.
– Un error puede ser visible o puede esconderse en su código
hasta mucho más tarde.
• testing: Un intento sistemático de revelar errores.
– Prueba fallida: se demostró un error.
– Prueba aprobada: no se encontró ningún error (para esta
situación particular).

22/10/2022
Introducción a las pruebas
Ariane 5.
Lanzado por primera vez el 4 de junio de
1996.
Motivo:
Fallo software. La programación no se había probado lo suficiente.
Ariane 5.
36.7 segundos después explotó.
En concreto el fallo fue un trozo de software que habían reutilizado
del Ariane 4, pero que no lo habían probado en el Ariane 5

22/10/2022
Introducción a las pruebas
Sistemas software:
• Mayor tamaño.
• Mayor complejidad.
• Menor tiempo de desarrollo.
• Mayor calidad.
Pruebas:
• Más importancia y
protagonismo día a día.
• Garantizan la calidad del
software.
• Garantizan la satisfacción
de los requisitos.
• Ahorran tiempo y recurso en
el desarrollo.
• Su objetivo: localizar, para
subsanarlas, el mayor
número de deficiencias lo
antes posible.
Un reto a la
Ingeniería de
Software.

22/10/2022
Pruebas de Programas
• Pruebas de programas es el proceso de
ejecutar programas con el propósito de
encontrar errores
• Se puede demostrar la presencia de un
error pero no la ausencia [Dijkstra]
• Debería ser visto como el último recurso
para encontrar errores

22/10/2022
Repaso: Definiciones
• Requerimientos: “¿Qué hace el producto?”
– Expresado sin ambigüedad y de forma verificable
• Arquitectura: “¿Cómo está hecho?” (descripto en el
nivel de abstracción más alto)
– Ej.: Diagrama de bloques; flujo de datos entre estos
• Diseño Detallado: “¿Cómo está hecho?” (descripto en
un nivel de abstracción intermedio)
– Ej.: Especificación de las interfases; descripción detallada
de la operación
• Implementación: “¿Cómo está hecho?” (descripto en
nivel de abstracción bajo)
– Ej.: Código; esquemático; dibujo del circuito impreso
• Integración de módulos diseñados separadamente
– Ej.: Hardware y software
• Verificación: “¿Funciona como debe?”

22/10/2022
Repaso: Ciclo de Vida Tipo “V”
• Es una evolución del
anterior. En este, la
verificación se desglosa
en etapas de nivel de
abstracción creciente.
Análisis y
Definición de los
Requerimientos
Diseño de la
Arquitectura del
Sistema
Diseño Detallado Testeo de cada
unidad (unit test)
Instalación,
Operación y
Mantenimiento
Prueba de
Aceptación
Prueba de
Integración
Implementación de
cada unidad
Plan de Pruebas
para Cada Unidad
Plan de Pruebas
de Integración
Plan de Pruebas de
Aceptación
❑ En cada etapa de
diseño se crea un
plan de pruebas,
que es el que guía la
etapa de validación
que le corresponde.

22/10/2022
Niveles de Pruebas
• Prueba de unidad (unit testing)
– Se testean unidades individuales de código (software o
hardware) separadamente.
• …por medio de sus interfaces, en un lenguaje de programación
(C, etc.)
– Es el primer paso de un enfoque bottom-up de testeo,
como el que propone el modelo V.
• Prueba de integración (integration testing)
– Se testean los módulos anteriores en conjunto, o sea,
una vez “conectados” entre sí.
• …también por medio de sus interfaces en C u otro lenguaje.
• Prueba de aceptación (acceptance testing o system
testing)
– Se testea que el conjunto cumpla los requerimientos.
– Se lo hace por medio de las interfaces del producto final
• Interfaces al usuario, etc.

22/10/2022
Niveles de prueba
P
r
o
c
e
s
o
d
e
d
e
s
a
r
r
o
l
l
o
P
r
o
c
e
s
o
d
e
p
r
u
e
b
a
Pruebas
unitárias
Pruebas de
integración
Pruebas de
sistema
Pruebas de
aceptación
Componentes
aislados
Verifican
Interacción
entre
componentes
Verifican
Requisitos del
sistema
Necesidades
de los
usuarios
Verifican
Verifican
Pruebas de
implantación
Paso a
producción
Verifican

22/10/2022
Tipos de prueba de soportabilidad
Existen de dos tipos:
• De Configuración: Se enfocan en evaluar
aquellos elementos configurados para
diferentes hardware y/o configuraciones de
software.
– Pueden implementarse como pruebas de
rendimiento del sistema.
• De Instalación: Se enfoca en evaluar que el
elemento a probar se instala como se indica,
en diferentes configuraciones de hardware y
software.

22/10/2022
Pruebas de Instalación
• A veces no son muy tomadas en cuenta…
• Se realiza para asegurar el funcionamiento
correcto de opciones y funcionalidades de la
instalación
• También se realiza para asegurar que todos
los componentes necesarios sean realmente
instalados

22/10/2022
Algunos casos de prueba de Instalación
• Computadoras con espacio en disco requerido
mínimo
• Computadoras con memoria RAM mínima
recomendada
• Discos removibles
• Sistemas con instalaciones frescas
• Sistemas con instalaciones sucias
• También es importante probar:
– Las opciones de instalación
– Botones de navegación
– Campos de entrada de usuario

22/10/2022
Desinstalación
• También es importante probar la
desinstalación del producto:
– Datos sean removidos
– DLLs sean removidos
– Ejecutables sean removidos

22/10/2022
Pruebas generales de software
Prueba Unitaria
• Ejecutar cada módulo
• Particionar, definir los casos de prueba.
• Comparar el resultado
Prueba de Regresión
• Identificar errores introducidos por la
combinación de programas probados
unitariamente.
• Determina cómo la base de datos de
prueba será cargada
• Utilizar la técnica down-top.
Pruebas de Humo
• Detectar los errores en realeases
tempranos y de manera fácil
• su objetivo es probar el sistema
constantemente buscando que saque
“humo”
• Realizar una integración de todo el sistema
cada cierto periodo (se recomienda un día,
máximo una semana)
Pruebas del Sistema
• Asegurar la apropiada navegación dentro
del sistema, ingreso de datos,
procesamiento y recuperación.
• deben enfocarse en requisitos que puedan
ser tomados directamente de casos de uso
y reglas y funciones de negocios
• Ejecute cada caso de uso, flujo básico o
función utilizando datos válidos e inválidos

22/10/2022
Pruebas de Stress
• Verificar que el sistema funciona
apropiadamente y sin errores
• Las pruebas de stress se proponen encontrar
errores debidos a recursos bajos o completitud
de recursos
• Use los scripts utilizados en las pruebas de
desempeño
Pruebas de desempeño
• Validar el tiempo de respuesta para las
transacciones
• Miden tiempos de respuesta, índices de
procesamiento de transacciones y otros
requisitos sensibles al tiempo
• Modifique archivos de datos (para incrementar
el número de transacciones) o los scripts para
incrementar el número de veces que ocurre
cada transacción
Pruebas de carga
• Validar el tiempo de respuesta para las
transacciones
• Miden tiempos de respuesta, índices de
procesamiento de transacciones y otros
requisitos sensibles al tiempo
• Modifique archivos de datos (para incrementar
el número de transacciones) o los scripts para
incrementar el número de veces que ocurre
cada transacción
Pruebas de volumen
• Verificar el tamaño de la BD, el equipo si es
suficiente etc.
• Las pruebas de volumen hacen referencia a
grandes cantidades de datos para determinar
los límites en que se causa que el Sistema
falle
• Deben usarse múltiples clientes, ya sea
corriendo las mismas pruebas o pruebas
complementarias para producir el peor caso
de volumen

22/10/2022
Pruebas de Recuperación y Tolerancia a fallas
• Verificar que los procesos de recuperación
(manual o automática) restauran
apropiadamente la Base de datos
• Estas pruebas aseguran que una aplicación o
sistema se recupere de una variedad de
anomalías de hardware, software o red con
pérdidas de datos o fallas de integridad.
• Se deben utilizar las pruebas creadas para la
Funcionalidad del sistema y Procesos de
Negocios para crear una serie de
transacciones
Prueba de Múltiples Sitios
• Detectar fallas en configuraciones y
comunicaciones de datos entre múltiples sitios
• El propósito de esta prueba es evaluar el
correcto funcionamiento del sistema o
subsistema en múltiples instalaciones.
• Consistencia, empaquetamiento,
sincronización
Prueba de Compatibilidad y Conversión
• Buscar problemas de compatibilidad y
conversión en los sistemas
• El propósito es demostrar que los objetivos de
compatibilidad no han sido logrados y que los
procedimientos de conversión no funcionan.
• Compatibilidad entre programas y Conversión
de datos
Pruebas de Integridad de Datos y Base de
Datos
• Asegurar que los métodos de acceso y
procesos funcionan adecuadamente y sin
ocasionar corrupción de datos.
• La Base de datos y los procesos de Base de
datos deben ser probados como sistemas
separados del proyecto
• Invoque cada método de acceso y proceso de
la Base de datos, utilizando en cada uno datos
válidos e inválidos. Analizar la BD.

22/10/2022
Pruebas de Seguridad y Control de Acceso
• Nivel de seguridad de la aplicación: Verifica
que un actor solo pueda acceder a las
funciones y datos que su usuario tiene
permitido
• Seguridad del sistema, incluyendo acceso a
datos o Funciones de negocios e incluyendo
accesos remotos
• Funciones / Seguridad de Datos: Identificar
cada tipo de usuario y las funciones y datos a
los que se debe autorizar.
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.
• Deberían emular las actividades ejecutadas en
el a través del tiempo. Debería identificarse un
periodo, como por ejemplo un año, y las
transacciones y actividades que podrían
ocurrir durante un periodo
• Ejecute cada caso de uso, flujo básico o
función utilizando datos válidos e inválidos…
Pruebas de GUI
• La navegación, Los objetos de la ventana y
características, tales como menús, medidas,
posiciones, estados y focos
• La prueba de interfaz de usuario verifica la
interacción del usuario con el software
• Pruebas de crear / modificar cada ventana
para verificar la adecuada navegación y
estado de los objetos.
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
• Incluya la apertura o cierre de varias
aplicaciones Microsoft, como Excel y Word (o
algún tipo de software similar a la que se está
probando)

22/10/2022
Prueba de Estilo
• Comprobar que la aplicación sigue los
estándares de estilo propios del cliente.
• Se entienden como tales el formato de las
ventanas, colores corporativos, tipos de letra
etc.
• Se realiza una navegación por la aplicación
verificando si se cumplen con los estándares
de GUI del cliente.
Prueba de Aceptación
• Determinación por parte del cliente de la
aceptación o rechazo del sistema
desarrollado.
• La prueba de aceptación es ejecutada antes
de que la aplicación sea instalada dentro de
un ambiente de producción
• Realización de los documentos de planes de
prueba de aceptación y especificación de los
mismos, basados en los criterios de
aceptación del cliente.
Prueba de Instalación
• Verificar y validar que el sistema se instala
apropiadamente en cada cliente, bajo las
siguientes condiciones: Instalaciones nuevas y
actualizaciones
• El primero es asegurar que el sistema puede
ser instalado en todas las configuraciones
posibles .El segundo propósito verificar que,
una vez instalado, el sistema opera
correctamente.
• Diseñar scripts para validar las condiciones de
la máquina a instalar.
Prueba de Documentación y Procedimiento
• Evaluar la documentación del usuario
• Evaluar la exactitud y claridad de la
documentación del usuario y para determinar
si el manual de procedimientos trabajará
correctamente como una parte integral del
sistema.
• Revisar la documentación del proyecto contra
las funcionalidades del sistema y su
configuración física.

22/10/2022
Pruebas Funcionales
• Se asegura la trabajo apropiado de los
requisitos funcionales, incluyendo la
navegación, entrada de datos, procesamiento
y obtención de resultados
• Las pruebas Funcionales deben enfocarse en
los requisitos funcionales Diseñar scripts para
validar las condiciones de la máquina a
instalar
• Que los resultados esperados ocurran cuando
se usen datos válidos.
Prueba de Usabilidad
• Determinar la usabilidad del sistema.
• Determina cuán bien el usuario podrá usar y
entender la aplicación. Identifica las áreas de
diseño que hacen al sistema de difícil uso para
el usuario.
• Verificar que la aplicación no presenta los
siguientes problemas de usabilidad típicos:
sistema es demasiado complejo ,
recuperación de errores es pobre ,
procedimientos no son simples ni obvios
Prueba de Campo
• Correr el sistema en el ambiente real para
encontrar errores y validar el producto contra
sus especificaciones originales.
• Realizar un subconjunto válido de pruebas de
sistema.
• Determinar que pruebas de sistema serán
corridas para validar el sistema en producción.
Pruebas Alfa
• Prueba de aceptación para detectar errores en
el sistema bajo un ambiente controlado.
• La verificación involucra la ejecución de partes
o todo del sistema en ambientes simulados,
con el fin de encontrar errores.
• Se llevan a cabo en el lugar en donde fue
desarrollado el sistema

22/10/2022
Pruebas Beta
• Realizar la validación del sistema por parte del
usuario.
• Prueba de aceptación donde La validación (o
pruebas beta) involucra el uso del software en
un ambiente real.
• Se selecciona un grupo de usuarios que
ponen a trabajar el sistema en un ambiente
real. Usan el sistema en sus actividades
cotidianas, procesan transacciones y
producen salidas normales del sistema

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
¿Qué es un manual de
procedimientos?
• Es el documento que contiene la
descripción de actividades que deben
seguirse en la realización de
las funciones de un sistema.
• Ejemplo:
– https://www.paho.org/hq/dmdocuments/2015/
2015-manual-sime-instalacion-configuracion-
v1.pdf

22/10/2022
Utilidad
• Permite conocer el funcionamiento interno.
• Auxilian en la inducción del puesto y
al adiestramiento y capacitación del personal.
• Sirve para el análisis o revisión de los
procedimientos de un sistema.
• Uniformar y controlar el cumplimiento de las
rutinas de trabajo y evitar su alteración arbitraria.
• Facilita las labores de auditoria, evaluación
del control interno y su evaluación.
• Ayuda a la coordinación de actividades y evitar
duplicidades.

22/10/2022
Se conforma por:
• A) IDENTIFICACIÓN
– Este documento debe incorporar la siguiente información:
– Logotipo de la organización.
– Nombre oficial de la organización.
– Denominación y extensión. De corresponder a una unidad
en particular debe anotarse el nombre de la misma.
– Lugar y fecha de elaboración.
– Número de revisión.
– Unidades responsables de su elaboración, revisión y/o
autorización.
– Clave de la forma. En primer término, las siglas de la
organización, en segundo lugar las siglas de la unidad
administrativa donde se utiliza la forma y, por último, el
número de la forma. Entre las siglas y el número debe
colocarse un guión o diagonal.

22/10/2022
Se conforma por:
• B) PROLOGO Y/O INTRODUCCIÓN.
– Prologo es la presentación que hace del manual alguna autoridad
de la organización y es del mas alto nivel jerárquico,.
– Introducción es una exposición de lo que es el manual, su
estructura, propósitos, su aplicación y la necesidad de mantenerlo
vigente.
• C) ÍNDICE
– Relación de los capítulos y páginas correspondientes que forman
parte del documento.
• D)CONTENIDO
– Lista de los procedimientos que integran el contenido del manual ya
sea general o específico.
• E) OBJETIVO
– Explicación del propósito que se pretende cumplir con los
procedimientos.

22/10/2022
Se conforma por:
• F) AREAS DE APLICACIÓN Y/O ALCANCE DE LOS
PROCEDIMIENTOS
– Esfera de acción que cubren los procedimientos.
• G) RESPONSABLES
– Unidades administrativas y/o puestos que intervienen en los
procedimientos en cualquiera de sus fases.
• H) POLÍTICAS O NORMAS DE OPERACIÓN
– Criterios o lineamientos generales de acción que se determinan en
forma explícita para facilitar la cobertura de responsabilidad de las
distintas instancias que participaban en los procedimiento.
• I) CONCEPTO.
– Palabras o términos de carácter técnico que se emplean en el
procedimiento.

22/10/2022
Se conforma por:
• J) PROCEDIMIENTO
– Presentación por escrito, en forma narrativa y secuencial, de cada una
de las operaciones que se realizan en un procedimiento, explicando en
qué consisten, cuándo, cómo, dónde, con qué, y cuánto tiempo se
hacen, señalando los responsables de llevarlas a cabo.
• K) DIAGRAMAS DE FLUJO
– Representación gráfica de la sucesión en que se realizan las
operaciones de un procedimiento.
• L) FORMULARIOS O IMPRESOS
– Formas impresas que se utilizan en un procedimiento, las cuales se
intercalan dentro del mismo o se adjuntan como apéndices. En la
descripción de las operaciones que impliquen su uso, debe hacerse
referencia específica de éstas, empleando para ello
números indicadores que permitan asociarlas en forma concreta.
También se pueden adicionar instructivos para su llenado.

22/10/2022
Se conforma por:
• M) GLOSARIO DE TERMINOS.
– Lista de conceptos de carácter técnico relacionados con el
contenido y técnicas de elaboración de los manuales de
procedimientos.

22/10/2022
Manual de Instalación
• Sirve de guía en la instalación del sistema. Para
ello, en primer lugar, deberá especificar los
requerimientos hardware y software necesarios
para el correcto funcionamiento del sistema, para
posteriormente describir cada uno de los pasos
necesarios para la configuración, compilación e
instalación del sistema.
• Además, se deberán incluir las pruebas que se
deberán realizar para asegurar que la instalación
se ha realizado correctamente, así como el
procedimiento de marcha atrás a aplicar en caso
de que no haya resultado exitosa la instalación del
sistema.

22/10/2022
Manual de Actualización
• Tiene como objetivo describir las acciones a
realizar para la correcta actualización del sistema
desde una versión origen hasta una versión
destino.
• Se deberán indicar los parámetros de los
elementos de configuración que deberán
modificarse como consecuencia de la
actualización, así como las acciones a realizar
para la correcta compilación e instalación del
sistema.
• Además, deberá incluir la secuencia de tareas que
hay que realizar en el caso que se quiera
desinstalar y dar marcha atrás a la actualización.

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
¿Qué significa programas ejecutables?
• En informática, un ejecutable o archivo ejecutable,
es tradicionalmente un archivo binario, cuyo
contenido se interpreta por el ordenador como un
programa
• Generalmente, contiene instrucciones en código
máquina de un procesador en concreto, pero
también puede contener bytecode que requiera un
intérprete para ejecutarlo.
• Además, suele contener llamadas a funciones
específicas de un sistema operativo (llamadas al
sistema).

22/10/2022
Archivo ejecutable
• En la mayoría de los sistemas modernos,
un archivo ejecutable contiene mucha
información que no es parte del programa
en sí:
– recursos como textos e imágenes,
– requisitos del entorno de ejecución,
– información simbólica y de depuración,
– o alguna otra información que ayude al
sistema operativo a ejecutar el programa.

22/10/2022
Release
• Una configuración del sistema que se va a
comercializar o entregar al cliente.
• Debe identificarse y almacenarse para
poder recuperarla en cualquier momento.
• La Gestión de Configuración también se
encarga de controlar la gestión e
instalación de Releases.

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
Manual de Usuario
• Objetivo: facilitar la tarea de conocimiento,
uso y aprendizaje del sistema desarrollado.
• Debe contener información acerca de todas
las operaciones básicas que el sistema
ofrece, así como capturas de pantallas útiles
para el seguimiento de la explicación.
• El lenguaje utilizado debe ser lo más
adecuado al perfil del usuario.

22/10/2022
Manual de usuario
• El manual de usuario tiene como objetivo
instruir al usuario en el uso del sistema y la
solución de los problemas que puedan
suceder en la operación.
• Debe contener:
✓Introducción
✓Objetivos del sistema
✓Guía de uso
✓Sección de solución de problemas
✓E-mail o teléfonos de soporte técnico

22/10/2022
Manual de usuario
• Introducción
– Debe contener una pequeña descripción del Sistema.
Como funciona, para que es, quien lo puede utilizar,
etc.
• Objetivos del Sistema
– Trata de enumerar cuales son los propósitos
generales del Sistema, para que fue creado, que es
lo que se intenta solucionar con el.
• Guía de Uso
– Mediante capturas de pantallas, se le hace conocer al
usuario el funcionamiento total del Sistema, para que
es que sirve cada elemento del Sistema, y todo lo
que involucre su manejo.

22/10/2022
Manual de usuario
• Sección de Solución de Problemas
– Es una pequeña sección en la que incluimos de la
manera mas explícita qué problemas o dudas con las
mas comunes que el usuario se puede encontrar y
como es que se solucionan.
• E-mail o teléfonos de soporte técnico
– Aquí solamente ponemos los datos de contacto de la
persona encargada de proveer el soporte técnico al
sistema, ya sea por correo electrónico o por teléfono.

22/10/2022
software.
• Código fuente
• Mantenimiento.

22/10/2022
Ingeniería de Software: Costo de Mantenimiento
Uno de los principales problemas que enfrenta la Ing. de
Software es la alta tasa de costo de mantenimiento que existe
actualmente

22/10/2022
Actividades de Mantenimiento
distribución de actividades de mantenimiento
perfectivas
correctivas
adaptivas
preventivas
• Tipos de Actividades de Mantenimiento:
– correctivas = arreglo de errores !
– adaptativas = modificación por cambios en el ambiente (Ej:
cambian regulaciones del SRI, CPU, SO, etc.)
– perfectivas = modificación por cambios en la especificación, o
agregar nuevas funcionalidades
– preventivas = optimización de la estructura del software
=> Asegurar la
flexibilidad de los
sistemas de software !!

22/10/2022
Objetos de la Gestión de
Configuración del Software
Unidad 1
Final de la unidad

GCSW Unidad1: Objetos de la Gestión de Configuración del Software

Recommandé

Recommandé

Contenu connexe

Similaire à GCSW Unidad1: Objetos de la Gestión de Configuración del Software

Similaire à GCSW Unidad1: Objetos de la Gestión de Configuración del Software (20)

Plus de Franklin Parrales Bravo

Plus de Franklin Parrales Bravo (20)

GCSW Unidad1: Objetos de la Gestión de Configuración del Software