DOCUMENTACION Y TECNICAS DE PRUEBA DE SOFTWARE

Fase 3 - Determine and implement solutions

TUTOR:
Angela María González

PRESENTADO POR:
José Luis Demoya COD: 72.055.703
Cristian Vicente Rodríguez COD: 1233892603
Yeimar Andrés González COD:
Alexander Arciniegas COD: 1144150641
Angel Alexander Reinoso Hernandez COD: 1122118129

GRUPO: 100404A_474

Universidad Nacional Abierta Y A Distancia UNAD

Barranquilla, Noviembre 22 de 2018
 DESARROLLO DE ACTIVIDADES

COLLABORATIVE ACTIVITY

1 - Define the measures to use for the development of tests.

Para el desarrollo de las pruebas de software se requiere de 350 MB der RAM libre como
mínimo para correr la aplicación, de igual forma se requiere un procesador igual o
superior a los 1.9 GHz, un espacio en disco duro cerca a los 20MB espacio total de la
aplicación: 13 Mb redondeando.

Se requiere del uso de un navegador para visualizar la página y de visual studio para
que en la ejecución de las pruebas se pueda mostrar la memoria usada de igual manera
la potencia requerida por la CPU evitando aun demoras inesperadas en la carga del
programa.

2 - Create the tests plan MIPS-007 of the attached forms (Practical environment).

MIPS-007:

ASPECT OR ELEMENT TO VERIFY YES NO DOES OBSERVATIONS

NOT
APPLY
1. Test strategy X
1.1. Definition of the testing strategy and its corresponding X
phases.
1.2. Definition of test design techniques X
1.3. Definition of personnel and testing experience required x No se especificara
el personal o
experiencia en
testeo de
aplicaciones
1.4. Definition of test coverage x

2. Schedule x
2.1. Detailed definition of the Schedule x
2.2. Prioritization of the tests and criteria used x
2.3. Restrictions of time, personnel and budget considered x No se estimaran las
restricciones de
tiempo ya que no
tiene una naturaleza
exacta.

3. Acquisition of test data x

3.1. Test Data Dictionary x
3.2. Techniques to be used to define test data (Data flow x
coverage, Boundary condition tests or border)
3.4. Definition of the Test Database, which includes aspects x Se desconocen
of depth, variety, scope and integrity of the data. procesos avanzados
de programación
para llevar a cabo
este requisitos en el
documento

4. Testing Environment x
4.1. Definition of the Software required for the tests x
4.2. Definition of the Hardware required for the tests x
4.3. Determination of the human resource required for the x No se determinara la
tests cantidad de recursos
humanos que se
necesitan.
4.4. Definition of other resources required for testing x No se definen otros
recursos que se
usaron en las pruebas.
4.5. Definition of back-up mechanisms for test results x
4.6. Estimated test budget x

5. Handling of Problems that may arise X

5.1. Handling beta products or pre-releases X
5.2. Handling patches or service packages X

General remarks:

SIGNATURE OF THE REVIEWER:

3 - Do two tests of acceptance, one with a successful procedure and the other one
with a deliberate error. Explain step by step the procedure and additional to this,
manage the format MIPS-008 y MIPS-009 of the attached forms (practical
environment).
 Programa funcional
1) Medición de la RAM

2) Carga máxima CPU

3) Carga total

4) Seleccionar la pestaña
5) Output exitoso

6) Peso
 Programa con falla deliberada
1) Sabotaje de la carpeta data
2) Error inesperado

3) Errores del compilador

 4) Peso del proyecto saboteado

MIPS-008:

REVIEW OF THE PROOF

ASPECT OR ELEMENT TO VERIFY YES NO DOES OBSERVATIONS
NOT
APPLY

1. General information of the test X

1.2. Test technique (White box, black box) X
1.3. Test strategy X
1.4. Type of test (Unit, integration, system, validation) X
1.3. Location of the test (where it will be done) X
1.4. Date and time of the test X
1.5. Responsible (s) for the application of the test X
2. Description of the test X
2.1. Input data X
2.2. Output data or expected results X
2.3. Procedure to perform the test X
General remarks :

SIGNATURE OF THE REVIEWER:

Reviewed by Alexander Arciniegas Position or role Compilador

Date 23-11-2018 Site Cali
Project's name FilmData
Description:
El programa debe de guardar datos de películas, directores y estudios.
GENERAL EVALUATION
General assessment of the requirements specification document, regarding the following aspects
Right
Totalmente correcto ya que la documentación de requisitos se hizo después del Software y el
MIPS 007 tiene todos los requisitos por medio de Ingeniera inversa
Unequivocal
Es correcto, debido a que los requisitos que se usaron para el desempeño del software dieron
resultados positivos.

Full
Es completo porque se especificaron todos los requisitos funcionales del software, para saber
su usabilidad y hasta qué punto puede llegar.
Consistent
Es consistente de acuerdo a las pruebas que se hicieron por medio del MIPS 004.

Ascertainable
Si es comprobable, ya que el software se sometió a pruebas para determinar si los requisitos
funcionan correcta y de manera idónea.
Modifiable
Se puede realizar ajustes en el software para obtener mayor rendimiento y corregir errores
eventuales que se presenten, así se garantiza la estabilidad del programa.

Identifiable
Si es identificables, porque se busca que los requerimientos cumplan las expectativas y
funciones que debe desempeñar el software.
Final observations

No hay comentarios.

SIGNATURE OF THE REVIEWER:

4 - Do any test of totality of the two types: errors of programming between

components or of interoperability? Explain if the test done is incremental or no
incremental and why one of the two options is chosen. Format pages 17 to 20 of
the attached forms (practical environment).

Con respecto a los componentes y la interoperabilidad, es necesario que los ficheros o

registros de componentes se encuentren en su totalidad dentro de los ficheros del
software, ya que al faltar una carpeta completa genera un error de interoperabilidad
debido a que el sistema espera la conexión entre los controladores y las tablas, de esto
se encarga la carpeta data y sus clases, de este modo es posible la interoperabilidad
entre aplicaciones, en diferentes máquinas y en entornos distribuidos heterogéneos.

Los errores de interoperabilidad a nivel de implementación pueden ser no originados por

el mal funcionamiento o la falta de un componente particular, sino por una combinación
incorrecta o por la falta de varios de ellos, muchos de estos problemas podrían evitarse
si se tuviera en cuenta todo el conocimiento de la importancia que se tiene sobre cada
componente.

Con respecto al modelo de este software, este permite el cumplimiento de las

características básicas de un modelo no incremental, es decir, el proyecto no contiene
una pruebas incrementales ya que aquí solo se aplicando dos pruebas a programas
pequeños y completos y se utiliza solo una parte de sus componentes esperando que el
programa completo funcione, la administración del proyecto no es tan compleja, ya que,
el cumplimiento de los requerimientos se hace con la característica de comprobar la
funcionalidad y los resultados en un menor tiempo y de manera más fácil.
 Referencias Bibliográficas

Guillamón M. A. (2011). Manual desarrollo de elementos software para gestión de

sistemas. (pp. 55 – 63). Madrid – España: Editorial CEP. Recuperado de:
http://bibliotecavirtual.unad.edu.co:2077/lib/unadsp/reader.action?docID=10741437&pp
g=49

Jones, C. (2006). Estimación de costos y administración de proyectos de software. (pp.

485). (2a. ed.). México, D.F., MX: McGraw-Hill Interamericana. Recuperado de:
http://bibliotecavirtual.unad.edu.co:2077/lib/unadsp/reader.action?docID=10450270&pp
g=8

Villada R, J. L. (2015). Desarrollo y optimización de componentes software para tareas

administrativas de sistemas: UF1286. (pp. 193 – 206). Málaga - España: Editorial IC.
Recuperado
de: http://bibliotecavirtual.unad.edu.co:2077/lib/unadsp/reader.action?docID=11162004
&ppg=8

De Lucia, A. (2008). Emerging Methods, Technologies and Process Management in

Software Engineering. Hoboken, N.J.: Wiley-IEEE Computer Society Pr. Recovered
from http://bibliotecavirtual.unad.edu.co:2048/login?url=http://search.ebscohost.com/logi
n.aspx?direct=true&db=e000xww&AN=225448&lang=es&site=ehost-live

Hauptmann, B., Grumberg, O., Nipkow, T., & IOS Press, (. (Firm). (2012). Software
Safety and Security: Tools for Analysis and Verification. Amsterdam: IOS Press.
Recovered
from http://bibliotecavirtual.unad.edu.co:2048/login?url=http://search.ebscohost.com/logi
n.aspx?direct=true&db=e000xww&AN=463799&lang=es&site=ehost-live

Campderrich, F. B. (2003). Ingeniería del software. Barcelona, ES: Editorial UOC.

Recuperado de
http://bibliotecavirtual.unad.edu.co:2077/lib/unadsp/reader.action?ppg=28&docID=1064
6149&tm=1479508839108

Weitzenfeld, A. (2005). Calidad de Software y Modelos de Madurez del Proceso.

In Ingeniería de Software Orientada a Objetos con UML, Java e Internet. México City:
Cengage Learning. Recuperado de
http://bibliotecavirtual.unad.edu.co:2081/ps/retrieve.do?tabID=&userGroupName=unad
&inPS=true&prodId=GVRL&contentSet=GALE&docId=GALE|CX3004300026

Weitzenfeld, A. (2009). "Modelos Clásicos." Ingeniería de Software Orientada a Objetos

con UML, Java e Internet. Recuperado de:
http://bibliotecavirtual.unad.edu.co:2081/ps/retrieve.do?tabID=&userGroupName=unad
&inPS=true&prodId=GVRL&contentSet=GALE&docId=GALE|CX3004300024

Bahamón, J. (2005). Control de Calidad en el Software. Cali, Colombia. Universidad

ICESI. Recuperado de:
https://repository.icesi.edu.co/biblioteca_digital/bitstream/item/4008/1/Control_calidad_s
oftware.pdf

Keenan, M. (2015). Software Documentation. Salem Press Encyclopedia.Recovered

from http://bibliotecavirtual.unad.edu.co:2051/login.aspx?direct=true&db=ers&AN=1090
57137&lang=es&site=eds-live

Saukuma, T. t., & Čevere, R. r. (2008). Software documentation quality influence on the
product quality. Computer Science (1407-7493), 34167-180. p.1 - 15. Recovered
fromhttp://bibliotecavirtual.unad.edu.co:2051/login.aspx?direct=true&db=aci&AN=35471
861&lang=es&site=eds-live