Repaso para el Parcial

Prof. Ramiro Estigarribia Canese

¿Qué son las Pruebas de Software?
Son un conjunto de verificaciones que se realizan en diversos
momentos de la vida del sistema.
 ¿Qué permiten verificar las Pruebas de
Software?
1. El correcto funcionamiento de los componentes del sistema.
2. El funcionamiento del hardware y software en el entorno de
operación. (Sistema Operativo).
3. Que el sistema cumpla con el funcionamiento esperado,
desde el punto de vista de su funcionalidad y rendimiento.
4. Que los cambios sobre un componente, no introduzcan un
comportamiento no deseado en otros. (efectos colaterales).
¿Podemos equivocarnos al programar?
El desarrollo de sistemas implica una serie de actividades en
las que las posibilidades de que aparezca el fallo humano
son enormes.

Debido a la imposibilidad humana de trabajar y comunicarse

de forma perfecta, el desarrollo debe ir acompañado de una
actividad que garantice la calidad.
¿Son importantes las pruebas?
Si, son un elemento crítico para la garantía de calidad.

La creciente percepción del software como un elemento del

sistema y la importancia de los costos asociados a un fallo,
están motivando la creación de pruebas minuciosas y bien
planificadas.

No es raro que una organización emplee entre el 30 y el 40

por ciento del esfuerzo total de un proyecto en las pruebas.
Importancia en casos extremos.
En casos extremos, por ejemplo: control de tráfico aéreo,
pueden costar de tres a cinco veces más que el resto del
proyecto.
¿Las pruebas son destructivas?

Las pruebas son uno de los pasos de la ingeniería que se

pueden ver como destructivo en lugar de constructivo.
➔ Durante las fases de definición y desarrollo, el ingeniero
intenta construir el software de la mejor manera posible.
➔ A continuación, llegan las pruebas. El ingeniero crea una
serie de casos de pruebas que intentan demoler el
software construido.
Mito de la Perfección
Si fuéramos realmente buenos programando, no habría
errores que buscar.

Según el mito: “Existen errores porque somos malos en lo

que hacemos, y si somos malos en lo que hacemos,
deberíamos sentirnos culpables por ello”.

Es falso: Las pruebas son un reconocimiento de la

imperfección humana.
Mito: Ausencia de Defectos
Los resultados que se van recogiendo a medida que se
realizan pruebas proporcionan una buena indicación de la
fiabilidad y la calidad.

Pero esto no puede asegurar la ausencia de defectos; sólo

puede demostrar que existen defectos en el software.
¿En qué consiste una estrategia de prueba
de software?
Una estrategia de prueba del software integra las técnicas de
casos de prueba, en una serie de pasos bien planificados que
dan como resultado una correcta construcción del software.

La estrategia proporciona un mapa que describe los pasos

que hay que llevar a cabo como parte de la prueba, cuándo se
deben planificar y realizar, y cuánto esfuerzo, tiempo y
recursos se van a requerir.
La Estrategia debe ser Flexible
La estrategia debe ser suficientemente flexible para promover
la creatividad y la adaptabilidad necesarias, para adecuarse a
todos los proyectos que serán desarrollados.

Al mismo tiempo, la estrategia debe ser suficientemente

rígida para promover un seguimiento razonable de la
planificación y la gestión a medida que progresa el proyecto.
 El Pasado vs el Presente
Durante muchos años, nuestra única defensa contra los errores
de programación era un cuidadoso diseño y la propia
inteligencia del programador.
Ahora nos encontramos en una era en la que las técnicas
modernas de diseño nos ayudan a reducir el número de errores
iniciales que se encuentran en el código.
De forma similar, los diferentes métodos de prueba están
empezando a agruparse en varias filosofías y enfoques
diferentes.
 ¿Cuál es la estrategia recomendada?
Las pruebas deben comenzar a nivel de módulo y avanzar
«hacia fuera», hacia la integración de todo el sistema.

La estrategia debe incluir pruebas de bajo nivel que verifiquen

todos los pequeños segmentos de código, así como pruebas
de alto nivel que validen las principales funciones del sistema
frente a los requisitos del cliente.

La estrategia debe proporcionar una guía al profesional y un

conjunto de hitos para el jefe de proyecto.
 Verificación y Validación
La prueba del software es un elemento de un tema más amplio
que, a menudo, es conocido como verificación y validación (V&V).

La verificación se refiere al conjunto de actividades que aseguran

que el software implementa correctamente una función
específica.

La validación se refiere a un conjunto diferente de actividades

que aseguran que el software construido se ajusta a los
requisitos del cliente.
 Conflicto de intereses
En muchos casos, se pide a la gente que ha construido el software
que lo pruebe. Parece inofensivo, después de todo:
¿Quién puede conocer mejor a las personas que lo han desarrollado?
Por el contrario, tienen interés en demostrar que:
➔ El programa está libre de errores.
➔ Funciona de acuerdo con las especificaciones.
➔ Cumple con los plazos y el presupuesto asignado.
Cada uno de estos intereses se convierte en dificultad a la hora de
encontrar errores
Punto de vista Psicológico
Desde un punto de vista psicológico, el análisis y el diseño
del software (junto con la codificación) son tareas
constructivas.

El ingeniero del software crea un programa de computadora,

su documentación y sus estructuras de datos asociadas.

Al igual que cualquier constructor,el ingeniero del software

está orgulloso del edificio que acaba de construir y se
enfrenta a cualquiera que intente sacarle defectos.
 Punto de vista Psicológico
Por tanto, el constructor tiende a tener cuidado diseñando y
ejecutando pruebas que demuestren que el programa funciona,
en lugar de detectar errores.

Desgraciadamente, y pese a todo, los errores seguirán estando.

➔ Y si el ingeniero del software no los encuentra, el cliente lo

hará!
El Responsable de Desarrollo
El responsable del desarrollo siempre es responsable de
probar las unidades individuales (módulos) del programa,
asegurándose de que cada una lleva a cabo la función para la
que fue diseñada.

En muchos casos, también se encargará de la prueba de

integración de la estructura total del sistema.

Sólo una vez que la arquitectura del software esté completa

entra en juego un grupo independiente de prueba.
 El Grupo Independiente de Prueba
El papel del grupo independiente de prueba (GIP) es eliminar los
problemas asociados con el hecho de permitir al constructor
que pruebe lo que ha construido.

Una prueba independiente elimina el conflicto de intereses que,

de otro modo, estarían presentes.

Después de todo, al personal del equipo que forma el GIP se le

paga para que encuentre errores. (es su trabajo).
 El Grupo Independiente de Prueba
El Responsable de Desarrollado y el GIP trabajan estrechamente a
lo largo del proyecto para asegurar que se realizan pruebas
exhaustivas.

Mientras se realiza la prueba, el desarrollador debe estar

disponible para corregir los errores que se van descubriendo.

El GIP es parte del equipo de desarrollo en el sentido de que se ve

implicado durante el proceso de especificación y sigue implicado
a lo largo del proyecto.
¿En qué afecta la reutilización,
en las pruebas de software?
El objetivo de las pruebas es encontrar el mayor número
posible de errores con una cantidad razonable de esfuerzo,
aplicado sobre un lapso de tiempo realista.

En el software O.O. gracias a una mayor reutilización de

código, se evita la necesidad de muchas pruebas.

Parece probable que se necesitarán menos pruebas para

obtener una alta fiabilidad en sistemas O.O.
 Nuevos Retos al Ingeniero del Software
La prueba de los sistemas O.O. presentan nuevos retos al
ingeniero del software.

La definición de pruebas debe ser ampliada para incluir

técnicas que descubran errores, aplicadas para el Análisis y el
Diseño Orientado a Objetos.

Las estrategias y tácticas deben tener en cuenta las

características del software O.O.
Análisis Orientado a Objetos
Antes de que pueda construir un sistema orientado a objetos,
se recomienda definir:

1. Las clases que representan el problema a resolver.

2. La forma en que las clases se relacionan e interactúan
unas con otras.
3. El funcionamiento interno (atributos y operaciones) de las
clases y los mecanismos de comunicación (mensajes)
que les permiten trabajar juntos.
¿Por qué es importante el A.O.O.?
No se recomienda construir software hasta que se tenga un
conocimiento razonable del sistema, producto o problema.

El Análisis Orientado a Objetos nos proporciona una forma

concreta de representar el conocimiento de los requisitos y
compararlo con la percepción que el cliente tiene del sistema a
construir.
¿Que permite UML?
UML permite a un ingeniero expresar un modelo de análisis
utilizando una notación de modelado con unas reglas
sintácticas, semánticas y prácticas.

En UML, un sistema viene representado por cinco vistas

diferentes que lo describen desde diferentes perspectivas.

Cada vista se representa mediante un conjunto de

diagramas.
1.Vista del usuario
Representa el sistema (producto) desde la perspectiva de los
actores.

El caso de uso es el enfoque elegido para modelar esta vista.

Esta representación del análisis, describe un escenario de

uso desde la perspectiva del usuario final.

Diagramas: Casos de Uso, Actividades.

Diagrama de Casos de Usos
Representa la forma cómo los usuarios operan con el
sistema. Consta de los siguientes elementos:

1. Actor.
2. Casos de Uso.
3. Relaciones.
Diagrama de Actividades
Permiten demostrar la lógica de un algoritmo. Se usan para
describir las actividades de negocios y la funcionalidad de
los sistemas. Componentes:

Acciones (rectángulo redondeado).

Nodo de decisión (diamante).
Conectores (lineas)
Nodo inicial (circulo negro).
Nodo terminal (círculo negro y blanco).
 2. Vista Estructural
Los datos y la funcionalidad se muestran desde dentro del
sistema, es decir, modela la estructura estática (clases,
objetos y relaciones).
Diagramas: Clases, Secuencia y Colaboración
 3. Vista del Comportamiento
Representa los aspectos dinámicos del sistema.
Muestra las interacciones o colaboraciones entre los diversos
elementos descritos en las vistas anteriores.
El diagrama utilizado es: Diagrama de Estado.

4.Vista de implementación
Los aspectos estructurales y de comportamiento se representan
aquí tal y como van a ser implementados.
El diagrama utilizado es: Diagrama de Componentes.
 5. Vista del Entorno
Diagrama de Despliegue: representa los elementos básicos de
software y hardware del sistema.
Diseño Orientado a Objetos
El diseño orientado a objetos transforma el modelo de
análisis, en un modelo de diseño que sirve como
anteproyecto para la construcción de software.

Se deben identificar los objetos, clasificarlos, definir

jerarquías de herencia y establecer relaciones.

El diseño debe ser específico al problema que se tiene entre

manos, pero suficientemente general para adaptarse a
requerimientos futuros.
 Error durante el Análisis
Si el error permanece sin detectarse durante el Análisis,
y aparece en la etapa de diseño, los siguientes problemas
pueden ocurrir:

1.Localización impropia de la clase a un subsistema y/o

tareas.

2. El trabajo del diseño innecesario tendrá que corregirse.

3. Muchos diagramas serán incorrectos, y tendrán que

corregirse.
 Error durante Analisis y Diseño
Si el error permanece sin detectarse durante el Análisis y
Diseño, y aparece en la actividad de codificación:
➔ Se gastará un esfuerzo considerable para generar el código
que implemente un atributo innecesario, operaciones
innecesarias, mensajes que controlan comunicaciones entre
objetos, y muchos otros aspectos relacionados.
Una vez que se encuentra el error, debe llevarse a cabo la
corrección, con posibles efectos colaterales.
 Ing.del Software vs Otras Ingenierías
Las métricas del software no se basan en las leyes
cuantitativas de la Física y no son exactas.

Las medidas absolutas, tales como la velocidad, el voltaje, o la

temperatura no son comunes en el mundo del software.

En su lugar, intentamos obtener un conjunto de medidas

indirectas que dan lugar a métricas que proporcionan una
indicación de la calidad del software.

Se trata de buscar una aproximación o una idea.

¿Qué es una Métrica?
Es el proceso por el que se asignan números o símbolos a los
atributos de las entidades del mundo real.

En las ciencias físicas, medicina y otras ciencias, somos

ahora capaces de medir atributos que previamente
pensábamos que no eran medibles.

Sentimos que la obligación de intentar "medir lo no medible"

para mejorar nuestra comprensión de entidades particulares
como la ingeniería del software.
 ¿El Software es Medible?
Muchos profesionales del software piensan que el software no es
medible. Esto hoy se considera un error.

La calidad del software es medible y varía de un sistema a otro o de

un programa a otro.

Un software para el control de aviones debe ser confiable al nivel de

"cero fallas"; mientras que un sistema para ser explotado durante 10
años o más, necesita ser confiable, mantenible y flexible para
disminuir los costos de mantenimiento y perfeccionamiento.
 Criterios para Medir la Calidad
1. Los requisitos del software son la base de las medidas de la calidad.
La falta de concordancia con esos requisitos es una falta de calidad.

2. Existen criterios de desarrollo que guían la manera en que se hace la

ingeniería del software. Si no se siguen los criterios, habrá
probablemente poca calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se

nombran (por ejemplo, facilidad de mantenimiento).
Si el software cumple con sus requisitos explícitos pero falla en los
implícitos, la calidad tampoco será fiable.
Factores de la Calidad
 Factores de la Calidad
1. Corrección: Hasta dónde satisface la especificación y logra los
objetivos del cliente.
2. Fiabilidad: Hasta dónde lleva a cabo su función con la exactitud
requerida.
3. Eficiencia: La cantidad de recursos informáticos y de código
necesarios para que un programa realice su función.
4. Integridad: Hasta dónde se puede controlar el acceso al software
o a los datos por personas no autorizadas.
5. Usabilidad: El esfuerzo necesario para aprender a operar.
 Factores de la Calidad
6. Facilidad de mantenimiento: El esfuerzo para localizar y arreglar
un error.
7. Flexibilidad: El esfuerzo para modificar un programa que ya está
en funcionamiento.
8. Portabilidad: El esfuerzo necesario para transferir de un entorno
hardware/software a otro.
9. Reusabilidad: Hasta dónde se puede volver a emplear el
programa (o partes).
10. Interoperatividad: El esfuerzo necesario para acoplar un sistema
con otro.
 Fórmula de Medición de la Calidad
Es difícil desarrollar medidas de los factores de calidad anteriores.

Se definen un conjunto de métricas para evaluar todos los factores

de acuerdo con la siguiente relación:

Fq = c1 * m1 + c2 * m2 + …+ cn * mn

Fq es el factor de calidad del software.

Cn son coeficientes y Mn son puntajes obtenidos.

 ¿Cuánto cobrar por un Sistema?
Muchos programadores cobran según el número de líneas del código
fuente del sistema.
Hoy día se considera un error, ya que existen otros factores: bases de
datos, capacitación, etc.
 ¿Cuánto cobrar por un Sistema?
La recomendación es realizar una o más reuniones con el cliente, de
forma a definir los detalles del proyecto. (captura de requisitos)

Realizar un estimativo de las horas de trabajo que serán necesarias.

Finalmente elaborar un informe detallando cada tarea, los costos y

las horas necesarias, de forma a negociar con el cliente.
¿Qué es la Administración de un Proyecto?
La administración del proyecto involucra planificación,
monitoreo y control del personal, procesos y acciones que
ocurren conforme el software evoluciona desde un concepto
preliminar hasta su despliegue operativo completo.

Construir software es una labor compleja, particularmente si

involucra a muchas personas que trabajan diariamente
durante un tiempo relativamente largo.
Construir Software vs Objetos Físicos
Construir software no es igual que construir un coche porque
el producto final, el software, tiene diferencias con los
productos físicos.
Y obviar estas diferencias implica importantes problemas a la
hora de desarrollar, planificar, gestionar, etc.
 Diferencias en la Construcción
En la ingeniería civil, los planos para construir son exactos.
Y los realizan personas ajenas a la construcción (los arquitectos).
En este caso existen dos actividades claramente diferenciadas: el
diseño y la construcción.
En software es más difícil especificar en una única fase de diseño
todas las cuestiones a tratar en la programación.
¿Qué es la Administración Efectiva?
La administración efectiva se enfoca en cuatro letras P:
1. Personal
2. Producto
3. Proceso
4. Proyecto

Un gerente que no consigue una comunicación comprensiva

con los participantes, se arriesga a construir una solución
elegante para el problema equivocado.
 Importancia del Factor Humano
Es importante brindar buen trato y capacitación constante, ya que
este factor es el que se encarga de desarrollar las distintas tareas.

Existe un modelo de madurez de capacidades del personal

(People-CMM), en reconocimiento de que "toda organización
requiere mejorar continuamente su habilidad para atraer,
desarrollar, motivar, organizar y conservar la fuerza de trabajo
necesaria a fin de lograr sus objetivos empresariales
estratégicos".
 ¿Por qué se planean los Proyectos?
Los proyectos se planean y debido a una razón principal: es la
única forma para manejar la complejidad.
Aunque actualmente la tasa de éxito ha mejorado, la tasa de falla
sigue siendo más alta de lo que debiera.
En un estudio de 250 grandes proyectos de software entre 1998 y
2004, encontraron que 25 se consideraron exitosos por lograr sus
objetivos de calendario, costo y calidad.
50 tuvieron pequeñas demoras y 175 experimentaron grandes
demoras, o no se concluyeron.
 Señales de un Proyecto en Peligro
1. El desarrollador no entiende las necesidades del cliente.
2. El objetivo del producto está pobremente definido.
3. Los cambios se gestionan pobremente.
4. Cambia la tecnología elegida.
5. Las necesidades empresariales cambian en la mitad.
6. Las fechas límite son irreales.
7. Los usuarios son resistentes.
8. Pérdida de patrocinio (o nunca obtenido adecuadamente).
9. El equipo carece de personal capacitado.
10. Los gerentes evitan mejores prácticas.
¿Quiénes son los participantes?
El proceso de software está poblado de participantes:
1. Gerentes ejecutivos: definen los temas empresariales.
2. Gerentes de proyecto (técnicos): deben planificar, motivar y
controlar a los profesionales que hacen el trabajo.
3. Profesionales que aportan las habilidades técnicas.
4. Clientes que especifican los requerimientos.
5. Usuarios finales, quienes interactúan con el software.
* Para ser efectivo, el equipo debe organizarse de manera que
maximice las capacidades de cada persona.
Y ésta es labor del líder del equipo.
 ¿Cómo es un líder de equipo?
La administración del proyecto es una actividad que implica
mucho trato con la gente. Por esta razón, los profesionales
competentes en programación, tienen con frecuencia pobre
desempeño como líderes de equipo.
Simplemente, no tienen la mezcla justa de habilidades personales
y desperdician sus habilidades técnicas.
Por desgracia, los individuos simplemente se topan con el papel
de gerente de proyecto y se convierten en gerentes accidentales
de proyecto.
Objetivos de un Líder de Equipo
1. Motivación. Habilidad para alentar al personal técnico a
producir a su máxima capacidad.
2. Organización. Habilidad para moldear los procesos
existentes (o inventar nuevos) que permitirán que el
concepto inicial se traduzca en un producto final.
3. Ideas o innovación. Habilidad para alentar a las personas
a crear y sentirse creativas, aun cuando deban trabajar
dentro de fronteras establecidas para un producto o
aplicación de software particular.
 1. Pruebas de Software

Link a la presentación Prof. Ramiro Estigarribia Canese

¿Qué son las Pruebas de Software?
Son un conjunto de verificaciones que se realizan en diversos
momentos de la vida del sistema.
 ¿Qué permiten verificar las Pruebas de
Software?
1. El correcto funcionamiento de los componentes del sistema.
2. El funcionamiento del hardware y software en el entorno de
operación. (Sistema Operativo).
3. Que el sistema cumpla con el funcionamiento esperado,
desde el punto de vista de su funcionalidad y rendimiento.
4. Que los cambios sobre un componente, no introduzcan un
comportamiento no deseado en otros. (efectos colaterales).
¿Podemos equivocarnos al programar?
El desarrollo de sistemas implica una serie de actividades en
las que las posibilidades de que aparezca el fallo humano
son enormes.

Debido a la imposibilidad humana de trabajar y comunicarse

de forma perfecta, el desarrollo debe ir acompañado de una
actividad que garantice la calidad.
¿Son importantes las pruebas?
Si, son un elemento crítico para la garantía de calidad.

La creciente percepción del software como un elemento del

sistema y la importancia de los costos asociados a un fallo,
están motivando la creación de pruebas minuciosas y bien
planificadas.

No es raro que una organización emplee entre el 30 y el 40

por ciento del esfuerzo total de un proyecto en las pruebas.
Importancia en casos extremos.
En casos extremos, por ejemplo: control de tráfico aéreo,
pueden costar de tres a cinco veces más que el resto del
proyecto.
¿Las pruebas son destructivas?

Las pruebas son uno de los pasos de la ingeniería que se

pueden ver como destructivo en lugar de constructivo.
➔ Durante las fases de definición y desarrollo, el ingeniero
intenta construir el software de la mejor manera posible.
➔ A continuación, llegan las pruebas. El ingeniero crea una
serie de casos de pruebas que intentan demoler el
software construido.
Mito de la Perfección
Si fuéramos realmente buenos programando, no habría
errores que buscar.

Según el mito: “Existen errores porque somos malos en lo

que hacemos, y si somos malos en lo que hacemos,
deberíamos sentirnos culpables por ello”.

Es falso: Las pruebas son un reconocimiento de la

imperfección humana.
Mito: Ausencia de Defectos
Los resultados que se van recogiendo a medida que se
realizan pruebas proporcionan una buena indicación de la
fiabilidad y la calidad.

Pero esto no puede asegurar la ausencia de defectos; sólo

puede demostrar que existen defectos en el software.
 Facilidad de Prueba
La facilidad de prueba es "la medición del nivel de sencillez" con
la que se puede probar un sistema.
1. Operatividad: Cuando mejor funciona, más eficientemente se
puede probar.
2. Observabilidad: Los estados y variables del sistema están
visibles o se pueden consultar durante la ejecución. (modo
debug).
3. Controlabilidad: Cuando mejor podemos controlar el software
y hardware, más se puede automatizar y optimizar.
 Facilidad de Prueba
4. Capacidad de descomposición: Si el sistema está
construido con módulos independientes, podemos aislar
más rápidamente los problemas.
5. Simplicidad: Cuanto menos haya que probar, más
rápidamente podremos probarlo
6. Estabilidad: Cuanto menos cambios, menos interrupciones
a las pruebas.
7. Facilidad de comprensión: Cuanta más información
tengamos, más inteligentes serán las pruebas.
Atributos de una Buena Prueba
1. Una buena prueba tiene una alta probabilidad de encontrar
un error. El responsable de la prueba debe entender el
software e imaginarse cómo podría fallar.

2. Una buena prueba no debe ser redundante. El tiempo y los

recursos para las pruebas son limitados.

3 . Una buena prueba debería ser la mejor de la cosecha. En

un grupo de pruebas que tienen propósito similar, se deben
seleccionar las mejores.
 Pruebas de Caja Negra
La prueba de caja negra se refiere a las pruebas que se llevan a
cabo sobre la interfaz del software.

Pretenden demostrar que las funciones del software son

operativas, que la entrada se acepta de forma adecuada y que se
produce un resultado correcto.

Una prueba de caja negra examina algunos aspectos del modelo

fundamental del sistema sin tener acceso a la estructura lógica
interna del software. (código fuente, base de datos).
 Pruebas de Caja Blanca
Se basan en el minucioso examen de los detalles
procedimentales. (con acceso al código fuente, base de datos,
etc).

Se comprueban los caminos lógicos del software proponiendo

casos de prueba que ejerciten conjuntos específicos de
condiciones y/o bucles.

Se puede examinar el “estado del programa” en varios puntos para

determinar si el estado real coincide con el esperado.
Caja Negra vs Caja Blanca
A primera vista parecería que una prueba de caja blanca muy
profunda nos llevaría a tener “programas cien por cien
correctos”.

Lastimosamente, incluso para pequeños programas, el

número de caminos lógicos posibles puede ser enorme.
Prueba del Camino Básico
El método del camino básico, propuesto por Tom McCabe,
permite al diseñador de casos de prueba obtener una medida
de la complejidad lógica y usar esa medida como guía para la
definición de un conjunto básico de caminos de ejecución.

Garantizan que durante la prueba se ejecute por lo menos

una vez cada sentencia de programa.

Cualquier representación del diseño procedimental se puede

traducir a un grafo de flujo.
 Prueba del Camino Básico
La complejidad de este grafo depende del
número de caminos independientes de un
programa.

Proporciona un límite superior para el número de

pruebas que se deben realizar para asegurar que
se ejecuta cada sentencia al menos una vez.
Prueba del camino Básico
El grafo permite observar los tres caminos básicos de
ejecución:

Camino 1: 1-2-5-8-9

Camino 2: 1-3-4-5-8-9

Camino 3: 1-3-6-7-8-9

Camino 4: 1-3-6-9
 Complejidad Ciclomática
Es una métrica que proporciona una medición cuantitativa de la
complejidad lógica de un programa.
Define el número de caminos independientes de un programa y
nos da un límite superior para el número de pruebas que se
deben realizar para asegurar que se ejecuta cada sentencia al
menos una vez.
Determina el número de pruebas que se deben realizar para
asegurar que se ejecuta cada sentencia al menos una vez, (if,
else, for, while, etc)
 Complejidad Ciclomática
El grafo permite observar los cuatro caminos básicos posibles:

Camino 1: 1-2-5-8-9

Camino 2: 1-3-4-5-8-9

Camino 3: 1-3-6-7-8-9

Camino 4: 1-3-6-9

En este ejemplo, la complejidad ciclomática = 4.

 Ejemplo, Caja Negra
Consideremos los datos contenidos en una aplicación bancaria.
Este software acepta datos en la siguiente forma:
Código de área: En blanco ó un número de 3 dígitos
Prefijo: Número de 3 dígitos que no comience por 0 ó 1
Contraseña: Valor alfanumérico de 12 dígitos
Órdenes: "Comprobar", "Depositar","Pagar factura", etc.
Los casos de prueba se seleccionan de manera que se ejercite el
mayor número de atributos de cada clase de equivalencia a la vez.
Prueba de Arquitectura cliente/servidor
Representa un desafío significativo para los responsables de las
pruebas.

La naturaleza distribuida de los entornos cliente/servidor, los

aspectos de rendimiento asociados con el proceso de
transacciones, las complejidades de las redes, y la necesidad de
servir a múltiples clientes desde una base de datos centralizada
se combinan todos para hacer las pruebas más difíciles y
costosas que la prueba de aplicaciones individuales.
 Prueba de la Documentación
Los errores en la documentación pueden ser tan destructivos para
la aceptación del programa, como los errores en los datos o en el
código fuente.
Nada es más frustrante que seguir fielmente el manual de usuario
y obtener resultados o comportamientos que no coinciden con los
anticipados por el documento.
Por esta razón, la prueba de la documentación debería ser una
parte importante de cualquier plan de pruebas del software.
Conclusiones
El principal objetivo del diseño de casos de prueba es obtener
un conjunto de pruebas que tengan la mayor probabilidad de
descubrir los defectos del software.

A menudo, los desarrolladores de software experimentados

dicen que «la prueba nunca termina, simplemente se
transfiere de usted (el ingeniero del software) al cliente: Cada
vez que el cliente usa el programa, lleva a cabo una prueba.
 2. Estrategias en las Pruebas

Prof. Ramiro Estigarribia

Link a la presentación
¿En qué consiste una estrategia de prueba
de software?
Una estrategia de prueba del software integra las técnicas de
casos de prueba, en una serie de pasos bien planificados que
dan como resultado una correcta construcción del software.

La estrategia proporciona un mapa que describe los pasos

que hay que llevar a cabo como parte de la prueba, cuándo se
deben planificar y realizar, y cuánto esfuerzo, tiempo y
recursos se van a requerir.
La Estrategia debe ser Flexible
La estrategia debe ser suficientemente flexible para promover
la creatividad y la adaptabilidad necesarias, para adecuarse a
todos los proyectos que serán desarrollados.

Al mismo tiempo, la estrategia debe ser suficientemente

rígida para promover un seguimiento razonable de la
planificación y la gestión a medida que progresa el proyecto.
 El Pasado vs el Presente
Durante muchos años, nuestra única defensa contra los errores
de programación era un cuidadoso diseño y la propia
inteligencia del programador.
Ahora nos encontramos en una era en la que las técnicas
modernas de diseño nos ayudan a reducir el número de errores
iniciales que se encuentran en el código.
De forma similar, los diferentes métodos de prueba están
empezando a agruparse en varias filosofías y enfoques
diferentes.
 ¿Cuál es la estrategia recomendada?
Las pruebas deben comenzar a nivel de módulo y avanzar
«hacia fuera», hacia la integración de todo el sistema.

La estrategia debe incluir pruebas de bajo nivel que verifiquen

todos los pequeños segmentos de código, así como pruebas
de alto nivel que validen las principales funciones del sistema
frente a los requisitos del cliente.

La estrategia debe proporcionar una guía al profesional y un

conjunto de hitos para el jefe de proyecto.
 Verificación y Validación
La prueba del software es un elemento de un tema más amplio
que, a menudo, es conocido como verificación y validación (V&V).

La verificación se refiere al conjunto de actividades que aseguran

que el software implementa correctamente una función
específica.

La validación se refiere a un conjunto diferente de actividades

que aseguran que el software construido se ajusta a los
requisitos del cliente.
 Conflicto de intereses
En muchos casos, se pide a la gente que ha construido el software
que lo pruebe. Parece inofensivo, después de todo:
¿Quién puede conocer mejor que las personas que han desarrollado?
Por el contrario, tienen interés en demostrar que:
➔ El programa está libre de errores.
➔ Funciona de acuerdo con las especificaciones.
➔ Cumple con los plazos y el presupuesto asignado.
Cada uno de estos intereses se convierte en dificultad a la hora de
encontrar errores
Punto de vista Psicológico
Desde un punto de vista psicológico, el análisis y el diseño
del software (junto con la codificación) son tareas
constructivas.

El ingeniero del software crea un programa de computadora,

su documentación y sus estructuras de datos asociadas.

Al igual que cualquier constructor,el ingeniero del software

está orgulloso del edificio que acaba de construir y se
enfrenta a cualquiera que intente sacarle defectos.
 Punto de vista Psicológico
Por tanto, el constructor tiende a tener cuidado diseñando y
ejecutando pruebas que demuestren que el programa funciona,
en lugar de detectar errores.

Desgraciadamente, y pese a todo, los errores seguirán estando.

➔ Y si el ingeniero del software no los encuentra, el cliente lo

hará!
El Responsable de Desarrollo
El responsable del desarrollo siempre es responsable de
probar las unidades individuales (módulos) del programa,
asegurándose de que cada una lleva a cabo la función para la
que fue diseñada.

En muchos casos, también se encargará de la prueba de

integración de la estructura total del sistema.

Sólo una vez que la arquitectura del software esté completa

entra en juego un grupo independiente de prueba.
 El Grupo Independiente de Prueba
El papel del grupo independiente de prueba (GIP) es eliminar los
problemas asociados con el hecho de permitir al constructor
que pruebe lo que ha construido.

Una prueba independiente elimina el conflicto de intereses que,

de otro modo, estarían presentes.

Después de todo, al personal del equipo que forma el GIP se le

paga para que encuentre errores. (es su trabajo).
 El Grupo Independiente de Prueba
El Responsable de Desarrollado y el GIP trabajan estrechamente a
lo largo del proyecto para asegurar que se realizan pruebas
exhaustivas.

Mientras se realiza la prueba, el desarrollador debe estar

disponible para corregir los errores que se van descubriendo.

El GIP es parte del equipo de desarrollo en el sentido de que se ve

implicado durante el proceso de especificación y sigue implicado
a lo largo del proyecto.
Criterios para completar las pruebas
Cada vez que se tratan las pruebas del software surgen unas
pregunta clásicas:

➔ ¿Cuándo hemos terminado las pruebas?

➔ ¿Cómo sabemos que hemos probado lo suficiente?

Desgraciadamente, no hay una respuesta definitiva a esta

pregunta, pero hay algunas respuestas prácticas y nuevos
intentos de base empírica.
¿Hasta cuándo debemos probar?
Una respuesta políticamente correcta es:

La etapa de pruebas nunca termina, ya que el responsable del

desarrollo del software pasa el problema al cliente.

Cada vez que el cliente/usuario ejecuta un programa, dicho

programa se está probando con un nuevo conjunto de datos.

Llega un momento en que el número de errores disminuye.

 Determinar fallos esperados
La intensidad de fallos en cada instante, I(t) se puede obtener
mediante la derivada de f(t): l(t) = lo / (lo p * t + 1)

Mediante la ecuación, se puede predecir la disminución de

errores a medida que avanza la prueba.
 Prueba de Unidad
La prueba de unidad centra el proceso de verificación en la
menor unidad del diseño del software: el componente software
o módulo.

Se examinan las estructuras de datos locales para asegurar

que los datos conservan su integridad durante todos los pasos
de ejecución del algoritmo.

Se prueban las condiciones límite para asegurar que el módulo

funciona correctamente en los límites definidos.
 Prueba de Integración
Una vez que se les ha hecho la prueba de unidad a todos los
módulos, se puede cuestionar lo siguiente:

Si todos funcionan bien por separado, ¿por qué dudar de que

funcionen todos juntos?

Por supuesto, el problema es «ponerlos juntos» (interacción).

 Prueba de Integración
➔ Los datos se pueden perder en una interfaz.
➔ Un módulo puede tener un efecto adverso e inadvertido sobre
otro.
➔ Las subfunciones, cuando se combinan, pueden no producir la
función principal deseada.
➔ La imprecisión aceptada individualmente puede crecer hasta
niveles inaceptables.
➔ Las estructuras de datos globales pueden presentar problemas.
➔ El sistema puede no estar preparado para recibir una gran
cantidad de datos en simultáneo.
 Etapas Alfa y Beta
Es virtualmente imposible que un desarrollador de software
pueda prever cómo utilizará el usuario realmente el programa.

Se pueden malinterpretar las instrucciones de uso, se pueden

utilizar habitualmente extrañas combinaciones de datos.

La mayoría de los constructores de software llevan a cabo un

proceso denominado pruebas alfa y beta para descubrir errores
que parezca que sólo el usuario final puede descubrir.
¿Qué es la Prueba Alfa?
La prueba alfa se lleva a cabo en el lugar de desarrollo pero
por un cliente.

Se usa el software de forma natural con el desarrollador

como observador del usuario y registrando los errores y los
problemas de uso.

Las pruebas alfa se llevan a cabo en un entorno controlado.

 ¿Qué es la Prueba Beta?
La prueba beta se lleva a cabo por los usuarios finales y en los
lugares de trabajo.

A diferencia de la prueba alfa, el desarrollador no está presente.

La prueba beta es una aplicación «en vivo» del software en un

entorno que no puede ser controlado por el desarrollador.

El cliente registra todos los problemas (reales o imaginarios)

que encuentra durante la prueba beta e informa a intervalos
regulares al desarrollador.
Ubuntu 16.04 - Calendario 2016
Lectura recomendada
http://www.pmoinformatica.com/2017/02/pruebas-de-caja-n
egra-ejemplos.html
 3. Prueba en Aplicaciones
Orientadas a Objetos

Link a la presentación Prof. Ramiro Estigarribia Canese

¿En qué afecta la reutilización,
en las pruebas de software?
El objetivo de las pruebas es encontrar el mayor número
posible de errores con una cantidad razonable de esfuerzo,
aplicado sobre un lapso de tiempo realista.

En el software O.O. gracias a una mayor reutilización de

código, se evita la necesidad de muchas pruebas.

Parece probable que se necesitarán menos pruebas para

obtener una alta fiabilidad en sistemas O.O.
 Nuevos Retos al Ingeniero del Software
La prueba de los sistemas O.O. presentan nuevos retos al
ingeniero del software.

La definición de pruebas debe ser ampliada para incluir

técnicas que descubran errores, aplicadas para el Análisis y el
Diseño Orientado a Objetos.

Las estrategias y tácticas deben tener en cuenta las

características del software O.O.
Análisis Orientado a Objetos
Antes de que pueda construir un sistema orientado a objetos,
se recomienda definir:

1. Las clases que representan el problema a resolver.

2. La forma en que las clases se relacionan e interactúan
unas con otras.
3. El funcionamiento interno (atributos y operaciones) de las
clases y los mecanismos de comunicación (mensajes)
que les permiten trabajar juntos.
¿Por qué es importante el A.O.O.?
No se recomienda construir software hasta que se tenga un
conocimiento razonable del sistema, producto o problema.

El Análisis Orientado a Objetos nos proporciona una forma

concreta de representar el conocimiento de los requisitos y
compararlo con la percepción que el cliente tiene del sistema a
construir.
¿Que permite UML?
UML permite a un ingeniero expresar un modelo de análisis
utilizando una notación de modelado con unas reglas
sintácticas, semánticas y prácticas.

En UML, un sistema viene representado por cinco vistas

diferentes que lo describen desde diferentes perspectivas.

Cada vista se representa mediante un conjunto de

diagramas.
1.Vista del usuario
Representa el sistema (producto) desde la perspectiva de los
actores.

El caso de uso es el enfoque elegido para modelar esta vista.

Esta representación del análisis, describe un escenario de

uso desde la perspectiva del usuario final.

Diagramas: Casos de Uso, Actividades.

Diagrama de Casos de Usos
Representa la forma cómo los usuarios operan con el
sistema. Consta de los siguientes elementos:

1. Actor.
2. Casos de Uso.
3. Relaciones.
Diagrama de Actividades
Permiten demostrar la lógica de un algoritmo. Se usan para
describir las actividades de negocios y la funcionalidad de
los sistemas. Componentes:

Acciones (rectángulo redondeado).

Nodo de decisión (diamante).
Conectores (lineas)
Nodo inicial (circulo negro).
Nodo terminal (círculo negro y blanco).
 2. Vista Estructural
Los datos y la funcionalidad se muestran desde dentro del
sistema, es decir, modela la estructura estática (clases,
objetos y relaciones).
Diagramas: Clases, Secuencia y Colaboración
 3. Vista del Comportamiento
Representa los aspectos dinámicos del sistema.
Muestra las interacciones o colaboraciones entre los diversos
elementos descritos en las vistas anteriores.
El diagrama utilizado es: Diagrama de Estado.

4.Vista de implementación
Los aspectos estructurales y de comportamiento se representan
aquí tal y como van a ser implementados.
El diagrama utilizado es: Diagrama de Componentes.
 5. Vista del Entorno
Diagrama de Despliegue: representa los elementos básicos de
software y hardware del sistema.
Diseño Orientado a Objetos
El diseño orientado a objetos transforma el modelo de
análisis, en un modelo de diseño que sirve como
anteproyecto para la construcción de software.

Se deben identificar los objetos, clasificarlos, definir

jerarquías de herencia y establecer relaciones.

El diseño debe ser específico al problema que se tiene entre

manos, pero suficientemente general para adaptarse a
requerimientos futuros.
 Error durante el Análisis
Si el error permanece sin detectarse durante el Análisis,
y aparece en la etapa de diseño, los siguientes problemas
pueden ocurrir:

1.Localización impropia de la clase a un subsistema y/o

tareas.

2. El trabajo del diseño innecesario tendrá que corregirse.

3. Muchos diagramas serán incorrectos, y tendrán que

corregirse.
 Error durante Analisis y Diseño
Si el error permanece sin detectarse durante el Análisis y
Diseño, y aparece en la actividad de codificación:
➔ Se gastará un esfuerzo considerable para generar el código
que implemente un atributo innecesario, operaciones
innecesarias, mensajes que controlan comunicaciones entre
objetos, y muchos otros aspectos relacionados.
Una vez que se encuentra el error, debe llevarse a cabo la
corrección, con posibles efectos colaterales.
Revisiones Técnicas Formales
Son revisiones de la documentación, que se aplican en
diversos momentos del desarrollo para detectar defectos.

La realización de revisiones periódicas permiten:

1. Obtener alertas tempranas sobre potenciales riesgos y

problemas de calidad.
2. Reducir los tiempos de desarrollo al evitar re-trabajos.
3. Generar estándares para los distintos ciclos de desarrollo.
 Estrategia Clásica de Pruebas
La estrategia clásica comienza con «probar lo pequeño» y si
funciona avanzar.
Se comienza con las de unidad, luego las de integración y
finalmente con las de validación.
Prueba de Unidad
Cuando se considera el software orientado a objetos, el
concepto de unidad cambia.

En vez de probar un módulo individual, la unidad más

pequeña es la clase.

Cada clase envuelve atributos (datos) y operaciones, que

manipulan estos datos.
Prueba de Integración
Existen dos estrategias:
1. La estrategia basada en hilos integra el conjunto de clases,
que colaboran para responder a una entrada o suceso.
Cada hilo se prueba individualmente.

2. La estrategia basada en el uso: Se comienza con las clases

más independientes, que interactúan muy poco. Luego se
avanza con las demás hasta terminar.
Prueba de Validación
Los detalles de conexiones de clases desaparecen.
La validación del software se centra en las acciones visibles
al usuario y en las salidas.

Para la construcción de las pruebas de validación, el

probador debe utilizar los casos de uso.

Los casos de uso proporcionan un escenario, que tiene una

gran similitud de errores con los revelados en los requisitos
de interacción del usuario.
 Diseño de Casos de Prueba
Una aproximación global al diseño de casos de prueba O.O. ha
sido definida por Bernard:
1. Cada caso de prueba debe ser identificado y asociado con la
clase a probar.
2. Debe declararse el propósito de la prueba.
3 . Debe desarrollarse una lista de pasos a seguir:
➔ lista de estados de los objetos
➔ lista de mensajes y operaciones
➔ lista de excepciones
➔ lista de condiciones externas (cambios de HW)
Conclusiones
El objetivo de la verificación orientada a objetos es encontrar
el máximo número de errores con un mínimo de esfuerzo.
Es idéntico al objetivo de prueba del software convencional.

Las estrategias y tácticas difieren de forma significativa.

La visión de verificación se amplía, para incluir la revisión de
ambos modelos de diseño y de análisis O.O.
 4. Métricas del Producto

Link a la presentación Prof. Ramiro Estigarribia

Importancia de las Métricas
Un elemento clave de cualquier proceso de Ingeniería es la
medición.

Empleamos medidas para entender mejor los atributos de los

modelos que creamos.

Pero, fundamentalmente, empleamos las medidas para

valorar la calidad de los productos de ingeniería o de los
sistemas que construimos.
 Ing.del Software vs Otras Ingenierías
Las métricas del software no se basan en las leyes
cuantitativas de la Física y no son exactas.

Las medidas absolutas, tales como la velocidad, el voltaje, o la

temperatura no son comunes en el mundo del software.

En su lugar, intentamos obtener un conjunto de medidas

indirectas que dan lugar a métricas que proporcionan una
indicación de la calidad del software.

Se trata de buscar una aproximación o una idea.

¿Qué es una Métrica?
Es el proceso por el que se asignan números o símbolos a los
atributos de las entidades del mundo real.

En las ciencias físicas, medicina y otras ciencias, somos

ahora capaces de medir atributos que previamente
pensábamos que no eran medibles.

Sentimos que la obligación de intentar "medir lo no medible"

para mejorar nuestra comprensión de entidades particulares
como la ingeniería del software.
 ¿El Software es Medible?
Muchos profesionales del software piensan que el software no es
medible. Esto hoy se considera un error.

La calidad del software es medible y varía de un sistema a otro o de

un programa a otro.

Un software para el control de aviones debe ser confiable al nivel de

"cero fallas"; mientras que un sistema para ser explotado durante 10
años o más, necesita ser confiable, mantenible y flexible para
disminuir los costos de mantenimiento y perfeccionamiento.
 Criterios para Medir la Calidad
1. Los requisitos del software son la base de las medidas de la calidad.
La falta de concordancia con esos requisitos es una falta de calidad.

2. Existen criterios de desarrollo que guían la manera en que se hace la

ingeniería del software. Si no se siguen los criterios, habrá
probablemente poca calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se

nombran (por ejemplo, facilidad de mantenimiento).
Si el software cumple con sus requisitos explícitos pero falla en los
implícitos, la calidad tampoco será fiable.
Factores de la Calidad
 Factores de la Calidad
1. Corrección: Hasta dónde satisface la especificación y logra los
objetivos del cliente.
2. Fiabilidad: Hasta dónde lleva a cabo su función con la exactitud
requerida.
3. Eficiencia: La cantidad de recursos informáticos y de código
necesarios para que un programa realice su función.
4. Integridad: Hasta dónde se puede controlar el acceso al software
o a los datos por personas no autorizadas.
5. Usabilidad: El esfuerzo necesario para aprender a operar.
 Factores de la Calidad
6. Facilidad de mantenimiento: El esfuerzo para localizar y arreglar
un error.
7. Flexibilidad: El esfuerzo para modificar un programa que ya está
en funcionamiento.
8. Portabilidad: El esfuerzo necesario para transferir de un entorno
hardware/software a otro.
9. Reusabilidad: Hasta dónde se puede volver a emplear el
programa (o partes).
10. Interoperatividad: El esfuerzo necesario para acoplar un sistema
con otro.
 Fórmula de Medición de la Calidad
Es difícil desarrollar medidas de los factores de calidad anteriores.

Se definen un conjunto de métricas para evaluar todos los factores

de acuerdo con la siguiente relación:

Fq = c1 * m1 + c2 * m2 + …+ cn * mn

Fq es el factor de calidad del software.

Cn son coeficientes y Mn son puntajes obtenidos.

Métricas de Fenton
Fenton sugiere métricas que permiten comparar diferentes
arquitecturas de programa mediante un conjunto de variables.
Tamaño de la Arquitectura = n + a
n: número de nodos (módulos)
a: número de arcos (líneas de control)
Métricas de Fenton
Profundidad = es el camino más largo desde el nodo raíz.
En el ejemplo: Profundidad =4

Anchura = es el máximo número de nodos de cualquier fila de

la arquitectura. En el ejemplo: Anchura = 6

Relación arco/nodo, R = a/n

Mide la conectividad y el acoplamiento.
R = 18/17 = 1,06.
Métricas de Código Fuente
Se usan un conjunto de medidas primitivas que pueden
obtenerse una vez que se ha generado el código fuente.

Estas medidas se listan a continuación:

n1: número de operadores diferentes

n2: número de variables diferentes

N1: el número total de veces que aparece el operador

N2: el número total de veces que aparece la variable

Métricas de Código Fuente
El investigador Halstead definió las siguiente fórmulas:
Largo del Programa: N = N1 + N2
Tamaño del Vocabulario del programa: n = n1 + n2
Volumen del Programa: V = N * log2(n)
Nivel de Dificultad: D = (n1/2) * (N2/n2)
Nivel de Programa: L = 1/D
Esfuerzo de Implementación: E = V*D
Tiempo de Entendimiento: T = E/18
 Métricas de Mantenimiento
El estándar IEEE 982.1-1988 sugiere un índice de madurez del software
(IMS) que proporciona una indicación de la estabilidad del producto.

Mr = número de módulos en la versión actual

Fc = número de módulos que se han modificado
Fa = número de módulos que se han añadido
Fd = número de módulos que se han eliminado.

El índice de madurez del software se calcula así:

IMS = [Mr – (Fa + Fc + Fd)] / Mr

Si IMS se aproxima a 1 se considera estable.
 ¿Cuánto cobrar por un Sistema?
Muchos programadores cobran según el número de líneas del código
fuente del sistema.
Hoy día se considera un error, ya que existen otros factores: bases de
datos, capacitación, etc.
 ¿Cuánto cobrar por un Sistema?
La recomendación es realizar una o más reuniones con el cliente, de
forma a definir los detalles del proyecto. (captura de requisitos)

Realizar un estimativo de las horas de trabajo que serán necesarias.

Finalmente elaborar un informe detallando cada tarea, los costos y

las horas necesarias, de forma a negociar con el cliente.
Conclusiones
Las métricas intentan obtener una manera cuantitativa de
valorar la calidad del software.

Para que sea útil en el contexto del mundo real, una métrica
debe ser simple, calculable, consistente y objetiva.

Debería ser independiente del lenguaje de programación y

proporcionar una retroalimentación eficaz para el
desarrollador de software.
 Conclusiones
Sin bien cada día podremos acercarnos más a una métrica exacta, en la
medida en que los métodos de programación evolucionan, se necesitará
replantear todo.

Y este ciclo repetitivo de cambios, no parece acabar, al menos mientras

dure la era de la tecnología.

Lecturas Recomendadas:

https://blog.innevo.com/metricas-de-calidad-del-software

Capítulo 23 del libro de Pressman.

 5. Administración de Proyectos

Link a la presentación Prof. Ramiro Estigarribia Canese

¿Qué es la Administración de un Proyecto?
La administración del proyecto involucra planificación,
monitoreo y control del personal, procesos y acciones que
ocurren conforme el software evoluciona desde un concepto
preliminar hasta su despliegue operativo completo.

Construir software es una labor compleja, particularmente si

involucra a muchas personas que trabajan diariamente
durante un tiempo relativamente largo.
Construir Software vs Objetos Físicos
Construir software no es igual que construir un coche porque
el producto final, el software, tiene diferencias con los
productos físicos.
Y obviar estas diferencias implica importantes problemas a la
hora de desarrollar, planificar, gestionar, etc.
 Diferencias en la Construcción
En la ingeniería civil, los planos para construir son exactos.
Y los realizan personas ajenas a la construcción (los arquitectos).
En este caso existen dos actividades claramente diferenciadas: el
diseño y la construcción.
En software es más difícil especificar en una única fase de diseño
todas las cuestiones a tratar en la programación.
¿Qué es la Administración Efectiva?
La administración efectiva se enfoca en cuatro letras P:
1. Personal
2. Producto
3. Proceso
4. Proyecto

Un gerente que no consigue una comunicación comprensiva

con los participantes, se arriesga a construir una solución
elegante para el problema equivocado.
 Importancia del Factor Humano
Es importante brindar buen trato y capacitación constante, ya que
este factor es el que se encarga de desarrollar las distintas tareas.

Existe un modelo de madurez de capacidades del personal

(People-CMM), en reconocimiento de que "toda organización
requiere mejorar continuamente su habilidad para atraer,
desarrollar, motivar, organizar y conservar la fuerza de trabajo
necesaria a fin de lograr sus objetivos empresariales
estratégicos".
 El modelo: People CMM
El People-CMM define áreas para el personal de software:
comunicación, ambiente de trabajo, desempeño administrativo,
capacitación, compensación, análisis y desarrollo de
competencias, desarrollo profesional, desarrollo de grupo de
trabajo y desarrollo de equipo/cultura.

Las organizaciones que conforme a este modelo logran altos

niveles de madurez, tienen una probabilidad muy elevada de
alcanzar prácticas efectivas en los proyectos de software.
 ¿Por qué se planean los Proyectos?
Los proyectos se planean y debido a una razón principal: es la
única forma para manejar la complejidad.
Aunque actualmente la tasa de éxito ha mejorado, la tasa de falla
sigue siendo más alta de lo que debiera.
En un estudio de 250 grandes proyectos de software entre 1998 y
2004, encontraron que 25 se consideraron exitosos por lograr sus
objetivos de calendario, costo y calidad.
50 tuvieron pequeñas demoras y 175 experimentaron grandes
demoras, o no se concluyeron.
 Señales de un Proyecto en Peligro
1. El desarrollador no entiende las necesidades del cliente.
2. El objetivo del producto está pobremente definido.
3. Los cambios se gestionan pobremente.
4. Cambia la tecnología elegida.
5. Las necesidades empresariales cambian en la mitad.
6. Las fechas límite son irreales.
7. Los usuarios son resistentes.
8. Pérdida de patrocinio (o nunca obtenido adecuadamente).
9. El equipo carece de personal capacitado.
10. Los gerentes evitan mejores prácticas.
¿Quiénes son los participantes?
El proceso de software está poblado de participantes:
1. Gerentes ejecutivos: definen los temas empresariales.
2. Gerentes de proyecto (técnicos): deben planificar, motivar y
controlar a los profesionales que hacen el trabajo.
3. Profesionales que aportan las habilidades técnicas.
4. Clientes que especifican los requerimientos.
5. Usuarios finales, quienes interactúan con el software.
* Para ser efectivo, el equipo debe organizarse de manera que
maximice las capacidades de cada persona.
Y ésta es labor del líder del equipo.
 ¿Cómo es un líder de equipo?
La administración del proyecto es una actividad que implica
mucho trato con la gente. Por esta razón, los profesionales
competentes en programación, tienen con frecuencia pobre
desempeño como líderes de equipo.
Simplemente, no tienen la mezcla justa de habilidades personales
y desperdician sus habilidades técnicas.
Por desgracia, los individuos simplemente se topan con el papel
de gerente de proyecto y se convierten en gerentes accidentales
de proyecto.
Objetivos de un Líder de Equipo
1. Motivación. Habilidad para alentar al personal técnico a
producir a su máxima capacidad.
2. Organización. Habilidad para moldear los procesos
existentes (o inventar nuevos) que permitirán que el
concepto inicial se traduzca en un producto final.
3. Ideas o innovación. Habilidad para alentar a las personas
a crear y sentirse creativas, aun cuando deban trabajar
dentro de fronteras establecidas para un producto o
aplicación de software particular.
Equipos Ágiles
El desarrollo de software ágil se ha sugerido como antídoto a
muchos de los problemas que plagan el trabajo en un
proyecto de software.

La filosofía ágil alienta la satisfacción del cliente y la entrega

incremental temprana del software, así como pequeños
equipos de proyecto enormemente motivados, métodos
informales, mínimos productos operativos de ingeniería de
software y simplicidad de desarrollo global.
 EL PRINCIPIO W5HH
1. ¿Por qué (why) se desarrollará el sistema?
2. ¿Qué (what) se hará? Defina el conjunto de tareas requeridas.
3. ¿Cuándo (when) se hará? El equipo establece un calendario de
proyecto al identificar cuándo se realizarán las tareas del
proyecto y cuándo se alcanzarán los hitos.
4. ¿Quién (who) es responsable de cada función?
5. ¿Dónde (where) se ubicará en la organización?
6. ¿Cómo (how) se hará el trabajo?
7. ¿Cuánto (how much) se necesita de cada recurso?
 Conclusiones
La administración de proyectos de software es una actividad
clave dentro de la ingeniería de software.
Comienza antes de iniciar cualquier actividad técnica y continúa a
lo largo del modelado, construcción y despliegue del software.
El personal debe organizarse en equipos para hacer trabajo de
alta calidad, y coordinarse para lograr comunicación efectiva.

Lectura Recomendada: Capítulo 24 de Pressman. (5ta edición)

 6. Estimación para Proyectos
de Software

Link a la presentación Prof.Ramiro Estigarribia Canese

¿Qué es la Estimación en Proyectos de Software?

Es el intento por determinar cuánto dinero, esfuerzo, recursos

y tiempo tomará construir una aplicación.

Antes de que el proyecto pueda comenzar, el equipo de

software debe estimar el trabajo que se va a realizar.

Se debe establecer un calendario que defina las tareas, el

responsable de cada tarea y las dependencias que puedan
imponer una demora.
Actividades a Estimar
1. Determinar cantidad de código a escribir.
2. Estimar horas hombre.
3. Estimar tiempo total.
4. Establecer plazo de entrega.
5. Determinar el personal involucrado.
6. Estimar el costo total.
¿Vale la pena Planificar?
La planificación es necesaria para resolver problemas
tempranos a bajo costo, en lugar de tardíos a alto costo.

Muchos expertos prefieren realizar directamente el trabajo

técnico en lugar de pasar tiempo planificando/estimando.

Pero fallar en la planificación es uno de los errores más

cruciales que un proyecto puede tener.
Actividades de Planificación
La planificación de proyectos de software abarca cinco
grandes actividades:
1. Estimación
2. Calendarización
3. Análisis de riesgos
4. Planificación de gestión de la calidad
5. Planificación de gestión del cambio.
¿Quién debe estimar un proyecto?
Debe ser un profesional que no tenga ningún interés directo o
indirecto, en los resultados del proceso de estimación, y que
esté únicamente guiado por su profesionalismo.

El objetivo del estimador, es obtener estimaciones de calidad,

las cuales no siempre tienen que coincidir con las
expectativas de los participantes.
Requisitos para el Estimador
1. Formación y experiencia profesional adecuada.
2. Una posición en la organización que le permita adoptar un
juicio independiente.
3. Debe basarse en un método que pueda ser explicado,
cuestionado, discutido y auditado.
4. Debe poder describir su experiencia en cada estimación.
5. Debe documentar su estimación, incluyendo cualquier
información necesaria para hacer el proceso de
estimación repetible y verificable.
¿Qué es el Compromiso Inicial?
Siempre que se hacen estimaciones se mira hacia el futuro y
se acepta cierto grado de incertidumbre.
La planificación requiere adoptar un compromiso inicial, aún
cuando resulte erróneo.
Aunque las estimaciones son tanto un arte como una ciencia,
no debe hacerse al azar.
Las experiencias pasadas (de todas las personas
involucradas) proporcionan una perspectiva histórica para la
generación de estimaciones.
Complejidad del Proyecto
La estimación de recursos y calendario requiere experiencia,
acceso a buena información histórica y coraje para
comprometerse con las predicciones.

La complejidad del proyecto influye en la incertidumbre y

también la familiaridad con el esfuerzo pasado.

➔ El que por primera vez desarrolla una WebApp de

e-commerce puede considerar el trabajo muy complejo.
➔ En cambio, un equipo que desarrolla su décima WebApp
considerará tal trabajo común y corriente.
Tamaño del Proyecto
El tamaño del proyecto es otro factor importante que puede
afectar la precisión y la eficacia de las estimaciones.

Conforme aumenta el tamaño, la interdependencia entre

varios elementos del software crece rápidamente.

La ley de Murphy: “lo que puede salir mal, saldrá mal”, y si hay
más cosas que pueden fallar, más cosas fallarán.
Técnicas de Estimación
1. La opinión de los expertos: se basa en la experiencia
profesional de los participantes de la estimación.
2. La analogía: Se basa en la comparación directa de uno o
más proyectos pasados.
Para poder utilizar esta técnica es necesario disponer de
una base de datos histórica de proyectos finalizados con
la que poder realizar la comparación.
Emular el Pasado
La disponibilidad de información histórica tiene fuerte
influencia sobre el riesgo de estimación.

Al mirar hacia atrás, puede emular las cosas que funcionaron

y mejorar las áreas donde surgieron problemas.

Como planificador, usted y el cliente deben reconocer que la

variabilidad en los requisitos del software significa
inestabilidad en costo y calendario.
El Objetivo de la Planificación
El objetivo es proporcionar un marco conceptual que permita
al gerente hacer estimaciones razonables de recursos, costo
y calendario.

Además, las estimaciones deben intentar definir los

escenarios de mejor y peor caso, de modo que los resultados
del proyecto puedan acotarse.

El plan puede adaptarse y actualizarse conforme avanza el

proyecto.
Conclusiones
A diferencia de los productos físicos, la producción de
software requiere de mucha comunicación entre los
participantes, por lo que hay un mayor grado de subjetividad.

La dificultad que se impone para estimar no deja que esta

sea una actividad trivial a la que no se considere importante.

Muchos de los procesos fracasan por no realizar con

seriedad esta actividad.
 Ingeniería WEB

Prof. Ramiro Estigarribia

Link a la presentación
¿Qué son las WebApps?
Son herramientas que se pueden utilizar accediendo a un
servidor web a través de Internet.

Necesitan un navegador para funcionar; por lo tanto, al no

requerir de una descarga desde cualquier tienda de
aplicaciones (PlayStore, App Store, etc), no ocupará espacio
de memoria adicional en los dispositivos.
Ventajas de implementar WebApps
1. Se Ahorra tiempo: Se pueden realizar tareas sin necesidad
de instalar ningún programa.
2. No hay problemas de compatibilidad: Basta tener un
navegador actualizado para poder utilizarlas.
3. No ocupan espacio adicional en el disco.
4. Las actualizaciones inmediatas, siempre se ejecuta la
última versión al abrir la aplicación.
Desventajas de implementar WebApps
1. Su uso requiere de conexión a internet.
2. Al ser ejecutada en un navegador web puede tener ciertas
limitaciones: permisos, dificultad acceder a propiedades
del dispositivo, etc.
¿Qué es la Ingeniería Web?
Es la aplicación de metodologías al desarrollo eficiente de
aplicaciones para Internet.

Consiste en la disposición y empleo de fundamentos

científicos, de ingeniería y gestión y con orientaciones
metódicas y disciplinadas del desarrollo, utilización y
mantenimiento de sistemas y aplicaciones web de calidad.
Atributos de la calidad de una WebApp
Seguridad en las WebApps
A diferencia de una aplicación local, una aplicación en
Internet ésta 24 horas expuesta a un posible acceso sin
autorización.

Las aplicaciones comúnmente son desarrolladas usando

lenguajes de programación tales como PHP, JavaScript,
Python, entre otros.

Es importante en cada caso implementar las mejores

opciones de seguridad.
¿Qué es un Servicio Web?
Es un aplicativo que facilita la interoperabilidad entre varios
sistemas diferentes.

Son cajas negras, en el sentido que no conocemos su

implementación interna ni hay que preocuparse por ello, ya
que lo importante es conocer qué funcionalidad brindan, qué
parámetros necesita recibir y qué devuelve.
 ¿Qué es JSON?

JSON (JavaScript Object

Notation) es un estándar en texto
que sirve para el intercambio de
información entre sistemas
diferentes.
 Reingeniería de Software

Link a la presentación prof. Ramiro Estigarribia

¿Qué es la Reingeniería?
Todas las compañías funcionan
de acuerdo con una gran cantidad
de reglas no escritas.
La reingeniería busca apartarse de las viejas reglas
acerca de la forma en que se organizan y desarrollan
los negocios, buscando reinventar la manera de
hacer las cosas.
 Éxitos y Fracasos
Al igual que todas las revoluciones, existen
cambios positivos y negativos:

➔ Algunas compañías han hecho un esfuerzo en rehacer su

ingeniería, y los resultados han mejorado su competitividad.

➔ Otras en cambio, se han basado únicamente en reducir y

tercerizar para mejorar sus beneficios.
Y como resultado se obtuvieron organizaciones reducidas con
pocas probabilidades de crecer.
 Reingeniería de productos tecnológicos
Pensemos en cualquier producto de tecnología:

"Durante todo el tiempo: está envejeciendo".

Luego de un tiempo se falla con más frecuencia, tarda en

repararse y ya no representa la última tecnología.

¿Qué se puede hacer?

Si el producto es de hardware, probablemente
lo tirará y se comprará uno nuevo.
Reingeniería de Software
Pero si es un software personalizado y con datos
importantes, no dispondrá la opción de tirarlo.
"Necesitará reconstruirlo".
Creará un producto con una funcionalidad, rendimiento y
fiabilidad mejorados.
Eso es lo que llamamos Reingeniería.
¿Quién lo hace?
A nivel de negocio, la reingeniería es ejercida por
especialistas de negocio (frecuentemente empresas
de consultoría).
A nivel de software, la reingeniería es realizada por
ingenieros del software.
Envejecimiento del SW
Una aplicación ha dado servicio y ha cubierto las necesidades
del negocio de una compañía durante muchos años.

La empresa adquirió nuevo Hardware,

nuevos sistemas operativos, etc.

Ahora la aplicación se ha vuelto inestable:

Sigue funcionando, pero cada vez que intenta efectuar un
cambio se producen fallos colaterales:
cuelgues inesperados, fallos en la impresión, etc.
Cambios por Naturaleza
El cambio es algo inevitable cuando se construyen
sistemas basados en computadoras; por tanto debemos
desarrollar mecanismos para evaluar, controlar y realizar
modificaciones futuras.

La reingeniería de sistemas de información es una

actividad que absorberá recursos de las tecnologías de la
información durante muchos años.
Es una actividad inevitable.
Documentación Escasa
Una documentación escasa es el rasgo
principal de muchos sistemas heredados.
¿Qué se puede hacer al respecto?

Opción 1: Dejar como está.

La creación de documentación consume muchísimo tiempo.

Si el sistema funciona, en algunos casos, éste es el enfoque
correcto.
Reestructuración de documentos
Opción 2: Es preciso ampliar la documentación,
pero se dispone de recursos limitados.

Quizá no se necesario volver a documentar por completo la

aplicación.
Más bien se documentará aquellas partes del sistema que
experimen cambios en ese momento.
La colección de documentos útil y relevante irá
evolucionando con el tiempo.
Reestructuración de documentos.
Opción 3: El sistema es fundamental para el negocio, y
es preciso volver a documentar por completo.
En este caso, un enfoque inteligente consiste en reducir
la documentación al mínimo necesario.
Todas estas opciones son viables.
Las organizaciones deberán seleccionar aquella que
resulte más adecuada para cada caso.
¿Qué es la Virtualización?
Es la creación a través de software de una versión virtual de
algún recurso tecnológico.
Es una excelente opción hoy día, ya que las máquinas
actuales en la mayoría de los casos están siendo
"sub-utilizadas" (gran capacidad de disco, memoria, etc.),
llegando a un uso de entre 30% a 60% de su capacidad.
Al virtualizar, se realiza un ahorro considerable de los costos
(energía, mantenimiento, espacio, etc).
Virtualización, Características
Un esquema de virtualización proporciona un ambiente de
ejecución similar a todos los efectos a un computador físico:

➔ CPU
➔ dispositivos de red
➔ memoria RAM
➔ sistema de sonido
➔ conexión USB
➔ particiones de disco, etc
Inconvenientes virtualización
Uno de los inconvenientes de las máquinas virtuales es que
agregan complejidad al sistema en tiempo de ejecución.
Esto tiene como efecto la ralentización del sistema, es decir,
el programa no alcanzará la misma velocidad de ejecución
que si se instala directamente como sistema operativo
principal.
Sin embargo, a menudo la flexibilidad que ofrecen compensa
esta pérdida de eficiencia.
¿Qué es la Ingeniería inversa?
Es el proceso de descubrir los principios tecnológicos
de un dispositivo o sistema, a través del análisis de su
estructura, función y operación.
Estos secretos se podrán comprender más
fácilmente si se tienen las especificaciones.
Pero estos documentos podrían no estar disponibles.
 Ingeniería inversa.
Tiene sus orígenes en el mundo del hardware.
Una compañía desensambla un producto de hardware en
un esfuerzo por comprender los secretos de fabricación.
Ing.Inversa en el SW
En la mayoría de los casos, el programa del cual hay que hacer
una ingeniería inversa no es el de un rival, sino, más bien, el
propio trabajo de la compañía.

La Ing. inversa del SW es el proceso de análisis de un programa

con el fin de crear una representación de programa con un nivel
de abstracción más elevado que el código fuente.

La ingeniería inversa es un proceso de recuperación de diseño.

 Ing.Inversa en el SW
Al aplicar ingeniería se profundiza el estudio del funcionamiento,
hasta el punto de llegar a entender, modificar, y mejorar.
Reingeniería de Bases de Datos
Las bases de datos permiten definir objetos
de datos, y permiten establecer relaciones
entre objetos.
El objetivo de la reingeniería de un esquema de bases de
datos, es formar uno nuevo a partir de este.
Exige comprender los objetos ya existentes y sus
relaciones.
Resumen y Conclusiones
La reingeniería busca reinventar la manera de hacer las cosas.

En los procesos de negocio se busca mejorar en costes,

calidad, servicio y rapidez.

La reingeniería de sistemas de información es una actividad

que absorberá recursos de las tecnologías de la información
durante muchos años.
Se considera inevitable.
Resumen y Conclusiones
La reingeniería de un esquema de bases de datos para
formar otro, exige comprender los objetos ya existentes
y sus relaciones.

Para comprender totalmente una interfaz de usuario

ya existente, es preciso especificar la estructura y
comportamiento de la interfaz.
Cuestionario
Administración de la Calidad

Ramiro Estigarribia Canese

 Antecedentes de la Calidad
➔ En la década de 1990, las principales corporaciones
reconocieron que cada año desperdiciaron millones de dólares
en software que no tenía las características ni la funcionalidad
que se habían prometido.
➔ Al despuntar el nuevo siglo, CIO Magazine dio la alerta:
“Dejemos de desperdiciar $78 mil millones de dólares al año”, y
lamentaba el hecho de que “las empresas estadounidenses
gastan millones de dólares en software que no hace lo que se
supone que debe hacer”.
 Código defectuoso - Hoy.
➔ A pesar de las buenas intenciones, el código defectuoso sigue
siendo el duende de la industria del software, es responsable
hasta de 45% del tiempo que están fuera los sistemas y costó
a las empresas estadounidenses alrededor de $100 mil
millones de dólares en 2012, en pérdidas de productividad y
reparaciones.
➔ Eso no incluye el costo que implica perder a los clientes
disgustados.
 ¿Cuán malo es el software defectuoso?
➔ Los expertos dicen que sólo se requiere de 3 a 4 defectos por
cada 1.000 líneas de código para que un programa tenga mal
desempeño.
➔ Hay que pensar que la mayoría de los programadores cometen
un error en cada 10 líneas de código que escriben, lo que,
multiplicado por los millones de líneas que hay en muchos
productos comerciales, permite imaginar que la corrección de los
errores cuesta al menos la mitad del presupuesto.

¿Comprende lo que esto significa?

 ¿Qué es la Calidad?
➔ Es un concepto complejo y de facetas múltiples.
➔ El punto de vista del fabricante la define en términos de las
especificaciones originales del producto. Si éste las cumple,
tiene calidad.
➔ El punto de vista del producto sugiere que la calidad tiene que
ver con las características de un producto.
➔ El punto de vista basado en el valor la mide de acuerdo con lo
que un cliente está dispuesto a pagar por un producto.
➔ En realidad, la calidad incluye todo esto y más.
¿Qué es la Calidad? (cont..)
➔ La calidad del diseño se refiere al tipo de materiales,
tolerancias y especificaciones del desempeño. Si se utilizan
mejores materiales, la calidad del producto se incrementa.
➔ En el desarrollo del software, la calidad del diseño incluye el
grado en el que el diseño cumple las funciones y
características especificadas en el modelo de
requerimientos.

satisfacción del usuario = calidad + entrega dentro del plazo.

 Calidad del Software
Obtener software de alta calidad es una meta importante.
Pero, ¿Cómo se define la calidad del software?
Indicadores de Calidad:
1. Un proceso eficaz busca la elaboración de un producto de alta
calidad.
2. Un producto útil entrega contenido, funciones y características
que el usuario final desea, en forma confiable y libre de errores.
Calidad del Software
3. Al agregar valor para el usuario,
el software de alta calidad proporciona beneficios a la
organización que lo produce y a la comunidad de
usuarios finales.
La organización que elabora el software obtiene valor
agregado porque el software de alta calidad requiere un
menor esfuerzo de mantenimiento, menos errores que
corregir y poca asistencia al cliente.
Calidad del Software según Pressman

La calidad del software es, según Pressman:

La concordancia con los requisitos funcionales y
de rendimiento, con los estándares de desarrollo y
con las características implícitas que se espera del
software desarrollado e implementado.
Clasificación de factores de Calidad según McCall
 Factores de la Calidad
Corrección: Hasta dónde satisface un programa su
especificación y logra los objetivos propuestos por el cliente.
Fiabilidad: Hasta dónde se puede esperar que un programa lleve
a cabo su función con la exactitud requerida.
Eficiencia: La cantidad de recursos informáticos para que un
programa realice su función.
Integridad: Hasta dónde se puede controlar el acceso al software
o a los datos por personas no autorizadas.
 Factores de la Calidad (cont..)
Usabilidad: El esfuerzo necesario para operar el sistema.
Facilidad de mantenimiento: El esfuerzo necesario para localizar
y arreglar un error.
Flexibilidad: El esfuerzo necesario para modificar un programa
que ya está en funcionamiento.
Facilidad de prueba: El esfuerzo necesario para probar.
Portabilidad: El esfuerzo necesario para transferir el programa de
un entorno hardware/software a otro.
Reusabilidad: Hasta dónde se puede volver a emplear un
programa (o partes).
 La Fórmula de Medición de la Calidad
Es difícil y en algunos casos improbable, desarrollar medidas
directas de los factores de calidad anteriores.

Es por eso, que se definen y emplean un conjunto de métricas para

desarrollar expresiones para todos los factores de acuerdo con la
siguiente relación:

Fq = c1 * m1 + c2 * m2 + …+ cn * mn

Donde Fq es el factor de calidad del software.

Cn son coeficientes y Mn son puntajes obtenidos.

 “El dilema de la Calidad”
➔ Si produce un sistema de mala calidad, usted pierde porque nadie
lo querrá comprar.
➔ Por otro lado, si dedica un tiempo infinito, demasiado esfuerzo y
dinero para obtener un elemento perfecto de software, entonces
será tan caro de producir que de todos modos quedará fuera del
negocio.
➔ Los ingenieros de software deben situarse en un punto medio
donde el producto es atractivo, pero tampoco es un objeto
perfeccionista que requiera demasiado tiempo o dinero para ser
terminado.
Factores de calidad ISO 9126
El estándar ISO 9126 ha sido creado en un intento de
identificar los atributos clave de calidad del software.
El estándar identifica seis atributos clave de calidad:

● Funcionalidad.
● Confiabilidad.
● Usabilidad.
● Eficiencia.
● Facilidad de mantenimiento.
● Portabilidad.
Factores de calidad ISO 9126
Características de las Métricas de
Sistemas O.O.
Berard define cinco características para las métricas
de Sistemas O.O.:
1. Localización
2. Encapsulación
3. Ocultamiento de información
4. Herencia
5. Abstracción de objetos.
1. Localización
Indica la manera en que la información
se concentra en el Sistema.
Generalmente la información se organiza
en forma de estructuras de datos.
(Bases de datos)
2. Encapsulación
Es el empaquetamiento de una colección de
elementos.
Engloba las responsabilidades de una clase,
incluyendo sus atributos y operaciones.
Eleva la medición a un nivel de abstracción más
alto, simplificando el análisis.
 3. Ocultación de Información
Oculta detalles operacionales de un componente de programa,
simplificando el entendimiento.
Un sistema bien diseñado debe implementar ocultación de
información.
Las métricas que proporcionan una indicación del grado de
ocultación que se ha conseguido en la etapa de Diseño.
 4. Herencia
Evalúa la propagación de características entre objetos.
La herencia ocurre a
través de todos los
niveles de una jerarquía
de clases.

Es una característica
vital en los sistemas O.O.
5. Abstracción de Objetos
Permite concentrarse en los detalles esenciales, prestando
poca atención a detalles de bajo nivel.
A medida que se mueve a niveles más altos de abstracción
se tiene una visión más general.
A medida que se mueve a niveles de abstracción más
bajos, se tiene una visión
más específica.
 Resumen y Conclusiones.
➔ La preocupación por la calidad del software ha aumentado a
medida que éste se integra en cada aspecto de nuestras vidas
cotidianas.
➔ Pero es difícil hacer la descripción exhaustiva de la calidad del
software.
➔ Con el tiempo se han propuesto varias dimensiones y factores
de calidad del software.
➔ Todos ellos tratan de definir un conjunto de características que,
si se logran, llevarán a un software de alta calidad.
 Resumen y Conclusiones.
➔ McCall y los factores de calidad de la norma ISO
9126 establecen características tales como
confiabilidad, usabilidad, facilidad de mantenimiento,
funcionalidad y portabilidad, como indicadores de la
existencia de calidad.
➔ Sin importar el enfoque que se elija, la calidad tiene
un costo que puede estudiarse en términos de
prevención, evaluación y falla.
 Administración de la Seguridad

Prof. Ramiro Estigarribia Canese

Link a la presentación ramiroec@gmail.com
¿Es importante detectar vulnerabilidades?
Es importante que podamos detectar cualquier
vulnerabilidad que exista antes de que esta sea
aprovechada por un hacker.
Como administrador de sistemas informáticos, una de
nuestras responsabilidades es mantener la seguridad de
nuestra plataforma lo menos vulnerable posible.
¿Qué es un Pentest?
(test de penetración de la seguridad)

Es el método de evaluar la seguridad de los equipos y las

redes de comunicación simulando un ataque informático.

El proceso consiste en un análisis activo de todos los

equipos de la red para detectar cualquier vulnerabilidad de
seguridad por una falla en la configuración de los servidores
o los equipos de seguridad.
¿Qué es BlackBox?
El auditor evalúa la seguridad de la red desde afuera de la
empresa.

El objetivo es acceder en forma remota a los equipos de la

organización y posicionarse como administrador del sistema.

El método es parecido al empleado por un hacker real.

No se informa a los empleados, sobre la auditoría.

Pruebas Externas
1. Pruebas de usuarios y passwords.
2. Captura de tráfico.
3. Detección de protocolos utilizados.
4. Scanning de puertos TCP, UDP e ICMP.
5. Análisis de la seguridad de las conexiones
6. Pruebas de vulnerabilidades conocidas.
7. Ataques de Denegación de Servicio. (DOS)
 ¿Qué es un WhiteBox?
Busca demostrar el nivel de seguridad con acceso interno.
➔ Se evalúa qué puede hacer un atacante interno y hasta
dónde será capaz de llegar.
➔ El auditor tiene acceso total a los equipos de la empresa.
➔ Los empleados tienen conocimiento de la auditoría y
colaboran con el auditor.
Pruebas Internas
1. Análisis de protocolos internos y sus vulnerabilidades.
2. Autenticación de usuarios.
3. Verificación de permisos y recursos compartidos.
4. Test de los servidores principales (WWW, DNS, etc.).
5. Análisis de la seguridad de las estaciones de trabajo.
6. Seguridad de la red.
7. Verificación de reglas de acceso.
8. Ataques de Denegación de Servicio. (DOS).
¿Qué es un Hacker Ético?
Es un profesional de la seguridad, que aplica sus
conocimientos de hacking con fines defensivos.
Hunter.io: Buscar Mails
Utiliza Google, Bing, Linkedin y otros para encontrar mails y
otros datos. La versión online es: https://hunter.io/
Robtex
Proporciona información a partir de cualquier dominio de
internet. Ejemplo:
https://www.robtex.net/?dns=presidencia.gov.py&graph=1
ARCHIVE.ORG
Muestra el historial de todas las páginas. http://archive.org
Puede ser útil para ver información, que hoy día ya no está
disponible: emails, usuarios, datos de servidores, etc.
¿Qué es Sitecheck?
Permite detectar malware, errores y software inseguro.

También indica si la página ha sido incluida en alguna lista

negra de herramientas de seguridad como Norton, ESET o
SiteAdvisor.

https://sitecheck.sucuri.net/
Netcraft
NETCRAFT: Proporciona información de 1 sitio web:

1. IP Address.
2. Sistema Operativo.
3. WebServer.
4. Fechas de cambios.

http://toolbar.netcraft.com/site_report
¿Qué es Google Hacking?
Es una técnica que utiliza el buscador Google para encontrar
datos de sitios.

Podemos encontrar agujeros de seguridad en la

configuración y el código que se utilizan en las páginas web.

Ejemplos:
Buscar en google: indexof[packet tracer]
Buscar en google: warning .com.py
Actividad opcional: Investigar un sitio.
Elegir una empresa de cualquier parte del mundo.

1. Encontrar sus direcciones de email con: hunter.io.

2. Obtener datos de ROBTEX.
3. Capturar una versión antigua de la página:
http://www.archive.org.
4. Identificar datos de servidor con NETCRAFT:
http://toolbar.netcraft.com/site_report
 7. Calendarización del Proyecto

Prof. Ramiro Estigarribia

Link a la presentación
 ¿En qué consiste la Calendarización?
Consiste en crear una red de tareas que le permitirán concluir el
trabajo a tiempo.

A esta altura del proyecto, usted ya identificó las tareas que deben
realizarse, estimó la cantidad de trabajo, conoce la fecha límite e
incluso consideró los riesgos.

Una vez creada la red, tiene que asignar responsables para cada
tarea, asegurarse de que se realizan y adaptar la red conforme los
riesgos que habrá cuando se convierta en realidad.
 Razones por las que el software se entrega tarde
1. Fecha límite irreal establecida por alguien externo al equipo.
2. Requerimientos del cliente variables que no se reflejan en
cambios del calendario.
3. Mala estimación del esfuerzo que se requerirá.
4. Riesgos que no se consideraron cuando comenzó el proyecto.
5. Dificultades humanas que no podían preverse por anticipado.
6. Falta de comunicación entre el personal del proyecto.
Fechas Límites Agresivas
Las fechas límite agresivas (léase “irreales”) son un hecho de
la vida en el negocio del software.

En ocasiones, tales fechas límite se demandan por razones

legítimas, desde el punto de vista de la persona que las
establece.
 Recomendaciones ante Fechas Agresivas
Es irreal ir a la oficina del cliente y exigir que se cambie la fecha.
Ante esta situación, los autores recomiendan:
1. Realizar una nueva estimación con datos históricos de proyectos
anteriores.
2. Con el modelo de proceso incremental, desarrolle una estrategia
que entregue funcionalidad crucial en la fecha límite impuesta, pero
que desarrolle el resto más tarde.
3. Reúnase con el cliente y explique por qué la fecha límite es irreal,
comparando con proyectos anteriores.
 Principios de la Calendarización
1. Dividir en partes. El proyecto debe separarse en tareas manejables.
2. Interdependencia. Algunas tareas deben sucederse en secuencia,
mientras que otras pueden ocurrir en paralelo.
3. Asignación de tiempo. A cada tarea debe asignarse una fecha de
comienzo y una de conclusión.
4. Validación de esfuerzo. Definir las personas para cada tarea.
5. Responsabilidades definidas. Cada tarea por calendarizar debe
asignarse a un miembro de equipo específico.
6. Resultados definidos. Cada tarea debe tener un resultado.
 Relación entre personal y esfuerzo
En un pequeño proyecto, una sola persona puede analizar
requerimientos, elaborar diseño, generar código y realizar pruebas.
Conforme el tamaño de un proyecto aumenta, más personas deben
involucrarse.

Existe un mito común que todavía creen muchos: “Si nos atrasamos
en el calendario, siempre podemos agregar más programadores y
ponernos al día”.
Por desgracia, agregar personal tardíamente en un proyecto con
frecuencia tiene efectos negativos.
 Definición del Conjunto de Tareas
Con la finalidad de desarrollar un calendario, en la línea de tiempo del
proyecto debe distribuirse un conjunto de tareas.

Si se usan herramientas automatizadas, la distribución del trabajo se

ingresa como una red o esbozo de tareas.

Luego se ingresan esfuerzo, duración y fecha de inicio para cada

tarea. Además, las tareas pueden asignarse a individuos específicos.
Con esta información se crea un cronograma, llamado gráfico de
Gantt.
 Seguimiento del Calendario
El calendario del proyecto se convierte en un mapa de caminos
que se van a monitorear en varias formas diferentes:

1. Realizar reuniones periódicas del estado del proyecto.

2. Evaluar los resultados de todas las revisiones realizadas.
3. Determinar si los hitos se lograron en la fecha prevista.
4. Comparar la fecha de inicio real con la fecha de inicio
planeada para cada tarea.
5. Reunirse informalmente con los profesionales para obtener su
valoración subjetiva.
Herramientas Comerciales Disponibles
https://www.tomsplanner.es/

https://gantter.com/

Microsoft Project

https://www.ganttproject.biz/
 Conclusiones
La calendarización comienza con la descomposición del
proceso. Las características del proyecto se usan para
adaptar un conjunto de tareas adecuado para el trabajo que
se va a realizar.
Una red de tareas muestra cada tarea de ingeniería, su
dependencia de otras tareas y su duración proyectada.
La red de tareas se usa para calcular la ruta crítica, un
cronograma y otra información del proyecto.
Al usar el calendario como guía, puede monitorearse y
controlar cada paso en el proceso de software.