PROYECTO DE CONSTRUCCION

DE SOFTWARE

ESTANDARES DE CODIFICACIÓN E INTERFAZ

¿QUE ES UN ESTANDAR DE CALIDAD?

Un estándar es un documento establecido por consenso,

aprobado por un cuerpo reconocido, y que ofrece reglas,
guías o características para que se use
repetidamente.

Organización Internacional de la Estandarización - ISO

CODIFICACIÓN (Cortes, 1994)

Es el paso en el que las labores anteriores de ingeniería,

en especial el diseño, se plasman en un lenguaje que entienda
la máquina.

3
ESTANDARES DE CODIFICACIÓN

Son buenas practicas para mejorar la eficiencia y la

calidad del software, sin embargo su uso no incide
en la funcionalidad del mismo.
CARACTERISTICAS A TENER EN CUENTA DE
LOS ESTANDARES DE CODIFICACIÓN

• Nombres de variables
• Indentación
• Comentarios
• Espaciado
• Bucles
• Etc
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

Nombres de variables

• La elección apropiada de los nombres de las

Variables es factor determinante para un buen
estándar.
Ejemplo:

•Correctos: diaCalculo, fechaIncoporacion
  •Incorrectos: dC, DCal, fI, FI¿
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

Indentación
Las normas de indentación indican la posición en la
que se deben colocar los diferentes elementos que
se incluyen en el código fuente.
Ejemplo:
Usar esto..
 

En vez de esto..
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

Comentarios
Los comentarios se usan para dar información
adicional al desarrollador sobre la implementación
del diseño de la clase, no para dar referencias del
diseño funcional de la misma.

 
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

Declaraciones de CONSTANTES
Los nombres de constantes deben escribirse de una
manera tal que se diferencien de una variable, por
ejemplo:
public static final String PROPERTY_SERVICIO = “StarService";

 
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

ESPACIADO
El adecuado uso del espaciado en la disposición del
código es catalogado un buen estilo de
programación.
int count; for(count=1;count<50;++)
{printf("%d",count*count+count);}

int count;
for (count= 0; count< 10; count++)
 {
printf("%d", count* count+ count);
}
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

ESPACIADO
El adecuado uso del espaciado en la disposición del
código es catalogado un buen estilo de
programación.
int count; for(count=1;count<50;++)
{printf("%d",count*count+count);}

int count;
for (count= 0; count< 10; count++)
 {
printf("%d", count* count+ count);
}
 CARACTERISTICAS DE LOS ESTANDARES
DE CODIFICACIÓN

ESPACIADO
El adecuado uso del espaciado en la disposición del
código es catalogado un buen estilo de
programación.
int count; for(count=1;count<50;++)
{printf("%d",count*count+count);}

int count;
for (count= 0; count< 10; count++)
 {
printf("%d", count* count+ count);
}
 ESTANDAR DE CODIFICACIÓN DE JAVA

NOMBRES DE ARCHIVOS
 ESTANDAR DE CODIFICACIÓN DE JAVA

COMENTARIOS DE COMIENZO

Todos los archivos fuente deben comenzar con un comentario en el que se

lista el nombre de la clase, información de la versión, fecha, y copyright:
 ESTANDAR DE CODIFICACIÓN DE JAVA
DECLARACIONES DE CLASES E INTERFACES
Partes de la declaración de una clase o interface
1 Comentario de documentación de la clase o interface
(/**...*/)
2 Sentencia class o interface
3 Comentario de implementación de la clase o
interface si fuera necesario (/*...*/)
4 Variables de clase (static)
5 Variables de instancia
6 Constructores
7 Métodos
OBSERVACIONES
Este comentario debe contener cualquier información
aplicable a toda la clase o interface que no era
apropiada para estar en los comentarios de
documentación de la clase o interface.
Primero las variables de clase public, después las
protected, después las de nivel de paquete (sin
modificador de acceso) , y despúes las private.
Primero las public, después las protected, después las
de nivel de paquete (sin modificador de acceso), y
después las private
Estos métodos se deben agrupar por funcionalidad
más que por visión o accesibilidad
 ESTANDAR DE CODIFICACIÓN DE JAVA

INDENTACIÓN

• Longitud de la línea:
Evitar las líneas de más de 80 caracteres, ya que no son manejadas bien por
muchas terminales y herramientas

• Rompiendo líneas
Cuando una expresión no entre en una línea, romperla de acuerdo con estos
principios: · Romper después de una coma.
o Romper antes de un operador.
o Preferir roturas de alto nivel (más a la derecha que el "padre") que de
bajo nivel (más a la izquierda que el "padre").
o Alinear la nueva linea con el comienzo de la expresion al mismo nivel de
la linea anterior.
o Si las reglas anteriores llevan a código confuso o a código que se aglutina
en el margen derecho, indentar justo 8 espacios en su lugar.
 ESTANDAR DE CODIFICACIÓN DE JAVA

INDENTACIÓN

• Rompiendo líneas
Ejemplo:
 ESTANDAR DE CODIFICACIÓN DE JAVA

COMENTARIOS

Los programas Java pueden tener dos tipos de comentarios:

• comentarios de implementación
Los comentarios de implementación son aquellos que también se encuentran en
C++, delimitados por /*...*/, y //

• comentarios de documentación.
Los comentarios de documentación (conocidos como "doc comments") existen
sólo en Java, y se limitan por /**...*/.
 Proceso de Diseño de la GUI
Analizar y Producir un
comprender las prototipo de Evaluar el diseño con los
actividades del diseño en usuarios finales
usuario papel o en una
herramienta

Diseñar el Producir el
prototipo prototipo del Evaluar el diseño con los
diseño dinámico usuarios finales

Prototipo Implementar la interfaz del

ejecutable usuario final
Principios de diseño de Interfaces de
usuario
• Familiaridad del usuario:
• Utilizar términos y conceptos que se toman de la
experiencia de las personas que más utilizan el sistema.
• Consistencia:
• Siempre que sea posible , la interfaz debe ser
consistente en el sentido de que las operaciones
comparables se activan de la misma forma.
• Mínima sorpresa:
• El comportamiento del sistema no debe provocar
sorpresa a los usuarios.
• Recuperabilidad:
• La interfaz debe incluir mecanismos para permitir a los
usuarios recuperarse de los errores. Esto puede ser de
dos formas:
• Confirmación de acciones destructivas
• Proveer de un recurso para deshacer
• Guía al usuario:
• Cuando los errores ocurren , la interfaz debe proveer
retroalimentación significativa y características de ayuda
sensible al contexto.
• Diversidad de usuarios:
• La interfaz debe proveer características de interacción
apropiada para los diferentes tipos de usuarios.
Interacción del usuario
• Una interfaz coherente debe integrar la interacción
del usuario y la presentación de la información.
• Shneiderman(1998) clasifica la interacción en 5
estilos primarios:
• Manipulación directa:
• Interacción directa con los objetos de la pantalla.
• Rápida e intuitiva
• Fácil de aprender
• Ejemplo: para borrar un archivo , el usuario lo arrastra al bote
de basura. Videos de juegos
 • Puede ser difícil de implementar.
• Sólo es adecuada donde hay una metáfora visual para las tareas y
objetos.
• Selección de menús:
• El usuario selecciona un comando de una lista de posibilidades.
• Evita errores del usuario
• Se requiere teclear poco
• Lenta para usuarios experimentados.
• Puede llegar a ser complejo si existen muchas opciones en el
menú.
• Ejemplo: muchos de los sistemas de propósito general
• Llenado de formularios:
• Introducción de datos sencilla en los campos de un
formulario.
• Fácil de aprender
• Ocupa mucho espacio en la pantalla.
• Ejemplo: ingreso datos del cliente
• Lenguaje de comandos:
• Los usuarios emiten un comando especial y los parámetros
asociados para indicar al sistema que hacer.
• Poderoso y flexible
• Difícil de aprender
• Administración de errores pobre.
• Ejemplo: Sistemas operativos
• Lenguaje Natural:
• El usuario emite comandos en lenguaje natural .
• Accesible a usuarios casuales
• Fácil de ampliar
• Se requiere teclear más .
• Los sistemas de comprensión de lenguaje natural no son
fiables.
• Ejemplo: Sistemas de horarios, sistemas www de
recuperación de la información.
Presentación de la Información
• Para encontrar la mejor presentación de la
información es necesario conocer a los usuarios y y
la forma en que utilizarán el sistema. Factores a
considerar:
• ¿El usuario está interesado en información precisa o en
las relaciones entre los diferentes valores de los datos?
• ¿Qué tan rápido cambian los valores de la información?
¿Se indicarán de forma inmediata al usuario los cambios
de un valor?
• ¿El usuario debe llevar a cabo una acción en
respuesta a los cambios de la información?
• ¿El usuario necesita interactuar con la información
desplegada vía una interfaz de manipulación
directa?
• ¿La información que se va a desplegar es textual o
numérica? ¿Son importantes los valores relativos
de los elementos de la información?
Color en el diseño de la interfaz
• El color ayuda y mejora la presentación de la
interfaz , permitiendo al usuario comprender y
manejar la complejidad.
• Shneiderman(1998) establece 14 lineamientos
claves para la utilización efectiva del color.
• Los mas relevantes:
• Limitar el número de colores utilizados y ser
conservador al momento de utilizarlos . No utilizar mas
de 4 ó 5 colores diferentes en una ventana y no más de
7 en la interfaz total del sistema.
• Utilizar un cambio de color para mostrar un cambio
en el estado del sistema.
• Ejemplo semáforos de alerta que reportan estados
normal, precaución y alarma.
• Utilizar el código de colores para apoyar la tarea
que los usuarios están tratando de llevar a cabo.
• Un color para resaltar una situación anómala, otro para
similitudes.
• Utilizar el código de colores en una forma
consciente y consistente.
• Si usamos rojo para mostrar alarma , mantener esta
lógica durante todo el sistema
• Ser cuidadoso al utilizar pares de colores
• Dada la fisiología del ojo , las personas no pueden
enfocar el rojo y el azul simultáneamente .
• En general el color no debe utilizarse para
representar algún significado por dos razones:
• Cerca del 10 % de los hombres no perciben el color y
pueden malinterpretar el significado.
• Las percepciones humanas del color son diferentes y
existen convenciones diversas para varias profesiones Ej.
Rojo para conductor significa peligro, para el químico es
caliente.
• Si se utilizan muchos colores o sin son muy
brillantes , el despliegue puede ser confuso
Soporte al usuario, Sistema de ayuda
en línea
• Los mensajes producidos por el sistema en
respuesta a las acciones del usuario
• El sistema de ayuda en línea.
• La documentación suministrada con el sistema
Factores de diseño en la redacción del
mensaje de Error
• Contexto:
• El sistema guía del usuario debe estar pendiente de lo
que hace el usuario y ajustar el mensaje de salida al
contexto actual.
• Experiencia:
• Al aumentar la familiaridad con el sistema , aumenta la
molestia por mensajes largos y “sin significado”.
• El usuario principiante no comprende los mensaje
concisos.
• El sistema debe proveer de ambos tipos de mensajes
• Nivel de habilidad:
• Conocer al usuario y sus habilidades implica adecuar los
mensajes a la terminología que el utiliza.
• Estilo:
• Los mensajes deben ser positivos en lugar de negativos.
Activos y no pasivos. No deben ser insultantes o tratar de
ser chistosos.
• Cultura:
• Reconocer la cultura del país en lo posible evita malas
interpretaciones del contexto del mesaje.
 Documentación del usuario
Evaluadores Administradores Usuarios Usuarios Administradores
de sistemas del Sistemas Novatos experimentados del sistema

Descripción Documento de Manual de Manual de Guía del

funcional instalación introducción referencia administrador

Descripción de Cómo instalar Iniciando Descripción de Operación y

servicios el sistema recursos mantenimiento
Evaluación de la interfaz
• Aprendizaje:
• ¿Cuánto tiempo tarda un usuario nuevo en ser
productivo con el sistema?
• Velocidad de operación:
• ¿Qué tan bien responde el sistema a las operaciones de
trabajo del usuario?
• Robustez:
• ¿Qué tan tolerante es el sistema a los errores del
usuario?
• Recuperación:
• ¿Qué tan bien se recupera el sistema a los errores del
usuario?
• Adaptación:
• ¿Qué tan atado está el sistema a un solo modelo de
trabajo?
Gracias!