ANÁLISIS, DISEÑO Y CONSTRUCCIÓN DE UNA APLICACIÓN EMPRESARIAL QUE CALCULE AUTOMÁTICAMENTE EL INDICADOR DE
DENSIDAD DE DEFECTOS (DDE) EN PRODUCTOS DE SOFTWARE.
DIEGO ARMANDO VIRGUEZ CASTAÑEDA
Trabajo de pasantía para optar el título de ingeniero de sistemas
P.h.D
Carlos Enrique Montenegro Marin
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS BOGOTA
CONTENIDO
1. INTRODUCCIÓN ... 9
2. PLANTAMIENTO DEL PROBLEMA ... 11
3. OBJETIVOS ... 13
5.2. INDICADOR DE DENSIDAD DE DEFECTOS (DDE) ... 15
5.2.1. Unidades de medición ... 16
5.3.1.3. Especificación ... 18
5.3.1.4. Validación ... 19
5.3.2. FASE DE DISEÑO ... 19
5.3.3. FASE DE CONSTRUCCIÓN ... 20
5.3.4. FASE DE PRUEBAS ... 20
5.4. APLICACIÓN EMPRESARIAL ... 20
6. MARCO TEÓRICO ... 22
6.1.1. Medidas derivadas ... 22
7. ESTADO DEL ARTE ... 24
7.2. PSM Insight ... 25
7.2.1. Creación personalizada de medidas e indicadores ... 27
8. ALCANCES Y LIMITACIONES ... 30
8.1. ALCANCES ... 30
8.1.1. Alcance del producto ... 30
8.2. LIMITACIONES ... 31
8.2.1. Limitaciones tecnológicas ... 31
8.2.2. Limitaciones de tiempo ... 31
8.2.3. Limitaciones de información ... 31
9. METODOLOGÍA ... 33
11.1. ANÁLISIS DE REQUERIMIENTOS ... 46
11.1.1. Características del producto ... 46
11.1.2. Usuarios del sistema y sus características ... 46
11.1.3. Documentación de usuario ... 47
11.1.4. Características del sistema ... 47
11.1.5. Diagrama de flujo de los requerimientos ... 51
11.2. FASE DE DISEÑO ... 57
11.2.1. Modelo entidad relación ... 57
11.2.2. Diseño de la interfaz de usuario ... 60
11.2.3. Diseño de la navegación de los usuarios ... 70
11.2.4. Diseño de los diagramas de actividades ... 71
13.2.4.1 Autenticar usuario ... 71
13.2.4.2 Generar Indicador ... 72
13.2.4.4 Modificar Indicador ... 75
11.2.5. Diseño del diagrama de clases ... 76
11.2.6. Descripción de los paquetes ... 78
13.2.6.1 Paquete presentación ... 78
13.2.6.2 Paquete de negocio ... 80
13.2.6.3 Paquete de integración ... 83
11.2.7. Modelo de tablas ... 85
11.2.8. Estrategia de implementación ... 85
11.2.9. Despliegue del producto ... 86
11.3. CONSTRUCCIÓN ... 88
11.4. PRUEBAS ... 88
11.4.1. Pruebas funcionales ... 88
11.4.2. Pruebas de aceptación ... 102
11.5. VALIDACIÓN: PROCESO MANUAL VS PROCESO CON EL SOFTWARE ... 110
11.5.1. Generación del indicador DDE de forma manual ... 111
11.5.2. Generación del indicador DDE con el software ... 112
12. ANÁLISIS DE RESULTADOS ... 115
12.4. LECCIONES APRENDIDAS ... 115
12.5. CONCLUSIONES ... 116
12.6. RECOMENDACIONES ... 117
11.4.3. A la universidad ... 117
11.4.4. A la compañía ... 118
13. BIBLIOGRAFÍA ... 119
ÍNDICE DE FIGURAS
Figura 1. Formado de ingreso de defectos. ... 11
Figura 2. Indicador como métrica o combinación de métricas. ... 15
Figura 3. Metodología de trabajo. ... 18
Figura 4. Herramienta SONARQUBE- Ámbitos de evaluación. ... 24
Figura 5. Resultado de evaluación en la herramienta SonarQube. ... 25
Figura 6. PSM Insight-Ventana principal. ... 26
Figura 7. Indicador PSM Insight. ... 27
Figura 8. Fases del ciclo de vida. ... 33
Figura 9. Actividades en la fase de análisis. ... 34
Figura 10. Actividades en la fase de análisis. ... 35
Figura 11. Actividades en la fase de diseño ... 37
Figura 12. Actividades en la fase de diseño. ... 38
Figura 13. Actividades en la fase de construcción ... 39
Figura 14. Actividades en la fase de construcción. ... 40
Figura 15. Actividades en la fase de pruebas. ... 41
Figura 16. Cronograma fase de análisis. ... 42
Figura 17. Cronograma fase de diseño. ... 43
Figura 18. Cronograma fase de construcción. ... 44
Figura 19. Cronograma fase de construcción. ... 45
Figura 20. Diagrama de flujo del requerimiento “Autenticar Usuario” ... 51
Figura 21. Diagrama de flujo del requerimiento “Generar indicador”. ... 52
Figura 22. Diagrama de flujo del requerimiento “Adicionar análisis”. ... 53
Figura 23. Diagrama de flujo del requerimiento “Modificar análisis”. ... 54
Figura 24. Diagrama de flujo del requerimiento “Adicionar plan de acción”. ... 55
Figura 25. Diagrama de flujo del requerimiento “Modificar análisis”. ... 56
Figura 26. Modelo entidad-relación. ... 57
Figura 27. Pantalla de inicio de sesión. ... 61
Figura 28. Pantalla de inicio. ... 62
Figura 29. Pantalla de consultar indicador. ... 63
Figura 30. Pantalla de generar indicador. ... 64
Figura 31. Pantalla información del proyecto... 65
Figura 32. Pantalla de inicio otros usuarios. ... 66
Figura 33. Pantalla de resultado del indicador... 67
Figura 34. Pantalla de resultado del indicador otros usuarios. ... 68
Figura 35. Pantalla de consulta otros usuarios. ... 69
Figura 37. Navegación entre pantallas de usuarios no directores. ... 71
Figura 38. Diagrama de actividad autenticar usuario. ... 72
Figura 39. Diagrama de actividad generar indicador. ... 73
Figura 40. Diagrama de actividad consultar histórico. ... 74
Figura 41. Diagrama de actividad modificar indicador. ... 75
Figura 42. Diagrama de clases. ... 77
Figura 43. Estrategia de implementación. ... 86
Figura 44. Modelo de tablas ... 87
Figura 45. Pantalla de inicio del aplicativo. ... 89
Figura 46. Pantalla de validación de credenciales del aplicativo. ... 89
Figura 47. Pantalla de validación de credenciales del aplicativo. ... 90
Figura 48. Pantalla de validación de credenciales del aplicativo. ... 90
Figura 49. Pantalla de validación de credenciales del aplicativo. ... 91
Figura 50. Pantalla de resultado después de forzar el aplicativo... 91
Figura 51. Error al forzar la navegación de la aplicación. ... 92
Figura 52. Error de ejecución. ... 92
Figura 53. Pantalla de consultar indicador. ... 93
Figura 54. Error de ejecución. ... 93
Figura 55. Pantalla de consultar indicador. ... 94
Figura 56. Gráficas de la generación del indicador. ... 94
Figura 57. Pantalla de consultar indicador. ... 95
Figura 58. Pantalla de consultar indicador. ... 95
Figura 59. Pantalla de consultar indicador. ... 96
Figura 60. Gráficas del resultado del indicador. ... 96
Figura 61 Área de texto para adicionar el análisis. ... 97
Figura 62. Pantalla de información del proyecto. ... 97
Figura 63. Resultado del indicador. ... 98
Figura 64. Error de base de datos. ... 98
Figura 65. Ingreso del análisis. ... 99
Figura 66. Ingreso del análisis con 2000 caracteres. ... 99
Figura 67. Modificación análisis. ... 100
Figura 68. Modificación análisis con 2000 caracteres. ... 100
Figura 69. Interfaz gráfica plan de acción. ... 101
Figura 70. Interfaz gráfica plan de acción. ... 101
Figura 71 Mensaje de error plan de acción. ... 102
Figura 72. Pantalla de inicio. ... 102
Figura 73.Pantalla de inicio. ... 103
Figura 74. Pantalla de inicio. ... 103
Figura 76. Ingreso de defectos y puntos funcionales. ... 104
Figura 77. Validación de los defectos ingresados. ... 105
Figura 78. Gráfica de la densidad de defectos. ... 106
Figura 79. Gráfica defectos inyectados y removidos. ... 106
Figura 80. Área de texto para la adición del análisis. ... 107
Figura 81. Validación ingreso análisis. ... 107
Figura 82. Modificar análisis. ... 108
Figura 83. Botón de guardado. ... 108
Figura 84. Interfaz gráfica para adicionar plan de acción. ... 109
Figura 85. Mensaje por campos vacíos en el plan de acción. ... 109
Figura 86. Interfaz gráfica de consultar histórico. ... 110
Figura 87. Resultado de la densidad de defectos. ... 111
Figura 88. Resultado de la densidad de defectos para la fase de requerimientos. ... 113
9
1. INTRODUCCIÓN
El software hace a una empresa más competitiva, automatizando parte de los procesos internos de esta. Por tanto, es necesario conocer bien el proceso que se quiera automatizar, para que el sistema que se quiere desarrollar en verdad cumpla con las necesidades de la empresa.
En el proceso de aseguramiento de la calidad de los productos de software que son desarrollados en Asesoftware, se usan distintos indicadores que sirven como métricas, que permitan la toma de decisiones y acciones, por parte de la dirección de la empresa. Entre estos indicadores se encuentran EDEF (estado de los defectos), DDE (densidad de defectos), entre otros. El presente documento, pretende abarcar el desarrollo de una aplicación empresarial para la generación del indicador de densidad de defectos, teniendo en cuenta, las fases de análisis, diseño y construcción (DDE), ya que Asesoftware no cuenta con un aplicativo que facilite el cálculo del indicador DDE, provocando que este sea calculado de forma manual. El cálculo de forma manual del indicador DDE genera los siguientes inconvenientes:
Adición de esfuerzo en horas de trabajo.
Expone a que se provoque un error humano, pues es necesario digitar los defectos encontrados en cada una de las fases, siendo este un proceso largo y tedioso por la cantidad de datos.
Como la generación del indicador DDE en general es una tarea del director de proyecto, los resultados no son visibles para todo el que los desee consultar, si no que se quedan en las manos de los directores y en la de sus superiores.
Usando la metodología en cascada, se pretende automatizar el cálculo del indicador de densidad de defectos (DDE) en productos de software, que se desarrollan en Asesoftware, teniendo en cuenta las fases de análisis, diseño y construcción, con el propósito de:
Reducir el esfuerzo en horas de trabajo en el cálculo del indicador DDE
Evitar errores humanos que se puedan cometer en la digitación de los datos por ser esta una tarea larga y tediosa.
Habilitar los resultados del indicador a los interesados.
10
El indicador de densidad de defectos (DDE), tiene como objetivo evaluar la calidad de los productos de software, por medio de los defectos reportados, teniendo en cuenta un periodo de tiempo, que en la compañía es de 15 días.
El indicador de densidad de defectos es usado por los directores de proyecto de la compañía. La principal fuente de datos que utiliza el indicador DDE son los defectos estimados y reportados a lo largo de las fases de análisis, diseño y construcción. También como fuente de datos, se usan los puntos funcionales del proyecto. Los directores de proyecto deben analizar los resultados del indicador. Hay dos gráficas que se utilizan para analizar el indicador, que son: la densidad de defectos en la etapa de análisis, diseño y construcción, y la gráfica de defectos encontrados con respecto a los defectos estimados.
11
2. PLANTAMIENTO DEL PROBLEMA
Dada la necesidad de la calidad en los productos de software, Asesoftware tiene a disposición el indicador de densidad de defectos (DDE). Los funcionarios de la compañía que utilizan el indicador DDE son los directores de proyecto. Los directores de proyecto manifiestan que no es eficaz ni eficiente generar el indicador como se ha hecho convencionalmente, por las siguientes razones:
Hay riesgo de que la información traída de la base de datos se digite mal por un error humano, dado que, esta información se digita en un documento de Microsoft Excel como se muestra en la figura 1.
La cantidad de esfuerzo y tiempo que gasta un director de proyectos manejando la información, es decir, copiando los datos y pegándolos en el archivo de Excel, es considerable, pudiendo gastar este tiempo en otras actividades, como en el análisis del proyecto o en la propuesta de un plan de acción.
Si los directores de proyecto quieren ver representado el indicador en forma gráfica, también deben hacerlo manualmente por medio de Microsoft Excel.
La información es de difícil acceso para quienes no sean directores de proyecto o no pertenezcan al área de dirección de la compañía. Se tendría que hacer una solicitud para conocer la información.
Figura 1. Formado de ingreso de defectos.
12
13
3. OBJETIVOS
3.1. GENERAL
Desarrollar una aplicación empresarial, que calcule automáticamente el indicador de densidad de defectos (DDE) en productos de software, desarrollados en Asesoftware, aplicando las fases del ciclo de vida en cascada.
3.2. ESPECÍFICOS
Analizar el sistema, de tal forma que se identifiquen los requerimientos del aplicativo a desarrollar, considerando los requerimientos propuestos por el cliente, y los requerimientos dilucidados y extraídos por el autor, dada la importancia de los requerimientos para la entrega exitosa del producto final.
Diseñar el aplicativo, haciendo uso del lenguaje de modelado UML, la notación CASE METHOD, y Mockups para la interfaz gráfica de usuario, buscando que el aplicativo sea de fácil uso para el usuario final, y que cumpla con los requerimientos identificados.
Construir la aplicación, asegurando que se satisfagan los requerimientos establecidos en la fase de análisis de requerimientos y los diseños establecidos en la fase de diseño.
14
4. JUSTIFICACIÓN
El software se ha vuelto indispensable en la actualidad, tanto así, que en el mundo industrializado, la mayoría de las personas se han visto relacionadas con el software directa o indirectamente. Pero no se puede hablar solo de las personas, también de las organizaciones, esos sistemas complejos que buscan el autoaprendizaje y la mejora de sus procesos constantemente, buscando así una ventaja competitiva, sistematizando el manejo de la información y distribuyendo el producto más importante de nuestro tiempo, la información (Pressman, 2010).
La cantidad tan grande de información generada por una organización puede llegar a ser muy tediosa si se quiere analizar manualmente, si se quiere enviar a algún cliente o si se quiere buscar algún registro de muchos años atrás. Por este motivo el software ha invadido las organizaciones, viéndose obligadas a acoger la ingeniería de software, ya que el software permite construir sistemas complejos en un tiempo razonable y con alta calidad, satisfaciendo así, las necesidades de la organización (Pressman, 2010).
La importancia del software ha sido tan grande que es difícil encontrar una organización que no use software en alguno de sus procesos internos o que no use software para ofrecer sus servicios, tanto así, que el software se ha convertido en una tecnología indispensable en los negocios (Pressman, 2010).
Actualmente encontramos organizaciones tan dependientes del software, que si este llega a fallar, la organización puede llegar a perder millones de pesos en pocas horas.
Por todo lo anterior, a las organizaciones les conviene sistematizar sus procesos, resolviendo así necesidades de negocio, facilitando la toma de decisiones por parte del departamento administrativo, y permitiendo que esta información esté disponible para un mayor número de personas. Con el desarrollo de la presente pasantía, se busca sistematizar el indicador de densidad de defectos DDE, que es parte fundamental del proceso de aseguramiento de la calidad, en los productos de software que son desarrollados en Asesoftware.
Con la sistematización del indicador a través de una aplicación empresarial, se busca reducir el tiempo del cálculo del indicador DDE, dando como resultado, la reducción de costes para la compañía, teniendo en cuenta el concepto de triple restricción (PMBOK).
15
5. MARCO CONCEPTUAL
A continuación se presentarán los conceptos relevantes que tienen relación con el indicador de densidad de defectos DDE. Téngase en cuenta que cuando se menciona por fase, se refiere a las fases del modelo de ciclo de vida en cascada: análisis, diseño y construcción.
5.1. INDICADOR Y METRICAS
En el contexto de la ingeniería del software, una medida proporciona un indicio cuantitativo de la extensión, cantidad, dimensión, capacidad o tamaño de algún atributo de un producto o proceso. La medición es el acto de determinar una medida. El IEEE Standard Glosary of Software Engineering Terminology define métrica como una medida cuantitativa del grado en el que un sistema, componente o proceso posee un atributo determinado. Una métrica de software relaciona en alguna forma las medidas individuales (Pressman, 2010).
Un indicador es una métrica o combinación de métricas que proporcionan compresión acerca del proceso de software, el proyecto de software o el producto en sí. Un indicador proporciona compresión que permite al gerente de proyecto o a los ingenieros de software ajustar el proceso, el proyecto o el producto para hacer mejor las cosas (Pressman, 2010).
Figura 2. Indicador como métrica o combinación de métricas.
Muestra que un indicador puede estar compuesto por una o varias métricas. Fuente: Tomada de (Pereira, Ayaach, Quintero, Granadillo, & Bustamante, s. f.).
5.2. INDICADOR DE DENSIDAD DE DEFECTOS (DDE)
El indicador DDE tiene como objetivo evaluar la calidad de los productos de software, por medio de los defectos reportados, teniendo en cuenta un periodo de
Indicador
Métrica
16
tiempo, con el fin de tomar acciones correctivas tendientes a reducir los costos de retrabajo (Asesoftware, 2015).
5.2.1. Unidades de medición
Las unidades de medición que usa el indicador DDE son: el número de defectos por fase y los puntos funcionales.
5.2.2. Entidades
Estimación de defectos: Se estiman los defectos inyectados y removidos en el producto de software, teniendo en cuenta las fases de requerimientos, diseño y construcción. Esta estimación es responsabilidad de los directores de proyecto, pues ellos los ingresarán al aplicativo.
Reporte de defectos: los defectos son reportados por medio de la aplicación Microsoft Team Foundation Server (TFS). EN TFS se pueden reportan los defectos, teniendo en cuenta una clasificación. Esta clasificación puede ser por tipo o por severidad (Asesoftware, 2015). Los defectos que se encuentren en la base de datos de TFS, serán los defectos que usará el aplicativo para generar el indicador de densidad de defectos.
Tamaño del producto: El tamaño del producto se mide por puntos funcionales. Los puntos funcionales son una métrica usada en la ingeniería de software para medir el tamaño del software (Meneses, s. f.). Los puntos funcionales serán responsabilidad del director de proyecto, pues ellos los ingresarán al aplicativo.
5.2.3. Medidas base
En las medidas base se tiene en cuenta los siguientes conceptos:
Defecto: es importante aclarar que en este contexto la palabra defecto es el resultado de un fallo o deficiencia, durante el proceso de creación del software, es decir, antes de ser entregado al cliente.
Defecto trivial: clasificación que usa Asesoftware con respecto a la severidad del defecto. Puede ser un defecto cosmético o menor.
Defecto no trivial: clasificación que usa Asesoftware con respecto a la severidad del defecto. Puede ser un defecto mayor o crítico.
17
Número de defectos triviales encontrados en requerimientos.
Número de defectos triviales encontrados en diseño.
Número de defectos triviales encontrados en construcción.
Número de defectos no triviales encontrados en requerimientos.
Número de defectos no triviales encontrados en diseño.
Número de defectos no triviales encontrados en construcción.
Puntos funcionales del proyecto.
Límite de especificación: Es la densidad de defectos esperada para una fase (Asesoftware, 2015).
5.2.4. Modelo de análisis
El indicador DDE se puede analizar por medio de gráficas. La densidad de defectos se grafica por fase del modelo de estimación (requerimientos, diseño y construcción). Es importante tener en cuenta que la densidad de defectos depende de la fase (no es constante), siendo mayor el número en la fase de construcción. También se puede graficar el desfase específico del proceso. Esto quiere decir la comparación entre el número de defectos estimados removidos y el número real de defectos removidos (Asesoftware, 2015).
5.2.5. Recolección de datos
Frecuencia de recolección: Para el indicador DDE, la estimación de los defectos inyectados por fase, la estimación de los defectos removidos por fase, y los puntos funcionales, se hacen al iniciar el proyecto. Los defectos triviales y no triviales de las tres fases, se recolectan hasta el final del proyecto.
Repositorio para los datos recolectados: Datamart de métricas de Asesoftware (Asesoftware, 2015).
5.3. METODOLOGÍA
18 Figura 3. Metodología de trabajo.
Muestra la metodología de trabajo usada en la presente pasantía. Fuente: Tomada de (Asesoftware, 2014).
5.3.1. FASE DE ANÁLISIS
La fase de análisis se divide en cuatro fases, que son: la extracción, el análisis, la especificación y la validación (E. Gómez, 2011).
5.3.1.1. Extracción: La fase de análisis, tiene como principal objetivo, la dilucidación de los requerimientos. Los analistas se sientan con el cliente, para poder determinar las funcionalidades del software, y las necesidades del negocio. Es importante decidir, las técnicas de obtención de requerimientos que se van a usar, identificar personas que tengan experiencia en el negocio, en lo posible varias, para entrevistarlas. Entre más puntos de vista se obtengan, mayor será la información útil que los analistas podrán obtener. Para la presente pasantía, los requerimientos se obtendrán a partir de entrevistas hechas a los directores de proyecto y a los directores de calidad (E. Gómez, 2011).
5.3.1.2. Análisis: En esta actividad, ya se deben tener unos requerimientos base. Estos requerimientos se deben agrupar en subconjuntos, para poder analizarlos, de tal forma que sean consistentes y no sean ambiguos. Es necesario resolver cuestiones como:
Requerimientos consistentes con los objetivos del negocio.
Requerimientos con un nivel alto de abstracción.
Requerimientos esenciales para el negocio.
Requerimientos que no sean ambiguos.
Requerimientos que se puedan probar en implementación.
Se debe hacer negociación con el cliente, para acordar los requerimientos esenciales del negocio, y no sobrepasar los límites del ingeniero (E. Gómez, 2011).
5.3.1.3. Especificación: En esta actividad, se debe documentar todos los requerimientos encontrados en la actividad de análisis a un nivel alto de detalle. La documentación permite:
Tener documentación como soporte con el cliente.
Reducir los esfuerzos de desarrollo.
19
Provee una base para la estimación de costos y para la estimación del cronograma.
En la presente pasantía, se realizará un documento de requerimientos donde se especificarán detalladamente los requerimientos del aplicativo. Este documento, se utilizará en las posteriores fases de la pasantía (E. Gómez, 2011).
5.3.1.4. Validación: En esta fase, se hace una validación de los requerimientos finales. Los requerimientos son validados con el cliente, por este motivo, puede llegar a descubrirse problemas que antes no se habían descubierto Sirven como punto de control, tanto interna como externamente. Internamente, para verificar que si se está haciendo lo correcto, externamente, con el cliente. También se verifica que los requerimientos sean claros, tengan el nivel de detalle apropiado, y sean consistentes.
En Asesoftware, el documento de requerimientos será validado por el departamento de calidad, verificando que cumpla con el formato previsto, para la especificación de los requerimientos. También se verifica, que el documento no sea ambiguo, y que los requerimientos sea claros para la lectura por parte del usuario (E. Gómez, 2011).
5.3.2. FASE DE DISEÑO
En esta fase, según (Marín, 2012) se busca representar al sistema, con una serie de modelos, que estén acordes con los requerimientos encontrados en la fase anterior. Estos modelos se pueden dividir en subsistemas que pueden entenderse e implementarse individualmente. Las actividades que se desarrollan son:
Definir la arquitectura del sistema teniendo en cuenta los atributos de calidad. Los atributos de calidad son los requerimientos no funciones, como disponibilidad, escalabilidad, etc. La arquitectura será una responsabilidad del arquitecto de software. El documento de arquitectura será entregado al analista de software como base para la escritura del documento de diseño.
Diseñar el modelo entidad-relación, para poder modelar las tablas que serán implementadas en el motor de base de datos.
Especificar el mecanismo de comunicación con interfaces externas en caso de que existan. Por ejemplo una base de datos externa donde se necesiten hacer consultas. Se usarán vistas y consultas para obtener información de bases de datos externas.
Se modelará el diagrama de clases teniendo en cuenta las tres capas (presentación, negocio e integración). Por otro lado, se modelara el diagrama de clases de las entidades con base al modelo entidad-relación.
20
El documento de diseño será validado por el arquitecto de software encargado (Marín, 2012).
5.3.3. FASE DE CONSTRUCCIÓN
En la fase de construcción, teniendo en cuenta a (Marín, 2012), se toman los modelos realizados en la fase de diseño, el manual técnico y el manual de usuario. Se siguen los siguientes pasos:
Configurar el ambiente de desarrollo, esto quiere decir, configurar e instalar las herramientas que se usarán en el desarrollo.
Se codificará cada uno de los subsistemas.
Se deben integrar los diferentes subsistemas y ejecutarlos.
Documentar el producto (manual técnico y manual de usuario) (Marín, 2012).
5.3.4. FASE DE PRUEBAS
Según (D. Gómez, 2014), la fase de pruebas consiste en validar el sistema en un ambiente de producción, para obtener la validación del cliente. Su objetivo principal es llevar el software desarrollado y probado en un ambiente real. Básicamente se diseñan dos tipos de casos de pruebas, los casos de prueba de unidad e integración (caja blanca) y los casos de prueba funcionales (caja negra).
Los diseños de caso de prueban se valen de métodos como la tabla de decisiones o la transición de estados (D. Gómez, 2014).
5.4. APLICACIÓN EMPRESARIAL
Son aplicaciones multicapa, escalables, confiables, y seguras. Son llamadas así, pues están diseñadas para resolver los problemas encontrados por las grandes empresas. No están diseñadas solo para grandes corporaciones, pues los beneficios de una aplicación empresarial son útiles, incluso esenciales, para los desarrolladores individuales y pequeñas organizaciones en un mundo cada vez más interconectado. La seguridad y la fiabilidad hacen que la complejidad de estas aplicaciones aumente, haciendo uso frecuente de tecnologías como Java Platform, Enterprise Edition (Oracle, 2012).
Las aplicaciones empresariales, cuentan con las siguientes características que las diferencias de otras:
Involucran datos persistentes.
Cuentan con grandes volúmenes de información.
El acceso a dichos datos es concurrente.
21
Implementan reglas propias del negocio.
22
6. MARCO TEÓRICO
A continuación se mencionan las medidas derivadas, que son ecuaciones importantes para la generación del indicador de densidad de defectos (DDE). Estas ecuaciones, se toman del artefacto densidad de defectos, de uso interno de la compañía.
6.1.1. Medidas derivadas
Estos son las ecuaciones para calcular la generación del indicador DDE. A continuación se hace una breve explicación de ellas.
%𝐼𝑁 = 𝑁𝑇𝐹 𝐸𝐼𝐹
( 1)
La ecuación número uno, se calcula el porcentaje de defectos inyectados (%IN), que es igual al número de defectos no triviales por fase (NTF), divididos por la estimación de los defectos inyectados por fase (EIF) (Asesoftware, 2015).
%𝑅𝐸 = 𝑁𝑇𝐹 𝐸𝑅𝐹
( 2)
En la ecuación número dos, se calcula el porcentaje de defectos removidos (%RE), que es igual al número de defectos no triviales por fase (NTF), divididos por la estimación de los defectos removidos por fase (ERF) (Asesoftware, 2015).
𝑅𝐸𝑆𝑁𝑇 = 𝐸𝐼𝐹 − 𝑁𝑇𝐹 ( 3)
23
𝐷𝐷𝐸 = ( 𝑁𝑇𝐹
𝑁𝑈𝑀𝐹𝑃) ∗ 100
( 4)
24 orientadas al análisis de código, en tiempo de ejecución (Sánchez, 2009). Así que, se tendrá en cuenta la herramienta de análisis de la calidad del código, SonarQube, y la herramienta PSM Insight, un software libre que automatiza el proceso práctico de medición de software (PSM, s. f.).
7.1. SONARQUBE
Es una plataforma de código abierto, que gestiona la calidad del código. Abarca siete “ejes” de calidad del código que, el autor puede apreciar en la figura 4:
Figura 4. Herramienta SONARQUBE- Ámbitos de evaluación.
Muestra los ámbitos de evaluación para la calidad del software usados por SONARQUBE. Fuente: Tomada de (SONARQUBE, 2015).
En la figura 5, se puede observar la evaluación concreta del proyecto JFreeChart, en el cual se comprueba que hay alertas de duplicación de código. También se puede observar, los comentarios y la complejidad del programa. Estos parámetros pueden ser personalizados por el usuario (Sánchez, 2009).
25
Figura 5. Resultado de evaluación en la herramienta SonarQube.
Muestra los resultados de una evaluación de calidad del código en SONARQUBE.
Fuente: Tomada de http://www.sonarsource.com/wp-content/uploads/2012/03/project-dashboard1.png.
7.2. PSM Insight
26 Figura 6. PSM Insight-Ventana principal.
Muestra la ventana de inicio del software PSM-Insight. Fuente: Tomada de (PSM, s. f.).
En la figura 6, se puede observar la ventana principal del programa. Esta ventana contiene tres contenedores principales, que son: Select, Tailor y Apply. Cabe resaltar que:
En el contenedor Select, se puede crear un proyecto como primer paso, dando clic en Projects.
El contenedor Tailor contiene las funciones primarias.
27 Figura 7. Indicador PSM Insight.
Muestra la ventana del programa PSM Insight para generar un indicador. Fuente: Tomada de (PSM, s. f.).
En la figura 7, se puede observar la ventana referente al indicador. Permite generar tres tipos de gráficas: Trend, Snapshot e Histrogram.
7.2.1. Creación personalizada de medidas e indicadores
Para la creación personalizada de medidas, se tienen en cuenta tres características: estructura, atributos y datos. La estructura define como se van a recolectar los datos. Los atributos y datos tendrán en cuenta la información que va a manejar la medida.
Para la creación de indicadores, se selecciona la medida que se va a trabajar y el tipo de gráfica que se desea usar. En la gráfica, se puede personalizar la descripción, los ejes, el título, y si se quiere, incluir anotaciones y comentarios (PSM, s. f.).
28
Tabla 1. Comparación entre las características de SonarQube y PSM Insight
Herramienta Características
SonarQube Esta herramienta, aunque tiene en cuenta elementos de la calidad de software importantes, como la complejidad en los programas, no tiene en cuenta las diferentes fases del modelo de ciclo de vida que se dan en los proyectos de software.
La herramienta está más orientada a los desarrolladores que a los directores de proyecto, pues los desarrolladores son los que están directamente involucrados con el código. PSM Insight La importación de datos se debe hacer de forma manual, adicionando tiempo y esfuerzo.
Aunque se pueden hacer medidas personalizadas, el programa no permite calcular las métricas. Se deben importar los datos ya con los cálculos realizados.
Aunque la aplicación permite hacer medidas e indicadores personalizados, estos dependen de la importación manual de los datos.
Fuente: Elaboración propia.
El lector pudo observar que la primera herramienta está enfocada al análisis de código y a los desarrolladores. Asesoftware quiere que el aplicativo esté enfocado a la toma de decisiones por parte de los directores de proyecto. La segunda herramienta, está enfocada a la toma de decisiones, y al análisis de resultados, pero, se deben importar los datos manualmente con los cálculos del indicador ya realizados. Por otro lado, presenta una interfaz gráfica algo obsoleta. Precisamente, uno de los requerimientos de Asesoftware es que el director no tenga que gastar tiempo copiando los defectos de cada periodo.
29
30
8. ALCANCES Y LIMITACIONES
8.1. ALCANCES
Con respecto al alcance, se cumplirá con los entregables exigidos por Asesoftware, para el desarrollo de la pasantía, que son: un documento de requerimientos, un documento de diseño y el desarrollo del aplicativo, con el manual técnico y el manual de usuario. Estos entregables cumplirán lo especificado en el cronograma.
No se incluirá entregables distintos a los arriba mencionados. El control y seguimiento de la pasantía, se hará teniendo en cuenta las fechas planteadas en el cronograma de actividades, con apoyo del arquitecto de software, y del director de proyecto. El arquitecto de software, apoyará la parte técnica y tecnológica, y el director de proyecto, facilitará la comunicación con el cliente, y estará pendiente, para que las fechas se cumplan como fueron establecidas.
8.1.1. Alcance del producto
A nivel de producto, se busca, por medio de una aplicación empresarial, generar el indicador de densidad de defectos por etapa (DDE). Cuando se habla de la generación del indicador, se refiere a los cálculos que se deben hacer propios del indicador, al análisis y al plan de acción que debe registrar el director de proyecto. Solo los usuarios que se encuentren registrados, y que cumplan con el rol de director de proyecto, podrán generar el indicador. En la tabla 2, se muestra los requerimientos generales que se tendrán en cuenta en el alcance.
Tabla 2. Requerimientos generales del alcance.
Nombre Descripción
Validar credenciales
El sistema permitirá al usuario acceder al sistema utilizando el usuario y contraseña.
Generar indicador El sistema permitirá calcular la densidad de defecto por etapa (DDE), junto con las medidas base y el límite de especificación. También mostrará gráficas de los resultados obtenidos.
31
Nombre Descripción
Adicionar plan de acción
Los directores de proyecto podrán escribir un plan de acción teniendo en cuenta los resultados del indicador Consultar histórico El sistema permitirá consultar indicadores generados
en periodos anteriores.
Fuente: Elaboración propia.
No se incluye previo registro de usuarios, pues se obtendrán de la base de datos externa de Ares 2. Ares 2 es un aplicativo de uso interno de la compañía.
No se incluye modificación de datos con respecto a los perfiles de los usuarios.
Los datos de los defectos y los usuarios provendrán de la base de datos de Ares 2. Estos datos no podrán ser modificados ni eliminados.
El análisis que hace el director de proyecto, teniendo en cuenta los resultados generados por el indicador, podrá ser modificable.
El plan de acción no podrá ser modificable una vez haya sido guardado.
8.2. LIMITACIONES
Este apartado, abarca limitaciones a tener en cuenta en la presente pasantía.
8.2.1. Limitaciones tecnológicas
Las siguientes tecnologías se emplearon en la pasantía, por requerimiento del cliente:
La tecnología que se usará será Java Enterprise Edition 7.
La base de datos será Oracle versión 11g.
La interfaz gráfica deberá ser construida en PrimeFaces versión 2.
8.2.2. Limitaciones de tiempo
La presente pasantía está limitada al tiempo que se presenta en el cronograma. Si por algún motivo se presenta un atraso en las actividades, el tiempo no puede ser mayor a los seis meses, pues así lo estipulo la oficina de pasantías.
8.2.3. Limitaciones de información
32
análisis, diseño y construcción de cada proyecto en particular. También contiene la información del recurso humano de la empresa. Esta información es necesaria al momento de iniciar sesión en la aplicación. Solo los usuarios con rol de director de proyecto pueden acceder a la aplicación.
33
9. METODOLOGÍA
En este apartado, se pretende describir la aplicación de la metodología, en la pasantía.
Figura 8. Fases del ciclo de vida.
Muestra las fases que se ejecutarán en la presente pasantía. Fuente: Elaboración propia.
Como se muestra en la figura 8, la pasantía abordará las fases de análisis, de diseño, de construcción y de pruebas. Son cinco entregables principales, exigidos por Asesoftware, que son:
El documento de requerimientos (Ver Anexo A en https://drive.google.com/driv e/folders/0B7YZBV85D2MrejJCdzF4QjVqOWc -CO_358_DDE_ESP_RSF.pdf).
El documento de diseño “CO_358_DDE_DOC_DIS” (Ver Anexo B en https://drive.google.com/drive/folders/0B7YZBV85D2MrUXk1ZVBJODJ4WmM - CO_358_DDE _DOC_DIS.pdf).
El código fuente de la aplicación (Ver Anexo E en https://drive.google.com/drive /folders/0B7YZBV85D2Mrd1ZZWTEzb0txREk - DDE.rar).
El manual técnico (Ver Anexo D en https://drive.google.com/drive/folders/0B7Y ZBV85D2MrekVyNUNEeEdwZnM - CO_358_DDE_MNL_TEC.pdf).
El manual de usuario (Ver Anexo C en https://drive.google.com/drive/folders/0B 7YZBV85D2MrV3B4U2RyMHEzTFE- CO_358_DDE_MNL_USU.pdf).
A continuación se hace una descripción más detallada, de cada fase del ciclo de vida.
9.1. FASE DE ANÁLISIS
34
El entregable exigido por la compañía, es un documento, con nombre “CO_358_ESP_RSG”. (Ver Anexo A en https://drive.google.com/drive/folders/0B7 YZBV85D2MrejJCdzF4QjVqOWc -CO_358_DDE_ESP_RSF.pdf). La fase de análisis, tendrá cuatro actividades, que son: extracción de requerimientos, análisis de requerimientos, especificación de requerimientos y validación de requerimientos. El documento del entregable contendrá: las características del producto, los usuarios del sistema, los requerimientos en un nivel de detalle más específico y diagramas de flujo de los requerimientos.
Figura 9. Actividades en la fase de análisis.
Muestra las actividades a ejecutar en la fase de análisis. Fuente: Elaboración propia.
35
Estudiar el documento formal de las funcionalidades que espera la empresa cumpla el aplicativo empresarial. También, estudiar la documentación disponible en la empresa con respeto al indicador DDE.
Observar el procedimiento de generación del indicador que realizan los directores de proyecto en el documento de Excel, pues allí se encuentra el formato para realizarlo. Tener en cuenta entradas y salidas.
Realizar entrevistas a los directores de proyecto y al director de calidad con el fin de resolver dudas que no hayan quedado claras en los pasos anteriores. Una vez se tenga una lista de requerimientos, se hará un análisis de los requerimientos, teniendo en cuenta, que en verdad sean esenciales para cumplir con las reglas de negocio, que tengan una delimitación adecuada, y que no sean ambiguos.
Figura 10. Actividades en la fase de análisis.
36
Como se ve en la figura 10, para la especificación de los requerimientos, se pretende dejar por escrito los usuarios del sistema, las características del producto, los requerimientos a un nivel de detalle adecuado, descomponiéndolos en requerimientos más específicos, y realizar diagramas de flujo que muestren los procedimientos de los requerimientos.
Como se ve en la figura 10, la última actividad, es la validación de los requerimientos con el cliente. Esta validación, se hará de la siguiente manera:
Los requerimientos finales, se discutirán con el director de proyecto. El director de proyecto, decidirá si se debe hacer alguna adición o exclusión de los requerimientos presentados.
El documento “CO_358_ESP_RSG” (Ver Anexo A en https://drive.google.com/ drive/folders/0B7YZBV85D2MrejJCdzF4QjVqOWc - CO_358_DDE_ESP_RSF. pdf), antes de ser aprobado, será validado, por el área de calidad de compañía.
9.2. FASE DE DISEÑO
En la figura 11, y la figura 12, se especifica las actividades a realizar en la fase de diseño.
El entregable exigido por la compañía, es un documento, con nombre “CO_358_DDE_DOC_DIS” (Ver Anexo B en https://drive.google.com/drive/folders/ 0B7YZBV85D2MrUXk1ZVBJODJ4WmM - CO_358_DDE _DOC_DIS.pdf). La fase de diseño, tendrá cuatro actividades, que son: diseño de la interfaz de usuario, diseño de los modelos de datos, diseño de los diagramas de actividades de las funcionalidades, y diseño del diagrama de clases. El documento del entregable contendrá:
Diseño del modelo entidad-relación aplicando la metodología CASE*METHOD de Oracle.
Diseño de los prototipos de interfaz gráfica especificados en la figura 11.
Diseño de la navegación de los usuarios entre las pantallas.
37 Figura 11. Actividades en la fase de diseño
38 Figura 12. Actividades en la fase de diseño.
Muestra las actividades a ejecutar en la fase de diseño. Fuente: Elaboración propia.
Diseño de los diagramas de actividades de las funcionalidades, especificadas en la figura 12.
Diseño del diagrama de clases, que se dividirá en paquetes, en base al patrón modelo-vista-controlador. Es decir, habrá, un paquete de la vista, un paquete del modelo, y un paquete de los controladores. Ver la figura 12.
9.3. FASE DE CONSTRUCCIÓN
39
Una vez configurado el ambiente de desarrollo, se construirán los prototipos de las pantallas, mostrados en la figura 13.
Figura 13. Actividades en la fase de construcción
Muestra las actividades a ejecutar en la fase de construcción. Fuente: Elaboración propia.
40
Cuando el producto este codificado, se escribirá el manual técnico (Ver Anexo D en https://drive.google.com/drive/folders/0B7YZBV85D2MrekVyNUNEeEdwZnM - CO_358_DDE_MNL_TEC.pdf) y el manual de usuario (Ver Anexo C en https://drive.google.com/drive/folders/0B7YZBV85D2MrV3B4U2RyMHEzTFE- CO_358_DDE_MNL_USU.pdf). Estos dos documentos son entregables que exige la compañía.
Figura 14. Actividades en la fase de construcción.
Muestra las actividades a ejecutar en la fase de construcción. Fuente: Elaboración propia.
9.4. FASE DE PRUEBAS
41 Figura 15. Actividades en la fase de pruebas.
42
10. CRONOGRAMA
Figura 16. Cronograma fase de análisis.
Muestra el cronograma con las actividades respectivas a la fase de análisis. Fuente: Elaboración propia.
Nombre de tarea Duración Incio Fin
S
1. Fase de análisis 26 días 2/02/2015 9/03/2015
1.1 Documento de requerimientos 26 días 2/02/2015 10/02/205
1.1.1 Extracción de requerimientos 7 días 2/02/2015 10/02/2015
1.1.1.1 Estudio documentación 5 días 2/02/2015 6/02/2015
1.1.1.2 Observación del procedimiento 1 día 9/02/2015 9/02/2015
1.1.1.3 Realización de entrevistas 1 día 10/02/2015 10/02/2015
1.1.2. Análisis de requerimientos 4 días 11/02/2015 16/02/2015
1.1.2.1 Analizar la consistencia de los requerimietos 1 día 11/02/2015 11/02/2015 1.1.2.2 Analizar la esencialidad de los requerimientos 1 día 12/02/2015 12/02/2015
1.1.1.3 Estudio documentación 1 día 13/02/2015 13/02/2015
1.1.1.4 Observación del procedimiento 1 día 16/02/2015 16/02/2015
1.1.3. Especificación de requerimientos 12 días 17/02/2015 5/03/2015
1.1.3.1 Determinar las características del producto 2 días 17/02/2015 18/02/2015 1.1.3.2 Determinar los usuarios del sistema 1 día 19/02/2015 19/02/2015
1.1.3.3 Documentar los requerimientos 5 días 20/02/2015 26/02/2015
1.1.3.4 Realizar digramas de flujo 3 días 27/02/2015 5/03/2015
1.1.4 Validación de requerimientos 2 días 6/03/2015 9/03/2015
43 Figura 17. Cronograma fase de diseño.
Muestra el cronograma con las actividades respectivas a la fase de diseño. Fuente: Elaboración propia.
Nombre de tarea Duración Incio Fin
S
1. Fase de diseño 27 días 10/03/2015 6/04/2015
2.1 Documento de diseño 27 días 10/03/2015 6/04/2015 2.1.1 Diseño de la interfaz 9 días 10/03/2015 20/03/2015
2.1.1.1 Pantalla de generación del indicador 1 día 10/03/2015 10/03/2015 2.1.1.2 Pantalla de informacion del proyecto 1 día 11/03/2015 11/03/2015
2.1.1.3 Pantalla de resultados 1 día 12/03/2015 12/03/2015
2.1.1.4 Pantalla de inicio 1 día 13/03/2015 13/03/2015
2.1.1.5 Pantalla de inicio de sesión 1 día 16/03/2015 14/03/2015 2.1.1.6 Pantalla de inicio con usuario diferente a director 1 día 17/03/2015 15/03/2015 2.1.1.7 Pantalla consultar indicador con usuario diferente a director 1 día 18/03/2015 16/03/2015 2.1.1.8 Pantalla de resultado con usuario diferente director 1 día 19/03/2015 17/03/2015 2.1.1.9 Diseño navegación entre pantallas 1 día 20/03/2015 20/03/2015
2.1.2. Diseño de los modelos de datos 11 días 23/03/2015 6/04/2015
2.1.2.1 Diseño del modelo entidad relacion 8 días 23/03/2015 1/04/2015
2.1.2.2 Diseño del modelo de tablas 3 días 2/04/2015 6/04/2015
2.1.3. Diseño del diagrama de actividades de las funcionalidades 4 días 7/04/2015 10/04/2015
2.1.3.1 Diagrama de actividad de autenticar usuario 1 días 7/04/2015 7/04/2015 2.1.3.2 Diagrama de actividad de generar indicador 1 días 8/04/2015 8/04/2015 2.1.3.3 Diagrama de actividad de consultar histórico 1 días 9/04/2015 9/04/2015 2.1.3.4 Diagrama de actividad de modificar indicador 1 días 10/04/2015 10/04/2015
2.1.4. Diseño del diagrama de clases 3 días 13/04/2015 15/04/2015 2.1.4.1 Diseño paquete de la vista 1 días 13/04/2015 13/04/2015
2.1.4.2 Diseño paquete del modelo 1 días 14/04/2015 14/04/2015
44 Figura 18. Cronograma fase de construcción.
Muestra el cronograma con las actividades respectivas a la fase de construcción. Fuente: Elaboración propia.
Nombre de tarea Duración Incio Fin
S
3.1 Desarrollo de la aplicación 78 días 16/04/2015 3/08/2015
3.1.1 Configuración del ambiente de desarrollo 2 días
3.1.2 Construcción del front-end 20 días 17/04/2015 14/05/2015
3.1.2.1 Construcción de la pantalla de inicio de sesión 2 días 17/04/2015 20/04/2015 3.1.2.2 Construcción de la pantalla de generación del indicador 4 días 21/04/2015 24/04/2015 3.1.2.3 Construcción de la pantalla de información del indicador 2 días 27/04/2015 28/04/2015 3.1.2.4 Construcción de la pantalla de resultados 4 días 29/04/2015 4/05/2105 3.1.2.5 Construcción de la pantalla de consulta del indicador 2 días 5/05/2105 6/05/2105 3.1.2.6 Construcción de la pantalla de resultado del indicador con usuario
distinto a director 2 días 7/05/2105 8/05/2105 3.1.2.7 Construcción de la pantalla de consultar indicador con usuario distinto
a director 2 días 11/05/2105 12/05/2105 3.1.2.8 Construcción de la pantalla inicio con usuario distinto a director 2 días 13/05/2105 14/05/2105
3.1.3 Construcción back-end 38 días 14/05/2015 6/07/2015
3.1.3.1 Inicio de sesión 5 días 14/05/2015 20/05/2015 3.1.3.2 Generación del indicador 9 días 21/05/2015 02/062015 3.1.3.3 Adición y modificación del análisis 8 días 03/062015 12/06/2015 3.1.3.4 Adición plan de acción 8 días 15/06/2015 24/06/2015 3.1.3.5 Consultar histórico 8 días 25/062015 6/07/2015
3.1.4 Codificación del modelo de tablas 12 días 7/07/2015 22/07/2015
3.1.4.1 Creación de las tablas 5 días 7/07/2015 13/07/2015 3.1.4.2 Creación de consultas a las bases de datos externas 8 días 13/07/2015 22/07/2015
3.1.5 Documentación del desarrollo 8 días 23/07/2015 3/08/2015
45 Figura 19. Cronograma fase de construcción.
Muestra el cronograma con las actividades respectivas a la fase de construcción. Fuente: Elaboración propia.
Nombre de tarea Duración Incio Fin
S
4. Fase de pruebas 17 días 4/08/2015 26/08/2015 4.1 Pruebas de unidad 12 días 4/08/2015 19/08/2015
4.1.1 Análisis, diseño y ejecución de casos de pruebas 2 días 4/08/2015 5/08/2015 4.1.2 Reporte de defectos 2 días 6/08/2015 7/08/2015 4.1.3 Ejecución de correcciones 8 días 10/08/2015 19/08/2015
4.2 Pruebas de aceptación 5 días 20/08/2015 26/08/2015
46
11. DESARROLLO DE LA PASANTÍA
En este numeral, se presentan los resultados alcanzados. Como bien se mencionó en la metodología, se siguió el modelo de ciclo de vida en cascada para el desarrollo del aplicativo. Por tal motivo, a continuación se muestra cada fase siguiendo el orden de ese modelo, y también se describirá los resultados alcanzados a lo largo del desarrollo de la pasantía.
11.1. ANÁLISIS DE REQUERIMIENTOS
Después de aplicar la extracción de requerimientos y el análisis de requerimientos, se determinó lo siguiente:
11.1.1. Características del producto
El aplicativo tiene las siguientes características:
El empleado (director de proyecto), se deberá autenticar para poder ingresar al sistema.
El director de proyecto puede generar el indicador de densidad de defectos. Cuando se habla de la generación del indicador se refiere a los cálculos que se deben hacer propios del indicador.
El director de proyecto puede escribir el análisis pertinente después de revisar los resultados del indicador.
El director de proyecto puede escribir el plan de acción.
11.1.2. Usuarios del sistema y sus características
Director de proyecto: Es la persona encargada de generar el indicador de cada proyecto, y de hacer las observaciones necesarias sobre los mismos. Tendrá acceso permanente al sistema, y podrá adicionar y modificar datos.
Área de calidad: Son aquellos que realizan el seguimiento del estado del proyecto con respecto al indicador DDE. Pueden ver los datos generados, gráficas, análisis y planes de acción, pero no pueden ingresar ni modificar información.
47
poder tomar decisiones de alto nivel. Pueden ver los datos generados, gráficas, análisis y planes de acción, pero no pueden ingresar ni modificar información. 11.1.3. Documentación de usuario
La documentación de usuario es la siguiente:
Manual de usuario: entrega al empleado información sobre los módulos que integran el sistema, la interfaz y la forma de usarlo apropiadamente.
Manual técnico: se documenta la información técnica que posibilita el mantenimiento y modificación del sistema.
11.1.4. Características del sistema
Autenticar Empleado
El empleado accede al sistema utilizando un nombre de usuario y una contraseña. Los requerimientos funcionales son los siguientes:
48
Generar Indicador
El sistema permite al director de proyecto generar el indicador de densidad de defectos por etapa (DDE) quincenalmente para cada proyecto asignado, junto con el límite de especificación. También generará dos gráficas, una que muestra la densidad de defectos DDE del periodo actual y la densidad de defectos de periodo anterior (si existe), y la otra donde se muestra el total de defectos removidos por fase, los defectos estimados inyectados y los defectos estimados removidos, también por fase. El indicador podrá ser generado solo para el periodo actual. Los requerimientos funcionales son los siguientes:
GenerarIndicador.Generar .CalcularIndicador
El sistema calculará el indicador DDE, de acuerdo a la definición encontrada en el documento de referencia que se encuentra en la sección de métricas en la página interna de Asesoftware, teniendo en cuenta los defectos no triviales estimados (inyectados y removidos), y los puntos funcionales del proyecto, que son ingresados por el director de proyecto, mientras que los defectos triviales y no triviales encontrados se hallan el sistema Ares 2. Los defectos no triviales estimados y los puntos funcionales serán ingresados por el director de proyecto, los defectos encontrados serán tomados de las consultas sobre el proyecto. GenerarIndicador.Generar
.Ok
El sistema guarda la densidad de defectos por cada fase del proyecto. El sistema sobrescribe la información de la densidad de defectos, cada vez que el director de proyecto genere el indicador.
GenerarIndicador.Generar .NoOk
El sistema muestra un mensaje anunciando que el empleado no puede generar el indicador. Considérese alguna de las siguientes razones: - Se presenta un error por conexión a la base de datos.
49
Adicionar Análisis
El sistema permite al director de proyecto escribir el análisis con respecto al resultado del indicador de densidad de defectos (DDE). Los requerimientos funcionales son los siguientes:
AdicionarAnálisis.Adicionar.Validar El sistema valida que la cantidad de caracteres no sobrepase los 2000.
AdicionarAnálisis.Adicionar.Ok El sistema guarda el análisis que haya escrito el Director de Proyecto.
AdicionarAnálisis.Adicionar.NoOk El sistema muestra un mensaje, anunciando que el análisis no fue realizado, cuando el empleado intente guardar sin haber diligenciado el campo de análisis o cuando haya caída del servidor de la base de datos.
Modificar análisis
El sistema permitirá al director de proyecto modificar información del análisis y plan de acción, para corregir errores de interpretación y redirigir las acciones correctivas. Los requerimientos son los siguientes:
ModificarAnálisis.Modificar.Validar El sistema valida que la cantidad de caracteres no sobrepase los 2000.
ModificarAnálisis.Modificar.Ok El sistema guarda el análisis que haya escrito el director de proyecto.
ModificarAnálisis.Modificar.NoOk El sistema muestra un mensaje, anunciando que el análisis no fue realizado, cuando el director de proyecto intente guardar sin haber diligenciado el campo de análisis, o cuando haya caída del servidor de la base de datos.
Adicionar Plan de Acción
50
AdicionarPlan.Adicionar.Validar El director de proyecto tendrá la libertad de agregar o no, uno o varios planes de acción.
El sistema valida que la fecha esperada sea igual o mayor a la fecha actual.
AdicionarPlan.Adicionar.Ok El sistema guarda el plan de acción que haya escrito el director de proyecto.
AdicionarPlan.Adicionar.NoOk El sistema muestra un mensaje anunciando que el plan de acción no se puede guardar. Este mensaje se muestra cuando se intente grabar un plan de acción, que no tenga todos los campos diligenciados o cuando haya caída del servidor de la base de datos.
AdicionarPlan.Adicionar.Bloquear El sistema no permite modificar los campos del plan de acción.
Consultar histórico
El sistema permite consultar la información relacionada con los indicadores DDE, generados en el periodo o en los periodos que elija el director de proyecto.
ConsultarHistórico.Consultar.Criterios El sistema solicita el código del proyecto a consultar.
ConsultarHistórico.Consultar.Orden El sistema muestra los periodos creados en forma ascendente. ConsultarHistórico.Consultar.Ok El sistema muestra los datos del
indicador (límites de especificación, densidad de defectos, gráficas) del proyecto, al seleccionar el periodo que se desea consultar.
51
consulta. Este mensaje se muestra, cuando haya caída de la conexión de red o caída del servidor de base de datos.
11.1.5. Diagrama de flujo de los requerimientos
A continuación se presentan los diagramas de flujo de los requerimientos mostrados en el numeral anterior, que representa el proceso de cada requerimiento.
Figura 20. Diagrama de flujo del requerimiento “Autenticar Usuario”
52
En la figura 20, se muestra el proceso que hace el usuario para iniciar sesión. El usuario inicia sesión, ingresando un nombre de usuario y una contraseña. El usuario debe estar previamente registrado.
.
Figura 21. Diagrama de flujo del requerimiento “Generar indicador”.
Muestra el proceso para generar un indicador. Fuente: Elaboración propia.
53
Figura 22. Diagrama de flujo del requerimiento “Adicionar análisis”.
Muestra el proceso para adicionar el análisis de un indicador. Fuente: Elaboración propia.
54
Figura 23. Diagrama de flujo del requerimiento “Modificar análisis”.
Muestra el proceso que para editar el análisis respectivo del indicador. Fuente: Elaboración propia.
55
Figura 24. Diagrama de flujo del requerimiento “Adicionar plan de acción”.
Muestra el proceso que para adicionar un plan de acción. Fuente: Elaboración propia.
56
Figura 25. Diagrama de flujo del requerimiento “Modificar análisis”.
Muestra el proceso para buscar un indicador ya generado en el histórico. Fuente: Elaboración propia.
57 11.2. FASE DE DISEÑO
11.2.1. Modelo entidad relación
Figura 26. Modelo entidad-relación.
58
El modelo entidad-relación, esta soportado por el artefacto ‘CO_358_DOC_DIS’ (Ver Anexo B en https://drive.google.com/drive/folders/0B7YZBV85D2MrUXk1ZVB JODJ4WmM - CO_358_DDE _DOC_DIS.pdf).
Para el modelo entidad-relación, de la figura 26, se tuvo en cuenta lo siguiente:
Las entidades en color verde son las entidades del sistema.
Las entidades de color azul corresponden a entidades externas del sistema. Estas entidades pertenecen al sistema Ares 2, que pertenece a Asesoftware. Se utilizará la base de datos de Ares 2 para el inicio de sesión del aplicativo, determinar los proyectos asignados que tiene cada director de proyecto y determinar los periodos.
A continuación se presenta el diccionario de datos.
Nombre Descripción Tipo
DDE_PLAN_DE_ACCION Guarda la información que el director de proyecto ingrese en el aplicativo referente al plan de
ACTIVIDAD Actividad que digita el director de
proyecto.
Atributo
RESPONSABLE Responsable de ejecutar la
actividad.
Atributo
FECHA_ESPERADA Fecha esperada para ejecutar la
actividad.
Atributo DDE_INDICADOR Guarda el análisis que ingrese el
director de proyecto.
ESTADO (DDE_INDICADOR) Estado del indicador. Puede tomar el estado de definitivo o el estado de borrador.
Atributo
DDE_ESTIMACION_DEFECTOS Hace referencia a los defectos no triviales que utiliza el indicador para calcular la densidad (DDE).
Entidad
FASE Tiene como dominio la fase a la
cual corresponden los defectos,
59
Nombre Descripción Tipo
es decir, fase de requerimientos, de diseño o de construcción. VALOR
(DDE_ESTIMACION_DEFECTOS)
Corresponde al total de defectos estimados en una determinada fase.
Atributo
TIPO Define si el defecto es un defecto
inyectado o removido.
Atributo DDE_TAMANO_SERVICIO Guarda los puntos funcionales
del proyecto.
periodo laboral en la compañía.
Entidad CONSECUTIVO (PERIODO) Consecutivo que se usa como
llave primaria.
Atributo FECHA_INICIO Fecha en la cual inicia el periodo. Atributo
FECHA_FIN Fecha en la que finaliza el
periodo.
Atributo
AÑO Año del periodo. Atributo
HORAS_LABORALES Horas que se deben laborar en el actual periodo, pues se tienen en cuenta los días festivos.
Atributo
ASIGNACION Asignación de proyecto a un
empleado de Asesoftware.
Entidad CONSECUTIVO (ASIGNACION) Consecutivo que se usa como
llave primaria.
Atributo
SERVICIO Representa el proyecto entre
Asesoftware y un cliente.
Entidad
CODIGO_SERVICIO Código del proyecto. Atributo
EMPRESA Representa la razón social del CONSECUTIVO (EMPRESA) Consecutivo que se usa como
llave primaria.
Atributo
ROLES_PERSONA Entidad de rompimiento entre la
entidad ROL y PERSONA.
Entidad
ROL Representa la función que
desempeña un empleado de Asesoftware en el proyecto.
Entidad
CONSECUTIVO (ROL) Consecutivo que se usa como llave primaria.
60
Nombre Descripción Tipo
ROLNAME Rol que se puede presentar en CONSECUTIVO (PERSONA) Consecutivo que se usa como
llave primaria.
Atributo NUMERO_IDENTIFICACION Número que identifica a una
persona.
Atributo
APELLIDOS Apellidos de una persona. Atributo
NOMBRE (PERSONA) Nombres de una persona. Atributo
TIPO_IDENTIFICACION Tipo de identificación de la persona. Puede ser una cédula o una cédula de extranjería.
Atributo
USUARIO Representa un usuario del
sistema de información Ares.
Entidad CONSECUTIVO (USUARIO) Consecutivo que se usa como
llave primaria.
Atributo
ROL (USUARIO) Rol que ejecuta una empleado
en un determinado proyecto.
Atributo
PASSWORD Contraseña del empleado. Atributo
USERNAME Nombre de usuario del
empleado.
Atributo
CARGO Cargo por el cual fue contratada
una persona en Asesoftware.
Entidad CONSECUTIVO (CARGO) Consecutivo que se usa como
llave primaria.
Atributo
DESCRIPCION Descripción del cargo de
empleado.
Atributo
NOMBRE (CARGO) Nombre del cargo que ejecuta el
empleado.
Atributo
11.2.2. Diseño de la interfaz de usuario
61
Pantalla de inicio de sesión
Figura 27. Pantalla de inicio de sesión.
62
Pantalla de inicio
Figura 28. Pantalla de inicio.
63
Pantalla consultar indicador
Figura 29. Pantalla de consultar indicador.
64
Pantalla generar indicador
Figura 30. Pantalla de generar indicador.
65
Pantalla información del proyecto
Figura 31. Pantalla información del proyecto.
66
Pantalla inicio con usuario diferente a director de proyecto
Figura 32. Pantalla de inicio otros usuarios.
67
Pantalla resultado del indicador
Figura 33. Pantalla de resultado del indicador.
68
Pantalla de resultado con usuario diferente a director de proyecto
Figura 34. Pantalla de resultado del indicador otros usuarios.
69
Pantalla consultar con usuario diferente a director de proyecto
Figura 35. Pantalla de consulta otros usuarios.
70
11.2.3. Diseño de la navegación de los usuarios
En este numeral, se presenta como los prototipos de las pantallas interactúan entre ellas y la manera de como el usuario navega para realizar el proceso completo, desde la consulta, hasta la generación del informe del indicador.
La representación de la navegación entre las páginas, se hizo a través de jerarquías. Por ejemplo, en la figura 36, la pantalla de inicio de sesión será la primera que verá el usuario. Ahora bien, se anexó el número de la figura, para que sea más entendible, y se sepa con detalle, el prototipo usado en la figura 36.
En la figura 36, cuando el usuario este en la pantalla de inicio (Ver figura 28), el usuario podrá escoger dos caminos, que son: consultar el indicador (Ver figura 29), o generar el indicador (Ver la figura 30).
Figura 36. Navegación entre pantallas del usuario.
