Contenido. Dirección General de Servicio Civil Modelo de Calidad de Software para Desarrollo de Sistemas en la DGSC

Transcripción

1

2 2 Contenido Introducción...3 Capítulo I...4 Estado del arte para Modelos de Calidad de Software Modelo de McCall Modelo de Dromey Modelo Furps Modelo ISO Modelo de Calidad Web (WQM) Six Sigma Modelo Boehm Capítulo II Modelo de Calidad Web (WQM) Características web Características de calidad Procesos del ciclo de vida Capítulo III Definición de métricas e indicadores para WQM Capítulo IV Estrategia de pruebas para desarrollo de software Conclusiones... 26

3 3 Introducción La Dirección General de Servicio Civil en su afán de evaluar y proponer una mejora continua respecto a los servicios y productos que ofrece al ciudadano, inicio en el 2012 un proceso de mejora enfocado en analizar aquellos procesos, metodologías y formas de actuar de las diferentes áreas que componen la institución determinando certificar la totalidad de los servicios generados por dichas áreas que componen la institución. Dicha certificación obedece a la Norma ISO La Unidad de Tecnologías de Infocomunicación fue una de las llamadas a estudiar y analizar minuciosamente sus procesos internos sobre la base del desarrollo de software definiendo aquellos puntos débiles que pudiesen entorpecer el trabajo realizado por el equipo humano ubicado en la UTIC. Es así como el 09 de julio del 2012 se establece la creación de un objetivo de calidad de software para la UTIC el cual debía ser una premisa fundamental por parte del personal informático una vez les fuera encomendada la tarea de crear o mantener software mejorando de esta manera la calidad del producto entregado al usuario. Para realizar esta labor se definió su realización en fases las cuales debían arrojar resultados que permitieran medir su avance y ejecución garantizando al final un documento que abarcara toda la investigación realizada a través de los meses invertidos. Este documento es el resultado de dicho estudio en el cual detallamos los hallazgos o resultados obtenidos los cuales deben servir como consulta obligatoria por parte del equipo de desarrollo de la UTIC en aquellas ocasiones en que les sea encomendada una labor de desarrollo de software. Además, este documento funge como guía para las subcontrataciones de desarrollo de sistemas que por medio de outsourcing la institución realice en el futuro. El presente trabajo se ha divido en 4 capítulos los cuales detallan claramente los pasos seguidos durante estos meses de trabajo. El mismo detalla en su primer capítulo un estudio riguroso sobre el Estado del Arte en materia de Modelos de Calidad de Software realizado por diferentes investigadores a nivel mundial, el capítulo 2 nos presenta una justificación del Modelo WQM, escogido al final por parte de los miembros de UTIC como la metodología a seguir e implantar para los desarrollos de software, en el capítulo 3 definimos métricas e indicadores que permitan cuantificar la calidad del producto software ofrecido al usuario y por último el capítulo 4 describimos una estrategia de pruebas a implementar en la UTIC que permita suministrar resultados tangibles sobre los productos elaborados dejando constancia de los escenarios empleados en los cuales el software construido fue probado. Esperamos que este documento sirva como guía al personal de la UTIC permitiendo describir características y subcaracterísticas de calidad que el software construido debe poseer ofreciendo un plus adicional al usuario en el producto entregado para su uso cotidiano.

4 4 Capítulo I Estado del arte para Modelos de Calidad de Software Una de las primeras tareas encomendadas a la UTIC fue investigar qué modelos de calidad de software existían y podían ser tropicalizados o utilizados en la Unidad de Tecnologías de Infocomunicación. Para cumplir esta labor nos dimos a la tarea de revisar bibliografía existente en materia de calidad de software desarrollada por diferentes autores internacionales, además, fue importante clarificar el concepto de calidad de software permitiendo detallar nuestro campo de acción. A continuaciones algunas definiciones sobre calidad vistas desde la premisa del desarrollo de software: Definición 1: La calidad es la suma de todos aquellos aspectos o características de un producto o servicio que influyen en su capacidad para satisfacer las necesidades, expresadas o implícitas (ISO 8402) Definición 2: Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas (IEEE ) Según Barbacci (1995) la calidad de software se define como el grado en el cual el software posee una combinación deseada de atributos. Tales atributos son requerimientos adicionales del sistema (Kazman, 2001), que hacen referencia a características que éste debe satisfacer, diferentes a los requerimientos funcionales. Estas características o atributos se conocen con el nombre de atributos de calidad, los cuales se definen como las propiedades de un servicio que presta el sistema a sus usuarios (Barbacci. 1995). En los modelos de calidad para el software, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se evalua a través de un conjunto de indicadores o métricas. Tienen una estructura, por lo general, en tres niveles: Factores de Calidad Criterios de calidad del Producto Métricas del Producto En el nivel más alto de la jerarquía se encuentran los FACTORES o CARACTERÍSTICAS DE CALIDAD, que representan la calidad desde el punto de vista del usuario. Cada uno de los factores se descompone en un conjunto de CRITERIOS O SUBCARACTERÍSTICAS DE CALIDAD. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el

5 5 factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software. Para cada uno de los criterios de calidad se definen entonces un conjunto de MÉTRICAS E INDICADORES, que son medidas cuantitativas de ciertas características del producto que dan una indicación del grado en que dicho producto posee un determinado atributo de calidad. Ahora bien, una vez clarificado estos conceptos, ofrecemos los resultados de los modelos que a nuestro criterio podrían ser utilizados en la UTIC, la tabla 1 detalla dicho resultado: Modelo de McCall Modelo de Boehm ISO 9126 Modelo WQM Furps Drommey Six Sigma Tabla 1: Modelos de calidad del software A continuación ofrecemos una breve explicación de cada uno de los modelos estudiados. 1.1 Modelo de McCall El modelo de McCall (1977) describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre factores de calidad, en base a criterios y métricas de calidad. Este enfoque es sistemático, y permite cuantificar la calidad a través de las siguientes fases: Determinación de los factores que influyen sobre la calidad del software. Identificación de los criterios para juzgar cada factor. Definición de las métricas de los criterios y establecimiento de una función de normalización que define la relación entre las métricas de cada criterio y los factores correspondientes. Evaluación de las métricas. Correlación de las métricas a un conjunto de guías que cualquier equipo de desarrollo podría seguir Desarrollo de las recomendaciones para la colección de métricas. En el modelo de McCall, los factores de calidad se concentran en tres aspectos importantes de un producto de software: características operativas, capacidad de cambios y adaptabilidad a nuevos entornos. En este modelo, el término factor de calidad define características claves que un producto debe exhibir. Los atributos del factor de calidad que define el producto son los nombrados criterios de calidad. Las métricas de calidad denotan una medida que puede ser utilizada

6 6 para cuantificar los criterios. McCall (1977) identifica una serie de criterios, tales como rastreabilidad, simplicidad, capacidad de expansión, etc. Las métricas desarrolladas están relacionadas con los factores de calidad y la relación que se establece se mide en función del grado de cumplimiento de los criterios. La Figura 1 muestra, para el modelo de McCall, los factores de calidad y sus criterios asociados. En ella se observa que algunos de los criterios son compartidos por más de un factor. Figura 1: Modelo de calidad de McCall

7 7 1.2 Modelo de Dromey Dromey (1996) propuso un marco de referencia o metamodelo - para la construcción de modelos de calidad, basado en cómo las propiedades medibles de un producto de software pueden afectar los atributos de calidad generales, como por ejemplo, confiabilidad y mantenibilidad. El problema que se plantea es cómo conectar tales propiedades del producto con los atributos de calidad de alto nivel. Para solventar esta situación, Dromey (1996) sugiere el uso de cuatro categorías que implican propiedades de calidad, que son: correctitud, internas, contextuales y descriptivas. La tabla 2, presenta la relación que establece Dromey (1996) entre las propiedades de calidad del producto y los atributos de calidad de alto nivel. Tabla 2: Modelo de calidad de Dromey

8 8 1.3 Modelo Furps El modelo de McCall ha servido de base para modelos de calidad posteriores, y este es el caso del modelo FURPS, producto del desarrollo de Hewlett-Packard (Grady, 1987). En este modelo se desarrollan un conjunto de factores de calidad de software, bajo el acrónimo de FURPS: funcionalidad (Functionality), usabilidad (Usability), confiabilidad (Reliability), desempeño (Performance) y capacidad de soporte (Supportability). La tabla 3 presenta la clasificación de los atributos de calidad que se incluyen en el modelo, junto con las características asociadas a cada uno (Pressman, 2002). Tabla 3: Modelo de calidad FURPS

9 9 1.4 Modelo ISO 9126 El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software (Pressman, 2002). Este estándar es una simplificación del Modelo de McCall (Losavio, 2003), e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software. El estándar provee una descomposición de las características en subcaracterísticas, que se muestran en la tabla 4. calidad externa e interna funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad adecuación exactitud interoperabilidad seguridad de acceso cumplimiento de la funcionalidad madurez tolerancia a fallos capacidad de recuperación Tabla 4: ISO 9126(Calidad externa e interna) cumplimiento de la fiabilidad capacidad para ser entendido capacidad para ser aprendido capacidad para ser operado capacidad de atracción cumplimiento de la usabilidad comportamiento temporal utilización de recursos cumplimiento de la eficiencia capacidad para ser analizado capacidad para ser cambiado estabilidad capacidad para ser probado cumplimiento de la mantenibilidad adaptabilidad instalabilidad coexistencia capacidad para ser reemplazado cumplimiento de la portabilidad El modelo de calidad del producto software de esta norma incluye calidad interna (medible a partir de las características intrínsecas, como el código fuente), calidad externa (medible en el comportamiento del producto, como en una prueba) y calidad en uso (durante la utilización efectiva por parte del usuario). Las características y subcaracterísticas mostradas en la tabla 4 se refieren a la calidad interna y externa. Mientras que para la calidad en uso sólo establece cuatro características, las cuales representan el efecto combinado de las características de la calidad del software para el usuario. A continuación detallamos las mismas:

10 10 calidad en uso efectividad productividad seguridad de acceso satisfacción Tabla 5: ISO 9126(Calidad en uso) 1.5 Modelo de Calidad Web (WQM) WQM es un modelo desarrollado para atender las necesidades de las aplicaciones web. Los sistemas web deberán ser gestionados y dirigidos de forma rigurosa y cualitativa, y será necesario establecer los mecanismos adecuados que garanticen la calidad de estos sistemas. Para ello se ha definido un Modelo de Calidad para la Web y un conjunto de métricas para cubrir la mayor parte posible de tipos de sitios web. WQM distingue tres dimensiones relacionadas: características web, procesos del ciclo de vida y características de calidad. Para diseñar el modelo se observaron las siguientes premisas: Deber ser aplicable a la gama más amplia de tipologías de sitios web. Debe cubrir tanto puntos de vista externos como internos. Las características y subcaracterísticas se usarán donde sean aplicables. Debe incluir, si es posible, medidas cuantitativas no definidas por una escala nominal.

11 11 WQM (Web Quality Model), propone una estructura de cubo que muestra aquellos aspectos que deben ser tenidos en cuenta en la evaluación de la calidad de un sitio web: las características web, los procesos del ciclo de vida y las características de calidad. WQM es un modelo tridimensional para la evaluación de la calidad de los sitios web, y está caracterizado por tres elementos básicos: La característica de calidad (basada en Quint2 y en el estándar ISO 9126). Los procesos del ciclo de vida (basado en el estándar ISO12207). Las características web (contenido, presentación y navegación). Como base para las características de calidad, WQM utiliza el modelo Quint2, que se basa en la ISO Quint2 amplía el estándar con nuevas características apropiadas para productos web: Funcionalidad, fiabilidad, usabilidad, eficiencia, portabilidad, y mantenibilidad. Para la segunda dimensión, los procesos del ciclo de vida, se utiliza la metodología Métrica V Six Sigma Six Sigma es una propuesta que permite mejorar procesos y productos que ha tenido una gran aceptación. Es una filosofía, una métrica y una estructura de mejoramiento. Esta filosofía pretende ser aplicada en los dominios relacionados a la tecnología y al software; y es utilizada para lograr la satisfacción del cliente con productos novedosos a un precio competitivo. Es una filosofía de gestión que se centra en evitar que se produzcan errores, pérdidas innecesarias o que se tenga que repetir un trabajo. Esta filosofía de Six Sigma consiste en mejorar la satisfacción del usuario por medio de la reducción y eliminación de defectos. Sigma es un término estadístico que mide la desviación estándar de un conjunto de valores, es decir la variación que se produce en un proceso. Esta medida estadística se utiliza para cuantificar el proceso y determinar si ésta está funcionando dentro de un intervalo determinado. Six Sigma tiene como finalidad la reducción de los costos a través de la eliminación de defectos y la mejora de los procesos. Utiliza los siguientes 3 principios: (1) enfoque al cliente, (2) proceso de orientación y (3) liderazgo basado en métricas.

12 Modelo Boehm El modelo de Boehm (1978) agrega algunas características a las existentes en el modelo de McCall y representa una estructura jerárquica de características, cada una de las cuales contribuye a la calidad total. Consiste en un modelo de descomposición de características de calidad del software en 3 niveles (usos principales, componentes intermedios y componentes primitivos) previos a la aplicación de métricas. Este modelo plantea factores de calidad formados por criterios de calidad y métricas respectivas (Figura 2). Figura 2: Modelo de calidad de Boehml El modelo de Boehm tiene como finalidad que a través de la calidad del software, el software: (1) realice lo que desea el usuario (2) utilice recursos informáticos de manera correcta y eficiente (3) sea fácil de utilizar y aprender (4) sea bien diseñado, codificado, probado y mantenido.

13 13 Este modelo es similar al de McCall ya que presenta una jerarquía de características, está basado en un amplio rango de características e incorpora 19 criterios que incluyen características de performance del hardware. Una vez definido el estado del arte sobre algunos modelos de calidad del software investigados por parte de la academia y expuestos para su utilización tanto para organizaciones privadas como públicas, el equipo de profesionales de la UTIC considerada oportuno la utilización y tropicalización del Modelo de Calidad Web Quality Model (WQM) ya que incorpora las ventajas de ISO 9126 contempladas en QUINT2, define un modelo de calidad y mide la funcionalidad web considerando características como contenido, presentación y navegación.

14 14 Capítulo II Modelo de Calidad Web (WQM) El software es considerado hoy día como una pieza fundamental dentro de la estrategia de negocio con que cuenta una institución ofreciendo así una diferenciación en cuanto a los servicios que otorga a sus clientes y usuarios. Es uno de los componentes básicos de la tecnología que se involucra en las empresas e instituciones públicas, no sólo como soporte a los procesos del negocio, productivos y administrativos, sino como parte del plus adicional con que se espera ejercer un cambio en la forma de percibir a las instituciones públicas que conforman el Estado Costarricense. Considerando este principio, la alta dirección de la DGSC, encomendó a la Unidad de Tecnologías de Infocomunicación la tarea de desarrollar un modelo de calidad de software que permitiera a sus usuarios incorporar en sus aplicaciones informáticas características y subcaracterísticas de calidad necesarias, garantizando de esta manera un producto software acorde con estándares internacionales de calidad del software. Como fue expuesto anteriormente en este documento, el objetivo en la producción de software es conseguir un producto de alta calidad. En el caso de los desarrollos de aplicaciones web, conseguir este objetivo se hace cada vez más imprescindible. Esto es debido, entre otras causas, a la inmensa cantidad de información asociada a la tecnología web, y al crecimiento de la complejidad de sus aplicaciones. Los sistemas web deberán ser gestionados y dirigidos de forma rigurosa y cualitativa, y será necesario establecer los mecanismos adecuados que garanticen la calidad de estos sistemas. WQM distingue tres dimensiones relacionadas: características web, procesos del ciclo de vida y características de calidad. (como se muestra en la figura 3) En WQM (Web Quality Model), se propone una estructura de cubo que muestra aquellos aspectos que deben ser considerados en la evaluación de la calidad de un sitio web o aplicación: las características web, los procesos del ciclo de vida y las características de calidad. WQM es un modelo tridimensional para la evaluación de la calidad de los sitios web, y está caracterizado por tres elementos básicos: La característica de calidad (basada en Quint2 y en el estándar ISO 9126). Los procesos del ciclo de vida (basado en el estándar ISO12207). Las características web (contenido, presentación y navegación). Nota: para el proceso de ciclo de vida, la UTIC ha considerado la utilización de la Metodología Métrica V.3 en lugar de utilizar ISO considerando que dicha metodología es más amplia, utilizada e implementada y adaptable fácilmente al entorno de trabajo del equipo de desarrollo.

15 15 Web Features Content Presentation Navigation Lifecycle Processes Development Operation Maintenance Effort Reuse Quality Characteristics Figura 3. Representación gráfica del Modelo WQM [RUI03] Como base para las características de calidad, WQM utiliza el modelo Quint2, que se basa en la ISO 9126 definiendo para ello un conjunto de características y subcaracterísticas necesarias de considerar una vez se desee implementar un producto software. Para la segunda dimensión, los procesos del ciclo de vida, se utiliza la metodología Métrica V.3. Se trabajará con los siguientes procesos: El proceso de viabilidad de sistemas. El proceso de análisis El proceso de desarrollo. El proceso de programación. El proceso de pruebas. El proceso de mantenimiento. Y para el tercer elemento, las características de un sitio web, los tres factores más utilizados son: Contenido. Presentación. Navegación.

16 Características web. En esta dimensión se incluyen los tres aspectos clásicos en web: Contenido, Presentación y Navegación. La navegación permite a los usuarios adquirir toda la información que buscan y hace esta información más fácil de encontrar. La presentación y el contenido son dos componentes principales a la hora de la realizar una página fácil de usar. En el Contenido se incluyen no sólo datos como el texto, gráficos, imágenes, video clips, etc., sino también programas y aplicaciones que proporcionan funcionalidades como scripts, programas CGI, programas java, y otros. El contenido también trata cuestiones de representación y estructura. De forma general, podemos distinguir entre varias categorías para el contenido en la web como estático, semi estático, y dinámico. Las páginas estáticas las forman simplemente textos, imágenes, audio, efectos de audio y video, especiales, etc, no existe contenido dinámico en ellas. Este contenido se genera una vez, al crear el sitio web por primera vez, y rara vez es cambiado. Las páginas semiestáticas pueden ser generadas de plantillas, pero sin usar programación significativa, esto incluye lenguajes de plantilla como XSLT, XML y otros similares. Esto también incluye algún script por parte del cliente para refinar, como JavaScript. El contenido dinámico es generado ante una solicitud utilizando programas de lado del servidor.la navegación está relacionada con las facilidades de tener acceso a la información y de moverse por la web. La presentación está relacionada con el camino por el cual el contenido y la navegación se presentan al usuario. 2.2 Características de calidad. Para describir las características de calidad, WQM utiliza como base el modelo Quint2, que a su vez está basado en el estándar ISO Se compone de 6 características de calidad aplicables en la web y a su vez para cada característica definida, se enumeran un grupo de subcaracterísticas importantes de considerar cuando de desarrollar software se habla. Además se enumeran cuatro características de uso necesarias para evaluar o medir el software una vez que el mismo ha sido entregado al usuario y donde es importante conocer de primera mano las observaciones que el usuario final pueda realizar sobre el producto software entregado. Las siguientes tablas muestran la calidad interna, externa y en uso que debe poseer un producto software.

17 17 Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Efectividad: Productividad: Internas y externas la capacidad del producto software para proporcionar funciones que satisfagan las necesidades especificadas e implícitas cuando el software se utiliza en las condiciones especificadas. la capacidad del producto software para mantener un nivel especificado de rendimiento cuando se utiliza en las condiciones especificadas. la capacidad del producto software de ser entendido, aprendido, utilizado y atractivo al usuario, cuando se utiliza en las condiciones especificadas. Depende del tipo de "uso" que se espera y tipo de "usuario" que utilizará el producto (ddesarrollador, evaluador/seleccionador, integrador, configurador/administrador del sistema, usuario del sistema) la capacidad del producto software para proporcionar el rendimiento apropiado, relativo a la cantidad de recursos utilizados, bajo las especificaciones determinadas. la capacidad del producto software para ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptación del software a cambios en el entorno, en los requisitos o en las especificaciones funcionales. la capacidad del producto software de ser transferido de un entorno a otro. En uso la capacidad del producto software de permitir a los usuarios conseguir los objetivos determinados con precisión y completitud en un contexto de uso especificado. la capacidad del producto software de permitir a los usuarios de gastar las cantidades de recursos apropiadas con relación a la eficiencia conseguida en un contexto de uso especificado. Seguridad uso): (de la capacidad del producto software de conseguir niveles aceptables de riesgo de dañar a personas, software, equipamiento o al entorno en un contexto de uso especificado. Satisfacción: la capacidad del producto software de satisfacer a los usuarios en un contexto de uso especificado. Nota: La calidad en uso es la capacidad del producto software para permitir que los usuarios consigan los objetivos especificados con eficiencia, productividad, seguridad y satisfacción en contextos de uso especificados. Las métricas e indicadores que se han de aplicar nacen a partir de encuestas de opinión realizadas por UTIC a los clientes tanto del sitio como de las aplicaciones web que posea la DGSC. 2.3 Procesos del ciclo de vida. Como fue mencionado se definió Métrica V.3 como metodología para el desarrollo de software durante las etapas del ciclo de vida. Para ello se tomaron los siguientes procesos para su ejecución: El proceso de viabilidad de sistemas. El proceso de análisis El proceso de desarrollo. El proceso de programación. El proceso de pruebas. El proceso de mantenimiento. Nota: para un mejor y mayor grado de profundada en cada tema se recomienda la lectura del material que conforma la documentación de la Metodología Métrica V.3.

18 18 Capítulo III Definición de métricas e indicadores para WQM Un aspecto fundamental al momento de definir nuestro modelo de calidad, fue la construcción de métricas e indicadores que permitieran la cuantificación de las características de calidad definidas al inicio del desarrollo de software permitiendo otorgar un valor porcentual al producto desarrollado por la UTIC. A continuación mostramos la siguiente tabla que detalla las características, subcaracterísticas, métricas e indicadores necesarios y un peso que permita evaluar en un rango de 1 a 100 la calidad del producto software desarrollado. Esta información debe servir para ayudar al equipo de QA (Quality Assurance) de la institución a dar seguimiento, confeccionar planes de prueba y demás tareas necesarias que permitan incrementar la calidad del software desarrollado por la UTIC.

19 Internas y externas Funcionalidad: la capacidad del producto software para proporcionar funciones que satisfagan las necesidades especificadas e implícitas cuando el software se utiliza en las condiciones especificadas. Subcaracterística Descripción Métrica Indicador Adecuación la capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas específicas y objetivos de los usuarios. Búsquedas globales (Global Search): número de tipos de búsqueda generales permitidas en un sitio o aplicación (peso 25% ) (numero de búsquedas exitosas/numero de búsquedas) * 100 Exactitud la capacidad del producto software para proporcionar los resultados o efectos correctos y con el grado de precisión acordado. Búsquedas extensivas: número de tipos de búsqueda especializadas permitidas en un sitio o aplicación web (peso 25% ) (numero de búsquedas exitosas especializadas / numero de búsquedas especializadas) * 100 Interoperabilidad Seguridad la capacidad del producto software para interactuar con uno o más sistemas especificados. Capacidad del producto software para proteger información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas autorizados. Interfaces externas: número de interfaces internas o externas que permiten interactuar con otros sistemas informáticos (peso 25% ) (cantidad de interfaces internas o externas / total de interfaces de la aplicación software) * 100 Conformidad Conveniencia la capacidad del producto software para adaptarse a los estándares, convenciones o regulaciones en leyes y prescripciones relativos a la funcionalidad. Atributo del software que tiene que ver con la presencia y la adecuación de un conjunto de funciones para tareas especificadas. La conveniencia es una subcaracterística de calidad que considera si las funcionalidades deseadas están presentes en el producto de software. Se determina, sobre todo, por la efectividad de las etapas de la ingeniería de requisitos, cuando un usuario y un desarrollador del software tienen que comunicarse para determinar las funcionalidades deseadas de un producto de software. Debe existir la precisión de la comunicación y la comprensión inequívoca del dominio de la aplicación y del problema que se tratará. Seguridad perimetral del software: número de interfaces de usuario, tablas de base de datos, dispositivos de comunicación y procedimientos almacenados enriptados. (peso 25% ) (numero de alternativas de software no encriptados / número total de alternativas de software que deben ser encriptados) * 100 Trazabilidad Atributo del software que indica la cantidad de esfuerzo necesitado para verificar la corrección del proceso de datos sobre puntos requeridos. Fiabilidad: la capacidad del producto software para mantener un nivel especificado de rendimiento cuando se utiliza en las condiciones especificadas. Subcaracterística Descripción Métrica Indicador Madurez la capacidad del producto software para evitar fallos provocados por errores en el software. Número de links rotos: cantidad de enlaces a otras páginas que están rotos o no dirigen a ninguna parte. (peso 25% ) (Cantidad de links funcionales / total de links de la aplicación software) *100

20 20 Tolerancia a fallos Recuperabilidad Conformidad la capacidad del producto software para mantener un nivel de rendimiento determinado en caso de defectos en el software o incumplimiento de su interfaz. la capacidad del producto software para restablecer un determinado nivel de rendimiento y recuperar los datos afectados directamente en caso de ocurrir un fallo. la capacidad del producto software para adaptarse a estándares, convenciones y regulaciones referidas a la fiabilidad. Número de imágenes con texto ALT (peso 25% ) Disponibilidad del producto software: cantidad de tiempo transcurrido en que la aplicación software o sitio web se encuentra disponible. (peso 25% ) (cantidad de imágenes con texto ALT / total de imágenes de la aplicación software) * 100 Tiempo mensual transcurrido en minutos / Disponibilidad Degradabilidad Atributo del software que refiere la cantidad de tiempo que el producto está disponible para el usuario en el tiempo en que es necesario. Atributo del software que tiene que ver el esfuerzo necesitado para reestablecer la funcionalidad esencial después de una interrupción. Número de errores ortográficos (peso 25% ) (Cantidad de errores ortográficos localizados / cantidad de palabras) * 100 Usabilidad: la capacidad del producto software de ser entendido, aprendido, utilizado y atractivo al usuario, cuando se utiliza en las condiciones especificadas. Depende del tipo de "uso" que se espera y tipo de "usuario" que utilizará el producto (desarrollador, evaluador/seleccionador, integrador, configurador/administrador del sistema, usuario del sistema) Subcaracterística Descripción Métrica Indicador Comprensibilidad Facilidad de aprendizaje Operabilidad Atracción Conformidad Entendibilidad Aprendibilidad Operabilidad Explicidad Personalización la capacidad del producto software para permitir al usuario que entienda si el software es adecuado, y como debe utilizarse para determinadas tareas y bajo ciertas condiciones de uso. la capacidad del producto software para permitir al usuario aprender su aplicación. la capacidad del producto software para permitir que el usuario lo opere y lo controle. la capacidad del producto software para atraer al usuario. la capacidad del producto software para adaptarse a estándares, convenciones, guías de estilo y regulaciones relacionadas con la usabilidad. Atributo del software que tiene que ver con el esfuerzo de los usuarios para reconocer el concepto lógico del producto software y su aplicabilidad, está relacionado con el reconocimiento de conceptos y su aplicabilidad. Subcaracterístca que refleja el esfuerzo de los usuarios para aprender un producto software (por ejemplo, control, entrada, salida). Mejorando la entendibilidad y claridad de los conceptos empleados en la aplicación, se hace mucho más fácil aprender cómo controlar la aplicación y qué tipo de entrada y salida produce o requiere. Esto mejora el esfuerzo requerido para aprender una operación. Subcaracterística de calidad que indica el esfuerzo de los usuarios para el control de operación y la operación. Atributo del software que tiene que ver con el estado del producto software (barras de progresión, etc.) Subcaracterística de calidad que permite al software ser personalizado Amigabilidad de la página: Grado de facilidad en la que un usuario inexperto hace uso eficiente de un sitio o aplicación Web (peso 25 %) Contador de páginas: contador interno de las páginas por área que fueron visitadas por los usuarios. (peso 25 %) Personalización del sitio Web (Mínimo 2 lenguajes, tres tamaños de letra, colores de fondo). (peso 25 %) Contador de visitas: esta métrica nos debe permitir obtener información de nuestros clientes ( número de visitantes a nuestro sitio web, número de visitas en línea, perfil del visitante (navegador, resolución, sistema operativo, colores de pantalla), visitas procedentes de los principales buscadores de Internet, países de procedencia de nuestros visitantes y páginas Web que nos envían visitas) permitiendo la toma de decisiones para futuros desarrollos web. (peso 25 %) Encuestas a realizar en la etapa de producción (cantidad de respuestas positivas obtenidas de la encuesta / cantidad total de respuestas a la encuesta) * 100 Calificación obtenida a través de encuesta realizada por QA Contador de visitas

21 21 por el usuario para reducir el esfuerzo requerido para su uso, e incrementar el nivel de satisfacción con el software. Atractividad Atributo del software que tiene que ver con la satisfacción de los deseos y preferencias del usuario, a través de servicios, comportamiento y presentación más allá de la demanda real. Claridad Subcaracterística de la calidad del software que tienen que ver con la claridad de hacer al usuario consciente de las funciones que el producto software puede realizar. Utilidad Atributo del software que tienen que indica la disponibilidad de instrucciones para el usuario sobre cómo interactuar con él. Facilidad de uso Subcaracterística de calidad que indica la satisfacción de los usuarios. Eficiencia: la capacidad del producto software para proporcionar el rendimiento apropiado, relativo a la cantidad de recursos utilizados, bajo las especificaciones determinadas. Subcaracterística Descripción Métrica Indicador Comportamiento temporal Utilización de recursos Conformidad la capacidad del producto software para proporcionar tiempos de respuesta y de procesamiento apropiados cuando realiza sus funciones bajo condiciones determinadas. la capacidad del producto software para utilizar cantidades y tipos de recursos apropiados cuando el software realiza su función bajo determinadas condiciones. la capacidad del producto software para adaptarse a estándares o convenciones relacionadas con la eficiencia. Páginas de acceso rápido (Quick access pages): tiempo de acceso o descarga para las páginas (debe definirse qué tiempo de descarga es el más adecuado) (peso 33 %) Frecuencia de navegación: informa sobre el ritmo de navegación de los internautas. Pasan demasiado tiempo en las páginas de tipo formulario? Sobrevuelan por encima las páginas de contenido? El cargado de páginas parece ralentizarse de un mes a otro? (peso 33 %) Tiempo de descarga: tiempo de descarga de archivos multimedia (gráficos, audio, video, animación, imágenes) o de text (word, pdf, excel, power point) (peso 33 %) Tiempo promedio de descarga por página (TPDP aplicación TPDP Sitio Web TPDP / paginas Ojo podría tener indicadores de frecuencia de navegación por área o aplicación de software desarrollada y de descarga de los archivos multimedia o de texto por área. TD (Tiempo de descarga) Mantenibilidad: la capacidad del producto software para ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptación del software a cambios en el entorno, en los requisitos o en las especificaciones funcionales. Subcaracterística Descripción Métrica Indicador Analizabilidad Cambiabilidad Estabilidad Capacidad del producto software de diagnosticar sus deficiencias o causas de fallos, o de identificar las partes que deben ser modificadas. Capacidad del producto software de permitir implementar una modificación especificada. La implementación incluye los cambios en el diseño, el código y la documentación. Capacidad del producto software de evitar los efectos inesperados de las modificaciones. Deficiencias o características ausentes debido a los diferentes navegadores (deficiencies or absent features due to different browsers): permite diagnosticar ya sea por medio de encuestas u otras herramientas las ausencias/deficiencias que posee un sitio o aplicación web. (peso 33 %) Deficiencias o resultados inesperados independientes de los navegadores (deficiencies or unexpected results independent of browsers) permite dianosticar deficiencias o errores no previstos en la fase de construcción del software o sitio web. (peso 33 %) Titulo de las imágenes (Image title): permite definir con anterioridad los títulos que deben poseer las imágenes, esto por normativa de accesibilidad, validando con anterioridad sus partes y evitando Datos obtenidos por medio de encuestas. Se puede colocar una encuesta digital que obtenga información valiosa para el posible mantenimiento del sitio o aplicación web. Datos obtenidos por medio de encuestas. Se puede colocar una encuesta digital que obtenga información valiosa para el posible mantenimiento del sitio o aplicación web. (numero de imágenes con titulo / total de imágenes del sitio o aplicación web) * 100

22 22 efectos inesperados posteriores. (peso 33 %) Facilidad de prueba Capacidad del producto software de permitir validar las partes modificadas. Conformidad Capacidad del producto software de cumplir los estándares o convenciones relativas a la mantenibilidad. Flexibilidad Atributo del software que refiere el esfuerzo necesitado para restablecer su estado de ejecución. Reusabilidad Atributo del software que refiere su potencial para la reutilización completa o parcial en otro producto de software. Portabilidad: la capacidad del producto software de ser transferido de un entorno a otro. Subcaracterística Descripción Métrica Indicador Adaptabilidad Capacidad del producto software para ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software considerado. Contador de elementos interactivos: define el número de elementos interactivos que posee una aplicación o sitio web. (peso 33 %) Número de elementos interactivos de una aplicación o sitio web (debe tender a cero) Facilidad de instalación Coexistencia Reemplazabilidad: la capacidad del producto software para ser instalado en un entorno especificado. la capacidad del producto software para coexistir con otro software independiente en un entorno común, compartiendo recursos comunes. la capacidad del producto software para ser utilizado en lugar de otro producto de software, para el mismo propósito, en el mismo entorno. Contador de elementos de búsqueda: define la cantidad de alternativas de búsqueda existentes en la aplicación o sitio web. Entre más complejo más difícil es su portabilidad. (peso 33 %) Graphics bytes: determina el tamaño en bytes de los gráficos utilizados en una aplicación o sitio web. (peso 33 %) Número de elementos de búsqueda para una aplicación o sitio web. (debe tender a cero) Peso en bytes de cada gráfico construido (el Web Master indica el peso requerido ) Conformidad: la capacidad del producto software para adaptarse a estándares relacionados con la portabilidad.

23 Capítulo IV Estrategia de pruebas para desarrollo de software Tal como lo plantea Roger S. Pressman en su séptima edición de su libro "Ingeniería del software, un enfoque práctico": "Una estrategia de prueba de software proporciona una guía que describe los pasos que deben realizarse como parte de la prueba, cuándo se planean y se llevan a cabo dichos pasos, y cuánto esfuerzo, tiempo y recursos se requerirán. Por tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de la prueba y la recolección y evaluación de los resultados". Nuestro trabajo persigue la elaboración de un marco específico y detallado sobre las pruebas de software que el equipo de desarrollo de la UTIC debe incorporar, interiorizar y poner en práctica una vez que le ha sido encomendado el desarrollo de software. Este marco al que se hace referencia no es más ni menos que la definición de una planificación o estrategia sobre las pruebas por realizar al software que se ha de construir y que debe ser considerando desde los inicios propios del desarrollo de software. Con ello pretendemos definir el camino a seguir, las pruebas por realizar, las plantillas necesarias para efectuar las pruebas, sus participantes, el análisis de los resultados obtenidos generando la documentación necesaria que ha de servir como historia de lo realizado. La planificación o estrategia de pruebas que presentamos debe permitirnos una mejor visualización sobre qué tipos de prueba realizar, qué técnicas y herramientas utilizar, qué plantillas o formularios pueden ser útiles y lo más importante cómo elaborar el documento de pruebas del software. 4.1 Estrategia de prueba para software. La figura 4 detalla cada una de las pruebas que se han de implementar e incorporar en los planes de prueba de software que los miembros de UTIC asuman. El mismo está conformado por: pruebas de unidad, pruebas de integración, pruebas de validación y pruebas del sistema.

24 24 Prueba del sistema Prueba de validación Prueba de integración Prueba de unidad Figura No. 4: estrategia de pruebas 4.2 El proceso de prueba. La figura 5 detalla el proceso completo relacionado con las pruebas basadas en parte en el estándar IEEE std Figura No. 5: ciclo completo de las pruebas Planificación de pruebas Se realiza la planificación general sobre las pruebas por realizar para cada fase de la estrategia de prueba del producto software por construir (pruebas de unidad, pruebas de integración, pruebas de validación y pruebas del sistema). El plan de pruebas se genera en base a la documentación sobre el proyecto y la documentación sobre el software a probar.

25 Diseño de pruebas Luego de realizado el plan de pruebas se procede a diseñar las pruebas especificas basándose en la documentación del software a probar Ejecución de pruebas Una vez finalizada la etapa de diseño de las pruebas, se ejecutan las mismas definiendo aspectos relevantes como ambientes de trabajo, escenarios de ejecución Evaluación de pruebas La etapa de evaluación donde se compara los resultados obtenidos con las salidas esperadas. En este punto se puede obtener alguna de dos salidas: una depuración o un análisis de los errores localizados Análisis de errores La etapa de análisis de errores puede servir para realizar predicciones de la fiabilidad del software y para detectar las causas más habituales de error mejorando los procesos de desarrollo Depuración Por último la depuración permite corregir o no los defectos. Si no es posible su localización, puede ser necesario realizar pruebas adicionales con el fin de obtener más información. Si se logra su corrección, se debe volver a probar el software de tal manera que se compruebe que el problema fue resuelto.

26 26 Conclusiones Es evidente que el desarrollo de software se ha convertido en un aliado fundamental dentro del proceso de mejora continua que experimentan las instituciones gubernamentales costarricenses, intentando llevar más y mejores servicios a los ciudadanos. Las altas autoridades de la DGSC han comprendido dicha situación y por ello han apostado por liderar este importante trabajo en los procesos internos de las áreas que componen nuestra DGSC y la UTIC, como encargada del desarrollo interno de software ha asumido el reto de evaluar y mejorar su forma de trabajar. Por ello es que consideramos que la definición de un Modelo de calidad de software es un paso en la línea correcta hacia esa mejora continua que deben realizar las instituciones públicas que día con día interactúan con miles de usuarios ya sea personalmente o bien por medios digitales. Esperamos que este documento sirva de guía constante para el equipo de desarrollo de la UTIC de tal forma que le permita tener claro el camino a seguir, además, en el plano profesional esperamos sirva de guía para esa mejora continua que debe existir dentro de todo profesional incorporando nuevos conocimientos y destrezas necesarias para realizar su trabajo de la mejor manera siempre teniendo claro que el producto software creado por ellos es la herramienta de trabajo de otros y que ese mismo trabajo es la obtención de los servicios del ciudadano que nos demanda día con día la superación personal y profesional.