Universidad Autónoma de Santo Domingo

Facultad de Ciencias
Escuela de Informática

Integrantes: Matricula:
Domingo Antonio Santamaría AE-6880
Reynaldo José Encarnación DC-6058
Alexander Roso CF-8233
Emmanuel Sierra CB-9010

1
ASPECTOS BÁSICOS EVALUABLES EN LOS PRODUCTOS DE SOFTWARE

2
 ASPECTOS BÁSICOS EVALUABLES EN LOS PRODUCTOS DE SOFTWARE

1. Análisis de requerimientos
2. Diseño
3. Programación
4. Prueba

3
 Requisito
Los requisitos del software son la descripción de las características y las
funcionalidades del sistema 'target'. Los requisitos nos comunican las
expectativas de los consumidores de productos software. El proceso de
recogida de información, análisis y documentación sobre los requisitos
software del cliente, se conoce como ingeniería de requisitos.

Proceso de la Ingeniería de requisitos

Es un proceso que consta de cuatro pasos:
 Estudio de viabilidad
 Recogida de requisitos
 Requisitos del Software 4

 Validación de los requisitos de Software

 Diseño
El diseño de Software es un proceso que transforma los requisitos del
usuario de una manera conveniente, lo que ayuda al programador a en la
codificación e implementación del software.
El diseño de Software produce 3 niveles de resultados:
 Diseño arquitectónico - El Diseño arquitectónico, es la versión más
abstracta del sistema. Identifica el software como un sistema con distintos
componentes que interactúan entre ellos.
 Diseño de alto nivel- El Diseño de alto nivel, rompe con el concepto de
diseño arquitectónico que se refiere a ‘Componente de única entidad
múltiple', por lo contrario tiene un punto de vista menos abstracto de los
sub sistemas y módulos y representa la existente interacción entre ellos.
 Diseño detallado- El Diseño detallado diseña acuerdos con la parte de
implementación de lo que se ve como sistema y sus sub sistemas con los
dos tipos de diseño mencionados con anterioridad.
5
Programación:  Se traduce el diseño a código. Es la parte más obvia del trabajo de
ingeniería de software y la primera en que se obtienen resultados “tangibles”. No
necesariamente es la etapa más larga ni la más compleja aunque una especificación o
diseño incompletos/ambiguos pueden exigir que, tareas propias de las etapas anteriores
se tengan que realizarse en esta.
Implementación
Esta es la fase en que ponemos el software en funcionamiento en el mundo real, o
dentro de la organización para la que fue desarrollado. En esta fase se realizan todos los
preparativos necesarios para asegurar que la inclusión del software dentro de la
organización se realizara sin contratiempos y produciendo la menor cantidad de
inconvenientes posible.
Mantenimiento
Como sabemos las organizaciones no permanecen igual, cambian a lo largo del
tiempo, así también los gustos y necesidades de las personas cambian, entonces el
software necesita ser modificado para que se adapte a esos cambios, y es por ello que
surge lo que en el software general las famosas actualizaciones.
Obsolescencia
Si bien es cierto que el mantenimiento hace el software se adapte a los cambios del
entorno, este mantenimiento no es eterno, llega un punto en el que ya no es posible
seguir haciendo modificaciones al sistema, en ese momento el software se vuelve
obsoleto, ya sea por la tecnología que se uso en su desarrollo o por que no fue diseñado
para la cantidad de operaciones que se realizan hoy en día, se cual fuere la razón una 6
vez que el software es obsoleto es tiempo de crear una nueva versión del software y es
cuando volvemos a encontrar nuestra necesidad, oportunidad o problema.
Las pruebas (testing ):
Las pruebas de Software son una evaluación
del software en contraste con la recogida de
requisitos de usuarios y especificaciones de
sistema.
Validación del Software
 La validación es un proceso para examinar si
el software satisface o no los requisitos del
usuario.
Verificación Software
 La verificación es el proceso de confirmación
del cumplimiento de los requisitos
empresariales por parte del software, y se
desarrolla ciñéndose a especificaciones y
metodologías adecuadas. 7
 Las Pruebas (Testing): son los procesos que permiten
verificar y revelar la calidad de TIPOS
un producto
DE PRUEBASsoftware.

Tipos de pruebas:

 Pruebas unitaria
 Pruebas funcionales
 Pruebas de integración
 Pruebas de sistemas

8
 PRUEBA UNITARIA

Una prueba unitaria permite comprobar que una parte especifica de código de una
determinada aplicación que está siendo programada o codificada no presenta fallos,
errores, o cálculos inesperados.
Aunque el objetivo de la prueba de forma individual es encontrar fallos (bugs ), la meta
final es aumentar la calidad del desarrollo, siendo uno de los objetivos principales de la IS
ó Ingeniería del Software, la falta de conocimiento por parte de los directores de producto,
así como los tabús y falsos aforismos típicos en informática, no pierdas tiempo.

– Las pruebas unitarias se tienen que poder ejecutar sin necesidad de intervención manual,
mejorar la automatización de la ejecución.
 – Las pruebas unitarias tienen que poder repetirse tantas veces como uno quiera, deben ser
rápidas.
 – Deben cubrir casi la totalidad del código de nuestra aplicación.
 – Deben poder ser ejecutadas bajo cualquier entorno, es decir, que los casos de error sean
reales entre plataformas.
Automatizable, Completas, Repetibles o Reutilizables, Independientes, Profesionales.
Por lo tanto, respondiendo a la pregunta inicial  ¿ Qué ventajas me proporcionan ? 9
 PRUEBA DE INTEGRACIÓN

En este caso probamos cómo es la interacción entre dos o mas unidades del
software.
Existen varios tipos de pruebas de integración. Los más comunes son:
  Big bang: se acoplan todos los módulos de una sola vez, reduciendo la
cantidad de pruebas (pero también dificultando la detección de posibles
errores).
 Bottom-up: se prueban primero los componentes de bajo nivel y luego se
avanza hacia los de mayor nivel.
 Top-down: el enfoque es exactamente inverso al anterior.
Se puede utilizar cualquier método de los antes mencionados, pero lo
más importante  es incluir las pruebas de integración ya que son de
importancia crítica para el proceso de aseguramiento de calidad.
10
 PRUEBAS FUNCIONALES

Las pruebas funcionales son un proceso de control de calidad que consiste en asegurar el cumplimiento de
un sistema o componente con requerimientos funcionales.
El objetivo principal de las pruebas funcionales es analizar el producto terminado y determinar si hace todo
lo que debería hacer y si lo hace correctamente.
Las pruebas funcionales se dividen en las siguientes fases:
 Análisis de requisitos (Planificación)
En esta fase se inicia la elaboración del modelo jerárquico de requisitos de prueba partiendo de los procesos
funcionales que soporta el producto o activo de software a evaluar En esta fase se identifica, acuerda y
especifican los atributos y características de calidad que se van a probar. El objetivo es diseñar las pruebas
para que tengan la mayor probabilidad de encontrar defectos con la mínima cantidad de esfuerzo y tiempo.
 Ejecución
En esta fase se ejecutarán los casos de prueba anteriormente diseñados de forma manual. Hay que seguir al
detalle el guión establecido dejando cierta libertad al tester para detectar situaciones anómalas no
contempladas. Las baterías de pruebas serán ejecutadas como mínimo una vez antes del paso a producción,
 Gestión de Incidencias (Defectos)
La gestión de incidencias es una parte implícita de la fase de ejecución, pero que al tener una alta
importancia en las pruebas funcionales, diferenciamos como una etapa independiente. Cuando al realizar la
acción de un step el resultado obtenido no es el esperado, habrá que abrir o reportar una incidencia para que
11
el equipo de desarrollo tenga constancia del error.
 PRUEBA DEL SISTEMA

Las pruebas del sistema tienen como objetivo ejercitar profundamente el

sistema comprobando la integración del sistema de información
globalmente, verificando el funcionamiento correcto de las interfaces
entre los distintos subsistemas que lo componen y con el resto de sistemas
de información con los que se comunica.
En esta etapa pueden distinguirse los siguientes tipos de pruebas
 Pruebas funcionales. Dirigidas a asegurar que el sistema de información
realiza correctamente todas las funciones que se han detallado en las
especificaciones dadas por el usuario del sistema.
 Pruebas de comunicaciones. Determinan que las interfaces entre los
componentes del sistema funcionan adecuadamente, tanto a través de
dispositivos remotos, como locales.
 Pruebas de rendimiento. Consisten en determinar que los tiempos de
respuesta están dentro de los intervalos establecidos en las
especificaciones del sistema.
12
 Pruebas de volumen. Consisten en examinar el funcionamiento del
sistema cuando está trabajando con grandes volúmenes de datos,
 Pruebas de sobrecarga. Consisten en comprobar el funcionamiento del sistema en el umbral
limite de los recursos, sometiéndole a cargas masivas. El objetivo es establecer los puntos
extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos.
 Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede
recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de
los datos.
 Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las
necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de
trabajo.
 Pruebas de operación. Consisten en comprobar la correcta implementación de los
procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y re
arranque del sistema, etc.
 Pruebas de entorno. Consisten en verificar las interacciones del sistema con otros sistemas
dentro del mismo entorno.
 Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al
sistema para evitar alteraciones indebidas en los datos.
13
Seguridad: durante el análisis de reconocimientos se pueden
identificar diversas características que derivaran a los
ASPECTOS BASICOS EVALUABLES EN LA PRODUCCIÓN DEL SOFTWARE
reconocimientos de seguridad del software.

Fiabilidad: Relacionado a la capacidad de la aplicación para

recuperarse en el menor tiempo ante la ocurrencia de la falla de un
sistema

Adaptabilidad: Capacidad del producto software para ser adaptado

a diferentes entornos especificados

Instabilidad: Capacidad del producto software para ser instalado en

un entorno especificado
14
 ASPECTOS BÁSICOS EVALUABLES EN LA PRODUCCIÓN DEL SOFTWARE
Corrección : hace referencia a que un programa debe hacer lo
que se espera de el.

Validez : verifica que el sistema de software producido cumple

con las especificaciones y que logra su cometido. Se trata de
evaluar el sistema o parte de este.

Usabilidad : capacidad del producto software que permite al

usuario entender si el software es adecuado y como puede ser
usado para unas tareas o condiciones de uso particulares.
15
Entrevista: Consiste en reunirse con una o varias personas y
cuestionarlas para obtener información
TÉCNICA BÁSICA DE OBTENCIÓN DE INFORMACIÓN

Cuestionario: Se emplean para obtener información deseada en

forma homogénea están constituidos por series de preguntas escritas,
predefinidas , secuenciales y separadas por capítulos y temáticas.

Revisiones: conjunto de actividades que suceden como resultado del

análisis, diseño y la codificación que sirve para depurar las actividades
de ingeniería del software

Pruebas: es el proceso de ejecución de un programa con el fin de

encontrar errores.
16
 DIAGRAMAS DE CAUSAS Y EFECTOS
Un diagrama de Causa y Efecto es la representación de varios
¿QUÉ ES?
elementos (causas) de un sistema que pueden contribuir a un
problema (efecto). Fue desarrollado en 1943 por el Profesor Kaoru
Ishikawa en Tokio.

Algunas veces es denominado Diagrama Ishikawa o Diagrama

Espina de Pescado por su parecido con el esqueleto de un pescado

17
 DIAGRAMAS DE CAUSAS Y EFECTOS

¿CUÁNDO SE UTILIZA?
Estas opiniones pueden estar en conflicto o fallar al expresar la causa
principales. El uso de un Diagrama de Causa y Efecto hace posible
reunir todas estas ideas para su estudio desde diferentes puntos de
vista.

El desarrollo y uso de Diagramas de Causa y Efecto son más

efectivos después de que el proceso ha sido descrito y el problema
esté bien definido. Para ese momento, los miembros del equipo
tendrán una idea acertada de qué factores se deben incluir en el
Diagrama.
18
El diagrama causa-efecto es una forma de organizar y representar las
diferentes teorías propuestas sobre las causas de un problema. Se
conoce también como diagrama de Ishikawa o diagrama de espina de
DIAGRAMAS DE CAUSAS Y EFECTOS

pescado y se utiliza en las fases de Diagnóstico y Solución de la

causa.

¿CÓMO SE UTILIZA?
El diagrama causa-efecto es un vehículo para ordenar, de forma muy
concentrada, todas las causas que supuestamente pueden contribuir a
un determinado efecto. Nos permite, por tanto, lograr un
conocimiento común de un problema complejo, sin ser nunca
sustitutivo de los datos. Es importante ser conscientes de que los
diagramas de causa-efecto presentan y organizan teorías. Sólo cuando
estas teorías son contrastadas con datos podemos probar las causas de
19
los fenómenos observables.
EJEMPLO DE DIAGRAMAS DE CAUSAS Y EFECTO

20
Este método de testing se basa en la experiencia del ejecutor. Consiste en realizar un análisis de
MÉTODO ADIVINACIÓN DE ERRORES

los requisitos y el diseño del sistema, buscando intuir en que puntos del sistema se pudieron
insertar errores y elaborar el diseño de las pruebas enfocado a atacar el sistema sobre estos
casos.

Es curioso, pero en la gran mayoría de las ocasiones este método es utilizado por los tester, no
existe mucha documentación del método ni una estructuración de los pasos a seguir para este
tipo de prueba.

Las historias de defectos pueden ser útiles; hay una alta probabilidad de que los errores que han
aparecido en el pasado, puedan volver a aparecer. Generalmente se enfocan en:

● Listas o strings vacíos o nulos

● Cero ocurrencias o instancias
● Números negativos 21
 MÉTODO ADIVINACIÓN DE ERRORES
using namespace System;
EJEMPLO DE LISTA DE STRING VACIOS O NULOS

void main()
{
String^ s;
Console::WriteLine("The value of the string is '{0}'", s);
try {
Console::WriteLine("String length is {0}", s->Length);
}
catch (NullReferenceException^ e) {
Console::WriteLine(e->Message);
}
}
// The example displays the following output:
// The value of the string is ''
22
// Object reference not set to an instance of an object.
●
 CAJA BLANCA: PRUEBA DEL CAMINO BÁSICO

La prueba del camino básico, es una prueba de “caja blanca” que consiste en verificar el código
de nuestros sistemas de manera que comprobemos que todo funciona correctamente, es decir, se
debe verificar que todas las instrucciones del programa se ejecutan por lo menos una vez.

Los pasos para desarrollar la prueba del camino básico son:

1.- Dibujar el grafo de flujo.
2.- Calcular la complejidad ciclomatica.
3.- Determinar el conjunto básico de caminos independientes.

23
 El siguiente diagrama flujo corresponde al algoritmo para determinar el número mayor de 3
valores dados.

24
 Paso 1: Dibujar el grafo de flujo
 Detectamos los nodos que conformaran el grafo de flujo así como los caminos que se pueden
recorrer durante la ejecución del programa

25
DIAGRAMA Y GRAFO DE FLUJO

26
COMPLEJIDAD CICLOMATICA
Paso 2: Complejidad Ciclomática
La complejidad ciclomática  mide el número de caminos
independientes dentro de nuestro código que es sometido a
prueba.  La formula para su calculo es:
V(G) = a – n +2
donde:
•a: Es el numero de aristas (lados)
•n: Es el numero de nodos (vertices)
En nuestro ejemplo la formula queda de la siguiente forma:
V(G) = 11 – 9 + 2 = 4
Nuestro código tiene una complejidad ciclomática de 4, eso
quiere decir que debemos realizar 4 pruebas para
asegurarnos de que cada instrucción se ejecute por lo menos
una vez.

27
 Paso 3: Caminos independientes
 Vamos formando los caminos independientes  (4 según la complejidad ciclomatica)desde el mas largo al
mas corto observando nuestro grafo de flujo.

28
FUENTES:

http://losmuchachosdelbonsai.blogspot.com/2013/03/pruebas-unitarias-y-junit.html
http://www.palentino.es/blog/que-es-una-prueba-unitaria-ventajas-que-posee-y-un-ejemplo-practico-en-
php/
https://technet.microsoft.com/es-es/library/bb490186.aspx
https://losandestraining.com/2017/10/12/test-de-integracion/
http://taller1cdsucn.blogspot.com/2013/08/tecnicas-de-caja-negra.html
http://www.jc-mouse.net/ingenieria-de-sistemas/caja-blanca-prueba-del-camino-basico

29
30