logo

WikiJuanan: GlosarioCalidadSoftware ...

Inicio | Indice De Paginas | Ultimas Modificaciones | Ultimos Commentarios | Usuarios | Registrarse | Conectar:  Contraseña:  

Calidad Del Software


Copiado de http://readyset.tigris.org/nonav/es/templates/glossary-std.html


Términos Generales


Esculpiendo

El proceso de remover el texto de ejemplo de las plantillas cuando el texto no aplica al proyecto actual. Con frecuencia partes del texto de ejemplo serán mantenidas o evaluadas para encajar con el proyecto actual. Incluso si el texto de ejemplo no encja en el contexto del proyecto actual, provee un ejemplo reutilizable de cómo redactar ese tipo de descripción. El término “esculpir” viene de una vieja broma: cuando a un escultor se le pregunta cómo a realizado una estatua de mármol de un caballo, él contesta «Fue muy fácil, solo empecé con un enorme bloque de mármol y le fui quitando todo lo que no parecía parte del caballo.”

Formas adjuntas

La idea es similar al llenado de las formas de impuestos utilizando formas para calcular subtotales y realizar decisiones específicas. En pocas palabras, hay una jerarquía en las plantillas: están las plantillas principales y las formas para temas específicos. Hemos dividido la información en varios archivos para que cada archivo se enfoque a un tema, y para que cada archivo pueda ser trabajado por una persona en un periodo de tiempo razonable.

Impacto del Proceso

La caja de impacto del proceso explica en que parte del proceso de desarrollo de software encaja cada plantilla. Normalmente esta caja incluye un breve comentario sobre quién debe crear el documento, y quien debería utilizarlo. Ud. puede cambiar la caja de impacto en el proceso, pero no debería ser necesario.

Listas de Pendientes

Existen dos clases de listas de pendientes:


Nota Adherible

La idea es similar a un post-it adherido a un documento que le indica «firme aquí» o que llene ciertas partes. Existen dos clases de notas adheribles:


Términos de Procesos


Equipo de Control de Cambios (CCB)

Un grupo de personas de evalúan los cambios propuestos a los requerimientos del proyecto y/o al código fuente para aceptar o rechazarlos en cada entrega en particular. Los cambios propuestos son generalmente rechazados si introducen muchos riesgos o pudieran disparar esfuerzo adicional (por ejemplo, la necesidad de rehacer muchas más pruebas en código nuevo). Un CCB normalmente está compuesto de coordinadores y representantes de área, como del grupo de QA y enlaces con clientes.

Característica Completa

Una entrega se le llama «Característica Completa» cuando el equiipo de desarrollo acuerda que no se le añadirán nuevas características a esta entrega. Las nuevas características pueden sugerirse para nuevas entregas. Se necesita trabajar más para implementar todas las características y arreglar las fallas.

Código Completo

Una entrega es llamada «código cmpletop» cuando el equipo de desarrollo acuerda en que no se le añadirá código fuente nuevo a esta entrega. Puede que aún haya cambios en el código fuente para arreglar fallas. Es posible también que haya cmabios en la documentación y el los archivos de datos, y a el código para escenarios de pruebas o utilerías. El código nuevo se añadirá en una entrega futura.

Herramientas de Desarrollo de Software


Sistema de Control de Versiones

Registro de Mensajes de Submisiones


Control de versiones


Automatización de Pruebas Unitarias


Sistema de Compilación Automatizada


Herramienta de Análisis de Código Fuente


Revisor de Estilo


Formateador de Código Fuente (Pretty Printer)


Automatizador de Pruebas de Sistema


Objetivos de Diseño


Corrección

El diseño se ajusta correctamente a los requerimientos dados.

Viabilidad

Este diseño puede ser implementado y probado con las cantidades de tiempo y esfuerzo planeadas.

Comprensibilidad

Los desarrolladores pueden enteder este diseño e implementarlo correctamente

Guías de Implementación por Etapas

Este diseño divide la implementación en componentes o aspectos que pueden corresponder a tareas de implementación razonables.

Modularidad

Los objetivos estan claramente separadados para que el impacto de la mayoría de los cambios del diseño puedan limitarse a solo uno o algunos módulos.

Extensibilidad

Nuevas características o componentes pueden ser añadidos después fácilmente.

Capacidad de Prueba

Es fácil probar los componentes de este diseño independientemente, y la información está disponible para ayudar a diagnosticar fallas.

Eficiencia

El diseño permite al sistema realizar funciones con aceptables cantidad de tiempo, espacio de almacenamiento, ancho de banda y otros recursos.

Facilidad de integración

Los componentes trabajarán juntos.

Ajuste a la Capacidad

La arquitectura genera componentes en equipos que proveen los recursos necesarios con un gasto toal razonable.

Expresividad

Permite almacenamiento de todos los valores válidos y relaciones

Facilidad de acceso

El código de la aplicación para accesar los datos almacenados es sencillo

Confiabilidad

Los datos almacenados no puden ser corrompidos fácilmente por código defectuosos, accesos simultáneos, o finalización inesperada de los procesos

Capacidad de Datos

El sistema puede almacenar la cantidad de información necesaria.

Seguridad en los Datos

Protección de los datos sensibles del usuario o de la empresa a los accesos no autorizados o a modificación

Desempeño

La información puede ser accesada rápidamente

Interoperabilidad

La base de datos o los archivos de datos pueden ser accesados o actualizados por otras aplicaciones

Prevención a Intrusos

Prevenir, por ejemple, que hackers puedan abrir una terminal de comandos en nuestro servidor.

Prevención contra el Abuso

Prevenir el abuso (por ejemplo, usar nuestro sistema para enviar spam).

Auditabilidad

Todos los cambios pueden ser identificados después.

Comprensibilidad y Capacidad de Aprendizaje

Se puede esperar que loos usuarios puedan entender la interfaz a primera vista. Los usuarios podrán encontrar información a características adicionales sin ayuda de otros usuarios o documentación, y serán capaces de recapitular lo que han aprendido.

Soporte a Tareas y Eficiencia

La interfaz del usuario encaja con las tareas del usuario realizará y puede ser usada con un número razonable de clicks y teclazos.

Seguridad

Los usuarios no podrán ser capcaces de producir un resultado no deseado (por ejemplo, borrar información, o enviar correos incompletos).

Consistencia y Familiaridad

Los usuarios podrán aplicar su conocimientos de interfaces similares o interfaces estándar a este sistema.

Términos de QA


Bug

    1. Desaprobado desde 1991. Vea Falla.

Falla

    1. Un elemento de la implementación de un programa que produce un error cuando es ejecutado, o que viola los estádares de desarrollo, por ejemplo, si el programa genera un error donde cuando intenta realizar una división por cero, el defecto está en las expresiones matemáticas en el código fuente, o el la estructura de la lógica de control que permitieron que la expresión fuera evaluada a pesar de sus parámetros. Las fallas pueden también existir en los datos iniciales, la documentación o en otros artefactos de soporte.

Error

    1. La diferencia observable entre la salida esperada del programa y la salida real, por ejemplo, podemos ver un error cuando el programa termina abruptamente o imprime un total equivocado. No todos las fallas provocan errores, algunas fallas pueden nunca ser descubiertas en las pruebas, pero todas los errores son causados por alguna falla.

Metas de QA


Functionalidad > Corrección

Corrección es el objetivo de calidad más básico. Significa que, cuando una entrada válida es dada y el sistema se encuentra en un estado válido y bajo una carga razonable, el comportamiento del sistem y sus resultados serán correctos.

Functionalidad > Robustez

La robustez es la habilidad del sistema para manejar elegantemente entradas inválidas. No debería ser posible para ninguna entrada del usuario abortar el sistema o corromper la información, incluso si la entrada del suaurio en anormal, inesperada, o maliciosa.

Functionalidad > Exactitud

La exactitud se refiere a la precisión matemática de los cálculos hechos por el sistema. Cualquier sistema que realice cálculos numéricos debe considerar la exactitud; por ejemplo, aplicaciones financieras o científicas.

Functionalidad > Compatibilidad

Los sistemas que aseguran que siguen estádares o proclaman cierta compatibilidad con sistemas existentes deberán adherirse a los protocolos relevantes de formatos de archivos y APIs. Se encontrarán ligas a los estándares relevantes en la parte de arriba de este documento.

Functionalidad > Corrección Verdadera

¿Los datos en el sistema una representación del mundo real? Cualquier sistema que contiene datos iniciales o recopila información acerca el mundo real debería asegurarse de que los datos son verdaderos. Por ejemplo, un programa de preparación de impuestos debería incluir datos correctos y actualizados sobre la ley de impuestos.

Usabilidad > Comprensibilidad e Legibilidad

Los usuarios necesitan entender el sistema para usarlo. La metáfora básica debrá ser comprensible y apropiada para las necesidades del usuario. Algunas fallas en la comprensibilidad incluyen metáforas poco claras, etiquetas pobres o difíciles de ver, falta de retroalimentación para confirmar los efectos de las acciones del usuario, y falta de ayuda o ayuda inadecuada en línea.

Usabilidad > Intituividad y Memorabilidad

Cada interfaz de usuario contiene algunos detalles que los usuarios necesitarán aprender y recordar. Por ejemplo, Alt-A para abrir el menú “Archivo”. Las reglas de la interfaz del usuario pueden hacer estos detalles más fácil de aprender y recordar. Por ejemplo, la “A” está subrayada y, como regla, la primera letra es normalmente la tecla de acceso rápido.

Usabilidad > Apoyo para Tareas

Esta es la calidad de la interacción entre las tareas que realiza el usuario y la interfaz del sistema. Los defectos de soporte en el apoyo para tareas son casos donde el sistema forza al usuario a realizar pasos poco naturales para realizar una tarea o donde el usuario carece de soporte para un paso difícil en una tarea. Por ejemplo, ¿debería el usuario inventar un nombre de 8 caracteres para su “lista de tarjetas de Navidad”? Otro ejemplo, ¿deberían los usuarios sumar ellos mismos sus deducciones de impuestos?

Usabilidad > Eficiencia

Los usuarios deberían ser cpaces de realizar tareas comunes con un esfuerzo razonable. Las tareas comunes deberían ser posibles con solo uno o dos pasos. La dificultad de cada paso debería ser también considerada Por ejemplo, ¿el usuario tiene que recordar una clave larga o dar click en un botón muy pequeño?

Usabilidad > Seguridad

Las personas somos propensos a equivocarnos, pero los efectos negativos de errores comunes debería se limitado. Por ejemplo, los usuarios deberían darse cuenta que un comando dado borrará su información, y debería ser consultado para confirmar acción, o tener una opción para deshacer.

Usabilidad > Consistencia y Familiaridad

Los usuarios deberían de ser capaces de utilizar su experiencia previa en otros sistemas similares. Es significa que los estándares para interfaces de usuario deberían ser seguidos, y las convenciones más comunes deberían ser usados cuando sea posible. Además, los elementos que aparecen en varias partes de la interfaz deberían ser usados de forma consistente a menos que otra convención para UI tenga prioridad. Por ejemplo si la mayoría de los campos de entrada para moneda no requieren un signo de moneda, entonces el que lo necesita es un error de consistencia, a menos que que exista una oportunidad real de que el usuario este trabajando con otro tipo de cambio en ese paso de la tarea.

Usabilidad > Satisfacción Subjetiva

Los usuarios deberían sentirse generalmente satisfechos con la interfaz del usuario. Esta calidad subjetiva se suma a las otras cualidades de la interfaz así como su estética.

Securidad

El sistema debería permitir se usado solo por usuarios autorizados, y restringir el uso basado en permisos. El sistema no debería permitir a los usuarios saltarse las reglas de seguridad o utilizar agujeros en la seguridad. Por ejemplo, todas las entradas de los usuarios deberían ser validadas y cualquiera entrada maliciosa debería ser rechazada.

Confiabilidad > Consistencia sobre carga

Todo sistema tiene límites de capacidad. ¿Qué pasa cuando estos límites son excedidos? El sistema no debería jamás perder o corromper la información.

Confiabilidad > Consistencia bajo concurrencia

Los sistemas que permiten accesos simultáneos por usuarios múltiples, o los que usan concurrencia internadebería estar libres de de condiciones de carrera y bloqueo.

Confiabilidad > Disponibilidad bajo carga

Todo sistema tiene límites de capacidad. ¿Qué pasa cuando estos límites son excedidos? El sistema debería de continuar sirviendo aquellas solicitudes que es capaz de manejas. No debería caerse o detener el proceso de todas las solicitudes.

Confiabilidad > Longevidad

El sistema debería continuar operando tanto como lo necesite. No debería gradualmente terminarse los recursos disponibles. Ejemplos de defectos de longevidad inluyen fugas de memoria o el agotamiento de espacio en discos con archivos de registro.

Eficiencia

La soperaciones del sistema deberían ejecutarse rápidamente, con un uso razonable de los recursos del equipo y de la red. Por ejemplo, si un usuario realiza una operación, esta debería ejecutarse eficientemente.

Escalabilidad

Escalabilidad es una cualidad general que se mantiene cuando el sistema continua satisfaciendo sus requerimientos en situaciones en que sus parámetros se han incrementado. Por ejemplo, un servidor de archivos debería ser escalable a un gran número de usuarios, a archivos muy grandes, o a discos de muy alta capacidad. Algunos objetivos específicos de escalabilidad se enumeran abajo.

Escalabilidad > Desempeño bajo carga

Este es un tipo específico de objetivo de escalabilidad involucrado con el desempeño del sistema en momentos en que sus servicios son tienen muchas solicitudes de muchos usuarios.

Escalabilidad > Volumenes grandes de datos

ste es un tipo específico de objetivo de escalabilidad involucrado con la habilidad del sistema para manejar grandes volúmenes de datos. Las operaciones deberían de continuar correcta y eficientemente aunque el tamaño del volumen de datos aumente. Más aún, la interfaz del usuario debería ser aún utilizable según la información presentada a los usuarios incremente en longitud.

Operabilidad

Las necesidades a largo plazo de los administradores del sistema deberían ser apoyadas confiablemente. por ejemplo, ¿es el sistema fácil de instalar? ¿Puede el administrador recuperarse de una caída? ¿Existen suficientes datos en el registro para diagnosticar problemas en el campo? ¿Pueden los datos del sistema ser respaldados sin bajas en el desempeño? ¿Puede el sistema ser actualizado de forma práctica?

Capacidad de mantenimiento > Comprensibilidad

¿Sería fácil para los (futuros) desarrolladores entender cómo el sistema funciona?

Capacidad de mantenimiento > Evolutividad

¿Puede el sistema ser fácilmente modificado y extendido en el futuro?

Capacidad de mantenimiento > Capacidad de prueba

¿Puede el sistema ser probado? ¿Los requerimientos especifican de forma precisa posibles entradas y resultados deseados? ¿Puede el sistema ser probado por partes? ¿Cuando se observan fallas, pueden ser rastreadas hasta las fallas en los componentes específicos (depuración)? ¿La realización de pruebas son prácticas con las herramientas de prueba disponibles?

Términos Estándar Adicionales


Para términos estándar adicionales, vea los siguientes sitios de referencia:



Compañía Propietaria. Copyright © 2003 Jason Robbins. Todos los derechos reservados. Términos de la Licencia. Mantenga esta leyenda derechos donde utilice este archivo como plantilla – Traducción al español por Interplanet, México, D.F.

No hay archivos en esta página. [Enseñar archivos/formulario]
Comentarios [Esconder comentarios/formulario]