lunes, 19 de enero de 2015

GESTIÓN DE LA CALIDAD DEL SOFTWARE



Fecha de clase: Lunes, 19 de enero del 2015


INTRODUCCIÓN

En esta clase se trató sobre la gestión de la calidad de los proyectos de software ya esta es la cualidad que caracteriza al software si es de calidad si es eficiente si es confiable y así un sin número de cualidades que van a corroborar que nuestro software está en perfecto estado.


MARCO TEÓRICO

GESTIÓN DE CALIDAD
Uno de los problemas que se afrontan actualmente en la esfera de la informática es el proceso de la calidad del software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comercializadores de software.
La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, portabilidad, usabilidad, seguridad e integridad.
En términos generales la calidad de software puede definirse como el grado en que un conjunto de características inherentes al software cumple con unos requisitos explícitos e implícitos.
La implantación de un sistema de calidad en una organización ayuda a mejorar la gestión del desarrollo de software, y esto traerá como consecuencia una disminución de los problemas y errores, favoreciendo las relaciones y comunicación entre las personas y grupos de organización, y de éstos con los clientes.
La gestión de la calidad va tomando cada día mayor importancia en el ámbito del desarrollo de software. De esta forma, los esfuerzos encaminados a integrar la gestión de la calidad dentro de la gestión de los proyectos deben generar también un aumento de la productividad.

Gestión de la calidad de software: Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como:

      1. Planificación de la Calidad del Software.
      2. Control de la Calidad del Software.
      3. Aseguramiento de la Calidad del Software.
      4. Mejora de la Calidad del Software




La Planificación de la Calidad del Software
Es la parte de la Gestión de la Calidad encargada de realizar el proceso administrativo de desarrollar y mantener una relación entre los objetivos y recursos de la organización; y las oportunidades cambiantes del mercado.
El objetivo es modelar y remodelar los negocios y productos de la empresa, de manera que se combinen para producir un desarrollo y utilidades satisfactorias.
En la Planificación de la Calidad de Software se debe determinar:
·         Rol de la Planificación.
·         Requerimientos de la Calidad de Software.
·         Preparación de un Plan de Calidad de Software.
·         Implementación de un Plan de Calidad de Software
·         Preparar un Manual de Calidad.
El Control de la Calidad del Software
Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad. Son las inspecciones, revisiones y pruebas para asegurar la calidad del producto centradas en 2 objetivos fundamentales:
·         Mantener bajo control un proceso.
·         Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
El Aseguramiento de Calidad del Software
Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Se trata de una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería del software.
Se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El aseguramiento de la calidad del software engloba:
·         Un enfoque de gestión de calidad.
·         Métodos y herramientas de Ingeniería del Software.
·         Revisiones técnicas formales aplicables en el proceso de software.
·         Una estrategia de prueba multiescala.
·         El control de la documentación del software y de los cambios realizados.
·         Procedimientos para ajustarse a los estándares de desarrollo del software.


La Mejora de la Calidad del Software
Es la parte de la Gestión de la Calidad que contribuye, por medio de las mediciones, a los análisis de los datos y auditorías, a efectuar mejoras en la calidad del software.
Las auditorías según el estándar ISO 19011:2002 se define como: proceso sistemático, independiente y documentado para evaluar el estado actual (evidencias de la auditoría) y evaluarlas de manera objetiva con el fin de determinar la extensión en que se cumplen los criterios de auditoría.
Una Auditoría de Calidad tiene como objetivo:
·         Mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza.
·         Suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos. (Corujo, H).
DIMENSIONES DE LA CALIDAD DE GARVIN
David Garvin sugiere que la calidad debe tomarse en cuenta, adoptando un punto de vista multidimensional que comience con la evaluación de la conformidad y termine con una visión trascendental (estética). Aunque las ocho dimensiones de Garvin de la calidad no fueron desarrolladas específicamente para el software, se aplican a la calidad de éste:
Calidad del desempeño. ¿El software entrega todo el contenido, las funciones y las características especificadas como parte del modelo de requerimientos, de manera que da valor al usuario final?
Calidad de las características. ¿El software tiene características que sorprenden y agradan la primera vez que lo emplean los usuarios finales?
Confiabilidad. ¿El software proporciona todas las características y capacidades sin fallar? ¿Está disponible cuando se necesita? ¿Entrega funcionalidad libre de errores?
Conformidad. ¿El software concuerda con los estándares locales y externos que son relevantes para la aplicación? ¿Concuerda con el diseño de facto y las convenciones de código? Por ejemplo, ¿la interfaz de usuario está de acuerdo con las reglas aceptadas del diseño para la selección de menú o para la entrada de datos?
Durabilidad. ¿El software puede recibir mantenimiento (cambiar) o corregirse (depurarse) sin la generación inadvertida de eventos colaterales? ¿Los cambios ocasionarán que la tasa de errores o la confiabilidad disminuyan con el tiempo?
Servicio. ¿Existe la posibilidad de que el software reciba mantenimiento (cambios) o correcciones (depuración) en un periodo de tiempo aceptablemente breve? ¿El equipo de apoyo puede adquirir toda la información necesaria para hacer cambios o corregir defectos?
Estética. No hay duda de que todos tenemos una visión diferente y muy subjetiva de lo que es estético. Aun así, la mayoría de nosotros estaría de acuerdo en que una entidad estética posee cierta elegancia, un flujo único y una “presencia” obvia que es difícil de cuantificar y que, no obstante, resulta evidente. El software estético tiene estas características.
Percepción. En ciertas situaciones, existen prejuicios que influirán en la percepción de la calidad por parte del usuario. Por ejemplo, si se introduce un producto de software elaborado por un proveedor que en el pasado ha demostrado mala calidad, se estará receloso y la percepción de la calidad del producto tendrá influencia negativa. (Pressman, R).

CONCLUSIÓN

En el mundo del mercado y especialmente en el mercado de software la calidad a dejado de ser solo algo que se queda a un lado a ser algo indispensable y necesario para los productos y servicios que comercialicemos a nuestros clientes ya que estos son los mejores críticos de la calidad y el elige cuanto está dispuesto a pagar por ella es por esto que debemos llevar a cabo todos los pasos para la gestión de la calidad.


BIBLIOGRAFÍA

Corujo, H. 2010. Gestión de la calidad. (En línea). Formato HTML. Consultado 06 de feb. 2015. Disponible en: http://www.liderdeproyecto.com/articulos/gestion_de_la_calidad.html

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición. Capitulo 14.


lunes, 12 de enero de 2015

DIAGRAMA DE ESTRUCTURA: CLASES


Fecha de clase: Lunes, 12 de enero del 2015



INTRODUCCIÓN

En esta clase aprendimos a utilizar los diagramas de clases ya que estas son una descripción visual de cómo se representan los modelos de objetos, además se aprendió a reconocer y a usar los íconos que se usan en las clases. Una clase es una abstracción  de la vida real y se representa como una caja y a su ves se subdivide en tres partes.


MARCO TEÓRICO

DIAGRAMA DE CLASES

Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.
En ¨, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo. (Kde).



ATRIBUTOS Y MÉTODOS:
  • Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:
    • public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
    • private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).
    • protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).
  • Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:
    • public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
    • private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).
    • protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). (Salinas, P).
RELACIONES ENTRE CLASES

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).


Agregación:   
Representa una relación parte todo entre dos clases. Muestra que el objeto agregado está físicamente construido a partir de otro objeto, o que lógicamente lo contiene


Asociación :  
Representa una conección semántica entre dos clases. La asociación es bidireccional, es la relación más general y la más débil semánticamente.


Dependencia o Instanciación (uso): 
Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana está condicionado a la instanciación proveniente desde el objeto Aplicacion). (Berzal, F).






CONCLUSIÓN

Los diagrama de estructura son importantes ya que son utilizados para estructurar problemas y así llevarlo a una solución clara y precisa, y así de esta manera, solucionar el problema de una manera gráfica, esta persona puede escoger tanto el diagrama de forma de comportamiento o de estructura y esto se elige de acuerdo a lo que si mismo requiere o necesita.


BIBLIOGRAFÍA

Berzal, F. 2010. Relaciones entre clases. (En línea). Formato PDF. Consultado 06 de feb. 2015. Disponible en: http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

Kde. Elemtos UML. (En líea). Formato HTML. Consultado 06 de feb. 2015. Disponible en: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html

Kendall,K ; Kendall,J. 2011. Analisis y diseño de sistemas. Octava edición. Cap- 10. (Libro Digital.)


Salinas, P. Modelo de clases. (En línea). Formato HTML. Consultado 06 de feb. 2015. Disponible en: http://users.dcc.uchile.cl/~psalinas/uml/modelo.html