El documento describe los pasos para construir un proceso de certificación para un proyecto de software. Explica que la calidad del software debe ser una preocupación desde el inicio del proyecto. Detalla los roles y responsabilidades del analista de certificación y los tipos de pruebas requeridas, incluyendo la necesidad de diseñar casos de prueba que cubran diferentes escenarios para encontrar errores de manera efectiva.

1. CONSTRUCCIÓN DE UN PROCESO
DE CERTIFICACIÓN PARA UN
PROYECTO INFORMÁTICO
NOMBRE: NATALIA GARCIA.
PROFESORA:PILAR PARDO.

2. ROGER PRESSMAN EN EL LIBRO INGENIERÍA DE
SOFTWARE MENCIONA:
• ROGER PRESSMAN EN EL LIBRO INGENIERÍA DE SOFTWARE MENCIONA:
• "ALGUNOS DESARROLLADORES DE SOFTWARE FALLAN CREYENDO QUE LA CALIDAD DEL
SOFTWARE ES ALGO EN LO QUE EMPIEZAN A PREOCUPARSE UNA VEZ QUE SE HA GENERADO EL
CÓDIGO. ¡NADA MÁS LEJOS DE LA REALIDAD! LA GARANTÍA DE CALIDAD DEL SOFTWARE
(SQA, SOFTWARE QUALITY ASSURANCE GCS , GESTIÓN DE CALIDAD DEL SOFTWARE) ES UNA
ACTIVIDAD DE PROTECCIÓN QUE SE APLICA A LO LARGO DE TODO EL PROCESO DEL SOFTWARE

3. • SE DEBE TOMAR EN CUENTA LA METODOLOGÍA EN LA CUAL SE BASA LA CONSTRUCCIÓN DEL
SOFTWARE, QUE PUEDE SER TRADICIONAL O ÁGIL, PARA DETERMINAR EN QUÉ MOMENTO O
ITERACIÓN DEBE SER APLICADA LA REVISIÓN. PARA AMBOS CASOS EL ROL DE ANALISTA DE
CERTIFICACIÓN DEBE COMPRENDER EL OBJETIVO POR EL CUAL SE CREA EL SOFTWARE Y, DESDE
DETALLAR EL ALCANCE DE LA CERTIFICACIÓN.

4. ¿QUÉ ES LA CERTIFICACIÓN DE UN PROYECTO?
• SEGÚN PRESSMAN, UNA VEZ GENERADO EL CÓDIGO FUENTE EL SOFTWARE DEBE SER
PROBADO PARA DESCUBRIR Y CORREGIR EL MÁXIMO DE ERRORES ANTES DE SU ENTREGA AL
CLIENTE. EL OBJETIVO DEL PROCESO DE CERTIFICACIÓN ES DISEÑAR UNA SERIE DE CASOS DE
PRUEBAS QUE TENGAN UNA ALTA PROBABILIDAD DE ENCONTRAR ERRORES

5. ¿CÓMO SE PUEDE LOGRAR ENCONTRAR ERRORES
EN EL SOFTWARE?
• EN ESTE PROCESO EL ANALISTA DE CERTIFICACIÓN SE BASA EN LAS TÉCNICAS DE PRUEBAS DE
SOFTWARE, LAS CUALES FACILITAN UNA GUÍA SISTEMÁTICA PARA DISEÑAR PRUEBAS QUE:
• -COMPRUEBEN LA LÓGICA INTERNA DE LOS COMPONENTES DEL SOFTWARE.
• -VERIFIQUEN LOS DOMINIOS DE ENTRADA Y SALIDA DEL PROGRAMA PARA DESCUBRIR ERRORES EN
LA FUNCIONALIDAD, EL COMPORTAMIENTO Y EL RENDIMIENTO.

6. ¿QUIÉN HACE LAS PRUEBAS?
• EL RESPONSABLE DE COMPROBAR Y PROCEDER CON LA CERTIFICACIÓN EN UNA PRIMERA
INSTANCIA ES EL ROL DEL CERTIFICADOR (ANALISTA, TESTER, QA, ETC). SIN EMBARGO,
CONFORME AVANZA CON EL PROCESO DE PRUEBA, OTROS ANALISTAS DE PRUEBAS SE PUEDEN IR
INCORPORANDO A LA CERTIFICACIÓN.

7. • PARA PRESSMAN EL OBJETIVO DEL DISEÑO DE PRUEBAS ES QUE SISTEMÁTICAMENTE SAQUEN A
LA LUZ DIFERENTES CLASES DE ERRORES, HACIÉNDOLO CON LA MENOR CANTIDAD DE TIEMPO
Y DE ESFUERZO. LA PRUEBA NO PUEDE ASEGURAR LA AUSENCIA DE DEFECTOS, SOLO PUEDE
DEMOSTRAR QUE EXISTEN DEFECTOS EN EL SOFTWARE.

8. • PASOS A SEGUIR:
• ANTES DE LA APLICACIÓN DE MÉTODOS PARA EL DISEÑO DE CASOS DE PRUEBA EFECTIVOS,
UN INGENIERO DEL SOFTWARE D EB ER Á ́ ENTENDER LOS PRINCIPIOS BÁSICOS QUE GUÍAN LAS
PRUEBAS DEL SOFTWARE:
• A TODAS LAS PRUEBAS SE LES DEBERÍA PODER HACER UN SEGUIMIENTO HASTA LOS
REQUISITOS DEL CLIENTE.
• EL OBJETIVO DE LAS PRUEBAS DEL SOFTWARE ES DESCUBRIR ERRORES. SE ENTIENDE QUE LOS
DEFECTOS MÁS GRAVES (DESDE EL PUNTO DE VISTA DEL CLIENTE) SON AQUELLOS QUE IMPIDEN AL
PROGRAMA CUMPLIR SUS REQUISITOS.
• LAS PRUEBAS DEBERÍAN PLANIFICARSE MUCHO ANTES DE QUE EMPIECEN.
• LA PLANIFICACIÓN DE LAS PRUEBAS PUEDE EMPEZAR TAN PRONTO COMO ESTÉ COMPLETO EL
MODELO DE REQUISITOS.
• EL PRINCIPIO DE PARETO ES APLICABLE A LA PRUEBA DEL SOFTWARE.
• EL PRINCIPIO DE PARETO IMPLICA QUE AL 80 POR 100 DE TODOS LOS ERRORES DESCUBIERTOS
DURANTE LAS PRUEBAS SE LES PUEDE HACER UN SEGUIMIENTO HASTA UN 20 POR 100 DE TODOS
LOS MÓDULOS DEL PROGRAMA.
• ENTRE OTRAS..

9. PLAN Y CASOS DE PRUEBAS
• PLAN DE PRUEBAS
• EL PLAN DE PRUEBAS TIENE COMO OBJETIVO ORIENTAR EL ESFUERZO DE PRUEBAS,
IDENTIFICANDO Y DETALLANDO LAS PRUEBAS MÁS IMPORTANTES, PARA QUE EL EQUIPO DE QA
PUEDA ENFOCARSE EN SU EJECUCIÓN Y RESPONDER DE FORMA ADECUADA A LOS CAMBIOS
QUE TIENE EL PROYECTO.
• PARA CONSTRUIR UN BUEN PLAN DE PRUEBAS, EL ROL DEL ANALISTA DE CERTIFICACIÓN DEBE
CONSIDERAR:
• OBJETIVOS DE NEGOCIO QUE TIENE QUE CUMPLIR EL SOFTWARE.
• CALENDARIO DEL PROYECTO.
• METODOLOGÍA DE DESARROLLO DEBE CONSIDERAR.
• Y CONSIDERAR LOS SIGUIENTES ÍTEMS EN LA CONSTRUCCIÓN:
• ANALIZAR LOS REQUERIMIENTOS DE DESARROLLO DE SOFTWARE.

10. CASOS DE PRUEBAS
• EL CASO DE PRUEBA ES LA CONDICIÓN ESTABLECIDA SOBRE UNA FUNCIONALIDAD A BAJO NIVEL
DEL APLICATIVO PARA DETERMINAR SU CORRECCIÓN. ES DECIR, EL CUMPLIMIENTO DEL RESULTADO
ESPERADO EN BASE A LAS DIRECTRICES ESTABLECIDAS AL INICIO DE LA CERTIFICACIÓN.
• TIPOS DE PRUEBAS
• PRUEBAS DE CAJA BLANCA
• DENOMINADA A VECES PRUEBA DE CAJA DE CRISTAL, ES UN MÉTODO DE DISEÑO DE CASOS DE
PRUEBA QUE USA LA ESTRUCTURA DE CONTROL DEL DISEÑO PROCEDIMENTAL PARA OBTENER LOS
CASOS DE PRUEBA.
• EL INGENIERO DEL SOFTWARE PUEDE OBTENER CASOS DE PRUEBA QUE:
• GARANTICEN QUE SE EJERCITA POR LO MENOS UNA VEZ TODOS LOS CAMINOS INDEPENDIENTES DE
CADA MODULO.
• PRUEBAS DE CAJA NEGRA
• LA PRUEBA DE CAJA NEGRA NO ES UNA ALTERNATIVA A LAS TÉCNICAS DE PRUEBA DE CAJA
BLANCA. MÁS BIEN SE TRATA DE UN ENFOQUE COMPLEMENTARIO QUE INTENTA DESCUBRIR
DIFERENTES TIPOS DE ERRORES QUE LOS MÉTODOS DE CAJA BLANCA.