Trabajo Ing. de Software

26
Capitulo V. Gestión de calidad. 5.1. Propósito del QA ( Software Quality): En un proyecto donde se realiza una implementación de un nuevo sistema, es normal que existan cambios en el plan de trabajo, debido a los requerimientos que se presentan durante el camino, lo que hace que sea de suma importancia que debamos definir y aplicar mecanismos que permitan detectar los problemas que puedan ocurrir al inicio, antes que sucedan. En este plan para asegurar de calidad, se definen los procedimientos y reglas fundamentales para una correcta colaboración, los principales objetivos son: Descubrir cualquier cambio en el plan, detectar el problema en su inicio de tal forma que se puedan tomar acciones para corregir la situación. Asegurar que cualquier desviación que se pueda producir sea destinada a los canales indicados para su corrección. Asegurar el cumplimiento de los estándares establecidos para la creación de software. Mejorar la calidad del software entregado, monitoreando y revisando constantemente ya sea el proceso de desarrollo y posterior producto final.

description

gestion de calidad

Transcript of Trabajo Ing. de Software

Capitulo V. Gestin de calidad.

5.1. Propsito del QA (Software Quality): En un proyecto donde se realiza una implementacin de un nuevo sistema, es normal que existan cambios en el plan de trabajo, debido a los requerimientos que se presentan durante el camino, lo que hace que sea de suma importancia que debamos definir y aplicar mecanismos que permitan detectar los problemas que puedan ocurrir al inicio, antes que sucedan.

En este plan para asegurar de calidad, se definen los procedimientos y reglas fundamentales para una correcta colaboracin, los principales objetivos son:

Descubrir cualquier cambio en el plan, detectar el problema en su inicio de tal forma que se puedan tomar acciones para corregir la situacin. Asegurar que cualquier desviacin que se pueda producir sea destinada a los canales indicados para su correccin. Asegurar el cumplimiento de los estndares establecidos para la creacin de software. Mejorar la calidad del software entregado, monitoreando y revisando constantemente ya sea el proceso de desarrollo y posterior producto final.

5.2. Organizacin QA

5.3. Actividades QA

Conjunto de actividades planificadas y sistemticas que deben realizarse con el objetivo de evaluar la calidad y adherencia del software a los estndares, procesos y procedimientos.

Las actividades utilizadas sern:

Revisiones Estndares Prueba Reporte Verificacin

5.3.1 RevisionesConstituyen la primera forma de monitorear y evaluar la calidad de los productos y adems proveen mayor visibilidad al desarrollador.

Las revisiones son una metodologa definida, estructurada y disciplinada para la detencin e identificacin de defectos en los productos de trabajo durante el ciclo de vida del software.Cuenta con 6 etapas: Planificacin Orientacin Preparacin Inspeccin Re-Work Seguimiento

El software desarrollado deber ser testeado por los propios desarrolladores y al momento de ser entregado, estos debern ser verificados por los dems miembros del equipo, controlndolos con pruebas unitarias y de integracin con el resto de mdulos que hayan sido liberados anteriormente. Estos deben ser revisados contra los estndares y checklist definidos.

5.3.2 Estndares

Son la base de cualquier sistema de calidad de software, proveen el cimiento para la evaluacin y medicin de las actividades y de los productos de trabajo durante todo el ciclo de vida del software.Su aplicacin da consistencia, rigurosidad y fortaleza a los mtodos en el desarrollo de software.La estandarizacin puede ser aplicada a cualquier o a todas las reas de desarrollo de software y mantencin el cual cubrir: Ciclo de vida del software Documentacin Cdigo fuente Procedimientos y protocolos

5.3.3 Prueba

Es la evaluacin del producto que permite detectar defectos y establecer el nivel de satisfaccin de los requerimientos.Sus actividades influyen la planificacin, diseo, ejecucin y reporte sobre los diferentes niveles de pruebas existentes durante el proyecto.Estos niveles van desde las pruebas de unidad, pasando por la integracin, hasta las del sistema y aceptacin.SQA debe garantizar: (SQA): Software quality assurance Los procedimientos de prueba verifican los requerimientos segn el plan. La versin del software evaluada sea la actual. Los procedimientos sean utilizados.

5.3.3.1 Reportes de Verificacin y Validacin

Checklist generado para realizar la verificacin y validacin del plan de proyecto:

5.4 Estndares, Prcticas, Convenios y Mtricas5.4.1 Estndar de Documentacin

Como estndares de documentacin se definirn dos documentos: Estndar de documentacin tcnica y Estndar de documentacin de usuario.

La documentacin tcnica del producto debe: Ser adecuada para que un grupo independiente del de desarrollo pueda encarar el mantenimiento del producto. Incluir fuentes, Modelos de Casos de Uso, Objetos, etc.

Para la escritura de documentos se han definido plantillas para ser utilizadas en la elaboracin de entregables. En estas plantillas se definen: Encabezado y pie de pgina. Fuente y tamao de fuente para estilo normal. Fuente y tamao de fuente para los ttulos a utilizar. Datos mnimos que se deben incluir: fecha, versin y responsables. 5.4.2 Estndar de Gestin, Verificacin y Prcticas

1. Se utilizan las prcticas definidas en la Gestin del Proyecto. Como estndar se utiliza el documento de especificacin de reas del conocimiento, promovida por el Project Management Institute, Inc. (PMI), tomando como referencia principal las prcticas plasmadas en la Gua del PMBOK Tercera Edicin. 2. Se utilizan las prcticas definidas en el Plan de Verificacin y Validacin.

Captulo VI: Gestin de Riesgos

6 6.4 Descripcin

Para el proyecto Comunidad Teraputica, se considera tambin un marco de trabajo para la planificacin y ejecucin de las actividades de gestin de riesgos que afecten el proyecto.

Este marco de trabajo debe permitirnos identificar, analizar y responder a los riesgos del proyecto a realizar:

Estimando y planeando las actividades de anlisis, planeacin y gestin del riesgo para el proyecto. Determinando cules riesgos pueden afectar el proyecto y documentndolos con sus caractersticas. Realizando un anlisis cualitativo del riesgo y de las condiciones para priorizar sus efectos sobre los objetivos del proyecto. Desarrollando procedimientos y tcnicas para aumentar las oportunidades y disminuir las amenazas en los objetivos del proyecto.

6.5 Planeacin de Riesgo

Para realizar la planeacin de los riesgos en el proyecto, deber utilizarse la siguiente documentacin:

1. Alcance del proyecto: base para la planeacin de riesgos por medio de la identificacin de los objetivos del proyecto y de los entregables del proyecto.2. Plan del Proyecto: La identificacin del riesgo requiere un entendimiento de la misin del proyecto, alcance y objetivos del propietario, el patrocinador y los interesados.6.6 Rol y Responsabilidades

A continuacin se define el lder, el apoyo y los miembros del equipo de gestin de riesgos para cada tipo de actividad del plan de gestin de riesgos.

6.6.1 Originador del Riesgo

El originador del riesgo inicialmente identifica el riesgo y formalmente lo informa a los miembros del Proyecto. El originador del riesgo es formalmente responsable por:1. La temprana identificacin del riesgo dentro del proyecto.2. La documentacin formal del riesgo, completando el Formato para Riesgos.3. La publicacin del Formato de Riesgo para la revisin del Gerente del Proyecto.

6.6.2 Gerente del Proyecto

El Gerente del Proyecto recibe, registra, y monitorea el progreso de todos los riesgos del proyecto. El Gerente del Proyecto es formalmente responsable de:1. Recibir los Formatos de Riesgos e identificacin de riesgos apropiados para el Proyecto.2. Grabar todos los riesgos en el Registro de Riesgos almacenados en forma digital en los servidores de NVR asociados.

3. Presentar todos los riesgos a NVR asociados. de Revisin del Proyecto.4. Reportar y comunicar todas las decisiones tomadas por el Grupo de Revisin del Proyecto.5. Monitorear el progreso y las acciones de mitigacin asignadas.6.6.3 Grupo de Revisin del Proyecto

El Grupo de Revisin del Proyecto confirma el riesgo, es decir su probabilidad e impacto, y asigna las acciones segn la estrategia seleccionada para cada riesgo. El Grupo es formalmente responsable por:1. Un regular repaso de los riesgos registrados en el Registro de Riesgos.2. La identificacin de solicitudes de cambio necesarias para mitigar los riesgos identificados.3. Asignacin de acciones para mitigar el riesgo.4. El cierre de riesgos que no presentan acciones pendientes y no presentan probablemente ms impacto al proyecto.

6.6.4 Equipo del Proyecto

El Equipo del Proyecto est comprometido con las acciones de mitigar el riesgo, delegados por el Grupo de Revisin del Proyecto.6.7 Identificacin de los Riesgos

El riesgo es un evento o condicin incierta que si ocurre tiene un efecto positivo o negativo en los objetivos del proyecto. Se deben efectuar reuniones con los miembros del equipo del proyecto para desarrollar el plan de riesgos. La identificacin de los riesgos para el proyecto ser representada a continuacin, a travs de una categora, un cdigo y el factor mismo de riesgo:

Tabla 6.1 "Riesgos Identificados

La tabla slo muestra los riesgos que se han identificado.

Existe una alta probabilidad de que se identifiquen nuevos riesgos en la etapa de implementacin del Proyecto.6.5 Probabilidad e Impacto de los Riesgos

Adicionalmente a la identificacin de los riesgos que puedan presentarse en el Proyecto, se debe establecer el anlisis necesario y la medicin de los mismos. La medida del riesgo abarca dos dimensiones bsicas: la probabilidad de que se produzca la amenaza que nos acecha, que se puede expresar en trminos de frecuencia o, mejor en trminos de frecuencia relativa, y la severidad con que se produzca dicha amenaza.Se ha establecido la siguiente tabla para clasificar las probabilidades de ocurrencia de los riesgos que pueden afectar al Proyecto:

Tabla 6.2 "Probabilidad de Ocurrencia de los RiesgosA continuacin se presenta la categorizacin de impacto definida para los riesgos que ya se encuentran identificados dentro del Proyecto:

Tabla 6.3 "Impacto de los Riesgos6.6 Priorizacin de los Riesgos

Esta matriz da 4 categoras para los riesgos, basados en la combinacin de frecuencia (probabilidad) y severidad (impacto) de cada riesgo.

Tabla 6.4 "Matriz Categoras de Riesgos

Las caractersticas de cada riesgo son las que determinan su frecuencia y severidad, y son las que definen el tipo de herramienta que se deber utilizar para su tratamiento y/o manejo.Cuando los riesgos se caracterizan por ser de alta frecuencia y alta severidad, las herramientas ms apropiadas para su manejo y tratamiento son: evitarlo o reducirlo.Si los riesgos son caracterizados por alta frecuencia y baja severidad sern manejados ms apropiadamente a travs de la retencin y/o reduccin.Por otro lado, si los riesgos se caracterizan por tener una alta severidad y una baja frecuencia, se pueden manejar o tratar mejor con transferirlos.

Finalmente, si los riesgos caracterizados por baja severidad y baja frecuencia se manejarn mediante la retencin. De manera que la matriz quedar de la siguiente manera:

Tabla 6.5 "Matriz Categoras Riesgos v/s Tcnicas Manejo6.7 Nivel de los Riesgos

Para llegar a establecer cules son los riesgos ms importantes que pueden llegar a afectar el Proyecto, se ha realizado una categorizacin de los mismos en base a experiencias de proyectos anteriores. Segn esto se establece la siguiente frmula de clculo:

Nivel del Riesgo = (Probabilidad x Impacto) Obteniendo la siguiente Matriz de Riesgos:

Figura 6.1 "Matriz de Riesgos

Tabla 6.6. "Riesgos y Severidad

6.8 Tcnica de Manejo Riesgos

Esta etapa consistir en estructurar un adecuado manejo y control de los riesgos ya identificados, analizados y priorizados en la etapa anterior, a travs de acciones factibles y efectivas.

Para lograr efectividad en esta etapa, se contar con las siguientes tcnicas de manejo del riesgo:

1. Evitar: ser siempre la primera alternativa a considerar. Se logra cuando al interior de los procesos se genera cambios sustanciales por mejoramiento, rediseo o eliminacin.2. Reducir o Controlar el Riesgo: si el riesgo no puede ser evitado porque crea grandes dificultades operacionales, el siguiente paso es reducirlo al ms bajo nivel posible. La reduccin del riesgo es probablemente el mtodo ms sencillo y econmico para superar las debilidades antes de aplicar medidas ms costosas y difciles. 3. Retener el Riesgo: despus de que los riesgos han sido reducidos, podran haber residuos del riesgo (riesgo residual) los cuales sern retenidos. Los planes deben manejar las consecuencias de estos riesgos si ellos ocurrieran, incluyendo la identificacin de los medios de financiar el riesgo. 4. Transferir el riesgo: Hace referencia a buscar respaldo y compartir con otro parte del riesgo. sta tcnica es usada para eliminar el riesgo de un lugar y pasarlo a otro o de un grupo a otro.

Captulo VII: Gestin de los RR.HH1 7.1 Descripcin Breve de los Roles

Para este proyecto se definido los siguientes roles:

Equipo de Proyecto: Son aquellos que participarn en la planificacin del proyecto y luego en su desarrollo. Ellos tienen la misin de concretar todas las actividades que el proyecto incluye y de cumplir con los objetivos que se quieren lograr, tambin tiene la responsabilidad de resolver conflictos que se presenten entre La Comunidad Teraputica y de promover la participacin del personal de la empresa en el proyecto cuando sea necesario.

Jefe de Proyecto: Es quien liderar y guiar al equipo de proyecto. Tendr la tarea de evaluar y aprobar cualquier producto entregable antes de concretar su entrega. El jefe de proyecto es el representante y responsable tanto del proyecto en s, como tambin del equipo de proyecto.

Coordinador de Proyecto: Es el intermediario entre el equipo de proyecto y el cliente. Su tarea principal es gestionar y resolver las necesidades (de informar, averiguar, advertir, reunirse, etc.) que tengan el equipo de proyecto y/o el cliente.

7.2 Descripcin Detallada de los Roles

Equipo de Proyecto: El Equipo de Proyecto tendr asignados los siguientes deberes y responsabilidades:

1. Desarrollar un plan de evaluacin para la solucin que el cliente requiere. 2. Cumplir cada una de las actividades y logros que el proyecto implica. 3. Dedicar al proyecto el tiempo pertinente y necesario para lograr su finalizacin a tiempo. 4. Resolver conflictos y controversias que se presenten entre La Comunidad Teraputica y el equipo de proyecto. 5. Promover y facilitar la participacin del personal de la Comunidad en el proyecto cuando sea necesario.

Jefe de Proyecto: El Jefe de Proyecto tendr asignados los siguientes deberes y responsabilidades: 1. Fomentar la finalizacin del proyecto de forma oportuna y exitosa, cumpliendo con el alcance acordado con el cliente. 2. Administrar y gestionar los recursos necesarios para concluir el proyecto. 3. Determinar y llevar a cabo medidas preventivas y correctivas para evitar el fracaso del proyecto. 4. Establecer hitos de control para evaluar el proyecto durante su desarrollo. 5. Gestionar los cambios que afecten al proyecto. 6. Evaluar y aprobar los productos entregables que conlleva el proyecto.

Coordinador de Proyecto: El Coordinador de Proyecto tendr asignados los siguientes deberes y responsabilidades:

1. Informar, cuando corresponda, al cliente sobre el estado del proyecto. 2. Resolver inquietudes que manifieste el cliente y el equipo del proyecto, cuando sea posible. 3. Escalar y/o gestionar la resolucin de inquietudes cuando sea necesario. 4. Programar reuniones entre las partes cuando sea pertinente.

7.3 Aptitudes Necesarias

Los roles mencionados anteriormente requieren de personal que cumpla con un perfil especfico para lograr un desempeo eficiente. De acuerdo a esto, cada rol requiere ciertas aptitudes, como las que se mencionan a continuacin:

Equipo de Proyecto: El Equipo de Proyecto debe ser conformado por personal que cuente con amplios conocimientos de planificacin y evaluacin de proyectos. Tambin debe tener conocimientos de desarrollo nivel intermedio o avanzado en las herramientas que se utilizaran para crear la Plataforma WEB.

Jefe de Proyecto: El Jefe de Proyecto debe tener experiencia de trabajo en proyectos informticos, trabajo en equipo y debe tener habilidades para liderar un equipo. Adems, debe poseer los conocimientos requeridos para el resto del equipo de trabajo.

Coordinador de Proyecto: El Coordinador de Proyecto debe tener la capacidad de transmitir con facilidad cualquier informacin entre el Equipo de Proyecto y el cliente. Adems, el Coordinador de Proyecto es quien debe tener el mayor nivel de conocimientos, tanto de la empresa como de las necesidades de la empresa, del equipo de proyecto y del proyect en s, ya que l debe resolver la mayor cantidad de inquietudes e inconvenientes que presente cualquiera de las partes, sin necesidad de recurrir a alguien ms.

7.4 Asignacin de Roles

A continuacin se muestra la lista de los distintos cargos relacionados con el proyecto, junto con el personal que ha sido asignado:

Tabla 7.1. "Asignacin de Roles definidos Proyecto

Captulo VIII: Gestin de las Comunicaciones2 8.1 Requisitos de las ComunicacinPara este proyecto hemos determinado que las partes demandantes de comunicacin son: Equipo de Proyecto. Jefe de Proyecto. Coordinador de Proyecto.

Estos podrn comunicarse entre s de acuerdo a un esquema jerrquico determinado, el cual est representado en el siguiente diagrama:

Figura 8.1 "Diagrama de Comunicaciones

8.2 Matriz de Comunicacin

El plan de gestin de las comunicaciones define los medios, frecuencias y contenidos formales que deben ser considerados al momento de compartir informacin relacionada con el proyecto, con el fin de que los interesados puedan transmitir y recibir la informacin de forma oportuna y accesible.

Tabla 8.2 "Matriz de Comunicaciones8.3 Canales de Comunicacin

Para este proyecto se han definido especficamente os siguientes canales de comunicacin:Canales formales:Correos electrnicos: Es el canal que se utilizar con mayor frecuencia debido a su rapidez. Para que un correo sea considerado vlido, debe ser enviado con copia al Jefe de proyecto, Coordinacin de la comunidad y administracin de la comunidad. Adems, se sugiere que los destinatarios notifiquen el recibo de un correo para as lograr una comunicacin ms confiable.Reuniones: Ests sern realizadas principalmente cuando se quiere comunicar algo relevante para el proyecto o cuando se deba discutir un tema. Si bien no es necesario que todas las partes se presenten siempre a una reunin, s se requiere informar va correo electrnico sobre quienes se han reunido y los temas que han discutido, se deja notificado bajo minuta de reunin los participantes de esta y los acuerdo tomados.

Canales informales:Telfono Mvil o Fija: Este canal se utilizar de forma auxiliar, debido a que el personal de la comunidad trabaja en terreno y no siempre tiene acceso inmediato a correo electrnico, y se utilizar principalmente cuando se requiera una respuesta inmediata. Aun as, este medio no formaliza ningn tipo de requerimiento o acuerdo.8.4 Distribucin de la Informacin

En la matriz de comunicaciones, se ha definido informes que deben ser entregados peridicamente.

Adems de esto, todos los informes generados por el equipo de proyecto sern almacenados en el servidor definido y debe ser tambin respaldados discos flexibles correspondiente a coordinacin de la comunidad.

Por otro lado, en caso de requerir o transmitir cualquier tipo de informacin relacionada con el proyecto, se debe enviar un correo electrnico a quien corresponda y con copia a las dems partes.

Para que esto funcione correctamente, se considera lo siguiente: Las distintas partes deben tener 2 direcciones de correo: una principal, a la cual sern enviados los mensajes de forma regular, una secundaria Lista de distribucin, a la cual le sern enviados los mensajes en caso de no poder hacerlo a la direccin principal. Las partes deben informar de al menos 1 nmero de telfono mvil y fijo que dispongan para ser contactados en forma inmediata. Las reuniones sern concretadas en un lugar acordado por las partes de forma anticipada, dependiendo de la ubicacin y disponibilidad de cada una de ellas, y siempre y cuando todas las partes participantes estn de acuerdo.

8.5 Rendimiento

De acuerdo a los informes que se entregarn peridicamente, se medir el rendimiento bajo el cual se est llevando a cabo el proyecto.

Para esto se considerarn los siguientes factores:

Cronograma. Alcance. Costos. Calidad.

Esta evaluacin se har de con una frecuencia 2 veces por mes y permitir determinar si el proyecto presenta desviaciones y realizar acciones correctivas, o bien realizar acciones preventivas en caso de que el proyecto corra el riesgo de desviarse.

Captulo IX: Gestin de las Adquisiciones3 9.1 Definicin

Tal como se estableci en el punto 2.3. Del captulo Gestin del Alcance, el proceso de Gestin de las Adquisiciones queda fuera de alcance del presente Proyecto, debido a que, este proceso ser gestionado directamente por La comunidad Teraputica.