Tuesday, May 21, 2019

CONCLUSIONES


Conclusiones

La creciente preocupación por la calidad en la industria del software tiene como objetivo principal el desarrollo sistemático de productos y servicios de mejor calidad y el cumplimiento de las necesidades y expectativas de los clientes. En el presente artículo se hace una introducción a la calidad y al modelo de calidad adoptado por Colciencias, CMMI. Pretendemos unir esfuerzos con esta iniciativa y motivar a la comunidad académica a trabajar en calidad con las empresas desarrolladoras de software para mejorar la competitividad y la calidad global de esta industria.
Resumiendo, podemos decir, que la calidad de software se refiere a: Los factores de un producto de software que contribuyen a la satisfacción completa y total de las necesidades de un usuario u organización, cuando el interés en mejorar la calidad es el producto de software, se identifican un conjunto de atributos de software relevantes y se elabora un modelo de medición que establezca las relaciones entre las propiedades internas del producto de software y las propiedades externas. Las propiedades internas del software se evalúan en los distintos artefactos del software que, por su naturaleza, no pueden ser ejecutados (el código fuente también puede ser analizado estáticamente). Por ejemplo, el modelo de arquitectura del software se puede evaluar según los requisitos de calidad establecidos. El código fuente se puede evaluar según su facilidad para ser modificado, sin que sea necesaria su ejecución.
Entonces podemos concluir que la calidad del software nos ayuda a estar seguros a nosotros como clientes de que adquirimos un producto o servicio que cumple con los estándares de la calidad más alta y que estamos de cierta manera protegidos ante cualquier fallo o desperfecto.

PRESENTACIÓN


UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO

Resultado de imagen para umb 




Barona Araujo Jeovanny (@bvronv.vj)
Zuñiga Sánchez Alejandro Víctor (@viczuni)


Profra. Mabilia Romero Guevara


Calidad del Software

Grupo: 15LI161

Matutino

Trabajo Final

Wednesday, May 15, 2019

4.9. Funciones de Evaluación del Software

Las técnicas de evaluación estática se aplican en el mismo orden en que se van generando los distintos productos del desarrollo siguiendo una filosofía top-down. Esto es, la evaluación estática acompaña a las actividades de desarrollo, a diferencia de la evaluación dinámica que únicamente puede dar comienzo cuando finaliza la actividad de codificación, siguiendo así una estrategia botomup.
La evaluación estática es el único modo disponible de evaluación de artefactos para las primeras fases del proceso de desarrollo (análisis y diseño), cuando no existe código.


Así pues, la importancia de las técnicas estáticas de evaluación a la hora de controlar el nivel de calidad con el que se está llevando a cabo el desarrollo es crucial.
, la estimación de faltas que aún quedan en un producto utilizando datos de las revisiones permite dos acciones que ayudan a prevenir futuros defectos en el proyecto:
. Seguir revisando el producto para disminuir el número de faltas remanentes.
. Tomar medidas correctivas del desarrollo si las estimaciones indican que se está llevando a cabo un trabajo pobre. Es decir, si las estimaciones de faltas.

4.8. Análisis de Proceso de Ciclo Vida del Software

Etapas en el ciclo.
Veamos, a grandes rasgos, una pequeña descripción de etapas con que podemos contar a lo largo del ciclo de vida del software.
Expresión de necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial).
Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).
del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).
Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, … que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
• Funcional.
• Estático.
• Dinámico.
Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).
Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.
Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).
Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos
Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

4.7. Análisis de Factores que Determinan la Calidad Software

Los factores que determinan la calidad se pueden clasificar en 2 grandes grupos:
1- Factores que se pueden medir directamente (Ej. errores / unidad de tiempo)
2- Factores que sólo pueden ser medidos indirectamente (Ej. facilidad de mantenimiento)
En ambos casos, se puede obtener una medida. Pero estas medidas deben ser comparadas con alguna referencia o indicador para poder llegar a una indicación de la realidad
Mc Call clasifica los factores de calidad en:
1- Características Operacionales
2- Capacidad de Soportar Cambios
3- Adaptabilidad a nuevos entornos
1- Características Operacionales
• Corrección
Es el grado en que un programa satisface sus especificaciones y consigue los objetivos pedidos por el cliente. Este factor tiene una pregunta asociada: ¿Hace lo que quiero?
• Confiabilidad
Es el grado en que se puede esperar que un programa lleve a cabo sus funciones esperadas con la precisión requerida. La pregunta asociada a este factor sería: ¿Lo hace de forma fiable todo el tiempo?
• Eficiencia
La cantidad de recursos de computadoras y de código requeridos por un programa para llevar a cabo sus funciones. La pregunta asociada a este factor sería: ¿Se ejecutará en mi hardware lo mejor que pueda?
2- Capacidad de Soportar Cambios
• Facilidad de Mantenimiento
• Es el esfuerzo requerido para localizar y arreglar un error en un programa. La pregunta asociada a este factor sería: ¿Puedo corregirlo?
• Flexibilidad
Es el esfuerzo requerido para modificar un programa operativo. La pregunta asociada a este factor sería: ¿Puedo cambiarlo?
• Facilidad de Prueba
• Es el esfuerzo requerido para probar un programa de forma que se asegure que realiza su función requerida. La pregunta asociada a este factor sería: ¿Puedo probarlo?
3- Adaptabilidad de nuevos entornos
• Portabilidad
Es el esfuerzo requerido para transferir el programa desde un hardware y/o un entorno de sistema de software a otro. Este factor tiene una pregunta asociada: ¿Podré usarlo en otra máquina?
• Reusabilidad
Es el grado en que un programa (o partes de este) se pueden rehusar en otras aplicaciones. Este factor tiene una pregunta asociada: ¿Podré rehusar alguna parte del software?
• Facilidad de Interoperación
• Es el esfuerzo requerido para acoplar un sistema a otro. Este factor tiene una pregunta asociada: ¿Podré hacerlo interactuar con otro sistema?
2- Métricas de Calidad
Es difícil desarrollar medidas directas de los anteriores factores de calidad. Por eso, se definen un conjunto de métricas para cada uno de los factores de calidad. Generalmente estas métricas definidas por MacCall solo pueden ser medidas en forma subjetiva.
Las métricas pueden estar listas de comprobaciones para obtener el grado de los atributos específicos del software. El esquema de graduación propuesto por McCall va en una escala de 0 (bajo) a 10 (alto).
En este esquema se usan las siguientes métricas:
• Facilidad de Auditoria
• La facilidad con que se puede comprobar la conformidad con los estándares
• Exactitud
La precisión de los cálculos y el control
• Normalización de las Comunicaciones
• El grado en que se usan el ancho de banda, los protocolos y las interfaces estándar
• Completitud
El grado en que se ha conseguido la total implementación de las funciones requeridas
• Concisión
Lo compacto que es el programa en términos de líneas de código
• Consistencia
El uso de un diseño uniforme de técnicas de documentación a los largo del proyecto de desarrollo de software
• Estandarización en los datos
• El uso de estructuras de datos de tipos estándar a lo largo de todo el programa
• Tolerancia de Errores
• El daño que se produce cuando el programa encuentra un error
• Eficiencia en la Ejecución
• El rendimiento en tiempo de ejecución de un programa
• Facilidad de expansión
• El grado en que se puede ampliar el diseño arquitectónico de datos o procedural
• Generalidad
La amplitud de aplicación potencial de los componentes del programa
• Independencia del Hardware
• El grado en que el software es independiente del hardware en que opera
• Instrumentación
El grado en que el programa muestra su propio funcionamiento e identifica errores que aparecen
• Modularidad
La independencia funcional de los componentes del programa
• Facilidad de Operación
• La facilidad de operación de un programa
• Seguridad
La disponibilidad de mecanismos que controlen o protejan los programas o datos
• Auto-Documentación
El grado en que el código fuente proporciona documentación significativa

4.6. La Norma ISO/IEC 9126

ISO/IEC 9126-1: Tecnología de dotación lógica – calidad del producto
ISO/IEC 9126 (1991) ha sido substituido recientemente por un nuevo estándar de cuatro partes que ha reconciliado los dos acercamientos a la utilidad. ISO/IEC 9126-1 describe las mismas seis categorías de la calidad del software que son relevantes durante el desarrollo de producto: funcionalidad, confiabilidad, utilidad, eficacia, capacidad de mantenimiento y portabilidad.
calidad del software cuando el producto es funcionando. El objetivo total es alcanzar la calidad funcionando, para el usuario final y el usuario de la ayuda.
La funcionalidad, la confiabilidad, la eficacia y la utilidad determinan la calidad funcionando para un usuario final en un contexto particular. El usuario de la ayuda se refiere a la calidad funcionando de tareas del mantenimiento y de la portabilidad.

4.5. Nomenclatura y Certificación Iso 9001 2000

La norma ISO 9001, es un método de trabajo, que se considera tan bueno, Que es el mejor para mejorar la calidad y satisfacción del consumidor.
La versión actual, es del año 2000 ISO 9001:2000, que ha sido adoptada como modelo a seguir para obtener la certificación de calidad por todas las empresas.
Estos principios básicos de la gestión de la calidad, son reglas de carácter social encaminadas a mejorar la marcha y funcionamiento de una organización mediante la mejora de sus relaciones internas.
La certificación en la norma 9001, es un documento con validad legal que acredita y que certifica, que usted cumple las más estrictas normas de calidad, en aras a una mejora de la satisfacción del cliente.
Hay dos tipos de certificaciones, de empresa y de producto. Estas últimas, solo tienen en cuenta la calidad técnica del producto. Y no la satisfacción del cliente, de la que se ocuparía la certificación de empresa. Si una empresa está certificada, todos sus productos lo están.