Convenciones y estándares

Abreviaturas de los módulos del sistema

Para nombrar a los diferentes módulos del sistema se podrán utilizar las siguientes abreviaturas (en orden por sigla):

Abreviatura	Módulo
MC	Módulo de Clientes
ME	Módulo de Ejecutivos
MP	Módulo de Personal
MPAS	Módulo de Pasajes
MR	Módulo de Rutas
MREP	Módulo de Reparaciones
MT	Módulo de Trámites
MU	Módulo de Unidades
MV	Módulo de Viajes

Nomenclatura básica de codificación

Identificador	Reglas de Nomenclatura	Ejemplo
Clases	Los nombres de las clases deben ser palabras completas, en mayúsculas y minúsculas, con la primera letra de cada palabra en mayúscula. Los nombres de clases deben ser simples y descriptivos, utilizando palabras completas y acrónimos o abreviaturas (a no ser que la abreviatura sea ampliamente conocida, como URL o HTML).	class Raster; class ImageSprite;
Interfaces	Los nombres de las interfaces deberían seguir las mismas reglas indicadas para las clases.	interface RasterDelegate; interface Storing;
Métodos	Los métodos deberían ser verbos, en mayúsculas y minúsculas, con la primera letra en minúscula, y la primera letra de cada una de las palabras internas en mayúscula.	run(); runFast(); getBackground();
Variables	Todos los nombres de variables de instancia o de clase deben estar constituidos por palabras con la primera letra de la primera palabra en minúscula y la primera letra de las palabras internas en mayúscula. Los nombres de variables deben ser cortos y significativos. La elección de un nombre de variable debe ser mnemotécnico, es decir, pensado para que un lector casual comprenda su uso al verla. Se deben evitar las variables de una sola letra, excepto en variables temporales de corto uso. Nombres comunes para este tipo de variables son: i, j, k, m y n para enteros. c, d, y e para caracteres.	int i; float myWidth;
Constantes	Los nombres de variables declaradas como constantes de clase y constantes ANSI, deberían escribirse siempre en mayúsculas, con las palabras internas separadas por el signo de subrayado ("_"). Las constantes ANSI se deben evitar en lo posible, para facilitar la depuración del código.	int MIN_WIDTH = 4; int MAX_WIDTH = 999; int GET_THE_CPU = 1;

Nomenclatura del modelo

Los nombres de clases y métodos que corresponden a Patrones de Diseño o pertenecen al framework de dominio o persistencia se escribirán en idioma inglés.
Los nombres de clases y métodos que corresponden al modelo (ubicado en la capa de dominio) se escribirán en idioma español.
Los nombres de clases y métodos pertenecientes a "generics subdomains" del framework de dominio (por ejemplo Money) se escribirán en idioma inglés.
Todos los comentarios en el código se escribirán en idioma español y sin acentos.
Todas las clases del modelo deberán implementar o extender uno (y sólo uno) de los tipos Entity, Value Object o Service, dependiendo del tipo de clase, según las buenas prácticas de DDD.
Todos los objetos del modelo podrán componerse de dos clases y una interfase. Una de las clases será un EJB del tipo Entity, donde no se escribirá lógica de negocio; el Entity EJB solamente guardará los atributos que se quieran persistir y sus correspondientes setters y getters. La otra clase será un EJB SessionBean, que contendrá la lógica de negocio y hará uso de los datos del EJB Entity. La interfase expondrá los servicios que podrán ser invocados remotamente desde el Session Bean y será, por supuesto, la interfase que implemente la lógica de negocio. (No es necesario que existan las tres clases para cada objeto de dominio. Se crearán de acuerdo a los requerimientos del modelo.)
Un Entity de DDD estará compuesto por su Entity EJB correspondiente y su SessionBean que implemente la lógica de negocio. Los Entity se llamarán como se llame la Entidad en el dominio (por ejemplo: "Unidad") y extenderán de la clase Entity del framework de DDD, la interfase de la lógica de negocio se llamará como el nombre de la Entidad + el nombre "Service" (por ejemplo: "UnidadService") y las clases SessionBeans tendrán el mismo nombre que la interfase + la palabra "Bean" (por ejempo: "UnidadServiceBean").
Un Value Object de DDD estará compuesto por su Entity EJB correspondiende y su SessionBean que implemente la lógica de negocio. La convención será la misma que para los Entity, salvo que el Entity EJB extenderá de la clase ValueObject del framework de DDD.
Bajo ningún concepto se permite separar en distintos paquetes los datos de un objeto de dominio de su lógica de negocio (por ejemplo: "Unidad" y "UnidadServiceBean" no pueden encontrarse en distintos paquetes). Si existen dos clases para representar un objeto del modelo en el código, las dos deben estar contenidas en el mismo paquete y siguiente la convención de los puntos anteriores.
No es necesario que las interfases de los SessionBeans que pertenecen a un objeto de dominio extiendan de la interfase Service del framework de DDD. Por ejemplo: "UnidadService" no debe heredar de "Service". La interfase "Service" fue creada para objetos de lógica pura, que no son parte de ningún Entity o ValueObject de DDD.
Las clases públicas de la capa de servicio (ServiceLayer) deberán llamarse de la forma "Nombre de la clase" + "ServiceLayer". La mayoría de los ServiceLayer serán SessionBeans, por lo tanto, se compondrán por una interfase y una implementación llamada del mismo modo con el agregado de la palabra "Bean". (Por ejemplo: interfase: "UnidadServiceLayer"; implementación: "UnidadServiceLayerBean".
Si hay atributos, constructores, setters o getters que no son parte del modelo, pero son requeridos por las herramientas de introspección usadas o el motor de persistencia, se agregarán en la clase al final de todos los otros métodos que sí pertenecen al negocio, y además se crearán con la visibilidad más reducida posible. (Por ejemplo: aunque el framework de DDD no provee un atributo "id" para los ValueObjects - y tampoco es correcto que lo provea -, pero el motor de persistencia puede requerir un atributo "id" para persistir el objeto y sus setters y getters correspondientes. En ese caso se creará un "id" privado auto-generado y setters y getters protegidos.)
No se deben usar annotations que pertenezcan a la aplicación, en ninguna clase de la capa de dominio. Si deben incluirse parámetros de configuración o mapeo ORM para el motor de persistencia, se especificarán mediante el uso de archivos de configuración externos como XML o properties. Fuera de la capa de dominio, podrán utilizarse las annotations, que resultan más cómodas para el desarrollo.
La capa de dominio debe construirse para ser completamente independiente de la aplicación que la utiliza. No debe existir ninguna dependencia de la capa de dominio hacia cualquier otra capa. La capa de dominio podrá ejecutarse fuera de la aplicación, ya que será la representación del modelo y la fuente de mayor valor para el negocio.
Siempre que se pueda (para consultas más o menos simples) se utilizará como convención para los nombres de los NamedQueries la siguiente plantilla: "EntidadByAtributoAtributoAtributo". Por ejemplo: "UnidadesByModeloMarca", "UnidadesByModelo", "VariableTypeByName", etc. El Primer "Entity" es el nombre de la clase que será devuelta por el NamedQuery. El nombre de la Entity será en singular si se sabe que sólo se obtendrá un resultado y en plural si se obtendrá una lista.
Para las constantes de nombres de NamedQueries, se utilizará la plantilla "MODULO_ENTIDAD_BY_ATRIBUTO_ATRIBUTO_ATRIBUTO", donde "MODULO" es la abreviatura del módulo al cual corresponde la consulta. Por ejemplo: "MV_TERMINAL_BY_NOMBRE", perteneciendo la consulta al Módulo de Viajes.
En las pruebas unitarias del sistema, se debe nombrar a las clases con el mismo nombre de la clase que están probando, con el agregado al final de la palabra "Test". Por ejemplo, "RutaTest" prueba a la clase "Ruta".
Se usará como codificación de los archivos del código fuente el estándar ISO-8859-1.

Riesgos

Probabilidad de Ocurrencia

1. Baja: (< 15%)
- Poco probable.

2. Media: (>15% y <85%)
- Posible / Muy Posible.

3. Alta: (>85%)
- Casi seguro

Severidad

1. Baja:
- Impacto menor en costo y en calendario.
- Sin cambio de beneficios.

2. Media
- Impacto importante en costo y calendario.
- Impacto menor en beneficios.

3. Alta
- Impacto importante en costo y beneficios.
- Impacto mayor en beneficios.

Exposición al riesgo

Fórmula para el cálculo de la exposición al riesgo:
Exposición al Riesgo = Probabilidad de Ocurrencia x Severidad

Estimaciones

Para las estimaciones se toma en cuenta el concepto de "story points" aportado por la metodología Scrum. Éste indica que se debe considerar por cada user story cuánto se tardaría en desarrollarlo, si una persona estuviese trabajando full-time sobre el mismo.

Las unidades equivalentes a los story points indicados en nuestro proyecto son los días, consideradas 8 horas/hombre por día.

Al momento de estimar, la unidad mínima de estimación debe ser de 0,5 storypoints. Esto se debe a que no se conoce con demasiada certeza el tiempo que puede llevar alguna tarea, o bien se podría caer en un micromanagement. En el sprint backlog, en el caso de que el tiempo necesario para terminar alguna tarea sea muy pequeño y el valor de "0,5" sea demasiado alto para expresarlo, se puede marcar como tiempo necesario "0", pero dejar indicado en el Estado de la tarea que todavía se está realizando.

Documentación

En la wiki, los documentos se deberán formar de las siguientes partes:

El título del artículo debe repetirse como primera línea del contenido del mismo, con el formato de texto <H1>.
Los títulos internos al artículo deben ir con el formato <H2>.
Los subtítulos internos al artículo deben ir con el formato <H4>.
Los conceptos importantes y/o que no pueden obviarse al leer el artículo deben ir en negrita.