Está en la página 1de 18

XXXXX

COD VERSION V1.0

Estndares 2011-09-15 CONFIDECIAL

Empresa XXXX
ESTANDARIZACION PARA DESARROLLO Y MODELAMIENTO DE DATOS

DETALLE:
TTULO: SUBTTULO: ARCHIVO: AUTOR: ESTADO: VERSIN: Inicial 1.0 Empresa XXX Estndares SNCP-EST-DESARROLLO-V1_0

Empresa XXXX Estndares

COD V1.0

HISTORIAL DE CAMBIOS
FECHA 2011-09-14 AUTOR DESCRIPCIN Creacin del documento primera versin

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina

ii

Empresa XXXX Estndares

COD V1.0

Contenido
1 2 GENERALIDADES ..................................................................................................................... 1 APLICACIN .............................................................................................................................. 1 2.1 HERRAMIENTAS .................................................................................................................... 1 2.2 ENTORNOS ........................................................................................................................... 1 2.3 UNIDADES (HERRAMIENTAS) .................................................................................................. 2 2.4 MDULOS ............................................................................................................................ 2 2.5 OBJETOS.............................................................................................................................. 3 2.6 ARQUITECTURA .................................................................................................................... 3 2.7 DIRECTORIOS ....................................................................................................................... 4 2.7.1 Definicin de Directorios................................................................................................. 4 2.8 ARCHIVOS ............................................................................................................................ 5 2.8.1 Definicin de Archivos .................................................................................................... 6 3 DESARROLLO ........................................................................................................................... 8 3.1 3.2 3.3 3.4 4 DOCUMENTACIN ................................................................................................................. 8 CLASES ................................................................................................................................ 9 CREACIN DE VARIABLES ...................................................................................................... 9 FUNCIONES .......................................................................................................................... 9

BASE DE DATOS ..................................................................................................................... 10 4.1 4.2 4.3 4.4 TABLAS Y VISTAS ................................................................................................................ 10 CAMPOS............................................................................................................................. 11 RESTRICCIONES: ................................................................................................................ 11 SQL .................................................................................................................................. 12

5 6

PESO DE LAS PGINAS ......................................................................................................... 14 REFERENCIAS ........................................................................................................................ 15

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina

iii

Empresa XXXX Estndares

COD V1.0

ESTANDARES

1 Generalidades
Este documento trata de definir los lineamientos que definen las normas principales que se deben seguir para una nomenclatura en el diseo de la base de datos as como para l para el desarrollo de las aplicaciones, para esto se utilizarn prefijos de las unidades (herramientas), prefijos de mdulos y nombres descriptivos que sern definidas a criterio del desarrollador. Los nombres que identifican los objetos, componentes, funciones, clases, y otros, debern informar de la forma ms comprensible y explicita la naturaleza del objeto, debern contener una breve descripcin conceptual de su existencia.

2 Aplicacin
Esta seccin explica cual es el tratamiento que se debe dar a los diferentes componentes que conforman la aplicacin como son: rbol de directorios, herramientas, unidades, entornos, mdulos, archivos, etc. Estos debern seguir los lineamientos que se detallan a continuacin.

2.1

Herramientas
Mdulo GENERAL Descripcin

Herramienta Postgres SQL

2.2

Entornos

Los entornos son los espacios en los cuales se realizan las diferentes tareas para completar el desarrollo de una aplicacin, pasando por los siguientes entornos:

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 1 de 18

Empresa XXXX Estndares

COD V1.0

Desarrollo.- El entorno de desarrollo comprende todos los mdulos sobre los cuales trabaja el grupo de programacin en las primeras fases del desarrollo de una nueva aplicacin: desarrollo y pruebas unitarias. Pruebas.- En el entorno de pruebas se realizarn la validacin de la funcionalidad con el dueo de la herramienta y se desarrollaran las validaciones de la nueva aplicacin con respecto a todo el sistema. Capacitacin.- En este entorno se cargar una versin final de la aplicacin antes de la ejecucin en produccin, con la cual se podr capacitar a los usuarios y realizar la transicin al ambiente de produccin reduciendo el impacto futuro. Produccin.- El ambiente de produccin comprende todo el sistema transaccional donde se ejecutan las versiones finales de las aplicaciones o mdulos.

2.3

Unidades (herramientas)

Las unidades se las define a todas las herramientas que posee el EMPRESA XXX como son catalogo, subasta, etc. Adems de unidades generales como son como que representa a compras, las principales unidades de las define a continuacin, las que deben seguir la siguiente sintaxis para definir los prefijos de las unidades se debe tomar las (3) primeras letras de cada palabra si existen ms de dos se deber separar cada prefijo con (.) PREFIJO gen com UNIDAD (HERRAMIENTA) Persona Compras

2.4

Mdulos

La definicin de mdulos se define como funcionalidades que pueden ser agregadas a una herramienta, la que pude estar conformada por uno a varios mdulos. Los prefijos que sern utilizados para denominar a los mdulos debern ser tomados de las (4) primeras letras del nombre del mdulo que definan de manera nica a cada modulo dentro del sistema.

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 2 de 18

Empresa XXXX Estndares

COD V1.0

PREFIJO

MODULO

2.5

Objetos

La nomenclatura para los objetos dentro del desarrollo y la base de datos deber seguir la siguiente definicin para todas las sintaxis que se utilicen. PREFIJO tab clas js exe f tgr v pk fk uk OBJETO Tabla Clase Java Script Archivos ejecutan acciones Funcin SQL Triger Vista Clave Primaria Clave candidata Unicidad

2.6

Arquitectura

El desarrollo de aplicaciones debe seguir un modelo vista controlador para todos los mdulos que sean desarrollados. Modelo, Esta es la representacin especfica de la informacin con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema tambin puede operar con ms datos no relativos a la

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 3 de 18

Empresa XXXX Estndares

COD V1.0

presentacin, haciendo uso integrado de otras lgicas de negocio y de datos afines con el sistema modelado
1

Vista.- Sencillamente es la representacin visual del modelo. Es la encargada de representar los componentes visuales en la pantalla, Esta asociada a un Modelo, esto le permite que al momento de cambiar el Modelo, la vista redibujara la parte afectada para reflejar los cambios. Controlador.- Es el escuchador a los eventos que genere el usuario, es decir es el que permite que interacte el usuario con el sistema. Interpreta los eventos (las entradas) y modela la capa de negocio ejecutando todas las rutinas en clases.

2.7

Directorios

El contendor principal de la aplicacin es el directorio compras/ donde se almacenarn clases, tablas, y los diferentes mdulos del sistema, los directorios deben ser definidos de acuerdo a la siguiente sintaxis. El nombre del directorio debe contener mximo (32) caracteres con nombres descriptivos del mdulo, si el nombre est compuesto por dos palabras estas deben ser escritas con minscula a excepcin de las letras iniciales de la segunda palabra. Compras/[nombre Descriptivo] Ejemplo: Compras/convenioMarco

2.7.1 Definicin de Directorios


Los directorios generales dentro de la path compras/ deben utilizar nombres descriptivos y deben ser detallada la funcionalidad o modulo que en esta se almacena. Compras/tablas/.- Almacena el modelo del negocio, en esta se encuentra todas las clases que sirven para conectar con la base de datos o con otros medios de recuperacin de informacin. Compras/clases/.- Este directorio guarda las clases que ejecutan rutinas que sirven para definir el negocio.

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 4 de 18

Empresa XXXX Estndares

COD V1.0

Compras/exe/.- Guarda todos los archivos que son utilizados para enviar a guardar bloques de datos o rutinas que son obtenidas desde las vistas, estos archivos sern considerados como ejecutables, estos solo deben contener cdigo php. Compras/js/.- Contiene archivos java script ya sean clases o funciones, con cdigo que ser ejecutado en el cliente como parte de la vista. Compras/til/.Compras/presentacin/.- Este directorio guarda todas las clases que sirven para dar formato a los datos que se presentarn en las vistas por ejemplo, botones, valida formatos, dibuja textos, dibuja combos, etc. Compras/seguridad/.- En seguridad se almacena clases que sirven para el control de las seguridades que utiliza el sistema como son validacin de datos de ingreso, validacin de la sesin de un usuario. Compras/includes/.- En este directorio se almacenarn todas las libreras que se hayan desarrollado para el sistema como libreras externas tales como: nuSoap, phpmailes, jcalendar, etc. Compras/img/.- Almacena todas las imgenes que sern utilizadas dentro del sistema, las que servir para botones, banners, etc.

2.8

Archivos

Los archivos que se crearn dentro de los directorios debern seguir la siguiente sintaxis. Debern contener el prefijo del objeto, seguido del prefijo de la unidad, si existe mdulos se debe especificar el prefijo del modulo y un nombre descriptivo del archivo separados por (.). Este nombre debe ser escrito en minscula excepto la primera letra de la segunda palabra si el nombre est conformado por ms de dos palabras, el nmero de caracteres no debe sobrepasar los (32) caracteres. [Prefijo objeto].[prefijo unidad].[prefijo modulo].[Nombre descriptivo].php Ejemplo: Ejemplo de la sintaxis conforme al desarrollo

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 5 de 18

Empresa XXXX Estndares

COD V1.0

2.8.1 Definicin de Archivos


De acuerdo a la sintaxis definida para los archivos vamos a indicar como ser esta para los directorios ms importantes del sistema. Tablas.- Los archivos que contienen las clases del modelo de datos que son almacenadas dentro del directorio tablas/ se definirn de acuerdo a la siguiente sintaxis: Tab.[prefijo herramienta].[prefijo modulo].[Nombre descriptivo].php Ejemplo: Ejemplo de la sintaxis conforme al desarrollo Clases.- Los archivos que son almacenados en el directorio clases/ guardan la capa del negocio en el sistema, deben seguir la siguiente sintaxis. Clas.[prefijo herramienta].[prefijo modulo].[Nombre descriptivo].php Ejemplo: Ejemplo de la sintaxis conforme al desarrollo Exe.- Los archivos conocidos como ejecutables deben ser escritos bajo la siguiente sintaxis: Exe.[Prefijo herramienta].[prefijo modulo].[Nombre descriptivo].php Ejemplo: Ejemplo de la sintaxis conforme al desarrollo

Java Script.- Los archivos que contienen las codificaciones deben ser almacenados en este directorio, se podr almacenar en nuevos directorios si es necesario todos estos archivos seguirn la siguiente sintaxis: Js.[Prefijo de herramienta][Prefijo Modulo][Nombre descriptivo].php Ejemplo: Ejemplo de la sintaxis conforme al desarrollo
Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 6 de 18

Empresa XXXX Estndares

COD V1.0

Seguridad.- Para los mdulos que tienen que ver son la seguridad de la aplicacin se tiene que utilizar la siguiente sintaxis: seg.[Prefijo herramienta].[prefijo modulo].[Nombre descriptivo].php Ejemplo: Ejemplo de la sintaxis conforme al desarrollo . Imgenes.- Las imgenes deben seguir el la siguiente sintaxis: Img.[Nombre descriptivo].png Ejemplo: Ejemplo de la sintaxis conforme al desarrollo

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 7 de 18

Empresa XXXX Estndares

COD V1.0

3 Desarrollo
Esta seccin detalla cmo se debe llevar el desarrollo de aplicaciones dentro del EMPRESA XXX, para lo cual se definen normas que deben ser seguidas por los desarrolladores para una correcta organizacin de la informacin.

3.1

Documentacin

La documentacin es muy importante ya que presenta la informacin de un determinado proyecto, archivo, tabla, algoritmo, etc. Esta documentacin debe estar presente en todos los archivos del sistema siguiendo la siguiente sintaxis para archivos principales. Ejemplo: /** * Tabla Ciudad * * Esta clase permite acceder a la tabla Ciudad * usando los mtodos bsicos * * @property object $_base * @property int $_clave * @property string $_secuencia * @property string $_codigoPais * @property string $_codigo * @property string $_ciudad * @property string $_nombre * * @package * @subpackage * @author fausUC@gmmail.com * @version 1.0 * @copyright * * @todo Tareas Pendientes TODO List * - redefinir metodos * - configurar variables * - realizar pruebas */ Para archivos en los que no sean principales se debe considerar al menos los siguientes parmetros dentro de la documentacin. /** * Tabla Ciudad * * Esta clase permite acceder a la tabla Ciudad * * @package * @subpackage

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 8 de 18

Empresa XXXX Estndares

COD V1.0

* @author * @version 1.0 * @todo Tareas Pendientes TODO List * - redefinir metodos * - configurar variables * - realizar pruebas */

3.2

Clases

Los nombres deben ser significativos, todas las palabras deben ser escritas en minscula a excepcin de la primera letra de la segunda palabra, el tamao no debe ser superior a (32) caracteres en total y no debe contener espacios, el conector para un campo cuyo nombre tenga dos (2) palabras es underscord (_). Clas_[Prefijo herramienta]_[Prefijo modulo]_[Nombre descriptivo] Ejemplo: class sie_corp_tablaCiudad { }

3.3

Creacin de Variables

Los nombres deben ser significativos, palabra ser con minscula, el tamao no debe ser superior a 32 caracteres en total y no debe contener espacios, debe ser in minsculas; el conector para un campo cuyo nombre tenga dos (2) palabras es underscord (_). /** * @var string */ protected $_clave;

3.4

Funciones

Los nombres deben ser significativos, el inicio del nombre ser con mayscula, el tamao no debe ser superior a 32 caracteres en total y no debe contener espacios, debe ser in minsculas; el conector para un campo cuyo nombre tenga dos (2) palabras es la segunda palabra inicia con Mayscula.

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 9 de 18

Empresa XXXX Estndares

COD V1.0

Ejemplo: /** * sqlInsert * * Devuelve la cadena sql para insertar * * @return string (slq insert) */ public function sqlInsert() { }

4 Base de Datos
El modelo de la base de datos deber ser diseado con power designer, y deber contener mnimo una documentacin bsica como la que se describe a continuacin. El modelo tendr las referencias de: versin, nombres del creador, nombres de los analistas, fecha de creacin o modificacin y versin. Ejemplo: Creado Por: Revisado Por: Fecha de ltima modificacin: Versin:

4.1

Tablas y Vistas

Cualquier objeto que contenga datos de forma fsica (tablas), ser codificado de acuerdo a la sintaxis (en lo posible el nombre identificativo en singular): [unidad]_[nombre descriptivo] Ejemplo: Tgen_persona Cualquier objeto que contenga datos de forma lgica (vistas), ser codificado de acuerdo a la sintaxis: [Prfijo objeto ][prefijo herramienta][Nombre descriptivo]

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 10 de 18

Empresa XXXX Estndares

COD V1.0

Ejemplo: v_sie_buscaProveedor El tamao del cdigo no debe ser superior a 32 caracteres en total y no debe contener espacios; el conector para una tabla cuyo nombre tenga dos (2) palabras ser underscord (_).

4.2

Campos

Los nombres de campos (atributos) deben ser significativos, el tamao no debe ser superior a 32 caracteres en total y no debe contener espacios, debe ser escrito en minsculas; el conector para un campo cuyo nombre tenga dos (2) palabras es underscord (_). Adems de su codificacin,

el atributo o campo deber tener las cuatro (4) letras primeras que lo identifiquen unvocamente de los dems, y que servirn para referenciar los objetos que contiene. Ejemplo: pers_id pers_identificacion estu_titulo cata_nombre (Campo de la clave primaria de la tabla persona) (Campo Identificacin de la tabal persona) (Campo Titulo de la tabla estudio) (Campo Nombre del tabla catalogo)

En caso que el nombre de una tabla sea compuesta, el atributo o campo deber tener las cuatro (4) letras primeras de cada palabra que lo identifiquen unvocamente de los dems, y que servirn para referenciar los objetos que contiene. Ejemplo: deta_cata_descripcion (Campo Descripcin de la tabla detalle_catalogo)

4.3

Restricciones:

Llamaremos ndices primarios a aquellos que identifican unvocamente a cada fila de una tabla (clave primaria o clave candidata). El resto de los ndices que se definan en una tabla (no son nicos y se aaden para optimizar algunas sentencias) diremos que son secundarios.

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 11 de 18

Empresa XXXX Estndares

COD V1.0

Los ndices primarios se nombrarn sustituyendo pk_U (siendo U el cdigo de la unidad) por el prefijo pk_u_ y el nombre descriptivo del ndice de la tabla y aadiendo el sufijo _n, en donde n es un nmero secuencial que nos permite diferenciar los distintos ndices. Por ejemplo, en la unidad com, desea insertar un ndice para la tabla tcom_solicitud_compra, se definen dos ndices primarios, de la siguiente manera: pk_com_solicitud_1 pk_com_solicitud_12

Los ndices secundarios se nombrarn sustituyendo fk_u (siendo CM el prefijo de la unidad) por el prefijo fk_u_ y el nombre descriptivo de la clave que debe ser comprensible y aadiendo el sufijo _n, en donde n es un nmero secuencial que nos permite diferenciar los distintos ndices. Por ejemplo, para una la unidad compra com si se desea definir una clave candidata para la tabla tcom_det_soli_compra, el ndice se de definira de la siguiente forma: fk_com_solicitud_detalle_1 fk_com_solicitud_detalle_2

4.4

SQL

La codificacin de cualquier sentencia DML (SELECT, UPDATE, DELETE o INSERT) debe emplear la identacin para su clarificacin, facilitando la bsqueda de las tablas implicadas (FROM) y de las condiciones impuestas (WHERE). Cuando estn implicadas ms de una tabla, deben emplearse, asimismo, las abreviaturas asignadas a cada tabla, vista o secuencia para cualificar los campos ayudando de este modo, al optimizador a realizar el parse de la sentencia. Es imposible dar aqu un formato genrico para todas las sentencias que SQL nos permite construir. Damos a continuacin algunos ejemplos de codificacin, a modo de sugerencia, si bien, cualquier otro estilo es aceptable siempre que ayude a la legibilidad de las sentencias y sea homogneo a travs de toda la aplicacin. Mostramos, en primer lugar, un SELECT simple. Si es necesario recuperar muchos campos, podran agruparse varios por lnea. Como se ha comentado en diferentes ocasiones, se emplean las abreviaturas para cualificar los campos cuando se trata de un join: SELECT FAC.C_INTERNO, FAC.N_FACT_PROV,

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 12 de 18

Empresa XXXX Estndares

COD V1.0

FAC.F_GRABACION, FAC.I_BRUTO, FAC.C_TIPO, TF.D_TIPO FROM CT_FACTURAS FAC, CT_TIPOS_FACTURAS TF WHERE F.C_TIPO = TP.C_TIPO En los INSERT es importante destacar que deben especificarse los nombres de los campos para mantener la independencia lgica de la sentencia con respecto a los cambios en la definicin de la tabla: INSERT INTO CT_TIPOS_FACTURAS (C_TIPO, D_TIPO, S_TIPO) VALUES ('J', 'DOCUMENTO A JUSTIFICAR', 'A JUSTIFICAR'); Igualmente, se especifican los nombres de los campos para mantener la independencia lgica en la sentencia UPDATE: UPDATE CT_TIPOS_FACTURAS SET C_TIPO = W_C_TIPO, D_TIPO = W_D_TIPO, S_TIPO = W_S_TIPO WHERE C_TIPO = W_C_TIPO;

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 13 de 18

Empresa XXXX Estndares

COD V1.0

5 Peso de las Pginas2


Los sitios web deben tener un peso mximo permitido por pgina que no supere una cantidad razonable de kilobytes (kb) que impidan su visualizacin. En este sentido, lo razonable depender directamente del tipo de sitio que se est desarrollando y de la conexin con la que cuente la mayor parte de los usuarios. Por ejemplo, si se trata de un sitio dedicado a usuarios de regiones extremas que tienen una conexin muy lenta, 50 kb ser un tamao considerable, respecto de si se compara eso con usuarios que se conecten en una ciudad del centro del pas. No obstante, se puede estudiar cunto se demora en que una pgina llegue completamente al computador de un usuario si se calcula lo siguiente: A. Si un mdem transmite a 56 kbps (kilobits por segundo) significa que por cada segundo de transmisin, en condiciones ideales, es capaz de enviar 7 kb (kilobytes) de informacin. B. Si una pgina pesa 70 kb, en condiciones ideales demorar 10 segundos en aparecer completa en el computador del usuario. C. Aunque no hay informacin tcnica consistente para establecer la velocidad promedio de un mdem, puesto que depende de diversas variables tcnicas, la experiencia indica que stos se conectan habitualmente a la mitad de su valor declarado. Entre las variables que afectan la calidad de la conexin se cuentan la capacidad del computador, la congestin de las redes y el nivel de visitas del servidor, entre otras. D. Dado lo anterior, la pgina de 70 kb sealada en el ejemplo anterior, tardara 20 segundos en desplegarse completamente. Con esa evidencia, la pregunta que debe hacerse cualquier desarrollador de sitios, es si sus usuarios estarn dispuestos a esperar todo el tiempo que se demora una pgina web en bajar completamente. Como lo ms probable es que la paciencia de los usuarios se agotar ms rpido que su deseo por acceder a la pgina que tarda en desplegarse, es necesario preocuparse de que el tamao de las pginas siempre tienda a bajar y no a aumentar. Las normas internacionales al respecto indican que un usuario no esperar ms de: 5 segundos para que aparezca algo visible en la pantalla 10 segundos para que aparezca algo legible en la pantalla 30 segundos hasta hacer un click hacia otra parte del sitio o hacia otro sitio
2

Gua para Desarrollo de Sitios Web - Gobierno de Chile cap II

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 14 de 18

Empresa XXXX Estndares

COD V1.0

6 Referencias
Gua para Desarrollo de Sitios Web - Gobierno de Chile cap II http://es.wikipedia.org/wiki/Modelo_Vista_Controlador NORMAS Y ESTANDARES Desarrollo de Aplicaciones Universidad de Cordoba

Realizado por:

Revisado Por:

Fecha ultima actualizacin

Nmero de pgina Pgina 15 de 18

También podría gustarte