Términos estándar

Glosario de términos

Términos del Proyecto	Términos estándar

Impacto del proceso: Este archivo contiene un diccionario de términos estándar definidos como se utilizan durante un proyecto. Los proyectos individuales no debería de haber necesidad de editar este documento. Escribir las definiciones de los términos y acrónimos que se encuentran aquí ayudan a mantener otros documentos más concisos y fáciles de editar.Vea ReadySET glossary para actualizaciones.

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:

Muchas de las plantillas cuentan con una sección con preguntas que ayudan a revisar su trabajo en esa plantilla. Normalmente las respuestas de ejemplo a las preguntas le indican que acciones correctivas tomar.
Para juntas de revisión de diseño o código, existen ligas a las guías y listas de pendientes que le ayudarán a identificar errores comunes en estos artefactos.

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:

TAREAS: Le indica cómo llear una plantilla. Este es el mínimo que necesita hacer. Uno de los principales objetivos de ReadySET es ayudar a su equipo a desarrollar rápidamente las actividades básicas de ingeniería de software. La notas de TAREAS facilitan esto haciendo las plantillas más auto-explicatorias.
SUGERENCIA: Le ayuda a pensa en mejores manera de llenar la plantilla. Uno de los otros principales objetivos de ReadySET es ayudar a su equipo a hacer mejores decisiones que pueden hacer su proyecto más exitoso. Las notas de SUGERENCIA ayudan con este objetivo.

Después de hacer lo que la nota asdherible dice, puede borrar la nota. En el archivo HTML están marcadas como class="sticky".

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: DEFINICIÓN 1
Registro de Mensajes de Submisiones: DEFINICIÓN 1
Control de versiones: DEFINICIÓN 1
Automatización de Pruebas Unitarias: DEFINICIÓN 1
Sistema de Compilación Automatizada: DEFINICIÓN 1
Herramienta de Análisis de Código Fuente: DEFINICIÓN 1
Revisor de Estilo: DEFINICIÓN 1
Formateador de Código Fuente (Pretty Printer): DEFINICIÓN 1
Automatizador de Pruebas de Sistema: DEFINICIÓN 1

Términos de Requerimientos

TÉRMINO 1: DEFINICIÓN 1

Términos de Diseño

TÉRMINO 2: DEFINICIÓN 2

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: n. Desaprobado desde 1991. Vea Falla.
Falla: n. 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: n. 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:

2004-2011 United Nations Development Programme