Mesa 2. Competitividad y Estudios Organizacionales

Presentación del tema: "Mesa 2. Competitividad y Estudios Organizacionales"— Transcripción de la presentación:

1 Mesa 2. Competitividad y Estudios Organizacionales
Build 2015 8/28/2018 7:32 PM LA GESTIÓN DE LA CALIDAD PARA EL PROCESO DE DESARROLLO DE SOFTWARE EN LA FACULTAD DE INFORMÁTICA Y MATEMÁTICA DE LA UNIVERSIDAD DE HOLGUÍN Mesa 2. Competitividad y Estudios Organizacionales Trabajo concluido La informatización de la sociedad, es una tarea de gran prioridad para el estado cubano debido a la alta perspectiva económica que posee. Gran parte del trabajo informático realizado en el territorio es desarrollado por la Universidad de Holguín “Oscar Lucero Moya” Y es en la FACINF donde tiene lugar el centro del proceso de desarrollo de software de la UHo siendo una actividad fundamental dentro del proceso de formación de los profesionales en dicha facultad. Autores: M.Sc. Reynol Solórzano Pérez. Universidad de Holguín Dra. C. Mayra Rosario Moreno Pino. Universidad de Holguín M. Sc. Ana de Lourdes Torralbas Blázquez. Universidad de Holguín © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2 Build 2014 8/28/2018 Introducción La calidad de un producto se traduce en ahorro de costos y en una mejora general. A nivel mundial en los últimos años se han realizado intensos trabajos para aplicar los conceptos y enfoques de calidad en el ámbito de la industria del software. Existen numerosas definiciones de calidad software en la bibliografía consultada. Pero hay elementos comunes que definen la calidad de software. Lo que está claro a partir de estas definiciones es que la calidad es algo relativo. Siempre va a depender de los requisitos o necesidades que se desee satisfacer. Por eso, la evaluación de la calidad de un producto siempre va a implicar una comparación entre unos requisitos preestablecidos y el producto realmente desarrollado. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita. Esta investigación está orientada al producto pero desde el proceso de desarrollo. Aunque un buen proceso no es garantía de calidad no se puede desdeñar y es necesario enfocarse debidamente en él. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

3 Build 2014 8/28/2018 Calidad de software El grado en el cual un sistema, componente o proceso tenga conformidad con los requisitos establecidos y con las necesidades o expectativas del cliente o usuario. IEEE, 1991 Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente. Pressman, 2010 Existen numerosas definiciones de calidad software en la bibliografía consultada. Pero hay elementos comunes que definen la calidad de software. Lo que está claro a partir de estas definiciones es que la calidad es algo relativo. Siempre va a depender de los requisitos o necesidades que se desee satisfacer. Por eso, la evaluación de la calidad de un producto siempre va a implicar una comparación entre unos requisitos preestablecidos y el producto realmente desarrollado. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita. Esta investigación está orientada al producto pero desde el proceso de desarrollo. Aunque un buen proceso no es garantía de calidad no se puede desdeñar y es necesario enfocarse debidamente en él. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

4 Build 2014 8/28/2018 Calidad de software Los requisitos del software son la base de las medidas de la calidad La evaluación de la calidad del software siempre va a implicar la comparación entre los requisitos y el producto generado. El usuario final mide la calidad del software según lo que tenga éste o no, es en ese sentido que la calidad del software depende de quien la juzgue Existen numerosas definiciones de calidad software en la bibliografía consultada. Pero hay elementos comunes que definen la calidad de software. Lo que está claro a partir de estas definiciones es que la calidad es algo relativo. Siempre va a depender de los requisitos o necesidades que se desee satisfacer. Por eso, la evaluación de la calidad de un producto siempre va a implicar una comparación entre unos requisitos preestablecidos y el producto realmente desarrollado. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita. Esta investigación está orientada al producto pero desde el proceso de desarrollo. Aunque un buen proceso no es garantía de calidad no se puede desdeñar y es necesario enfocarse debidamente en él. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

5 Build 2014 8/28/2018 Producto software La mayoría de las características que definen al software no se pueden cuantificar fácilmente Esto hace que se enfrente a unos problemas generales como: el aumento constante del tamaño y complejidad de los programas, la dificultad de conseguir productos totalmente depurados, el equipo de desarrollo y el producto en sí que se desarrolla. Existen numerosas definiciones de calidad software en la bibliografía consultada. Pero hay elementos comunes que definen la calidad de software. Lo que está claro a partir de estas definiciones es que la calidad es algo relativo. Siempre va a depender de los requisitos o necesidades que se desee satisfacer. Por eso, la evaluación de la calidad de un producto siempre va a implicar una comparación entre unos requisitos preestablecidos y el producto realmente desarrollado. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita. Esta investigación está orientada al producto pero desde el proceso de desarrollo. Aunque un buen proceso no es garantía de calidad no se puede desdeñar y es necesario enfocarse debidamente en él. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

6 El desarrollo de software en la FACINF
Build 2015 8/28/2018 7:32 PM El desarrollo de software en la FACINF Se inaugura la FACINF en 1999 Los estudiantes son la fuerza de trabajo principal Proceso de desarrollo de software es dirigido por profesores Forma parte del ejercicio de culminación de estudios Esta facultad se inaugura en 1999 con estudiantes de la región oriental. Los estudiantes de esta facultad constituyen la fuerza laboral principal en el proceso de desarrollo de software que tiene lugar en la facultad. Este proceso de desarrollo de software está compuesto en su mayoría por estudiantes y es dirigido por profesores. Entre los sistemas desarrollados allí sobresalen el de la Empresa Ernesto “Ché” Guevara, la Intranet para el hotel Pesquero III, el Proyecto FELTON, el Partido Provincial y el del Hospital Pediátrico Muchos de estos proyectos son realizados por estudiantes como parte del ejercicio de culminación de estudios © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

7 Problemas actuales Existe la tendencia de empezar a codificar sin tener en cuenta las etapas de captura de requerimientos, como etapa primaria y fundamental del proceso de desarrollo de software Se trabaja de forma espontánea, se aprende sobre la marcha, sin una organización en la creación del software En la mayoría de las ocasiones resulta difícil actualizar o mejorar un programa porque no siempre se tiene la documentación más elemental Se hizo una investigación con especialistas en el desarrollo de sw para detectar las deficiencias en el proceso de desarrollo teniendo a estudiantes como la fuerza principal. Entre las deficiencias encontradas están que: No existen mecanismos de control suficientes. Ya sea manual o asistido Se ha perdido el aprender de los errores anteriores pues se cuenta con poca documentación al respecto. No existen antecedentes de datos históricos sobre la calidad de los productos que han sido elaborados pues no se cuenta con una base de datos históricos de proyectos anteriores No se trabaja pensando en el mantenimiento del sistema El trabajo realizado, en muchas ocasiones, no tiene la calidad y profesionalidad requerida

8 Metodología Se hizo un estudio de los modelos de calidad de software más relevantes de la bibliografía revisada para escoger el que más se adecue a las características del entorno donde será aplicado (académico). Se plantearon tres etapas para aplicar el modelo de calidad escogido y la gestión de riesgos de un producto informático: al inicio del proyecto, durante el desarrollo y al finalizar el proyecto. Se plantearon entonces, las listas e comprobación para medir cada uno de los factores y criterios del modelo escogido. Se desarrolló una herramienta informática, QSoft donde se automatiza la medición de la calidad de software y la gestión de riesgos informáticos mediante el uso de la metodología planteada en esta investigación. Se hizo una investigación con especialistas en el desarrollo de sw para detectar las deficiencias en el proceso de desarrollo teniendo a estudiantes como la fuerza principal. Entre las deficiencias encontradas están que: No existen mecanismos de control suficientes. Ya sea manual o asistido Se ha perdido el aprender de los errores anteriores pues se cuenta con poca documentación al respecto. No existen antecedentes de datos históricos sobre la calidad de los productos que han sido elaborados pues no se cuenta con una base de datos históricos de proyectos anteriores No se trabaja pensando en el mantenimiento del sistema El trabajo realizado, en muchas ocasiones, no tiene la calidad y profesionalidad requerida

9 Modelos de calidad de software
Build 2014 8/28/2018 Modelos de calidad de software Proporcionan las bases para la especificación de los requerimientos de calidad y la evaluación de la misma Son utilizados para construir mejores productos y para asegurar su calidad Convierten la calidad en algo concreto, que se puede definir, que se puede medir y que se puede planificar sobre todo © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

10 Estructura de un modelos de calidad de software
Build 2014 8/28/2018 Estructura de un modelos de calidad de software Calidad de Software Medidas Cuantitativas Grado en que se posee un determinado atributo de calidad Producto de software Atributos de Calidad Internos Usuario Atributos de Calidad Externos Factores de Calidad Criterios de Calidad del producto Métricas del Producto En los modelos de calidad, la calidad se define de forma siguiente: En el nivel más alto de la jerarquía se encuentran los FACTORES de calidad que representan la calidad desde el punto de vista del usuario. Son las características que componen la calidad. También se les llama Atributos de Calidad Externos. Cada uno de los factores se descompone en un conjunto de CRITERIOS de calidad. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software. También se les llama Atributos de Calidad Internos. Para cada uno de los criterios de calidad se definen entonces un conjunto de MÉTRICAS, que son medidas cuantitativas de ciertas características del producto que, cuando están presentes, dan una indicación del grado en que dicho producto posee un determinado atributo de calidad. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

11 Modelos de calidad de software
Build 2014 8/28/2018 Modelos de calidad de software En los modelos de calidad, la calidad se define de forma siguiente: En el nivel más alto de la jerarquía se encuentran los FACTORES de calidad que representan la calidad desde el punto de vista del usuario. Son las características que componen la calidad. También se les llama Atributos de Calidad Externos. Cada uno de los factores se descompone en un conjunto de CRITERIOS de calidad. Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software. También se les llama Atributos de Calidad Internos. Para cada uno de los criterios de calidad se definen entonces un conjunto de MÉTRICAS, que son medidas cuantitativas de ciertas características del producto que, cuando están presentes, dan una indicación del grado en que dicho producto posee un determinado atributo de calidad. © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

12 Comparación entre modelos
Build 2015 8/28/2018 7:32 PM Comparación entre modelos Particularidades del contexto McCall Boehm FURPS Dromey ISO 9126 Los estudiantes son los principales desarrolladores No se cuenta con un equipo de aseguramiento de la calidad de software Los desarrolladores están en un constante proceso de aprendizaje “Ha de ser simple y concreto si se quiere que pueda ser utilizado con ciertas garantías de éxito” (Pressman, 2010) Debe ser flexible tanto para el entorno de desarrollo como para los tipos de sistemas en los que pueda ser utilizado Para esta investigación se estudiaron cinco modelos para escoger uno. Los modelos que se escogieron son los más relevantes de la bibliografía estudiada son: El modelo que se propone en esta investigación debe tener ciertas características que permitan que sea usado sin muchas complicaciones por los desarrolladores. Estas características están determinadas por el contexto donde será aplicado. Este contexto es académico por lo que tiene particularidades que lo diferencian de un contexto de desarrollo profesional: © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

13 Comparación entre modelos
Build 2015 8/28/2018 7:32 PM Comparación entre modelos Características del modelo a escoger McCall Boehm FURPS Dromey ISO 9126 Disponibilidad de la información Claridad Adaptabilidad Completitud Genérico Facilidad de Uso Sencillez Facilidad de modificación Modelo Fijo, a la Medida o Mixto Se compararon en cuanto a 9 características. Se dieron los valores 1, 2 o 3 de acuerdo al grado en que cada modelo presenta estas características Disponibilidad de la información. Grado en que es posible acceder a la información existente Claridad. La facilidad de entender Adaptabilidad. Grado en que el modelo posee la capacidad de adaptarse a distintas situaciones dependiendo del producto al que se va a aplicar Completitud. Grado en el que el modelo describe todas sus partes en su totalidad sin dejar por fuera información importante Genérico. Si el modelo sirve para propósitos generales Facilidad de Uso. La facilidad con la que se pueda utilizar el modelo Sencillez. Sencillez o simplicidad del modelo Facilidad de modificación. La facilidad con la que se pueda modificar el modelo para adaptarlo a un tipo de sistema determinado Modelo Fijo, a la Medida o Mixto aracterísticas: © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

14 Comparación entre modelos
Build 2015 8/28/2018 7:32 PM Comparación entre modelos Criterios McCall Boehm FURPS Dromey ISO 9126 Disponibilidad de la información 2 1 Claridad 3 Adaptabilidad Completitud Genérico Facilidad de Uso Sencillez Facilidad de modificación Modelo Fijo, a la Medida o Mixto Total 25 16 15 13 21 Se compararon en cuanto a 9 características. Se dieron los valores 1, 2 o 3 de acuerdo al grado en que cada modelo presenta estas características Disponibilidad de la información. Grado en que es posible acceder a la información existente Claridad. La facilidad de entender Adaptabilidad. Grado en que el modelo posee la capacidad de adaptarse a distintas situaciones dependiendo del producto al que se va a aplicar Completitud. Grado en el que el modelo describe todas sus partes en su totalidad sin dejar por fuera información importante Genérico. Si el modelo sirve para propósitos generales Facilidad de Uso. La facilidad con la que se pueda utilizar el modelo Sencillez. Sencillez o simplicidad del modelo Facilidad de modificación. La facilidad con la que se pueda modificar el modelo para adaptarlo a un tipo de sistema determinado Modelo Fijo, a la Medida o Mixto aracterísticas: © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

15 Comparación entre modelos
Build 2015 8/28/2018 7:32 PM Comparación entre modelos Es más general Sistemas de gestión empresarial y herramientas informáticas típicas Es sencillo y fácil de utilizar Se tienen las métricas Modelo de McCall Es más general. Plantea una amplia gama de factores y criterios que lo hacen muy configurable y adaptable para cualquier tipo de sistema Al ser sistemas de gestión empresarial y herramientas informáticas típicas las que se producen en FACINF no se necesita un modelo personalizado Es sencillo de utilizar y cubre cualquier variante que se necesite en FACINF Se tienen las listas de comprobación (métricas) para los factores y criterios que lo conforman © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

16 Modelo de McCall Ejes 3 Factores 11 Criterios 23 Build 2014 8/28/2018
© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

17 Listas de comprobación
Las listas de comprobación son las métricas asociadas a los criterios y (o) factores que representan Son las medidas cuantitativas de estas características del producto que, cuando están presentes, dan una indicación del grado en que dicho producto posee un determinado atributo de calidad. Las listas propuestas como solución cuentan con un mínimo de cinco preguntas. Estas preguntas están orientadas en función de aspectos concretos que darán una mejor medida de cada criterio. Aquí se muestra un ejemplo de lista de comprobación en este caso del criterio Auto Descripción. Cada lista está integrada por un grupo de preguntas que van a estar determinadas por el objetivo que persiga el criterio en cuestión. Estas se responden de manera afirmativa o negativa (“SI”, “NO”) y tienen el propósito de sacar a la luz los problemas que puedan existir. Estos resultados se promedian y se obtiene un valor para el criterio objeto de evaluación.

18 Listas de comprobación
No. Preguntas Respuesta SI NO 1 ¿Se encuentran comentadas las clases? 2 ¿Se encuentran comentados los módulos? 3 ¿Se encuentran comentadas las funciones? 4 ¿Es insignificante el número de líneas de comentario que están en blanco? 5 ¿Los nombres de las variables, funciones y módulos son descriptivos de la propiedad física o funcional que representan? 6 ¿Se encuentran descritos todos los atributos y funciones del sistema? Criterio Auto Descripción Aquí se muestra un ejemplo de lista de comprobación en este caso del criterio Auto Descripción. Cada lista está integrada por un grupo de preguntas que van a estar determinadas por el objetivo que persiga el criterio en cuestión. Estas se responden de manera afirmativa o negativa (“SI”, “NO”) y tienen el propósito de sacar a la luz los problemas que puedan existir. Estos resultados se promedian y se obtiene un valor para el criterio objeto de evaluación.

19 Build 2014 8/28/2018 En el año 2013 se presentó la investigación “QSoft. Aplicación Web para gestionar el proceso de medición de la Calidad de Software“ (Pérez Téllez, 2013) Este trabajo plantea un sistema informático para medir la calidad de software que se realizan en la UHOLM, que sigue la metodología para medir calidad de software, con el uso del modelo de McCall y las listas de comprobación explicadas anteriormente © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

20 Principales funcionalidades
Build 2014 8/28/2018 Principales funcionalidades Automatización de la metodología Gestión del equipo de desarrollo Gestión de la información de los proyectos Gestión de los modelos Modelo de McCall ISO 9126 FURPS Gestión de factores, criterios y listas de comprobación © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

21 Proporciona la evidencia para emitir un certificado de calidad
Build 2014 8/28/2018 Proporciona la evidencia para emitir un certificado de calidad Proporciona la base de datos históricos Permite realizar comparaciones y hacer estudios de tendencias Es comercializable © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

22 Conclusiones Se hizo un estudio con los modelos más relevantes encontrados en la bibliografía y se escogió el modelo del McCall debido a que es el modelo más general, es adaptable a cualquier entorno y tipo de sistema, es sencillo de utilizar y se adecua a las necesidades de la FACINF que es un entorno académico y la mayoría de los sistemas que se producen. Se diseñó una metodología para la gestión de la calidad en el proceso de desarrollo de los sistemas informáticos, con énfasis en la gestión de riesgos informáticos, en la FACINF.

23 Conclusiones Se elaboraron las listas de comprobación para cada uno de los factores y criterios del Modelo de McCall para de esta forma minimizar la subjetividad en la medición de la calidad de un sistema informático. Se diseñó e implementó la herramienta QSoft que informatiza el proceso planteado en la metodología y que utiliza cada uno de los elementos mencionados.

24 Referencias bibliográficas
Álvarez, A. (2012). Los Atributos de Calidad del Software. QA : news, (10), 37. Berander, P., Damm, L., Eriksson, J., Gorschek, T., Henningsson, K., Jönsson, P., Kågström, S., et al. (2005). Software quality attributes and trade-offs. (L. Lundberg, M. Mattsson, & C. Wohlin, Eds.) (p. 100). Boehm, B. W., Brown, J. R., Kaspar, H., Lipow, M., McLeod, G., & Merritt, M. (1978). Characteristics of Software Quality. North Holland. De Antonio, A. (2004). GESTIÓN , CONTROL Y GARANTÍA DE LA CALIDAD DEL SOFTWARE. Dromey, R. G. (1995). A model for software product quality. IEEE Transactions on Software Engineering, (2), 146–163. Galin, D. (2004). Software Quality Assurance. From theory to implementation (Pearson Ed.). Harlow, England: Addison Wesley. IEEE. (1991). IEEE Std – IEEE Standard Glossary of Software Engineering Terminology. (The Institute of Electrical and Electronics Engineers, Ed.) (Corrected .). New York: IEEE Software Engineering Standards Collection.

25 Referencias bibliográficas
INTECO. (2009). Ingeniería de Software: Metodologías y ciclos de vida. Laboratorio Nacional de Calidad del Software. ISO/IEC. (2001). International Standard. ISO/IEC (2001), Part 1, 2, 3: Quality Model. Institute of Electrical and Electronics Engineering. Retrieved from Malhotra, N., & Pruthi, S. (2012). An Efficient Software Quality Models for Safety and Resilience. International Journal of Recent Technology and Engineering (IJRTE), 1(3), 66–70. Mccall, J. A., & Cavano, J. P. (1977). A FRAMEWORK FOR THE MEASUREMENT OF SOFTWARE QUALITY, 133–139. Moreno, J. J., Bolaños, L. P., & Navia, M. A. (2010). Exploración de Modelos y Estándares de calidad para el producto software. UIS Ingenierías. Revista de la Facultad de Ingenierías Fisicomecánicas, 0(1), 39–53. Odeh, A. H. (2012). SMSCQA : System for Measuring Source Code Quality Assurance. International Journal of Computer Applications, 60(8), 35–39. Pérez Téllez, J. D. (2013). QSoft. Aplicación Web para gestionar el proceso de medición de la Calidad de Software. Universidad de Holguín.

26 Referencias bibliográficas
Pressman, R. S. (2010). Ingeniería de Software. Un enfoque práctico. Sexta edición. (6ta ed., p. 980). McGraw-Hill. Ramírez Hidalgo, A. (2008). Confección de listas de comprobación para medir la calidad del software de los sistemas de gestión. Universidad de Holguín. Scalone, F. (2006). Estudio comparativo de los modelos y estandares de calidad del software. Universidad Tecnológica Nacional. Facultad Regional, Buenos Aires. Solano, H., & Torres, I. (2013). Análisis de frameworks para el desarrollo de aplicaciones móvilesen la plataforma Android. Universidad del Azuay. Thapar, S. S., Singh, P., & Rani, S. (2012). Challenges to the Development of Standard Software Quality Model. International Journal of Computer Applications, 49(10), 1–7. Waghmode, M. L., & Jamsandekar, P. P. (2013). Software quality models: a comparative study. AMS’s International E-Journal of Ongoing Research in Management and IT, 1–5.