Upload
roberta-alverez
View
225
Download
0
Embed Size (px)
Citation preview
INTEGRANTES
Alex Santacruz Daniel Mesías
Danilo TaimbudMauricio Velasco
Juan Carlos Martínez
TEMA
CONTROL, VERIFICACION Y
VALIDACION DE LA CALIDAD DEL SOFTWARE «FACTORY»
UTILIZADO PARA REALIZAR CUENTAS
POR COBRAR
PRESENTACION
SISTEMA CONTROL INTERNO
(FACTORY)
Sistema Control Interno
PLATAFORMA DE DESARROLLOVISUAL FOX PRO 6.0SQL SERVER 2008
REQUERIMIENTOS PARA SU FUNCIONAMIENTOComputador Pentium 4 o SuperiorSistema Operativo Windows SP3 de 32 bits Procesador de 3Ghz o superior1Gb de RAM300 Mb de Espacio en Disco
Sistema Control Interno
PLATAFORMA DE DESARROLLOVISUAL FOX PRO 6.0SQL SERVER 2008
REQUERIMIENTOS PARA SU FUNCIONAMIENTOComputador Pentium 4 o SuperiorSistema Operativo Windows SP3 de 32 bits Procesador de 3Ghz o superior1Gb de RAM300 Mb de Espacio en Disco
Sistema Control InternoMODULOS DEL SISTEMA CONTROL INTERNO
Empresa dedicada a sistemas contables abarcando los módulos de :
ContabilidadInventarios –Facturas /Modulo conectado con cartera cuentas por cobrar e información de las mismaClientes-Información / Modulo conectado con clientes e informaciónProveedoresRoles
PROGRAMA DE CONTROL INTERNO DE CUENTAS POR COBRAR
REGISTRO DE INGRESO MENSAJE ,DE USUARIO Y CONTRASEÑA ,DADA POR EL ADMINISTARDOR ,PARA EL INGRESO AL PROGRAMA ARCHIVO/CONFIGURACION GENERAL/DIRECTORIO DE TRABAJO
ANEXA LA INFORMACION DEL PROGRAMA DECISIÓN (PROGRAMA CONTABLE) DEL PERIODO DE LAS CUENTAS POR COBRAR E INFORMACION DE LOS CLEINTES
SOPORTE TECNICO /REGISTRO DE TAREAS
INFORMACION DE TAREAS DE LOS TECNICOS CON FECHAS Y DETALLES SOPORTE TECNICO /TAREAS PENDIENTES
TAREAS PENDIENTES DE LOS TECNICOS Y POR HACER EN LAS EMPRESAS CON FECHAS Y DETALLES REGISTRO DE TAREAS/SOPORTE TECNICO
EL TECNICO INGRESA LA VISITA TECNICA , HACIENDO REFERENCIA A LA FECHA Y A LA EMPRESA ASISTENTE TECNICO /REGISTRO DE ASISTENCIAS
EL REGISTRO DE ASISTENCIAS QUE HUBO CON LA EMPRESA EL CODIGO DE PROGRAMA, EL CONTACTO DE LA EMPRESA, YA SE POR FECHA ,CLIENTE O POR EL TECNICO QUE LA REALIZO
CONTROL DE CARTERA /REGISTRO DE COBROS
LOS COBROS POR FACTURA QUE ESTAN PENDIENTES CON INFORMACION DE : FECHAS,CLIENTES,VALORES E INFORMACION DE LA EMPRESA CONTROL DE CARTERA/CONTROL DE LLAMADAS
LAS LLAMADAS COBROS Y DETALLES DE LA RESPUESTA QUE SE RECIVE DE LOS CLIENTES POR LOS PAGOS ,HACIENDO REFERENCIA EN FECHAS ,CONTACTOS DE LAS EMPRESAS CONTACTOS/REGISTRO DE CONTACTOS
LA INFORMACION DE LOS CONTACTOS DIRECTOS DE LAS EMPRESA A LAS CUALES NOS CONTACTAMOS PARA LOS COBROS CONTACTOS/REPORTES Y CONSULTAS/CONSULTA GENERAL INFORMACION DE LOS CONTACTOS Y EMPRESAS
COTIZACION /REGISTRO DE COTIZACION
LA INFORMACION DE CONTACTOS A LOS QUE SE LES A ENVIADO LAS COTIZACIONES DE LOS PROGRAMAS CONTABLES COTIZACION /REGISTRO DE COTIZACION
LAS COTIZACIONES QUE SE HAN ENVIADO ,PERO LAS QUE ESTAN PENDIENTES, DE LOS PROGRAMAS Y MODULOS NECESARIOS CONTABLES COTIZACION/COTIZACIONES ACEPTADAS
LA INFORMACION DE CONTACTOS DE LAS COTIZACIONES ACEPTADAS DE MODULOS CONFIRMADOS Y PROGRAMAS COMISIONES/GENERAR COMSIONES REPORTES DE LA INFORMACION EN COTIZACIONES PENDIENTES Y ACEPTADAS EN UN RANGO DE FECHAS.
? INFORMACION SOBRE EL PROGRAMA
CONTROL DE CALIDAD
DE SOFTWARE
Objetivos Planificar las actividades de
aseguramiento de la calidad Revisar objetivamente los productos y
las actividades para verificar que estén conformes con los procedimientos y estándares
Mantener bajo control un proceso, eliminar las causas de los defectos en los diferentes módulos del software
¿Qué es 'Control de Calidad'?
Cliente Industria
Punto de vista del:
Definición Son las técnicas y actividades de carácter
operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales:
– mantener bajo control un proceso – eliminar las causas de los defectos en
las diferentes fases del ciclo de vida En general son las actividades para evaluar
la calidad de los productos desarrollados
El costo de corregir y detectar errores producidos en las primeras fases de desarrollo de software es mayor a medida que nos encontramos más alejados de éstas.
Control de Calidad de Software
Otro motivo para el control de calidad es que la prueba de software no puede garantizar que encuentre todos los errores
La garantía de calidad de software engloba: métodos y herramientas de análisis, diseño,
codificación y prueba revisiones y técnicas formales que se aplican
en cada fase de la ingeniería de software una estrategia de prueba multiescalada el control de la documentación del software y
de los cambios efectuados un procedimiento que asegure un ajuste a los
estándares de desarrollo mecanismos a medida y de información
Control de Calidad de Software
Implica vigilar el proceso de desarrollo del software para asegurar que se sigan los procedimientos y los estándares de garantía de calidad
Abarca todo el proceso de desarrollo
Supervisa y mejora el proceso,
Asegurar que se siguen los procedimientos acordados
Se alcanza el nivel de calidad deseado y se localizan y resuelven los problemas
Control de Calidad de Software
Control de Calidad de Software
Al aplicar control de calidad en el desarrollo de un proyecto
de software se solucionan problemas: En la empresa y usuario
en particular En la calidad en
general. En la administración del
proyecto del software. En cada una de las
fases del ciclo de vida del sistema.
Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requisitos relativos a la calidad, centrados en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
Control de Calidad de Software
Control de Calidad de Software
Para considerar un software como un producto de alta calidad se deben establecer:
El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Definir el software que va a ser controlado:
Seleccionar una medida que pueda ser aplicada al objeto de control.
Crear o determinar los métodos de valoración de los indicadores:
Definir las regulaciones organizativas para realizar el control:
Es necesario definir los siguientes pasos:
Proceso de Control
Implica vigilar el proceso de desarrollo del software para asegurar que se sigan los procedimientos y los estándares de garantía de calidad
Proceso de desarrollo del Software
En el proceso de control de calidad se comprueba que las entregas cumplan con los entandares definidos, consiste en revisar que al final el producto cumpla los requerimientos del cliente.
Quality Control (QC)
≠Quality Assurance
(QA)
Software Quality Control (QC)
Realización de pruebas para detectar defectos,bloqueando la publicación de productos defectuosos y mejorando el resultado
en diferentes iteraciones del ciclo de entrega
certificación.
Software Quality Assurance
Son los mecanismos que se implican en el proceso
de desarrollo, verificando que se sigue unos
estándares y procedimientos, y asegurando que
los problemas se encuentran y se tratan adecuadamente.
Software Quality Assurance
No hay grandes diferencias respecto a proyectoscerrados:Estilo y buenas prácticasAuditorías de códigoTests unitariosTests de integraciónTests de regresiónDentro del departamento de desarrollo Ayuda a desarrollar: detección temprana de defectos
Ciclo del Testing
Ciclo del Testing
Testing La forma más natural de verificar un software es:
ejecutarlo en una serie de situaciones representativas, verificar que su comportamiento sea el esperado.
Hay que elegir un conjunto de datos de prueba apropiado porque no es posible probar absolutamente todas las posibilidades: deben ser los menos posibles para tener menos trabajo, pero deben cubrir la mayor cantidad de casos posibles.
La tarea de elegir el conjunto de datos de prueba es algo complejo: un puente que mostró soportar 100 toneladas podemos
asumir que también soportará 10 toneladas. ¿Analogía?
Testing: Prueba de Software La prueba del software es una actividad
crítica de la ingeniería de software. Debe aplicarse en forma sistemática:
explicitar claramente los resultados esperados, describir la forma de obtener los resultados, documentar los resultados obtenidos.
En la práctica, la prueba del software se hace: en forma desestructurada, sin aplicar criterios claros.
Utilidad de las Pruebas Si las pruebas no dan certeza sobre la
corrección del software, ¿tienen alguna utilidad?
Si bien no proporcionan certeza, las pruebas pueden aumentar nuestra confianza en que el sistema se comportará como es esperado.
Lo esencial de las pruebas es: elegir un conjunto de datos de prueba
apropiados, aplicar las pruebas en forma sistemática.
Localizable, Repetible y Precisas Las pruebas no solamente deben detectar la
presencia de errores, sino que deben indicar cuál es el error y dónde se encuentra.
Las pruebas deben organizarse para que provean información acerca de la localización de los errores.
Las pruebas también deben ser repetibles: aplicadas dos veces, debieran producir los mismos resultados.
La influencia del ambiente de ejecución atenta contra la repetibilidad de las pruebas.
Los resultados esperados deben definirse dependiendo de los datos de entrada y de otros eventos del ambiente.
Más sobre Faltas y Fallas Una falla solamente ocurre si existe una
falta. ¿Qué ocurre si un defecto no provoca
una falla? ¿Qué ocurre si una falta no produce una
falla?
Ciclo del TestingEjemplo de planificación de entregas al Departamento de Calidad:
Pruebas del Sistema Al final del desarrollo el software se incorpora a
otros elementos del sistema (hardware, personas, información) y se realiza una serie de pruebas de integración del sistema y de validación.
Estas pruebas están más allá del alcance del proceso del software y no las realizan únicamente los ingenieros de software.
Sin embargo, los pasos dados durante el diseño y la prueba del software mejorarán en gran medida la probabilidad de tener éxito en la integración del software del sistema mayor.
Niveles de Test o prueba Prueba de Unidad: es la prueba de cada módulo, que normalmente
realiza el propio personal de desarrollo en su entorno
Prueba de Integración: con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto
Prueba de validación: el software totalmente ensamblado se prueba como un todo para comprobar si cumple los requisitos funcionales y de rendimiento, facilidad de mantenimiento, recuperación de errores, etc.
Prueba del sistema: el software. ya validado se integra con el resto del sistema (rendimiento, seguridad, recuperación y resistencia)
Prueba de aceptación: el usuario comprueba en su propio entorno de explotación si lo acepta como está o no
Requisitos de usuario
Especificación de requisitos
Diseño modular
Especificación lógica del módulo
Pruebas de sistema
Pruebas de integración
Pruebas de unidad
Pruebas de aceptación
Código
Relación entre productos de desarrollados y Niveles de Pruebas
Pruebas de Caja Negra y Caja Blanca
Pruebas de Caja Negra y Caja BlancaHay dos maneras de probar cualquier producto
construido:
1. Si se conoce la función específica para la que se diseño el producto, se aplican pruebas, que demuestren que cada función es plenamente operacional, mientras se buscan los errores de cada función. (Prueba de Caja Negra)
2. Si se conoce el funcionamiento interno del producto, se aplican
pruebas para asegurarse de que todas las “piezas encajan”, es
decir, que las operaciones internas se realizan de acuerdo a las
especificaciones, y que se han probado todos los componentes
internos de manera adecuada. (Prueba de Caja Blanca)
Pruebas de Caja Negra y Caja Blanca Las pruebas de caja negra son las que se aplican a
la interfaz del software.
Una prueba de caja negra examina algún aspecto funcional de un sistema que tiene poca relación con la estructura lógica interna del software.
La prueba de caja blanca del software se basa en un examen cercano al detalle procedimental.
En la prueba de caja blanca se prueban las rutas lógicas del software y la colaboración entre componentes, al proporcionar casos de prueba que ejerciten conjuntos específicos de condiciones, bucles o ambos.
VERIFICACIONY
VALIDACION
VALIDACION Y VERIFICACION
Verificación de Software
Existen autores que hacen diferencia entre verificación y validación de software: verificación: el software es correcto, está
implementado acorde a sus especificaciones; validación: el software es útil para satisfacer las
necesidades del usuario. La verificación del software es el proceso a través
del cual se corrobora que el software satisface sus objetivos.
Todo debe ser verificado Todas las cualidades relevantes del
sistema deben ser verificadas: corrección: la implementación se
comporta de acuerdo con las especificaciones;
portabilidad, modificabilidad, performance. Etc.
La verificación debe realizarse por distintas personas durante distintas etapas del desarrollo del software; La gente del equipo de desarrollo
podría realizar esto.
Resultado de la Verificación
Después de hacer una serie de pruebas de verificación no se llega a una conclusión tajante: “el producto está bueno y lo ponemos en
comercialización”; “el producto está malo y debemos
desecharlo”. Más bien se llega a tener una idea conceptual
de la calidad del software. Supuestos sobre la verificación de software:
la presencia de defectos no puede evitarse en grandes sistemas de software,
a veces, algunos defectos pueden tolerarse, la corrección es relativa y difícil de evaluar.
Verificación Objetiva o Subjetiva Algunas pruebas del
sistema son objetivas: dar una entrada y
verificar la corrección de la salida,
medir el tiempo de respuesta de una transacción.
Otras cualidades no pueden medirse tan objetivamente: portabilidad: sólo puede
decirse algo acerca de cuán difícil sería portar el software a un ambiente particular;
modificabilidad: el sistema será más o menos modificable de acuerdo al cambio a aplicar. Es deseable sin embargo poder decir algo más general
sobre las cualidades del software: estimaciones subjetivas. portabilidad: el software está desarrollado en java, o sea
que podrá correr en cualquier máquina.
Enfoques de Verificación Existen dos enfoques fundamentales:
Test: experimentar con el comportamiento del sistema;
Análisis: comprobar propiedades del sistema. Otra clasificación de la verificación:
Dinámica: requiere ejecutar el software; Estática: no requiere ejecución.
Afortunadamente todos los enfoques son complementarios.
Sistema Control Interno (FACTORY) ¿Están incluidas todas las funciones
requeridas por el cliente?
• ¿Existen conflictos en los requerimientos?
• ¿Tiene alguno de los requerimientos más de una interpretación?
• ¿Está cada requerimiento claramente representado?
VALIDACIÓN
la validación es asegurar que el sistema software cumpla adecuadamente las necesidades del cliente
ProductoNecesidades del Cliente
ValidaciónValidación
Validación del Software Evaluación Interna
Evaluación Externa
Revisión de Requerimientos
Rectificar y Mejorar
Estándares de Calidad
Principios generales a utilizar en la validación Especificación de los requisitos.
Especifica los requisitos del software de forma documentada, esto es la base para realizar el proceso de verificación y validación
Prevención de defectos. Prevé los defectos en el proceso de desarrollo del software y no en probar la calidad del código del software después que se escribe.
Tiempo y esfuerzo. La validación debe comenzar con anticipación; es decir, durante la planificación del diseño, desarrollo y el diseño de la entrada de datos, mediante esfuerzos planificados a lo largo de todo el ciclo de vida del software.
Ciclo de vida del software. Se selecciona el modelo más apropiado para establecer las etapas del ciclo de vida del software.
Planificación. Se especifica los aspectos tales como el alcance, el método de validación, los recursos, el cronograma, los tipos y la magnitud de las actividades que se deben llevar a cabo para la validación.
Procedimientos. Se establecen los procedimientos documentos “como”, “quien”, “cuando” va a llevara a cabo la validación.
Validación del software después de un cambio. Debido a la complejidad del software, un cambio aparentemente pequeño puede tener un impacto significativo en todo el sistema. Siempre que el software sea cambiado, un análisis de validación debe dirigirse al cambio individual y también para determinar la magnitud e impacto de ese cambio en la totalidad del software.
Alcance de la validación. El alcance de la validación debe estar basado en la complejidad del software y en los riegos de seguridad; no en el tamaño de la organización o la restricción de los recursos. La documentación de la validación debe ser suficiente para demostrar que todos los planes y procedimientos de validación del software se han completado con éxito.
Flexibilidad y responsabilidad. El fabricante o desarrollador del software tiene flexibilidad a la hora de escoger como aplicar estos principios de validación, pero es él, el responsable de demostrar que el software se ha validado.
Ciclo de vida del software
Documentación de la validaciónLa documentación de la validación del software debe incluir los siguientes aspectos:
Los requisitos definidos por el usuario. El plan de desarrollo del software. El protocolo de validación utilizado. El criterio de aceptación.Las pruebas y sus resultados.Las conclusiones sobre si el software se ajusta o no al uso previsto.El manual del usuario del software.
Sistema Control Interno (FACTORY) ¿Pueden los requerimientos ser
implementados con la tecnología y el presupuesto disponible?
• ¿Está la SRS escrita en un lenguaje apropiado?
• ¿Existe facilidad para hacer cambios en los requerimientos?
• ¿Está claramente definido el origen de cada requisito?
• ¿Pueden los requerimientos ser sometidos a medidas cuantitativas?
Documentación