INTEGRANTES Alex Santacruz Daniel Mesías Danilo Taimbud

Presentación del tema: "INTEGRANTES Alex Santacruz Daniel Mesías Danilo Taimbud"— Transcripción de la presentación:

1 INTEGRANTES Alex Santacruz Daniel Mesías Danilo Taimbud
Mauricio Velasco Juan Carlos Martínez

2 TEMA CONTROL, VERIFICACION Y VALIDACION DE LA CALIDAD DEL SOFTWARE
«FACTORY» UTILIZADO PARA REALIZAR CUENTAS POR COBRAR

3 PRESENTACION SISTEMA CONTROL INTERNO (FACTORY)

4 Sistema Control Interno
PLATAFORMA DE DESARROLLO VISUAL FOX PRO 6.0 SQL SERVER 2008 REQUERIMIENTOS PARA SU FUNCIONAMIENTO Computador Pentium 4 o Superior Sistema Operativo Windows SP3 de 32 bits Procesador de 3Ghz o superior 1Gb de RAM 300 Mb de Espacio en Disco

5 Sistema Control Interno
PLATAFORMA DE DESARROLLO VISUAL FOX PRO 6.0 SQL SERVER 2008 REQUERIMIENTOS PARA SU FUNCIONAMIENTO Computador Pentium 4 o Superior Sistema Operativo Windows SP3 de 32 bits Procesador de 3Ghz o superior 1Gb de RAM 300 Mb de Espacio en Disco

6 Sistema Control Interno
MODULOS DEL SISTEMA CONTROL INTERNO Empresa dedicada a sistemas contables abarcando los módulos de : Contabilidad Inventarios –Facturas /Modulo conectado con cartera cuentas por cobrar e información de las misma Clientes-Información / Modulo conectado con clientes e información Proveedores Roles

7 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

8

9

10 CONTROL DE CALIDAD DE SOFTWARE

11 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

12 ¿Qué es 'Control de Calidad'?
Punto de vista del: Industria Cliente Punto de vista del cliente: El grado en que un cliente y/o usuario percibe que el producto software satisface sus necesidades. Punto de vista de la industria: Grado en el que un producto de software satisface su especificación de requerimientos

13 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

14 Control de Calidad de Software
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. Otro motivo para el control de calidad es que la prueba de software no puede garantizar que encuentre todos los errores A causa de esto, la propuesta de control de calidad es empujar las tareas relacionadas con la calidad desde las primeras fases del proyecto. Esto permite encontrar los errores en forma temprana sin que se sigan propagando en las siguientes fases

15 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

16 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 Control de calidad implica vigilar el proceso de desarrollo de software para asegurar que se siguen los procedimientos y los estándares de garantía de calidad, en el proceso de control de calidad se comprueba que las entregas cumplan con los estándares definidos. Consiste en revisar que al final el producto cumpla los requerimientos del cliente.

17 Control de Calidad de Software
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 El control de calidad del software abarca todo el proceso de desarrollo: supervisar y mejorar el proceso, asegurar que se siguen los procedimientos acordados, que se alcanza el nivel de calidad deseado y que se localizan y resuelven los problemas.

18 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. Al aplicar control de Calidad en el desarrollo de un proyecto de software se solucionan problemas como: en la empresa y usuario en particular, en la calidad en general, en la administración del proyecto en cada una de las fases del ciclo de vida del sistema

19 Control de Calidad de Software
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 la Calidad de Software (Software Quality Control): 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.

20 Control de Calidad de Software

21 Para considerar un software como un producto de alta calidad se deben establecer:
Normas mínimas a cumplir Procedimientos en el desarrollo y en el control en cada fase del ciclo de vida del producto Estructura organizacional del proyecto Tareas y responsabilidades especificas del personal encargado de llevar a cabo las pruebas Documentación a preparar para revisar la constancia del producto. Técnicas para llevar acabo auditoria y pruebas requeridas Estándares, normas y especificaciones a usuario

22 Controlar Calidad de Software
Definir Parámetros Indicadores Criterios de Medición Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores y criterios de medición. El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.

23 Proceso de Control Definir el software que va a ser controlado:
Es necesario definir los siguientes pasos: 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: Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

24 Proceso de desarrollo del 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 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. Implica vigilar el proceso de desarrollo del software para asegurar que se sigan los procedimientos y los estándares de garantía de calidad 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.

25 Quality Control (QC) ≠ Quality Assurance (QA)

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

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

28 Software Quality Assurance
QA Diseño de Aplicación QA de Código QA Unitario QA Integral QA Diseño de Aplicación: Efectuamos una exhaustiva revisión del análisis. A tal fin, se evalúan especificaciones de casos de uso, diagrama de transición de estado, diagramas de bases de datos, documentación, reglas de negocio y demás elementos que nos permitan aseguramos la consistencia de la solución planteada y su cobertura de acuerdo a los requerimientos. QA de Código: Efectuamos una revisión completa de código mediante la aplicación de reglas y estándares de desarrollo; basamos este test en las buenas prácticas de programación las cuales utilizamos en forma constante para todos nuestros desarrollos. De esta manera confirmamos que el código sea consistente y nos permita detectar errores antes de comenzar con las pruebas unitarias. QA Unitario: Planificamos y ejecutamos pruebas a medida que el desarrollo avanza. Estas pruebas son pruebas de componentes aislados del software, lo que nos permite ganar tiempo en el testeo general de la aplicación. Una vez que la aplicación llega a determinado porcentaje de completitud, se procede a realizar pruebas integrales. Con esto garantizamos el funcionamiento individual de los distintos componentes del software. QA Integral: Durante la etapa de cierre del proyecto, se procede a realizar pruebas integrales para probar el software como un todo.

29 No hay grandes diferencias respecto a proyectos
cerrados: Estilo y buenas prácticas Auditorías de código Tests unitarios Tests de integración Tests de regresión Dentro del departamento de desarrollo Ayuda a desarrollar: detección temprana de defectos

30 Ciclo del Testing En general, nunca se aclara cómo hacer para saber si un caso de prueba descubrió un error o no. Obviamente, eso lo dice la especificación. Sin especificación es imposible testear, pues la corrección se define con respecto a la especificación. ' Para algunos la especificación está tan ausente o lejana que la suelen llamar oráculo. ' En muchos casos el oráculo es el cliente. ' En muchos casos el testing es una farsa.

31 Ciclo del Testing

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

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

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

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

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

37 Ciclo del Testing Ejemplo de planificación de entregas al Departamento de Calidad:

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

39 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

40 Relación entre productos de desarrollados y Niveles de Pruebas
Requisitos de usuario Pruebas de aceptación Especificación de requisitos Pruebas de sistema Diseño modular Pruebas de integración Especificación lógica del módulo Pruebas de unidad Código

41 Pruebas de Caja Negra y Caja Blanca

42 Pruebas de Caja Negra y Caja Blanca
Hay 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)

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

44 VERIFICACION Y VALIDACION

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

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

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

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

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

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

51 Necesidades del Cliente
VALIDACIÓN Validación Necesidades del Cliente Producto la validación es asegurar que el sistema software cumpla adecuadamente las necesidades del cliente

52 Validación del Software
Evaluación Interna Evaluación Externa Revisión de Requerimientos Rectificar y Mejorar Estándares de Calidad

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

54 Validación del software después de un cambio.
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.

55 Ciclo de vida del software

56 Documentación de la validación
La 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.

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

58 Documentación