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.

Vaya a: Generales | Procesos | Herramientas de Desarrollo de Software | Requierimientos | Diseño | Metas de Diseño | Términos de QA | Objetivos de QA | Términos Adicionales
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:

Dictionary.com (Diccionario.com)
Whatis.com (Quées.com)
Diccionario NIST de Algoritmos y Estructuras de Datos
Diccionario gratuito en línea de computación
Glosario IBM de términos de computación
Archivos Jargon