[UP AND DOWN SAC] CHECKLIST DE VERIFICACIÓN DEL ANALISIS

[Sistema de gestión UP AND DOWN] [Versión: 01] | [Fecha de Revisión: 02/05/2019]

Checklist de Verificación – Etapa de Análisis

Para la verificación de:

Nombre del Proyecto Sistema de gestión UP AND DOWN

Nombre del Documento IMPLEMENTACIÓN DE UN SISTEMA DE INFORMACIÓN PARA LA MEJORA DEL PROCESO
ADMINISTRATIVO DE LA EMPRESA UP AND DOWN INVERSIONES SAC - TRUJILLO

Fecha 02/05/2019

Criterio Sí / No / NA Fuente

1. Correctitud

a. ¿Se tiene una correcta percepción y entendimiento del tamaño y complejidad del Si ROGPRES
sistema?

b. ¿Se tiene un equipo de trabajo con el numero correcto de participantes para Si ROGPRES
desarrollar las todas las necesidades del usuario?

c. ¿Se definió cada una de las tareas de cada miembro del equipo de trabajo? No CGMJDM

d. ¿Se identificaron las clases mediante el análisis de los escenarios de uso Si CGMJDM
desarrollados como parte del modelo de requerimientos?

e. ¿Los atributos que definen las clases se especificaron de acuerdo al contexto que No CGMJDM
se usara en el sistema?

f. ¿Se efectuó un análisis gramatical para la definición de las operaciones de cada Si ROGPRES
clase?

g. ¿La inteligencia del sistema está distribuida entre las clases para enfrentar mejor Si ROGPRES
las necesidades del problema?

h. ¿Se clasificaron correctamente los distintos elementos del modelo de análisis de Si SOM97
manera que se agrupen en un paquete de análisis?

i. ¿Se definieron correctamente las colaboraciones de las clases con las otras clases No SOM97
del sistema?

2. No Ambiguo

a. ¿La documentación se especifica de forma concisa? Si ISAD

b. ¿Las diferentes definiciones evitan causar confusiones al cliente? Si ISAD

c. ¿Las definiciones básicas evitan tener jergas informáticas? No MJON

Página 1
[UP AND DOWN SAC] CHECKLIST DE VERIFICACIÓN DEL ANALISIS

[Sistema de gestión UP AND DOWN] [Versión: 01] | [Fecha de Revisión: 02/05/2019]

d. ¿La documentación utilizan gráficos o notaciones formales para eliminar la Ni ASC

ambigüedad?

e. ¿Los distintos elementos evitan conflictos entre ellos? No ISAD

f. ¿La información del comportamiento esta definido de forma concisa? Si ISAD

Página 2
[UP AND DOWN SAC] CHECKLIST DE VERIFICACIÓN DEL ANALISIS

[Sistema de gestión UP AND DOWN] [Versión: 01] | [Fecha de Revisión: 02/05/2019]

3. Completitud

a. ¿El requerimiento descrito considera todos los elementos requeridos para sus No KUCHTA
especificaciones en la plantilla?

b. ¿Los requerimientos y elementos todos se proveen de todas las definiciones No KUCHTA

necesarias?

c. ¿El requerimiento especifica las referencias a los elementos de solución de demás No KUCHTA
documentos?

d. ¿Están todas las posibles interfaces y operaciones incluidas en la definición? N/A CARSON2

e. ¿Están especificados todos los flujos y alternativas de solución en el documento? N/A CARSON2

f. ¿La información contiene todos los objetos y entidades definidas? N/A THREE

g. ¿Están especificadas todas las características de comportamiento importantes Si LEVESON

identificadas o implícitas en la especificación del sistema?

4. Consistencia

a. ¿Se presenta de forma clara la información del problema? Si ISAD

b. ¿Se define de forma concisa las funciones que debe realizar el software? No MJON

c. ¿El documento presentado describe el rendimiento del sistema? No MJON

d. ¿Los procesos de datos evitan conflictos con el desarrollo del software? Si ASC

e. ¿La información del problema se muestra de forma detallada? Si ASC

f. ¿Se identifican de forma concisa las metas globales del sistema? Si ISAD

Página 3
[UP AND DOWN SAC] CHECKLIST DE VERIFICACIÓN DEL ANALISIS

[Sistema de gestión UP AND DOWN] [Versión: 01] | [Fecha de Revisión: 02/05/2019]

5. Categorizado por importancia y/o estabilidad

a. ¿Está explicita la importancia de cada documento de analisis? SI ROGPRES

b. ¿Los documentos de análisis fueron priorizados según su importancia? SI ROGPRES

c. ¿Los documentos de análisis están relacionados con el objetivo de negocio? SI ROGPRES

6. Verificable ROGPRES

a. ¿Se le puede aplicar técnicas para revisar el analisis? NO ROGPRES

b. ¿El análisis esta documentado correctamente? SI ROGPRES

c. ¿El análisis es suficiente para realizar el proyecto? NO ROGPRES

d. ¿Esta descrito correctamente los documentos de análisis? SI ROGPRES

e. ¿Los documentos de análisis son intuitivos? SI ROGPRES

7. Modificable

a. ¿El análisis del requerimiento y sus correcciones tienen riesgos altos? NO SAWO

b. ¿Las entrevistas, cuestionarios, observaciones tienen cambios constantes? NO SAWO

c. ¿La etapa de análisis es susceptible a cambios debido a la construcción SI SAWO

posterior?

d. ¿Podemos hacer cambios en el modelo o desecharlo y hacer uno nuevo? SI SAWO

e. ¿El analista debe comprender completamente la recolección de usuarios par ano SI SAWO
provocar cambios futuros?

f. ¿El software sufríra cambios pero estos deben de estar reflejados en el análisis? SI JOFED

g. ¿Las necesidades del cliente pueden cambiar debido nuevas necesidades ? SI HENF

8. Trazable

a. ¿El análisis es fundamental para la colección de requerimientos? SI SAWO

b. ¿El documento de análisis contempla la especificación detallada de los SI SAWO

requerimientos de software?

c. ¿Constituyen la descripción inicial del sistema? SI SAWO

d. ¿Delimita el alcance del sistema? SI SAWO

e. ¿Los requisitos de los usuarios están plasmados en el documento de análisis? SI SAWO

f. ¿La naturaleza del sistema se ve reflejado en el análisis de? SI JOFED

g. ¿El análisis se ve plasmado enteramente en el diseño? SI JOFED

Página 4
[UP AND DOWN SAC] CHECKLIST DE VERIFICACIÓN DEL ANALISIS

[Sistema de gestión UP AND DOWN] [Versión: 01] | [Fecha de Revisión: 02/05/2019]

Página 5
[UP AND DOWN SAC] CHECKLIST DE VERIFICACIÓN DEL ANALISIS

[Sistema de gestión UP AND DOWN] [Versión: 01] | [Fecha de Revisión: 02/05/2019]

 Referencias:

Acrónimo Fuente

SAWO Sandra Wong Durand, Análisis y requerimientos de software

JOFED Joaquín Federico Fuentes, Realidad virtual aplicada al tratamiento del trastorno de lateralidad y
ubicación espacial Tesis profesional

HENF Henry F. Korth & Abraham Silberschatz, Planificación de un proyecto de sistemas.

ROGPRES Roger R. Pressman - Ingeniería de Software 7ma Edicion

SOM97 Sommerville, I., Sawyer, P. Requirements Engineering, Chichester, Jhon Wiley & Sons, 1997

CGMJDM Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli. - Fundamentals of Software Engineering 1991

ISAD Ingenieria de Software, Analisis y Diseño

ASC Analisis de Sistemas de Computacion

MJON Molina Rios Jimmy, Tapia Joofre, Zea Ordoñez Mariuxi, Nociones de ingenieria de software

JMCS10 Martínez, J. y Silva C. Anexo 2 Ingeniería de Requerimientos: “Guía Metodológica para el

levantamiento y análisis de Requerimientos de Software en base a Procesos de Negocio”,

PRESS10 Pressman R. Ingeniería del software: Un enfoque práctico, University of Connecticut, 2010

WIBEA13 Wiegers K. y Beatty J. Software Requirements, Microsoft Press, 2013

KUCHTA Kuchta J. Completeness and Consistency of the System Requirement Specification, Faculty of
Electronics, Telecommunications and Informatics,Gdansk University of Technology,

WERTRY16 Werneman A. y Tryggvesson J., Correctness and Completeness in Requirement Engineering, FUSE
Seminar, 2016

CARSON Carson R. Requirements Completeness, International Council on Systems Engineering

CARSON2 Carson R. Requirements Completeness: A Deterministic Approach, Information and Communications

Systems Boeing Information, Space, and Defense Systems

THREE The Three Cs of Requirements: Consistency, Completeness, and Correctness

Página 6