Documentos de Académico
Documentos de Profesional
Documentos de Cultura
I. GENERALIDADES
I.1. Definiciones
Introducimos en este apartado algunos conceptos generales que nos serán de utilidad en la
definición de estándares.
a. Aplicaciones
Llamaremos aplicación a cualquier desarrollo software funcionalmente independiente
que, no obstante, puede interconectarse, puntualmente, a otros desarrollos. Ejemplos de
aplicaciones son Sistema de Compras, Sistema de Planillas, Sistema de Contabilidad,
etc. A cada aplicación se le asocia un código único de 2 letras que denominamos
código de aplicación
b. Funciones.
Las aplicaciones se dividen en funciones con poca relación entre sí cada una de las
cuales cubre un aspecto del organigrama funcional de la aplicación. Una aplicación
típica no tendrá más de una docena de tales funciones. Las funciones se descomponen, a
su vez, en subfunciones. La comunicación entre las diferentes subfunciones de una
misma función será, en general, elevada. La subdivisión funcional puede continuar,
pero solo será significativa a propósitos de estandarización un máximo de cinco niveles
funcionales. Funciones y subfunciones se codifican empleando un carácter para cada
nivel hasta un máximo de cinco caracteres, formando una combinación única dentro de
cada aplicación.
c. Módulos
El nivel más bajo de esta jerarquía está formado por el módulo. Una subfunción emplea
uno o más módulos para realizar la tarea que tiene encomendada.
d. Identificador
Por ultimo definiremos el concepto de identificador, el cual emplearemos
frecuentemente en la normalización de los nombres de los diferentes objetos
I.2. Entornos
Desde un punto de vista lógico se distinguirán tres entornos bien diferenciados: Desarrollo
(DEV), Pruebas (QAS) y Producción (PRD).
a. Desarrollo (DEV)
El Entorno de Desarrollo comprende todos los módulos sobre los cuales trabaja el
grupo de programación en las primeras fases del desarrollo de una nueva aplicación:
desarrollo y pruebas unitarias. Existirá un Entorno de Desarrollo por cada nueva
aplicación que se empiece.
b. Pruebas (QAS)
El Entorno de Pruebas se compone de los módulos y escenarios de datos necesarios
para realizar las pruebas de integración previas a la puesta en servicio de una
aplicación. Una vez entregada a los usuarios (clientes), el grupo de mantenimiento
realizará su labor sobre este entorno. Cada aplicación dispondrá de su propio
Entorno de Pruebas siendo posible disponer simultáneamente de más de una versión
de la misma aplicación.
c. Producción (PRD)
El Entorno de Producción consta de los datos y módulos ejecutables que emplean
los usuarios (clientes) finales así como de todos los módulos necesarios para
reconstruir la versión actual de los ejecutables.
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
I.3. Responsabilidades
a. Desarrollo (DEV)
Cada programador dispondrá de sus propios directorios de trabajo en su
equipo local así como de datos independientes para realizar pruebas unitarias
de los módulos que vaya desarrollando.
Es responsabilidad del programador la organización de su directorio de
trabajo así como el mantenimiento de sus datos de prueba. Se favorecerá el
traspaso de módulos en desarrollo entre programadores con la única
limitación de que un programador no pueda modificar el trabajo de otro.
b. Pruebas (QAS)
Desde el primer momento que se necesite probar la integración de dos o más
módulos se creará un Entorno de Pruebas (QAS) para la aplicación
correspondiente. A este entorno se pasarán los módulos que hayan superado
las pruebas unitarias y sobre los que se vayan a realizar las pruebas de
integración. El Área de Infraestructura creará los Entornos de Pruebas
necesarios pasando, a continuación, la responsabilidad del mantenimiento de
los escenarios de pruebas y de la coherencia del Entorno de Pruebas al
Analista responsable de la aplicación. Hasta la puesta en servicio de la
aplicación, existirán simultáneamente los Entornos de Desarrollo y Pruebas
para una misma aplicación.
Para las aplicaciones en explotación es posible mantener varias versiones de
la misma en el Entorno de Pruebas (por ejemplo, una para mantenimiento y
otra para desarrollar nuevas funcionalidades). Los Entornos de Pruebas de
las diferentes aplicaciones estarán aislados. Con el acuerdo previo de los
Analistas responsables, la Unidad de TI facilitará la colaboración entre los
diferentes grupos de desarrollo.
c. Producción (PRD)
Las aplicaciones se distribuirán en el Entorno de Producción (PRD)
atendiendo a consideraciones de seguridad y de rendimiento. La integridad y
seguridad de los datos y módulos en el Entorno de Producción serán
responsabilidad exclusiva del Área de Infraestructura. Se debe definir un
procedimiento de pase a producción, para permitir a los grupos de
mantenimiento de aplicaciones el pase a producción de módulos
modificados o nuevos al Entorno de Producción.
Nota:
1. El control de los botones es CommandButton
2. El nombre para los botones se mantendrá como se ha venido trabajado
(cmdNombredeControl).
3. Los botones de los formularios se podían dentro de un Frame sin borde y estarán
juntos con el botón Salir ligeramente separado de los demás y estarán en el orden
siguiente según se necesiten: Nuevo, Editar, Eliminar, Guardar, Cancelar,
Búsqueda / Imprimir, Salir.
4. Los botones Nuevo, Búsqueda y Salir siempre estarán activos al momento de
cargar el formulario si este es un formulario de mantenimiento o se muestran de
acuerdo a los permisos que tiene el Usuario.
5. Los demás botones se activaran según el usuario los requiera.
6. El botón Salir estará inactivo al presionar Nuevo, Editar, Eliminar y se volverá a
activar al presionar Guardar o Cancelar.
7. Si el mantenimiento es en una Grilla se trabajara con 2 botones (+) Agregar un
Item , (-) Eliminar un item (Si es nuevo se elimina de la lista, caso contrario se
pinta el Item de color rojo indicando este que va a ser eliminado, cuando un item
esta eliminado el botón (-) cambia a (R) para que el usuario retornen este item a
ala lista). Si no se utiliza los botones + y – utilizar los botones alineados a la
derecha de la grilla en forma vertical en el mismo orden e iconos del
mantenimiento general.
II.1.4. Comentarios
Normas generales a seguir en toda documentación:
a. Los comentarios deben añadir claridad al código. Deben contar el
por qué y no el cómo.
b. Deben ser concisos.
c. Idealmente hay que escribir la documentación antes que el código.
Hay dos tipos de comentarios: Comentarios de implementación y
comentarios de documentación. Los comentarios de implementación
son del tipo: // ... o /* ... */. Los comentarios de documentación son del
tipo: /** ... */. Los comentarios de implementación describen el
código, los de documentación una visión de más alto nivel para gente
que no tiene el código a mano y que sólo quiere usarlo. La información
de los comentarios no debe ser evidente, deben ser cosas que no están
contenidas en el código Los comentarios no deben estar en cajas
dibujadas con asteriscos o similar ni deben incluir caracteres extraños
2.1.4.1. Comentarios de implementación
Comentarios de bloque: Al comienzo de cada fichero o bloque. No se
usan en este proyecto Comentarios de línea: Son comentarios
explicativos de una parte pequeña del código. Sintaxis: // ... o /* ... */
2.1.4.2. Comentarios de documentación
Son los comentarios destinados a ser procesados por javadoc.
Importante: No se pueden usar comentarios de documentación para
bloques de código dentro de métodos porque javadoc los asigna a la
primera declaración que encuentre detrás de ellos
2.1.5. Declaraciones
2.1.5.1. Número de declaraciones por línea
Se debe declarar cada variable en una línea distinta, de esta forma cada
variable se puede comentar por separado. Ejemplo:
int level, size; // Mal
int level; // Indentation level
int size; // Size of table
Los arrays se deben declarar de este modo:
double[] table; // Bien
double []table; // Mal
2.1.5.2. Inicialización
Inicializar cada variable en su declaración a menos que su valor inicial
dependa de algún cálculo
2.1.5.3. Localización
En el comienzo de los bloques. La única excepción es el bucle for. No
se deben declarar variables con el mismo nombre que otras en un
método.
2.1.5.4. Declaraciones de clases e interfaces
Se siguen estas reglas:
o No hay espacio entre el nombre del método, el paréntesis y la
lista de parámetros
o Se abre la llave { al final de la misma línea que la declaración
o La llave de } debe aparecer en línea aparte con la misma
indentación que el método o clase que cierra
2.1.6. Sentencias
2.1.6.1. Sentencias simples
Cada línea debe contener una sola sentencia. Ejemplos
argv++; // Bien
argc++; // Bien
argv++; argc++; // Mal
2.1.6.2. Sentencias compuestas
Son las que están entre llaves { y }
o Deben estar indentadas a un nivel superior que el precedente
o Todas las sentencias del tipo if o for, while, do ... while deberán
tener llaves aunque sólo contengan una sentencia, de esta forma
se evita la introducción accidental de errores si se añaden
posteriormente sentencias
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Sentencia if
if (condition) {
statements;
}
if (condition) {
statements;
} else {
statements;
}
if (condition) {
statements;
} else if (condition) {
statements;
} else {
statements;
}
Ejemplo. Antes:
void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}
Después:
void cancelAll(Collection c) {
for (Object o : c) {
((TimerTask)o).cancel();
}
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
}
Sentencia while:
while (condition) {
statements;
}
while (condition);
Sentencia do-while:
do {
statements;
} while ( condition);
switch ( condition) {
case ABC:
statements;
/* El comentario tambien indentado */
case DEF:
statements;
break;
case XYZ:
statements;
break;
default:
statements;
break;
}
Declaración de Constantes
Ambito : Ejemplos :
Local (Constante a Nivel de Form) lcstrEstadoEmbarque as String = “E”
Publico (Constante a Nivel de Aplicación) pcdecPorcentaje as Single = “1.25”
Declaración de Funciones y Procedimientos
Función: <Ámbito> <f> <Tipo de Ejemplo :
Dato><Nombre Función> lfrsDevuelveTipoEnvase
Procedimiento <p><Nombre> psLlenarDatos
Declaración de Parámetros
Parámetros Funciones y Procedimientos Ejemplos :
<prm> <Tipo de Dato><Nombre> prmstrApellidosNombres as String
Nombramiento de Archivos
Tipo de Archivo Nomenclatura Propiedades
Grupo grpNombreGrupo
Proyecto EXE prjNombreProyecto
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Proyecto Datos DLL datNombreProyecto Ejecución desatendida
Actualizar controles ActiveX
Conservado en Memoria
Proyecto Negocio DLL negNombreProyecto Ejecución desatendida
Actualizar controles ActiveX
Conservado en Memoria
Proyecto Útiles DLL utlNombreProyecto Ejecución desatendida
Actualizar controles ActiveX
Conservado en Memoria
Proyecto Control OCX ctlNombreProyecto
Formulario formAreaNombreFormulario Font=Tahoma
Size= 8
BorderStyle= 2,3,4
Módulo modAreaNombreModulo
Clase clsNombreClase Instancing=5-MultiUse
MTSTransaccionMode=0-
NotAnMTSObject
Archivo de Recursos resNombreArchivo
Nombramiento de Clases
Tipo de Clase Nomenclatura Propiedades
Clase de Datos datNombreClase Instancing=5- MultiUse
MTSTransaccionMode=3-
Requiere transaccion
Clase de Negocios negNombreClase Instancing=5- MultiUse
MTSTransaccionMode=3-
Requiere transacción
Clase de Usuario o clsNombreClase Instancing=5-MultiUse
Cliente MTSTransaccionMode=1-
NoTransacctions
Clase de Útiles utlNombreClase Instancing=5-MultiUse
MTSTransaccionMode=1-
NoTransacctions
Métodos y Propiedades Inician con mayúscula y no
usan caracteres de tipo.
Public Property Let
Text(New_Text As String)
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
III. DE LA APLICACIÓN
Bases de datos
Sistemas propietarios
Aplicaciones
Cliente externas
delgado
Cliente
grueso
Tecnología y herramientas
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Aplicación en 3 capas:
Modelo Físico:
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Modelo de despliegue:
Modelo de Componentes:
ESTÁNDAR DE DESARROLLO “LEONCITO”
Unidad de TI Fecha Emisión: 24/09/2019
Revisión: 2
Arquitectura de componentes:
Capa de usuario:
o Crear una clase en el cliente (capa usuario) que guarde los datos del usuario
conectado
o No leer la fecha del servidor (solo enn Store procedures)