PLAN DE CALIDAD DEL PROYECTO INTEGRANTES CEBRIÁN GUERRERO, Saskia RAMOS RAMÍREZ, José Fernando RIVERA HERBOZO, Moisés Alfredo RODRÍGUEZ NOBLECILLA, Antonio.

Slides:



Advertisements
Presentaciones similares
Ciclo de vida de desarrollo de software
Advertisements

ingeniería de software
PROCEDIMIENTO AUDITORIAS INTERNAS.
VALORACIÓN Y SELECCIÓN DE INVERSIONES EN RECURSOS INFORMÁTICOS
Metodologías ágiles.
PROCESO Y MODELOS EN LA INGENIERIA DE SOFTWARE
Planificación del Proyecto
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Fase Elaboración Conclusiones Grupo 6 – PIS
Proceso de Originación de Crédito: Banco de los Alpes
SI187 – Calidad de Software y Sistemas
Proyecto de Ingeniería de Software 2008
Administración de Procesos de Pruebas
Trabajo Práctico Taller de Desarrollo de Proyectos 2 Septiembre 2009.
ITERASOFT. OBJETIVOS DEL GRUPO Producir un sistema Manejador de Itinerarios de alta calidad y confiabilidad Realizar un proyecto bien administrado y productivo.
TEAM SOFTWARE PROCESS CICLO 3.  Análisis del Proyecto  Producto  Resultados por Rol  Resultado del Proceso.
MAESTRÍA DE GERENCIA EN SISTEMA
Papeles de trabajo para la auditoria de sistemas computacionales
REQUERIMIENTOS DE SOFTWARE
Planeación con Planning Tool y DotProject Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Rubby Casallas, Andrés Yie.
Unidad VI Documentación
El tipo de proyectos puede utilizar una metodología específica
Proyecto de Ingeniería de Software Grupo 9 Septiembre 2009
VII Congreso de Expotecnología UVM 2007 Jonás A. Montilva C.
Proceso de Gestión de Proyectos
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
Ximena Romano – Doris Correa
Areas de Proceso del Modelo CMMI-DEV
Proyecto I Maestría en Gerencia de Sistemas
Ingeniería de Software
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
SI187 – Calidad de Software y Sistemas Setiembre Lima – Perú Ciclo 2010 – 2 Equipo 5 1 Informe de diagnóstico de la Empresa “IT- Expert”
Técnicas de Estimación de Esfuerzo
35 años de investigación, innovando con energía 1 Mayo, 2012 P LAN DE ASEGURAMIENTO DE LA CALIDAD DEL DESARROLLO DE SOFTWARE E STÁNDAR IEEE 730 Y G UÍA.
Especialización en Desarrollo de Software
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
Proyecto de Ingeniería de Software Grupo Nº 9 - GXPost (Desarrollo con GeneXus 8.0) Evaluación de la Fase Construcción (Jueves 4 de Noviembre de.
El rol de SQA en PIS.
PRESENTACIÓN Este trabajo se desarrolla sobre el tema de competencias, y basado en el Marco de Fundamentacion Conceptual Especificaciones de la Pruebas.
INGENIERIA DE SOFTWARE
Introducción a las Ingenierías de la Información
Grupo 10 – 2008 Proyecto de Ingeniería de Software
Roles de Open UP.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Producto SETI Buenos Aires, Septiembre 2008 Propuesta de Servicios Consultoría. Soluciones informáticas.
DISEÑO CURRICULAR Presentado por: Cesar Augusto Sáenz María Alejandra Hernández 1.contenidos curriculares de competencia.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Introducción al proceso de verificación y validación.
Proyecto: Lanzamiento QUICK ORDER. Objetivo General  Desarrollar el sistema de información de acuerdo a los requerimientos establecidos por el cliente,
problemas de la calidad del software
Estructurar tus ideas para hacerlas realidad
Implementando PSP / TSP
TEMA: RESPONSABILIDAD DE ERRORES
REVISION Y AUDITORIA.
*Acquisition is subject to shareholder and regulatory approvals and customary closing conditions and is anticipated to close in the third calendar quarter.
Sistema de control de calidad de software
FACULTAD DE CIENCIAS COMPUTACIONALES Y TELECOMUNICACIONES ASIGNATURA:
Proyecto de Ingeniería de Software 2008 Proyecto TITA Soft. Grupo 02.
Documentos del Programa de Garantía de Calidad de Software
Administración de Proyectos de Software
EI, Profesor Ramón Castro Liceaga IV. AREAS DE EVALUACIÓN DE LA AUDITORIA EN INFORMÁTICA. UNIVERSIDAD LATINA (UNILA)
Autor: Reinozo Cuesta Christian Marcelo
Modelo de procesos de software
TEAM SOFTWARE PROCESS CICLO 1. El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de.
Aseguramiento de la Calidad. (Software Quality Assurance, SQA) Por. Ing. Ernesto Soto Roca.
Plan de Pruebas de Aceptación
Integrantes: Mejía Zúñiga Yoselin Taco Apaza Pamela Ychuta Torres John.
Taller de Desarrollo de Proyectos II (75.47) 2º cuatrimestre 2008.
Fase de Inicio Proceso Unificado de Desarrollo de Software.
Transcripción de la presentación:

PLAN DE CALIDAD DEL PROYECTO INTEGRANTES CEBRIÁN GUERRERO, Saskia RAMOS RAMÍREZ, José Fernando RIVERA HERBOZO, Moisés Alfredo RODRÍGUEZ NOBLECILLA, Antonio Daniel SOTO TAIRA, Leonardo Ángel 22 de Septiembre de 2010

1. OBJETIVOS DEL PLAN DE CALIDAD  El objetivo principal del presente documento es definir las actividades de control y aseguramiento de la calidad para el proyecto GEPP de la empresa SSIA. Sirve para poder identificar si el proyecto está cumpliendo con los estándares establecidos por la empresa, y, si se están realizando dichos entregables, tantos software como documentos, de manera correcta.  Además, contiene una lista de documentos y puntos importantes con los que deben contar los documentos para ser considerados de calidad, se brinda, en teoría, las reglas mínimas con las que debe contar un documento o programa en dicha empresa.

2. ALCANCE DEL PLAN DE CALIDAD PROYECTO: Sistema de Generación de Evidencias de Prácticas Pre-Profesionales –GEPPP DESCRIPCIÓN DEL PROYECTO: El proyecto GEPPP permitirá obtener, de forma automatizada, indicadores medibles que describan los niveles alcanzados por los programas académicos a través de la evidencia acumulada en los informes de prácticas pre-profesionales; de igual manera, a través de la interpretación y transformación de esta información, presentar los niveles alcanzados según los program outcomes que ABET propone para acreditar los programas de Ingeniería CAC (a – i) y EAC (a – k). Dichos indicadores proporcionarán un sustento confiable sobre el nivel de calidad del programa académico y permitirá mostrar la efectividad de los criterios, para así identificar deficiencias y plantear propuestas de mejora en caso sea necesario.

2. ALCANCE DEL PLAN DE CALIDAD PROCESOSASEGURAMIENTO DE CALIDAD Fundamento TeóricoSí Requerimientos del SistemaSí Gestión del ProyectoSí Diseño ArquitectónicoSí

2. ALCANCE DEL PLAN DE CALIDAD PRODUCTOS CONTROL DE CALIDAD Fundamento Teórico: AntecedentesNo Fundamento Teórico: ProblemáticaNo Fundamento Teórico: PropuestaSí Fundamento Teórico: Indicadores de ÉxitoSí Fundamento Teórico: Alcance del ProyectoSí Fundamento Teórico: SupuestosSí Fundamento Teórico: Factores Críticos de ÉxitoSí Fundamento Teórico: RestriccionesSí Fundamento Teórico: Metodología de TrabajoNo Fundamento Teórico: IntroducciónNo Requerimientos del Sistema: IntroducciónNo Requerimientos del Sistema: ActoresSí Requerimientos del Sistema: Modelo de Casos de UsoSí Requerimientos del Sistema: Requerimientos FuncionalesSí Requerimientos del Sistema: Requerimientos No Funcionales (Interfaces, Rendimiento, Usabilidad, Fiabilidad, Seguridad, Soporte, Reusabilidad, Escalabilidad, Portabilidad) Sí Gestión del Proyecto: IntroducciónNo Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Responsable del Financiamiento)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Equipo del Proyecto)No Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Stakeholders del Proyecto)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Organigrama del Equipo de Proyecto)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Entregables del Proyecto)Si Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Fases, Iteraciones e Hitos del Proyecto)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Recursos Humanos)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Herramientas de Trabajo)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Estimación del Proyecto)Sí

2. ALCANCE DEL PLAN DE CALIDAD PRODUCTOS CONTROL DE CALIDAD Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Criterio de Evaluación)Sí Gestión del Proyecto: Plan de Proyecto - Organización del Equipo de Proyecto (Seguimiento y Control del Proyecto) Sí Gestión del Proyecto: Plan de Aceptación - Responsabilidades (Clientes)Sí Gestión del Proyecto: Plan de Aceptación - Responsabilidades (Equipo de Proyecto)Sí Gestión del Proyecto: Plan de Aceptación - Tareas de Aceptación del ProductoSí Gestión del Proyecto: Plan de Aceptación - Criterios Funcionales de AceptaciónSí Gestión del Proyecto: Plan de Aceptación - Criterios No Funcionales de AceptaciónSí Gestión del Proyecto: Plan de Aceptación - Configuración Física de AuditoríaSí Gestión del Proyecto: Plan de Aceptación - Configuración de Auditoría FuncionalSí Gestión del Proyecto: Plan de Aceptación - Resolución de ProblemasSí Gestión del Proyecto: Plan de Aceptación - Metodología de EvaluaciónSí Gestión del Proyecto: Gestión de Riesgos - ConsideracionesSí Gestión del Proyecto: Gestión de Riesgos - Lista de RiesgosSí Gestión del Proyecto: Gestión de Riesgos - Plan de RiesgosSí Gestión del Proyecto: Plan de Configuraciones y Versiones - Herramientas para de del SoftwareSí Gestión del Proyecto: Plan de Configuraciones y Versiones - Programa Administrador del CambioSí Diseño Arquitectónico: IntroducciónNo Diseño Arquitectónico: Arquitectura del SistemaSí Diseño Arquitectónico: Arquitectura de del SistemaSí Diseño Arquitectónico: Arquitectura de la AplicaciónSí

2.1. ENTREGABLES DEL PLAN DE CALIDAD ENTREGABLES DE QADESCRIPCION BREVE Checklist para el Fundamento TeóricoContiene una lista de los puntos que el fundamento teórico debe contener. Checklist para los Requerimientos del Sistema Contiene una lista de los puntos que los Requerimientos del Sistema deben contener. Checklist para del ProyectoContiene una lista de los puntos que del Proyecto debe contener. Checklist para el Diseño ArquitectónicoContiene una lista de los puntos que el Diseño Arquitectónico debe contener. Cronograma de Validaciones y Verificaciones Es la presentación de fechas y tiempos a considerar para la validación de entregables y productos software a validar. Asimismo, se verá la dependencia de dichas actividades. Asignación de recursos para validacionesEs la asignación de recursos humanos a entregar por cada actividad a realizar para la validación y verificación. Documento para Gestión de RiesgosContiene todos los riesgos a los que el equipo de QA/QC y el cliente se atienden y propone soluciones óptimas para evitar grandes retrasos en los proyectos o minimización de los mismos.

2.1. ENTREGABLES DEL PLAN DE CALIDAD ENTREGABLES DE QCDESCRIPCION BREVE Log de Inspección para el Fundamento Teórico Contiene una lista de errores o bugs encontrados en el documento. Log de Inspección para los Requerimientos del Sistema Contiene una lista de errores o bugs encontrados en el documento. Log de Inspección para del ProyectoContiene una lista de errores o bugs encontrados en el documento. Log de Inspección para el Diseño Arquitectónico Contiene una lista de errores o bugs encontrados en el documento. Informe de Inspección para el Fundamento Teórico Contiene estadísticas de los errores encontrados, así como un porcentaje de errores encontrados en el documento. Informe de Inspección para los Requerimientos del Sistema Contiene estadísticas de los errores encontrados, así como un porcentaje de errores encontrados en el documento. Informe de Inspección para del ProyectoContiene estadísticas de los errores encontrados, así como un porcentaje de errores encontrados en el documento. Informe de Inspección para el Diseño Arquitectónico Contiene estadísticas de los errores encontrados, así como un porcentaje de errores encontrados en el documento.

3. ORGANIZACIÓN DEL EQUIPO DE QA JEFE DEL PROYECTO Rodrigo Sarria JEFE DE DESARROLLO Clifford de la Piedra DBA’s Alessandra Rebagliati Bruno Ávalos LÍDER DE EQUIPO Inspector LÍDER DE EQUIPO Inspector Encargado de Pruebas

4. ASEGURAMIENTO DE LA CALIDAD 4.1. REVISIONES DE ASEGURAMIENTO DE LA CALIDAD

4.2. CRONOGRAMA DE REVISIONES DE ASEGURAMIENTO DE LA CALIDAD

4.3. ESFUERZO EN LAS REVISIONES DE QA CODIGO DE QAESFUERZO (Horas hombre) RQA días RQA días RQA días RQA días Total13.5

4.4. INVOLUCRADOS EN LAS REVISIONES DE QA REVISIÓN DE QA INVOLUCRADOS EN LA REVISIÓN DE QA Miembros del equipo del proyecto Miembros del equipo de QA RQA01Jefe del proyecto Líder de equipo Inspectores RQA02 Jefe del proyecto Jefe del desarrollo Líder de equipo Inspectores RQA03 Jefe del proyecto Dba´s Jefe del desarrollo Líder de equipo Inspectores RQA04 Jefe del proyecto Jefe del desarrollo Líder de equipo Inspectores

4.5. PERFIL DEL REVISOR DE QA  El Revisor de QA deberá:  Ser conocedor (nivel intermedio) en la metodología RUP.  Tener experiencia previa en manejo de la metodología RUP o en revisión de documentos que utilicen la misma.  Tener manejo de las Herramientas (Software de Rational) para poder desarrollar las inspecciones y pruebas con total normalidad.  Poseer facilidad de comunicación, para que los Jefes de Proyecto puedan entender los defectos encontrados en los entregables o software.

4.6. HERRAMIENTAS A UTILIZAR EN QA FORMATOS / HERRAMIENTAS  Rational ClearQuest  Rational Robot  Rational SODA  MS Project  Formato de Log de Inspección  Rational Functiontal Test  Rational Manual Tester

4.7. CRITERIOS DE EVALUACIÓN  La metodología que se tomará como referencia es RUP. Esto se debe a que los jefes del proyecto han establecido RUP como metodología de trabajo.  De esta manera, podremos comparar si en realidad están aplicándola adecuadamente y encontrar cuales son los puntos que no se toman en cuenta durante el ciclo de vida del proyecto