plan_de_calidad_scrum_handler (1).docx

May 1, 2012 [Plan de Aseguramiento de la Calidad]

ITESM

Plan de Aseguramiento de la Calidad

Plan de Aseguramiento de la Calidad de Software

Marcel Valdez Orozco A00790834Rubén Valdez Bejarano A00739846

Paolo Iván Aguirre Montoya A00739866


Contenido1. Propósito del plan de calidad.....................................................................................................4

2. Documentos de referencia.........................................................................................................4

3. Administración...........................................................................................................................4

3.1. Organización.......................................................................................................................4

3.2. Roles y responsabilidades...................................................................................................5

3.3. Estimación de Recursos para el Aseguramiento de la Calidad............................................6

4. Documentación..........................................................................................................................6

4.1. Propósito............................................................................................................................6

4.2. Descripción del plan de proyecto.......................................................................................6

4.3. Descripción de Requerimientos de Software (SRD)............................................................6

4.4. Descripción de Diseño de Software (SDD)..........................................................................6

4.5. Planes de Validación y Verificación....................................................................................6

5. Perfiles operacionales................................................................................................................8

6. Normas, prácticas, convenciones y métricas............................................................................11

6.1. Propósito..........................................................................................................................11

6.2. Contenido.........................................................................................................................11

7. Revisión y Verificación del prototipo........................................................................................13

7.1. Propósito..........................................................................................................................13

7.2. Revisión de plan de proyecto...........................................................................................13

7.3. Revisión de Especificaciones de Software (SRS)...............................................................18

7.4. Revisión de Diseño (ADR).................................................................................................22

7.5. Revisión de código............................................................................................................27

7.6. Planes de Revisión de Verificación y Validación...............................................................31

8. Pruebas....................................................................................................................................31

8.1. Propósito..........................................................................................................................31

8.2. Procesos para definir casos de prueba.............................................................................31

8.3. Proceso de ejecución de casos de prueba........................................................................32

8.4. Formas de registro de casos de prueba............................................................................34

8.5. Pruebas implementadas...................................................................................................35

8.6. Ejemplo de casos de pruebas...........................................................................................36


9. Notificación de problemas y acción correctiva.........................................................................40

10. Herramientas, técnicas y metodologías...............................................................................41

11. Recolección de registros, mantenimiento y retención.........................................................42

12. Gestión de riesgos................................................................................................................43

13. Glosario................................................................................................................................45

14. Bibliografía...........................................................................................................................45


1. Propósito del plan de calidadDefinir un conjunto de actividades y métricas que auxilien en el aseguramiento de la calidad

del prototipo Scrum-Handler, que es un sistema gestor de proyectos basados en Scrum, la metodología ágil de desarrollo de software. Este documento abarcará inspecciones de elementos como: el plan de proyecto, el análisis de requerimientos, el diseño GUI y el desarrollo del prototipo. Cabe destacar que su ciclo de vida es muy corto pues es un prototipo con el propósito de que en el futuro sea un sistema con mayor funcionalidad, sin embargo, la razón por la que se quiere desarrollar con calidad este prototipo, es para asegurar que en un futuro se pueda hacer reúso de los artefactos que se desarrollen para el prototipo de software.

2. Documentos de referenciaPara el desarrollo de este plan de aseguramiento de calidad se utilizó el estándar de IEEE 730

“Standard for Software Quality Assurance Plans 2002”, el cual explica paso a paso lo que debe de ejecutarse para que el software tenga un criterio de calidad. A parte de este estándar, se utilizó el documento “ESA PSS-05-11” el cual es una guía para el desarrollo de plan de calidad que se utilizó para complementar el estándar IEEE 730.

3. Administración

3.1.OrganizaciónLos miembros del equipo del proyecto ‘Scrum-Handler’ son:

Rubén Valdez Bejarano, cuyo rol principal es el de Administrador del proyecto. Marcel Valdez Orozco, diseñador en jefe del equipo. José Guzmán, coordinador de desarrollo del prototipo. Paolo Iván Aguirre Montoya, verificador de los artefactos desarrollados en el proyecto.

La siguiente figura muestra a los miembros del equipo y los diferentes roles a los que fueron asignados, tanto primarios, como secundarios.


Figura 1: Roles del proyecto

3.2.Roles y responsabilidadesEn la tabla 1 se puede observar claramente que responsabilidad, orientada al plan de calidad,

tiene cada persona, y que debe de respetar para poder asegurar cierta calidad en el proyecto.

Rol Nombre Responsabilidad en el SQPAdministrador Rubén Valdez Asegurarse que el equipo de

trabajo ejecute todas las actividades de calidad en las fases del proyecto, además de comunicar los errores que se vayan encontrando en el Plan de Calidad.

Analistas Rubén ValdezJosé Guzmán

Licitar los requerimientos del sistema, según los estándares de calidad.

Diseñadores Marcel ValdezPaolo Aguirre

Desarrollar el diseño de arquitectura y bajo nivel del software, según los estándares de calidad que se encuentran en el plan de calidad.

Desarrolladores José GuzmánMarcel Valdez

Seguir las métricas, estándares, técnicas, herramientas y metodologías de codificación establecidas, para asegurar la calidad del software.

Verificadores Paolo AguirreRubén Valdez

Llevar a cabo las revisiones de software en todas las fases del proyecto.

Tabla 1: Roles y responsabilidades de los miembros del equipo

AdministradorRuben Valdez

Analista

Rubén Valdez

José Gúzman

Diseñador

Marcel Valdez

Paolo Aguirre

Desarrollador

José Gúzman

Marcel Valdez

Verificador

Paolo Aguirre

Rubén Valdez


3.3.Estimación de Recursos para el Aseguramiento de la CalidadEl proyecto ‘Scrum-Handler’ es un proyecto escolar que se esta administrando bajo una

gestión general de administración de proyectos que tiene las siguientes fases: Inicio, planeación, ejecución, monitoreo, control y cierre.

En este tipo de gestión la definición del SQAP se realiza en la fase de planeación y su impulso llega en las fases de ejecución, monitoreo y control, fases que se desenvuelven en paralelo según la administración de proyectos que se tomó.

En base a lo anterior, se puede concluir que no hay recurso económico en juego, y por lo tanto, que los únicos recursos a considerar son: tiempo y recurso humano. Dichos recursos ya están distribuidos en el diagrama de Gantt, donde se establece que el inicio de este proyecto es el 11 de febrero del 2012 y finaliza el 28 de abril del 2012, y en transcurso de dicho lapso de tiempo se distribuyen el recurso humano en la realización de diferentes actividades.

4. Documentación

4.1.PropósitoIdentificar la documentación que rige el desarrollo, la verificación y validación del prototipo

identificando sus revisiones o auditorias que serán conducidas y sus criterios.

4.2.Descripción del plan de proyectoEn este documento se puede observar las actividades que se planearon para implementar el

prototipo, como el alcance del proyecto, el desglose de actividades, etc.

4.3.Descripción de Requerimientos de Software (SRD)Este documento contiene los requerimientos funcionales y no funcionales los cuales debe de

cumplir el prototipo para poder ser aceptado por el cliente. Los requerimientos, básicamente, cubren los procesos de la metodología SCRUM.

4.4.Descripción de Diseño de Software (SDD)Este documento plantea la arquitectura que se utilizó para desarrollar el prototipo, así como el diseño GUI de las pantallas y el diseño de entidades que se utilizaron en la implementación.

4.5.Planes de Validación y VerificaciónEn estos planes de verificación y validación se indicará qué se debe de llevar a cabo en cada

plan, para posteriormente ser revisado. Se planea verificar y validar por fases (requerimientos de software, desarrollo de plan de proyecto, diseño del software, desarrollo del prototipo) para asegurar la calidad en cada parte del proyecto.

Verificación: Es el proceso con el cual se comprueba que el software cumple con los requisitos funcionales y no funcionales según los especificados.


Para las revisiones e inspecciones de los documentos en el presente, plan de calidad, el apartado número 7 proporciona procesos de revisión los cuales deben de ser completados en cada fase por el encargado responsable, además se incluyen Checklists para asegurar la consistencia, integridad, precisión y legibilidad de cada documento.

Validación: Es el proceso por medio del cual se asegura que el producto satisface las necesidades del cliente.

En lo que se refiere a la validación se planea hacer casos de prueba para las actividades críticas, según los perfiles operacionales; dichas pruebas estructurales serán las siguientes:

Pruebas de caja negra. Pruebas de estrés. Pruebas de integridad.

Además de estas pruebas se especificaron normas, prácticas, convenciones y métricas, que se deben seguir para asegurar que el proyecto sea entregado con los criterios de calidad acordados con el cliente, para el proyecto.


5. Perfiles operacionalesPerfil del cliente

Tecnológico de Monterrey: La aplicación se esta realizando con fines educativos para la materia de “Administración del desarrollo de software”, donde el cliente es la Dra. Lorena Gómez quién utilizará el sistema para que alumnos futuros puedan administrar sus proyectos utilizando la metodología SCRUM.

Perfil de usuario

En el sistema de SCRUM-Handler se pueden identificar tres roles o perfiles los cuales tienen restricciones y accesos diferentes en el sistema.

Cliente: Este usuario es la persona a quién va dirigido el software del proyecto que se esta administrando con la herramienta. Este usuario, según lo planteado en el plan de proyecto, sólo tiene autorizado ver los Features que el equipo de trabajo ha especificado.

Administrador: Este usuario es el encargado de supervisar a los grupos de estudiantes que están utilizando la herramienta, la única función de este usuario es ver cómo van progresando los proyectos, ya sean los Sprints, Features o la gráfica Burndown.

Usuarios SCRUM: Este usuario puede ser un conjunto de personas con diferentes roles en el sistema, pero acceden a las mismas pantallas, por ejemplo, este usuario puede dar de alta un nuevo proyecto, nuevas Features, nuevos Sprints, nuevos Releases, etcétera. En resumen, este usuario es el que tiene a su disposición toda la funcionalidad de la herramienta, y es el que realiza actividades diariamente.

En la tabla 2 se puede ver el peso que se le dio a cada perfil de usuario, para identificar cuál es el perfil clave, además, en la figura 2 resume a qué pantallas tiene acceso cada perfil de usuario, y de ahí se puede detectar qué actividades son las más utilizadas.

Perfil de usuario Frecuencia de uso del sistemaCliente .1Administrador .3Usuarios SCRUM .6

Tabla 2: Frecuencia del uso del sistema


Figura 2: Acceso a pantallas por usuario

Modos del sistema

El sistema sólo cuenta con un modo, el “Modo Administrativo”, este contiene las pantallas descritas con anterioridad y dependiendo del perfil del usuario, se habilita, deshabilita, prohíbe o permite la funcionalidad requerida.

Perfil funcional

El modo con el que cuenta el sistema Scrum-Handler provee cierta funcionalidad según los perfiles de usuario:

Servicios para el cliente: Visualización de las Features del producto en la pantalla de Product Backlog.

Servicios para el administrador: Visualización de las Features en la pantalla de Product Backlog, visualización de los Sprints en el Sprint Backlog, visualización de la gráfica en la pantalla Burndown Chart.

Servicios para los usuarios SCRUM: Crear nuevo proyecto, editar nuevo proyecto, borrar proyecto, registrar nuevo miembro, crear Features, editar Features, eliminar Features, crear Releases, eliminar Releases, crear Sprints, eliminar Sprints, asignar Features a los Releases, asignar actividades a los Sprints, asignar Sprint a los Releases, registrar la bitácora de trabajo, consultar grafica Burndown, ajustar la prioridad de las Features.


Determinar el perfil operacional

Como se puede observar en los perfiles funcionales, los servicios de cliente y de administrador son solamente servicios de visualización, ya que no alteran el estado del proyecto que se esta administrando, por lo que el único perfil de operación clave es el de los usuarios SCRUM ya que son los que más interactúan con la herramienta. En la figura 3 se puede observar el peso que se especificó a las actividades realizadas por los usuarios SCRUM y de ahí se puede obtener las actividades clave.

Figura 3: Actividades clave para los usuarios SCRUM


6. Normas, prácticas, convenciones y métricas

6.1.PropósitoIdentificar estándares, prácticas, convenciones y técnicas que pudieran ser aplicados en el

proyecto ‘Scrum-Handler’.

6.2.Contenido6.2.1. Convenciones

Convenciones de Codificación

Se deben utilizar las convenciones de codificación de C# de Microsoft®:

- Directrices para Nomenclatura- Directrices para Estructura de Código- Directrices para Comentarios de Código

Adicionalmente, se utilizaran las directrices de Diseño de Librerías de Clases de Microsoft®, para el desarrollo de librerías y marcos de trabajo o frameworks.

Cabe mencionar que, a pesar de que en el documento de Convenciones de Codificación de C# de Microsoft, se califica a estas características de código como directrices, en el proyecto serán reglas, en otras palabras, serán obligatorias a menos que se acuerde lo contrario en una inspección de código.

Adicionalmente se tienen las siguientes reglas dentro de las convenciones de codificación:

1. Ningún documento de código puede tener más de 500 líneas de código, a menos que sea autogenerado.

2. Ningún procedimiento o método puede tener más de 50 líneas de código, a menos que sea autogenerado.

6.2.2. Normas

Norma de Control de Versiones

3. No se podrá hacer Commit al repositorio del tronco principal en SVN, si la evaluación de StyleCop para Visual Studio 2010, utilizando la convención de codificación de Microsoft®, determina que hay errores de estilo en algún documento de código fuente.

4. No se podrá hacer Commit al repositorio del tronco principal en SVN si el proyecto no compila exitosamente.

5. No se podrá hacer Commit al repositorio del tronco principal en SVN si la aplicación tiene errores de ejecución conocidos, tales como pruebas unitarias o de integración insatisfactorias.

http://msdn.microsoft.com/en-us/library/ms229042.aspx

http://msdn.microsoft.com/en-us/library/ff926074(v=vs.100).aspx


6. No se podrá hacer Commit al repositorio del tronco principal en SVN, si algún documento de código fuente tiene implementaciones incompletas, a menos que haya algún placeholder con el comentario “// TODO: [Descripción de funcionalidad faltante]”, dentro del archivo de código fuente donde se codificará la implementación.

Norma de Codificación Segura de Interfaces

1. Se crearán Contratos de precondición, para todo método público que asuma características de los parámetros que recibe. Ejemplo: Contract.Requires(param != null);

2. Se crearán Contratos de pos condición, para todo método público que crea o modifica el estado públicamente visible de un objeto, incluido a sí mismo. Ejemplo: Contract.Ensures(this.Counter == Contract.OldValue(this.Counter) + 1)

3. Se crearán Contratos de Invariantes de Clase, para toda clase mutable con métodos y estado públicos. Ejemplo: Contract.Invariant(this.Id >= 0);

6.2.3. Prácticas

Práctica de integración continúa:

1. Al implementar un requerimiento de sistema, cada desarrollador deberá crear una rama o branch del tronco o trunk, donde se implementará el requerimiento.

2. Al finalizar la implementación que ejecute satisfactoriamente sus pruebas unitarias y de integración en la rama, el desarrollador pondrá un candado sobre el tronco principal.

3. Inmediatamente, se hará una integración o merge en su copia local, de su rama con el tronco o trunk principal.

4. El desarrollador ejecutará las pruebas unitarias y de integración sobre el programa resultante de la integración, y si alguna prueba unitaria o de integración se ejecuta insatisfactoriamente, es responsabilidad del desarrollador arreglar tal defecto.

5. Sólo al conformar satisfactoriamente con todas las pruebas unitarias, integración, y demás normas, prácticas y convenciones, se podrá hacer Commit al repositorio SVN de código, en el tronco o trunk principal.

6. Finalmente, se libera el candado sobre el trunk o tronco principal.

6.2.4. Métricas1. La métrica de tamaño del código fuente del proyecto serán líneas de código (LOC).2. La métrica de progreso del proyecto será el número de requerimientos funcionales

implementados versus faltantes (requerimientos implementados / requerimientos totales * 100%).


3. La métrica para el tamaño de documentos de especificación de requerimientos serán páginas de documentación (pp).

4. La métrica para determinar la calidad de un programa será el número de defectos por cada mil líneas de código (#defectos/KLOC).

7. Revisión y Verificación del prototipo

7.1.PropósitoDefinir procesos de revisión para cada artefacto, documento o entregable crítico en el

desarrollo de software, que especifiquen los pasos a seguir y las actividades a llevar a cabo para evitar discrepancias en el proceso de revisión como tal.

De igual manera, definir formas de registro de todos los defectos encontrados y Checklists con la finalidad de tener una sola forma de registro estandarizada para los diferentes procesos de revisión.

7.2.Revisión de plan de proyectoProceso de Revisión del Plan de Proyecto

Propósito - Guiar al equipo en la revisión del plan de proyecto, para determinar el grado de corrección y conformidad con las especificaciones y estándares descritos para el plan de proyecto.- Guiar al equipo de desarrollo, en la gestión de la documentación que evidencie el estado técnico del mismo.

Criterios de Entrada

La revisión, antes de iniciar, debe contar con al menos los siguientes artefactos:-Objetivos de la revisión.-Checklists (regulaciones y estándares) para hacer la revisión técnica.-Checklists de revisiones anteriores (si las hubo) con las anomalías encontradas.-Documentación del plan de proyecto a revisar.

Fase # Nombre Actividades

1 Administración El Project Manager debe:-Asegurar que la revisión cumple con los estándares y requerimientos del plan de proyecto.-Facilitar la planeación, definición, ejecución y administración de la revisión.-Proveer orientación para el procedimiento de la revisión.

2 Planeación Si el plan de proyecto es técnicamente complejo entonces:El autor del plan del proyecto es responsable de:-Identificar el equipo de revisión.-Asignar responsabilidades a cada miembro del equipo.-Calendarizar actividades y anunciar el lugar de encuentro(s).-Distribuir el material de revisión a los miembros.Sino, el autor debe:-Planear y calendarizar su revisión individual.


3 Recapitulación de la revisión

Si el plan de proyecto es técnicamente complejo entonces:El autor debe de:-Presentar una síntesis del procedimiento que se llevará a cabo en la revisión a los miembros del equipo.Si no, el autor puede:-Utilizar el Checklists como procedimiento de la revisión a llevar.

4 Recapitulación del producto

Si el plan del proyecto es técnicamente complejo entonces:El autor debe:-Presentar una síntesis del producto que será sometido a revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el plan de proyecto para su revisión individual.

5 Preparación Si el plan de proyecto es técnicamente complejo entonces:Cada miembro del equipo debe:-Examinar el plan y los documentos relacionados para iniciar una revisión individual antes de la reunión.-Documentar, clasificar y enviar al autor las anomalías encontradas.Sino, el autor puede:-Preparar los documentos requeridos para iniciar la revisión.

6 Revisión Si el plan de proyecto es técnicamente complejo entonces:El equipo de revisión deberá:-Realizar reuniones para cumplir con:--La evaluación del plan de proyecto e identificación de las anomalías.--Determinar si el plan de proyecto está completo y cumple con los requisitos de la revisión.Sino, el autor puede:-Evaluar el plan de proyecto e identificar las anomalías.-Determinar si el plan de proyecto está completo y cumple con los requisitos de la revisión.

7 Seguimiento Si el plan de proyecto es técnicamente complejo entonces:El autor debe:-Generar una lista de puntos de acción y sus riesgos.-Documentar las reuniones.-Verificar que los puntos de acción planeados estén cerrados o hechos.Sino, el autor puede:- Generar una lista de puntos de acción y sus riesgos.-Verificar los puntos de acción planeados estén cerrados o hechos.

8 Postmortem Acabada la revisión, el autor debe hacer:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del plan del proyecto.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.Enviar la documentación al Project Manager.


Criterios de Salida

La revisión, para finalizar, debe completar todas las fases y contar con al menos los siguientes artefactos:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del plan de proyecto.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.

Tabla 3: Proceso para la verificación del plan de proyecto

Bitácora de Tiempo

Su objetivo es registrar el tiempo invertido en la revisión, para encontrar puntos de mejora en desempeño y resultados de la revisión.

ID Revisión FechaAutorArtefactoFase Inicio Fin Interrupción Comentarios

Tabla 4: Bitácora de tiempo

Checklist de Revisión

Su objetivo registrar si el plan de proyecto cumple con las características propias de un plan de proyecto, de acuerdo al equipo de verificación y validación, y de reconocer algún otro defecto a enmendar, o mejora a realizar.

ID Revisión FechaAutorFaseArtefactoObjetivos

ChecklistIniciación del Plan Sí No N/A Comentario¿El alcance del proyecto esta definido?¿Los requerimientos del usuario están establecidos?¿Hay sistemas afectados por este proyecto?¿Hay un gerente de proyecto para el proyecto?


¿Hay entregables identificados?¿El equipo y sus miembros han sido identificados?¿Se definió una carpeta de proyecto u otro mecanismo para la gestión de documentos e información del proyecto?Establecimiento del Ambiente del Proyecto Sí No N/A Comentario¿Se documentaron un ciclo de vida, productos de trabajo, revisiones para el plan del proyecto?¿Están definidos y documentado los criterios para la selección de métodos y herramientas para soportar el enfoque de tecnología que ha sido identificada?¿Esta las necesidades de comunicación identificadas y definidas (internet, voz, email)?¿Cada una de las necesidades del equipo han sido revisadas (entrenamiento, espacios de trabajo)?¿Se han seleccionado los métodos y herramientas de trabajo?Definición de Métricas del Proyecto Sí No N/A Comentario¿Las características principales (metas, objetivos, ambiente, riesgos, etc.) han sido identificadas?¿Se han definido indicadores y reportes para todas las características identificadas?¿Se determinó cuando las mediciones deben reunirse, analizarse y reportarse?¿Se preparó un plan de medición del proyecto ajustado al plan de proyecto general?Asignación de Personal y Calendarización de Desarrollo

Sí No N/A Comentario

¿Se preparó un plan de medición del proyecto ajustado al plan de proyecto general?¿Ha sido generado el calendario con una herramienta de planeación y sus resultados son revisados para validar que cumplen con las metas del proyecto?¿El calendario final ha sido documentado en el plan del proyecto?Administración de Riesgos Sí No N/A Comentario¿Se identificaron riesgos?¿Se tiene una tabla de riesgos?¿Se incluyeron lecciones aprendidas de proyectos anteriores?¿Los factores de riesgo han sido calificados?


¿Cada factor de alto riesgo ha sido especificado con una sentencia?¿Cada sentencia de riesgos tiene condiciones y consecuencias una vez que el proyecto inicio?¿Cada sentencia de riesgo ha sido asignada a un porcentaje de probabilidad de ocurrencia?¿Cada sentencia de riesgo tiene asignado una perdida si el riesgo ocurre?¿La exposición al riesgo ha sido calculada por cada sentencia de riesgo?¿Existen planes de acción de mitigación para los riesgos que pueden ser mitigados?Para cada riesgo que será mitigado, ¿Se tiene su costo o esfuerzo estimado para el plan de acción de mitigación?¿El plan de contingencia ha sido documentado y se incluyen su esfuerzo y costo anticipado?Consistencia, Claridad, Integridad y Exactitud Sí No N/A Comentario¿El plan de proyecto no es demasiado detallado, ni demasiado general?¿Cada componente del plan de proyecto es claro y sin ambigüedades?¿La relación entre componentes es clara?¿No falta ningún detalle relevante en cualquiera de los componentes del plan del proyecto?¿Hay detalles irrelevantes presentes en los componentes del plan de proyecto?¿Hay algún componente innecesario en el plan del proyecto?¿Alguna información es redundante en el plan?¿Está relacionado el plan con los documentos de referencia?¿Es el contendido del plan consistente con el alcance del proyecto y sus objetivos?¿El plan tiene el nivel de detalle, vocabulario, sintaxis de acuerdo con su audiencia y su supuesto uso?Comentarios

Otras Anomalías


Recomendaciones

Firma de AceptaciónNombre Firma

Tabla 5: Checklist revisión del proyecto

7.3.Revisión de Especificaciones de Software (SRS)Proceso de revisión de la especificación de requerimientos de software

Propósito Guiar en la revisión del SRS para determinar la capacidad de uso del documento e identificar irregularidades de especificaciones y estándares para el SRS; y gestionar la documentación que evidencie el estado técnico del mismo.


La revisión, antes de iniciar, debe contar con al menos los siguientes artefactos:-Objetivos de la revisión.-Checklists (regulaciones y estándares) para hacer la revisión técnica.-Checklists de revisiones anteriores (sí las hubo) con las anomalías encontradas.-Documentación del SRS a revisar.


1 Administración El Project Manager debe:-Asegurar que la revisión cumple con los estándares y requerimientos del SRS.-Facilitar la planeación, definición, ejecución y administración de la revisión.-Proveer orientación para el procedimiento de la revisión.

2 Planeación Si el SRS es técnicamente complejo entonces:El autor del SRS es responsable de:-Identificar el equipo de revisión.-Asignar responsabilidades a cada miembro del equipo.-Calendarizar actividades y anunciar el lugar de encuentro(s).-Distribuir el material de la revisión a los miembros.Sino, el autor debe:-Planear y Calendarizar su revisión individual.


Si el SRS es técnicamente complejo entonces:El autor del artefacto debe de:-Presentar una síntesis del procedimiento que se llevará a cabo en la revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el checklist como procedimiento de la revisión a llevar.


Si el SRS es técnicamente complejo entonces:El autor debe:-Presentar una síntesis del producto que será sometido a revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el SRS para su revisión individual.


5 Preparación Si el SRS es técnicamente complejo entonces:Cada miembro del equipo debe:-Examinar el SRS y los documentos enviados para iniciar una revisión individual antes de la reunión.-Documentar, clasificar y enviar al autor las anomalías encontradas.Sino, el autor puede:-Preparar los documentos requeridos para iniciar la revisión.

6 Revisión Si el SRS es técnicamente complejo entonces:El equipo de revisión deberá:- Realizar reuniones para cumplir con:- La evaluación del SRS e identificación de las anomalías.- Determinar si el SRS está completo y cumple con los requisitos de la revisión.Sino, el autor puede:-Evaluar el SRS e identificar las anomalías.-Determinar si el SRS está completo y cumple con los requisitos de la revisión.

7 Seguimiento Si el SRS es técnicamente complejo entonces:El autor debe:-Generar una lista de puntos de acción y sus riesgos.-Documentar las reuniones.-Verificar que los puntos de acción planeados estén cerrados o hechos.Sino, el autor puede:- Generar una lista de puntos de acción y sus riesgos.-Verificar los puntos de acción planeados estén cerrados o hechos.

8 Postmortem Acabada la revisión, el autor debe hacer:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del SRS.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.Enviar la documentación al Project Manager.

Criterios de Salida

La revisión, para finalizar, debe completar todas las fases y contar con al menos los siguientes artefactos:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del SRS.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.

Tabla 6: Proceso para la verificación del documento de requerimientos


Bitácora de Tiempo

Su objetivo es registrar el tiempo invertido en la revisión para encontrar puntos de mejora en desempeño y resultados de la revisión.


Tabla 7: Forma de bitácora de tiempo


Objetivo registrar si la especificación cumple con ciertas características propias del documento SRS y de reconocer algún otro defecto o mejora a realizar.


ChecklistOrganización e integridad Sí No N/

AComentario

¿Están todas las referencias a otros requerimientos correctos?¿Todos los requerimientos están escritos a un nivel consistente y adecuado de detalle?¿Los requerimientos proporcionan una adecuada base para el diseño?¿Esta la prioridad de cada requerimiento incluida?¿Están todas las interfaces de hardware, software, y comunicación definidas?¿Los requerimientos definidos tienen algoritmos intrínsecos?¿La especificación incluye todo el conocimiento del cliente o las necesidades del sistema?¿Están documentados todos los


comportamientos esperados para todas las condiciones de error anticipadas?Precisión Sí No N/

AComentario

¿Algún requerimiento tiene conflicto o esta duplicado con otro requerimiento?¿Cada requerimiento esta escrito de manera clara, concisa y sin ambigüedades?¿Cada requerimiento es verificable por medio de pruebas, demostraciones, revisiones o análisis?¿Cada requerimiento tiene un alcance para el proyecto?¿Cada requerimiento está libre de contenido innecesario y errores gramaticales?¿Hay información necesaria que haga falta en la especificación de algún requerimiento?¿Pueden los requerimientos ser implementados sin conocer las restricciones?¿Están los mensajes de error especificados de manera única y significativa?Atributos de Calidad Sí No N/

AComentario

¿Los objetivos de desempeño están propiamente especificados?¿Están todas las consideraciones de seguridad y protección especificadas apropiadamente?¿Hay otras metas de otros atributos de calidad que estén explícitamente documentados y cuantificados, con sus aceptables ventajas y desventajas?Trazabilidad Sí No N/

AComentario

¿Cada requerimiento es único y correctamente identificado?¿Cada requerimiento funcional de software es trazable a un requerimiento de alto nivel?Temas Especiales Sí No N/

AComentario

¿Son todos los requerimientos y sólo eso? Es decir, no diseños o soluciones de implementación¿Están todas las funciones de tiempo crítico identificadas, y sus criterios de tiempo especificados?¿Los temas de internacionalización han sido adecuadamente tomados en cuenta?


Comentarios

Otras Anomalías

Recomendaciones


Tabla 8: Checklist del documento de requerimientos

7.4.Revisión de Diseño (ADR)Proceso de revisión de diseño

Propósito - Guiar al equipo de desarrollo en la revisión del diseño de software, para determinar la capacidad de uso e identificar irregularidades de especificaciones y estándares del artefacto.- Guiar al equipo de desarrollo en la gestión de la documentación que evidencie el estado técnico del mismo.


La revisión, antes de iniciar, debe contar con al menos los siguientes artefactos:-Objetivos de la revisión.-Checklists (regulaciones y estándares) para hacer la revisión técnica.-Checklists de revisiones anteriores (sí las hubo) con las anomalías encontradas.-Documentación del diseño de software a revisar.


1 Administración El Project Manager debe:-Asegurar que la revisión cumple con los estándares y requerimientos del diseño de software.-Facilitar la planeación, definición, ejecución y administración de la revisión.-Proveer orientación para el procedimiento de la revisión.

2 Planeación Si el diseño de software es técnicamente complejo entonces:El autor del diseño de software es responsable de:-Identificar el equipo de revisión.-Asignar responsabilidades a cada miembro del equipo.-Calendarizar actividades y anunciar el lugar de encuentro(s).-Distribuir el material de la revisión a los miembros.Sino, el autor debe:-Planear y Calendarizar su revisión individual.



Si el diseño de software es técnicamente complejo entonces:El autor debe de:-Presentar una síntesis del procedimiento que se llevará a cabo en la revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el checklist como procedimiento de la revisión a llevar.


Si el diseño de software es técnicamente complejo entonces:El autor debe:-Presentar una síntesis del producto que será sometido a revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el diseño de software para su revisión individual.

5 Preparación Si el diseño de software es técnicamente complejo entonces:Cada miembro del equipo debe:-Examinar el diseño y los documentos enviados para iniciar una revisión individual antes de la reunión.-Documentar, clasificar y enviar al autor las anomalías encontradas.Sino, el autor puede:-Preparar los documentos requerida para iniciar la revisión.

6 Revisión Si el diseño de software es técnicamente complejo entonces:El equipo de revisión deberá:-Realizar reuniones para cumplir con:--La evaluación del producto e identificación de las anomalías.--Determinar sí el diseño de software está completo y cumple con los requisitos de la revisión.Sino, el autor puede:-Evaluar el diseño de software e identificar las anomalías.-Determinar sí el diseño de software está completo y cumple con los requisitos de la revisión.

7 Seguimiento Sí el diseño de software es técnicamente complejo entonces:El autor debe:-Generar una lista de puntos de acción y sus riesgos.-Documentar las reuniones.-Verificar que los puntos de acción planeados estén cerrados o hechos.Sino, el autor puede:- Generar una lista de puntos de acción y sus riesgos.-Verificar los puntos de acción planeados estén cerrados o hechos.

8 Postmortem Acabada la revisión, el autor debe hacer:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del diseño de software.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.Enviar la documentación al Project Manager.


Criterios de Salida

La revisión, para finalizar, debe completar todas las fases y contar con al menos los siguientes artefactos:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del diseño de software.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.

Tabla 9: Procesos de verificación del diseño

Bitácora de Tiempo





Objetivo registrar si el diseño cumple con ciertas características propias del diseño y de reconocer algún otro defecto o mejora a realizar.


ChecklistEstructura Sí No N/A Comentario¿Es el pseudocódigo consistente a nivel de detalle?Datos Sí No N/A Comentario¿Todos los datos han sido propiamente definidos e inicializados?¿Todos los datos son usados?


¿El nombre de los elementos y tipos de datos conforman el diccionario de datos del proyecto?¿Son usados por default y están correctos?Exactitud e integridad Sí No N/A Comentario¿Las especificaciones externas de cada módulo están completas y comprobables?¿Todos los métodos numéricos han analizados para la precisión?¿El presupuesto del diseño de alto nivel de memoria se ha ampliado en más detalle y esta actualizado?¿Todas las funciones están claramente específicas y son lógicamente independientes?¿Hay problemas de mantenimiento abordados adecuadamente?¿Cada módulo tiene alta cohesión interna?¿Cada módulo tiene bajo acoplamiento externo?¿El diseño detallado es verificable?¿Es la lógica correcta, clara y completa?¿Todas los interfaces de usuario están totalmente diseñadas?¿Pueden las condiciones de terminación de los ciclos ser realizadas?¿Puede toda la lógica ser probada?Robustez Sí No N/A Comentario¿Las condiciones de error son manejadas de una manera no destructiva?¿Pueden las medidas correctivas ser tomadas por cada modulo que atrapa un error?¿Las condiciones inusuales son manejadas de manera razonable y no destructiva?Aspectos generales Sí No N/A Comentario¿El diseño general implanta todos los requisitos explícitos? ¿Una tabla de trazabilidad fue desarrollada?¿El diseño en general cumplen todos los requisitos implícitos?¿El diseño esta representado en una forma que es fácil de entender por personas ajenas?¿Esta la notación del diseño estandarizada? ¿Es consistente?¿El diseño fue creado con patrones y procedimiento reconocibles de la arquitectura?¿El diseño se esfuerza por incorporar


componentes reutilizables?¿El diseño es modular?¿El diseño tiene definido tanto procedimiento y abstracción de los datos que pueden ser reutilizados?¿La arquitectura de software final ha sido particionada para facilitar su implementación? ¿Y el mantenimiento?¿Los conceptos de ocultamiento de la información y la independencia funcional han sido seguidos a través del diseño?¿La especificación de diseño ha sido desarrollada para el software?Interfaz de usuario Sí No N/A Comentario¿Hay varios estados de la interfaz documentados?¿Tiene objetos y acciones que aparecen en el contexto de la interfaz ha definido?¿La flexible interacción ha sido definida como un criterio de diseño en la interfaz?¿Se tienen definidos modos de expertos y novatos de interacción?¿Es la metáfora de la GUI (si hay) consistente con las aplicaciones en general?¿Son los iconos claros y comprensibles?¿La interacción es intuitiva?¿Tiene un sistema de ayuda integrado implementado?¿Los mensajes de error que aparecen en la interfaz son fáciles de entender? ¿Ayudan al usuario a resolver el problema rápidamente?¿El color que se utiliza es efectivo?¿Hay un prototipo para la interfaz que se ha desarrollado?¿Las impresiones de usuarios del prototipo han sido recolectadas de manera organizada?Diseño de componentes Sí No N/A Comentario¿Cada algoritmo ha sido probado para descubrir errores? ¿Cada algoritmo es correcto?¿Es el diseño del algoritmo consistente con las estructura de datos que el componente manipula?¿Hay alternativas algorítmicas de diseño que se han considerado? En caso afirmativo, ¿por qué fue elegido este diseño?¿La complejidad de cada algoritmo fue


calculada?Comentarios

Otras Anomalías

Recomendaciones


Tabla 11: Checklist de revisión del diseño

7.5.Revisión de códigoProceso de revisión de código

Propósito Guiar al equipo de desarrollo en la revisión del código de software para determinar la capacidad de uso e identificar irregularidades de especificaciones y estándares del artefacto.Guiar al equipo de desarrollo en la gestión de la documentación que evidencie el estado técnico del mismo.


La revisión, antes de iniciar, debe contar con al menos los siguientes artefactos:-Objetivos de la revisión.-Checklists (regulaciones y estándares) para hacer la revisión técnica.-Checklists de revisiones anteriores (si las hubo) con las anomalías encontradas.-Documentación del código de software a revisar.


1 Administración El Project Manager debe:-Asegurar que la revisión cumple con los estándares y requerimientos del código de software.-Facilitar la planeación, definición, ejecución y administración de la revisión.-Proveer orientación para el procedimiento de la revisión.

2 Planeación Si el código de software es técnicamente complejo entonces:El autor del código de software es responsable de:-Identificar el equipo de revisión.-Asignar responsabilidades a cada miembro del equipo.-Calendarizar actividades y anunciar el lugar de encuentro(s).-Distribuir el material de la revisión a los miembros.Sino, el autor debe:-Planear y Calendarizar su revisión individual.



Si el código de software es técnicamente complejo entonces:El autor debe de:-Presentar una síntesis del procedimiento que se llevará a cabo en la revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el checklist como procedimiento de la revisión a llevar.


Si el código de software es técnicamente complejo entonces:El autor debe:-Presentar una síntesis del producto que será sometido a revisión a los miembros del equipo.Sino, el autor puede:-Utilizar el código de software para su revisión individual.

5 Preparación Si el código de software es técnicamente complejo entonces:Cada miembro del equipo debe:-Examinar el código y los documentos enviados para iniciar una revisión individual antes de la reunión.-Documentar, clasificar y enviar al autor las anomalías encontradas.Sí no, el autor puede:-Preparar los documentos requerida para iniciar la revisión.

6 Revisión Si el código de software es técnicamente complejo entonces:El equipo de revisión deberá:-Realizar reuniones para cumplir con:--La evaluación del producto e identificación de las anomalías.--Determinar sí el código de software está completo y cumple con los requisitos de la revisión.Sí no, el autor puede:-Evaluar el código de software e identificar las anomalías.-Determinar sí el código de software está completo y cumple con los requisitos de la revisión.

7 Seguimiento Si el código de software es técnicamente complejo entonces:El autor debe:-Generar una lista de puntos de acción y sus riesgos.-Documentar las reuniones.-Verificar que los puntos de acción planeados estén cerrados o hechos.Sino, el autor puede:- Generar una lista de puntos de acción y sus riesgos.-Verificar los puntos de acción planeados estén cerrados o hechos.

8 Postmortem Acabada la revisión, el autor debe hacer:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del código de software.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.Enviar la documentación al Project Manager.


Criterios de Salida

La revisión, para finalizar, debe completar todas las fases y contar con al menos los siguientes artefactos:-Documentación de revisión(es).-Documentación de objetivos logrados en la revisión.-Documentación de aceptación del código de software.-Listado de las anomalías presentadas resueltas y no resueltas.-Listado de Recomendaciones.

Tabla 12: Proceso de revisión de código

Bitácora de Tiempo






ChecklistEstructura Sí No N/A Comentario¿El código esta completa y correctamente implementado?¿El código conforma con algún estándar de codificación?


¿Está el código bien estructurado, coherente en estilo, y consistente en formato?¿Hay algún procedimiento no utilizado, innecesario o inalcanzable?¿Hay algunas sobras de código o rutinas de prueba en los documentos de codificación?¿Puede cualquier código ser remplazado por llamadas externas a componentes reutilizables o librerías?¿Hay bloques de código repetido que pueda ser condensando en un solo procedimiento?¿El uso de almacenamiento es eficiente?¿Son usados símbolos antes que constantes o cadenas de caracteres constantes?¿Existen módulos excesivamente complejos que deban ser restructurados o divididos en varias rutinas?Documentación Sí No N/A Comentario¿Esta el código de forma clara y debidamente documentado y con un adecuado estilo de mantenimiento fácil de comentarios fácil?¿Están todos los comentarios consistentes con el código?Variables Sí No N/A Comentario¿Están todas las variables propiamente definidas con un significado, consistente y claro?¿Todas las variables tienen el tipo apropiado de consistencia o casteo?¿Hay alguna redundancia o variables sin uso?Operaciones Aritméticas Sí No N/A Comentario¿El código evita comparar numeros de punto flotante por igualdad?¿El código previene sistemáticamente errores de redondeo?¿El código evita sumas y restas con números con magnitudes muy diferentes?¿Los divisores son probados en busca de ceros o ruido?Ciclos y bifurcaciones Sí No N/A Comentario¿Todos los ciclos, bifurcaciones, y lógica están construidos de manera completa, correcta y propiamente anidada?¿Son probados los casos más comunes de cadena IF-ELSEIF?¿Están todos los casos cubiertos en los bloques IF-ELSEIF o CASE, incluyendo las clausulas ELSE


o DEFAULT?¿Cada sentencia de CASE tiene una sentencia DEFAULT?¿Las condiciones de terminación de ciclos son evidentes y alcanzables siempre?¿Están los índices o sub-índices iniciados apropiadamente antes del inicio del ciclo?¿Puede alguna sentencia, que está dentro del ciclo, ser posicionada fuera del ciclo?¿El código dentro del ciclo evita la manipulación del índice o la usa para salir del ciclo?Programación defensiva Sí No N/A Comentario¿Los índices, apuntadores y subscriptores son probados contra vectores, registros y límites de archivo?¿Se prueba la validez e integridad de los datos importados y los argumentos de entrada?¿Todas las variables de salida están asignadas?¿La memoria usada es desalojada?¿Se usan los tiempos de espera o trampas de error para tener acceso a dispositivos externos?¿Se valida que el archivo exista antes de tratar de acceder a el?¿Todos los dispositivos quedan en el estado correcto al terminar el programa?Comentarios

Otras Anomalías

Recomendaciones


Tabla 14: Checklist de revisión de código


7.6.Planes de Revisión de Verificación y Validación

8. Pruebas

8.1.PropósitoDefinir procesos de definición y ejecución de casos de prueba para cada artefacto de software

que especifiquen los pasos a seguir y las actividades a llevar a cabo para evitar discrepancias en los procesos de definición y ejecución.

De igual manera, definir formas de registro de todos los casos de prueba definidos y los resultados de su ejecución con la finalidad de tener una sola forma de registro estandarizada para todos los diferentes procesos relacionados con los casos de prueba.

8.2.Procesos para definir casos de pruebaPropósito Guiar en la evaluación y mejora de la calidad del artefacto de software desarrollado preparando

casos de prueba para la identificación de defectos, problemas y puntos de mejora que en el artefacto de software no pudieran no detectarse en las revisiones e inspecciones.


El diseñador de casos de pruebas, antes de iniciar, debe contar con:-Plan de Proyecto.-Especificación de Requerimientos de Arquitectura (ARS).-Especificación de Requerimientos de Diseño (DRS).


1 Administración El Project Manager debe:-Asegurar que la definición de casos de prueba cumple con los estándares y requerimientos acordados por ley, contrato u otra política.-Planear tiempo y recursos para la creación de casos de pruebas.-Facilitar la planeación, definición, ejecución y administración de creación de casos de pruebas.-Proveer orientación para el procedimiento de la creación de casos de pruebas.

2 Planeación El Diseñador de casos debe:-Recibir documentación por parte del project manager.-Calendarizar una fecha de entrega de una propuesta de los casos de prueba.

3 Análisis El Diseñador de casos debe:-Estudiar los documentos que recibió.-Definir las prioridades de los requerimientos en base a su sensibilidad en el artefacto del software.

4 Definición El Diseñador de casos debe:-Definir los casos de prueba que validan que los requerimientos solicitados los cumple el artefacto de software que se desarrollará.

5 Revisión El Diseñador de casos de pruebas debe:-Realizar revisiones técnicas de los casos de prueba generados.-Documentar las revisiones.


6 Inspección El Diseñador de casos de pruebas debe:-Realizar inspecciones técnicas de los casos de prueba generados.-Documentar las inspecciones.

7 Postmortem Una vez definido el diseño de los casos de prueba, el Diseñador de casos de pruebas debe de hacer los siguientes documentos:-Tabla de casos de prueba a realizar.-Documentación detallada de los casos de prueba a realizar.

Criterios de Salida

El Diseñador de casos de pruebas debe:-Realizar, al menos una, inspección del diseño con expertos en el área y tener la aceptación de ellos.El diseñador debe concluir este proceso con varios artefactos:-Tabla de casos de prueba a realizar.-Documentación detallada de los casos de prueba a realizar.

Tabla 15: Proceso para crear pruebas

8.3.Proceso de ejecución de casos de pruebaPropósito Evaluar y mejorar la calidad del artefacto desarrollado a través de la identificación de defectos,

problemas y puntos de mejora en el artefacto de software no detectados en las revisiones e inspecciones.


Antes de iniciar con la ejecución de pruebas se debe contar con:-Tabla de casos de prueba a realizar.-Documentación detallada de los casos de prueba a realizar.-Plan de proyecto.-Especificación de Requerimientos de Arquitectura (ARS).-Especificación de Requerimientos de Diseño (DRS).


1 Administración El Project Manager debe:-Asegurar que la ejecución de los casos de prueba cumplen con los estándares y requerimientos acordados por ley, contrato u otra política.-Planear tiempo y recursos para la ejecución de casos de prueba.-Facilitar la planeación, definición, ejecución y administración de la ejecución de casos de prueba.-Proveer orientación para el procedimiento de la ejecución de casos de prueba.

2 Planeación El verificador de pruebas debe:-Recibir documentación por parte del diseñador de casos.-Calendarizar una fecha de entrega de una propuesta de las pruebas realizadas.

3 Análisis El verificador de pruebas debe:-Estudiar los documentos que recibió.-Preparar el ambiente necesario para la ejecución de las pruebas.

4 Definición El verificador de pruebas debe:-Ejecutar las pruebas en el ambiente solicitado.-Documentar los resultados


5 Revisión El verificador de pruebas debe:-Realizar revisiones técnicas del ambiente, la ejecución de la prueba y los resultados obtenidos.-Documentar las revisiones.

Inspección En caso de haber una prueba compleja en su ejecución y en el entendimiento de sus resultados, entonces:-Realizar inspecciones de la ejecución de prueba realizada.-Documentar las revisiones.

6 Postmortem Una vez completadas las pruebas el verificador de pruebas debe hacer los siguientes documentos:-Documentación de los resultados de las pruebas realizadas.

Criterios de Salida

El verificador de pruebas debe concluir con varios artefactos:-Documentación de las pruebas realizadas.

Tabla 16: Proceso para ejecutar pruebas

8.4.Formas de registro de casos de pruebaBitácora de Tiempo

Su objetivo es registrar el tiempo invertido en la definición y ejecución de casos de prueba para encontrar puntos de mejora en desempeño y resultados de los procesos.



Escenario de Casos de prueba

Tipo de PruebasElemento(s) bajo prueba

Objetivo de las Pruebas

No. de Prueba

Nombre de Prueba

Estado Inicial Input Output Passed (✓| X )


Tabla 18: Formato para los casos de prueba

8.5. Pruebas implementadasPara validar el prototipo se implementaron casos de prueba sobre las entidades, la

implementación de los casos de prueba pueden ser vistos en la siguiente liga, que es parte del repositorio donde se trabajo el prototipo.

https://www.assembla.com/code/proyecto-scrum/subversion/nodes/trunk/src/scrum-handler/ScrumHandler.Dominio.Test

En estas pruebas se validan los datos de entrada y de salida de las entidades críticas, así como las pruebas de integración entre esas entidades, para poder cubrir las actividades clave que se encontraron en los perfiles operacionales.


8.6.Ejemplo de casos de pruebasA continuación se muestran ejemplos de como serian las pruebas para el prototipo.

Tipo de Pruebas Pruebas Unitarias de Caja NegraElemento(s) bajo prueba ProductBacklog.ReorderFeaturePriorities

Objetivo de las Pruebas Se valida que ProductBacklog reordena las prioridades de los Features de acuerdo al cambio de prioridad de uno de los Features del ProductBacklog.Estos casos de prueba se encuentran implementados en: ProductBacklogTest.cs

No. de Prueba Nombre de Prueba Estado Inicial Input Output

Passed (✓| X )

1

Tests if reorder feature priorities when new priority is moved to beginning.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}, {name: "new feature", priority: 3}]

features,features[3],oldPriority: -1,newPriority: 1

features: [ {name: "feature 1", priority: 2},

{name: "feature 2", priority: 3},


{name: "new feature", priority: 1} ]

✓

2

Test if reorders features priorities with new priority at middle.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}, {name: "new feature", priority: 3}]

features,features[3],oldPriority: -1,newPriority: 2




{name: "new feature", priority: 2}]

✓

3

Test if reorder features priorities when top priority moves to lowest.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}, {name: "feature 4", priority: 4}]

features,features[0],oldPriority: 1,newPriority: 4




{name: "new feature", priority: 3}]

✓


4

Tests if reorder features priorities when top priority moves to middle.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}, {name: "feature 4", priority: 4}, {name: "feature 5", priority: 5}]






{name: "feature 5", priority: 5}]

✓

5

Tests if reorder features priorities when lowest priority moves to top.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}]





✓

6

Tests if reorder features priorities when lowest priority moves to middle.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}, {name: "feature 4", priority: 4}, {name: "feature 5", priority: 5}]







✓

7

Test if reorder feature to same priority does not change order.

features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}]





✓

9.10.

Tipo de Pruebas Pruebas de Integración de Caja NegraElemento bajo prueba ProductBacklog.ReorderFeaturePriorities + BaseEntity<Feature> +

ScrumHandler.Dominio.Helpers.Extensions.MakeWiredCollection + ObservableEntityCollection<Feature> + CompositionObserver + Feature

Objetivo de las Pruebas Se valida que ProductBacklog, la clase que hereda de BaseEntity<Feature> e implementa la interfaz IObservableComposition<Feature>, permita que el método de extensión MakeWiredCollection<Feature> cree una ObservableEntityCollection<Feature> al cuál se le observa con un CompositionObserver, y también se valida que este a su vez, redirija los eventos de modificación recibidos al BaseEntity<Feature>, por medio de la interfaz IObservableComposition<Feature> que este implementa.Estos casos de prueba se encuentran implementados en: ProductBacklogTest.cs

No. de Prueba

Nombre de Prueba Estado Inicial Input Output

Passed (✓| X )

1

Tests if order after last feature removal is correct.

ProductBacklog.Features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}]

ProductBacklog.Features.Remove(ProductBacklog.Features[2])

ProductBacklog.Features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}]

✓

2

Tests if order after middle feature removal is correct.

ProductBacklog.Features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}, {name: "feature 4", priority: 4}, {name: "feature 5", priority: 5}]

ProductBacklog.Features.Remove(ProductBacklog.Features[2])

ProductBacklog.Features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 4", priority: 3}, {name: "feature 5", priority: 4}]

✓

3

Tests if a feature added is assigned last priority.

ProductBacklog.Features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}],feature: {name: "feature 3", priority: 0}

ProductBacklog.Features.Add(feature)

ProductBacklog.Features: [ {name: "feature 1", priority: 1}, {name: "feature 2", priority: 2}, {name: "feature 3", priority: 3}]

✓

Tipo de Prueba Pruebas de Integración de Caja NegraElementos bajo prueba

ScrumHandlerContext + ProductBacklog.ReorderFeaturePriorities + BaseEntity<Feature> + ScrumHandler.Dominio.Helpers.Extensions.MakeWiredCollection + ObservableEntityCollection<Feature> + CompositionObserver + Feature

Objetivo de las pruebas

Se valida que las modificaciones en una entidad Feature efectivamente disparen los eventos de la entidad de ProductBacklog y refleje los cambios en el contexto de entidades.

Estos casos de prueba se encuentran implementados en: ProductBacklogIntegrationTest.csEstado Inicial del Contexto de Entidades

Contexto Inicializado con: [ person: { Email: "[email protected]", Firstname: "name", Lastname: "lastname", Password: "password" },project: { Creator: person, Name: "project", ProductBacklog: { Features: [{ Name: "first feature", UserStory: "feature user story", Estimate: 10 }, { Name: "second feature", UserStory: "feature user story", Estimate: 10 }, { Name: "third feature", UserStory: "feature user story", Estimate: 10 }]}}]

Nombre de Prueba Estado Inicial (de la prueba) Input Output

Passed (✓| X )

Tests if backlog reorders priorities in background to previously added features. feature: Context.Features[0] feature.Priority = 3

Context.Features: [{Name:"first feature", Priority:3},{Name:"second feature", Priority:1},{Name:"third feature", Priority:2}]

✓

Tests if backlog reorders priorities correctly after the last feature is removed.

feature: Context.Features[2]backlog: Context.ProductBacklogs[0]

backlog.Features .Remove(feature)

Context.Features: [{Name:"first feature", Priority:1},{Name:"second feature", Priority:2}]

✓

https://www.assembla.com/code/proyecto-scrum/subversion/nodes/trunk/src/scrum-handler/ScrumHandler.Dominio.Test/ProductBacklogIntegrationTest.cs


9. Notificación de problemas y acción correctivaCuando un defecto o problema aparece durante la ejecución de los casos de prueba es

prudente tomar acciones que solventen el problema e informar al personal indicado inmediatamente.

En el caso de la comunicación, el verificador o ejecutante de casos debe de tener en todo momento los datos de ubicación y contacto del administrador de proyectos, gerente de desarrollo y del desarrollador. Entonces cuando se completan todas las pruebas, verificador debe de:

Enviar los resultados al desarrollador y al gerente de desarrollo a través del medio de comunicación definido previamente entre estos miembros del equipo.

Dar seguimiento a que las correcciones que ha solicitado, con sustento en las pruebas realizadas, sean llevadas a cabo.

Una vez que la ejecución de las pruebas den el resultado esperado el recomendable comunicar al administrador de proyectos para que marque la actividad como completa y enviar copia al desarrollador y gerente de desarrollo para que estén entrados de que todo ha sido satisfactorio.

El proceso de ejecución de casos de prueba ofrece una serie de pasos y sus correspondientes actividades que permiten llevar un control y una ejecución de pruebas estandarizada y justa a las necesidades y la organización del equipo de proyecto.

Sin embargo, hay ciertas actividades que se recomiendan seguir en la circunstancia de que se encuentre un defecto en la ejecución de alguno de los casos de prueba, por lo que se recomienda seguir las siguientes actividades:

a. Marcar como no aprobado el caso de prueba en la bitácora de escenarios de casos de prueba.

b. Registrar el caso de prueba, el defecto y sus características en la bitácora de resumen de defectos de la manera más clara y descriptiva posible.

c. Seguir con los demás casos de prueba de manera ordinaria.

d. Repetir los pasos a y b en caso de que se sigan presentando defectos en la ejecución de los casos de prueba.

e. Si se acaba de ejecutar los casos de prueba antes del tiempo planeado de su ejecución entonces entregar los resultados inmediatamente para aprovechar los días que sobraron y los encargados de desarrollo puedan corregir los defectos.


f. Si se acaba de ejecutar los casos de prueba en el tiempo planeado de su ejecución entonces entregar los resultados inmediatamente para no perder los días que ya no corresponden a pruebas.

g. Si se acaba el tiempo de ejecución de pruebas y aun no se termina de realizarlas pero hay escenarios de casos con defectos se recomienda entregar una primera versión de la documentación para que los autores del artefacto no desaprovechen el tiempo planeado para la corrección de defectos.

10. Herramientas, técnicas y metodologíasHerramientas

Microsoft Quality Testing Framework

Se utilizará el marco de trabajo de Microsoft para la implementación de casos de prueba, con el objetivo de incrementar la integración de las pruebas con Visual Studio Ultimate 2010, y así asegurar la calidad de la información generada por la herramienta de análisis de código y cubrimiento de pruebas de Visual Studio Ultimate 2010.

DevExpress Unit Test Runner

Se utilizará el ejecutor de pruebas unitarias de DevExpress para ejecutar rápidamente las pruebas automatizadas del sistema, con el objetivo de reducir el tiempo utilizado ejecutando pruebas y así incrementar la productividad de implementación.

TestingTools - Expressive Assertions

Se debe utilizar este componente .Net, para definir aserciones expresivas encima de las librerías de pruebas unitarias de Microsoft, con el objetivo de asegurar la legibilidad del código de las pruebas automatizadas.

Técnicas

La técnica Arrange-Act-Assert para la definición de casos de prueba (Jeff Grigg, 2009)

Todas las pruebas se deben implementar y diseñar utilizando el patrón Arrange-Act-Assert para asegurar la legibilidad del diseño e implementación de los casos de prueba, donde, en la sección Arrange se define el estado previo a la ejecución de la prueba, en la sección Act se ejecuta el objeto bajo prueba, y finalmente en la sección Assert se verifica que estado final, resultante de ejecutar el objeto bajo prueba, sea el esperado.

La técnica de Code First – Test After, para la programación de unidades de código simples.

https://github.com/marcel-valdez/testing-tools


Para las unidades de código simples que caigan dentro de la funcionalidad de los perfiles operacionales más importantes, se permite codificar la unidad de código primero y diseñar e implementar las prueba después.

La técnica de Test Driven Development (Beck, 2003) para la programación de unidades de código complejas.

Se debe utilizar la técnica de Test Driven Development para la programación de unidades de código cuya implementación no sea obvia; primero se diseñan los casos de prueba por medio de nombres descriptivos del objetivo de cada caso de prueba, y luego se implementan los casos de prueba automatizados, finalmente se implementa la unidad de código compleja.

Metodología

Pruebas Iterativas basadas en el uso (Usage-based testing) (Chan, 2006)

Se debe analizar los perfiles operacionales de la aplicación, para generar pruebas priorizadas acorde a la probabilidad de uso (en cualquier día) de cada funcionalidad de la aplicación, dentro de los límites de tiempo asignados para el desarrollo de pruebas. Conforme se implementen los requerimientos del sistema, se desarrollan los casos de prueba de dado requerimiento. El objetivo de usar esta metodología es generar el número óptimo de pruebas para validar la funcionalidad crítica del sistema, con el tiempo disponible para pruebas.

11. Recolección de registros, mantenimiento y retenciónCon la finalidad de preservar la documentación SQA archivando en un solo lugar,

salvaguardando los diferentes cambios que se realicen sobre la documentación SQA, en caso de que la documentación lo requiera.

Por lo tanto, se propone un sistema de control de versiones que es una implementación en software del control de versiones que automatiza las tareas de guardar, recuperar, registrar, identificar y mezclar versiones de archivos. RCS es útil para archivos que son modificados frecuentemente.

Por lo tanto se propone el uso de la herramienta Subversión de Assembla, dicha herramienta web, tiene la capacidad de guardar cada cambio del documento como una nueva ‘revisión’ cuando se sube dicho cambio al servidor de Assembla haciendo una diferenciación entre los archivos por revisiones, por lo tanto puedes si es necesario repasar una revisión anterior puedes acceder a él. También Assembla te informa quien fue el ultimo en realizar en subir su cambio, además de los comentarios que agrego el autor del cambio que pueden ser significativos al cambio realizado. De igual manera, Assembla maneja una opción conocida como ‘tag’ que te permite marcar la documentación al momento sirviendo de referencia para saber si ese tag fue por razones como: primera versión entregable, primera vez que completo la documentación, o alguno otro evento importante que haya ocurrido al momento con la documentación SQA.


Los datos para comunicarse con los proveedores de la herramienta Subversión de Assembla son:

Departamento de Ventas y Soporte

Teléfono: 1.781.583.7541

Correo electrónico: [email protected]

Y los puedes seguir a través de las siguientes redes sociales:

http://blog.assembla.com

http://twitter.com/assembla

http://www.facebook.com/assembla

12. Gestión de riesgosLos riesgos que pueden afectar el plan de calidad vienen ligados con los riesgos que afecten al

proyecto de Scrum-Handler en si, ya que cualquier cambio en los requerimientos o en el alcance del proyecto generaría un cambio en las pruebas y actividades críticas planteadas en los puntos anteriores.

Descripción Impacto Estrategia Plan de acción

Desfase de actividades de la implementación

5 Mitigar El administrador del proyecto debe de asegurarse que las actividades sean realizadas en el tiempo especificado porque el retraso impactaría en el tiempo que se tiene para realizar las pruebas

Problemas con el repositorio Assembla

2 Mitigar Los desarrolladores y los verificadores del plan de calidad deben de seguir los estándares y métricas proporcionadas por el plan


Cambio de requerimientos 4 Mitigar En dado caso de que se cambien los requerimientos se deberá de modificar el plan de calidad lo mas antes posible para que no afecte el tiempo del desarrollo de las pruebas

Tabla 19: Riesgos que pueden afectar el plan de calidad


13. GlosarioAssembla: Servicio de Internet de repositorios SVN donde se pueden versionar los documentos binarios del proyecto.

Checklist: Listas de Revisión. Se usan en los procesos de revisión.

Commit: Consiste en persistir en el control de versiones, una versión nueva de un archivo.

Estándar: Patrón uniforme y formalmente definido en este documento o en otro externo (ej. IEEE 703) con el que debe conformar un producto de software.

Métrica: Unidad de medición para un producto de software (ej. LOC: Línea de Código).

Norma: Regla o conjunto de reglas, definidas en este documento u otro externo (ej. Convenciones de Codificación de Microsoft(r)), que hay que seguir para llevar a cabo una actividad de desarrollo de software.

Práctica de Software: Un patrón de acción, habitual y continuo de llevar a cabo una actividad de desarrollo de software (ej. Integración Continua).

Trunk: Directorio raíz del Assembla desde el cual se mantiene los cambios realizados por los involucrados

14. BibliografíaBeck, K. (2003). Test-Driven Development by Example. Addison Wesley.

Chan, E. (2006, February 25). Code Based vs. Usage Based Testing. Retrieved May 01, 2012, from Edwin Chan's Weblog: http://edwinchan.wordpress.com/2006/02/25/black-box-vs-white-box-testing/

Jeff Grigg. (2009, February 18). Arrange-Act-Assert. Retrieved May 1, 2012, from Cunningham & Cunningham, Inc.: http://c2.com/cgi/wiki?ArrangeActAssert

plan_de_calidad_scrum_handler (1).docx

Documents