integrantes alex santacruz daniel mesías danilo taimbud mauricio velasco juan carlos martínez

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 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


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



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.


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

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

integrantes alex santacruz daniel mesías danilo taimbud mauricio velasco juan carlos martínez

Documents